At some point I stopped being scared of software. Given enough time and money I could usually work it out. That pushed my attention toward leadership and the human systems around the work. I was getting more senior and getting asked to lead small teams, so it was a natural shift.
Reading Tom DeMarco put language to something I was already circling: the gelled team. A gelled team is not just a group of competent people on the same project. It is a team with trust, momentum, and a shared identity. Communication gets easier, conflict gets cleaner, and people start protecting the work because they feel they belong to something real.
That kind of cohesion does not happen by accident. It needs stability, real safety, shared ownership, room for deep work, and some sense of identity. Most companies quietly destroy all of that and then wonder why the team never really forms.
I still believe that. I have also learned, the expensive way, that DeMarco’s ideas can be catastrophic if you apply them without care.
What actually forms a team
As a young leader, identity was the lever I could pull most easily. I could not always change the reporting structure. I could not always change the roadmap. I could not always change the incentives around the team. But I could create a sense that the people doing the work were part of something specific, not just assigned tickets under a generic company banner.
Over time I compressed the problem into three requirements: a shared space, a shared goal, and a shared identity.
Shared space matters more than people like to admit. A team needs somewhere that is recognisably theirs: a desk bank, a room, some bounded territory distinct from other teams. Humans organise around proximity and repeated contact. Norms form almost automatically when a group occupies the same place long enough.
Shared goal matters too, but it has to be narrow enough to mean something. Company goals are usually too vague to produce real cohesion. A team needs a task that belongs to its domain, specific enough that ownership can form around it.
Shared identity is the closest thing to DeMarco’s original point. It is the sense that this is not a temporary collection of workers, but a real unit with its own character, standards, and sense of itself. Symbols help. So do jokes, rituals, and milestones that belong to the team rather than to a slide deck.
I have watched this work.
On one team, we were modernising a large old platform into something more coherent. It was not glamorous work in the way greenfield projects are glamorous. There was legacy code, institutional memory, awkward boundaries, and the usual emotional residue that accumulates around a system that has been useful for too long. The technical milestone was containerisation, but what mattered socially was that the team needed a way to understand what it was becoming.
I commissioned a ridiculous poster to mark the milestone: a huge whale pushing through rough water with shipping containers on its back and a few flamingos perched on top. It was absurd in exactly the right way. The image captured the emotional shape of the work better than any plan could have. We were trying to move something large, awkward, and important without pretending it had suddenly become elegant.
When the milestone landed, the poster gave the team a symbol that was unmistakably theirs. The jokes started. The references stuck. The group became less like a reporting line and more like a unit. I had seen enough process theatre by then to know the difference. This was not a workshop exercise. It was real cohesion forming around real work.
I saw the same pattern later in a different form. A small team with a reputation for being a little too independent leaned into the joke and turned it into a shared identity. A flag went up. The language changed. People who had previously been a collection of individual engineers started behaving like they belonged to the same thing.
That is the part of DeMarco that is easy to fall in love with. When it works, it feels like cheating. Coordination gets easier. People communicate in shorthand. The team develops standards without needing everything written down. Members defend each other’s focus. They take pride in the work because the work is no longer abstract; it belongs to the group.
None of that is the problem. The problem is what happens when the identity becomes stronger than the team’s connection to the organisation around it.
Where it goes wrong
The danger is not that identity is fake. The danger is that it works.
A strong team identity creates an inside and an outside. That boundary is not automatically bad. Teams need some internal coherence. They need enough separation from the rest of the organisation to develop trust, taste, cadence, and standards. If everything is porous all the time, the team never forms. It remains a crowd of individuals being interrupted by whichever external demand is loudest that week.
But the same boundary that allows a team to form can harden into a wall.
That is the failure mode I have lived through more than once. It starts innocently. You are trying to give engineers the conditions to do good work. Clear goals. Room to think. Fewer random interrupts. A little less organisational noise. You see the team start to breathe again, and because the improvement is real, you keep doing the thing that produced it.
Then, without noticing the shift, “building the team” becomes mediating the world.
You become the sole translator between the team and everyone else. Feedback stops reaching the people doing the work in its original form. Stakeholders stop having direct contact with the people who could answer them. The engineers get a cleaner environment, but they also get less reality. The team becomes more loyal, more coherent, and more dependent on you as the interface.
From inside the team, this can feel like leadership. From outside, it looks like a faction.
Both readings can be true. That is what makes the failure dangerous.
The team may genuinely be working better. They may genuinely trust each other more. They may be shipping better work because they are not being thrashed around by every passing request. But the organisation is also losing direct access to the people who understand the system. The team is losing contact with customers, operations, product, sales, and all the ugly constraints that live outside engineering. The manager becomes load-bearing in a way that looks virtuous until it starts to distort the business.
Loyalty migrates. People start belonging to the team, or to the leader of the team, more than they belong to the company. That can feel noble when you are the person they trust. It is also exactly what an organisation does not want from a leader. The point is not to gather personal loyalty. The point is to build a team that can operate with trust while staying connected to the company it serves.
The same pattern shows up when identity is built against a neighbouring group: the legacy team, the head office, “management,” the process people. Opposition is a cheap way to gel a group. It is also a reliable way to make the group unintegrable later. You get cohesion now and pay for it in politics, duplication, and exits when the business needs the team to join the larger system.
I have made versions of this mistake. I have over-indexed on team independence. I have treated legitimate requests for visibility as attacks on autonomy. I have mistaken team trust for organisational health. I have put cohesion above the harder work of integrating that cohesion into the wider company.
The results were predictable: short-term team strength, longer-term organisational friction, and eventually a break.
The lesson was not that shared identity was wrong. The lesson was that I had been using it as a wall.
How to keep the useful part
DeMarco is still right about the gelled team. The correction is narrower.
Build identity inside the organisation, not against it. Shared symbols and private jokes are fine. Defining the company as the enemy is not. If the team’s story requires a villain next door, you are buying cohesion on credit.
Keep the manager from becoming the only bridge. Translation is useful, but only as a temporary act. If engineering and the rest of the business can only understand each other through one person, the system is fragile. Put engineers in contact with the people who own outcomes, constraints, and consequences. Let product, operations, sales, support, and leadership interact with the people who can actually explain the trade-offs.
That does not mean dumping every conversation onto the team. It means designing the right contact points. Engineers do not need to sit in every commercial conversation, but they do need enough business context to make good decisions without guessing. Stakeholders do not need to wander through engineering with unlimited interrupts, but they do need enough access to understand why something is hard, risky, or important.
Ownership without organisational context is just a craft bubble. The point of a gelled team is better work for the business, not a happier silo.
Treat identity as a means, not the product. The product is trust, speed, and clean conflict in service of a real goal. When identity starts competing with that goal, or with the company’s ability to coordinate, it has gone too far.
Leave enough surface area that the team can be inspected without being dismantled. Visibility is not the opposite of trust. A team that can only function if nobody outside can see how it works is not gelled. It is fragile.
The test is simple: does the identity make the team easier or harder for the organisation to work with?
If identity helps the team communicate, own outcomes, and collaborate cleanly with neighbouring domains, it is doing its job. If it turns ordinary coordination into a territorial negotiation, it has become a liability. If people outside the team have to negotiate access through the manager, the team is not protected. It is isolated.
Still worth building
There is nothing wrong with shared identity. Once you have had a real gelled team, the fake versions are hard to take seriously. A team that trusts itself, communicates in shorthand, and takes pride in its work is not a problem to solve. It is one of the best things an organisation can have.
The problem is the silo. Applied carefully, DeMarco’s ideas create groups that can carry hard work together inside a larger system. Applied carelessly, they create loyal factions that treat the rest of the organisation as an external threat.
Teams need a shared identity.
They also need to remain part of the company that identity is supposed to serve.