There’s a story I don’t tell in retros. Not because I’m hiding it—just because it doesn’t fit into sticky notes and burndown charts. It was a team I led during one of the most complex innovation cycles I’ve ever been part of—cross-functional, multi-time-zone, high visibility. We were working on a risk intelligence model powered by machine learning, and from the outside, we looked like a textbook Agile success story. Everyone loved referencing us. Our slide made it into a global town hall. But there’s a truth behind the slide. Yes, the team delivered. Yes, the roadmap held. But it was a specific, time-boxed stretch of momentum—maybe four months—when everything just aligned. People, purpose, bandwidth, backlog, timing. We had a good product owner, a smart designer who didn’t disappear behind Figma, and a lead engineer who didn’t let ego into architecture discussions. There was no dysfunction to fix. It just... worked. I remember thinking, This is it. This is what we mean by high-performing teams. And then, like sand slipping through fingers, it changed. First, one of the senior engineers left. Then we got pulled into a wider platform rewrite that had nothing to do with our mission. The product owner rotated to another line of business. And the new one? Different rhythm. Different voice. Not bad, just unfamiliar. One sprint, we were flying. The next, we were dragging unfinished stories across columns like we were moving furniture. Nobody failed. But the music stopped. Quietly. And most people didn’t notice. But I did. I used to chase “high performance” like it was a trophy. It’s not. It’s a moment. A phase. And like all phases—it passes. I wish someone had told me that earlier. Instead, I spent years looking at high-performing teams like they were something I was supposed to build, maintain, and export across the org. I thought if I just got the right blend of personalities, gave them autonomy, shielded them from distractions, and enforced Agile rituals with care—I could engineer greatness. That belief is romantic. And false. Because high performance isn’t something you build. It’s something that emerges. Temporarily. Under very particular conditions. And it doesn’t always announce when it’s arrived, or when it’s leaving. There’s no retrospective slide for “team soul erosion.” What I’ve realized, after leading enough squads, is that most of our Agile mythology relies on a dangerous assumption: that if a team is good, it’ll stay good. That’s not how teams work. People change. Energy shifts. Trust, even when well-earned, thins in silence. Greatness is real—but it’s not permanent. We don’t like saying that. Because it means we can’t take credit for it when it’s working. And we can’t fix it with tooling when it’s not. The closest I’ve seen anyone capture this truth is Richard Hackman. He led a body of research at Harvard for decades, quietly studying what made teams effective—not in theory, but in real-world contexts like cockpit crews and intelligence task forces. His conclusion was blunt: teams don’t succeed because they’re high-functioning or friendly. They succeed when five conditions line up—clear direction, solid structure, stable membership, supportive context, and expert coaching. And here’s the kicker: most organizations can’t offer all five consistently. The business doesn’t stand still long enough for that alignment to last. And that’s not a failure. That’s the job. Amy Edmondson’s work on psychological safety only deepens that insight. She showed—long before it became a buzzword—that learning and performance are byproducts of interpersonal risk-taking without punishment. Meaning: the minute people don’t feel safe saying “I don’t know” or “I disagree,” your velocity numbers stop telling the real story. In theory, high-performing teams are safe, supported, structured, and clear. In practice, they’re lucky. And when that luck hits, a good leader’s job is to host it—not hoard it. And when the moment ends? To know when to let go. I stopped trying to immortalize great teams. I stopped naming them in slides. I stopped calling them “high-performing” like it was a medal. Now, I say something else. I say: this team is in a moment. That moment could be flow. Or friction. Or fog. All of those are valid. All of those are human. When a team is thriving, I don’t freeze them. I ask them what they’re afraid of losing. When a team is stuck, I don’t fix them. I listen for what changed that no one acknowledged. I no longer use the phrase “high-performing team” the way I used to. Not because I think excellence is a myth. But because permanence is. We should stop holding teams to a bar that assumes stasis. The bar should be: can they notice when things change? Can they talk about it? Can they reorient? Can they grieve the version of themselves that no longer fits, and choose to become something new? If a team can do that? That’s what I call maturity. That’s what I build for now. Referenced: Tuckman, B. W. & Jensen, M. A. C. (1977). Stages of small-group development revisited. Group & Organization Studies.Hackman, J. R. (2002). Leading Teams: Setting the Stage for Great Performances. Harvard Business School Press.Edmondson, A. (1999). Psychological Safety and Learning Behavior in Work Teams. Administrative Science Quarterly. Tuckman, B. W. & Jensen, M. A. C. (1977). Stages of small-group development revisited. Group & Organization Studies. Hackman, J. R. (2002). Leading Teams: Setting the Stage for Great Performances. Harvard Business School Press. Edmondson, A. (1999). Psychological Safety and Learning Behavior in Work Teams. Administrative Science Quarterly. Please Like, Share, and Comment if you liked my article. Would love to know your thoughts. Until then, continue to learn, unlearn, and relearn, my friends.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Books That Found Me When I Wasn’t Looking

Why I Stopped Believing in “High-Performing Teams”

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

10 Things I Wish I Knew About Product Management Sooner

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

10 Product Development Traps

10 Things I Wish I Knew About Product Management Sooner

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

10 Product Development Traps

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps