“Engineering Manager” as an Anti-Pattern
Too many responsibilities, demands from every side, not enough technical time, ultimately doomed to mediocre performance. Sounds like a God Object to me.
The (un?)natural evolution
You’ve got your successful software business and your core cadre of hard-hitting devs. Thing is, you want to do a lot more, so your company is hiring like nuts. Pretty soon you’ve got a direct reporting problem.
The boss can’t keep up with all the Zeldas invading the dungeons — better hire some sub-bosses, right?
Maybe we can at least slow the Zeldas down.
But consider: what do you want this person to do, exactly ?
Life as a sub-boss
Broadly speaking, a software engineering manager has three responsibilities:
1. Keep developer tasks aligned with leadership priorities
2. Manage developer relationships and morale
3. Advise on technical implementation
Now in the real world, numbers 1 and 2 generally result in the doomsday time-suck God Shiva the Destroyer of All Human Happiness:
Leaving no time for #3. So with each passing day, your managers are more and more out of touch on the technical details.
Now consider: you are asking someone to manage a team of engineers, while steadily undermining that person’s engineering capabilities.
A professional engineer, who no longer does any engineering, is going to lose the respect of those in the trenches. They may be be a people person; engineers may want to like them. But engineering is a technical discipline, and respect is earned with strong technical execution.
Over time, this loss of confidence in a manager’s technical prowess, will also affect that manager’s ability to influence the human side. Now you’re undermining tasks 1 and 2 as well.
A clear setup for failure.
How it’s done when lives are on the line
An interesting point of comparison comes from the world of naval aviation.
The leader of all the pilots on an aircraft carrier is known as “CAG”, or Commander, Air Group. Not only is this person a manager, but they are also an active pilot themselves, launching off the deck with “cat shots” and “trapping” on the arresting gear wires.
The CAG’s schedule is carefully managed such that management responsibilities are compartmentalized, and delegated to support personnel, so there is adequate time to maintain their technical proficiency. Respect is maintained because a CAG leads by example.
How then to do this in software?
You can’t make time … but you can buy it
A Navy air group commander is surrounded by support personnel, such that any task which does not require the commander’s individual expertise is delegated. But what can we delegate from the task list of a software engineering manager?
Uh, how about … nearly everything?
What you need is people who can pass messages and manage schedules. Is a project proceeding on track? Are there new priorities from management that are straightforward and require simply rearranging the task stack ? Delegate all of those things.
Now if there’s a scheduling problem that requires more than just rearranging tasks, fine — go to the experts for expertise.
But consider: we promote the most talented engineers on a team, who also have some people skills — so often a rare talent set in the software world. We then proceed to have them handle menial messaging and scheduling tasks.
You can hire other people do this ! And those people are less expensive!
Re-focus your engineering leadership on fixing engineering problems
Hire technical project managers. I like to call them “Schedule Managers” . More posts to come on this role.
Let your newly-hired team of project managers handle the messaging, scheduling, and de-conflicting. Every hour spent by your TPMs is a new hour available for engineering. And it’s a fresh hour with less on the to-do list of menial tasks. Ask any developer — those open-headspace hours are programming gold.
Next, hire a talented, respected engineering consultant. Find someone with broad experience across a range of software projects and tech stacks. Have this consultant work with your managers and senior devs to audit your code base and development process. What can be improved ? What long-standing tech debt can be resolved ? What new ideas can the consultant’s experience bring to your technical roadblocks ?
Remember — software engineering is about innovative ideas. Even just one great idea can be a transformation.
Pull menial support tasks away from your technical managers. Let their headspace open up again; let your top engineers get back to doing what engineers do well. Watch your team morale improve, innovation soar, and roadblocks disappear. In a world of disappointing, mediocre software, your newly-inspired teams will crush the competition.
Happy delegating !