This is your last article that you can read this month before you need to register a free LeadDev.com account.
Estimated reading time: 10 minutes
Key takeaways:
- Engineering managers are facing a tradeoff problem, not a** workload one**. Every expectation may be reasonable on its own. The issue is they’re all expanding at once. - Hidden tradeoffs are just as real as visible ones. Making choices explicit gives you something to push back on.
- The goal is to concentrate judgment where it changes outcomes.
Engineering managers are being asked to do more in every direction. You may be expected to help your team move faster with AI, stay close to technical decisions, coach people through ambiguity, influence across teams, and operate more strategically.
Each expectation may be reasonable on its own. The problem is that they are all expanding at the same time. This is usually framed as a workload problem. It is really a tradeoff problem.
Leadership capacity is finite. You only have so much attention available for coaching, reviewing, deciding, escalating, and making sense of an ever-changing organization. Something is already being dropped, whether anyone admits it or not. The clever move is to make those tradeoffs visible.
This is not about doing less for the sake of doing less. It is about getting clearer on where your judgment matters most, what you are choosing to neglect, and who needs to know.
Your inbox, upgraded. #
Receive weekly engineering insights to level up your leadership approach.
The engineering manager role does not scale linearly
Many engineering organizations talk about management capacity as if it scales linearly. Add a few more projects, stakeholders, or more dependencies, and the manager will somehow stretch to cover it.
However, scope does not grow in one clean direction. Sometimes it means more direct reports. Sometimes it means fewer, more senior people, running more work in parallel. Sometimes it means more cross-team dependencies, less explicit ownership, or more technical change flowing through the system at once.
AI adds another layer to this. It can help teams produce work faster, but it can also increase the amount of material you have to interpret: more feature proposals, longer specs, and more half-formed options competing for a decision. The bottleneck moves from producing work to figuring out which work is coherent, and worth doing.
The distinction between span of control and context load matters. Span of control is about how many people report to you. Context load is about how many conversations, decisions, and risks you are expected to handle at the same time.
Cognitive overload shows up in subtle ways: risks take longer to surface, coaching feedback gets shallower, and technical judgment becomes less reliable.
As a manager, you have not become less capable. It is the role that has simply exceeded the amount of context one person can hold well.
3 tradeoffs to make explicit #
The trouble with hidden tradeoffs is that they rarely feel like real choices. They feel like improvised calls under accumulating pressure.
You miss a design review because someone on the team is having a hard week and needs you more. You cut a one-to-one short because a cross-team fire is waiting. You let an engineer own a call because you cannot be everywhere. You skip the strategy doc because the delivery risk in front of you is louder.
None of those are automatically wrong. Most of them are exactly what a good manager should do. What matters is whether you made the trade deliberately and whether the people around you know you made it.
Let’s group some of these repeated tensions in pairs to explore alternatives to our default reactions.
More like this #
1. Depth vs. breadth
The first tradeoff is how deeply you can understand the systems and decisions you own while still covering a growing organizational surface.
Pick depth and you are in the design reviews, the architecture debates, and the risk conversations. You catch more directly. You can actually coach engineers through the details, but you have less time for alignment, influence, and stitching work together across teams.
Pick breadth and you spend your time shaping ownership, escalation paths, priorities, and where decisions get made. That might be exactly what the team needs, but if you never say so, your engineers keep expecting you in every important technical conversation while your manager expects you to be working three levels up.
Unmet expectations create frustration either way.
The clearer version sounds like this: “given our scope right now, I am going for breadth this quarter. I will spend less time in detailed design reviews and more time making sure we have the right owners, the right decision forums, and clear escalation paths.”
Now people have something concrete to push on. Your manager can challenge it. Your team can flag a risk. That is the whole point. Once the tradeoff is visible, it can be discussed and adjusted.
2. Urgency vs. importance
The second is how much of your time you protect for long-term quality, team health, and strategy when the pace never lets up.
Urgent work is loud. Incidents, escalations, blockers, an exec ask, a customer issue, a near deadline. It all demands you right now.
Important work, on the other hand, is usually quieter. Coaching a new tech lead. Writing down a decision rule so your intervention is not required the next time. Fixing the process gap that keeps generating fire drills. Building alignment before the next planning cycle blows up.
We tell ourselves we will get to the important stuff once things calm down. We all know that, in most places, things do not calm down.
A more deliberate, intentional version might be: “this month I am protecting time to coach our new tech leads. I will not be at every project status review unless there is a scope, reliability, or across-team dependency call that actually needs me.”
The exact sentence does not matter. Naming what gets less of you does. Skip that step and your calendar becomes your strategy, and the loudest thing always wins.
3. Presence vs. impact
The third tradeoff is how present you can be across every conversation and review without watering down the impact you have on the handful of things that really move the needle.
Managers confuse visibility with value all the time. Being in every meeting feels responsible. Being copied on every thread feels informed. Reviewing every decision feels safe. Past a certain point, though, visibility is just a tax on your judgment.
The better question is not, “where should I be?” It is, “where does my presence change the outcome?”
Sometimes that means dropping out of a recurring meeting and checking an AI recap. Sometimes it means letting an engineer run the architecture discussion and only stepping in if the decision crosses a line you agreed on ahead of time. Sometimes it means swapping status updates for a short list of risks, decisions needed, and dependencies still hanging.
A useful boundary sounds like this:* “I do not need to be in every discussion. I only need an early heads-up when a decision touches customer commitments, reliability, staffing, or another team’s roadmap.”*
That helps your team understand what your involvement actually means. Not that every decision should wait for you, but that the right decisions reach you at the right time, with enough context that your judgment is worth something when it gets there.
Let’s go a bit deeper on this.
Treat oversight as finite capacity #
We are usually disciplined about technical capacity. We track utilization, saturation, latency, error budgets, and bottlenecks. We accept, without argument, that a system degrades when demand outruns capacity. We almost never think this way about leadership.
Every org has a finite amount of review, decision-making, validation, and coaching to go around. Push past it and quality does not crash. It erodes. More work needs rework. Decisions get reopened. Ownership goes blurry. Managers turn reactive. Teams wait too long for a call, or give up and stop asking.
The usual response is to get more efficient. Shorter meetings, more delegation, cleaner routines, and protected focus time. All of that helps, but only so far. Efficiency buys back time. It does not let you off the hook for deciding where your judgment matters most.
A better starting move is to look hard at your oversight load itself.
Ask yourself which decisions genuinely need you. Which reviews you are doing out of pure habit. Where you are just re-running the judgment of an engineer who is already good enough to make the call. Which approvals create safety, and which only create delay. Where you are still the backstop because nobody made ownership clear.
Then take the load off on purpose. Kill the low-value approvals. Push ownership down to where it belongs. Ask senior engineers to own whole problem areas, not scattered tasks. Write down the decision rules so the routine calls stop coming to you. Swap repeated status checks for better operating signals. Make it obvious which risks need escalation and which ones the team should just handle.
The point is not to check out. It is to save your attention for the spots where your judgment actually changes what happens.
One concrete way to do this is to draw decision boundaries. Engineers make local implementation calls without your review. Tech leads own design decisions inside the architectural constraints you agreed on. You get pulled in when a decision affects scope, staffing, reliability, customer commitments, or another team. Directors get pulled in when the tradeoff hits org priorities or needs resources you do not control.
These boundaries will not be perfect, and they do not need to be. Their job is to kill the unnecessary escalations so the ones that remain are sharper.
Negotiate instead of absorb #
A lot of managers swallow these tensions in silence because naming them feels like admitting they cannot keep up. It is not that. It is leadership under constraints, which is the actual job.
The conversation with your manager should not sound like an admission of defeat. It should sound like a design problem you are solving together: “our scope is growing while the expectations around coaching, technical depth, and org leadership stay the same. These don’t all scale together. Let’s work on which tradeoffs we want to make on purpose.”
That reframe matters. You are not asking for sympathy. You are helping the org make a better choice.
A good manager of managers may not be able to take the pressure away tomorrow. However, they can clarify priorities, dial back conflicting asks, and stop measuring you against two goals that contradict each other.
Same goes for your team. Stepping back from some decisions? Say why. Protecting more time for coaching? Say what gets less of you. Asking senior engineers to own more of the technical judgment? Be clear about where they have the authority and where you still want to be looped in.
People handle tradeoffs far better than they handle ambiguity. The frustration usually is not the tradeoff itself. It is finding out too late that everyone had assumed a different one.
How to start #
You do not have to redesign the whole job to get going. Pick one tradeoff you are already making but have never said out loud. Write it as a sentence:* “this quarter I am optimizing for ___, which means I will deliberately spend less attention on ___.”*
For example: *”this quarter I am optimizing for broader org alignment, which means I will be less involved in routine project status tracking.” * Or: “this quarter I am optimizing for coaching our new tech leads, which means I’ll step back from some design discussions unless they cross the escalation lines we agreed on.”
Then test it. Take it to your manager and your team and ask: “what breaks if this is true?” Their answers tell you whether the tradeoff is ok, misunderstood, or genuinely risky.
Once a month, sit with four questions:
*What am I optimizing for right now?What is getting neglected because of it? Is that neglect on purpose or by accident?*Who needs to know?
This way you will keep the role from being shaped entirely by whichever pressure is loudest.
Engineering managers of the future #
As the job keeps expanding, engineering managers get asked to coach more people, watch over more systems, sit in more decisions, and influence more of the org, all on the assumption that these responsibilities can grow together. They cannot. Leadership capacity is finite, and something is already getting less of your attention.
The managers who do this well are not the ones who keep absorbing every new expectation forever. They are the ones who understand where their attention is worth the most, make those choices visible, and push their org to decide on purpose instead of finding out too late.