Thriving as a Software Engineer: The Time Sink of Engineering Management

Part of my #thrivingSWE article series. Read the previous one, or start at the beginning.

In the last article we talked about the "individual contributor" (IC) role. Today we'll talk about its counterpart, the engineering manager.

An engineering manager (EM) is a people manager who manages engineers. In some companies they may also manage people in adjacent technical roles, like program managers or user experience designers.

Engineering managers usually have a technical background and typically start out as engineers and grow into people managers for various reasons. If you're an EM already, you might have heard comments like this:

• "You're a great tech lead, now we need you to step up and manage the team as well!"
• "Promotion to the next level will be hard unless you manage a team."

Of course, what they don't tell you is that...

Yes, being a manager is a completely different job and just because you're good at being a software engineer it doesn't automatically follow that you'd be a good manager of software engineers.

This is why there is usually a bifurcation in the software engineer career ladder to separate EMs from ICs. (Note in particular that moving between the two branches of the ladder is usually non-trivial once you're past the first level after the split.)

But what they don't tell you about being an EM is that management can be a giant time sink that takes you away from technical work.

You'll find that blocks of uninterrupted time get scarcer and scarcer, making it harder for you to make progress on important tasks (managerial or technical) without doing some serious reworking of your calendar.

The Management Time Sink formula below demonstrates this:

This formula depends on two variables: D is the number of direct reports the manager has and P is the number of projects that the manager is managing.

The number of direct reports is important because as a manager you have to meet with each report at least biweekly to talk to them about their projects, to do career planning, etc. So each week you're meeting half of your reports for 30 minutes each, which is 0.25 * D hours.

Then you're going to have a weekly meeting with your own manager. It's unlikely to be biweekly. So that's another 30 minutes.

Then you have a weekly team meeting. Another 30 minutes.

Then you have the standups on the other 4 days of the week. That would be 15 minutes each day for each project. You will likely not attend every standup, but you will try.

Then you're going to have meetings with the product managers for your projects and the managers or leads of teams you're interacting with. Let's say it averages to 2 meetings per week, so one hour.

Then there is normal management overhead: dealing with expense reports, HR issues, OKRs, all-hands slides, VP requests, etc. My assertion here is that beyond a base amount of overhead per week (which I've pegged at 3 hours) there is additional overhead that depends both on the number of direct reports and the number of projects that are distributed among your team, since each additional project adds to organizational complexity and may cause intra-team issues and dependencies.

So this gives us the final MTS formula shown above. Let's try applying it:

In the first case, we have a newly-minted EM managing a single project with 4 reports. The MTS formula yields 9 hours of managerial time, so the EM is spending around 20% of their time on management. So they can still do a good chunk of technical work in a normal week.

In the second case, we have a more senior EM running 3 projects with 16 direct reports. They are conservatively spending 65% of their time on managerial work, but it's likely more than that. And they'd be lucky to find large blocks of time for doing technical work.

This is why some people argue that EMs shouldn't be coding or doing important technical work -- they really don't have the time for it. This is not a universal attitude -- companies like Google have hybrid roles (typically called a "Tech Lead Manager" or TLM) that combine IC work (where you design and maybe even code) with management duties. But that's a story for next time.