Extending the Conversation on What Makes High-Functioning Teams Gel
Our table sat near the center of the restaurant. Five old colleagues, catching up over dinner, trading stories, laughing about things that probably weren’t nearly as funny to anyone who hadn’t been there.
In the chrome trim nearby, I caught our reflection. A little distorted, perhaps. A little older, certainly. It occurred to me that we had been doing this for more than twenty-five years.
We first came together around the turn of the millennium, working at RSW Software and what would become Empirix. We survived reorganizations, changing responsibilities, new technologies, new management, and eventually Oracle’s acquisition of the business in 2008. Our careers took different directions. Some of us stayed in engineering, while others moved through consulting, support, leadership, and entirely different organizations.
Yet here we were. Still talking shop. Still challenging one another. Still laughing at the same old stories. And I found myself wondering why.
What Makes a Team Gel?
Not long ago, my friend Robin gave a presentation to the Software Quality Group of New England about what distinguishes a team that merely works together from one that truly gels. It was a fascinating discussion.
Robin explored the importance of shared identity, trust, leadership, and the ability of individuals to accomplish something extraordinary together. One observation particularly resonated with me: in a gelled team, leadership isn’t confined to the person with the title. People step forward when they’re needed and step aside when someone else is better suited to the moment.
During the discussion, I offered a thought about shared struggle, and how people who work through difficult problems together sometimes develop something beyond ordinary professional cooperation.
Robin’s presentation got me thinking about those five people around the restaurant table. I wasn’t interested in challenging his conclusions. Quite the opposite. I wondered whether our experiences might help explain some of what he was describing. How does a team become that kind of team? And why do some of those relationships survive long after the work itself is finished?
I can only speak from experience, but I think ours offers a few clues.
The Crucible
In those early days, many of us came through what was broadly known as Apps Engineering. The boundaries between support, pre-sales, consulting, and training were not nearly as rigid as they would eventually become. We answered customer questions, diagnosed problems, demonstrated products, trained people, traveled when necessary, and performed something called a Quick Start.
A Quick Start was essentially an hour on the phone with a prospective customer, using their live application to demonstrate that our technology could do what we claimed. Today, that might sound relatively straightforward. But this was before the convenience of modern screen sharing, cloud environments, and an AI assistant waiting to suggest the next ten things to try. You had to guide someone blindly over the phone through recording, validating, and load-testing an unfamiliar application, identifying its peculiarities in real time and making something useful happen before the hour ran out.
Sometimes it went beautifully. Sometimes it didn’t. And sometimes you found yourself staring at a problem, wondering how on earth you were going to get out of it.
Those experiences taught us the products, certainly. They taught us about customers and the strange things people do with software. But somewhere along the way, we learned something else.
We learned each other.
We learned who would ask the question nobody else had considered. Who would try something that seemed impossible. Who could recognize a familiar failure hiding inside a completely unfamiliar problem. We learned who to call, and perhaps more importantly, we learned that when we called, somebody would answer.
Nobody designed a team-building exercise around those experiences. We weren’t following a carefully constructed program for developing trust. We were just trying to get the work done. Looking back, I suspect that’s where much of the foundation was laid: not simply in the struggle itself, but in discovering what we could count on from one another when things became difficult.
Anchors, Spark Plugs, and Foils
Over the years, I’ve come to recognize certain patterns in the way we worked together. Sometimes a situation needed someone to slow things down and restore perspective. Sometimes it needed someone to get things moving. And sometimes it needed someone willing to say, “Wait a minute. That doesn’t make sense.”
I’ve come to think of these contributions as the Anchor, the Spark Plug, and the Foil.
They’re archetypes, not fixed personality types or assigned positions. They’re modes of contribution that emerge to meet the moment, and I think that’s an important distinction. In a team that has truly gelled, people move between them naturally. The person challenging an idea today may be the one championing it tomorrow. The person who steadied everyone during the last crisis may be the one proposing something wildly ambitious in the next discussion.
Nobody announces a change of roles. Nobody asks permission. Someone simply recognizes what’s needed and steps forward.
The Anchor: The Gravity Well and Synthesizer
The Anchor brings perspective when things begin to spin out of control. Institutional memory matters here, along with pattern recognition and the ability to separate what is important from what is merely urgent. When everyone is chasing symptoms, the Anchor asks what problem we’re actually trying to solve. When the room fills with competing opinions, the Anchor remembers what we’ve already learned. And when a solution begins to look suspiciously like a solution in search of a problem, the Anchor asks a question that brings everyone back to earth: What defines “correct”? Which risk actually matters? The Anchor doesn’t necessarily have the answer. Sometimes the most valuable contribution is recognizing that nobody does.
The Spark Plug: The Catalyst and Energy Driver
Every team needs momentum. Someone has to look at an obstacle and wonder whether there’s another way around it. Someone has to take an idea that has been sitting on the table and say, “Well, why don’t we try it?” The Spark Plug brings curiosity, energy, and a willingness to explore possibilities before every uncertainty has been resolved. Not every idea will work, and some will fail spectacularly. But without that willingness to move, a team can spend an extraordinary amount of time discussing what might happen without ever discovering what actually does. And sometimes the person who was the Anchor five minutes ago becomes the Spark Plug because the moment has changed.
The Foil: The Constructive Challenger
Then there’s the person willing to challenge the idea, not to win an argument and not to demonstrate superior intelligence, but because the work deserves a better answer than polite agreement. The Foil asks the uncomfortable question, finds the assumption everyone else has accepted, and points out the consequence nobody wants to consider. I’ve always believed that disagreement, when grounded in mutual respect, is one of the most valuable things colleagues can offer one another. But it requires trust. You need to know that the person challenging your idea isn’t challenging your worth, and you need enough confidence in the relationship to return the favor. Without that understanding, the Foil becomes an irritant. With it, the Foil becomes invaluable.
Knowing What the Moment Needs
What interests me isn’t simply that these three contributions exist. It’s how naturally people can move among them when they’ve worked together long enough to understand one another.
An idea begins to take shape. Someone pushes it forward. Someone else finds a weakness. Another person recalls something relevant from years earlier. Then the roles shift: the challenger proposes an alternative, the person who started the discussion becomes the skeptic, and someone who has barely spoken offers the observation that changes everything.
It happens without choreography, and nobody particularly cares who gets credit for playing which part. Perhaps that’s one of the things Robin was describing.
Toward the end of Robin’s session, I remember saying that you don’t need position power to lead. You just have to decide you’re going to be the one. Looking back, the people at that table had been making that decision, quietly and in turn, for a very long time. Nobody gave them the title. Nobody asked.
The Unspoken Code
There’s another part of the story that I think matters.
I remember an occasion when a colleague found himself in trouble late at night on the road and needed help. By then, our responsibilities had become more specialized. The organization had grown, and the lines between pre-sales, support, engineering, and consulting were much more clearly drawn. Helping him wasn’t necessarily my department’s responsibility anymore, and there were people who made that point.
But I couldn’t see it that way. Someone I had worked beside, someone who had been there through the same difficult customers and impossible problems, needed help. What was I supposed to do? Tell him to call the correct department?
I helped, not because there was a policy requiring it and certainly not because it was convenient, even if it meant absorbing some heat from management afterward. I helped because he was one of ours.
I don’t mean to romanticize the past. We had disagreements. We annoyed one another. We had strong opinions, competing priorities, and all the ordinary imperfections that come with working closely with other human beings. But underneath those differences was an understanding that rarely needed to be spoken:
We all came from the same place. And nobody gets left behind.
That understanding didn’t disappear when the reporting structures changed. It didn’t disappear when Oracle acquired the business. And it hasn’t disappeared even now, when many of us haven’t worked together in years. We still make introductions, share advice, and help one another find an opportunity or think through a problem. And sometimes we just sit around a restaurant table and tell stories.
I suspect the same experiences that taught us how to work together also taught us something about our obligations to one another.
Near the end of Robin’s session, the conversation turned to AI, and he made an observation I haven’t been able to shake. Whatever these tools can do, they don’t seem to feel any obligation to anyone, and obligation is part of what makes a team a team. I thought of that night on the road. If obligation is something a team has, it has to be learned somewhere.
What Happens to the Next Generation?
Which brings me to something I’ve been thinking about as AI becomes an increasingly important part of how software is built, tested, and maintained.
I’m enthusiastic about much of what these technologies can do. There are problems I spent hours, and sometimes days, trying to solve that today’s tools can help resolve in minutes. I wouldn’t trade that progress away merely for the sake of nostalgia, and I certainly don’t believe the next generation of engineers needs to suffer through every frustration we endured. There was plenty about those days I wouldn’t wish on anybody.
But I wonder about something else.
What happens when the junior engineer no longer needs to ask the senior engineer for help? When the person struggling with an unfamiliar customer application can ask an AI assistant rather than turning to the colleague at the next desk? When the difficult, messy, occasionally embarrassing experiences through which we learned our craft become increasingly rare?
Perhaps we eliminate a great deal of unnecessary frustration, and that would be a good thing. But might we also eliminate some of the opportunities through which people learn to understand, trust, and rely on one another?
I don’t know. Maybe the next generation will find entirely different ways to develop those relationships. I hope they do. Because the value of those early experiences wasn’t limited to the technical knowledge we acquired. Somewhere in the middle of solving problems, making mistakes, arguing about approaches, and helping one another recover from the occasional disaster, we became something more than a collection of people working for the same company.
We became a team. And for some of us, that connection lasted long after the team itself ceased to exist.
The Reflection
Back at the restaurant, the conversation wandered as it always does: old technologies, new technologies, people we’d worked with, people we’d lost touch with, and stories that somehow become funnier with every retelling.
I looked again at the reflection in the chrome. Five men, a little older than when we first met. Different careers, different lives, different perspectives, yet still capable of challenging one another, still curious about what the others were doing, and still showing up.
I don’t know whether every team that gels produces friendships that last a quarter century. I rather doubt it, and I wouldn’t suggest our experience represents some universal formula. But Robin’s presentation helped me recognize something I hadn’t fully appreciated.
We didn’t become close because we were alike. We learned to work together despite our differences, and eventually those differences became part of our strength. We learned when to push, when to challenge, and when to steady one another. And somehow, without ever deciding to do so, we carried a little of that team with us into everything that followed.
Twenty-six years later, I think that’s worth reflecting on.