How to become passionate about delivering shareholder value

I am passionate about delivering shareholder value. It feels kind of embarrassing to admit, but it’s true¹. I like all the things an engineer is supposed to like - writing elegant code, designing systems, solving hard technical problems - but I confess I don’t like those things as much as I like delivering shareholder value. That’s why I kind of enjoy the vibe shift that’s happened recently in tech. I wish my job was more secure, and my colleagues were happier, but I do really like the fact that my work is now much more tightly connected to the company’s strategy.

I think delivering shareholder value is underrated among software engineers. I have worked with many smart, competent engineers who believed that their job was to write good code, and if any shareholder value happened along the way that was the company’s business. To some degree this is a trauma response: when company strategy whipsaws around enough, engineers will give up on trying to follow it and just focus on the work directly in front of them. I’m sure there are also companies that structurally encourage this mindset (e.g. by punishing engineers who try and stick their noses into strategy discussions)². But I also think that many engineers just haven’t heard the best case for why they ought to be focusing on shareholder value. I’m going to try to deliver that case now.

What is shareholder value?

First, what does “delivering shareholder value” mean? It sounds like vague corporate-speak. However, it’s actually not corporate-speak but finance-speak, and like most financial statements it has a very specific definition. Delivering shareholder value means making the company stock price go up and stay up³.

That’s it! By itself, it’s not a very useful definition, since it’s not clear how connected my Jira ticket is to the Microsoft stock price. But engineers should be used to accurate-but-not-useful definitions in other domains⁴. They’re often the first step on the road to having actual functional intuitions about the topic. We’ll get there, but right now I want to emphasize that “delivering shareholder value” is not vague or nonsense. It is a concrete idea.

Note: “and stay up” is a core part of the definition. I’m not talking about pure hype - that might temporarily raise the stock price, but at some point it’ll all come crashing down. The best way to deliver durable shareholder value is to build good products that people are willing to pay for. It’s probably possible to build a career around pumping out purely short-term value, but that’s not really what I’m interested in or what I’m writing about here.

Can engineers even impact shareholder value?

Although it’s hard to say exactly how, it’s foolish to think that an individual engineer has no impact on your company’s stock price. For one thing, tech companies make money from software, and the success or failure of a software project can obviously impact company stock price in many ways:

• A delayed project can lead to an unimpressive yearly conference, lowering hype
• A project that launches buggy or non-functional can shape customer sentiment for a long time
• Successful projects can directly make money, increasing fundamentals, or cause hype
• Visible enough failures - e.g. huge security incidents - can affect stock prices all on their own

The one thing everyone agreed on in my post about shipping is that delivering a successful project requires one single engineer to have all the context in their head. So engineers leading projects have a direct connection to shareholder value. But even if you’re not leading a project, you might still be instrumental in its success or failure. Successful or unsuccessful company departments often succeed or fail on the strength of their engineers: how capable they are, how many mistakes they make, how fast they can work when speed matters.

Why might you want to create shareholder value?

What if you don’t care about any of this? What if you’re interested in the intellectual challenge of designing software, not the business challenge of building hype or profits?

One reason you might care is that shareholder value is part of the software design process. There is no such thing as “good software” in a vacuum. Good software is software that is good at something: i.e. at some particular goal. If you’re not connected to the financial goals of the company, you run the risk of optimizing for software that looks nice or is cool. In my view, that’s not really software design. It’s much more satisfying to design software against real constraints.

Another reason is that creating shareholder value is harder than most technical problems. Many technical problems you encounter in the line of work are easy to solve. But creating shareholder value - making money - is usually hard, because everyone is trying to do it and the space is much more competitive. Another reason it’s hard is that you have more potential to really fail than in most technical problems. In technical problems, you can tell pretty quickly if something’s likely to end up working or not. But when you’re trying to deliver shareholder value, you can try something that seems really promising but goes completely nowhere. That’s challenging! It’s worth getting good at.

A third reason is that it’s your job. You can certainly survive at a tech company by just doing what you’re told and only having opinions about technical matters. But it’s not really what you’re paid to do. You’re paid to produce value (i.e. value for shareholders). I don’t think it’s actually a moral failing to not do your job well. People get to decide what they want to do. But if you’re the kind of person who values doing your job, you have a strong reason to care about shareholder value.

A final reason - perhaps the most important - is that you may end up being happier at work. Many engineers are unhappy because their values are misaligned with their company’s values. If there is a way for you to care about what your company cares about, you should do it! Aside from having a better relationship with managers and executives, it’ll just feel more real.

One common theory of burnout is “work unrecognized”: engineers burn out not because they work too hard, but because their work becomes untethered from the feedback they’re getting from the company. I think one cause of this is a values mismatch between engineers and their employers - that can cause engineers to end up grinding away at a task that their manager doesn’t care about at all.

Final thoughts

I know it sounds like a joke or parody to say “I’m passionate about delivering shareholder value” - like saying “my greatest weakness is I work too hard”. But it really is true. I worry that people who are new to the industry are picking up a bit too much unwarranted cynicism, and that it’s not going to serve them well long-term.

I think a lot of engineers are working in situations where there doesn’t seem to be any path to affecting shareholder value one way or another. Either their opinions aren’t taken seriously, or their product is stagnant, or they’re just too snowed under with bullshit. The last thing I want to do is to chide those engineers - that’s a really tricky situation. But lots of us work in more functional environments, where we have a real opportunity to shape the financial situation of the company, for good or ill.

If you do have that opportunity, you’ll probably be a lot more satisfied at work if you take it.

edit: One interesting note - I run most of my blog posts through GPT-o3 before publishing to catch typos and make high-level structural suggestions (I never use any actual generated text). While o3 is much less sycophantic than 4o, it still likes to start its feedback with a paragraph of what it likes about the post. This was the first post I’ve tried where it didn’t do that. It’s not a model update: it gives positive feedback about other drafts I have in the pipeline. For some reason, GPT-o3 really didn’t like this post!