Don’t be an engineering leader….

…be a business leader instead. Let me explain.

The age of the specialized player/coach engineering leader is coming to an end. Software Engineering is not as specialized (translation, hard to acquire) a skill as it was two decades ago. The barriers to entry have reduced basically to nothing. You don’t need a four-year college degree to figure out how to create a web application. You don’t need any hard-to-achieve certification to create mobile applications. Heck, you can embed artificial intelligence into your application by just incorporating an API (openAI, Hugging Face etc.).

Before everyone raises their pitchforks, let me caveat the rest of this post by saying that there will always be exceptions, but as I look around the tech industry, what I said above and what I am about to say below is largely true.

The open-source software movement started this by making software engineering accessible to everyone. You don’t need a comp-sci degree to get access to, understand and extend Android’s source code. As regular people started learning more, they started sharing their knowledge with everyone else using bbs, irc, mailing lists etc. YouTube, Wikipedia, etc, amplified that by bringing that knowledge and learning to the masses. I am one of the billions of people who have used these online video resources to self-learn all the latest and greatest innovations in software engineering, AI, and everything in between.

In parallel, AWS, Azure, and GCP were (and are) making it extremely easy to deploy any code to a highly scalable and reliable infrastructure without needing any specialized knowledge or experience with systems, networking, build systems, etc. I remember buying an expensive server back in the day (gosh, I sound old!) to host my personal software projects. I can do all that and more at a fraction of the cost with a few clicks in my AWS management console. 

The side-effect of all of this is that the current generation of engineers are working on an abstraction layer that is at a level higher than the previous generation and, more importantly, is simpler to understand than ever.

I remember needing to understand the moods and feelings of the server I was deploying to before pushing code to it. No more of that! I remember logging into F5 boxes to write rules in TCL. Now, all it takes is a few clicks, and you have a highly scalable load balancer that can handle billions of requests per second.

The bottom line is that all of us are now standing on the shoulders of very friendly and helpful giants.

So, what does this all mean for engineering leaders? As I said at the beginning of this post, the era of the player/coach is coming to an end. Engineering leaders are focusing more and more on higher-level problems related to people, organization design, scale, and execution-related processes than focusing on helping individuals solve specific code, system design, and network topology nuances because the abstraction layer they are working on is so much simpler than before. So basically, more of a coach than a player. If leaders are focusing on becoming more coaches than players, it also means that it will become harder to stand out in the crowd. Add an economic downturn to the mix, and you now have a gloomy future filled with intense competition and depressed wages. So…How do you stand out and command glory day tech salaries?

Amazon popularized the idea of a single-threaded leader a few years ago. The single-threaded owner owns most (and sometimes all) aspects of product development. Typically, a single-threaded leader owns product, engineering, design, and sometimes product marketing. In some cases, I have seen these single-threaded leaders own the entire P&L, which means, along with owning the functions I mentioned above, they also own the revenue teams like sales, growth marketing, professional services, etc. I have been a single-threaded owner in a couple of my past gigs where I managed product, engineering, and design, and I can say with a high level of certainty that it was one of the most efficient organizations I managed. To be clear, being a single-threaded leader doesn’t mean you are an expert in all the functions you manage, but you know enough to run those functions efficiently. If you are an engineering leader, I highly recommend you consider pursuing a single-threaded leadership role in the future, which I believe will help you stand out in the crowd today and in the future.

But let’s not get ahead of ourselves. Baby steps. If you are an engineering leader and aspire to become a single-threaded leader, the first step is to get closer to your partner in crime, the product leader. In this post, I will dig into concrete steps you can take today to understand the product function a bit deeper and put you on the road to becoming a well-rounded product development leader. Simply put, to understand the product function, you have to get comfortable doing some of the work your product manager does. Let’s start at the beginning. 

Discovery

Engineering leaders have been told for many years to focus on the ‘how’ and leave the ‘why’ to product managers. To become a well-rounded leader, you have to understand the ‘why’ in a way your product manager does. The most important part of a product manager’s job is to figure out what to build. This seems easy, but in practice is very hard to nail down. It is not just talking to customers and asking them what they want. It is understanding the entire customer journey, which includes their life and work goals, their current pain points, known and unknown obstacles in the way of adopting your product, emotional hurdles, etc, and then synthesizing that into a clear, achievable roadmap that will result in positive results for the customer and the company. Clayton Christensen describes it well in his book Competing Against Luck (which I highly recommend). In order to capture the struggles of the customer, you have to capture the story of your customer, which should read something like this-

Once upon a time . . . 

Every day . . . 

One day . . . 

Because of that, we did this . . . 

Because of this, we did that . . . 

Finally, I did . . .

I highly recommend engineering leaders tag along with their product counterparts in as many customer discovery sessions as possible. And don’t be a passive listener; participate in it. Offer to be the scribe, lead some of the discovery sessions, share your hypothesis, thoughts, observations, etc. The closer you get to your customers, the deeper your understanding of the solution will be and you can clearly explain the ‘why’ to your team. 

Another common discovery technique is customer surveys. I highly recommend engineering managers understand how surveys work and the best way to structure them. Personally, I am not a huge fan of relying on surveys as a means to uncover the customer journey. However, they are great for collecting post-launch feedback, including determining conversion drivers. Another place where surveys really shine is when you want to figure out your customer’s willingness to pay (or affinity) for a specific feature. You can learn more here, here and here about different types of surveys.

Success Metrics

The best product managers obsess over figuring out, tracking, and reporting on success metrics. Figuring out the empirical measures of success is very hard, especially if you are working in a large company where it is hard to attribute product usage to lagging company metrics like revenue, growth, etc. 

I am a huge fan of input metrics and output metrics. I first encountered them at Amazon and, since then, have either directly used them in my teams or pushed my product counterparts to use them. Simply put, input metrics are controllable metrics that a team can directly influence by ‘doing’ things, like shipping software, adding more products to the catalog, cleaning up the user interface, etc. Output metrics are lagging metrics of the company, like revenue, churn, customer growth, etc. The team has to figure out which of their input metrics eventually affects the lagging metrics, and once they figure that out, they can double down on it. For example, you might figure out that usage on a specific page directly correlates to higher retention, and then you can figure out projects to do that will increase activity on that page. Keep in mind that teams typically don’t land on the right input metrics on their first try. It takes multiple tries and discipline to eventually figure out the right metric. 

In most companies, the product manager is tasked with figuring out success metrics. This is another place where a future single-tasked leader should dive in and help the product manager figure out the right input metrics to track and influence. Figuring out the right metrics is probably worth a post in itself, but the simple answer is that the only way you can figure out the right metric is to not fall into the causation correlation trap but instead use experimentation to get to the truth.

Execution

OK, so you and your product manager have wrapped up discovery and are now in the execution phase. This is where an engineering manager can dramatically offset the work of a product manager. Traditionally, the product manager must write clear epics and stories that can be pulled into a sprint. If you ever aspire to become a single-threaded leader, you have to be willing to write some of the requirements yourself. 

I have heard countless complaints from engineering managers who reported to me that the ‘requirements’ were unclear. My standard answer to them is, ‘It is as much your job as the product manager’s job to ensure requirements are clearly understood. If you have enough knowledge and know how to pinpoint the gaps, you can probably plug the holes yourself and help your product manager out.’ 

Fleshing out requirements and writing shovel-ready stories is not rocket science. Even if you have never done it before, I am sure your product manager can get you started on how to write stories with clear acceptance criteria and where to look for missing bits of information. Pro-tip: the missing information is probably in the heads of one of these people: the customer, the product manager, the product designer, or your leadership team. 

Product Managers are rare species. There is usually one PM for every ten engineers, so anything you can do to help your counterpart not only gives you more insight into the product role but also helps reduce the paperwork burden on the lonely product manager who is probably overworked and also helps you ensure your engineers have enough clarity around the features they need to deliver. 

Another thing you can help out with is status reports. Product Managers spend an insane (and often invisible) amount of time writing status reports. Weekly business reviews, monthly business reviews, etc, are predominantly driven by product managers because they are usually seen as the ones with the most information about the status of a project, the customers using the features and the competitive landscape. At any given point, you, the engineering leader, should be as knowledgeable about the state of things as your product manager. In the teams I have built, the engineering and product managers alternate in writing status updates and representing their teams in common meetings. 

Launch

Product managers sink in a ton of time getting a feature ready for launch. There are knowledge base articles to be written, marketing collateral to be refined, launch emails to be pored over, social media posts to be sharpened, creative assets to be cleaned up, beta customers to be selected, and numerous other odds and ends that need to be tightened. Offer to write some of the launch collateral yourself. I personally derive a lot of pleasure from writing launch emails and marketing collateral because as I am writing it, in my head, I imagine myself physically moving the project over the finish line, and that gives me a lot of personal satisfaction. Yes, I know, it is a bit weird, but so is life in general.

Understanding the ins and outs of how to put together a perfect feature launch is crucial if you aspire to become a single-threaded leader at some point in the future. The good news is that most of this is usually not done by the product manager alone. They partner heavily with the marketing and/or the content team to assemble these things. So you will have other, more knowledgeable people to bounce things off of. If you are completely new to copywriting, you can start here, here, and here. Like everything else in life and work, the more you practice, the better you become. 

Customer Support

I also encourage engineering managers to volunteer themselves for customer support-related activities. Post-launch, there is usually a period of time when the product manager will be inundated with feedback, questions, complaints, etc. This is a place where you can help out as well. Answering customer questions can sometimes be tough, but nothing gives you deeper insight into how customers use your product than angry customer complaints. As a bonus, this also helps you empathize better with your product counterpart. 

Another activity I highly recommend doing is phone/email support for customers. Yes, straight-up customer support. In a past life, I made all my engineering leaders do a small stint in customer support where they are encouraged to jump into solving customer problems but, at the minimum, are required to listen to customer support agents solving problems for customers. 

That is it, for now, folks. I will probably squeeze in another post before the holidays, but if I don’t talk to you all before that, have a great holiday!

P.S - if you enjoyed reading this post, consider sharing this by click on the button below