Value Modes and Mud Balls

When I was in the midst of leading a team through a complex migration of our infrastructure, taking a web of under-specified microservices to a simplified set with far stronger domain modeling, the most difficult challenge was not the technical work—the team was composed of experts, who knew exactly how to carry out such a migration. Instead, it was articulating the difference between work streams that accrete value versus those that yield no value, or even negative value, until they complete in a "Big Bang" moment of value delivery. Our migration fell squarely into the latter category of binary value.

As an industry, we've become accustomed to methodologies that yield iterative value, be it Agile or other similar approaches. This tends to work exceptionally well for problem spaces where accretion is an effective way forward. For example, landing page optimization can be as simple as changing some variables, running tests and observing the results, then rolling out the ones with statistically significant outcomes. However, adding more mud onto an already established ball only leaves you with a larger ball of mud.¹

To be clear, it's almost always preferable to deliver value continuously and in real-time. Continuous improvement is a core tenant of DevOps and Lean methodology because it reduces the risk that value delivery is delayed unnecessarily or in the pathological case indefinitely as well as the cost of working on the wrong thing. That said, not every project can be shaped to deliver value incrementally. Some problems, like our ball of mud, require reconsidering things more holistically; instead of adding more mud, we could build something different.

Binary Value in the Wild

Some of the most impactful initiatives I've led have been necessarily structured in terms of binary value. That is to say, value that comes into existence all at once and until then there's virtually no sign of value at all. Moreover, these projects might even create drag on velocity, slowing the team down while the work is in progress. This is in stark contrast to an accretion approach, where day-over-day, week-over-week, we see tangible progress and the benefits stream into reality in a consistent and predictable way.

However, not all work can be shaped to fit accretive value delivery. Imagine you have a minimum-viable infrastructure that was built over the weekend in the early days of a startup by a long-since departed colleague. With all the best intentions, they designed an overly complex system composed of microservices that missed the needs of the product by a margin that's only increasing with each passing day. There's a clear path to resolving this issue: fewer microservices, which encapsulate the crystallized modeling of the product domain.

Observant readers will notice that accretion won't help us here: our microservices are poorly modeled, with domains split between them, unnecessary interdependencies, and so forth. Adding more to them won't improve that situation. Instead, we need to rethink our microservices holistically, reconsidering them altogether. So we draft a new architectural design that accounts for what we know about the product as well as some of what we anticipate. But we can't stop the world and rebuild everything and instead we need to craft a new system in parallel with the old. It's crucial here to notice that this is:

1. Extremely costly.² We now have two versions of the system which need to be maintained and kept in sync and,
2. There is no value to this second system while it's incomplete. Even if we gradually switch over to it, until there's only one system we'll be in a space of negative value.³

This is a bit of a scary proposition. There's a reason value accretion is a favored default: if we're wrong about the value here it won't be a cheap mistake to make. However, in this particular case, I'm speaking from the experience of the real initiative I mentioned earlier which proved to be instrumental in moving the product forward. Before it, we were mired in page after page, spending virtually all our cycles in on-call incidents, applying bandages to one systemic problem and then the next. Given these circumstances, such a migration was a fairly clear path.

The Importance of Binary Value

You don't need to be knee-deep in a crisis to prioritize binary value however. In fact it's often the case that the kinds of work streams platform teams find themselves involved in don't accrete value along the way. Partly this is due to the fact that platform teams tend to operate across the holistic system, which often entails projects that by their fundamental nature cannot be accretive. At the same time, these projects provide key business value, ranging from increasing development velocity to attaining important business operations criteria, such as compliance.

A common example is developing continuous integration systems, which until they've been rolled out aren't providing intermediary value. They can also be disruptive when partially rolled out: developers may need to manage systems that use legacy integration strategies alongside ones that use the nascent system. And depending on the complexity of the systems they'll interface with, these projects can take months of development time. Until such a project finishes, it's really not a surface of accretive value delivery.

Another important type of work that can almost never be accretive is certification and compliance work. These are fundamentally binary: you either have SOC 2 compliance or you don't and the work to reach certification does not provide value to that end until it's complete. To check this, consider how silly it would be to suggest to a customer that you're basically SOC 2 compliant because you're midway through certification work–this is unlikely to be an effective substitute for anyone who cares about the certification in the first place.

There are any number of work streams that fall into binary value delivery. Because we're very often more attuned to accretive value, these can be hard to spot at first. But once you begin to look for them, you'll see this crop up in many places. When you do see it, it's a good idea to make sure everyone is aligned with this observation because binary value work streams should be approached with a different methodology altogether.

Socializing Binary Value

As I mentioned at the beginning of this article, my team was undertaking a serious and difficult technical enterprise: migration of a production system to an entirely new architecture. Yet, this was far from the hardest problem. Indeed, the biggest challenge was rallying our business stakeholders around the idea that we can't simply apply a few bandages and be free of the mountain of technical debt that's already weighing us down.

It's hardly surprising that none of us were really thinking about the nature of value itself and how it exists in at least two distinct categories. Accretive value delivery is ubiquitous. So much so in fact it might not even be apparent that value can exist in at least two modes. The first step in aligning with our stakeholders then was to socialize this idea: we're used to putting a little mud on the ball here and there and we're actually pretty good at that, but there's this other kind of value over here that we're currently missing out on.

We posed the idea of incorporating a focus on specific binary value work streams. I doubt this would have been effective if we had simply suggested we dedicate an engineering team to conduct the architecture migration. Instead, by connecting directly with folks and offering our perspective on how value can be driven in different ways, we were able to seed the idea that some kinds of work won't be suited to the model we're used to. This discourse was a foundation for then pitching the work and seeing it through to success with full support from the business.⁴

There's a larger opportunity here to talk about value delivery proactively. Folks are coming from varied backgrounds with exposure to different things. Tapping into this wealth of experience and knowledge by having open and ongoing dialogue is a great way to keep everyone aligned and maximize the potential for great outcomes. I would suggest weaving discussions like these into a regularly occurring, cross-functional forum.⁵

The Impact of Binary Value

Binary and accretive value delivery are two related modes that characterize how we can expect to see returns on our efforts. While accretive methods build value bit by bit over time, binary value is delivered all at once upon completion of a project or initiative. Although accretive methods are often favored for their lower risk, some objectives can only be achieved through binary value delivery. For instance, there's no way to accrete compliance certification; you're either compliant or you're not.

One particular challenge of binary value is that it may not be fully recognized by decision makers during prioritization. Accretive methods are so common that other modes of value delivery might not have been fully considered. It's important to ensure that everyone is able to identify where and how value might be driven, and agree on the best approach given the circumstances.

If we could fit everything into an accretive model, we probably would and arguably should. However, some of the largest impact initiatives have been oriented around binary value delivery. These initiatives have proven to be transformative, having a significant impact on the wider organization and company. For example, I've seen such projects yield millions of dollars in revenue, create seven-figure cost savings, and transform struggling engineering teams into thriving ones.

Accretion is a powerful tool and often the correct one. If we want to increase the surface area of the mud ball or form it into a more polished form, it's the right method. However, when we want to transcend mud altogether, we might need to reach for binary value instead.

Footnotes

1. While this tends to be a pejorative when it comes to software design, it's not altogether bad. This ball of mud got you so far, so it wasn't useless and it deserves a bit of credit. That said, you probably don't want to balance the business on such a foundation indefinitely. ↩

2. The least important cost is monetary, with other costs, like mental overhead or the fact that the legacy system is still actively degrading and requires frequent triage, being far more serious costs. ↩

3. One of the more challenging aspects of such endeavors tends to be the fact they create a negative value before they create positive. That intermediary space of negative value is hard to overcome because we perceive loss as more costly than profit. ↩

4. The full story is a little more nuanced; some calculated failure also illustrated the importance of this direction. ↩

5. If such a forum doesn't already exist, consider establishing a regular time for office hours, open to all departments. Invite folks to bring their own questions and offer perspective on how your group operates. ↩