Triage is a Skill

Res Extensa #42 :: Training your attention when everything seems important

When we think of triage, our minds often drift to the medical definition: the prioritization of patients in an order of treatment that maximizes survival. On a battlefield, medics are on a mission to minimize the overall casualty count. The need for attention overwhelms the available resources to treat everyone.

So, how does the concept of triage apply in the business context?

Here I'd adapt the definition slightly:

The assigning of priority order to projects on the basis of where funds and other resources can be best used, are most needed, or are most likely to achieve success

Most working environments aren’t, of course, as dangerous as a battlefield, but we can apply similar guiding principles.

Every team I've worked with has a years-long queue of ideas. The backlog or "someday maybe" list would need 10x the available resources to work completely through, so a major aspect of the workload is to sort the wheat from the chaff.

"Attention triage" is a skill — one that applies to every job, particularly those where the possible things to work on far outnumber the available resources or time to do them. Being forced to ration out limited resources trains your Triage Processing Engine to make decisions. Building anything is an exercise in triage.

In the realm of knowledge work, attention is our most scarce and precious resource. We should treat triage as a core skill to develop and sharpen, like any other tool in the repertoire.

All decisions have costs

Choosing where to direct attention requires a swift evaluation of the tasks you're sidelining. If you’ve ever worked with someone that has a good nose for triaging their time, you’ll see this process-of-elimination happen instantaneously. They've developed a knack for tunneling in on the most important pieces.

Opportunity cost is omnipresent, unavoidable. Each time you choose a starting point or a next action on a project, or the next feature to build, you’re implicitly deciding that others are less important, too hard, too expensive, et cetera.

One tactic that helps is to make our omissions explicit. Instead of writing down the reasons a particular thing needs doing, spend more time on the reasons it doesn't. It's too easy to come up with reasons in favor of something. And when we do that with a big list of items, it's hard not to keep those things hanging around, living rent-free in our heads while we’re trying to move forward — the nagging nice-to-haves that of course would be the "right" way to do it, but each little detail slows the train.

I’ve also been on teams where we’ve over-indexed on opportunity cost, worrying ourselves to the point of paralysis. We analyzed all possible pathways for so long that precious time evaporated while we sought the optimal route.

This is a key to effective triage: the ability to measure your opportunity costs quickly and largely through pattern recognition.

Strong vs. weak teams

Strong teams are highly motivated by progress — by a desire to see, show, or explain the path traveled. In order to do this, they need to remove the extraneous distractions. This doesn’t mean they’ll never pursue a path that doesn’t work out. On the contrary: they just pursue many many paths for the shortest possible time required to determine they won’t work. It’s the nature of trial and error. A natural element of progress is rapid iteration to find the right stepping stones.

Strong teams are also time-box, with calendar milestones to zero in on. When locked in on a fixed future point, they use the time-honored engineering philosophy of “ya ain’t gonna need it” (YAGNI) as they’re choosing tools and techniques. This keeps the work lean and removes distractions. Instead of including a new framework only to use 2% of it (even though it might be a “best practice”), they write their own function to do what they need and move on. Yeah, maybe the “right way” is to use an existing library, or to build an abstraction. But much of the time those things are diversions where the ROI is years away, if it's there at all.

Weak teams, on the other hand, don’t set hard boundaries for work (or they make excuses for why they need to move them when they get close). They allow “found work” along the way to distract them from the end objective. “This might be a good time to refactor this module”, or “we should think about making this a reusable library” are things you might hear. Those ideas aren’t negative in the absolute; there’s a time and place to pursue them. But if you’ve set hard boundaries and clear objectives, those should be your guiding rails to stay within.

The role of experience

When given a new challenging problem, an experienced pro with a knack for triage will drill right into the most sensitive and painful parts of a requirements list. Since they've been through the ringer before, they have an intuition for what the likely snags will be. When you lay the requirements out on the table, often times the thing that'll trip you up, explode the scope, or be just damn hard to get done doesn't look that thorny or complex on paper...

Experience is an invaluable contributor to making rapid-but-reasoned decisions.

Like any skill, attention management can be honed through deliberate practice. Put in the reps to block out tasks, ship imperfect work, and through trial and error you'll accumulate the experience to recognize familiar patterns. Experience is the process of hitting milestones imperfectly and making adjustments along the way.

Baseball players take thousands of pitches before they recognize what they can and can't hit. The more pitches you see, the better your muscles adapt to swinging at the right ones.