I’ve recently been on an interview panel for a company in the process of looking for their next engineering leader (think CTO or Senior Vice President of Engineering).
Over the course of the many discussions a few common themes kept coming up.
This is very broad, but encapsulates the notion that a majority of the work of an engineering manager’s time is spent on making people do good work and produce good output. Activities in this bucket include 1:1s, coaching, feedback, mentorship, motivation, career management, etc.
At its core, an engineering manager’s job is strengthening and motivating the people who work for them and the people who work with the people who work for them.
Assuming you have a strong and growing workforce, the goal is to make sure they know the goals. A team going in different directions isn’t a team. A group working on a hundred items ends up with a hundred partially done and poorly done products.
Getting two people to work together is no big deal. Ten people takes some work. A hundred gets pretty tough. Aligning a thousand people is nearly impossible. And yet, there is no force on earth more powerful than a thousand people working together to achieve a common goal.
Clarity of vision is about making sure your people know what the end goal is. You want people to understand the big destination at the end. Clarity of Priorities is about making the people who work for you understand what the next steps are and why they are important.
The reason this is important is that without it, everything becomes a micro debate. Rather than making a decision and implementing steps one through ten to achieve something, every step devolves into meeting rehashing and questioning the original decision. There is no surer way to cripple a project than infusing numerous repeated micro-debates into the process.
The underside of this is that micromanagement is bad. A manager should not dictate how to achieve a priority or what language or tool a team should use. You want to leave the implementation details up to those who are closest to the problems.
If your priorities change, congratulations. You are in a normal functioning organization. Just make sure people know that it’s changed and why. If your vision changes, be prepared with a strong story to tell why. Priorities are likely to change often and vision less so, but change, especially in the face of new information can be good. Not providing clarity when change occurs is what leads to confusion and inefficiency.
Metrics are a big deal. This was a fairly common phrase. More interestingly every eng manager seemed surprised that putting business metrics in front of engineers is really important. Choosing the right metrics, publishing them effectively, and having the team internalize their importance are all hard things to do that usually takes iteration, experience and practice.
In the end, it should be trivial to:
Usually this means wiring up business logic (such as user or revenue growth) or engineering stats (such as number of releases) into business intelligence platforms of some kind. Publishing means you need automated output of reports or dashboards and consumption usually means output via email (not great) slack (ok) or wall mounted TVs (my favorite!).
Obviously, be cautious of what you measure. Vanity stats must be ruthlessly culled.
Recruiting is a big, large, huge deal. A good engineer manager understands this and makes sure their people understand this. Furthermore a good engineering manager takes responsibility for hiring, and training people who hire, whether or not they report to them (recruiters, schedulers, interviewers, hiring managers, receptionists, etc.)
This is something I’ve personally spent the past three years thinking about and writing words and software to support. I’ll have much more to say about this area shortly.
These were the themes that kept surfacing. There were other excellent one-off answers, but if your CTO or engineering manager candidate has a solid handle on these four, they’re in decent shape.