StaygeLabs - engineering culture

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.

The Brilliant Jerk Problem

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

Someone was particularly harsh to me once. Not in a way that was ambiguous — harsh in a way that landed. This person is well-regarded. Genuinely skilled, the kind of person whose opinion carries weight in a room. I gave them the benefit of the doubt. Everyone has bad days. The work is hard. Maybe something else was going on.
Then, later, someone else apologized to me on their behalf.
That's the thing I keep thinking about. Not the original incident — but the apology that came from a third party. Because that apology means something specific: other people knew. The behavior was familiar enough that someone else felt responsible for managing the aftermath. Not the person who did it. Someone around them.
That's not a bad day. That's a pattern with a support system built around it.
When an org has a brilliant jerk, it rarely just tolerates them. It builds informal infrastructure to absorb the damage — people who run interference, who translate their behavior for others, who smooth things over after. That infrastructure is invisible until you're the one receiving the apology. But it's real, and it's expensive, and it means the org has already made a decision. It decided that managing the fallout was preferable to addressing the source.
The "brilliant" part is why. Talent creates leverage, and leverage creates exceptions. The calculus is usually implicit: this person produces too much, knows too much, is too embedded to confront. So instead of confronting them, you build the workaround. And the workaround works well enough that the problem never becomes urgent enough to fix.
What it costs is harder to see. It's not just the people who get treated harshly. It's the ones who watch it happen, update their models of what behavior is acceptable here, and calibrate accordingly. Culture isn't what's written down. It's what people observe being tolerated — and then what they do next.
The third-party apology was kind. I appreciated it. But it was also a signal: this person's behavior is known, it's happened before, and the response is to apologize around them rather than to them. That's not a culture with a policy problem. That's a culture that's already chosen.

The Mask Tax

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

Say someone on your team tells you they can't handle multitasking. They're neurodivergent, and they're telling you directly. Now what?
There are two obvious moves. You accommodate: protect their focus time, route work differently, adjust expectations. Or you treat them the same as everyone else and let them figure it out. Neither is obviously right, and both can go wrong in ways that are hard to see until they've already done damage.
If you accommodate, you're making a judgment that their neurodivergence is the thing to optimize around, not the role. That can feel like support. It can also feel like you've quietly decided they can't do the job. It creates asymmetry — other people on the team don't get their workload managed the same way, and that breeds questions even when no one says anything out loud.
If you treat them the same, you're holding the standard. That can be respectful — you're taking them at face value as someone capable of figuring it out. Or it can be a way of not dealing with the actual problem. If they're struggling and you knew, you made a choice.
Experience makes it stranger. Someone who's been in the field a long time is supposed to have built their own strategies by now. Maybe they have. Or maybe they've been masking for years and they're telling you because they're exhausted, and what looks like competence is partly the cost of sustained adaptation.
The framing of "support them or let them struggle" is where the thinking usually gets stuck. It treats accommodation as a binary — special treatment or none — when the actual question is more specific: what does this person need in this role right now, and is that something the team can actually do?
A lot of neurodivergent people don't want exceptions. They want structural changes that would help anyone: fewer context switches, clearer task prioritization, async over synchronous where it's possible. The thing that helps them is often just better design. The accommodation isn't the special part — the special part is actually asking.
Most orgs never ask. They either quietly over-manage around it or quietly let the person struggle, and call both of those things "treating people fairly." Neither is. Fair isn't uniform. Fair is matching support to what someone actually needs to do the work well.