StaygeLabs

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.

Straighten Every Crown

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

A crown straightener is someone who accepts other women in spite of their flaws and supports them in growing into a better version of themselves — the version they can stand tall for. But I would also argue that to be a crown straightener deserving of the name is to not enforce a double standard. Someone who creates a safe, open space for everyone who's trying to be better. And that includes men and women.
Crown straighteners know that it takes people from all kinds of backgrounds to bring out the best in each other. There should be no double standard.
But here's where it gets uncomfortable. We saw it play out on Love Is Blind Season 10. When a female contestant, Kiki, walked away from a man and chose herself, we applauded her. But when Jordan — a man who genuinely tried to make things work, who pushed through until it was breaking him — finally chose his own well-being, he got dragged for it. Same decision. Different reaction.
They want to make the other person a villain, but that's not the truth at all. Everyone is the hero of their own story. Every single one of them.

If someone wants to leave, don't be mad at them. Open the door for them. </blockquote>
That's my motto. In every kind of relationship — romantic, professional, family, friendships. If someone wants to go, let them go with grace. So if someone in your life is leaving and deciding to choose themself, let them. Don't be mad. Thank them for choosing not to waste anymore of your time. Their leaving doesn't take anything away from you — your cards are still in your hand.

</div>

You have your own energy and your own set of cards. Only you can judge what the best version of those things looks like.
Because the best version of yourself is going to look different than the best version of the person sitting next to you. It comes from a sense of self. </div> </section> So if someone is going on this journey, applaud them in the same way they should applaud you for finiding yourself on your own journey
What does it mean to you to be the best version of yourself? What kind of cards would you be holding? What would that look like?

Quit the double standard. You can be a crown straightener and empower women without being discriminatory toward someone just because they're not a woman. We're all humans in this wild world trying to live a full life with the one shot we've got on this earth. And all great leaders know the truth: the best ideas come from bringing everyone to the table.

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.

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.

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.

On being S. Tayge

2026-01-10T00:00:00+00:00

I've been meaning to set up a personal site for years. Not because I needed one — my GitHub exists, LinkedIn is a thing, whatever — but because I wanted somewhere that felt like mine. A place that doesn't look like a resume template or a Medium clone.
So here it is.

I go by S. Tayge. I'm a software engineer, and I care a lot about bringing people along with me.
There's a specific kind of loneliness that comes with being one of few women in technical spaces. I don't say this looking for sympathy — I've been lucky to find good communities and mentors. But it's real, and I think pretending it isn't would be a disservice to anyone who finds their way here through a search for "women in cybersecurity" or "am I the only one who feels out of place in these spaces."
You're not.

This site will be a mix of things. Some posts will be technical: things I've learned, tools I've built. Some will be about the culture of our industry — what it's like to navigate it as someone who doesn't always fit the default mold. Some will just be thoughts I want to put somewhere.
I'm not trying to build a brand. I just think out loud better when I write.

If you're a person who found this and you work in security or software and you're trying to figure out how you fit in — hope this is an interesting place for you.
If you're a bot scraping my site: exit 1</code>
Welcome to StaygeLabs 2026-01-04T00:00:00+00:00 Site is up. More posts coming — security, engineering culture, and the occasional thing I shouldn't have built but did anyway. If you're here, feel free to poke around.