You Told Me What You Built. But Why Should I Care?

Preface

Having spent almost 20 years in the tech industry, across different companies and domains, I’ve collected my share of battle scars. Each came with a lesson, and I’m always happy to share those lessons with others.

This month, I’m celebrating my first anniversary as an engineering manager at Stripe. This is a big milestone for me. Working at a company like Stripe is a source of pride, and what I’ve learned here in one year would probably have taken me five or ten years elsewhere. I like to say that I’ve been an engineering manager for ten years: five before Stripe, and one at Stripe that counts as five.

One of the biggest, and perhaps most important, lessons I’ve been learning here is about impact. I didn’t fully appreciate how much my thinking had changed until I started helping friends and other people with their CVs and interview preparation. Those conversations made the difference clear enough that I decided to dedicate this post to it.

The pitfall

Almost every time I read a CV from a seasoned engineer, or even an engineering manager, I run into the same pattern. The CV is filled with verbs such as “architected,” “designed,” and “implemented,” followed by descriptions of systems. Some go into gory detail; others are more concise. But they often fail to answer the most basic question: “Who cares?”

Don’t get me wrong. As an engineer at heart, I can sense the joy and pride, mixed with frustration, as these engineers try to squeeze years of hard work into one or two lines on an A4 page. Behind those lines are countless nights spent solving difficult engineering problems. After all, this is why many of us joined this industry in the first place: the joy of creating!

But then I ask again: Who cares?

Let me put on my managerial hat for a second. I’m going through a pile of CVs from very talented engineers, and I need to pick a few people to interview. What will convince me to pick Jane over John, or Paul over Andy? They all went to great schools, worked at great companies, and bring years of experience solving difficult problems.

The answer is the value they brought to the business and its users.

What is impact

Some people think impact is a buzzword thrown around to justify why some people get hired or promoted while others don’t. At one point, I was one of those people. That was because I didn’t fully appreciate its meaning. Thankfully, that is no longer the case.

Most of us work at companies that exist to create value. These companies make money by creating value for their users. If users get the value they need and are delighted by it, they stay. If they don’t, they go elsewhere. It’s as simple as that.

We, the people working at these companies, are there to help create that value. Sometimes we do it directly. Sometimes we do it indirectly, by enabling other people to create value for users.

As engineers and engineering managers, we build products, or the infrastructure that supports them. Our optimization function should therefore be the value we create, not the complexity, difficulty, or ingenuity of what we build.

A complex project that takes a year to solve a very difficult problem but creates little user value is like a tree falling in the forest. Who cares?

On the flip side, a tiny Lua script running in a load balancer that reduces request latency by 40% and makes the product much more appealing to users is a huge win!

Once you understand this simple truth, you start appreciating what impact actually means. Impact is the value, direct or indirect, that you bring to your employer, its business, and its users.

Make your story about impact

When you write your CV or describe a project in an interview, talking about what you architected, designed, or implemented without explaining why it mattered to the business and its users means you are not selling yourself well. Period!

Every line describing your work should explain why users are better off because of what you built. If you can’t explain that, don’t write it.

Moreover, if you can’t quantify the value you created, you leave the reader with no way to judge how much it mattered. From their perspective, it might as well be no value at all.

Imagine you built a state-of-the-art compression algorithm called Pied Piper, and you make the bold claim that it has been adopted by many users. How many? Why did they need it in the first place? What Weissman score did your algorithm achieve, and what did that performance allow users to do?

Give an estimate of adoption, explain the problem those users had, and show what made your solution valuable.

When I read that, I learn two things about you. First, you understand your domain well. More importantly, you understand that you are there to create value for users, and you can explain the value you created.

The "What" still matters

If you come away from this post thinking that describing what you built is no longer important, you’ve missed the point.

The “what” is extremely valuable, but it needs the context of the “why.”

When you write your CV or talk about your projects in an interview, start with why. Explain why the project mattered. Then describe what you built and how it worked.

The “what” is what differentiates you from a salesperson. Being able to describe your solution in detail demonstrates your craftsmanship, which is equally important when presenting yourself as an engineer.

The impact explains why your work mattered. The technical details show the engineering skill you brought to it.

The recommended template

The template I suggest people use when describing their work in a CV is:

“[Architected/Designed/Implemented] a [system/project/feature] that [improved/reduced] [a relevant metric] by [a concrete number or percentage], enabling [users] to [achieve a valuable outcome], through [a brief description of the solution].”

This is not a fixed formula. Modify it and change the order to fit your story. What matters is that both the “why,” ideally supported by a quantifiable metric, and the “what” are there.

Here is a made-up example:

“Architected and implemented a deployment platform that reduced deployment time by 80%, from 50 minutes to 10 minutes, and cut failed production deployments from 12% to 3%, enabling 200 engineers across 30 teams to ship customer-facing improvements faster and with fewer disruptions through automated canary rollouts, health verification, and rollback.”