All Projects Are Business Projects

When building software, I have often been faced with the debates on “Technical” projects vs “Business” projects.

• Business project aim at increasing KPIs, grow revenue, improve user experience, offer new capabilities in the product. They are seen as bringing in value and very high priority.
• Technical projects are driven by engineering and often are related to infra changes, refactoring, adding tests, improving architecture, updating dependencies, framework changes and so on. They are seen as a cost and are often deprioritised.

I disagree with this approach for many reasons, so let’s get into it!

tl;dr:

• All projects in a company have a business purpose, even the one looking more technical. We should highlight this impact to get things prioritised. This requires effort but is worth doing for a more pleasant day to day and a more future-proof career.
• Not all tasks are up for debate. Some things just need to happen in order to build a given piece of software, this is just the reality of building a software product. Engineers should explain the necessity of said tasks, but should also professionally push back against unreasonable asks.

There are no technical projects

Hot take: all projects are business projects, and if a an engineering team is doing something just for the sake of doing something technical they are making a mistake.

Am I saying that we shouldn’t work on technical topics? Of course not. It means that those technical tasks and projects are done to achieve some kind of business goal, even if at first glance it might not seem like it.

Here are some examples of topics I’ve often seen framed as “technical projects” and how they could be viewed. I’m simplifying everything here, of course, but you’ll get the point.

The key here is for engineers to highlight the business impact. Everything is done for a reason, but non-technical people might not understand it and think this is a waste of time.

The problem with technical stories

While having “technical stories” or “technical sprints” can help moving some topics forward, it often doesn’t work properly for a few reasons.

• Accepting that we have technical stories and business stories enables shortcuts when building new features. It leads to the mindset of “if it exists purely technical stories, we’ll use them to fix our problems later”, and then many technical topics that should be inherent to the creation of a feature become up for debate and maybe pushed back.
• It leads to comparing two widely different things. If I’m a non-technical CEO and I have to chose between “Refactor this feature to align with best practices” and “Add social login to drive conversion up by 5%”, I’m picking the second one every day. To make good decisions we need to look at options with their business impact in mind.
• Finally, engineers are often tasked creating technical stories, but often struggle to do a good job at it. This can be for many reasons. They could be swamped by work coming from “business” stories… so the preparation work and framing ends up subpar, making it even harder to get prioritised. It could also be that they don’t feel like preparing stories is part of their job and don’t want to do it. It could also simply be a lack of experience doing it.

Moving away from technical stories in different work streams allows for more interesting tradeoffs.

Painting walls

What I find really surprising is how many technical decisions are left up for debate to a very broad audience. This feels even more obvious when you are having the discussion for another profession.

Let’s say I want my wall painted green, and I hired someone to do it. The steps to do so would probably look like:

• Some back and forth and project management to figure out what to do and when to do it.
• Go at the store and buy paint
• Come to my home, move furnitures around
• Put down protective sheets on the floor
• Put a first layer of white paint to prepare the wall
• Wait a few hours
• Paint the wall green
• Wait a few hours
• Paint the second layer of green <- This is what I want, a well painted wall
• Wait a few hours
• Do small fixes, touch up mistakes
• Clean up the gear, remove protections layers
• Put the furniture back
• Handle invoicing and so on

Now imagine if I said: “Ok, we have the business project of painting the second layer of green, this brings value to my home. However to move faster I don’t think we should paint the first layer or cleanup, that seems like low value technical tasks. Also, I don’t want my floor dirty, but I also don’t feel like you need to put protective layers to do this, so let’s skip this part as well. Finally, going at the store and getting paint is completely out of scope: the paint should be on the wall, not at the store.”

This clearly makes no sense, and obviously all steps are required, even if some seem less related to making my wall green.

Explaining and having a business sense

Following this example, it’s worth saying that the painter and I could discuss the value of each step.

For instance the first layer of white paint could be skipped, but it would reduce the quality of the final result. However removing the wait between layers is nonsensical and would ruin everything. Explaining those tradeoffs and helping the customer make the decision might be required and is the painter’s responsibility. The painter should be firm when steps are unavoidable, but also pragmatic if the value of a step is not bringing the expected value.

This is the same thing with building software. Engineers need to be able to explain what is needed and give a sense of why. They should have a clear idea of what could be removed or added and the consequences of doing so, and express it to their business and product partners.

Include all the work

To address this issue, all feature work should include all the technical aspects required to its success. This means refactoring, tests and so on are just as part of the project as business-logic code. They are not something to be negotiated or a different project that we can do later: they are a needed action for completing the project. Of course each team should figure out what they consider to be the level of quality they want to aim for depending on their context - don’t put the same level of security in banking software or in a marketing landing page.

It’s important to remind ourselves that we are building software. We should not put technical work to the side because there is inherent complexity that needs to be managed. Skipping this part might you feel like you move faster right now, and even this could be debated, but this is not viable long or even mid term.

If some technical debt piled up so much that it is unmanageable, there should be some one-off projects that are more driven by engineering. However those projects need to make business sense and be showcased as such. For instance there is probably no need to refactor a feature that doesn’t evolve, is stable and might even be removed in a few months… but adding more tests to the payment system is probably high priority.

To be able to work like this require a lot of trust between engineering and the rest of the organisation, and this might take time to build… but this is worth it and pays off in the long run if you want quality software that is able to evolve quickly without stress.

Example

Let’s say a developer want to refactor the authentication system. Right now it is in a monolith and was built by interns 5 years ago. The developer hate everything about this piece of software with a passion. For context, the company has decided to move to services a couple of years ago, and auth is still stuck.

To get this refactoring done, they first need to get the product manager on board. Here is how the discussion could go:

Obviously, not the best outcome. In this situation the dev:

• Focused on fuzzy concepts like guidelines or technical debt that have no clear business impact.
• Didn’t take the current company objectives into account.

The PM was focusing on user impact and staying on target, which makes sense. If everything seems to be working fine, spending more time on a system can easily be seen as over-quality.

Here’s a different approach:

In this situation the dev:

• Took the time to highlight the business benefits.
• Showcased the positive impact of the refactoring.
• Anticipated the discussion so that there is room for planning and no need to disrupt ongoing projects.
• Didn’t allow for much debate around the extraction into a service.
• Agreed to take some additional communication and organisational tasks to get the change moving.

Of course this second one is idealised and assumes a good work relationship between the dev and the PM. It also requires a good product/business sense from the dev, which means that they have time allocated to go beyond just writing code. The PM also needs to be open for discussion and acknowledge the complexity inherent in building software.

That’s not easy and not all companies, teams and individuals are able to have this level of communication. However it’s really worth thriving to get there as the benefits are just so significant.

As an engineer, you’ll get some push back with partners that will discard good points by saying “we are doing this because I said so”, or some variation of this. You’ll have to get out of your comfort zone invest time in improving your knowledge of the business and product.

More than 10 years ago I wrote “Developers, Share Your Technical Knowledge”, and I still stand behind this. Sharing how things work, explaining the impact of code and architecture is key in having a more interesting professional experience and building trust.

In my opinion, investing in these skills and spending the time doing it is really worth doing. Going beyond writing code will be a great benefit for your career and your day to day. This is especially true today, where AI is shuffling the card, giving even more power to those who can build software and understand the business or product side of things.