In the last few chapters we’ve talked about three concepts. Throttling, where some actions we take spins The Wheel of Change and causes the Change-Feedback-Change cycle; Inertia, when the spin takes control over us; And fruition, the time it takes for the actual value to surface v.s. the perceived value.
In this chapter, we’re going to see how thinking of the three together helps us avoid executions of valueless tasks.
Get off The Wheel
At Wiser (2016) I was a team leader in charge of the company’s third web scraping infrastructure. It has finally come to full and complete fruition after a year’s work. All of our external customers were satisfied, the ones we scrape for.
Unfortunately, we also ended up with one hellish core. It was running a few hundreds of scrapers, and bleeding about 6,000$ a month due to performance issues. We anticipated a few thousands scrapers in the upcoming months, meaning costs would be the Bottleneck for the business to scale efficiently. Seems like a good timing to get it fixed.
Because we wished to have a clear set of eyes on this, I called in a meeting. It was with my superior, the VP R&D, the team and three of the most experienced engineers the company had, the architects. I’ve presented a three to six months plan on how to entirely invert the core and turn it into micro-services oriented, whatever that meant. A plan contained to the core with zero Changes to the scraping/business logic itself, no migrations wither. A plan ensuring no harm would be done to our customers, no negative values would be accumulated. I did not anticipate what followed.
“The code is shit. You should dump the entire infrastructure and product and start new. We can make it in three months!”. Surprisingly, they knew it was shit without actually having a look at the code. Although they were right, they were wrong. As it no longer mattered. It’s been weeks since we had any new feature requests or bugs, barely even any open tickets on Jira. The existing business logic was not expected to Change any time soon. Only maybe extended someday when new requirements arise. There would be no value in refactoring the code. Only harm.
“This needs to stop”, I ranted to my manager afterwards. “This is exactly why the company already has three infrastructures which do exactly the same thing. That’s exactly what these guys say every 18 months. And here we are again actually thinking of working on a fourth one?!”.
Coincidently, the company ran into financial troubles and I got fired along with 75% of the company. A few months later they got back on their feet, and started working on the fourth infrastructure. As far as I know, it took 15 months to come to full fruition again. It was re-coded (not 100% as-is), it was stable, performing well and meeting customer satisfaction. Just like the third one did, only running faster. I’m not aware of any deprecations to the old ones or migrations out of them.
Some Wheels not only better stay inert, but better not be hoped on at all. In the next chapter, the first of The Wheel’s Feedback series, we’ll see what leads down these wrong rabbit holes.
Hold the Spin
Sometimes, even though a fruition comes to an end with some external value, you already know it is only temporary and short lived. Such was the case of RapidAPI data team’s main product, the Analytics Dashboard.
We were handed a design for a new feature. As we were migrating on-demand to the new micro front-end infra, it seemed like the right time for another migration. “This is going to take much longer than we previously thought”, said Hezi, one of the finest engineers I had the pleasure of working with. “We thought it would be about two weeks, but after deep diving into the code and estimating it with PERT it would be up to two months”. Proportionally speaking, it would take us more time to migrate to the new infra than the time to code the new feature.
We also already knew the product would be deprecated within 6-9 months. Further down the Roadmap exists an entirely new one. Meaning this feature is going to be this product’s last. No more Changes afterwards, no more value in delivering faster than in the old infra.
If we were first to migrate, we’d only be accumulating negative values, as every Change has the potential for an Instability that would harm the customer. And a fruition duration of months is likely to make the migration itself valueless.
But that may not be the case. Although the migration is not a technical prerequisite for the feature, it has an indirect value. It does not enable a feature, it enables it to be delivered faster. The estimations we’ve done has shown the delivery and fruition would be shorter on the old infra. And it would end with more value and less harm. We avoided throttling the wheel for the wrong reason. Continuing migrating on demand, would just be inertia again, the wheel spinning us.
We kept The Wheel inert for a little while longer.
Don’t Spin
Both on the new infra and the old one, the feature’s fruition process was long and complicated. We were afraid the actual value would differ from the expected value, ending up delivering a valueless feature. Or for it to take so long, leaving the team without a win to celebrate.
The technical feasibility was yet clear enough, and the expected value as well. The technical design and the UI/UX experience, both had a lot of edge cases uncovered. And we kept finding more and more, even after a few days of iterations. I had a decision to make.
The product itself was in an inert state, its Wheel of Change was not spinning. The reason why it was so stable. “I’m sorry guys, but we only came up with a half-baked solution. For this, we won’t start Changing again and cause harm to a fully functional product. This is off the next Sprint”.
I was looking for a good reason to throttle The Wheel and could not find one. Sounded like a good reason for it to stay inert. A few weeks later, priorities changed and the feature was discarded completely. Guess it was not that important to begin with.
In the next series, The Wheel’s Feedback, we’d be digging deeper into understanding why validating the expected value is incredibly important; what Feedback has to do with it; and how Feedback throttles The Wheel of Change. Thank you for reading The Wheel of Change series.