Sometimes folks will tell you to think about your value proposition – what actual benefit you bring to the table – as a software developer. That could be to negotiate your salary, interviews or promotions. It could be as a freelancer or consultant. It could also just be a way to let you get included in a really cool project (“hey, I can help you out!”)

So what’s your value proposition? What do you actually bring to the table?

Software as Automation

Sometimes software reduces drudgery and toil.

Once a month, Bob needs to update the spreadsheet with the tax information to send to the accountants. He has to log into a bunch of sites and get the monthly expenses. You make a little server that reads the data from various APIs and emails a summary directly to the accountants. Bob gets back a day a month he used to spend doing that.

So: software can reduce work where humans don’t add much value, freeing up humans to do better things with their time. If you’re selling that benefit, you can sell it as time saved (“get Bob’s real job done sooner”) or money saved (“Bob can do something more useful” or even “let’s fire Bob”).

The longer your little server runs, and the less maintenance it takes, the better an idea it was to have you write it.

It’s usually easiest to sell this idea as “I save you money” or “I save you time”, because in theory the company can always keep paying Bob if they want the job done. You just make that cheaper.

Software as Insight

Sometimes software makes people smarter.

If you take your little server from the Bob example and run it every day and email it to Sandra-the-CTO’s secretary, now Sandra can always ask her secretary how much they’re spending on email marketing. A similar trick lets Sandra see how you’re doing on people reading the email and buying a thing, though email companies try hard to make you do that on their site so you can’t just switch email companies.

(Which shows you how valuable they think it is.)

Knowing the answer to questions like, “is this kind of email selling products for us?” makes Sandra smarter, which is a big plus from Sandra’s point of view.

The longer your email reports run, and the less maintenance they take, the better an idea it was to have you write them.

You’d usually sell this as “smart executives make better decisions, which make you more money.” You’re probably also selling a kind of power fantasy to the executives – “you’ll be smarter” is a power fantasy to them too, not just to software developers. But it’s best not to say so directly. I promise, they’ll figure it out when you say it.

Data Scientists sell this one pretty directly. I notice that they’re making a killing these days.

Software as Capability

Sometimes software lets you do a thing you couldn’t do before. Amazon uses software tracking to get packages to their destination more quickly. Supermarkets can get fresher produce on shelves, and even make some kinds of food possible to sell when they would have spoiled before.

When you sell this idea to a company, it will usually be about making money. “I can help you get food onto shelves more quickly” can make them more money. Whatever the company’s purpose, or the team’s purpose, it’s presumably about making money or saving money. So “I’ll help you do a thing” tends to turn into one of those.

It can be hard if you’re talking about a capability they don’t have yet. It’s not always clear how helpful those will be. So you’re guessing a bit, when you sell something new that they can’t already do. Still, you believe it will be helpful or you wouldn’t consider it a value that you bring.

And hey, sometimes it’s easy. “I’m good at statistics, you need tracking statistics, let’s find out where all those defects are coming from” is the kind of thing a manager loves to hear, and knows perfectly well is worth money.

One choice here, especially if you’re talking to somebody with some financial savvy, is to talk in terms of risk. If the company is going to work on the product either way, talk in terms of how much better the software can be with your contribution, or how much more likely it will be to get it finished in an acceptable way.

Having a capability is good, when you need it. So the longer the code you wrote keeps running, the more value they get from being able to do the thing. If your code stops, so does the value.

You’ll normally sell this one as “make more money”. New capabilities, better performance, more money. You’ll want to connect the dots about exactly how, but that should be easy. Ask the company what they do, suggest how they can do it more/better.

Software as Product

Obviously you can make a product that the company can sell. This one is really straightforward in some ways (“You sell widgets. I can make widgets!”). But it can be really hard to figure out a price for it.

You’re basically offering the same kinds of things (automation, insight, capability) but you’re selling them to somebody else, not keeping them and using them for the company. But you’re selling the same basic ideas, just one step further away.

Pricing is hard. You probably don’t have a great idea of how much more expensive they could make their product with you on the team. You also won’t control whether they do.

And you’re probably not talking about you personally making some new product that they don’t sell yet. If you do, that makes it much easier to explain how you bring value! But usually you’re not doing that. If the product isn’t on the market yet, everybody is just guessing how many will be sold at what price. Advanced tip: ask the company for an estimate of this, which they will inflate, and then use that estimate in all your own guesses.

But at that point, your existing track record of fixing problems on teams and fixing problems with products becomes relevant information. It can be hard to “prove” that, but if you try, you’re still ahead of most developers.

In some ways, this is the hardest way to show your value. Products are speculative and customers are fickle. Nobody is very good at predicting what people will buy. It may be easier to sell your value using one of the other categories here.

If the product succeeds then the longer your work runs, the more money it will make. The less maintenance it requires, the better an idea it was to hire you to do it. If it fails, then of course the trick is to fail quickly and cheaply and then it doesn’t matter whether it keeps running.

But if the product works out, your value in building it is delivered over the years as it sells, not immediately and up-front.

Value Over Time, Not Value Up Front

Careful readers have noticed a repeating refrain.

The value in the software, and your value as a developer, doesn’t happen immediately. Instead, the actual “we want this to do a useful thing” value happens day by day and year by year as it keeps working.

To put that another way: if you build something fragile that often doesn’t work, you’re losing a lot of that value. At best it will take a lot of extra maintenance to keep the value coming in. At worst, they shut it down and your time was wasted. They don’t get the value from it, you don’t get the bragging rights.

Why does that matter?

Well, partly because we’re terrible about keeping software running, as an industry. The good case is that we hand it off to Operations or SREs. But we’re also awful about building things that are easy for them to run. Depressingly often, we can make a thing but we can’t keep it going.

And of course, you’d like to be free to move on to building your next chunk of value, not maintaining the old one forever.

If you work at an agency or consultancy, you might reasonably point out that you build the software, you deliver the software and you get paid. But then the value of what you delivered still happens over time. If it stops working, the customer is going to feel they got cheated, just like if you never delivered. It will cost you reputation and future business because what you created didn’t deliver value to the people who paid for it.

This is roughly the same idea as a salaried employee saying, “my software always delivers value on the first of every month, when I get my paycheck.” If it doesn’t work for the buyer, you’ll stop getting paychecks.

Your Value Proposition: Recap

The value of your software, and your value as a software developer, comes from three things.

It can come from reducing toil, which reduces overhead (saves money.)

It can come from adding insight, which improves decisions (makes money.)

It can come from adding capabilities, which will usually improve their performance (makes money.)

And you can sell it, which is the same thing but for the customer (makes money for vendor).

All of the real value of these things is normally delivered over time, not immediately. Even if you make a big piece of software, you don’t normally sell that directly to another company – you use it over time or sell it over time. Even if the customer gets the value from using it, that value is still important.