Hard Thoughts About Assets and Value in a Software Organization

I've been thinking and experimenting a lot about how to use the various LLMs, both in my work and with my clients. I keep seeing a familiar trap: that managers think the gating factor in product development is the speed of coding. But that's not true. The gating factor is the speed of understanding the customer problem and then, how fast the team learns together to solve that problem. (For more info, see A Little Scree About AI and the Hard Parts of Product Development.)

In the meantime, managers keep focusing on lines of code as an asset. Lines of code—by themselves—are not an asset. Once the managers realize that, we can address their very real questions:

• What is an asset?
• How can we measure assets? Unfortunately, what's easy to measure is not always a useful measure.

I'll start with assets.

How I Think About Assets

Assets offer current—and sometimes—future value to the organization.

Here are some examples of assets in your organization:

• Existing products. Because your customers can buy them, which increases your revenue. Also, sometimes, the organization can depreciate them. (See How to Link the Team’s Measures to What Managers Want for a brief discussion of CapEx, OpEx, and depreciation.)
• Running, tested features that are ready to deploy.
• Capital equipment, because you can depreciate it.

You might have heard the saying, “People are our greatest asset.” That happens to be almost true, even if managers do not always act that way.

In software organizations, the collaborative team is the greatest asset. Because no one can finish a running, tested feature—never mind a project— alone.

And while we can add more features to products, the product itself does not learn. Teams of people, from product value teams, customer success teams, and product development teams—learn what customers want and how to solve those customers' problems.

LLMs cannot increase that speed of learning with more code. They might increase the speed of learning with more tests and validation suggestions.

Lines of code are not an asset. Only running, tested features are an asset.

Now, let's discuss how we might measure an asset.

How to Measure Assets

We have some ways to measure assets.

For example, we can use a product backlog burnup chart to see how many more running, tested features we have added to the product over time. (For more information and examples, see Agile and Lean Program Management or Create Your Successful Agile Project.) I like this burnup chart because it shows how we also increase the problems we want to solve over time.

Notice that running, tested features might not require more lines of code. Sometimes, teams learn that they need to remove lines of code to be able to create a running, tested feature.

We might want to see a given team's speed of learning. I find this most valuable for managers, not for cross-functional teams. See Why Minimize Management Decision Time for more details.

The flow metrics help us see old work and why that's a problem. (See Flow Metrics and Why They Matter to Teams and Managers.) In addition, the longer the cycle time, the slower that team learns.

Challenge Yourself About Your Asset and Value Thinking

I am sure that the LLMs can support a team's ability to learn faster. However, writing more lines of code does not help a team learn faster. Too often, more lines of code blur the lines between what is an asset and what is dreck. (Or cruft.)

Instead, ask yourself these questions:

• What would have to be true for a team to learn as fast as possible? What product management structures or people would need to be where? What team structures would we need?
• How can we all our tools, including LLMs to finish more running, tested features? Or, prune the product tree so we have less to do?
• What do our customers find most valuable about our product now? How can we capitalize on that to make an even more valuable product?

Lines of code are not an asset. Lines of code do not appreciate in value over time. Only running, tested features can appreciate in value over time. Even better, team learning can appreciate over time, whether those are management or feature teams.

Easy measures, which are often activity-based measures, can mislead us and distract us from value-focused measures. Decisions, whether they are in the form of running, tested features, or management decisions, do offer value.