Success in engineering leadership is not easy to define. If you’ve been reading our blog, you know that often it means becoming less technical and more people-oriented as your team grows. The journey of an engineering leader is a rocky one, where you have to navigate the ups and downs of building a company and growing a team while delivering impact to your end-users.
A few months ago, Eiso Kant and Jason Warner started a podcast for Engineering Leaders called Developing Leadership. Almost 20 episodes in, and the lessons shared by our guests have been invaluable to our listeners.
Building high-performance teams, creating a company culture that scales, and why your software delivery pipeline shouldn’t stop with engineering, here are 10 lessons from the Engineering Leaders we’ve had the pleasure of speaking to.
1. Engineering, Product and Design need to work together.
Honestly, those three functions (Engineering, Product and Design) cannot accomplish anything on their own. They can only be successful together. And so, by putting them on the same team, in the same reporting line with the same goals, and the same sort of executive sponsorship. I think it can circumvent a lot of acrimony or finger-pointing. It aligns everybody and points in the same direction towards the same goal.
I've seen product organizations that are organized very differently than their engineering organizations so much so that it's very difficult to understand the two and how they can work together. They don't understand how they can deliver. Those are the worst-performing organizations that I've ever seen in my life.
2. Engineering Leadership is all about people. Technology is secondary.
It really helped me once I realized that leadership in engineering, and management roles in engineering, are all about people. Technology is secondary to management positions, and the sooner you realize that the better you embrace the real responsibility, the better you act on it. Suddenly the amount of confidence you have allows you to let go of the correct way of doing things. Because with technology it's either a zero or one, right. It's either correct or incorrect. With people, it's not the way it works, and that's okay.
3. If you want to build a high-performance team, organization, and culture, you need to start with yourself.
I start with myself because that's the first place you have to start. Right? Unless you work really hard, try really hard, and are very self-critical, you will not have good people who want to work with you. If you sit there and try to lead from the back rather than from the front, people are just not going to do it.
I always start with myself, and then next, it becomes the leadership team that reports to you. So your directors or your VPs. It's so crucial that they acquire the same spirit. People who want to play blame games, people who want to point fingers, they're just not going to be able to run a high-performance organization. It's not going to work. Because great people, people that you want to work with, you work for them as much as they work for you.
4. Your Software Delivery Pipeline shouldn’t stop with engineering.
Software engineers like to talk about CI/CD. So, take that same paradigm further. At Moov we like to say, "if it's not documented, it doesn't exist. If we haven't told people about it, it doesn't exist.” So, on some of our bigger changelogs, the marketing team is tagged inside of GitHub before they can merge into production. We're leveraging automated tools to have that communication happen throughout the organization.
I see it happen too often when a new feature gets released, nobody uses it and the team says "oh, I guess the feature sucks." But you never actually got everything done. Which is, it's on social media, it's communicated to customers, your CS team knows about it, your sales organization knows about it, and it's pushed all the way through, not just new bits on a server, but the entire process.
5. Focus on removing the biggest blockers to your success.
I was always intrinsically interested in whatever I perceived, right or wrong, to be the biggest block or the most significant thing that could unlock the next level for the company.
Of course, initially, it was writing the kernel, so that's what we focused on. Then it was, "how can we make this easy to use for developers?" And that was the API design. And then afterward, I was like, "well, we need to start hiring people. We need to raise money. We need to get the word out there."
Then, as an engineering leader, you have to answer: How can I unblock the team? How can we hire? How can we collaborate well? What does success look like for the team? How can I enable others to be successful with no kind of a stream of work for myself?"
6. People don’t want to receive corrective feedback, but if you don’t give it they will get frustrated with you.
I was doing surveys and was getting feedback from the organization on how those management situations were going, and I was hearing many comments like, "I want more feedback." I was like, "Great. Let me tell you all the things you could be doing better." But that was not what they wanted at all. They want to praise.
So they first wanted to be listened to, then they wanted to be praised and told how they were so fantastic. And then they wanted to grow. But people don't actually want to receive corrective or critical feedback, but you need to give it because if they don't end up changing and growing, they will get frustrated with you. So, one of the things we did was try to maintain a ratio of about five praises to every one piece of corrective feedback.
7. Want to be a better leader? Write more.
I had an interview once and the exec asked me, because I'd written a book, "Hey, did writing a book make you a better leader?" her question was really good because I'm like, "oh yeah." The reason I think it makes me a better leader is, ask me about 1:1s, I will bore you to death with my thoughts on 1:1s. But everything that I'm telling you is actually something that I've written down, passed it through my fingers and I've considered it.
When I choose to go and write something down, the idea goes from me kind of just thinking in the back of my head to something far more thoughtful and well-constructed.
8. You should probably be spending more time recruiting.
Unless you're spending 40 or 50% of your time on it, don't tell me it's hard to recruit, just do more of it. To me, that's the number one lesson in recruiting. You just have to put a lot of time into it. My comparative advantage as a CTO at Better in the early days was to lend credibility to the company and use that to hire good people. If you look at a startup and you go to the root cause of everything that's good and bad, it's going to be people. You have to hire good people in order to be successful. That's something I saw so clearly a Spotify. The quality of that early tech team was just phenomenal.
9. Culture is the most important thing to get right early on.
I realized at some point that the culture of the team and the company was the foundation of a company. And that was the most important thing to get right early on. But sometimes you can fetishize culture and it can become a weapon as well. Interestingly I've seen that happen, where people will say, "No, no, that's just not our way." But they won't fully understand it. Or maybe they don't want to live the values. But they want to use it as a weapon. And that's just as dangerous.
Leaders should apply to themselves before asking someone to do the same thing. They should first embrace their culture, demonstrate every day that this is an example of embracing their culture from what they do, and also spot issues or anything they can address with individuals every week.
10. Make sure your people are comfortable, delivering and that there’s a strong purpose to what they do, or they will leave.
People are more and more reflecting on their choices, what they want to do with their lives. There's a lot of people considering leaving the industry, changing jobs. There's this huge shift everywhere. We now need to be extra careful about making sure that people are not only comfortable and that they're delivering, but they also find there's a strong purpose to what they do. We’re seeing people in our industry leave for smaller companies, where they can have a bigger impact, and work on areas like climate change.
BONUS: Think of yourself as a functional leader second, and an executive first.
🚀 Jason Warner, co-host of Developing Leadership, GM at Redpoint Ventures, Former CTO of GitHub and lover of sports metaphors
If I'm giving any advice to engineering leaders, it’s a two-fold thing: you've got to think of yourself as your department and your department's efficiencies. But I will also flip it around and say: think of yourself as a functional leader second, and an executive first.
If you're thinking about yourself as an executive first, you're thinking about a business, you're thinking about the new CAC multiples, you're thinking about sales efficiencies, you're thinking about all the stuff that's going on in finance. Not that you have to actually know those things, but you're interested when the CFO is talking at the LT staff meeting or the exec staff meeting about what's happening in procurement. You're still interested. You don't tune out and just think about "we need to start talking about database tuning". Think about those things second. And the reason why is because then you'll actually pick up on a bunch of these things and care about the entirety of the business.
If you found yourself taking notes as you read through these lessons (as some of our podcast listeners do), you should subscribe to developing leadership on Apple Podcasts and Spotify!