Generated and suppressed demand. | Irrational Exuberance

Eight years in the past, I wrote about my theory of restoring struggling teams,
which got here right down to 4 steps:

1. A workforce is falling behind if every week their backlog is longer than the week earlier than.
   Solve by hiring extra.
2. A workforce is treading water in the event that they’re in a position to get their vital work carried out, however will not be in a position to begin paying down technical debt or begin main new initiatives.
   Solve by decreasing work-in-progress.
3. A workforce is repaying debt once they’re in a position to begin paying down technical debt, however progress nonetheless feels gradual.
   Solve by staying the course: it’s truly working, you simply must preserve the religion till you end digging out.
4. A workforce is innovating when their technical debt is sustainably low, morale is excessive, and nearly all of work is satisfying new consumer wants.
   There’s nothing left to unravel, at this level.

Even now, I discover this psychological mannequin extraordinarily beneficial, however I do assume it’s lacking one attention-grabbing
nuance that I’ve seen many groups run into in high-growth environments: suppressed and generated demand.
Suppressed demand is the thought of incoming work that isn’t incoming, as a result of groups cease asking you for assist.
Generated demand is when an more and more efficient workforce’s progress is observed, and the beforehand
suppressed demand is transformed into precise demand.

The consequence of generated demand is {that a} workforce that was struggling can efficiently get better,
work by way of a lot of its backlog, after which shortly thereafter be simply as far underwater as they have been at their worst.
This is a really disorienting expertise, and even a demoralizing one. The workforce has carried out every thing proper,
shipped a bunch of genuinely beneficial work, and are nonetheless simply as far underwater as they have been earlier than.

To give a concrete instance, our Customer Operations Engineering workforce didn’t exist a 12 months in the past,
and as a substitute we invested in buyer operations engineering duties by prioritizing them into
a bigger workforce’s duties. This typically meant we had very beneficial initiatives that didn’t get staffed.
We then cut up it out into its personal workforce, launching a lot of initiatives like transforming our inside
buyer operations tooling and integrating Sierra for our IVR, each of which labored out fairly effectively.
As a results of understanding effectively, there are much more requests for work. Despite undertaking a lot,
the workforce is even additional behind on the incoming requests than they have been a 12 months in the past, once they had
shipped comparatively little and had comparatively little capability to ship extra.

Unfortunately, the answer right here just isn’t notably novel: you need to run by way of the cycle once more.
And doubtlessly a 3rd time. And doubtlessly a fourth time. You simply must preserve working by way of
it till you’ve surfaced all the backlog of suppressed demand.
This is similar to the issue of latent incidents which trigger
efficient reliability applications to appear like they’re failing as they drain the inventory of beforehand
created latent incidents. Sometimes you’re doing the appropriate factor, and it simply takes some time
to work. Your problem in that second is constructing conviction that you’re certainly doing the
proper factor, and convincing your workforce and management of that as effectively.

Finally, it’s attention-grabbing to try to foretell which groups are, and which aren’t, sitting
on high of a backlog of suppressed demand. Some groups run by way of the restoration cycle, and
discover that there merely isn’t a lot else to do. These are typically groups with very slim interfaces,
for instance a workforce whose job is offering inside queues most likely gained’t have a lot generated
demand after clearing the preliminary backlog. Teams with broad interfaces, like buyer operations
or developer expertise, are usually sitting on an extremely massive, albeit presently invisible,
backlog of suppressed work.