In the previous chapter, we’ve taken a look at one of the Wheel of Change’s properties, Change entails Feedback entails Change. In this chapter, we’re going to examine another property of it. The spin has a speed which can be controlled by throttling it correctly. By speeding it up & slowing it down when necessary. That would require to act correctly under necessity itself and overcome it.
In the previous chapter, we talked about RapidAPI’s predictability and customer satisfaction. The path towards that was via ownership of products. So that a single product could be entirely developed end-to-end by a single team. To do so, an organizational Change was needed. As borders were set, it was needed to minimize friction that causes delays in delivery. But there was this little tiny tiny problem – the system’s architecture was blocking it from happening. And It affected my group the most.
The Monetization team of our group had about 14 products embedded into 3 really big and messy front end clients, all of them owned and maintained by other teams. It had easily taken them a week or two to review and approve Changes, as they had their own priorities, and the sudden move to remote working (Covid) did not help this at all. This has deeply frustrated the Monetization team. And my superiors were unhappy with the delivery delays we were experiencing.
We needed to remove the technological dependencies that tightly coupled the teams. Engineers from several groups and teams worked hard to resolve this. They have created a new micro-frontend infrastructure to enable hosting of small applications within bigger ones, a reverse dependency. Once done, it allowed the team to run free and removed one major inefficiency. Now possible, 14 different products should be migrated to the new infrastructure. Or should they?
As the first migration took about two weeks, we expected others to take roughly the same (we were horribly wrong, more on that later in this series). As binary thinkers, we came up with two non-beneficial migration plans. The first, not to migrate any of them. Obviously, that would have zero impact and we won’t be minimizing neither frustration nor delivery delays. If we do want to minimize as much as possible, the other option would be to migrate them all, and as quickly as possible. It may not be instinctively clear to us why this is non-beneficial as well. Let’s try and see why through a single product timeline.
It’s a timeline of exactly one block of Change, moving to the new infra. The next thing that would happen is nothing. The product would be moved as-is, with zero customer facing Changes. If the customer experiences No-Change, there would be no Feedback. And when there is no Feedback, there is no Change. When the Change-Feedback-Change cycle does not exist, there would be nothing that throttles the Wheel of Change, so it would not spin.
And if it doesn’t spin, there would be no Changes. And if there are no Changes, there is nothing to deliver. We may have moved to a new infra, but there is zero external customer value as there is nothing to deliver. And there is also zero internal value to the team because there are no delivery delays to overcome when there is nothing to deliver!
Actually that’s not 100% correct. Migrating the product would indeed throttle the wheel. As every Change has the potential to cause an Instability, it might entail Feedback that would entail Changes, to fix those instabilities. This is of a negative value. Mostly external one to the customer, but also for the team. They would spend time on fixing something that should not have been broken in the first palace. Because there is no reason to spend two weeks on something we’ve just seen has at best a non-negative value.
I can think of one reason. Out of inertia. If we’ve already started moving to the new infra, we should finish it. We may have throttled the wheel, but it spins out of control. Or better to say, the spin controls us. And that would have non-beneficial results.
So, if there is no value in migrating the second product, why did we migrate the first one? Throttling is not always a question of when, it’s also a question of before what. We did so before it was expected to Change and because it was expected to Change.
Two months earlier, the Monetization team got a design full of Changes from our PMs. We’ve divided it to 3 Epics with 3-5 User Stories each. They were mostly ready for execution. Alas, with a two weeks delivery delay for each User Story, it would have taken forever to get even one Epic done.
Not only that, we knew that Change entails Feedback entails Change. It was expected for The Wheel of Change to no longer be inert, but to start spinning. With such delays, Our Velocity could never keep up with the spin itself, as we would also create instabilities along the way. The gap between the Velocity and the Spin would result in a bad customer experience. If we’re already about to throttle The Wheel of Change, we’d better make sure we can stay on it. Which is exactly why it was the right time to remove the inefficiency in delivery. It was clear that the effort invested was guaranteed to be valuable, as right after setting up the new infrastructure actual delays would be saved. Months of it.
[From left to right, the order of events. In red: high level non-technical goals, In blue: required Changes]
Once done, indeed it was our bottleneck. It allowed us to quickly deliver small Changes to our PMs for Feedback. It allowed us to deliver to our customers within minutes. We delivered faster than ever, which caused trouble of its own. It also opened up the possibility to keep up with next year’s roadmap, one of full new products and many future Changes.
The Wheel of Change spins, but unlike before it generates positive values. Because the reason to throttle it was not of inertia, but to create external customer value. And we kept on controlling the throttle by migrating on-demand.
A few weeks afterwards a new need arose. RapidAPI has decided to move from private tenancy to multi-tenancy. It has entailed major external customer facing Changes to one other product of the Monetization team. It was the right time again to throttle the wheel and make it spin for a while.
By the time I left RapidAPI we’d moved only 3 products out of 14. If the job was to move all the products, I did not get the job done. If the job was to get the right job done, I did get the job done. I can only hope they keep on throttling correctly, by understanding how timing and value are so tightly coupled. We’ve seen it throughout this chapter and we’d be digging deep into it in the next one.