March 16, 2021
The following blog is the second post in a three-part series. If you enjoyed this post, check out parts 1 and 3.
Why is engineering leadership so hard?
In my last post, we talked about the challenges that engineering leaders face. Every job has its share of challenges, but maybe the hardest part of being an engineering leader is that you no longer have peers who can trade-notes with, problem-solve, and empathize with. When the job gets tough, there is no one to turn to about it!
There also seems to be a not-so-subtle difference in how business and technical leaders are treated. Too often, there’s a mentality that one group works on “the business” and the other works on the “code” or the “release.” I’d be willing to bet that if you were to sit in on an average board or exec meeting, you’d likely see this play out. If the board meeting is a holiday dinner, why is it that engineering seems to be always stuck at the kid’s table?!
Maybe you haven’t experienced this difference, and if not, that’s great! But from what I’ve seen…it can be tough out there. We need to get leaders on both sides of the table to a point where this difference isn’t so keenly felt.
We can start by identifying the source of the issue: What makes us so different? And to find answers, let’s start by looking at the career paths of technology leaders vs. business leaders.
The path of a future engineering leader vs. that of “the business” leader
First, let’s consider the typical career path for most of us. We spent the first 10-15 years of our working lives trying to become the best software engineers we could be. We mastered Java, then Python (and let’s ignore that dalliance with Perl ;)). We stayed up late to nail the Google interview puzzle. We even eventually learned to recite the manifesto of the latest agile processes. We go from a developer to architect, then to leader. Life is good!
Now let’s compare this to business functions, e.g., sales, marketing, etc. They’ve been reading “The Journal,” Harvard Business Review, and The Innovator’s Dilemma since they were in college! They entrenched themselves in a world of quarterly numbers, margins, pipelines, “the three Ps.” They post their “best practices” on LinkedIn and boast about their expertise to their networks – “We’re CRUSHING it!” While the future engineering leader is giving Django a try, the future CMO is getting their MBA.
We’re worlds apart from the business
I’m exaggerating these career paths for effect, but these two paths are worlds apart from one another. There is this false assumption that the executive team is working from the same book. While most technology leaders must (sink or swim) learn about the business to contribute to the conversation, the business executives frankly don’t understand engineering. The expectation is that the business execs don’t need to understand anything about SDLC, architecture, or how software is made [it’s your job!]. So, they don’t learn it. We’re asking the business to “trust the process” that they don’t understand.
Ultimately, it’s on us to connect the work that the engineers do to the business. We need to put the engineering work into the context of the goals and outcomes of our business! But how do we do it?
The path forward
If we want to change these interactions with our peers, we need to change our approach. As I said at the outset, unfortunately, we often can’t turn to peers within our companies. So idea – we need to look elsewhere.
The good news – many have trodden the path we are on. The only problem is that it’s not clear where to find them. We just need to seek them out and discuss! We need resources that we can turn to, resources that can help us through these challenges, expand our knowledge, and make us more impactful in our leadership roles.
In my next post, I’ll cover these resources out for engineering leaders. Too many of us are dealing with these challenges, but there is a way forward if we’re willing to address this elephant in the room.
Continue the Series
