Why are your engineers disengaged?
In 1976, Hackman and Oldham published the Job Characteristics Model. It’s survived 50 years of replication. Five core dimensions predict whether a job produces intrinsic motivation or burnout:
- Skill variety: does the role use a range of capabilities?
- Task identity: can the person see a whole piece of work through from start to finish?
- Task significance: does the work affect other people?
- Autonomy: does the person control how they do the work?
- Feedback: does the work itself provide clear information about results?
Hold those five dimensions up against the feature factory. Here is the model those five dimensions feed, the causal chain the JCM predicts:
The Feature Factory Destroys All Five
A feature factory is what you get when a product org treats engineers as a “resource” that converts tickets into code. Tickets arrive fully specified. Engineers don’t meet users. Roadmap items are handed down, not shaped together.
Run the JCM against this model:
- Skill variety. The engineer writes the same kind of CRUD endpoint they wrote last sprint. One skill, repeated.
- Task identity. They never see a feature from discovery to adoption. They get a ticket, close a ticket. Was it used? They’ll never know.
- Task significance. The ticket says “add filter to admin dashboard.” Nobody explained that this saves the support team 20 hours a week.
- Autonomy. The tech lead already decided the approach. The PM already wrote the acceptance criteria. Paint-by-numbers.
- Feedback. Sprint review happens. Stakeholder nods. Ticket moves to Done. Feedback arrives six months later as a bug report.
No amount of compensation fixes this. No ping-pong table, no free lunch, no “unlimited PTO.” The work itself is motivationally bankrupt.
Three Changes That Cost Nothing
-
Put the “why” in the ticket. “Support team spends 20 hours/week manually filtering tickets. Add saved filter so they can get that time back.” Not “Add filter to dashboard.”
-
Close the feedback loop. Engineers should see usage data, support tickets, and customer quotes for features they built. Directly. Not filtered through a PM summary.
-
Let engineers participate in discovery. One hour per sprint is enough to restore task significance. Not every engineer wants this; the ones who do should be in user interviews.
Standardizing delivery is rarely just about process. Done well, it restores task identity and feedback. A team working in ad-hoc chaos cannot see its impact; it closes tickets into a void. When outcomes become visible, ownership follows, because people can finally see what their work produced.
The Agent Risk
When AI coding agents enter the workflow, the risk is that engineers get pushed further from the five dimensions. If agents handle boilerplate while humans handle design and judgment, that’s a net positive. If agents handle everything and humans become prompt-writers and PR-reviewers, all five dimensions collapse.
The question for every team adopting AI tooling: are you using agents to restore autonomy and mastery, or to strip what’s left of it?
If your engineers are shipping on time and updating their LinkedIn, the problem isn’t compensation. It’s the work itself. Run the five dimensions against your ticket flow before the good people leave. s@spencervaradi.com.