So what exactly does one do as an Engineering Leader?

Office Space

I think designated Engineering Leadership roles are like traffic lights; their necessity is beyond a threshold. The problems they solve are either less pronounced in smaller Engineering organizations, or can be absorbed by other roles. Assuming growth is a fundamental aspiration for anything entrepreneurial, it is worthwhile noticing what the good ones do well in larger organizations and here’s my take on it:

As organizations grow, there are three variables that introduce a greater need to be managed:

It is here that the Engineering Leader adds value. She’s solving for better outcomes1 by managing People, Process, and Culture, and bringing overarching perspectives into view. Of course, teams are able to manage these on their own. But it’s usually worthwhile and quicker than the organic way, to make this somebody’s full-time job.

By the way, I say Engineering Leader here, but the level doesn’t matter. You could be called anything depending on organizational hierarchy and pomp - but you’re managing a team (flat or pyramid) that is engineering software. Also, I won’t cover responsibilities that are close to the code. Depending on span and the presence or absence of other roles, Engineering Leaders will need to weigh in on or contribute to the codebase. That is table-stakes.

Instead, I will focus on more abstract areas:


Lookout

Good Engineering Leaders have a longer term view and a wide perspective, and they bring this into what the team is doing.

Being right about what’s coming in the future is incredibly hard. But this is where the money is. There is always an element of chance, but the ones who do this well are able to have

long-term thinking with a broad view of how different systems in the organization and outside are going to come together2

There is art to it, but I can tell you what seems to help: information and deliberation. As organizations grow, it becomes difficult to keep information organized and available. Good Engineering Leaders are thirsty for information from all available avenues and become the provider of this vision which will help the team gain advantages.

Balance

With the wider perspective they have, good Engineering Leaders bring the realization that things are rarely black and white, and help land on the right gray for the day.

There are a wide variety of balances that teams have to strike - build vs buy, speed vs flexibility, levels of abstraction and modularization, new vs known, talent levels, features vs refactoring, innovation vs expansion, volume vs quality, delivery vs strain, calculated risk… we could go on. Again, as organizations grow, keeping overall balances aligned becomes challenging.

Good Engineering Leaders help teams land on good compromises and the right prioritization. They get the culture and information in place so that there is introspection about what the need of the hour is, and awareness of what the remainder is, in a certain choice. And if they’re looked to for a decision, they are quick, get the balance right, and will stand behind it.

Sales

A good Engineering Leader knows it needs to be sold.

They’ve got deep Engineering knowledge to understand Engineering complexity and sell the idea of time or investment or trade-off to stakeholders at a level that’s easily understood. Similarly, they’ve got deep knowledge about why something is needing to be built, and are able to sell the idea in a way that brings on board not a mercenary engineer, but a passionate and involved one with eyes on the desired outcome.

It’s not selling snake oil. They’re the conduit and translator that has empathy for and intricate knowledge about the needs of two different groups, and build bridges.

It doesn’t even stop there. Even with topics coming out of Balance or being the Lookout, a good Leader is focused on engaging people and not dictating a course of action. If there ever is a preference in there that is not a straight forward data based decision, they’re bringing other people onboard.

Culture

They’re observing and curating culture. Culture is a great many things and of course one can’t define it in an oligarchic way. But they focus on a few things:

Defining the first two well, communicating this well, handling the process around this transparently, and constantly thinking about what needs adjustment or reconsideration as circumstances change, is a winning trait. Members of teams will mostly gravitate towards what’s rewarded, and collectively help keep tabs on the latter. Good Leaders are able to keep what’s rewarded objective, and tie it back to what’s important for the wider company. As a part of what they try to sell more widely, they’re seeking investment into metrics that help keep things objective.

The other big area in Culture is building Trust. Good Engineering Leaders watch out for practices that break trust because once it’s is broken there is a mushrooming of defensive strategies on all sides that kill productivity and joy. They do everything they can to help everyone see and appreciate its precarious balance and great value. And if something trust-breaking happens, they are a counterweight that brings things back on course.

Hiring

On top of well understood roles in Hiring, good Engineering Leaders hire for diversity in thought. The objective is to bring as many perspectives as possible into what the team solutions. There’re two things they watch out for here:

Under this same topic, I should mention Org design. A lot of what happens is a function of how the org is set up. And as companies grow, it becomes more and more challenging to align efforts. Good Engineering Leaders create the right tail winds through their org design.

Succession

Software will change hands. Maybe through attrition, or re-orgs, or a hand-off to another team. Good Engineering Leaders are able to account for this and imbibe this into the development team’s fabric. They develop a culture where making it easy for a new pair of eyes to find their way about the system and checking whether it behaves as expected, is table-stakes. They bring that to Balance discussions. Unless this is taken care of, systems will attract inertia in new hands and stop evolving. Teams that do this well are able to move on to more interesting things easily.

Network

They network widely and understand people deeply. They take the time to have conversations. They bring people together. An idea with a talent. A rookie with a veteran. A need with a surplus. And then they help create the space in which those brought together can be productive.


To wrap up, this probably goes without saying, but a lot of what’s described above can’t be done without being knowledgeable about Software Engineering itself. You can’t hire for diversity of thought unless you know what the points of contention are. You can’t simplify complexity for folks if you don’t understand yourself. You can’t advocate for a certain balance unless you know what’s weighing in. You can’t see what’s possible if you don’t understand what’s coming up. You can’t judge the odds of innovation and disaster. You can’t ballpark without consulting. You can’t foresee.

So the good ones take the time to be knowledgeable about as many topics as they can - the problem domain, processes, experiments, advances in technology, advances in computing, the basics, the details, the larger constructs, Policy, and rising and bygone trends. They’re knowledgeable, but they trust the team and step away a little bit to focus on creating the best possible circumstances for an engineering problem to be solved well.

  1. More on this in another post. What is a “good” outcome? 

  2. Sam Altman on Success 

  3. By extension, what is measured also.