The Engineering Manager

But why?

I was in a supermarket recently, and at the other end of the aisle I could hear a parent getting continually more frustrated. What should have been a relatively simple trip to purchase some groceries had been turned into a consistent barrage of questions. Their young child had entered the why stage. No action or decision was safe from the dreaded why.

Why were they going down this particular aisle? Why was it cold in this part of the supermarket? Why does cheese need to be refrigerated after all? No topic was taboo. Parents who are unable to deal with the persistent barrage of whys find the dialogue drifting off into the absurd, where they find themselves explaining why trollies have wheels, why shops exist, and why we even need to eat food in the first place. Why? Why?!

Adults find this behavior incredibly annoying. Children in the why phase manage to highlight just how much of the world that we, as adults, don’t tend to spend too much time thinking about. As we age, we reason at ever more abstract levels that don’t need to be concerned with. For example, we don’t care exactly how a car is put together – we just drive it. This ability to think abstractly and to build upon abstract concepts with even more abstract concepts has allowed the human race to flourish. Right now I’m not thinking at all about how my keyboard works, or how my operating system works, or how machine code is being executed by the processor on my laptop. I’m just writing.

But listening to this child constantly asking why made me think: why don’t we do this more as adults?

Conserving power

In an evolutionary sense, the ability to work in abstractions allows us to conserve vast amounts of brainpower. Imagine the overwhelm of having to concern yourself with how everything works all of the time, from gravity to your musculoskeletal system, to your heart, the hardware and software stacks of your phone, and so on. We wouldn’t leave our beds. Trust in abstractions and analogies allow us to function.

But consider the flip side: how much do we refuse to question because it seemingly is good enough right now? How many poor or inefficient decisions have come of a result of not challenging the status quo?

As a manager, compared to an individual contributor, you have the ability to veto a number of decisions, such as the priority of projects, who to hire and how to get work done. Depending on your seniority in the organization, you may be able to make critical strategic decisions such as whether to move all of your applications into the cloud, whether to acquire another company, or whether to lay off half of your staff after a disappointing year.

You therefore owe it to yourself to improve your critical thinking skills. You can partition these skills into two categories:

• Using why to critique existing ideas
• Using first principles to construct your own

These thinking techniques are interlinked. As the child in the opening example showed, continued use of why helps distill an idea into first principles (or lack thereof). When building new ideas, application of first principles should result in well-formed ideas that can stand thorough application of why.

Using questions to interrogate assumptions

Let’s start by exploring the power of why.

A common practice when there is an incident such as downtime of an application, or a critical bug that caused reduced service or corrupted data is a 5 Whys session. It is a technique to uncover the root cause of issues. Typically the application of five iterations of “why?” can uncover the next steps that the team needs to take to prevent the incident from happening again in the future.

As an example, let’s assume that your application is down.

1. Why? Because the API stopped serving any requests.
2. Why? Because the latest deploy caused a deadlock when the application started up.
3. Why? Because the production environment has many more concurrent requests than the testing environment, and a non-thread safe data structure was used.
4. Why? It wasn’t thought about during development. The tests all passed.
5. Why? The automated tests don’t cover any high-throughput scenarios.

We hit the root cause by the 5th why. The action is to improve the automated tests to incorporate a load simulation of the live environment.

It’s extremely useful to apply questioning to situations where something has gone wrong. But we should also be applying critical questioning in order to test assumptions about seemingly good processes and decisions. Because humans operate in abstractions, and because we can become comfortable with those abstractions, we can sometimes not question them enough as we should do. A key skill as a manager is being able to question everything for the greater good of the business.

Now, your reason for doing this isn’t because you are trying to be annoying, nor is it because you don’t inherently trust the instruction or direction that you are being given. That couldn’t be further from the truth! Instead, you should be applying a critical mindset to everything that you’re involved in because, when handled personably, it can challenge existing ways of thinking and produce better results.

For example, many businesses operate under the assumption that running any of their applications in the cloud is too expensive in the long term. This thinking can stifle innovation. Let’s apply a similar questioning technique to the 5 Whys example above.

Let’s assume that your team wants to build a new part of the application in the cloud, but are facing resistance.

• Why? We don’t build applications in the cloud because it is way too expensive.
• Why is it expensive? When we compare the cost of cloud instances to the cost of buying hardware and paying it off over three years, it costs more money.
• Why is that the case? We did a comparison of running our existing infrastructure in the cloud two years ago, and the costs were almost double.
• Which parts were most expensive? Any instances that required reservations of SSDs or GPUs were dramatically more expensive than buying the hardware ourselves.
• The new part of the application does not require SSDs or GPUs. What would that cost? Looking at the pricing plans now, it seems that the cost of reserved instances is about equivalent to the cost of buying our own hardware. Still, we’re used to buying our own hardware, so we should just do that.
• But are there other costs with buying our own hardware? I guess there is the time that it takes for us to build and rack the new machines – we could be doing something else instead, plus the extra power consumption in the data center, and the additional spares we’d need to keep as well. We’d also need to deal with anything that breaks, such as replacing drives or PSUs.
• What do you think about using the cloud for this new part of the application now? Actually, it’s not that bad. We should think about how we can save time and effort by putting more stateless parts of the application in the cloud.

OK, so the example is a little contrived, but I hope that it illustrates a point. We can use questioning to break down assumptions to their root (i.e. an assumption that all cloud compute is too expensive) and then see whether that still holds true. Using this technique with skill can potentially save you and your business a lot of time and money.

Thinking from first principles

When we use critical questioning to challenge existing assumptions, we dig right down to the building blocks that those assumptions are based on. These building blocks are called first principles. By definition, a first principle is a self-evident proposition or assumption that cannot be deduced from any other proposition or assumption. In the above example, the first principle that the assumption was based on was that all cloud compute was too expensive, but that wasn’t actually true.

When approaching new problems and coming up with your own ideas, you should think in terms of first principles to improve the clarity of your thinking. As mentioned previously, our ability to think in abstractions can weaken our judgement, as those abstractions may no longer be as true as they once were. Also a similarly dangerous evolutionary trait is our ability to think in analogy, where we make assumptions based on the comparison of two things that are not actually related. We can also be on top of Mount Stupid.

For example, if your boss approaches you saying you need to build something like Facebook for marketers, then the critical thinking that should have been done to fully explore the problem is being masked by analogy: of course, Facebook is successful, so if we just replicate that for another problem domain then it will definitely be a success, right? Wrong. Instead, you need to think from first principles. What does Facebook for marketers actually mean? Is it about connecting marketers together? Is it about sharing insight or information with each other? Is it enabling communication within a company, or globally? Is it simply being able to easily search for data within their business? What problem exactly needs to be solved?

It’s always easier to reason by analogy than first principles. I recommend watching this video about first principles thinking by Elon Musk. Despite the extra brain power required, thinking in this way leads to better outcomes. In the video, Elon describes how thinking in analogy created an assumption in the industry that batteries would always be too expensive to build. But instead, thinking about the problem from first principles, by researching the cost of each individual component and calculating the cost per kilowatt hour, revealed that previous analogy was not at all true, unlocking Tesla as a business. And as of the time of writing, they’re doing pretty well.

In summary

A key to growth in managerial roles is not simply efficient execution of whatever work that you are being given. Excellent managers are also able to think critically and apply first principles thinking to whatever work they, or the business is doing – it leads to better decisions, less wasted time and money, and more innovative products that solve users’ problems. Encourage this mindset with your team and colleagues.

We don’t sell, we close

What’s your relationship with the salespeople in your organization? Do you even talk to them? Is there a culture of us and them in your company? Do you feel like they see your department as unwashed geeks and you see theirs as a herd of Patrick Batemans wearing Submariners? I hope not!

Regardless of your own relationship with the salespeople in the organization, you have to have utmost respect for them: they close the deals that bring in the money that keep us all employed. Kudos to them.

Although we as engineers may have a stereotype of salespeople as the hustlers of big deals, commission cheques and the wearers of flashy Swiss watches, the art of selling big enterprise deals requires real talent, artistry and chutzpah. These people are at the periphery of the business, often away from home at the other end of the world on puddle-jumper flights, fighting the good fight to sell the stuff you’re building.

What do salespeople do all day?

As a manager in engineering, it’s extremely useful to include some salespeople in your network inside the business. Before we look at some ways that you can work more closely with salespeople, and most importantly, make their lives much easier, let’s have a look at what they typically concern themselves with.

Now there are many different types of sales roles in the world of SaaS. Those roles can range from those who contact leads who have requested demos or who have been identified as prospects at events to qualify them as worth pursuing further, through to senior salespeople who spend multiple quarters crafting multi-million dollar deals. In the same way that your most senior engineers can have a dramatic effect on the future health of the company, the same is true with the most senior salespeople. A landmark deal can secure years of runway and growth.

So what do they concern themselves with?

• Building relationships. Software companies with sales organizations of a decent size will typically work on deals that are worth quite a lot of money. This means that they aren’t the kind of deals that close very quickly. The length of time it takes from a lead being qualified to the paper being signed is called the sales cycle and for the biggest deals the sales cycle can potentially be years. This means that your salespeople will be continually working on building the relationship with their prospect throughout the cycle, ensuring that what they are selling is what ultimately gets chosen.
• Solving problems with the technology that you are building. Every client has different problems that your software can solve. Your salesperson will think creatively about how your software can fit into their daily lives so that they can do their job better, faster and more efficiently. This can be as simple as demonstrating the power of the software through to building a compelling story of how their whole organization could change around it.
• Working on revenue targets and growth. Always be closing: this is slightly tongue-in-cheek with a reference to the quite epic monologue in Glengarry Glen Ross (warning: very strong language) but it rings very true: sales is about closing deals. It’s not about turning up and giving a pitch in the hope that someone will bite, it’s about being creative, hustling, getting on that plane or train, learning about prospects, getting their interest and then getting them to sign on the dotted line. Sales organizations hold themselves to typically quarterly targets and they have to hit them (and you thought that your deadlines were bad). They’re the frontline indicator of the health of the business. If they’re closing lots of deals, it’s probably a function of their confidence in the product and the great work you’re doing. If they’re having a bad quarter, it could quite possibly be an indicator of something else that’s wrong in the organization, but they get the flak. Remember this.
• Understanding what the market wants to buy. They are uniquely placed to see what kinds of problems clients are trying to solve and what kinds of existing tools they are using to do it (if any!). They can also use the relationships they build to see that there are entirely new, untapped areas of the market to sell to. Also, they can alert you to when there are cheap ambitious startups that are trying to undercut you. Is the market becoming more specialist and is after point solutions rather than software suites? Is the market becoming more price sensitive and as a result you need to adjust yours?

So now we’ve taken a look at what salespeople concern themselves with, how can you help them do their job even better? Let’s be honest – it’s a world away from you working on the code with your team. Or is it?

How can you help salespeople succeed?

There are a number of ways that you can help your sales staff do their job really well. Let’s take a look at some of them.

• Get to know them. You’ll have more in common with them than you think: you’re making the stuff that they sell! Introduce yourself, spend some time talking to them about their job and what their current challenges are. Buy them a coffee and have a chat. As mentioned at the beginning of the article, some organizations have an us and them culture between engineering and commercial. You can bridge this gap.
• Prioritize uptime, speed and stability. You might have the best features in the world, but if they’re slow, buggy and ragged around the edges then that won’t matter one bit in a demo. Keep experimental or slow features behind feature flags. Ensure you’re fixing stability issues as a priority. Remember that demos may be occurring on different continents to the one that you’re on, and consider your SLAs carefully. A simple, fast tool can make a feature rich slow tool look awful when they are pitched side-to-side.
• Deliver on time. Since the sales cycle can be a long one, especially when your software is going through lengthy procurement procedures, remember that your roadmap is a key persuader to the potential buyer. If you’ve promised to drop a feature this quarter and you don’t, then your salespeople will look like they’re overpromising or that there isn’t company-wide alignment on the story and the discipline of delivery.
• Work on cadence. In addition to delivering on time, you’ll want to work on your cadence of delivery with your team. Software that has regular updates looks cared for, alive and driven by creative people. Sequence your projects so that you can keep releasing new things regularly. If you have large pieces of architecture work that will take months to complete, try to combine them with lots of small enhancements so that your salespeople can show that you’re always shipping.
• Promise at the right granularity. This point is aimed more at product, but you can help lobby the cause as an engineering leader. Roadmaps that go into to much granularity before the unknowns have been worked out will fail to deliver. Prime your salespeople with roadmaps that provide high granularity for features very close to release, but talk in general terms about what you’re doing six months from now. Describing that the latter half of the year will concern itself with “solving our most common data export problems” is better than saying you’ll be “allowing data export from all 25 components” because it gives you more flexibility in the scope of the project. It’s hard to fail at the first promise.
• Use their expertise as stakeholders in new projects. If not already, as per your product marketers, invite key salespeople to join your team’s demo meetings and kick-offs for new projects and solicit their feedback regularly. They’re working on the periphery of the business and have some of the most up to date information from the field: key missing features, what competitors are selling, and how you stack up against them.

In summary

The sales staff in your organization have more in common with you than you might think. They’re fantastic people to have closer to your team to get a temperature check on what you’re building, and they have the most up to date information on how you’re stacking up against your competitors. Go and talk to them.

Thank you to Joakim Nilsson for the comments and feedback on my draft of this post.