StaygeLabs - leadership

The Hub Trap

2026-05-28T00:00:00+00:00

A leader I know recently told me she felt a wave of relief when a teammate offered, almost casually, to take a few meetings off her plate.

Not because the meetings were the problem. They weren't, really. It was that for months, she had been the person everyone routed through — the keeper of context, the answerer of questions, the one who knew which thread connected to which decision. People were "executing." People were "helping." But every path on the project map ran through her, and nobody had noticed she was the map.

When that one person offered, unprompted, to lift something — it wasn't the task that moved her. It was being seen.

If you've ever had that feeling, you might be in what I've started calling the hub trap.

What the hub trap actually is</h2>
It's not just being busy. It's not just being a manager or a lead. Plenty of people are busy and plenty of people lead things without ending up here.
The hub trap is a specific shape of overload: you are the only person holding the whole picture, and the structure of the work depends on you continuing to hold it. Teammates can do their pieces well — and often do — but the coordination, the context, the why this connects to that, lives in your head. Take you out for a week and the project doesn't pause; it fragments.
Some signs you might be in it:

People come to you when they need something, almost never when you might need something.</li>
You spend more time re-explaining context than producing work.</li>
Your calendar is mostly other people's questions.</li>
When you imagine taking a real vacation, you feel a small spike of panic — not about the work itself, but about who would even know what's going on.</li>
You've been called "indispensable" recently. (This is rarely the compliment it sounds like.)</li> </ul>
Here's the cruel thing: you usually end up here because you're good. You picked things up quickly. You filled gaps no one else saw. You said yes when others hesitated. The reward for being competent in a system without enough structure is that the system reorganizes itself around you. Quietly. Without anyone deciding to do it.
Why nobody comes to help</h2>
The most disorienting part of being a hub is that the support gap doesn't feel proportional to your output. You're doing more, and somehow you're getting less care, not more.
A few reasons this happens:
Competence reads as self-sufficiency. When you handle hard things without visible struggle, people assume you don't need anything. The smoother you make it look, the more invisible the cost becomes.
Hubs broadcast availability, not need. If you're always the one responding, people learn that the flow goes one direction. There's no precedent in the relationship for them to reach toward you.
Most workplaces don't have a "check on the load-bearing wall" ritual. Performance reviews catch outputs. Status updates catch blockers. Almost nothing catches the slow accumulation of context debt on one person's shoulders.
You've probably been signaling "I've got it" — sometimes out loud, sometimes just by continuing to show up and deliver. That signal works. It works so well it becomes a trap.
How to tell if it's you</h2>
Not all heavy roles are hub traps. Some leaders carry a lot and the structure supports them. The diagnostic isn't "am I tired" — it's about where the dependencies live.
Try this:

Imagine you are out for two full weeks. No email. No Slack. What stalls? If the answer is "specific deliverables I own," that's a normal workload. If the answer is "the project's sense of direction, half the decisions, and most of the cross-team coordination" — hub. </li>

Look at the last ten things that landed in your inbox or DMs. How many were people needing something from you versus people offering something to you? A healthy ratio isn't 50/50, but it shouldn't be 10/0 either. </li>

Ask yourself who else could answer the question "what's the current state of this project?" If the honest answer is no one — hub. </li>

Notice the moments you feel resentful. Resentment is often a signal that the implicit contract has gone lopsided. You're giving something the relationship isn't built to give back. </li> </ol>
Getting out (without burning it down)</h2>
Here's the part I want to be honest about: you usually can't fix this in a week, and most of the advice floating around — delegate more! set boundaries! — is too thin to actually help. The hub trap is structural, not personal, and unwinding it takes structural moves.
What actually helps, in roughly the order I've seen it work:
1. Make the invisible visible. Before you can redistribute load, somebody with authority has to see it. Not in a venting way — in a concrete, written, "here is the scope I am currently holding" way. List the roles, not just the tasks. "I'm the tech lead, the grooming owner, the cross-team liaison, and the escalation path for two other programs." Most managers genuinely don't know. They've been getting good outputs and assuming the inputs were fine.
2. Identify the one thing only you can do. Hubs absorb work indiscriminately because everything feels important when it lands on you. Step back and ask: of everything I'm holding, what is the small set of things that genuinely require my judgment, my context, or my authority? Protect those. Everything else is a candidate to move.
3. Build first responders. You don't need to hand off whole roles to start. You need one other person who is the first place a given question goes. Pick a component, a workstream, a recurring meeting — and route it through someone else by default. Your job becomes escalation, not initiation. This is the single highest-leverage move, and it's also the one hubs resist most, because it feels slower in the short term. It is. It's worth it.
4. Stop being the documentation. If the only place certain context lives is in your head, write it down — even badly. A scrappy decision log, a "current state of the project" doc updated weekly, a Jira page nobody loves but everyone can read. The goal isn't perfect documentation; it's that you stop being the only API.
5. Follow up on the people who did show up. Somewhere in your last few months there was probably a version of that teammate who offered, unprompted, to take something off your plate. That awareness is rare. Don't let that gesture die in a thank-you. Bring them closer. Tell them what else would help. Those are the people who, with a little structure, become co-owners instead of just helpers.
6. Have the harder conversation. At some point, if the load doesn't shift, the conversation with your manager has to get more direct than "I'm a little overwhelmed." It has to name the structure. I am holding five roles. Something is being underdone, and right now I'm absorbing that cost invisibly. We need to decide together which role I'm actually in. This is uncomfortable. It's also the conversation that actually changes things.
The reframe</h2>
The hub trap isn't a sign you're failing. It's usually a sign you've been succeeding inside a structure that wasn't built to scale with your success. The system found a way to extract more from you without ever explicitly asking, and you kept saying yes because that's how you got here in the first place.
But "indispensable" isn't a career goal. It's a ceiling. It's also a quiet kind of loneliness — being the only one who knows where everything is.
The way out isn't to care less. It's to stop being the only one who cares about everything.
And if you're reading this and recognizing yourself: the relief you'd feel if someone just noticed — that's not a small thing. That's information. It's telling you what's been missing.
You don't have to wait for someone else to offer.

The Autonomy Paradox

2026-05-26T00:00:00+00:00

The instinct for time management in technical work isn't just a junior engineer problem — it's a new-to-the-work problem. It's just more visible in junior folks.
When someone is new, you expect them to struggle. So you coach them to communicate, ask questions, get unblocked. Good advice. But here's the tension: people also want to make an impact. They want to figure things out themselves. So no matter how much you encourage communication, in any given moment, they're the ones deciding what to do. That decision is autonomy.
Autonomy means no intervention. And that creates two opposing forces:

A pull to proactively engage (ask for help early)</li>
A pull to reactively engage (push through, then surface)</li> </ul>
Take a concrete scenario. You're new to an org. You're tasked with reverse engineering firmware — specifically the peripherals. You hit a new peripheral and get stuck. Do you push through or ask for help?
Most junior engineers push through. They don't want to signal they're stuck. Sometimes that pays off. Often, they burn hours on something a five-minute conversation would have solved. My rule of thumb: no meaningful progress in two hours? Stop and ask.
But now flip it. You've been on that project a year. You know the target cold. And yet you're still being nudged to check in at every step. At some point that's not coaching — it's friction. You finish your last peripheral analysis, you see something interesting, you go explore it. You figure something out. It's genuinely useful. But it's not what the PI wanted.
This is the other failure mode. Not the junior burning cycles alone — but the experienced engineer drifting out of scope because the check-in culture never adapted to their growth.
PIs have their own styles, but ultimately they're busy. In a perfect world, their teams would operate autonomously — calibrated autonomy, where the level of independence matches the person's familiarity with the work, not just their seniority. The coaching challenge isn't "always communicate more." It's teaching people to recognize which moment they're in — and respond accordingly.

Defining Your Own Role

2026-05-26T00:00:00+00:00

When you're new to an organization and someone senior takes an interest in you, it feels like luck. They find you — you don't find them. They see something worth developing. You start listening, following their lead, shaping your work around their feedback. And it works. You get good. You get recognized. Five years in, you're solid at the job and you know it.
Then you part ways. And somewhere in the aftermath, you realize: you never actually defined this role for yourself.
The mentor relationship is easy to underestimate while it's working. What it gives you isn't just advice — it's a framework for what good looks like. You measure your output against their expectations. You take on work they point you toward. You develop judgment, but it's judgment calibrated to someone else's model of the job. That's not a flaw in the relationship. That's how mentorship works. But it means that the version of yourself you built was partly constructed around a reference point that is now gone.
This is different from losing a manager. A manager tells you what to do. A mentor shapes how you think about what's worth doing. When a manager leaves, you get reassigned. When a mentor leaves, you have to figure out what you actually value — what impact looks like on your own terms, not theirs.
The hard part isn't the skill gap. After five years, the skills are there. The hard part is that you've never had to answer the question from scratch: what do I think this role should be? You've been answering a different question — am I doing this role well by someone else's measure?
Defining your own role means deciding what problems you want to own, what output actually matters to you, what kind of work you're willing to fight for. It also means tolerating the discomfort of not having someone to sanity-check against. That discomfort can feel like regression. It isn't. It's just the first time you're doing it without scaffolding.
The mentorship gave you something real — and it also wasn't the right one. Those can both be true. The clearer that becomes, the easier it is to stop building toward someone else's measure of good and start building toward your own.