Sometimes Jason Warner and I like to get on our podcast and vent about things that irk us in our industry, organizational structures, and engineering leadership. It’s frustrating to see some of the pattern behaviors in the tech industry and watch as they hurt future generations of engineering leaders.
The lack of pro engineering leaders, our obsession with cargo culting, and the wrong way of doing OKRs are some of the things we continuously talk about on Developing Leadership. So, I’ve decided to put some of these flaws on paper. To challenge engineering leaders to look inward at themselves, their teams, and their companies, and try to imagine a different way of doing things - without fear of experimentation.
1. The Lack of Professional Leadership in Tech
If we put engineering leaders into amateur, pro-ams, and pro categories, we have plenty of amateurs and pro-ams in our industry - but very few pros. There is a lack of professional engineering leadership throughout engineering organizations.
Why? The rate at which tech is growing leads to a massive demand for new engineering leadership positions. And since we have more amateurs than pros, we will have more amateurs training the next generation of engineering leaders.
If we assume that 80% of the current generation are pro-ams, and only 20% are pros, that means 80% are going to train the next generation. It’s unlikely that they’ll have a quality education, and this is what will hurt our industry the most.
🏈 We see this in sports. There are 32 professional teams in the NFL. That means there are 32 starting quarterbacks in the NFL. Not all 32 are NFL-caliber quarterbacks, but there will always be 32 because there just need to be.
2. The Way Engineering Leaders Learn
I’ve asked hundreds of engineering leaders, “what did you read and learn to get to where you’re at today?” And most will mention three books, and no matter how good they are, these books rarely apply to every company stage or type of leader.
The truth is that it’s easy to write content for amateurs or pro-ams, but writing for pros is highly nuanced. So there’s a point where we should be immersing ourselves in content that might not be specific to engineering leaders.
A book I highly recommend is “The Score Takes Care of Itself” by Bill Walsh, the famous 49ers football coach. It’s an excellent book. A key takeaway is that there are so many times when you need to make a decision, and it’s the art of the decision, not the science and the mechanics of the situation, that matter. That’s where the pros and the excellent leaders are made.
📕 Another book we often mention on the podcast is "Simple Sabotage" by Rober M. Galford, Bon Frisch, and Cary Greene.
💡 Leaders need to push themselves, continuously assess their performance, and build strategic foresight - this doesn’t come from reading books. Jason Warner has notebooks on his desk for companies he has never worked for - Google, Yahoo, Salesforce, and others, - where he tries to tackle issues these companies face. It’s a great exercise to challenge yourself and build strategic foresight.
3. The Lack of Experimentation with Organizational Structures
No matter how mature an organization is, someone will slip in a new project or a new library, and sometimes it gets us into trouble, but it's what moves tech companies forward. We have a huge culture of experimenting with technology.
Sadly, however, there’s a lack of experimenting with organizational models, and by the time we decide to try something different in our organization, it often comes from cargo culting.
🏗️ Cargo Culting comes from the early 20th-century when indigenous Melanesians attempted to copy cargo airplanes by making them out of wood and straw. Spoiler: The planes couldn’t fly. This applies to companies who try to emulate other company cultures or popular methodologies in their own company without adapting them to their own.
In software, we encourage an experimental mindset. We talk about short feedback loops and failing QA tests, and experiments happening all the time. But it’s the exact opposite with leadership. In leadership, you’re typically not allowed to make mistakes. You have to have all the answers.
This goes back to amateurs, pro-ams, and pros. Pros will never act like they have the answer. Pro-ams do. They say, “This is the way. This is the way because Google did it, or I read a blog post.” But a pro will say, “Our goal is to achieve this. We will try it this way because we need to optimize X, Y, and Z to achieve these goals. And if it doesn’t work, we throw it out.”
I shared some decision-making frameworks in a recent blog post which can help break away from this pattern.
4. OKRs
There are many conceptual things in OKRs that make sense, and we can call them alignment tools. Alignment tools work well in engineering, but traditional OKRs don’t. We all believe in setting goals, but OKRs and engineering don't go hand in hand. There’s also a lot time wasted around OKRs because they often lead to lengthy, pedantic discussions.
We can get pedantic over OKRs because we often don’t understand the philosophy and the soul of what this alignment tool is supposed to be doing. It should allow us to be on the same page about where we’re going, why we’re going there, who we’re doing it for and what time of horizon we’re doing it under. Instead, we argue about a K being worded like an O.
OKRs work pretty well for Sales and Marketing. But for Product, Design, and Engineering, not so much - because they take away the soul of these projects.
It’s tough to translate an OKR into software engineering, so some companies have adopted methods like Twilio’s “Draw The Owl,” where we have goals and time horizons, but we allow the middle to be messy and creative.
🦉 The meme “how to draw an owl” became one of the central values of the customer-engagement platform, Twilio. The essence of it is that you should figure things out alone. After the two circles, everyone has their way of drawing the owl. “It reminds them that they have — or are empowered to find — the answer.” - Jeff Lawson, CEO of Twilio.
5. Not Being Able to Link Engineering Work to Business Impact
Engineering is where the rubber meets the road. It’s where most of the value in a company gets created. Still, so many great engineers and engineering leaders can’t see the impact of what they’re doing. If I could wave a magic wand, everyone in engineering would be able to see the effect of their work on the business.
Drawing a line between engineering and business impact is not always easy, but it is key to creating a strong sense of purpose for the team. I recently wrote about how Nuno Antunes (VPE of Datadog) linked engineering’s impact to ARR and the positive effect on the organization.
Engineering leaders need to find a metric that their team can influence and is connected to their business goals.
6. Engineering, Product, and Design as Separate Teams
Many organizations don't have engineering, product, and design on the same team, creating tension and a lack of alignment on goals. It's an organizational structure that will not yield good outcomes, and it needs to change.
Jonathan Nolen, VP of Engineering at LaunchDarkly, recently joined us on the podcast to talk about the alignment between these teams and building what they call “The Product Delivery Organization”:
Honestly, those three functions (Engineering, Product, and Design) cannot accomplish anything independently. They can only be successful together. By putting them on the same team, in the same reporting line with the same goals, and with the same executive sponsorship, we circumvent a lot of anger and finger-pointing. It aligns everybody and points in the same direction towards the same goal.
✅ Check out the complete Scaling Your Engineering Org Checklist!
7. Not Enough CEOs With Product and Engineering Backgrounds
One of the biggest mistakes we still see in our industry is that most CEOs still do not come from an engineering or product background. Instead, they come from Sales and Marketing (understandably, because they often drive those businesses to success). However, most companies today are building tech in one way or another - so we need more CEOs with a product and engineering background.
🔎 Here’s a great example: Microsoft's CEO, Satya Nadella, is a product person. If they had put a Sales or Marketing person in charge, we wouldn't be having a conversation about Microsoft today. Satya is the reason why Microsoft is where it is.
If there’s one thing I would like you to walk away with today, there are always resources that can help you become a better engineering leader. Your ultimate goal to deliver impact to your end-users and create a great developer experience can be achieved with the right amount of alignment, no BS attitude, experimental mindset, and self-reflection.
If we missed something, let us know on Twitter!
