So, what would you say you do here?
Navigating the Engineering leadership role
If you have been lucky in your career, you get to manage people who are better than you. I have had that in spades. The downside is that many times, you face the existential question that was infamously posed in the movie Office Space - "So, what would you say you do here?".
I am still figuring out the answer to it but following are few things that I would tell my younger self.
There are many leadership frameworks. There isn't a best or a complete one. Pick one, implement, learn and refine. 4Ps & a C is one framework that can be applied to break down the leadership role in a structured way. The "4Ps & a C" are Problem, People, Product, Process and Culture. Unpacking this, you are responsible for ensuring that your teams are working on the right problems, you have the right people in place to solve these problems, the products your teams are building, solves these problems and that you have processes in place for being on top of this. As a leader culture is shaped by how you show up. As your scope increases, your actions are copied and you have a disproportionate impact on culture.
On Problem, OKRs (Objective and Key Results) is a good mechanism to mature the problem definition. That is if you stick to the spirit of OKRs to clearly define ambitious, clear objectives and tangible key results. You can read more about this approach here.
On product, the best approach is a combination of roadmaps, technical design reviews and product reviews. Roadmaps need to be live, reviews need to be done early and regularly. Ensure that your product has sufficient instrumentation and that your teams both understands key product metrics and have a regular routine of looking at them.
For people, Conduct periodic talent reviews. Minimally check if the best people are working on their strengths and if teams are effective and that you have good managers in place. Stay on top of hiring. Poorly done this can have the most negative impact on your team. You should regularly both interview and audit your hiring process. This is one place where it is OK to err on the side of micro management at least until you feel the process is biased to quality.
On process, there are few critical ones to pay attention to. (1) Institute weekly portfolio reviews. People don't like accountability and will use all excuses to fight this. However, I find this to be a better option than no accountability. The pervasive problem in managing people is not micro management. Instead it is under management. (2) For software teams, you need to have a tight incident management process as done well it increases product stability and promotes user trust. (3) Some form of org learning process. Mistakes happen. Welcome them and learn from them. Organizationally introduce a process that seeks to learn and share. Design it such that this process does not feel like a trip to the principal's office for your team.
There is truth to the adage that "teams look like their leaders". You have a disproportionate impact on the culture. If you come to meetings late, you are sending the message that it is cool to be late. If you are disrespectful, people will copy you. If you have the attention span of a goldfish, you will promote superficiality. Model the culture you desire.
One of your key jobs as a leader of larger teams is to make decisions. The only thing more important than that is to learn from these decisions. Start a routine to capture your decisions and learn from them.
Save a small % of your time for doing something hands on. You will not become an expert in that but it will make you feel real. Figure out a process for doing deep dives. Your technical design reviews and product reviews should tell you if something either smells off or is a great opportunity or is very energizing for you. Do deep dives in all these cases.
Master how your and your team's time is spent. Write down your calendar design rules and maniacally stick to that. Fight interrupts for yourself and your team. Have rules for how and when you will use email and chat. I like the idea of eventual thoughtful response as opposed to immediate response to email. For chat, I find them useless for everything except emergencies.
You will no longer be the most knowledgeable in any domain. Get comfortable with that and don't seek to be more knowledgeable than your team. If you continue to be the most knowledgeable, you have likely hired a B team. Instead seek to be the most curious. For this, get really good at asking questions.
Finally, write our what works for you and share it with others. That deepens thinking.