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.
