Management at this level gets confusing. We hire managers based partially on their technical skills, but many of us think of this job as not really “technical.” After all, the manager is probably not writing much code or doing much systems design, right?
Assuming that the job at this level becomes essentially nontechnical is a mistake. It turns out there’s more to running effective engineering teams than pure management skills, and management at this level will require you to learn some new skills that are easiest to learn if you understand the practice and discipline of software engineering. You’re going to turn your technical focus now to observing and improving the systems of work that your developers are operating within. In particular, you now need to develop an eye for the technical health signals for the overall team. But what are those health signals?
The popular management book First, Break All the Rules2 discusses several questions you can answer to help predict team productivity and satisfaction. Among them are:
For most engineers, the answer to these questions can be discerned by the speed and frequency with which they push code. If the work they need to do is clear, they know what code to write. If the tools, tickets, automation, and process are available and easy to use, they are able to get the code written. And if they’re not distracted by excessive meetings or drowning in support and incident management, they’ll get a chance to write code every day. These health signals — frequency of code releases, frequency of code check-ins, and infrequency of incidents — are the key indicators of a team that knows what to do, has the tools to do it, and has the time to do it every day.