Being a great engineering leader means killing your ideas

The following is a guest post from Elad Ash, Chief R&D and GM at Placer.ai.

Throughout the course of my career, I’ve been fortunate to get to sit in virtually every role in the software development organization:

• Programmer 
• Algorithm developer
• Team leader
• Group leader
• Organization leader

The one constant in my career has been working for companies that are in the “growing up” stage. When companies go virtually overnight from five devs working in a garage together to securing millions of dollars in venture funding – things change quickly. 

Individual engineering teams begin forming, each with their own subculture, practices, and standards. New tools are introduced. Leaders are faced with daunting challenges – like knowledge transfer and alignment – and you start hearing questions like: “You have 6x more people, why can’t you do 6x more things?”

I love tackling these challenges. And I’ve discovered the hard way that most of the conventional wisdom about being a leader of a high-growth engineering team is...just wrong. Here are three areas where I’ve had to throw the playbook out the window and chart my own course. ‍

Leave it better than when you entered (LIBTWYE)

Conventional wisdom: Move fast and break things
What I’ve discovered: LIBTWYE

LIBTWYE: Leave it better than when you entered.

When an organization is still in its early days, your primary goal is to prove product-market fit. So it makes sense to do things “quick and dirty.” (After all: why worry about test coverage when you’re not even confident the thing you’re building solves a meaningful customer problem?)

In the next round, you’re expected to start selling and servicing it – in production. This requires a change in mindset, to owning not just velocity but quality. 

And as a leader, it requires the ability to measure people in a different way. You start paying attention not just to time-to-market, but also to non-functional requirements. How much technical debt have you sold as part of your task? Have you just done what was asked for? Or have you considered the larger scope?

In my experience, there are two ways to develop: you can create technical capital or technical debt. The compounding effects of either are tremendous, and are often overlooked. 

Enter the concept of LIBTWYE: the things that pave the road to smooth, rapid future development. (Things like documentation, measurement, and test coverage.)

There’s no doubt that a LIBTWYE mindset takes longer. But the compounding benefits are tremendous, which is why as a rule I’m willing to “pay” up to 100% of development time for LIBTWYE. 

And it’s not just the obvious things that weigh on every engineering leader’s mind (like moving from SQL to Redis, or introducing caching). Taking small steps to close these gaps – things as simple as splitting functions that are too big, or introducing code review – will make major initiatives in the future easier. ‍

First people

Conventional wisdom: Learn the product and customers first
What I’ve discovered: First people. Then technology. Then product and customers.

Here’s one that I really think is backwards: the idea that technical leaders can accelerate onboarding by deep diving into the product on day one. Sure, it’s helpful to understand the product. And it’s even better when that’s accompanied with some real-world market context from customers or prospects. 

But it’s totally inverted. It deprioritizes the human beings that are responsible for building the product – along with their most important context and constraints. In my experience, treating those considerations as an afterthought tends to lead to a fundamental misunderstanding of how the team operates and how to optimize it. Here’s the roadmap that I follow whenever I begin leading a new team.
‍

1. Orient

• Get to know the people. You’re managing people. Start by getting to know them: what excites them, what frustrates them, their expectations for themselves and their roles. The first two weeks should be spent almost exclusively getting to know people.
• Get to know the technology. Understand at a deep level the technology, environment, and tools that you’re going to be working with.
• Only then – get to know the product. Once you have a good grasp of the people and the technology...specific decisions and tradeoffs will make more sense. You’ll just *get* the product

2. Experiment 

Focus on low-hanging fruit – things that have the potential for substantial impact, but aren’t too difficult to achieve. I’m a big proponent of a “knights of the round table” model for rolling out experiments. (There’s no head of the table; everyone comes in at the same level, and we discuss as equals.) We try to find a champion who’s willing to sponsor an experiment with a given process. Usually, if an experiment is well-structured, it’s pretty easy to tell whether it worked or not when evaluating the results. (For example: we ran an experiment at Placer.ai around our “definition of done” process that was big and demanding and had lots of steps, and ultimately produced very little value. So we scrapped it.)

3. Plan

‍Once you’ve acclimated to the landscape and run an experiment or two, prepare a plan. A real roadmap – not just one quarter ahead. Get buy-in by supporting your plan with data. This is critical because engineers are very good about being cynical about new ideas, but are often not consistent in their cynicism. (For example, I encountered a tremendous amount of well-meaning – but often reactive and flighty –pushback at previous places when I moved the organization to CI/CD.)

4. Execute

‍In my roles as VP R&D and Chief R&D, I’ve implemented a daily meeting cadence with senior R&D managers. It’s short, just 15 minutes, and looks a bit like a standup but larger. This cadence is a crucial forum for me to absorb context and concerns from my leadership team – and to answer one of the most critical questions that any leader should ask himself continuously: what are my blind spots? It requires some emotional intelligence:  for example, you realize that you’ve touched a sore spot when you say something and see two leaders exchange a glance at each other – or someone speaks for a long time about something that you thought was a minor issue. Once you get the hang of it, these meetings become the key to understanding what’s really going on.‍

A great leader kills his or her ideas

Conventional wisdom: A great leader is the most passionate advocate for his or her ideas
What I’ve discovered: A great leader kills his or her ideas

There’s a pervasive narrative that leaders should be confident and charismatic advocates for their own initiatives. 

I’m deeply skeptical of this model. In my experience, this leads to an “echo chamber” where an engineering leader becomes single-mindedly focused on just her own ideas – with no external perspective on feasibility or relevance.

This is why I regularly conduct a thought experiment to try to gain perspective and try to fall out of love with my own ideas: If I joined today, what would I do?

It’s also why I tend to be fanatical about KPIs. They keep me honest, anchor me to reality, and prevent me from over-indexing on pet projects. Some of the specific VP R&D metrics that I rely on regularly for orientation:

• Technical debt: Measured by manual work. (When it increases above a certain level, I “buy” a sprint from the organization to pay it down.)
• Number and severity of RCAs: For every incident in production, we create an RCA (root cause analysis) internally.
• Time to handle tickets by severity: Showstoppers need to be handled in less than 30 mins, critical issues in less than a day.
• % of R&D dedicated to on-call: A good proxy for the stability and maintenance of the system.
• Velocity: Average number of tickets and story points per person. 
• Stability of production: We run tests not just on staging but on production, so that we can measure how much time the master is in green. ‍

The bottom line

Ultimately, the leaders that are able to make the leap from individual contributor to team leader – and from team leader to group manager – are the ones that learn how to unlock the organization’s most valuable assets: people and technical capital. 

Doing so requires patience, humility, and the willingness to question received wisdom. It’s not a job for everyone. But for those of us who love the stress of leading an engineering team in a high-growth organization – it’s worth the payoff of seeing the team achieve its full potential.