Know who the work is for

4 hours ago

3 min read

Updated: 4 hours ago

Why engineers who can name the business outcome make better calls, and how technology leaders build that knowledge

An engineer who knows what the company is trying to do, and who the work reaches, makes better decisions without being told. Strategy decks don’t build that knowledge. Stories do, along with a few habits that keep the business in front of the team. It matters more now that AI writes a growing share of the code, because judgment about what matters is the part of the job the tools can’t supply.

One question changed how an infrastructure team planned outages

Years ago I was brought in to rebuild the commercial technology organization at a power company that had just come out of bankruptcy. The infrastructure team had little sense of how its day-to-day work affected people outside the company, and systems and the network sometimes went down for maintenance with little or no notice.

At that company, the network wasn’t an internal convenience. The power plants depended on it to know how much power to generate. Drop it at the wrong moment and plants could fall short, and on a Texas summer afternoon that means homes without air conditioning, with the most vulnerable people at real risk.

I asked the team who had grandparents living in or near Dallas. Several hands went up. I walked them through it: take the network down without enough planning, and the north Texas plants lose the connection that tells them how much to generate. Local outages follow, and their grandparents sit at home in the hottest part of the summer with no air conditioning. Then I asked them to plan the next window properly.

It was heavy-handed, and it worked. Unplanned and poorly planned outages stopped. No new rule went out. The team had seen who was on the other end of the network, and that was enough.

Knowing the story sounds different at each level

At every level, knowing the story shows up as a reason attached to the work.

An engineer can say what the current task is for: “I’m getting checkout in the mobile app under 30 seconds, because faster orders raise volume, and volume is how we hit this year’s sales plan.”

A team lead uses the story to decide what gives when capacity drops: “Saved carts can wait a sprint. The checkout work can’t, because the sales plan depends on it.”

A director uses it to fund bets and argue against them in the business’s terms: “We shouldn’t build our own search this year. It won’t move order volume, and checkout will.”

In large organizations, most engineers can’t give the first of these answers. The gap is expensive. An engineer without the reason builds what the ticket says, and the ticket is rarely the whole story.

AI makes context the engineer’s main contribution

On the teams I work with, coding assistants now write much of the first draft. The tools don’t know that the network feeds the power plants or that the order flow funds the sales plan.

Say a ticket asks for address validation at checkout. An assistant will produce a clean validation step with a confirmation screen, and it will meet the spec. It will also add seconds to a checkout the team is trying to get under 30. An engineer who knows the story catches that before it ships. An engineer who doesn’t ships it faster.

Three habits build the story into the team

Attach a result and a person to every piece of planned work. Each planned item names the business result it moves and the people it reaches. If nobody can name either, question the item before anyone builds it.

Put engineers near the people their systems serve. Ride-alongs with operators, shifts on the support queue, a seat on customer calls. An afternoon watching a dispatcher fight a tool teaches more than a quarter of requirements documents.

Retell the stories that matter. Turn incidents and wins into stories with the human consequence attached: who was affected, what it cost them, and what changed afterward. A leader who repeats those stories gives the team a shared sense of the stakes that onboarding material can’t.

Signs it’s working

Engineers raise business trade-offs before anyone asks.
Maintenance and incident plans name who is affected as well as which systems.
Fewer features ship as specified and then get reworked or go unused.
Asked what the company is trying to do this year and how their work moves it, engineers answer with results, not tasks. That is the engineer question in the one-week test from Fast, governed, or both.

Questions about building this into a team: dave@dave-nix.com