DEV Community


Posted on

7 Fatal Flaws in The Software Engineering Industry

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.

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.

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.

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.

  1. 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.


Discussion (1)

andrewbaisden profile image
Andrew Baisden

These are good points. On DEV we are encouraged to share the whole article on the platform instead of forcing people to go to another page 😉