The cross-functional team is a group project
.. and your best people know it
Bridgette Hamstead published a long-form analysis this week titled “Why You Hated Group Projects, and Probably Still Do.” The piece argues that group projects in school weren’t measuring collaboration. They were measuring neurotypical social architecture under a different name, and they did so by distributing the cost of that measurement disproportionately onto neurodivergent students who absorbed the labor when the social coordination failed.
The whole essay is worth reading. The section I want to extend is the one about how the group project format follows people into adult professional life, because for engineering leaders, this isn’t a description of something you survived. It’s a description of something you might currently be running.
Hamstead names the workplace versions: the committee, the task force, the cross-functional team, the working group. The architecture is the same. The stakes are higher. The social dynamics that produced the schoolyard role assignments produce the same role assignments at thirty-five, with different titles. The person who carried the eighth-grade history project is now the staff engineer on your platform team who has been quietly absorbing the integration work nobody else committed to, and who is starting to interview elsewhere.
This piece is what to do about that, written from the seat of the person responsible for the format rather than the seat of the person paying its cost.
What the cross-functional team measures
If you accept Hamstead’s argument that group projects measured social fluency while calling it collaboration, the engineering-leadership question becomes: what is the cross-functional team measuring while calling it coordination?
The honest answer is that most cross-functional teams in engineering organizations measure the participating engineers’ ability to navigate ambiguous organizational situations with low explicit structure and high interpersonal stakes. They measure how quickly someone can read the political dynamics across teams, find a workable position, negotiate through informal conversation, tolerate other teams’ approaches without taking over or shutting down, and produce a coordinated outcome without anyone explicitly telling them what coordination looks like. Engineers who can do this are rewarded. Engineers who can’t are described as not being collaborative, regardless of the technical quality of their work.
The content of the project (the actual technical problem the team was assembled to solve) is almost beside the point. An engineer who is deeply expert in the domain but who can’t navigate the team’s social dynamics will produce a worse organizational outcome than an engineer who knows less but coordinates fluently. The performance review follows the coordination, not the technical depth, and this is rarely made explicit because making it explicit would require admitting that the cross-functional team is a social-fluency assessment that has been disguised as a technical one.
I’ve written elsewhere about the scaling ceiling of group-based decision-making, where collective deliberation in technical organizations consumes more cognitive bandwidth than it produces and the cost falls disproportionately on the people whose contribution would be highest if they were allowed to do it alone. Hamstead’s piece is the neurodivergence-specific articulation of the same dynamic. The hive mind ceiling and the group project format produce the same outcome through the same mechanism: forced social coordination consuming the resources that the work itself requires.
Who’s absorbing the cost on your team
Hamstead names four roles that group projects reliably produced: the one who does everything, the one who gets steamrolled, the one who was too intense about it, and the one who checked out. Engineering leaders should be able to identify all four on their teams right now.
The one who does everything is your highest-conscientiousness senior engineer, often autistic or AuDHD, whose nervous system finds watching technical work be done incorrectly more costly than absorbing the work themselves. They have learned that on any cross-functional team they’re part of, they will end up doing the integration work, writing the design doc, owning the cleanup, and tracking the action items, because doing those things themselves is less costly than managing the social load required to get someone else to do them. They are, by every visible metric, your strongest contributor. They are also the one most likely to leave next year, because the math they’re doing on their own labor has been unsustainable for some time and you didn’t notice.
The one who gets steamrolled is the engineer with strong technical opinions who lacks the social fluency to get those opinions heard in the informal power structure of the team. Their proposal was the right one. It didn’t make it into the architecture document. They’ve stopped offering proposals as aggressively as they used to. You experience this as them becoming more agreeable. They experience it as having learned that the format doesn’t allow their contribution through, and they’re allocating their effort accordingly.
The one who was too intense about it is the engineer whose high standards are read by the team as a friction problem instead of a contribution. They keep pulling the conversation back to quality when the team has decided quality is sufficient. They are being managed by the group’s social dynamics in ways the manager can usually see but rarely intervene in. They are doing some of your team’s most important work, and the team is gradually routing them out of the decisions that depend on the kind of attention they bring.
The one who checked out is the engineer whose participation in the team format costs more than the grade is worth. They show up to standups, ship their tickets, and contribute nothing else. From the outside, this looks like disengagement. From the inside, it’s often a nervous system that has reached the limit of what the format can ask of it and made a triage decision. You read their behavior as a performance problem. The performance problem is downstream of a format problem the organization isn’t acknowledging.
All four of these roles persist in your organization because the team format produces them. The roles aren’t about the individuals occupying them. The roles are about what happens when you put high-conscientiousness people into low-structure collaborative situations with ambiguous accountability and call the resulting dynamic teamwork.
What “communicate better” feedback is doing
Hamstead’s section on the feedback neurodivergent students received from teachers (”communicate better, work on your collaborative skills, try to be more flexible”) has a direct workplace analogue. The performance review that says an engineer needs to work on their cross-functional collaboration, or be more flexible in working with partner teams, or improve their communication with stakeholders, is doing the same thing the teacher’s feedback did. It locates the problem inside the engineer rather than in the format that’s producing the friction.
This is the same dynamic I’ve described in the likability tax piece: when evaluation language gets vague, the vagueness is the tell. “Needs to improve cross-functional collaboration” without specifics is the workplace version of “doesn’t play well with others.” Both substitute a character read for a content read. Both make the engineer responsible for absorbing the cost of a structure that was producing the friction regardless of who was inside it.
If you find this language on your team’s performance review documents, the diagnostic question is: what was the specific situation, what did the engineer recommend, what was the constraint they were operating under, what did the partner team agree to, and what happened next. If you can’t answer those questions, you don’t have a collaboration problem. You have a format problem dressed as a person problem.
The remote work read
Hamstead’s section on why remote work felt like relief to many neurodivergent workers is worth quoting at length, because it’s the part of the piece that gets the most pushback from leadership and the part where leadership is most likely wrong.
The argument is that for workers whose cognitive resources were being consumed by the regulatory cost of physical co-presence, the move to remote work freed up bandwidth that had been invisible to their employers. They weren’t less collaborative. The collaboration just became less expensive. When you read remote workers’ reluctance to return to the office as evidence of cultural decline or disengagement, you are reading a real signal incorrectly. What it signals is that the office was extracting a cost from a subset of your workforce that you weren’t acknowledging, and that the people paying that cost had figured out an arrangement that worked better and don’t want to lose it.
For engineering leaders making return-to-office decisions, this is the dimension that the cost-benefit analysis usually omits. The benefits of physical co-presence are real and measurable, mostly through proxy metrics that capture neurotypical collaborative output. The costs are also real but are paid by a subset of the workforce whose absorption of those costs has been treated as invisible labor for a long time. When you sum the benefits without subtracting the costs, the math says return to office. When you account for the costs, the math says different policies for different work, and the engineers most affected know this even when they can’t articulate it.
What you can do
Hamstead’s piece offers three moves to neurodivergent adults navigating the workplace version of the group project: ask, opt out, name. From the seat of the manager or director, there are different moves available, and they are the structural ones the individual engineer can’t make for themselves.
Make role definition explicit before the team starts. The group project’s defining feature is ambiguity about who’s doing what. The fix is naming roles out loud, in writing, before anyone has had time to default into the patterns the team produces. Who is responsible for the design doc? Who owns the integration work? Who tracks decisions and surfaces blockers? Who has final authority on technical calls? Most cross-functional teams answer these questions through informal negotiation that takes weeks and produces the role assignments the team’s social dynamics would have produced anyway. Naming the roles upfront short-circuits the negotiation. It also redistributes the labor that defaults to the most conscientious person on the team.
Track individual contribution with the rigor you would apply to a code review. Most cross-functional teams produce a single deliverable with everyone’s name on it, and the credit gets distributed by manager memory and social proximity to the visible parts. This is the workplace version of the group project grading rubric Hamstead describes: assessment of the group treated as assessment of the individuals, with no mechanism to distinguish them. The fix is documenting who proposed what, who owned what, what the decisions were and who made them. The documentation doesn’t have to be formal. It does have to exist somewhere other than the manager’s head.
Question the format before defaulting to it. Not every coordination problem needs a cross-functional team. Some need a written proposal that other teams comment on asynchronously. Some need a single person empowered to make a decision after consultation. Some need an explicit owner with clear authority and a clear escalation path. The cross-functional team is the default format because it distributes responsibility, which is its primary appeal to the organization assembling it. If the format is the right tool for the problem, run it. If it’s the default because no one wanted to take ownership, that’s a different signal, and the engineers on the team can tell.
Read the role distribution on your existing teams. If the same engineer keeps ending up in the “does everything” role across multiple teams, that’s organizational information. The pattern isn’t a coincidence. It’s a structural outcome the team format produces, and unless you intervene, the engineer absorbing the cost will continue to absorb it until they leave. The intervention isn’t telling them to do less. It’s redistributing the work the format was pushing onto them, which requires you to look at who isn’t carrying enough and to address that side of the equation, not theirs.
What the cover story is doing
Hamstead has a sharp section about the institutional interest the group project format served, which she names as training students for compliance with group process regardless of process quality. The workplace version of this insight is uncomfortable enough that I want to state it plainly.
The cross-functional team format persists in engineering organizations partly because it distributes coordination cost in a way that benefits the organization at the expense of the individuals doing the coordinating. When the team produces a good outcome, the company credits its collaborative culture. When the team produces a bad outcome, the cost is borne by the engineers who carried it. The format makes responsibility diffuse on the way in and concentrated on the way out, and the concentration falls on the people whose conscientiousness made them absorbable.
This isn’t a moral failing of any specific manager. It’s the structural function of the format. The reason the group project survives in education, namely that it produces graded compliance without requiring the institution to do the hard design work that real collaborative learning would require, is the reason the cross-functional team survives in engineering: it produces apparent coordination without requiring the organization to do the hard design work that explicit ownership would require.
The cost of this arrangement is paid by a predictable subset of your engineers. They are doing the integration work, writing the documents, tracking the decisions, absorbing the friction. Hamstead’s piece is a description of who they are and what it’s costing them. The question for the people running the format is whether you’re willing to acknowledge what’s being paid for the appearance of collaboration, and whether the appearance is worth the price.
You probably know which of your engineers I just described. The next move is yours.