Engineering Managers Don't Have a Time Problem
A diagnosis, a countermeasure, and one real case. Six weeks of system work, and what it actually changed.
Engineering managers running multiple teams keep asking me the same question. How do they get their time back?
Here is the pattern I see, and what works.
The calendar is the symptom. The fix is not productivity hacks. It starts with auditing where the hours actually go.
Where the hours went
Running this audit with one manager, three teams under him, five buckets emerged.
Direct management: time spent supporting the tech teams.
Alignment: time with the wider organization, including upper management.
Personal work: time for the manager’s own job — thinking, planning, learning.
Bookable time: time available to work with others, including the tech teams.
Code reviews: time spent reviewing the team’s code.
The manager’s free time lived in two of those buckets: bookable and personal.
For one observed week, direct management ate 8 hours. Bookable time, another 9. Code reviews, 3. Alignment, 5. Personal work, the hours he needed to think, to write, to plan, to learn: only 4. The smallest bucket was the one his growth depended on.
The system around him had no other way to function. The teams brought every question, every blocker, every decision. He absorbed them. The calendar followed.
Why “block your calendar” doesn’t work
The standard advice for an engineering manager drowning in meetings is the same one I hear everywhere. Block focus time. Say no to meetings. Decline anything not urgent and important.
This advice fails for one reason. It treats time as a personal discipline problem. It isn’t.
If you block two hours of focus time on Tuesday morning and the team has no other way to unblock a deployment decision, what happens? Someone Slacks you. You context-switch. The block is broken. You either answer and lose the focus, or ignore and the team waits while delivery slips. The block doesn’t survive contact with the system that needs you.
The deeper problem isn’t on your calendar. It’s in the workflow that funnels every decision through the manager. You can refuse meetings all you want. The underlying demand doesn’t go away. It shows up as a 47-message Slack thread instead. AI compounds it. Your engineers produce more code and more decisions every week. Every one of them still routes through you.
When you audit the system underneath the calendar, four causes consistently show up.
Role expectations are fuzzy. Nobody on the teams knows exactly which decisions belong to them and which belong to the manager, so the safe move is to bring everything up.
There is no mechanism to see how the teams are actually doing. No clear flow metrics, no visible blockers, no shared signal. The only way to know is to ask. The only person to ask is the manager.
The teams have different needs from the manager, and nothing surfaces those needs. So the manager gives each team the same support. That means over-serving some and under-serving others.
And the manager’s time with each team isn’t tracked. The gap between perceived time and actual time is invisible until you measure it.
None of these are calendar problems. They are system gaps that produce calendar problems. Add up four small structural holes. You get a manager whose week is no longer his own.
Rebuild the system, not the schedule
Here is what works. The four moves I’ve seen implemented that reverse the situation.
Visual management and KPIs visible to you and to the team. It shows how work flows through each team, updated automatically. The team can see its own progression and blockers without booking a meeting. You become the leader who responds to signals instead of inbound noise.
Clear role boundaries with each team. It is about what decisions stay yours and what belongs to the team. How to ask for help, and what help actually means. Thirty minutes per team, replacing months of fuzzy expectation.
Delivery objectives, replacing recurring alignment slots. The objectives drive the meetings. The resulting performance gaps trigger problem-solving and learnings. No objective, no meeting.
Sanctuary blocks defended on the calendar. Personal work and bookable time, both reserved as real appointments, declined when something tried to override them. Bookable time stays open for the team to book when they have a clear ask. Without one, it stays defended.
Six weeks later
Back to the manager we started with. Six weeks after the four moves were in place, his numbers had moved. Personal work more than doubled, from 4 hours to 9. Code reviews dropped from 3 to 1, because the team was unblocking itself. Alignment eased from 5 to 4 as recurring syncs gave way to purpose-driven ones. Across the week, he reclaimed about four hours outright.
Two numbers in the chart need a second look. The simple reading misses what they mean.
Bookable time fell, from 9 hours to 5. On paper that looks like a loss: the manager less available, the team less supported. In practice it was the opposite. The teams used less of his bookable time because they needed it less. Better autonomy showed up as a smaller number. Read only the chart, and you’d flag it as a problem. Read the system, and it’s one of the strongest signals in the data.
The opposite pattern shows up in direct management. It dropped from 8 hours to 6, far from solved. This is the part most case studies would quietly drop. I’m leaving it in, because it’s the truth. Six weeks rebuilt the system enough to reclaim his personal time and to let the teams carry their own load. It did not solve direct management. That bucket needs a different intervention, and it was still open when this snapshot was taken.
The pattern
Engineering managers don’t have a time problem. They have a system that produces a time problem.
The calendar reflects the system. So does the burnout.
Real system work moves some things fast, some slowly, and some not at all in the first cycle. The manager who expects a clean win in six weeks is the manager who gives up in week three. This one didn’t get a clean win. He got his thinking time back, teams that needed him less, and one stubborn bucket still on the list. That’s what progress actually looks like.
Design the system first. The time follows.
One more thing. If you want to see where your own system leaks, the Delivery Scorecard takes two minutes. Ten questions, and you know which bucket to look at first.