You probably have heard about McDonald’s before, right? Have you ever wondered how McDonald’s makes money?

If you thought that they’re in the burger business, you’re wrong. At first glance, it appears that their revenue comes through selling fast food.

If you look closer though, you will see that the majority of their revenue comes from real estate.

Their franchise is set up in a way that franchisees not just buy the concept from them, but also lease the restaurant.

The nice advantage for them is that it provides them with an additional source of income. It pays off especially when burger sales plummet during economically difficult times.

When you look at your business, what comes out when you look at it from a different angle?

I worked in software development agencies for a long time. There, I wrote code based on requirements clients gave me. That’s all I ever thought I would do.

The focus was always on the code, code quality, pair programming, and so on.

What if all these things don’t matter as much as you think? I’m not saying that they’re irrelevant, they’re still important. It’s just that I am shifting focus on something else.

In the past, a software developer’s job was to take requirements that were often gathered by somebody else and turn them into working code. Then, as soon as the code was working, it was another team’s job to get this into production. There was a clear separation between Dev and Ops.

We already learned over ten years ago, that things work better when Dev and Ops work together. It was the inception of a new movement: DevOps. DevOps brought a lot of new tools and methodologies with it.

What happened here was that we’ve had two separate processes that required an eventual handover.

Handovers cost time and are a potential herd for information loss that could cause trouble during deployment.

DevOps looks at this from a different perspective and eliminates the handover that causes so much trouble. Instead of having two individual core processes, we now have one. The idea behind this is that instead of thinking in business functions such as Software Development and Software Operations, we look at it from a process perspective.

The new process looks like this:

Dev + Ops working together

The process now takes into account everything from the first line of code until a new version goes into production. Also, there are no handovers between departments anymore, because there’s only one department now.

This change required software developers to learn more about software operations and vice versa administrators how to write code and work with tools like version control and a CI Server. The combination of both disciplines increased effectiveness by a lot.

Now, when it comes to selling software development services to clients, you might think “What’s the big deal, they need software and I have the people to write it”.

Again, at first glance, this seems valid. Let’s look at this in more detail.

When a new client project starts, what are the first steps? You meet with your new client and discuss requirements, right?

The client might say things like “So, we want to build a business based on white-label landing pages for customers. They can come in and create their own landing pages without having to write a single line of code. We want email integration, so they can send emails to their clients, contact management, and payment integration as well so they can get paid right away upfront.”

What happens next? If you start writing code right away, you’re missing a lot of steps in between.

Instead, ask more questions such as “How do you intend to make money off of this?”, “Where do you want to start rolling this out? Nationally or internationally?”

These questions in the end help you to determine which technology stack you’ll be using (web application only or are mobile Apps needed too?), how to deploy it (single vs. multiple regions on a cloud provider, do you need a CDN?) and so on.

Your core process in this scenario is not to write software. It is knowledge transfer. You get as much knowledge from your client to build the software they need for their business model. Choosing the right technology plays a huge role in this, as it determines if you will reach milestones in time and if the software will work reliably in production.

But looking at it from a macro perspective, technology, CI/CD, clean code, pair programming are tools in your toolbox to help businesses succeed in a digital environment. It will be still your job to choose the right tools for the job, but you should choose them based on how much value they add to your process.

What do you think about this approach? Do you think that this could help your business as well? Do you need help to market this approach to your customers? I want to hear your thoughts: jan@work-with-jan.com.