Engineers & The Creation of Value, Part I

Does What Engineers Do Even Matter? No One Knows.

I believe that software engineers should stop talking about Technical Debt.

I believe they should instead, advocate for Technical Investments, which are defined as:

Work that the engineers believe is valuable to their business…

…but that no one is asking for.

(see: Tech Investments, Not Tech Debt).

But, question #1 is therefore:

"What, exactly, is valuable to a business?"

I’m so excited to talk about this, I’m writing it as a two-part post! Herein is Part I!

Warning (Extremely Valuable) Abstract Thinking Ahead

We're about to do an unapologetically deep dive into how, exactly, engineers create value for the businesses in which they operate.

This may feel somewhat far removed from the day-to-day concerns that are filling up your inbox and/or Slack.

Nonetheless, I'll encourage you to take the time to dig in and really wrestle with the below.

Precisely because few people really understand it, having that insight into the creation of value is like having a superpower.

Such understanding can, over time, meaningfully help your career – because it will allow you to find creative ways (that no one is “asking” for!) to generate major, visible business wins.

It can also make your job profoundly more pleasant. Because you can break out of a lot of frustratingly oppositional patterns, by finding ways to pursue value that work for everyone.

But developing such an understanding takes some real work.¹

What Kind of Value Are We Talking About?

I suspect most engineers, if they think about business value at all, tend to think only of revenue – e.g. if their team is working on a new product, they'll think of "business value" as :

The money that customers will pay us for the new product, once it launches.

This is far too limited a view.

Revenue, by itself, is not a reliable proxy for overall company value – revenue plays a role in determining company value, but is not that value by itself.

Hopefully, the work of the engineers make the company, as a whole, more valuable.

But, what is "overall company value"? And how might we determine it?

Interestingly, there are two situations where we can easily obtain someone’s estimate of overall company value:

• Immediately after an investor buys or sells a share of stock in a public company

• Immediately after closing a funding round at a startup

In both cases, investors are putting up their own money to buy a part of a company.

How much those investors are willing to pay for that part of the company is driven by their belief about the overall company value.

That is the kind of value we're interested in.²

Engineers can, by the work they do, either increase or decrease that kind of overall company value.

The potential increase in value is why companies hire engineers – engineer salaries represent an investment on the part of the business, made in hopes of a positive return.

Whatever someone tells you your job is, please understand and believe me: your actual job is to increase the value of your company.

Unfortunately, company executives tend to have a somewhat limited understanding of how the work of engineers can increase the value of the company.

This is especially true for various value opportunities that engineers can see right in front of them, e.g:

• Cleaning up difficult-to-change code

• Improving tooling to test, integrate and deploy changes

• Instrumenting production systems with monitoring

• Retiring old infrastructure

In the right situations, the above kinds of work can make a company meaningfully more valuable – and can thus be worth prioritizing, even against work that might immediately increase revenue.

But engineers can not, in general, depend on stakeholders or product managers to understand how to convert problems in technical areas into investment opportunities.

That is why "no one is asking for" the work the engineers believe is valuable – because stakeholders don't understand how that work can ultimately make the company worth more.

To ensure that you, as an engineering leader, are able to do that work, we're going to spend some time unpacking the concept of "overall company value".

Hidden within it we'll find the keys to successfully identifying and then advocating for a wide variety of technical investments – and for understanding our work as engineers more broadly.

Also, it's fun!³

What? Oh, Good Lord No, This Is Not How You Talk To Stakeholders

Before we dig in: I'm not proposing you lead with all of the below, in your initial conversations with your stakeholders.

As you read the below just focus on understanding and applying the overall model of value for yourself.

Later in the book, we'll lay out a plan for gradually drawing your stakeholders into a repeated process of decision-making, which they will find delightful.

We'll do so in a way that doesn't require front-loading an economics lecture (stakeholders who are upset about their features being late are oddly resistant to economics lectures, I have found).⁴

A Few Of My Favorite Misconceptions About Value

As step one to sharpening our understanding, let's list several things that are not reliable proxies for engineers increasing overall company value:

• Cranking out new features as fast as possible

• Rapidly chewing through well-groomed tickets on a team's sprint board

• Writing "high-quality" or "defect-free" code

• Living up to long-term "commitments" to delivery deadlines

Stakeholders (and other engineering leaders!) will sometimes tell you, extremely confidently, that something on that list is all you need to worry about.

The way they’ll say that is: "Stop asking so many questions and just do your job".

Implicit in such an exhortation is a belief that "engineering's job" is… just one of those activities.

Such a belief is fundamentally wrong.

Engineering's job is to create value for the business. Even if the people who hired you don't think about it that way.⁵

Each of those activities is potentially valuable for a business… but, unfortunately, each of them is also potentially damaging to value.

Below are situations in which each of the above is valuable… and also situations where each of the above is super totally not valuable:

• Cranking out new features as fast as possible

  
  Super valuable when rapidly chasing product market fit and iteratively testing a series of new prototypes with customers.

  
  Super damaging when the company has built a product that customers fundamentally don't want or need, and the parade of new features is a desperate attempt to avoid facing that hard truth for as long as possible⁶
  

• Rapidly chewing through all the well-groomed tickets on a team's sprint board

  
  Super valuable when the team is developing something genuinely important for the business, and the engineers and product leads are talking all the time, and the work is going live and driving learning every day.

  
  Super damaging if the product team is using the tickets as a way to avoid talking with the engineers and there's weeks of lead time to "write good tickets" (or god forbid Product Requirements Documents) and the engineers don't really understand the why of what they're building and the the team "closes tickets" by merging PRs into some infrequently-deployed branch.
  

• Writing "high-quality" or "defect-free" code

  
  Super valuable if what the code does is genuinely important to customers, AND bugs in the code will cause those customers major problems, AND the code is going to live for a long time AND be changed by many engineers over the course of its life.

  
  Super damaging if the code has a high likelihood of being thrown away, and the time to write it "well" delays critical feedback from customers.⁷
  

• Living up to long-term 'commitments' to delivery deadlines

  Super valuable if, um… Um. Just give me a sec.

  
  Um.

  
  Look, making key business decisions based on extracting long-term "commitments" from engineering is a fool's game for everyone involved.

  
  See Melissa Perri's truly excellent Escaping the Build Trap for much, much better options.

As the above makes clear, there's a lot of contextual nuance to understanding when your team's work is or is not valuable.

Fortunately, there is a unifying way to understand value, so that the most important factors of the context pop into sharp relief.

And developing that unifying understanding will allow you to see a vast array of potential technical investments in a clear light.

So, now, we're ready for Part II, where we're going to build a model! Yee! Hah!

1. My friend Edmund Jorgensen says "Tell them sometimes you need the math so fucking clear an afternoon and brew some coffee".

2. I will bet you All the Things that the leader of your business cares very intensely about this form of value. Like, very, very intensely.

3. It's maybe especially fun if you have an obsessive love for developing a first-principles understanding of activities people are blindly doing all around you. Say.

4. As Edmund and I first came to understand these ideas about company value (after reading the simply amazing Principles of Product Development Flow, by Don Reinertsen), we eagerly brought abstract models for value into just about every one of our discussions with stakeholders. We emerged from that experience a few years later, battered and bruised, with the very different approach you're going to see later.

5. My book is basically a ticket to the Dan Milstein Course in How To Give People What They Actually Want, Not What They Ask For, And Leave Them Very Happy Indeed

6. I totally made this up I've never seen any stakeholders exhibit this exact behavior look something shiny.

7. "The absence of bugs is not the presence of value" should be engraved on the wall of every academic institution that launches one of those stupid engineering productivity studies that measure defect rates as a form of "productivity", argh don't get me started