Generated and suppressed demand. | Irrational Exuberance
Eight years ago, I wrote about my theory of restoring struggling teams,<br>which came down to four steps:<br>A team is falling behind if each week their backlog is longer than the week before.<br>Solve by hiring more.<br>A team is treading water if they’re able to get their critical work done, but are not able to start paying down technical debt or start major new projects.<br>Solve by reducing work-in-progress.<br>A team is repaying debt when they’re able to start paying down technical debt, but progress still feels slow.<br>Solve by staying the course: it’s actually working, you just have to keep the faith until you finish digging out.<br>A team is innovating when their technical debt is sustainably low, morale is high, and the majority of work is satisfying new user needs.<br>There’s nothing left to solve, at this point.<br>Even now, I find this mental model extremely valuable, but I do think it is missing one interesting<br>nuance that I’ve seen many teams run into in high-growth environments: suppressed and generated demand.<br>Suppressed demand is the idea of incoming work that isn’t incoming, because teams stop asking you for help.<br>Generated demand is when an increasingly effective team’s progress is noticed, and the previously<br>suppressed demand is converted into actual demand.
The consequence of generated demand is that a team that was struggling can successfully recover,<br>work through much of its backlog, and then shortly thereafter be just as far underwater as they were at their worst.<br>This is a very disorienting experience, and even a demoralizing one. The team has done everything right,<br>shipped a bunch of genuinely valuable work, and are nonetheless just as far underwater as they were before.<br>To give a concrete example, our Customer Operations Engineering team didn’t exist a year ago,<br>and instead we invested in customer operations engineering tasks by prioritizing them into<br>a larger team’s tasks. This often meant we had very valuable projects that didn’t get staffed.<br>We then split it out into its own team, launching a number of projects like reworking our internal<br>customer operations tooling and integrating Sierra for our IVR, both of which worked out quite well.<br>As a result of working out well, there are far more requests for work. Despite accomplishing so much,<br>the team is even further behind on the incoming requests than they were a year ago, when they had<br>shipped relatively little and had relatively little capacity to ship more.<br>Unfortunately, the solution here is not particularly novel: you have to run through the cycle again.<br>And potentially a third time. And potentially a fourth time. You just have to keep running through<br>it until you’ve surfaced the entire backlog of suppressed demand.<br>This is very similar to the problem of latent incidents which cause<br>effective reliability programs to look like they’re failing as they drain the stock of previously<br>created latent incidents. Sometimes you’re doing the right thing, and it just takes a while<br>to work. Your challenge in that moment is building conviction that you are indeed doing the<br>right thing, and convincing your team and leadership of that as well.<br>Finally, it’s interesting to attempt to predict which teams are, and which aren’t, sitting<br>on top of a backlog of suppressed demand. Some teams run through the recovery cycle, and<br>find that there simply isn’t much else to do. These tend to be teams with very narrow interfaces,<br>for example a team whose job is providing internal queues probably won’t have much generated<br>demand after clearing the initial backlog. Teams with broad interfaces, like customer operations<br>or developer experience, are generally sitting on an incredibly large, albeit currently invisible,<br>backlog of suppressed work.
Hi folks. I'm Will Larson.<br>If you're looking to reach out to me, here are ways I help.<br>Books<br>I wrote<br>An Elegant Puzzle,<br>Staff Engineer,<br>The Engineering Executive's Primer, and<br>Crafting Engineering Strategy.
Newsletter<br>If you'd like to get get updates, subscribe for weekly emails, or follow my RSS feed.
Popular<br>Building internal agents<br>"Good engineering management" is a fad<br>Moving from an orchestration-heavy to leadership-heavy management role.<br>Eng org seniority-mix model.<br>How to create software quality.
Recent<br>Generated and suppressed demand.<br>Make no assumptions.<br>Revised rules of engineering leadership.<br>Early and late-stage hypergrowth.<br>Agents as scaffolding for recurring tasks.
Related<br>Make no assumptions.<br>Revised rules of engineering leadership.<br>Early and late-stage hypergrowth.<br>Judgment and creativity are all you need.<br>Should you include engineers in your leadership meetings?