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 the this bucket include 1:1s, coaching, feedback, mentorship, motivation, career management, etc.
At its core, an engineering manager’s job is strengthing 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 a decision and implementign steps one through ten to acheive something, every step devolves into meeting rehashing and questioning the original decision. There is no sure way to cripple a project then 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 ineffciency.
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 and publishing them effectively them 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 growht) 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 big deal. A good engineer manager understands this and makes sure their people under stand 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.
At the end of the day the topics above are the most common sensible themes that came across. There were other excellent one-off answers that don’t quite fit nicely into the above, but hopefully your CTO has a good sense of the above.