More Experience, More Overwhelmed

Dev Leader Weekly 114

Nov 01, 2025

TL; DR:

The skills that got you here need to evolve
Communication, Networking, and Delegation!
Join the live stream (or check out the recording) on Monday, November 3rd, at 7:00 PM Pacific!

More Experience → More Overwhelm

It’s not uncommon for software developers to start to feel more overwhelmed in their day-to-day work as they gain more and more seniority. While it’s still not common with folks I talk to, I have heard from more and more that they’ve reached a level where they’re not interested in more responsibility -- EXACTLY because of this.

Some developers go from being solid individual contributors to being promoted into senior+ roles -- and suddenly, what used to be exciting challenges now feels like unending pressure. The work hasn’t gotten easier. The expectations have skyrocketed. And many end up quietly wondering: “Why do I feel like I’m doing worse even though I’ve technically leveled up?”

Let’s talk through what’s going on and how to navigate it.

Bandwidth Problem or Delegation Problem?

In the Reddit post that inspired this topic, a developer wrote: “I don’t have anyone to delegate to.” While technically that might look true from a reporting structure, I think there’s a bit more that we need to consider.

In my opinion, the sentence isn’t complete. It could more accurately be “I don’t have anyone to delegate to yet“, or a variation might be “I don’t know who to delegate to”.

At staff/principal level, it’s true -- you usually don’t have direct reports. You can’t just assign work to someone. But that doesn’t mean you can’t delegate. Delegation at this stage happens through influence, not authority.

That means building relationships, finding allies, and aligning incentives so that helping you also helps others. When you say “I have no one to delegate to,” what you often mean is, “I haven’t built the network or influence yet to make delegation possible.” And that’s fixable.

So you avoid feeling like you’re barking orders or confusing other developers with what they might have for other priorities, partner with engineering managers. It might be your manager you need to talk to about getting some help or, depending on the workstream, an engineering manager on another team. There’s likely plenty of work to be done that might be more level-appropriate for engineers with less experience, and it’s a GREAT opportunity for them to contribute.

I talked about all of this (and more from this article) in this code commute video:

From the ExperiencedDevs subreddit, this Redditor wanted to understand how to navigate a situation where they’re feeling overwhelmed as a staff engineer. How can they get back to a good spot?

Start Letting Go Without Dropping the Ball

When you feel like you can’t delegate AND it feels like you need to be tackling all of the most critical problems, it can feel like there’s no down time. Here’s how you can start to escape the trap of feeling too important to take a break.

1. Raise Awareness the Right Way

Talk to your manager. Always. Even if they can’t move people around immediately, they can’t help you with what they don’t know. You can frame it as business risk, not personal burnout, if you feel that you’re not having success with getting buy in or traction.

Instead of “I’m drowning,” try:

“I’m currently the single point of failure for these three systems. If I go on vacation or get sick, progress halts. We need to build resilience here.”

That framing isn’t personal or emotional -- it’s factual and responsible. Personally, I would hope that your manager is interested in helping with your well-being, so stating that you’re overwhelmed SHOULD be a good enough signal to get some traction. However, this can be a path forward if you’re feeling self-conscious about it or they’re perhaps not treating it with more priority.

2. Pitch Mutually Beneficial Opportunities

If you’re struggling to get support from other teams, when you ask them for help, don’t make it a one-way request. Reframe it as an opportunity.

Instead of “I need someone to help me with this system,” (which may come across as you must give me something), try:

“I’m looking for someone who wants to grow their system design or cross-team collaboration experience. I can help mentor them while we split ownership of this component.”

Now you’ve turned your pain point into a growth opportunity for someone else. That’s a far easier sell to other managers and senior engineers. It doesn’t mean they can automatically drop all of their priorities to support it, but it might signal an interesting opportunity for them to look into.

3. Build Your Informal Team

Even without direct reports, you still need a team. Think of it as a meta team -- a network of peers and partners across different projects.

You’ll need:

A few senior engineers who you can collaborate with regularly. And these can and should be within and across other teams.
Product or project managers who understand your priorities and can help adjust scope.
Engineering managers you can align with for shared ownership or resources.

The more you invest in these relationships, the easier it becomes to share load, get context, and unblock work. Influence compounds like interest.

4. Protect Your Strategic Energy

At staff and principal level, your brain is pulled in multiple directions -- execution, planning, mentoring, and firefighting. But if you spend all your time on the urgent, you’ll never have time for the important.

Block time for thinking, documenting, and forward-looking design. Protect it like you would a critical prod system. Because it is.

Again, I’ll remind you to work with your engineering manager if you need more support on this. This is a frequent conversation I try to have with my senior and principal engineers so that they have more time to focus on:

Level-appropriate work
Ambiguous challenges
More strategic efforts

5. Say “No” With Justification

Saying no isn’t a rebellion. It’s prioritization. When new work comes your way, connect your answer to impact.

Of course, you’ll need to do this in a way that’s naturally how you speak -- so don’t take this at face value. Instead of “I don’t have time,” say:

“If I take this on, I’ll have to pause the work on X that we said was important for delivering value for Y. Which outcome do we want to prioritize?”

That re-centers the discussion on outcomes instead of effort. You’re not refusing -- you’re facilitating trade-offs. In my experience as an engineering manager, I’ve had to do this with my own manager, my VP of engineering, and even the CTO of the company.

Sometimes it’s really just about bringing visibility to what pieces of the puzzle are currently in motion. From there, better and more informed decisions can be made.

The Real Skill Gap After Senior Engineer

The leap from senior to staff (and beyond) isn’t mostly about tech. It’s about scope, systems, and influence.

You can’t scale yourself by coding more -- you have to scale through others. That means the real growth areas are things like:

Delegation through influence.
Stakeholder communication.
Networking across teams.
Building alignment and buy-in.
Identifying and mitigating organizational risk.

These are not “soft skills.” They are force multipliers. They are how senior engineers become staff, and how staff engineers stay sane.

As you became more senior in your role, you:

Built credibility
Took ownership
Became the person people trust.

That’s exactly why you’re in demand. But now, the game has changed. The only way to keep growing is to stop trying to carry it all. Your value is no longer about personal output -- it’s about organizational throughput.

You’re not just a problem solver anymore. You’re a problem distributor. And if that feels unnatural?

Good. Growth always does.

Action Steps You Can Take This Week

List every responsibility you own. Mark which ones could be shared or taught.
Identify one area where you’re a single point of failure. Write a one-sentence business justification for why that’s risky. Any thoughts on who might be able to step in?
Schedule a sync with your manager. Bring that list and the business framing.
Reach out to another EM or senior engineer. Ask if someone on their team wants a growth opportunity on one of your projects.
Book one focus block for strategic work. Use it to write docs, roadmap risks, or clarify ownership. Set the boundary for yourself and keep it.

Repeat weekly.

Final Thoughts

If you’re feeling overwhelmed as you gain more experience, it’s not a sign that you’re failing. It’s a sign that your career has outgrown your current approach.

The skills that got you here -- ownership, independence, technical mastery -- aren’t the same ones that will sustain you here. The next level is about scaling yourself through influence, clarity, and trust.

Don’t wait until you’re burnt out to change how you work. Start delegating. Start influencing. Start teaching.

You earned your spot. Now learn to share it.

Dev Leader Weekly