Defining value as a software engineer

Value is about “saving people time and reducing their stress”

According to Clayton Christensen’s “Jobs to Be Done” framework, a widely used product development theory, value means helping someone achieve their goals in a particular circumstance. For example, when someone buys a drill, what they really want is a hole in the wall (not the drill itself). These goals typically fall into three categories: functional (saving time or money), emotional (reducing stress and uncertainty), and social (looking good to others).

Some examples:

• Functional (saving time or money): Using LLMs to write boilerplate code faster (saves time); switching to a cloud IDE to avoid expensive local machine upgrades (saves money)
• Emotional (reducing stress and uncertainty): CI/CD pipelines with reliable tests reduce the stress and uncertainty of manual deployments (it’s insurance against having to stay late at work to fix a production bug)
• Social (looking good to others): Contributing to open-source projects to be seen as a skilled engineer by peers

For me, I’ve always simplified it to just “saving people time and reducing their stress”. I think this definition is easier to remember and it still encompasses all variations of value creation:

Social goals? That’s stress from not being perceived how you want to be perceived.

Money goals? That’s stress from not having money. And money itself is just a store of value, you can’t do anything with it except hold it or look at it in your bank statement. So your only use for it is to buy products or hire services that save you time and reduce your stress.

Value is about “saving people time and reducing their stress”

As a software engineer, your ultimate goal is to save time and reduce stress for the customer and the people you work with (your boss, your peers, your team members, other teams).

Let’s understand WHY and HOW next.

Create value through a decision-making process optimized for global outcomes

One of the primary reasons companies exist is to help customers fulfill their goals (save them time and reduce their stress), so you, as an employee in a given company, must have a clear vision of those customer goals to be able to effectively act and make decisions that positively impact them. Anything that you do that won’t directly or indirectly help with those customer’s goals has little to no value.

But this “indirectly” is what makes things really hard. For me, they are about the behaviors we express in the company when communicating/interacting with others and also about the decisions we have to make on a daily basis regarding what to do and how to do it.

On the topic of decision-making, for example, how do you calibrate if adding a high-scale message broker (e.g., Kafka) to your infrastructure will really help the company’s customers to achieve their goals? The answer to this question is super indirect and abstract, tending more towards an art than a science. There is the time frame question (it works now but will we grow? will the system scale?), the maintenance cost question (who will maintain this? how will this impact new employees’ onboarding?), the security question (is adding this new infrastructure making things safer because of the better configuration options or less safe because we are now expanding the surface area we need to monitor and maintain?). One thing interacts with the other in a mess of probabilistic scenarios that is hard to grasp.

What experienced value-focused software engineers do to cope with that complexity is to have a set of battle-tested mental models and frameworks running in the background of their minds at all times and apply the relevant ones when necessary almost automatically.

You can think of those mental models as pieces of functional software that run in your brain. They receive some set of inputs, perform some calculation and return a result.

And what is the most important input parameter other than the task itself that you have at hand? The one that should always be mandatory but somehow people forget to pass in (weak or untyped interface? 😝). The one where, in my interviews with CEOs, CTOs, and managers, they complained about it being missing in their employees’ mental algorithms?

Business context!

Experienced high-value engineers have a pretty good vision of the business they are in. They deeply understand the WHY of the feature they are planning or building. Who are the main stakeholders for it. What business metrics it will impact. Which aspects of it are important and which aren’t. For example, it’s important for your web application full page load latency to be under 1 second, but any optimization done to reduce full page load latency to less than 1 second is often a waste of time/money/effort because the user’s brain won’t be able to perceive it as meaningfully faster for navigation and thought flow.

This allows them to optimize for global outcomes (value creation for the customer and the company) instead of local outputs (features, tickets, commits).

Now, remember that “The Matrix” scene, “I know kung-fu”, where Neo learns to kick ass in an instant? In the chapter “Mental Models for Decision-Making and Prioritization” you will learn about the mental models I used most throughout my career. Some of them will stick with you, just like kung-fu stuck in Neo’s mind, and you will start making better value-driven decisions and making sense of the chaos.

But what about communicating/interacting with others, why does it create so much indirect value?

Create value through excellent communication skills that reduce friction

Another kind of indirect value you generate for customers is when you help your company run smoothly. When I say “company”, I want you to think of “the group of people whose actions are organized towards creating value to the customer”. Companies are beautiful human systems when you think about it. No single individual would be able to create that amount of value, but when someone organizes them, magic starts to happen.

Magic is a strong word because the reality is that the more humans you add to this organized effort called a company, the more friction will exist for each individual to make their contribution to the whole (and the customer). Examples of that friction are: Communication problems, bureaucracy, politics, distance between main decision-makers and the front lines.

Helping the company run smoothly means helping reduce that friction, and the way you do that is through excellent communication and understanding how to navigate people and human organizations.

Value-driven software engineers have incredible communication skills. They share context when needed, they prevent mistakes by putting everyone on the same page regarding a given issue, they go out of their way to prevent an unnecessary feature from being built. In the chapter “Mental models for being an excellent communicator”, we will explore exactly what you need to do to be considered an excellent communicator.

Here’s a map of how the Value-Focused Software Engineer creates incredible value to the customer via his decisions and communication/interactions with others within the company.

But before we jump into the mental models and behaviors for value-optimized decision-making and excellent communication, I want to talk about the code itself.

You should see code as technical debt

The code is important, but only when and where code is needed.

In fact, it’s better if you think of code as technical debt, even if it’s the most beautiful code you’ve ever seen. If your company could solve the customer problem without code, they would do it! Think about it. Code has a lot of cost associated with it. Once code goes into production, you have to have engineers to maintain it, to update it, to keep it secure, to monitor for failures. Also, engineers come and go so from time to time you have engineers spending time (company money) onboarding on that code.

Mental model: code is technical debt

Having this mindset will help you put the business and customer goals first, always with priority over code and architecture, as it should be.

But don’t get me wrong: knowing good architecture and coding patterns is still a necessary building block in the knowledge needed to create value to the customer as a software engineer. Again, it’s just not the priority when compared to the business and the customer goals. And this isn’t a solved problem in our industry either. I’ve seen a lot of senior engineers writing pretty bad code, even though the knowledge and resources exist and are out there (in the Appendix section I listed the needle-mover resources for me).

Idea

One hypothesis for the existence of those senior engineers that write bad code is that, due to lack of value-oriented mental models, they focused their time on learning new frameworks and new programming languages, thinking THAT would make them better programmers, but it does not. They just learn how to write the same shitty code (hard to read, hard to navigate, hard to test) in many different ways. 😆

I’ll talk about how not to become this senior engineer in the chapter: “Value for you”, section “Honing your skills as a developer: focus on fundamentals rather than on technologies/stacks”

Now that we have code importance in its proper place (after value, business and customer goals), let’s install some new mental model packages in your brain.

Recap

• Value = help people save time and reduce stress
• Your ultimate goal is to create value to the customer, not write code.
• Value for the customer is created when you help your company run smoothly via:
  • Decision-making process optimized for value creation = Mental models + Business context
  • Excellent communication and human interaction skills that reduce friction = save time and reduce stress to people around you

---

This is a sample chapter from High Output Software Engineering. If you liked this one, you might enjoy the other samples available:

• Why read this book?, What it is?, Who is it for?, and How it works?
• The hidden costs of additions to a system (and why you should fight them)
• When in doubt, overcommunicate to prevent possible misalignments

If you're a software engineer working on product teams you might enjoy my book High Output Software Engineering — it's all about understanding value creation, making value-driven trade-offs, communicating with excellence and knowing how to navigate organization dynamics.

Buy it now for $9.99 (PDF & EPUB instant access)