Imagine two engineering teams whose manager holds regular feedback conversations and brings unresolved launch decisions to the director. Now that role is removed, and both teams report directly to the director. An approval step and a weekly reporting meeting disappear. So far, the change looks useful.
Then the teams disagree about moving a service to a new system. One needs the move finished before a customer launch, while the other thinks the proposed date leaves too little time to test recovery from a failure.
A senior engineer starts coordinating the move, which may be exactly the right work for them. However, the plan still expects them to finish a reporting feature that Friday. Meanwhile, a newer engineer needs feedback, but the director's next available slot is a fortnight away.
In this hypothetical reorganization, work the teams relied on has lost its place in the plan. A flatter structure can work, provided those responsibilities are covered.
The work that remains needs an owner, the authority to act, and time in the plan.
Some management work should disappear
There is still a reasonable case for fewer layers. If you've prepared a status update and then repackaged it for several meetings, you know how much effort can go into moving information without making a decision.
Andy Jassy described that overhead in his September 2024 message to Amazon employees: repeated preparatory meetings and long review chains. Amazon's stated aim in flattening included giving people closer to the work more ownership.
That gives us a useful question for a review meeting: what judgment does this step add? Sometimes it challenges an expensive or risky decision. At other times, the same information is simply passing through another inbox.
Removing the latter can help. But coaching an engineer or resolving a disagreement between teams takes time and judgment. Those responsibilities need separate consideration, even when the same person performs all of them.
Who gets to decide now?
The senior engineer can explain the technical options, but changing the launch date may require the director. That is a sensible division of responsibility, provided the engineer knows who will decide and when they can get an answer.
Julie Wulf's research on flattened firms found that fewer layers could coexist with greater control at the top. Although it concerns senior hierarchies in large firms, the distinction matters here: removing a reporting level does not automatically delegate its decisions.
Intel illustrates this. In July 2025 earnings remarks, its CEO reported reducing management layers by approximately 50%, while also introducing personal approval of every major chip design before fabrication.
That may be appropriate during a turnaround. Teams still need a way to establish their own decision authority and get timely answers.
At the planning meeting where the two teams agree the move's scope and dates, confirm which choices the engineer can make and which need the director. Record that agreement in the work item, including when any outstanding decision is needed and where to escalate if the director cannot respond in time.
If a decision later stalls or is overturned, revisit it at the next planning meeting or retrospective. Was authority unclear, was the decision-maker unavailable, or had a commitment changed? The director should agree a correction with both teams and update the same work item. If the same kind of decision keeps returning to the director, consider delegating it with clear limits.
What gets postponed is worth watching
Even with clear decision rights, some work is easier to postpone. An incident demands attention, whereas a development conversation can move to next week. So can a careful handoff or someone's first opportunity to lead. Delivery may continue while support quietly thins out.
A Microsoft study of engineering managers identified developing talent, enabling autonomy, and clearing obstacles as valued attributes, with availability helping managers perform those functions. It studied people's perceptions, rather than the effects of removing managers, but it identifies work worth preserving.
Peers and technical leads can help the newer engineer learn. But a manager still needs to handle performance concerns and career decisions. If a senior engineer takes on regular mentoring, their delivery commitments need to leave time for it.
There is also knowledge that can leave with a person: why a service has an unusual recovery requirement, or whom to consult before changing it. Where a handover is possible, start with context needed for an upcoming decision. If the change has already happened, record what the team knows and still needs to check.
Look for missing support as well as delays
You may be implementing a change you did not choose, without a full account of the previous manager's work. Start in an existing meeting: where has someone waited for a decision, missed useful feedback, or picked up extra coordination? Choose one example to address.
Also consider an engineer who finishes every assigned task without getting a supported chance to lead a design review. In a one-to-one, ask what they want to learn next and who has time to help. If you are seeking support, bring an example of work you would like to try.
| Work to examine | A useful next question |
|---|---|
| Repeated updates | What decision uses this, and could one version serve everyone? |
| Waiting for approval | Who can decide, and when do we need an answer? |
| Learning and feedback | What would help this person develop, and who can support it? |
| Added coordination | Which commitment needs to change to make room? |
| Missing context | What do we need to establish before changing an old decision? |
Agree one adjustment with the person who can authorize it. That might mean combining updates or arranging a small design review for an engineer to lead, with a colleague who has time to help. Use the planning or development notes you already keep.
If you cannot change the priorities yourself, bring a specific choice to your manager.
An engineer asking their manager to choose
I can coordinate the service move this week, but that will push the reporting feature into next week. Which should take priority?
That gives the manager a specific choice. However, some choices will exceed their authority too.
Take the tradeoff to your own leadership
The director has a responsibility upward as well. If an executive commitment prevents a local adjustment, bring the consequence and a recommendation to whoever owns that commitment.
A director taking a recommendation upward
The service move needs our senior engineer to resolve the recovery-testing plan with both teams. I recommend moving the reporting feature to next week. If both dates must hold, we need to reduce scope or agree help from another team. Can we confirm the priority today?
The director should also explain how they will cover the feedback and development work the removed manager handled. If they cannot make room, their own manager needs to help decide which existing duty can change or where support can come from. Otherwise, a delivery-only discussion can leave coaching squeezed out again.
Where routine approvals keep travelling upward, propose a specific category of decision the director or teams could own, with agreed limits. Then bring the answer back to the teams and update their commitments. If no decision comes, make the unresolved consequence visible rather than presenting both dates as secure.
Make room for the leadership work that remains
At your next planning meeting or one-to-one, choose one responsibility that has moved or lost its owner since the reorganization. Agree the answers to three questions:
- Who will do this work?
- What can they decide?
- What changes in the plan to make room?
A one-off handover may need a temporary adjustment. But if the engineer keeps coordinating between teams, whoever sets delivery commitments must allow for that work in future plans. The engineer can explain the tradeoff; their leaders are responsible for deciding what the team can promise.
At the next meeting, check whether the adjustment happened. If you agreed feedback or a development opportunity, check that the person received the promised support.