What is Engineering Leadership, Anyways?

Great software engineering organizations adopt best practices such as CI/CD, infrastructure-as-code, and automated testing. These are truisms our industry has adopted over the years and if you move from one organization to another, you will see that the quality of a software team’s code tends to be reflective of the adoption of these practices (or not). Why, then, are the leadership roles most responsible for establishing, implementing, and maintaining these practices so less strongly defined? An Engineering Manager at one company is a Team Lead at another. Or maybe it’s called a Tech Lead, Dev Manager, or just Manager. And what the hell does a Director or VP of Engineering even do, anyways? If engineers are responsible for writing code to drive towards positive outcomes for the business, and an engineering leader isn’t writing code, what is their impact? Why do we need middle-managers in the first place? Why do we promote the most prolific software engineers into roles where they no longer do real work? In 2023 and 2024 we saw this prioritization of “doers” over managers in Meta’s Year of Efficiency which focused on flattening the company by removing middle managers. Amazon quickly followed. If companies such as Meta and Amazon, renowned for their innovation and technical supremacy, were reducing waste by reducing managers and increasing a manager’s number of direct reports to as high as 20, surely this must be the way.

Doing Real Work

I read a book recently about why startups are so much better positioned than large, traditional organizations to change (or create) new markets and products. In that book, the author posited that in successful startups, frontline managers occasionally do “real work” like writing code or chipping in on software development, as opposed to in traditional companies where managers just manage people and tasks. I think this is a very misguided, and often times destructive, line of thinking. Engineering Managers should not be software engineers who also do people management. I’ve seen too many companies, and interviewed too many candidates, where an engineering manager’s role is 50% hands-on-keyboard writing code and 50% people management (read: performance reviews). This diminishes the value of both roles. Software engineers should not be valued for their ability to write code. Instead, they should be valued for their ability to solve problems. Yes, writing code is part of how problems are solved, but so is talking to customers, understanding the intended value or impact of a given feature, and being able to run and maintain that software in Production after it’s been deployed. Similarly, an Engineering leader should not be valued for their ability to manage people. Yes, managing people is part of leadership, but so is consistently delivering new capabilities in line with estimates, developing (or hiring) new skills on a team to unlock new ways for technology to solve business problems, and ensuring the individuals that report to you have an opportunity for growth and development. Neither software engineering nor engineering leadership is a part time job, so it doesn’t make sense to ask a person to do both. This isn’t to say that engineering leaders shouldn’t be technical. A good engineering leader understands and can empathize with the challenges their teams face, and empathy is built through experience. Review a pull request or technical design document. Try to deploy code to Production, or pair with someone on your team as they do it. But your real work as an engineering leader is not realized through the occasional code that you write. To the contrary, you should be impactful far more often than that! The thing I find most difficult for companies, and sometimes new leaders, to come to terms with is how the timescale of impact differs for engineers relative to engineering leaders. While an engineer’s output is seen in Production in hours or days (you are deploying to Production this often, right?), an engineering manager, director, or VP may not see the outcome of their work for weeks, months, or even years. The decisions tend to be less easily reversible, as well. It’s much easier to back out a code change than it is to back out a re-org. Coaching and mentorship takes time. Establishing new processes or fixing broken ones takes time. Changing code is hard; changing people is even harder. Most often in startups, we over-value immediacy and under-value the future. This isn’t to say no one is thinking ahead, but that startups tend to live on the knife’s edge of existence such that being able to see outcomes now makes it easier for startups to justify the value. I won’t go into organizational design and team structure in this article, but suffice it to say if you’re expecting your engineering leaders to also be software engineers, you are prioritizing short-term benefit over long-term viability.

An Engineering Leader’s Focus

Any engineering leader’s primary focus should be delivery. And I don’t mean “we shipped it”. That’s the easy part. Instead, great engineering leaders focus on the quality of delivery. Was it on time? Did it launch without much fanfare (boring launches are just as strategic a decision as boring technology). Are you able to measure the impact your team has on broader business goals? These are the questions to ask when measuring how well your teams are delivering and if you’re helping to drive continuous improvement in this area. How do you impact delivery excellence? I believe engineering leaders have the greatest influence over three things: team, people, and process. While org design is another post for another time, team design is a place engineering leaders at any level can apply their vantage point to great effect. If the company is making moves in AI and you have no skills in machine learning or artificial intelligence on your team, you need to decide whether you build it or hire it. Time and money are two limiting factors here, but you need at least one of them to be able to effectively fill the skills gap. Even if you have the expertise, understanding the product roadmap and ensuring the team is prepared to adopt and maintain any new technologies that might be required to meet Product’s needs is another way leaders can leverage their team’s collective expertise to help drive value. Teams, though, are nothing more than a construct for the people that comprise them. As an Engineering Leader, it is your responsibility to make sure that the individuals on your team are motivated, challenged, and rewarded for their work. It’s your responsibility to tell them when they’ve done well just as much as it’s your responsibility to coach them in the areas they need to grow. Establishing a career framework (and establishing it early) is a great tool to use in helping to develop the people in your team. Lastly, how the team executes and how the individuals on your team feel about how work gets done is achieved through process. For a variety of reasons, “process” is a dirty word in software engineering but I believe it is one of those most effective ways to drive impact as an engineering leader. Doing the work is hard (and it should be, if it’s worth doing). The work required to do the work shouldn’t also be hard. What is this meta-work I speak of? How decisions are made, how work is estimated, how tasks are broken up, how code moves through the deployment pipeline or release train, and how Engineering engages with other organizations across the company all describe how work gets done. This is where getting closer to the work (but being careful not to devolve into taking on hands-on-keyboard responsibilities) is the most beneficial. As an engineering leader, it is your responsibility to make sure your teams have the tools they need to do their best work. Could you build a house with only a hammer? Sure. But it wouldn’t be very fun to do. And it would take a lot longer than it would if you had the right tools, the right blueprints, and the right processes to build it better. If there is friction in your team’s daily work, it is your responsibility to remove it. In doing so, you empower your teams to drive the kind of impact that makes high-functioning software engineering organizations a rewarding place for the people on your teams to build and grow their careers.

All of this is real work. It’s just different work. For this reason, I think one of the most detrimental things an Engineering organization can do is build career paths that make management something you get promoted into, as opposed to a different role you transition into. How engineering leaders drive impact is different than that of individual contributors. It’s not less, or more, but different. If you’re an engineering leader trying to figure out how you can have the most impact on your team(s), think about working on the system and not in the system. In so doing, you will help your team achieve outcomes they couldn’t have reached with just a manager focused on performance reviews, or a manager who moonlights as a software engineer. It’s this unique combination of perspective and focus that makes engineering leaders at all levels a critical part of the organization.