Motivation in agentic teams

Day 24: Where the Win Went. Motivation in Agentic Teams

Velocity is up and your 1:1s have gone quiet. If that describes your team since you adopted coding agents, you probably don't have a performance problem. The thing that used to make engineers feel good about their work has broken, and it won't repair itself. This lesson covers what broke, why the obvious fixes backfire, and how to give the win a new place to live.

The silent retro

It was a Friday retro after one of our highest-velocity sprints at PhoenixDX. The burndown on the screen was the cleanest we'd had all quarter. I opened the way I always do: 'What are you proud of this week?' Nobody answered for a while. Then one of our strongest engineers shrugged. 'Honestly? Nothing. Claude did it.' There was a short laugh, and nobody added anything. We moved to the next item because staying there felt awkward.

On the drive home it hit me that the metrics and the mood were moving in opposite directions, and I only had a dashboard for one of them. Every number I tracked said the team was doing great. The room was telling me something else.

The problem: the small win disappeared

The 'small win' is the moment something you've been fighting finally works. The test goes green after two hours. The race condition suddenly makes sense. The query drops from 4 seconds to 40 milliseconds. In my experience, that moment is one of the main things that keeps engineers going day to day. Teresa Amabile's research on the 'progress principle' backs this up: of everything that lifts people's emotions and motivation during a workday, the biggest factor is making progress in meaningful work. Coding agents didn't take the work away. They took away the moment where you could feel you'd done it. And because output went up, nobody noticed.

Look at the second loop. The work hasn't gone anywhere: framing, reviewing, deciding. But nothing in the loop marks a win, so it keeps running without paying anything back. A few weeks of that and you get the flatness senior ICs describe after a 'productive' week. They shipped a lot and felt none of it.

What I got wrong first

I tried the two obvious fixes first. You'll be tempted by them too, so here's how each one went wrong.

• ▹Fix 1: 'Take some tickets without the agent.' It felt like make-work, and everyone could tell. A win you manufacture by tying one hand behind your back doesn't feel like a win. It also sent the wrong message, that the real job is typing code, which is exactly what we were trying to get people to stop believing. Seniors found it patronising. Juniors assumed they were being tested.
• ▹Fix 2: 'Celebrate shipping more.' Hollow. Shipping volume was the very part people felt they hadn't done themselves, so praising output sounded to them like praising the agent. Picture congratulating someone on how fast their compiler is.
• ▹The mistake under both: each one still located the win in typing or output, and agents own that territory now. The old moment isn't coming back. The win needs a new home.

The reframe: ask what is still uniquely theirs

The question worth asking is this: when an agent writes most of the code, what are engineers still uniquely responsible for? Outcome ownership. In practice that comes down to four things:

• ▹Framing the problem. What are we actually solving, what's out of scope, and what does 'done' mean? In my experience a good problem brief improves agent output more than any prompt trick.
• ▹Choosing between options. The agent can lay out three approaches. A person still has to pick one and own the trade-off.
• ▹Catching what the agent got subtly wrong: the off-by-one at a pagination boundary, the retry that isn't idempotent, the test that passes because it asserts nothing.
• ▹Owning it in production. Your name is on the pager, and you're the one who explains what happened.

That's where the win moves. It builds on Day 23: ownership is about the outcome, not about who did the activity. At PhoenixDX we made it a rule. Credit goes to whoever owns the outcome, meaning the person who framed the problem, made the judgment call and stood behind the result. It doesn't go to whoever (or whatever) typed the code.

Three concrete changes we made

In an agentic team, motivation doesn't show up because you hope it will. You design it into your rituals. Here are the three we changed.

• ▹1. Retro prompt. 'What did you ship?' became 'What judgment call did you make this week that the agent couldn't?' The question points people at where their win now lives. Because they know it's coming on Friday, they start noticing those calls as they make them.
• ▹2. Demo credit. In demos, the owner presents the decision and the trade-off rather than the diff. Nobody scrolls through generated code. They walk through what they chose, what they rejected and why.
• ▹3. Catch log. This is a shared channel where people post agent mistakes they caught before production. We count these as wins, not chores, and a good catch gets the reaction a clever fix used to get.

## Friday retro (agentic version)
1. What judgment call did you make this week that the agent couldn't?
2. What did you decide NOT to build, and why?
3. Best catch of the week? (link from #catch-log)
4. Where did the agent waste your time? (process input, not blame)

## #catch-log post format
What the agent produced: retry wrapper around payment webhook handler
What was subtly wrong: retries were not idempotent -> double charge risk
How I caught it: asked 'what happens on the 2nd delivery?' during review
What it would have cost in prod: duplicate charges, manual refunds
Guardrail added: idempotency-key test + note in AGENTS.md

Pay attention to the last line of that format. Every catch should leave a guardrail behind: a test, a rule in your agent instructions file or an item on the review checklist. With a guardrail, the catch keeps protecting you after everyone has forgotten the save.

When to use this, and when not to

• ▹Use it when velocity is up and energy is down, when retros keep getting 'nothing much' answers, or when strong ICs describe their own work in the passive voice ('it got done').
• ▹Use it early. Changing a ritual costs almost nothing. Winning back an engineer who has quietly checked out costs a lot.
• ▹Don't use it to paper over real problems. If people are flat because they're overloaded or the roadmap makes no sense, a new retro question will land as a gimmick.
• ▹Don't force it onto work that's still hands-on. If someone spent the week in a brutal debugging session the agent couldn't help with, celebrate that the old way.

Common pitfalls

• ▹Judgment theatre. People invent dramatic 'decisions' just to have something to say at retro. The fix is to welcome small, honest answers. 'I cut the scope in half' counts.
• ▹The catch log turns into a blame log, aimed either at the agent ('Claude is useless') or at whoever wrote the prompt. Keep every post framed around the catch and the guardrail.
• ▹Over-gamifying. Put catches on a leaderboard and people start hunting trivial nitpicks. Keep it social and unscored.
• ▹Assuming it works for everyone. Some people loved the craft for its own sake. Outcome ownership won't fully replace that for them, and pretending it does costs you their trust.

What changed, honestly told

Within about six weeks the 1:1s had energy again. People arrived with stories: a trade-off they'd argued for, a bug they caught in review, a scope cut that saved a week. One engineer started a friendly contest over who could write the best problem brief. I couldn't have planned that, and I was glad to see it.

It didn't work for everyone. One person on the team loved the craft itself, the feel of writing a tight function by hand and the slow work of shaping code. 'You own the outcome' is true for them, but it doesn't replace what they lost, and they're still adjusting. Together we're working out where the craft still lives for them, in places like performance work and the debugging sessions where the agent goes in circles. I don't have a clean answer yet, and I've told them that directly.

The manager's takeaway for Day 24

Once agents do the typing, you have to decide on purpose what counts as a win. If you don't, your team will decide that nothing does. Give credit for outcome ownership: framing, judgment, catching mistakes and standing behind the result. Then build it into rituals people already attend: retros, demos and a shared space for catches.

In your next 1:1, ask: 'What's one call you made recently that you'd want your name on?' Then notice how long the answer takes. Tomorrow, in Day 25, we'll cover what to do with the answers you get.

Extend your knowledge

• ▹Read 'The Progress Principle' by Teresa Amabile and Steven Kramer. It lays out the research on why small wins in meaningful work drive daily motivation.
• ▹Read 'Drive' by Daniel Pink, then map autonomy, mastery and purpose onto your agentic workflow. Where does each one live for your team now?
• ▹Read the 'Postmortem Culture: Learning from Failure' chapter in Google's 'Site Reliability Engineering' book. Its blameless tone is a good model for keeping your catch log about learning rather than blame.
• ▹This week, swap one retro question for 'What judgment call did you make that the agent couldn't?' Write down how the answers differ from last sprint.