Urgency is a privilege for well-run teams

It’s a weird time in the tech industry, and if you’ve been in the industry long enough you’ve likely experienced an economic downturn or a company under financial crisis. Consequently there have been a few moments in my career where I’ve heard leaders plead with engineering teams to “act with urgency.”

In his book “The Hard Thing About Hard Things,” ¹ Ben Horowitz (of Andreessen Horowitz) articulates the dichotomy in a startup CEO’s behavior in favorable vs. unfavorable business conditions as “peacetime” vs “wartime”: Peacetime CEO/Wartime CEO. I think it’s reasonable to say that as a result of economic conditions that were extremely favorable to the tech industry ² over the last decade+, most of our collective memory lives in peacetime. But as a result of rising interest rates, declining post-COVID growth numbers, the rise of LLMs and increasingly expensive lock-in to publicly-traded SaaS vendors, peacetime is becoming less peaceful. Every new layoff announcement mentions renewed investments in efficiency and execution, and the market demands both growth and revenue.

As an IC, each time I heard this request I didn’t understand what the expectations were in terms of changing my behavior. Create more tickets? Have fewer meetings? Work more hours? It didn’t feel like any of these activities would actually contribute to stronger outcomes, and engaging in productivity theater is extremely demoralizing. It also doesn’t take many long nights or weekend hours to breed irreparable burnout. Consequently the prevailing sentiment myself and many of my peers felt was panic. And panic is a terrible state of mind for timely, strategic execution.

The plea to “act with urgency” would have probably been more precisely phrased as “ship more code,” and it felt like it carried a veiled permission to eschew typical process and bureaucracy to unlock everyone’s inner Herculean effort to turn the ship around. And to be fair this advice probably makes sense at startups or small companies that are often built by individual Herculean efforts. But at mid-to-large sized companies operating within complex and intertwined systems, engineers frantically committing code without coordination or planning ultimately generates more problems than it solves. There is a tremendous amount of required context to keep these systems running beyond the obvious, happy path.

Requests for things like “urgency” often fall flat because they don’t speak to the actual barriers of what makes outcomes fast or slow. These include poorly defined or changing product requirements, too much cross-team collaboration, a developer experience with slow feedback loops, etc. It’s rarely raw effort, but it’s an easy scapegoat.

In my experience the ability of teams to execute in wartime is a function of their diligence in peacetime. Some thoughts about teams, their construction, and the potential to increase pace:

To ship faster, you must ship in the first place.

A common scenario: a team in a critical but stable path doesn’t have a track record of shipping regularly. Due to nascent/favorable business conditions it never mattered much - the business grew regardless of what was (and was not) shipped. Suddenly business conditions change and the team faces pressure to execute work quickly. But because they don’t already have the process or norms to define and execute work, they struggle to fulfill their new mandate and chaos ensues.

The most important indicator of team health is shipping regularly. And getting a team to the point where they ship regularly is the long game of clear product direction, process buy-in, and discipline. An urgency mandate reduces these mechanics to a switch, and I’ve yet to witness a team suddenly “turn on” performance when they didn’t already have a track record of it.

My suggestion for managers is to always take team culture and performance seriously, and promptly address issues as they arise during peacetime.

One way I’ve seen this blow up is the case of the toxic or underperforming teammate. Negative performance conversations are one of the most confrontational and uncomfortable parts about a manager’s job, and when you add on legal considerations (documentation, performance improvement plans, etc) they can be a tremendous investment of time. It’s often tempting for managers to work around or even ignore these problems rather than address them.

In peacetime they might be able to put this person on a secondary project, limit their involvement in certain meetings, or cover for their failures with additional staffing (these are all smells!). But a situation of urgency and rapidly changing headcount will throw oils on these fires, and issues that were once an inconvenient but tolerable disturbance will suddenly become a threat to the rest of the team’s continued employment. The last place any employee wants to be is on a team with a reputation of poor output or toxicity when the business is critically analyzing its costs.

The Mythical Man Month is much less painful for teams who have a defined onboarding process.

Declarations of urgency often precede a re-org where coworkers are moved from lower to higher priority workstreams. Teams in critical paths can suddenly find themselves with new headcount in an effort to increase development speed, which is in stark contrast to the Mythical Man Month (MMM).

This is a tough scenario for a few reasons. In terms of output, the MMM is very real - building shared context takes time and is inevitably a cost to short term productivity. In terms of people, the worst side effect of re-orgs is the loss of managerial career context. Peacetime investment in onboarding process helps mitigate both. Some guiding questions:

• Is there an up-to-date onboarding document that is as self-service as possible?
• Does your team write documentation around its ownership and ceremony?
• Is there a defined backlog of work with new-hire tasks already allocated?
• Are you performing 1:1:1 manager handoffs between the new manager, old manager, and the transferee to ensure they can advocate for themselves and maintain career context in their new role?

Going faster forces intentional tradeoffs about risk. Ensure those are well understood!

A team’s output speed is bottlenecked by getting defined, prioritized work into the hands of ICs as fast as possible. This process is often slow because understanding priority requires a lot of inputs.

The stages of a software planning process exist to ensure your team is building the most important thing despite a universe of competing priorities and constraints. User Research validates customer assumptions, A/B testing validates product and technical assumptions, test plans validate resiliency assumptions… these are all valuable guardrails that take time to mature.

One of the main levers for increasing output speed to remove some of these guardrails. Maybe you engage in fewer customer interviews when performing product discovery. Maybe you ship something to production with a weaker QA pass. You likely need to cut some product and technical scope.

In an environment where you are suddenly prioritizing delivery speed over confidence, make sure these tradeoffs are well understood by all. I recommend writing the decisions and impacts into a document, and aligning on them upward and with product / engineering / design leadership. Situations demanding urgency are often emotionally heightened, but there is a very real opportunity cost to eliminating guardrails. You want to take steps to avoid a situation where you cut scope in service of pace, consequently delivered the wrong thing, and can’t explain how and why you got there.

In summary I’ll borrow another phrase from The Hard Thing About Hard Things: “there are no silver bullets, only lead bullets.” Appealing to effort feels like grasping for a silver bullet when only the lead bullets of well-oiled process are relevant. Going faster is an optimization over existing performance. As a manager/manager of managers, if you’re only concerned with team pace and execution during wartime, you’re probably too late.

Footnotes