In the last article, we looked briefly at software engineering that support business functions but does not create products.

We noted that they need to be experimental, work in small batches (short iterations) and are ultimately learning enterprises. We noted that the software engineers must be able to measure and observe that their work is having an intended effect.

And we noted that the businesses the software organizations are in must be similar in order for it to all work well together.

What then, is the difference between a supporting software organization and one that creates products?

The Value Stream for Product Development

Where does the software engineering fit in the value pipeline?

There is an obvious application of the principles of the Goal to the software engineering process itself, considered as its own system. This is considering throughput as the release of features, work in progress (unreleased features) as inventory, and the costs as the costs of engineering.

While there is great value in that kind of thinking, it does not properly contextualize software engineering in a business which needs to make money, and so it is not complete.

This is where things get difficult. Software, the product, is not produced in the same way as other kinds of goods are manufactured.

The manufacturing process for a copy of a software program is copying bits and sending them over a wire, or putting them onto some medium. This process is generally not very interesting. Frequently the next copy costs very little, and the next customer acquired (other than the acquisition costs) costs little to add to a running system.

So if the sale of the software does not require any real manufacturing, since the software does not need to be rewritten by software engineers every time it is sold (whereas each custom hubcap is its own product, and if it is not manufactured, it cannot be sold), what exactly do software engineers do?

Supporting the Value Stream

It turns out that software engineers, even in the context of a company that makes a software product, do not sit directly in the middle of the value stream that produces the money. They are orthogonal to it. They have a large impact on it but usually the result of their efforts are not immediately tied to dollars in (with the exception of companies that charge for the software development itself as consultants).

It turns out that software as product, compared to software as business support, is very similar.

The main difference is who the end user of the software is, and how the effect on the rest of the value pipeline is measured (i.e. the one in which dollars are flowing).

Measuring Impact

What exactly needs to be measured?

Since the customers of the software company are also the users of the software, and they are ultimately the exit points of the money-in to become money-out, it would be logical to assume that what needs to be measured is the increase in sales, year over year, and the retention rates of existing customers.

While these are primary goals, they are also trailing indicators. By the time customers have moved on or sales have declined, it is too late to retain those customers or make those sales.

What would be leading indicators? Every software company has its own, but they all center around what customers need the product for, and how the company can continue improving the product and attracting new customers. (At least, they ought to, but in practice a lot of activity in software engineering organizations seems to just be for the sake of change. See Slack, for example, which I hear constant complaints about on every new release).

Not that different yet very different

It turns out that these things are not that different than working with internal customers (i.e. other business units) except for the scale and remoteness. More programmatic data collection methods are used to get usage data and collect errors, and building relationships with customers is not always straightforward or easy.

There are slews of 3rd party applications to collect this kind of data, and many businesses whose business is helping other businesses learn about their customers.

All of this data can be useful, but ultimately misses the point if nobody actually talks to actual customers and finds out what they really need.

As this becomes extremely complex, and guessing what would make the most impact becomes harder, it lends itself to specialization.

This is where we find the role of “Product Management” – people whose job it is to figure out what to build next that might make the difference to our value pipeline.

What Product Does

Product Management focuses on determining what the engineers should be building.

This role exists already in software engineering if it’s being done right. As mentioned in a previous post, engineers need to thoroughly understand the business and the users of their software to do their job right. They must have some ideas of what requirements are there and what could help.

Having dedicated “Product Managers” in most companies is a two-edged sword.

On the one hand, the additional engagement with customers and analysis can truly helpful in making a real impact.

On the other hand a separate hierarchy is usually set up that reports parallel to, but separate from, the software engineering organization. Different incentives emerge, and success is not measured in the same way across both organizations.

Where the breakdown happens

Career advancement for product often means getting ambitious projects shipped.

Where the breakdown happens is when Product has a different set of incentives than Engineering. Engineering is responsible for the ongoing ability to deliver and stability as well as the features being delivered.

Product is not responsible for stability. They are responsible for initiatives. After all the fanfare happens, engineers are held responsible for outages, and slow velocity moving forward.

As the classic agile fable goes, when the chicken and the pig start a breakfast restaurant, the chicken is only involved, while the pig is committed.

Software engineering teams are committed to the code they produce, while product is only involved.

Because the product department is not accountable to the same metrics, technical debt that results in immediate delivery is translated to career advancement for them, and a slow down for the engineers in the form of bad code and more production incidents (i.e. unplanned work).

This does begin affecting the product owner eventually, if they are around long enough, and then product and engineering start discussing “paying off tech debt”. There is usually a limited appetite, and business as usual happens shortly after, and the next feature becomes the number one priority.

What could work…

What could work, long-term, is engineering committed to delivering on time and at a high quality. That does not accept the supposed conflict between quality and velocity. (There really is none, if your horizon is even a month or two).

But what about an organizational structure that correctly aligns incentives of people with what makes sense for the business?

This kind of radical change is unlikely to happen in already established companies because most leaders are fearful of making the changes needed, because so many key people would not like it.

If that is impossible, what would be second best?

Engineering leaders need to provide a better menu of options. Instead of irresponsible short-cuts, provide ways to solve problems creatively, or deliver the most essential parts of the solution quickly.

Instead of “It will take 2 months, but if we do this quick workaround, we could ship in 2 weeks, but we would need to then spend 8 weeks following up”, it could be “We can ship this sub-feature in 2 weeks, and follow up with the subsequent deliverables in each of the following 6 weeks”

In an organization that could actually follow through on its commitments to cleaning up (this is rarer than you think) short-cuts and tech debt could actually make sense. But frequently the interest is paid 10x over before the principal is touched, and sometimes it becomes so expensive that projects start acquiring the label of “legacy code”, which is product-engineering-speak for “We give up on it”.

Engineering has to own quality, stability, and the continued ability to deliver further features. Nobody else can do that.

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.

As we explore Software Engineering and its relationship to businesses, the first question is: What is success?

Notice that I don’t ask “What is software engineering?” To say what something is means you have to know why it exists. And to know why it exists, you must know the end it is directed towards, which is also what would define success.

If the ultimate aim is understanding how to improve these organizations, we must have a good answer to this question, because better is only a relative term.

So what is the goal of software engineering?

Software is a tool. Therefore it must be for something, to solve some problem.

Some things are just for their own sake, like playing a game or the piano, or reading a book. It’s just fun.

While a software engineer may feel this way about writing software, that does not explain the context in which software engineering happens inside of organizations. Why are people willing to spend so much money on software engineering?

What are the kinds of problems that organizations need software engineering to solve?

To get at this, it is necessary to say something about the general nature of business.

Since businesses and organizations have many different ends and reasons for being (and they’re incommensurate) it can be helpful to look at the most basic common denominator.

Businesses exist to make money.

“But what about non-profits or other kinds of organizations that don’t make money?”

Wikipedia is a good example here. Wikipedia must produce a platform that attracts and delights enough users that its yearly appeal for donations meets its operating expenses. Something they do must result in dollars going back into their organization to replace the dollars spent operating it.

So we will content ourselves, at least for now, to using this simple definition. An organization must take money, spend it doing some activity, and then somehow end up with at least the same amount of money on the other side through sales or donations.

If organizations need to make money, how does software engineering help?

The Goal

In The Goal, Eli Goldratt lays out the theory of constraints. This theory is essential if you want to understand what makes some companies beautifully effective and fast, while others are a huge mess.

The goal is to make money, or, stated differently increase throughput while reducing inventory and operational expenses.

Let’s break this down. Throughput is the rate at which money in is converted to more money out through sales. Why do we choose sales as the endpoint? Because everything else is meaningless. If you build up $100k of inventory and you had $100k to start with, you now have $0. You can no longer operate your business to even sell the inventory. You could work for free and try to move some things, but your inventory is only valuable to you if someone wants it.

Sales is then the end of the value pipeline.

Money in -> ???? -> Sales. That’s the basic story. The “????” is your particular business.

Why reduce inventory? As mentioned, inventory is just money trapped in the system. Why would you want money trapped in the system instead of converted to sales (and thereby available to become another input)?

Operational expenses are all the money that the system burns in the middle. This is money you don’t get back, but that is necessary to convert each dollar in into more dollars out. It’s obvious why you want to reduce this. These dollars are necessary, but if you could do the same work without them, you would.

Throughput. This is perhaps the most interesting part of this definition. Why do we want to increase throughput? Because every time a dollar goes through your system, it comes out as a dollar + a little extra. This is exponential growth. This is what allows you to reinvest. The larger your pipeline of throughput, the more money you can make in your business. The faster your throughput, the faster you can compound this process.

How does Software Engineering fit in this picture?

Software fits into a business in primarily 2 ways.

1. Software is the product
2. Software supports the business

Depending on what kind of business you have, you may not need your own software engineering in-house. But you absolutely need some function in your organization that is responsible for delivering the needed software to the needed business functions to support either a) increasing throughput, b) reducing inventory or c) reducing operational expenses.

Software engineering may not exist as a discipline in your company, but it is difficult (seemingly impossible) to compete in most industries with no software at all.

So Successful Software Engineering does…?

A Successful Software Engineering Organization either creates the product or supports the operation of the business.

Is the definition of success the same in each case?

If it supports operations, then its role can be seen simply as improving the existing processes, or even replacing them, to achieve the goal (as outlined above).

If it produces the product, then its role is actually a key part of the value pipeline of the whole business.

In order to understand how a software organization is working, you need to evaluate it in reference to its goals. Only then could we compare the function in two contexts to see if they’re measured in the same way.

We will do this in the following posts.

What makes a successful software engineering organization?

What are the simple quantitative outcomes? What are the harder-to-measure qualitative outcomes?

Does successful software engineering help companies make more money?

What’s the exprience of working in a successful versus failing software engineering organization?

Are the engineers happier? Do they work harder or more hours? Do they get more done with less effort?

These are essential questions to answer on the way to improving a software engineering organization and the teams that comprise them.

As Stephen Covey reminds us in The 7 Habits, “Begin with the end in mind”.

So before optimizing for success, we must define it.