Ask who hurts

The ticket says Add bulk edit to the user admin screen. It was filed by Dan, who manages your team. It has acceptance criteria, a medium priority, and a link to a design.

Dan does not want bulk edit. Dan has never opened the user admin screen. He heard it in a planning meeting from Priya, who runs ops, who was passing on a complaint from Marta in finance, who spends Thursday mornings changing cost centres for about three hundred people, one row at a time, from a spreadsheet that payroll emails her.

Marta is the only person in that chain whose week is actually worse. She has never seen the ticket.

The name on a request is a relay address

This is not incompetence, it is how organisations move information. Managers forward, product consolidates, support summarises, and every hop strips out the specifics because the specifics are not what the next person needs to hear.

What survives is a solution, because a solution is compact and easy to relay. Bulk edit travels well. I get a spreadsheet on Thursdays and have to reconcile it against a system that will not let me paste does not travel at all, so by the time it reaches you it has been compressed into a feature request that fits in a title field.

The result is that you can build exactly what was asked for, ship it, and not help anybody. Bulk edit would let Marta make three hundred changes in one screen instead of three hundred screens. It would not tell her which three hundred, which is the part that actually takes the morning.

The move

Trace the request one hop upstream, until you reach someone whose own week is worse, and go and talk to that person.

The test that tells you when to stop

You have found them when you can do three things.

Name them. Not “finance”, not “the ops team”. A human with a first name who exists.

Say what they do instead today. The workaround, the manual step, the thing that fills the Thursday. If you cannot describe what currently happens, you are describing a wish rather than a problem.

Reach them without asking permission. If getting to this person requires a meeting request routed through two managers, you have found a stakeholder, not a sufferer. Sufferers are usually easy to reach, because nobody protects the calendar of the person doing the annoying job.

Fail any of the three and you have stopped one hop too early.

THE TICKET                      ONE HOP AT A TIME

  ENG-4417                        filed by      Dan, eng manager
  "Add bulk edit to                              heard it in planning
   user admin"                    relayed by    Priya, ops lead
  filed by Dan                                   summarising a complaint
  priority: medium                originated    Marta, finance
                                   with          Thursday mornings, ~300
  acceptance criteria                            cost centres, one at a time,
   - multi-select rows                           against a spreadsheet
   - edit selected                               payroll emails her
   - confirm dialog
                                 can I name her?          yes
  three named people             what does she do today?  the spreadsheet
  between you and                can I reach her?         she sits upstairs
  anyone in pain
                                 -> now go and watch a Thursday

Why this is your job now, specifically

The uncomfortable version of this argument is that the part of your job that was safe to skip has changed.

When implementing the ticket was most of the work, taking it at face value was defensible. Somebody senior had presumably done the thinking, and your contribution was the part they could not do. That trade has moved. Hiring managers surveyed by The Pragmatic Engineer in 2026 named product engineers, people who combine building ability with design sensibility and judgment, as the role they cannot find. DORA’s 2025 research names user-centric focus among the small set of capabilities that determine whether AI adoption actually helps a team.

Neither of those is a claim that this technique is proven to produce better products. I am not going to pretend that evidence exists. What they establish is direction: the scarce thing is no longer the implementation.

What it costs

It is socially awkward, every time. Going around Dan to talk to Marta can read as going over Dan. Mostly it does not, if you tell him you are doing it and why, but occasionally you will work somewhere it does, and that is real information about where you work.

It slows the start. You will spend half a day on a ticket you could have started immediately, and sometimes the answer will be that the original request was right all along. That happens. It is still cheaper than three weeks of building the wrong thing carefully.

And you will not always be allowed. Some organisations genuinely cannot let engineers talk to users, usually for reasons involving regulation or a very large customer. In that case, get one hop closer than you are now. Support is closer than product. Product is closer than a ticket.

Try this week

Take the ticket at the top of your board and write the chain of names on a piece of paper. Who filed it. Who told them. Who told them.

Most chains are two or three long and you can usually reconstruct them by asking one question in Slack: who originally ran into this?

Then send that person a message that is not a meeting request:

Hi Marta, I’m picking up the bulk edit thing. Before I build anything, could I watch you do the Thursday update once? Twenty minutes, no prep, I just want to see what actually happens.

Watch what she does before she gets to the screen you were going to change. That is usually where the real work is, and it is never in the ticket.