If a business has software engineering but no external software product, then its engineers are primarily focused on delivering software that supports the rest of the business (i.e. increasing throughput while lowering operational expenses and reducing inventory).

It is not enough for the engineers in this function to meet the stated requirements delivered by the rest of the organization. That might be a political success, but if it does not actually impact the above metrics, it really doesn’t matter for the business.

The software engineers are the only ones capable of balancing the continued software delivery capabilities (i.e. being able to continue to add features and change systems) with the task of also adding new features.

They must have a very strong understanding of the business in order to do this effectively, as they won’t be able to make day-to-day decisions that support both of these objectives at the same time.

If engineers function only as order-takers, they will not make decisions that will continue to work for feature after feature, or architect a system in a direction that can evolve with the business, and eventually defects increase, delivery speed slows down, and discussions about rewriting and migrating, or maybe outsourcing ensue.

Software engineering requires making technical decisions that serve the organizational needs, and nobody else in the organization has the necessary context to do this. It is their job to be fluent in the business and experts in their domain.

Many software organizations fail at this basic responsibility, instead allowing the business to dictate timetables, priorities, and in some unfortunate cases, technical decision-making.

Software engineering is about delivering this feature, ensuring it is the right feature and has impact, and also continuing to deliver the next and the next without creating instability.

Uncertainty and Reducing Risk

Finding out you’re wrong quickly is better than finding out you’re wrong slowly.

Further, delivering value sooner is preferable to delivering value later (unless later it is dramatically more). If the value is the same overall, you want to get it sooner so that you can put it into use.

Both of these things imply that incremental delivery is the best approach, as you get feedback faster (find out if you’re wrong) and deliver value sooner (turn investment into results faster).

If this sounds like Agile development, it’s because it is.

But I want to also add – you don’t need to pick an agile religion. Scrum versus Kanban versus LEAN etc are really inconsequential.

The important outcome is to adopt a way of thinking and continuous improvement that allows you to start anywhere and get better and better over time. The prescriptions of agile consultants can largely be ignored if you actually start to think in an agile way, and to keep the goals front and center.

More Insights from The Goal

Eli Goldratt maintains that an experimental mindset is a key business skill because you can’t know perfectly what is going to make a difference in a complex system.

Perfectly controlled experiments aren’t possible (at least practically) in most business contexts. And in a complex enough system, it’s very hard to be sure you’re isolating variables.

Fortunately, the point is not absolute certainty, but more like good-enough certainty.

You can hypothesize and test and measure. That’s enough to apply the mindset.

For this to work well, the whole business must adopt the same mindset. We are investigating and learning, forming a more useful model of our domain. If we all have that approach, then software engineering can proceed well, as everyone knows that we’re trying to make an impact and we have to figure out how.

Applied Learning Directed at Goals

It starts to become clear that a great business must be a learning enterprise.

Mediocre businesses don’t learn much. They learned once, or they learn slowly, and they mostly coast doing what they’re doing.

A great business has to be great. To be great is not an all-at-once thing. It requires continuously improving, and continuously striving after what’s next, and capturing knowledge and distilling it, and putting it into practice.

And then the next generation must be trained in the how and the why. Otherwise good practices are forgotten, and eventually great ideas that are counterintuitive are replaced with good ideas that make sense on the surface.

Training and collaboration and writing useful (and used) documentation must be part of the daily work. Personal development has to be a focus to keep a business growing and not breaking. People must embody and eschew the principles and knowledge, and continue searching for what works better.

In the next article, I will explore Software Engineering when it creates products.