What every engineer should know about business cases

A lot of people think engineering and business should not be in the same sentence. I think they should be together more often. A lot of the problems I’ve seen in companies is engineers and business not talking to each other. That miscommunication can bring a lot of trouble to an organization. From a more positive side if you are starting as an engineer, understanding the business and communicating in their language can be a great superpower.

The purpose of this text is not to go through the different reasons the disconnection happens, but to propose a bridge. I am not going to suggest we send our all business friends to CS school (although it could help also) but the bridge in this scenario is the other way around.

Think about any interaction you have with somebody from the business side (Product Owner or something like that). A lot of times the conversation is engineers think they should build X but the business does not understand why. This causes two fundamental problems: engineers can’t build the right stuff, so everything crumbles (hello technical debt!) and business does not understand why engineers want to build X (looks like they just want to scratch their own itch).

Next time you are planning this kind of conversation. Frame it in a business case. This is a very simple exercise, where the central idea is to have a return of investment. We are going to build X, it is going to cost the company Y and we are going to make Z money, so in T time we are going to recover the money, after that we’ll profit. There are far more complex and complete approaches than this, but think it in a simple way. If you buy a car and use it for Uber, how long will you recover the money you invested in the car.

I know it’s pretty simple, but I want you to apply it to engineering. There is two kinds of costs: development (your time and your team) and infrastructure (you are probably working on cloud, so you’ll need a place to host all those shiny microservices of python scripts). Getting the cost should not be hard and if it starts to get very complex a good approximation will work.

The other part of the equation (how much money is the company going to make or Z in our equation) can be a little be more complex but still doable. There are several ways the company you work for can make money with software:

  • Selling more: You’ll be able to handle more traffic, products, regions or regions just to name a few
  • Being more efficient: I’ll take less time to close a deal, so if you are faster you’ll close more deals. Or you reduce costs, now everything is more automated and you don’t need a lot of humans ( I am not saying you should suggest replacing other coworkers with bash scripts, not cool, hopefully, they’ll be able to perform more meaningful tasks than what they were doing before)
  • Reducing risks: If we use MQRabbit there will be a lower chance of everything crumbling on Black Friday. So you won’t wake me up in the middle of the night saying that the site is down and people can’t buy cat food

I am sure there are a lot more ways, these were meant to give you examples and light up your inspiration. A cool trick is to involve the business people if you explain a little your idea they can think of other way of framing it.

Once you have costs and ways to make money, its just a matter of thinking how long it’ll take to recover they money you invested.

This is not a silver bullet not all your projects will be approved by this method. Although it will start some very interesting conversations that might help you build what you think is worth building.

Happy to hear from you on twitter.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s