In the previous chapter, we’ve seen one of the Wheel of Change’s traits. Change entails Feedback entails Change, but the question is how fast it happens. In this chapter, we’re going to examine the trait of the spin’s throttling. The spin has a speed which can be controlled by throttling it. We can be speed up and down to our own needs. It would require us to act correctly under necessity itself, and then to overcome it.
We previously talked about RapidAPI’s predictability and customer satisfaction, and that the path towards it goes through ownership of products. As such that a single product could be entirely developed end-to-end by a single team. To do so, an organizational Change was needed. Once team and ownership borders were set, it required us to minimize the frictions which led to delays in delivery. But there was this little tiny tiny problem – the system’s architecture was preventing us from successfully doing so. 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 others outside our group. Their own priorities had delayed the review process. It easily taken a week or two for them to review and approve Changes. And the sudden move to remote working due to Covid-19 did not help this at all. This has deeply frustrated the Monetization team, as it was beyond their control. And my superiors were unhappy with the delivery delays the team had.
We needed to remove the technological dependencies that tightly coupled the various teams. Engineers from several groups worked hard to resolve this. They have created a new micro-frontend infrastructure to enable decoupling and hosting of smaller applications within bigger ones, a reverse dependency. Once done, the review process no longer required involvement by multiple teams. It had removed one major inefficiency.
As it is now possible, should all the 14 different products be migrated to the new infrastructure?
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. To minimize it as much as possible, would mean to migrate them all and as soon as possible. Which was our second option. 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.
The above timeline shows exactly one block of Change, the move 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 to throttle 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 fixing those instabilities, entail a Change. This is of a negative value. Mostly external one to the customer, but also internally 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 which leads to produce no-value, by doing so 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. Which leads to non-beneficial results.
So, if there was no value in migrating the second product, why did we migrate the first one? We did so before it was expected to Change and because it was expected to Change. Throttling is not always a question of when, it’s also a question of before what.
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 our Velocity and the Spin would result in a bad customer experience.
We though that if we’re already about to throttle The Wheel of Change, we’d better make sure we can stay on it. It was exactly why it was the right time to remove our delivery’s Inefficiency. It was clear that the effort invested was guaranteed to be valuable, as right after setting up the new infrastructure actual time 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, our delivery Bottleneck had indeed opened up. 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 led to other kinds of troubles. It also opened up the possibility to keep up with next year’s Roadmap, one of full new products and Changes.
The Wheel of Change kept on spinning, but unlike before it generated mostly positive values. It’s throttling was not out of inertia, but out focusing on creating external customer value. And we kept on controlling the throttle by migrating on-demand.
A few weeks afterwards a major shift had happened. RapidAPI had 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, at least for a while longer.
By the time I left RapidAPI we’d moved only 3 products out of 14. If the job was to move all the products, we did not get the job done. If the job was to get the right job done, we 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.