In the previous chapter, we’ve seen that one key for a successful throttle/spin control over The Wheel of Change is timing and value. And they are intertwined. Good timing is knowing when the exact time is to do a Change. And it relies on having a clear expected value. But only when the Change is done, the actual value presents itself. From the moment of initiation to the moment of completion, we go through a process or fruition which ends with the actual value. The actual value and the expected will probably differ, but they also differ because of the duration of the fruition process.
In the previous chapter, we decided at RapidAPI to create the new infrastructure only when we had a clear expected value. Only when actual delivered time is guaranteed to be saved. Not before that, and that’s good timing. But it was also good timing because we knew that the duration of fruition would be short. We knew that two weeks after the infra was ready, we’ll see the actual value. As fruition was correctly predicted and estimated, it was part of the expected value and had affected it. Thus differing less from the actual value at the end of the fruition process.
In this chapter we’ll see how long, delayed or complicated fruition processes affect the actual value, and differs it away from the expected value.
Ellah, one of the team members at RapidAPI, had worked hard for about two weeks on a new feature. She was congratulated on her hard work delivering on time – but no more than that. We’ve heard nothing from our PMs or our customers about it. Two weeks later we found out that our PMs forgot to switch on the feature flag. It wasn’t the first time. Delayed, but eventually we got amazing Feedback from our customers, but for Ellah it was too late. “It was a long time ago”, said quite miserably, “I’ve moved on to something else. I really don’t care about this feature anymore”.
So even with a significant external actual value, for her it was non-existent. She can no longer perceive it. When it comes to motivation, people need a sense of achievement and impact. A long fruition process dissipates those. A good reason to consider the fruition duration to be a short one. To celebrate wins instead of missing them. Instead of me, as Ellah’s manager, who now needs to put her shields up again and convince her to stay.
Indirect External Value
There are some Changes that have no direct value, but maybe have an indirect one. For example, a new customer facing feature that requires a new database. The first one is of external customer value, and the second one has no value on its own. It only enables the first. So only when the feature would be fully accepted and appreciated by the customer, the value of the database would come to fruition.
Let’s presume it takes two different engineers to get it done. The database would be delivered by the backend engineer, and the customer facing feature by the frontend engineer. While the database was delivered on time within two weeks, the frontend was delivered as expected within two months. And the fruition process ended with a big win for the company. For the front-end engineer that would be a cause for celebration. For the backend, due to the long fruition process, it might be “I’ve moved on to something else. I really don’t care about this feature anymore”. If it were shorter, in the backend engineer’s mind he would still have a reason to celebrate as he was still a part of it.
Let’s now presume that one engineer can do both. He had delivered the database on time and it’s external value is currently undefined. It’s internal value is positive because it has indeed enabled the feature. Once the feature was delivered, the Feedback received was bad. Turns out no one uses it. The fruition process ended with zero external value. Although an internal value was gained, the engineer would go and say “that was a waste of time”. Big losses, covers small wins.
As every Change has the potential to cause Instability, some Changes would result with a negative value. Some are inevitable when we wish to gain value. Small losses need to be covered by big wins. Such was not so much the case with RapidAPI’s message handling infrastructure migration to V2, due to a complicated and long fruition process.
The migration required every group and team to migrate each of its handlers. At first, it was done quickly. But as company priorities changed (which happens), the migration rate declined. Thus the fruition process took longer and longer.
More than that, some of these handlers were 3-5 years old. Specifically those of the Monetization team. And unfortunately, the company was not prepared for the inevitability of engineers being long gone. There were no product requirements or technical specs to work with. The fruition of a single migrated message handler was expected to end with no external value, as it is migrated as-is. It didn’t take long to migrate, but as we were in the dark of a Legacy-evolved code, we had caused harm to our customers. So after migrating one, all the Monetization team was left with is the harm done. Negative value.
The fruition of the entire migration would be celebrated by another team, as it is owned by another team. But the fruition process continues as long as some message handlers remain on V1. Until it is deprecated, maintenance of two infrastructures is required. Negative internal values would be accumulated until then.
When I joined the company, the process was five months in. As we already learned, five months is already too long for anyone on the Monetization team to celebrate. When I left the company, due to priority changes, the process was 18 months in and was not over. When the day of fruition comes, would anyone celebrate it? Would there be some value remaining to celebrate?