💰 Code with Purpose: Business Value Is definitely Your Job as a Software Engineer 🔧
🌟 Beyond Algorithms and Technicalities: let’s talk about how important it is to remember that our job is making the company profitable, not just having fun with technology and tools we love.
⏩ Introduction
I read this article this summer: Business Value Isn’t My Job and it was so painful to read that I immediately planned to restart the newsletter today with some reflection on the topic.
I invite you to read it, but here is a quick recap just to set up the stage for my thoughts: the author, Bryan Finster, talked about a conversation he had with a developer stating that a Software Engineer only needs to bring to the table their technical knowledge, and if a company need a domain expert they will hire one.
Bryan expressed his pain on hearing that, and I couldn’t agree more than that with him: the fact that some experienced developers might think that is very sad.
A couple of other very bad things that this person said to Bryan: “If the business tanks and you’ve fulfilled your role as efficiently as possible why would you care? The market is begging for good SWEs.” — or “As a software engineer, it’s not our job to drive business value.”
Go to the article to read it all: if you suffered like I did when reading such things, you will love Bryan’s reflection on that — and hopefully also mine once you are back here.
🎨 Once you understand the business value, your value is 10x
You know what they say, right?
The operation was successful, but the patient died.
If you are perfect technically, and then the business doesn’t work, it’s (also) your responsibility to understand why and how to make it work. It just is.
That is actually the real job!
We bring our technical knowledge to the table, yes — but only to cooperate with the skills of the others so that the company makes money. This has multiple consequences, and while some imply how we should technically approach the job, some others actually imply that we must become a domain expert on our company business and the way our company is trying to make money in that business.
On the technical side, for example, we should be able to develop software in a way that lowers the risks for the business to the minimum possible: This includes, for example, being able to build MVP in a short time, or making experiments and A/B testing very cheap. This can all be conducted by having code that is easy to change — and I immediately think of Test-Driven Development, Continuous Integration, Continuous Deployment, Trunk-Based Development, Domain-Driven Design, etc.
All those amazing, top-notch practices have one thing in common — the same thing shared by Lean, XP, and Agile in general: they are not just practices to make the life of developers better or make the job more fun — they are practices that maximize the competitive advantage that business has with its own technology; they enable business moving fast, adapting to changes in real-world, spending just enough needed in a feature, etc. They are a smart choice to support the business, not just because of technicalities.
But that is not enough!
It is fundamental to understand how business works to be successful: you need to know which business you work on, how important it is for people and for society, who are your customers, how much money is involved in that business, etc.
Why is all that information important? Because they should impact your decisions!
Imagine you work for an e-commerce company selling shoes: the type of shoes you sell is a fundamental thing to know. If you sell baby shoes, the actual customers of the shop are the parents. If you sell only shoes that cost thousands of euros, your customers are very rich people.
This information will impact all the company parts, software engineering included:
- marketing will focus on communication and advertisements for parents/rich people
- UX in the first case will probably need to be simple, while in the second you might want to test something that makes people feel to be in an exclusive, premium shop because rich people are used to feeling special
- products we offer will probably have different materials and costs, since baby shoes need to be comfortable but will be used for some months, while premium shoes must last all life and might not even be used once
Let’s come to the impact on software development and imagine the cost of a bug coming to production: we can assume that in both cases, bugs will not have much impact in real life, because people will be fine if they can’t buy some shoes due to a bug; on the other hand, the impact on the company success will be different due to a different cost and profit for the two type of products, that will be higher in the premium shoes example, meaning more money lost due to the bug.
In both cases, the basic technology behind is fairly standard: just e-commerce. But if we try to imagine 10 years for the two companies, while the baby shoes shop could live with a no-code/low-code solution for its entire life, the second one could probably need an internal codebase at least for a part of the shop, to enable the chances to offer Premium features to rich people that are so addicted to being treated as VIP.
The miscommunication of this information between the management and the product team on these kinds of topics is one of the biggest causes of problems in a company. But don’t make the mistake of thinking that “if they don’t tell me, it’s their fault”: If you accept that, and do nothing to make them understand how important it is for the team to know such information and daily communicate with the stakeholders and customers, then you are part of the problem.
The “product team” is not a company team working on product knowledge — is a team of people working on a specific product; it’s cross-functional, including stakeholders, PM, Marketing, UX, Dev, Ops, etc. Everyone should be on the same product team. Companies should organize themselves into product cross-functional teams, not in Marketing/Product/Tech, etc. People with similar tasks should find other ways to align on how companies do things in their skill context but work daily with other members of the product team.
Remember this: if you are able to have a visible impact on business with your job, you will be irreplaceable — no AI can get your place because it’s your unique impact as a human being that makes a difference in the team and the company, not just a technical skill.
Until next time, happy coding! 🤓👩‍💻👨‍💻
Go Deeper 🔎
đź“š Books
- The Clean Coder: A Code of Conduct for Professional Programmers — In The Clean Coder: A Code of Conduct for Professional Programmers, legendary software expert Robert C. Martin introduces the disciplines, techniques, tools, and practices of true software craftsmanship. This book is packed with practical advice–about everything from estimating and coding to refactoring and testing. It covers much more than technique: It is about attitude.
đź“© Newsletter issues
- Why most software teams are inefficient [Craft Better Software newsletter by Daniel Moka]
đź“„ Blog posts
- Business Value Isn’t My Job — the post that inspired this issue
🎙️ Podcast episodes
- Habits of Successful Software Engineers — Getting to Code Quickly and Model Thinking [Developer Tea podcast]
🙏 Thank you for reading this shortened version of the article, you can find the full version on my blog here.
