Article content
Marco’s team isn’t working. Everyone knows it. The diagnosis comes fast: “Marco isn’t motivated.” “Sara doesn’t communicate.” The plan: a one-on-one with Marco to figure out what’s blocking him, a team building workshop, and if things don’t improve, swap someone out.
Three months later, Marco is gone. Luca replaced him. The team still isn’t working.
The scene keeps repeating because the diagnosis is wrong. Not wrong in an obvious way — wrong in a plausible way, which is worse. “Marco isn’t motivated” sounds reasonable. Everyone nods. Too bad the problem isn’t Marco.
Social psychology has a name for this: fundamental attribution error. Ross described it in 1977: when we observe behavior, we tend to attribute it to personal traits (laziness, poor collaboration) while underestimating the weight of the situation the person is in.
J. Richard Hackman spent forty years studying teams: flight crews, orchestras, intelligence squads. The bottom line of his research: structural conditions explain up to 80% of variance in team effectiveness (Wageman, Hackman & Lehman, 2005). When a team isn’t working, the most likely problem isn’t who’s in it. It’s how it was designed.
Before replacing people, check the conditions.
The five conditions: a checklist, not a theory
Hackman didn’t produce an abstract model. He produced a checklist. Five conditions that, when present, make it likely a team will work. When absent, make it likely it won’t. He validated them empirically across hundreds of teams in different contexts. They work as a diagnostic tool long before they work as theory.
Here’s a quick translation into software context. For the full picture, start with the previous piece on Hackman’s team vs. working group distinction.
1. Being a real team. Clear boundaries, stable composition, real interdependence. If even one of these three is missing, you don’t have a team. You have a group of people with a shared manager.
2. A compelling direction. A clear, challenging, meaningful objective. Not “close the sprint stories” — that’s a unit of measurement, not a direction. A compelling direction answers the question: why does this work matter?
3. An enabling structure. Roles, norms, skills. The minimum infrastructure so people don’t have to renegotiate everything from scratch every week.
4. A supportive organizational context. Does the team have the information it needs? The resources? Does the reward system incentivize group outcomes or individual performance? This is the condition the team can’t give itself. It depends on the organization around it.
5. Competent process coaching. Not technical mentoring: someone who helps the team work better together. How they make decisions, handle disagreements, distribute work. It’s the condition that matters least of the five (the 10% in Hackman’s 60/30/10), but it’s the one everyone focuses on.
The instinct when managing teams is to start at the bottom: coaching, facilitation, interpersonal dynamics. Hackman says: start at the top.
The table that flips the diagnosis
This is the core of the argument. Six phrases I hear repeated constantly. For each one: the usual diagnosis, the most likely structural cause, and where to look instead.
Some of these mappings are directly anchored to Hackman’s research. Others are my translation into the software context, and I flag them as such.
”Marco isn’t motivated”
It’s Marco’s problem, people say. He lacks drive, ownership. Maybe he’s not right for the role.
More likely, the team lacks a compelling direction (condition 2). If the team’s objective is vague, purely administrative, or changes every two weeks, motivation isn’t a trait of Marco’s. It’s a rational response to a context that gives no reason to invest energy. I’ve seen brilliant developers seem disengaged because their team’s mandate was “support the product” — which in practice meant answering tickets endlessly with no vision of where things were heading.
Don’t look at Marco. Look at the team’s mandate. If you can’t explain in one sentence why the work matters, that’s your problem.
”Sara doesn’t communicate”
Where to look here is at work design. If everyone works on a separate feature and interactions are limited to the occasional comment on a pull request, there’s no structural reason to communicate more. Sara isn’t uncollaborative. She’s rational: why would she update others on work that doesn’t affect them?
The cause is a lack of real interdependence (condition 1). You can run all the communication workshops you want: if the work structure doesn’t create mutual dependencies, communication will remain an empty ritual.
”The team doesn’t trust each other”
The classic response: team building activities, vulnerability exercises, an offsite to get to know each other better.
Trust in a team doesn’t come from an afternoon workshop. It comes from working together long enough to predict how the other person will behave. Hackman saw this with flight crews: crews that had flown together for a while made fewer errors than newly formed ones, even with less experienced pilots. The most likely problem is unstable composition (condition 1). If you rotate people between teams every quarter, you restart from zero each time.
How many times has the team’s composition changed in the past year? If the answer is “often,” the trust deficit isn’t a relationship problem. It’s structural turnover.
”Retros don’t produce anything”
Here the question comes before the answer: is there a shared process to improve? Retrospectives assume a team that collaborates on a common outcome and wants to improve how they do it. If everyone has their own workflow, priorities, and blockers, the retro has no object. The format is irrelevant. The cause is that the group isn’t a real team (condition 1).
”The lead can’t guide the team”
The usual diagnosis: they lack soft skills. Send them to a leadership course.
The lead might be excellent. But if the team doesn’t have access to the information it needs, if resources get cut without notice, if the evaluation system rewards individual performance and ignores group outcomes, the lead is in an impossible position. It’s like asking a pilot to land well with a poorly designed airplane — you can send them to every flight course there is, but if the flaps don’t work, the problem isn’t their technique.
The cause is the organizational context (condition 4). Does the lead have the authority to make decisions? Are priorities stable enough to allow a plan? If not, the leverage is in the organization, not the person.
”Too much conflict”
Here the answer is less straightforward. Conflict in a team can be a good sign: if the team is real and negotiating norms for working together (condition 3), some friction is physiological. Hackman says it clearly: the best teams aren’t conflict-free. They’re teams that have learned to manage conflict.
But conflict can also signal unclear boundaries (condition 1): who decides what? Who has authority over which part of the system? If two people both think they’re responsible for the same area, the conflict isn’t relational. It’s structural.
The useful distinction: if the conflict is about how to do things, it’s probably healthy. If it’s about who should do what, it’s a boundary problem. And if it’s chronic despite everyone’s best intentions, it’s almost certainly not a people problem.
Why we keep getting the diagnosis wrong
If structural conditions matter this much, why does the default remain “someone’s fault”?
The first reason is that structure is invisible. You see people. You see behaviors. You don’t see the conditions in which those behaviors emerge. Hackman pressed this point in the last paper of his career, “From causes to conditions” (Hackman, 2012): research on teams has focused too much on internal causes (who does what, how they behave) and too little on external conditions (how the team is designed, what context it operates in). The same applies to people managing teams in practice.
The second is that replacing people feels easier. Giving Marco feedback, sending Sara to a workshop, swapping the lead: these are all actions a manager can take tomorrow morning. Redesigning the team’s mandate, stabilizing composition, changing the incentive system — those require time, authority, and often negotiation with someone above. The interpersonal diagnosis is attractive because it has solutions at hand. Too bad they’re the wrong solutions.
The third is more insidious, and I’ve seen it up close: the organization incentivizes individual diagnosis. Performance reviews evaluate people, not conditions. PIPs apply to people. “Cultural fit” is an attribute of people. The entire management apparatus is built around the idea that performance is an individual trait. Admitting the problem is structural means admitting the system is poorly designed — and the person who designed the system is often the one making the diagnosis.
Next time someone says “the problem is Marco,” pause for a moment. Not because Marco is necessarily innocent: sometimes the problem really is the person. But it’s less common than we think, and the interpersonal diagnosis is so intuitive we always get there first.
Try reframing. Not “who isn’t working?” but “what in the structure isn’t working?” Move from person to condition. Then ask yourself: is this condition under my control? If yes, that’s where the energy goes. If not, at least you know that no team building workshop will fix it.
It’s not a small difference. It’s the difference between debugging the code and debugging the compiler.
Sources
- Hackman, J.R. (2002). Leading Teams: Setting the Stage for Great Performances. Harvard Business School Press.
- Hackman, J.R. (2011). Collaborative Intelligence: Using Teams to Solve Hard Problems. Berrett-Koehler.
- Hackman, J.R. (2012). From causes to conditions in group research. Journal of Organizational Behavior, 33, 428-444.
- Wageman, R., Hackman, J.R. & Lehman, E.V. (2005). Team Diagnostic Survey: Development of an Instrument. Journal of Applied Behavioral Science, 41(4), 373-398.
- Ross, L. (1977). The intuitive psychologist and his shortcomings: Distortions in the attribution process. In L. Berkowitz (Ed.), Advances in Experimental Social Psychology (Vol. 10, pp. 173-220). Academic Press.
