Building a Usable Process for Humans

How can a TPM build a process that saves time, generates metrics, and gets results?

We’ve all suffered through a process only one person understands, that takes half a day to do something simple, that requires all the planets to align — the one you rarely touch, and whose owner ends up fixing your mistakes anyway.

Why do repeatable things have to be this hard? Sometimes it’s compliance or scale. Sometimes it’s just a bad process. Let’s talk about the latter.

I’ve spent years designing processes for salespeople and software engineers — about as different as two groups get, except for one thing: they’re both at the company to do something else, something that (stereotypically) actually brings them joy, and they both hate a process.

But sometimes you need one.

I was tasked with designing, implementing, and supporting how a software company triaged customer-reported bugs. We had SLAs to hit. Customer Support was worn down by frustrated customers; Engineering was worn down by having to context-switch between features and bug triage. Over 1,000 bugs sat unaddressed, and we needed zero bugs older than seven days.

The process itself: Support logs the bug, an engineering director routes it, and the engineering team responds with an assessment — “working as expected,” “can’t recreate,” “yep, that’s broken.” What happens next depends on the assessment. I’ll skip the mechanics and focus on the principles that made it work.

1. Individuals and interactions over processes and tools

If you’re into Agile, you know this one. A process exists to make things easier for the people doing the work, not harder. Support needs to talk intelligently to frustrated customers and gather the right information; Engineering needs to triage without losing its week to it. Ask who benefits, and how — then build the process around their actual answers: what they need to know, how much time they have, and what success looks like to them.

2. Eliminate waste, make the right way the easy way

If you’re into Lean, this one’s yours. Engineers might touch this process once a week for 30 minutes — 1/80th of their time — so don’t expect them to remember 50 complicated steps and read your beautiful manual. Gather just enough data that Support doesn’t waste time and Engineering has what it needs. Once it’s with the engineer, minimize the back-and-forth. Keep statuses simple, automate the routing, and give stakeholders exactly what they need to make capacity and priority calls — nothing more.

3. Have a champion or two, and iterate

Build the process with one or two people from each group — they’re your champions. Run it through a few low-risk iterations, take their feedback seriously, and don’t extend it to everyone else until your champions are actually comfortable with it. Direct feedback from real users is gold.

4. Establish measurement up front

Triaging bugs in under seven days was the headline goal, but we also set targets like: no more than five minutes reviewing bugs in the weekly leadership meeting, no more than 30 minutes of triage per engineering lead per week, and bugs missing information get routed straight back to Support.

5. Drip in the solution

Start simple, ship it, get feedback, adjust, repeat. Every change should be small enough that it’s expected and easy for people to absorb.

6. Keep it going, and support it

Keep “eliminate waste” and “people over tools” front and center so the process scales without becoming a burden — especially for the new people who’ll inherit it after you. Your job doesn’t end at launch; it includes maintenance, curation, and staying curious.

We landed at a steady sub-seven-day triage rate. Engineering managers knew exactly what to do each week and could repeat it in under 30 minutes. Support could get clarification straight from customers. Leadership reviewed dashboards in under five minutes at the weekly meeting, and high-priority fixes made it into team backlogs.

If six guidelines are too many to remember, just remember this: make the right way the easy way.*

*I learned “make the right way the easy way” from a few DevOps and Reliability engineers. It’s a good one.