In the previous chapter, we’ve seen that timing and value is a key for a successful throttle/spin control over The Wheel of Change. Good timing is knowing when the exact time is to do a Change, and it relies on having a clear expected value. The two are intertwined, 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 due to the duration of the fruition process.
As told in the previous chapter, at RapidAPI we decided to move to a new micro-frontend infrastructure. We did so only when it had a clear expected value, only when an actual delivery time is guaranteed to be shortened. That is good timing, because we also knew the duration of the fruition. Two weeks, and we’ll see the infra’s actual value. Predicting and estimating the duration of fruition was done prior to execution, thus is was part of the expected value and had affected it. The actual value surfaced only at the end, two weeks later, and had barely differed from the expected one.
In this chapter we’ll examine the results of long, delayed and complicated fruition processes. How drifts are created between the expected values and the actual ones.
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, delivered 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 turn on the feature flag. It wasn’t the first time. Although delayed, but we eventually got amazing Feedback from our customers.
Unfortunately, for Ellah it was too late. “It was a long time ago”, she said quite miserably, “I’ve moved on to something else. I really don’t care about this feature anymore”. She was no longer capable of perceiving the value. Even with a significant external actual value, for her it was already non-existent.
When it comes to motivation, people need a sense of achievement and impact. A long fruition process dissipates those. A good reason to for the fruition duration to be a short one. To celebrate wins instead of missing out out on them. It would have saved me the trouble as Ellah’s manager, to put her shields up again and convince her to stay.
Indirect External Value
Some Changes do not have a 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 indeed delivered on time within two weeks, the frontend was delivered as expected within two months. The fruition process ended with a big win for the company.
For the front-end engineer it 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, a reason to celebrate would have remained in the backend engineer’s mind. The engineer would have not forgotten he was part of the effort celebrated.
Let’s consider an alternative result, where after 2 months the Feedback received was bad. The fruition process ended with zero external value. On the contrary, launching the database had some internal value. Although enabling a potential value to surface, the backend engineer would go and say “that was a waste of time”. Big losses, covers small wins.
Such was not the case with a long and complicated fruition process at RapidAPI’s, of migrating message handlers to a new infrastructure. It required every 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 those handlers were 3-5 years old. Specifically those of the Monetization team. And unfortunately, their owners were long gone by now. Neither product requirements nor technical specs were available. As each was migrated as-is, any migration could not have ended with an external value. 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. All the Monetization team was left with was the harm done. Only negative values.
There was nothing to celebrate but the fruition of the entire migration. Which would be done by another team, once the previous infra would be deprecated. But as long as some message handlers remain on it, maintaining two sets of infrastructures is required. As long as the fruition process continues, negative internal values are accumulated.
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. Due to priority changes, the process was 18 months in when I left the company, and was not over. When the day of fruition comes, would anyone celebrate it? Would there be any value to celebrate?