Pressure Without a Plan.
When we launched Digg v4, the old site turned off, but the new site didn’t turn on. There was a lot of pressure to get things working, but no one knew what to do about it. It took almost a month to get it wholly functioning. It was not a pleasant month, with many false starts while we tried to dig out of launching an unfinished, desperate product.
That launch was a foundational early career experience for me. However, it was not a unique one, as many leaders inject that sort of pressure into their teams as a routine management technique. Some examples of the pressure without a plan pattern that I’ve seen:
The aforementioned Digg V4 launch was pressure without a plan in two ways. First, a fixed launch date was set to motivate engineering, but we had no clear mechanism to launch on that date. Fixing things after the launch was pressure without a plan as well.
Uber’s service migration had a well-defined platform as the destination for things removed from the Python monolith, but initially did not have a clear plan for leaving the monolith other than escaping the top-down pressure.
Pressure without a plan is almost the defining characteristic of 2010s era service decomposition projects. Calm and Carta’s initial approaches had some elements of this as well, which is why I ended up quickly pausing both after joining.
Metrics-only AI adoption at many companies falls into this bucket, with a focus on chiding non-participation without understanding the reasons behind the non-participation. (At Imprint, we’ve tried hard to go the other direction.)
Pressure itself is often useful, but pressure without a plan is chaos, unless your team has an internal leader who knows how to reshape that energy into pressure with a plan. Your aspiration as a leader should be to figure out how to become that internal leader.
Being that person is not only the best way to help your team succeed (convincing folks who love “pressure without a plan” not to use it is… hard), it’s also some of the most interesting work out there. Crafting Engineering Strategy’s chapter on strategy testing is my approach to iteratively refining a plan before committing to its success, and how I’ve learned to turn “pressure without a plan” into a situation that makes sense.
As an ending aside, I think the origin of this pattern is the misapplication of management by objectives. The theory of management by objectives is that the executing team is involved in both defining the goal and the implementation. That sounds good, almost what Escaping the Build Trap recommends. However, in practice it’s very common to see executives set targets, and then manage a low-agency team to hit those goals which the team believes are impossible, which leads very precisely to the “pressure without a plan” pattern.