A couple of weeks ago, I hosted a talk with Point Nine, where I presented what I believe are the essential building blocks of great engineering leadership. Instead of focusing on how much you need to spend your time on hiring or in meetings, I went through the most useful mental models I've acquired during my time at Athenian. A journey that has allowed me to spend most of my days with hundreds of different engineering organizations of all shapes and sizes.
Throughout this journey, I kept asking myself: What's different between these companies? What's different between their leadership, their tooling, processes, and workflows? And I came to build up my own mental models from these conversations. The feedback to my presentation was overwhelmingly positive, so I decided to put my words on paper. Ultimately, my goal is to answer the question: What makes great engineering leadership, and what does it look like at different stages of your growth?
What you can expect from this article is a handful of mental models that, when combined, will provide a clear understanding of what is required to be a great engineering leader at different stages of your company. At the end of the article you'll find a cheat cheet for all of these!
🤔 How to use these mental models: Some of these mental models are about knowing where you fall on a spectrum. Others are about knowing where you spend your time. As we go through them, try to think about those two things. A great engineering leader knows how to balance these elements and when to apply them based on the stage of their business. Because in the early days of a tech company, you're the CTO who is still writing code, but as the company grows, you will be in the exec room, talking to non-engineers and making decisions that go beyond code.
This is the first part of a three part series I did, based on the Point Nine talk mentioned above. You can read the other two articles "The 5 Pillars of Great Engineering Leadership" and "The Engineering Leader's Process For Continuous Improvement" for a full deep dive into this topic.
Eiso Kant is hosting a webinar on April 28th, where he will walk through all these topics (+1 new mental model!). There will also be a Q&A session at the end to answer all your questions on Engineering Leadership! Sign-up for free here.
The three areas of success in software engineering
If we're talking about excellent engineering leadership, we need to answer the question, "What is success in engineering leadership at different stages of the company?". And to me, there are three fronts:
- IMPACT: At the end of the day, engineering leaders are builders. It’s easy to build an engineering organization where success is defined as our best practices or how great the developer experience is, but sometimes not on the impact on the end-user. What really matters is the ability to deliver value to your customers continuously. This is something you can never lose track of, no matter what stage you’re at.
- SCALE: Engineering is a complex system. You can see it as a graph with lots of interdependencies, but true success means that you're able to overcome that as much as possible. Success means having the ability to grow your organization and grow linearly or super linearly. Scale, by definition, is stage-dependent.
- RELIABILITY: How reliable is your service? Success related to reliability will vary massively on what stage you’re at. When you're that early-stage startup, you probably shouldn't be optimizing for, let’s say, five nines uptime. But once you have banks or the NSA as your customer, you no longer have that choice.
As a software engineering leader, you are responsible for delivering impact and developer experience. This means that you can balance delivering something to the end-user while ensuring that your developers are happy - which will dictate your organization's productivity and ability to scale.
The tricky thing is that impact is not easily measured. Sometimes it's not a straight line to your end-user. Sometimes impact is an internal team building something which is enabling others. However, it's not the responsibility to deliver tickets, it's the ability to provide impact that makes great engineering leaders.
💡 Reminder: Great engineering leaders can sit at all levels of the organization. You might feel like a lot of what we're talking about here applies to the top of the org. But at the end of the day, all great engineering leaders will have an understanding of this. Not just the CTOs or the VPs of Engineering.
Where do you fall on the spectrum?
Deeply Technical vs. People-oriented
Do you find yourself massively interested in the architecture, the major technology choices, and the database sharding issues? Or are you more passionate about the processes, the people, the product, the career ladders, and the hiring? Are you a deeply technical or people-oriented leader?
There is a classic distinction between a CTO who is more architectural and deeply technical and a VP of engineering who is more people and process-oriented. The critical thing to ask yourself is whether you find these different qualities in your organization. How do they sit between people in the org? Do you want someone very people-oriented to report to a deeply technical CTO?
🦄 Unicorn Engineering Leaders: There are unicorn engineering leaders in our industry. They are passionate about these things and can switch between deeply technical and people-oriented. What makes a unicorn engineering leader? I would say it's someone who sits in both. But what makes successful engineering leadership in an organization is when people in the right roles are aware of where they sit on this spectrum and find ways to balance themselves.
Confidence vs. Competence
If you're the CTO at an early-stage company what matters is your ability to create output, so at this stage, your competence is far more critical. But as the organization starts scaling, communication becomes a priority. The level of confidence you portray to the other stakeholders around you really matters at this stage, particularly non-engineering stakeholders.
If you’re an engineering leader at the growth stage, you need to show confidence, and it oftentimes means being an exceptional communicator. Engineering leaders often struggle with this because they had to be execution machines in those early days of the business.
🤔 Imagine this: You find yourself in a meeting where the CEO turns to you and says, "Hey, we're having a huge scalability issue. Are we going to be able to tackle this?" You're likely in "de-risking" mode as an engineering leader, so you present complex plans with many variables and outcomes. The problem is that this doesn't transmit a lot of confidence. Confidence is something that you often find in sales or marketing when someone says, "Look, these are the four things we're going to do. We've got it covered."
Although it can be stage-dependent, there is something to be said about balancing confidence and competence when going into an exec meeting. I love this method that Jason Warner brought to our podcast a few months ago:
"Lead with confidence, show a little bit of competence, and end with confidence again."
- Jason Warner on Episode 10 of Developing Leadership
People, Process, Product
Are you an engineering leader who deeply cares about her people and is entirely focused on making sure that they are happy but is not investing time in processes or the product? Or are you completely focused on the process but not spending time with your people in one-on-ones?
Where you should sit on this spectrum varies as your company grows. At an early stage, your sensitivity to the product really matters, your ability to put in place great processes, not as much. Even less critical is our ability to manage lots of people and deeply understand them and help progress their careers. Before product-market fit the only thing that matters is, "are we going to survive?" and “are we going to get something out there and can we iterate on fast enough?”
Yet, as you start scaling up, there are new skill sets that will be demanded from you. Those skills are directly related to your ability to build processes and improve them, and your ability to manage people, and guide them throughout their careers. The larger the organization gets, the more you will spend equal time between these three.
✅ Check out the complete Scaling Your Engineering Org Checklist!
Adaptable, Opinionated, Dogmatic
Are you saying to your team, "we are going to do scrum exactly like how scrum is supposed to be done."? Or are you just opinionated about using scrum, or about an architecture decision? Do you have strong opinions, but they're loosely held, or are you very adaptable?
The larger the organization becomes, the more adaptable you have to become. Your job becomes entirely around alignment because of organizational dynamics, politics, and a growing team. And that means that your adaptability needs to increase, to the point where you may have to make decisions between two bad options.
🥊 Dogmatic leaders: I personally have never seen a pro engineering leader who is dogmatic. Opinionated, yes. It's often better to be more opinionated at an earlier stage to move things faster.
Short-term, Medium Term, Long Term
If you're an engineering leader, you're probably spending most of your time thinking in the short term - because engineering is where the rubber meets the road. We are the ones that are told, “we need to get this out this quarter. Can you do it?” We get little time to plan.
The paradox is that the decisions you make as a CTO or an engineering leader in the early stage are the decisions that will cause the most pain 10 years down the line. Your database and architecture decisions will probably have to be unwound 5-10 years later and now require a hundred engineers.
So it is not enough to think about what's right in front of you at an early stage. Yes, you definitely want to be as pragmatic as possible to ship software as quickly as possible before market fit. And you'll probably want to start with go channels versus Kafka in the early days, but you have to consider the impact of these decisions long-term.
As the organization grows and you get more predictability on your revenue, hiring, and goals, you will spend more time on the medium-term decisions. And if you’re at the exec level, you're going to be spending more of your time on long-term discussions.
🪑 Think about where are you today. If you are in that growth stage and you're spending all of your efforts on the short term, it's because you're overwhelmed. So how do you get out of that? As you can probably guess, my answer is that great engineering leaders manage to find that balance on all of these.
Where are you spending your time?
Let's say you're a CTO at a Series B or Series C stage. If you're spending all of your time with the engineering team, you are not doing your job. As an engineering leader at the top of the org, you are just as responsible for spending time with your customers, peers, and non-engineering leaders. When your role as an engineering leader is to deliver impact, you are part of a bigger system. So you need to understand what's going on.
The number one advice I give to engineering leaders at the growth stages is: Go have a regular meeting with the VP of Sales, the VP of Product, and anyone else who is a peer at your level.
I stole this from Jason Warner, Former CTO of GitHub, and to be honest, I venture to say that this holds true as much at the early stage as it does at the later stage. But as the organization grows, it becomes your responsibility to understand how engineering can move the needle for everyone. And that's only possible if you're spending time with your end customer, your peers, and non-engineering
The tradeoff between Velocity, Quality and Customer Impact
I'm referencing CAP Theorem, the tradeoff between consistency, availability, and partition tolerance - for those of you who like databases. 😉 In databases, you could only ever have two out of the three. As an engineering leader, you usually only get to have two out of three as well when it comes to Velocity, Quality, and Customer Impact.
If you have part of your organization focused on quality and customer impact, odds are that you won't be able to ship new features with a crazy velocity.
If you focus on shipping really fast and high quality, you will be shipping fewer features with customer impact.
If you try to make everything perfect and focus on shipping really fast and new features to customers to have an impact, your quality will likely suffer at some point.
I think what is beautiful about engineering is that it is this ambiguous. It is not as straightforward as a sales pipeline, but it is useful to realize that you usually can't have all three. I have yet to see organizations that can ship lots of new features at a high value, very fast with high quality and have a massive impact on customers.
So, where do you sit?
As an engineering leader, I encourage you to reflect on the mental models above. Assess which ones you're finding the right balance for and which ones you're spending too much time on. If someone else on your team sits on the other side of the spectrum, as an engineering leadership team, you are balanced.
The key takeaway is that engineering leaders are builders, but that doesn't mean that we have to spend all our time under the hood. We are also builders of teams and organizations. So find those gaps, and ask the right questions, and you should be on your way to building a culture of continuous improvement. No matter what stage you’re at.
At Athenian, we’re building a platform that helps engineering leaders build this continuous improvement culture by leveraging insights and aligning teams with company goals. If this sounds like something your engineering org needs, why not schedule a quick demo?
.png)
