Your Engineers Aren't Lazy. You're Starving Them.

Why are your engineers unmotivated?

Deci and Ryan identified three things humans need to stay motivated: autonomy, competence, and relatedness. Not perks. Not compensation. Not team-building events. Three psychological nutrients. When they’re present, people engage deeply. When they’re absent, no amount of money fills the gap.

Most product orgs strip all three. Not intentionally. By default.

Autonomy goes first. Fully-specified tickets. Tech lead already picked the approach. PM already wrote the acceptance criteria. The engineer becomes a translator from Jira to code. Autonomy isn’t about working from home. It’s about having agency over your own output.

Competence goes next. The senior engineer who’s written the same kind of CRUD endpoint for three years isn’t growing. The work isn’t stretching capability, it’s dulling it. Mastery requires progressive challenge. Feature factories run on repetition.

Relatedness goes last. Engineers who never meet users, never see outcomes, never hear whether what they built mattered. The sprint review is a stakeholder nod. The ticket moves to Done. The feedback loop is severed.

The three needs aren’t just theory. They’re measured. Mean scores from two national work samples on the Basic Need Satisfaction at Work Scale (1–7):

Deci et al. (2001) PSPB 27(8), Table 1: mean need satisfaction, Bulgarian (n = 431) and U.S. (n = 128) work samples, 1–7 scale. Real, citable values.

What AI Tooling Can Do, If You Let It

Embedding AI tooling into a delivery workflow can have an unexpected side effect: it can restore autonomy. When agents handle repetitive QA and documentation, engineers get their time back for the hard problems. The work becomes interesting again.

That’s not the default outcome. The default is that agents write the code and humans review it, shrinking the human role to quality gate. That’s motivationally disastrous.

The fix is structural. Three changes:

Give engineers problems, not solutions. “Here’s what the user needs. How would you solve it?”, not “Build this form with these fields.”
Match work to growth goals. The engineer who wants system design gets infrastructure-adjacent stories. This requires knowing what each person is optimizing for.
Close the feedback loop. Usage data, support tickets, user quotes, direct to the engineers who built the feature. Not filtered through a PM summary.

Motivation problems in product teams are usually structural, not personal. If your engineers are shipping on time but updating their LinkedIn, look at how the work is defined before you look at the people. s@spencervaradi.com.