Value over replacement in software engineering

There are two ways of assessing how much value you’re providing as an engineer. The first way is to total up all of the code you’ve shipped and all of the value that code has provided (e.g. how much money it’s made). The second way is to try and figure out what you specifically have done that a replacement-level engineer in your place wouldn’t have done. In other words, you can look at your literal value, or you can look at your value over replacement.

I don’t think one way is necessarily better than the other. But it’s important to be clear-eyed about which method you’re using and why. For instance, if you’re wondering if you’re justifying your compensation, you should be looking at value. That’s a straightforward calculation of how much money your company is spending on you, and how much value it’s getting back. But if you’re wondering if you deserve to be promoted, you should be looking at value over replacement. It’s cool that some code you shipped made 10M in ARR, but if that was normal work that any of your peers would have done (e.g. if you’d been sick), it doesn’t necessarily mean you’re performing above your level.

How can you measure value? It’s easy to know how much money the company is spending on you. The hard part is gauging how much money the company is getting back. If you know how much profit the company is making - and you should - you can try to estimate how much profit your specific part of the company is making, and how much your code is contributing to that. For instance, if you write a signup flow for a new customer segment, and those customers end up being a ~5M/yr source of revenue, you can plausibly say that your value is some reasonable percentage of 5M/yr.

What about value over replacement? That requires guessing at which of the things you did were things other engineers wouldn’t have done in your place (or would have done slower). You have to develop a concept of a “replacement-level engineer”: the median-strength engineer that could be hired at your level and at your company. It’s easy to fool yourself in both directions here - either imagining that your replacement would be a total dud, or that your replacement would be very strong indeed. In general, this is much harder than just measuring value.

If you’re in the habit of proactively identifying new work (e.g. hacking on new features or digging through metrics to find performance issues), estimating your value over replacement is much easier. The replacement-level engineer would have at least tried to do all the work you were assigned, but they wouldn’t have had the same ideas you had. As long as the work you identify actually adds value, that value is value over replacement.

However, you can definitely add value over replacement doing regular work, even if it’s harder to spot. One way to identify this is to notice when you (or another engineer) are explicitly requested for a particular project: because of your subject-matter expertise, or unusual speed, or something along those lines. This is a direct recognition of value over replacement.

In theory, you don’t necessarily have to deliver value over replacement. Being a standard-level engineer across all metrics is good enough by definition. But nobody is standard across all metrics. Everyone’s worse at some tasks and better at others. In practice, you had better deliver positive value over replacement in at least some areas, because you’re likely delivering negative value in others.