Why Leading Your Way Out of Technical Waste Hasn't Worked

Is technical waste really a threat?

Sure it costs a lot of money, but that is small compared to the revenue from a successful software product. You attained business success by maximizing the odds of revenue. You could afford some technical debt along the way.

But now that debt has become waste. Technical waste is not just costing money. It is costing options. Want to take the product to the cloud? You can’t in less than 2 years. Subscription business? Nope. Integrate with that new business partner who uses a different tech stack? Nope.

Technical waste is no longer an expense. It is now a business threat.

You know this. You have already dedicated multi-year efforts to reducing waste, yet the problem persists. Mounting evidence shows that even good businesses with clear alignment, leadership, skills, and funding are unable to address technical waste.

Clear leadership has not solved technical waste because it is fundamentally different from other business problems. It cannot be solved from the normal way we approach business problems. This does not mean you have to disrupt your whole company. There is a solution that nests within a traditional business approach.

Let’s look at an example

For the purposes of privacy, we will call one of my past clients Company X. Technical waste was costing them 2 key options. 

• They were losing their innovators and senior programmers.
  Why? Interviews showed the top reason was the daily frustration of working in the code.
• They needed to move to subscription pricing and cloud delivery, but couldn’t.
  Why? They would lose too many customers because the current bug rates and fix times were too high for subscription service expectations.

They had just under 1,000 people in the software organization. Leadership gave the product direction six pillars, with one of them being to fix technical waste – and it was hailed as one of the top two critical pillars. Each team was expected to spend about 30% of its budget on stories to address technical waste.

The result of a 2 year investment? Technical waste didn’t get much worse.

The tools got more stable, teams made improvements, and several key cultural transitions happened. Despite these wins, there was no significant impact on business options. Employee retention remained low, defects remained high, and releases remained infrequent and late.

Company X decided to get more data. They ran a simple survey, asking each of the teams what technical obstacles they faced. Specifically, what would prevent them from moving to continuous delivery for internal dogfooding.

They clustered the 76 responses given by the 69 responding teams. They sized each cluster based on the number of teams that identified that problem.

There was very little agreement:

The most widespread problem impacted just 9% of the org; there were only 3 problems that impacted more than 2 teams. Yet most of these problems required multi-team collaboration to solve.

Implications

Having a unique problems for each team is fundamentally different than every other problem a business faces. Yet this is the normal case for technical waste.

Organizations are designed to make it easy to align around problems and share techniques and resources. They take advantage of the 80/20 rule, finding the 20% of the problem space that delivers 80% of the value, and then align to address that 20% well.

Organizational alignment doesn’t work with technical waste, because there is no big problem. Each part of the organization has a fundamentally different problem.

As an example, one second-level manager had 6 teams reporting up to him.

• 1 team’s #1 problem was insufficient automated tests. They wanted to add many.
• 1 team’s #1 problem was too many automated tests. They wanted to delete many.
• The other 4 teams’ problems had nothing to do with testing – or with each other.
• Every team was right, for their context.

There is no metric or alignment that works for these teams. Any direction that manager could have given for his six teams would be obviously wrong to five out of his six teams — and this gets even worse as you look higher in the organization.

Solving technical waste requires a new way of organizing, but it must fit within today’s organizations.

How Company X Started Solving Technical Waste

2 of the 13 organizations adopted a better way to lead. It is conceptually simple but hard in practice. There are 3 critical parts:

• Leaders shift from trying to align teams around objectives to trying to improve teams ability to make decisions and own outcomes.
• Teams improve their ability to fix sources of technical waste without passing risk along to other teams or the organization.
• Everyone aligns on an incremental and experiment-driven approach to picking which risks to address and how.

How Leaders Improve Teams

Aligning in contradictory directions at once requires us to change the definition of leadership. Why? Because leaders can no longer provide alignment or consistent decision-making. They focus on Growing Responsible Ownership (GROw handout download). The stances and mentoring provided within GROw helps leaders enhance the abilities of teams to make responsible decisions, and those teams then choose what problems to solve and how to do so. Everyone demonstrates their responsibility through the use of experimentation and data as they are now unlocked to address its blocking problems without causing problems for others. The company can dynamically align in many directions at once.

How Teams Fix Waste Without Externalizing Risk

It’s not just about the leaders though. Teams must deeply understand risk and safety, and learn to code in a way that simultaneously reduces both short-term and long-term risk. Disciplined Refactoring is the best way of working we’ve seen, and our flagship workshop with 16 specific and practical techniques that applies Disciplined Refactoring effectively. This provides the technical safety to improve quality, attain continuous delivery, replace a legacy system, and improve general product development. Whatever technical wastes you experience, Code by Refactoring shows you how to fix those wastes without causing problems for any other team.

How Everyone Re-Aligns Incrementally

Alignment isn’t an one-time event. Every waste fixed and every bug found alters the situation. The strategy shifts from aligning around a direction to re-aligning quickly and effectively. A practice is needed to ensure a team can do that reliably. Safeguarding is the best way we have found for a team to continuously re-align to address the risks that are impacting them today. Over time, this practice results in a team optimizing its investments towards the most significant wastes — without having to wait for deep analysis.

What Now?

The product you get is a direct reflection of developer habits.

A classic response to technical waste is to try to shift process and culture. However, while culture is hard to change, specific behaviors and habits on the micro level are not. Getting different business results is easy when these habits can be changed and aligned to the business needs.

So how do we change those habits?

Awareness is the first step towards change. This begins in workshops that introduce the habits.

Experiencing the new state helps the brain start recognizing new patterns. This begins in the mobbing experience within those workshops.

Practicing the new state helps the brain build the neural pathways that build new patterns for the long term. This begins in the daily practice that focuses on one micro-behavioral shift at a time.

And what habits need to change?

Deep Roots (email) has discovered the specific behavior shifts that are necessary to increase quality, rewrite legacy systems, and get to continuous delivery. Let us help you eliminate your business threat!

• ←Previous
• Next→