This might be a hot take at some companies, and it might be a ‘well, duh’ take at others.
Reasons you might be shipping code as an Engineering Manager:
- It’s what made you successful as an Individual Contributor
- It’s familiar
- You can see/show the results
- The team is struggling to hit goals
- You want to lead from the front
- You don’t have enough to do on the managerial side
- You work at a company that expects this from their Engineering Managers
- If you don’t write code, your day ends and you feel you haven’t accomplished anything
If you are an Engineering Manager reading this, and you routinely write code, ask yourself if that is the best way to deliver value to your team. Chances are, it is not.
There are a number of developers on your team, and those developers are on the team (presumably) to write code. That’s what they are good at. That’s what (at least some of) their performance gauged on. There are other expectations of developers of course, but coding is primary for most.
There is just one manager. It’s you. And there are a bunch of things that you are expected to do, some of these probably include:
- holding 1:1s w/ everyone on the team
- performance reviews
- org planning
- creating a long term vision
- roadmapping
- interfacing with counterparts/stakeholders across your org
- refining your teams systems & processes
- tracking metrics around quality, burnout, happiness
- resolving interpersonal issues
- coaching & mentoring
- backlog refinement
- removing blockers
- leading meetings / sprint ceremonies
- interviewing
- performance management
Some of the items above can be handled by a skilled Tech Lead, a Product Manager, or a Scrum Master — but on teams that have all of these, even if responsibilities were divvied up between them, there would still be some remaining for the Engineering Manager.
Those remaining items are items that the Engineering Manager and only the Engineering Manager can do. Focus your efforts here, because you already have Individual Contributors to do the coding. That’s what you rely on them for. In turn, they are relying on you to do the management.
You need to break the mold of what you were doing before you entered management. It may serve you in the short term to continue coding or to step in when your team is floundering, but in the long term you are not setting yourself or your team up for success.
If your team is going to fail because they over-committed, let them, instead of stepping into hero code the feature at the last minute. If you don’t let them fail you will be robbing them of an opportunity to learn and do better next time. Turn the failure into an item for your sprint retro and discuss where your estimates went wrong.
If you don’t have enough to do on the management side, start networking with your Engineering Management peers. Have some coffee chats or some 1:1s with them and find out what they are spending their time on. Chances are there is something critical to you (or your teams) long term success that you can be doing, or doing more of.
If you aren’t having 1:1s with everyone on your team on a weekly basis, start. Depending on the size of your team, preparing for and having these meetings will take significant time but it is 100% one of the most valuable things you can spend your time on.
If you feel as though you aren’t accomplishing enough in the day, keep a task list of the meetings you attended, the blockers you removed, the mentoring and coaching you did, and the fires you put out. Give up the things that made you a successful Individual Contributor (crushing code) and re-calibrate your ‘getting stuff done’ meter for the tasks that make you a successful manager.
Remember, your team has multiple Individual Contributors to write code. It only has one manager.
