What Makes a Great IT POD Team? Beyond Just Technical Skills

For anyone who's ever been on a team full of talented people that still somehow underperformed.

You've probably experienced this before.

A team stacked with strong engineers. Solid resumes, sharp technical interviews, impressive portfolios. And yet, the project drags. Communication breaks down. Small disagreements turn into silent resentment. Deadlines slip — not because anyone lacked the skill to do the work, but because something less visible wasn't working.

That "something" has a name, and it's been studied more rigorously than most people realise.

Google Already Answered This Question

In one of the most-cited workplace studies of the last decade, Google's Project Aristotle analysed 180 teams — 115 engineering teams and 65 sales teams — to figure out what separated the best-performing teams from the rest.

The finding surprised even the researchers. Team composition — who was on the team, their personalities, their shared hobbies, even their individual talent — did not predict team effectiveness. What did predict it was a set of five factors, and the strongest one by far was something called psychological safety: the shared belief that it's safe to take risks, ask for help, and admit mistakes without being punished or embarrassed for it.

Let that sink in for a moment. Google — a company that famously over-indexes on hiring the most technically gifted people on Earth — found that raw talent wasn't what made teams excel. It was whether people felt safe enough to be honest with each other.

This is the real answer to what makes a great IT POD team. Skills get you in the door. Psychology determines what happens after.

The Concept Behind the Data

Psychological safety isn't a soft, feel-good HR term. It was formally defined by Harvard's Amy Edmondson, who described it as the belief that neither the formal nor informal consequences of interpersonal risk — like asking for help or admitting failure — will be punitive.

In an IT pod, this plays out constantly. A developer who suspects a feature won't be ready by the deadline. A QA engineer who flags a risk that nobody wants to hear about. A junior team member who doesn't understand a requirement and is afraid to ask. In a psychologically unsafe environment, all three of these stay quiet — and small problems become large ones by the time anyone notices.

Research on psychological safety and team performance describes the healthiest version of this dynamic clearly: when mistakes are treated as stepping stones for learning rather than failures, teams build confidence and keep experimenting. Deloitte's own leadership academy built an entire program around this principle, training over 100 partners and leaders specifically on creating space for open dialogue and learning from error.

The lesson for IT pods is direct. A team that's afraid to surface problems will always look fine right up until it isn't.

Why Hiring Managers Are Already Catching On

This isn't just academic theory — the hiring data backs it up.

LinkedIn's research found that 9 out of 10 global executives now believe soft skills matter more than ever — and for the second year running, communication topped LinkedIn's list of the most in-demand skills overall, ahead of every technical competency measured. Adaptability was named the fastest-rising "skill of the moment," reflecting how quickly the nature of technical work itself is changing.

A separate Global Talent Trends report found that 92% of hiring professionals believe soft skills are equally or more important than hard skills when evaluating candidates. That's not a fringe opinion. That's a near-consensus across the people whose job is literally to predict who will succeed on a team.

This shift makes complete sense in the context of an IT pod specifically. A pod isn't a collection of individuals completing isolated tasks — it's a tightly interdependent unit where a designer's clarity affects a developer's speed, and a developer's communication affects a QA engineer's ability to catch issues early. The technical skill of any one person matters less than how well that skill connects to everyone else's.

The Three Traits That Actually Separate Great Pods

Beyond psychological safety as the foundation, three specific traits consistently show up in the highest-performing cross-functional teams.

Ownership over tasks. There's a meaningful difference between someone who completes their assigned work and someone who feels responsible for whether the product actually succeeds. In a great pod, a developer doesn't just write code that passes their own tests — they think about whether the feature will hold up under real customer use. This kind of ownership can't be mandated through a job description. It emerges when people feel genuinely included in decisions about what they're building and why it matters.

Communication that surfaces problems early. The instinct in most workplaces is to present good news quickly and bad news slowly, if at all. Great pods invert this. The team norm becomes: the sooner you say "this isn't working," the more useful you are — not less. This requires deliberate practice. Research on building psychological safety consistently points to leaders modelling vulnerability first — admitting their own mistakes openly before asking the team to do the same.

Adaptability over rigid expertise. LinkedIn's data shows that the skills required for any given role have changed by 25% on average since 2015 — and that number is projected to reach 65% by 2030. A pod built entirely around today's tech stack will struggle the moment that stack changes. A pod built around people who learn quickly and adjust their approach without ego will outlast almost any specific technology shift.

What This Looks Like Day to Day

None of this is abstract once you see it in practice.

A great pod's daily standup doesn't sound like a status report read aloud — it sounds like people genuinely checking in on blockers, because they know raising one won't make them look weak. Retrospectives in a great pod aren't performative; people actually name what went wrong, including their own part in it, because the team has built enough trust that doing so doesn't feel like an attack.

Disagreements in a great pod happen openly and get resolved quickly — not because everyone agrees, but because nobody is afraid to push back on an idea, including the team lead's idea. Research on high-performing teams found that organisations introducing norms that balance psychological safety with accountability saw teams become noticeably more open to challenging each other's ideas, which directly translated into stronger decision-making.

This is the texture of a healthy pod. It's not louder or more chaotic than a dysfunctional one. If anything, it's calmer — because problems get handled while they're still small.

Why This Matters More in a Pod Than in a Traditional Team

In a traditional, siloed IT structure, a weak link can sometimes hide. A disengaged developer on a 40-person engineering org might go unnoticed for months. The structure absorbs individual gaps because there are so many layers and so much redundancy.

A pod doesn't have that luxury — and that's precisely its strength. With 5 to 8 people sharing direct ownership of an outcome, every person's mindset, communication style, and sense of accountability shows up in the work almost immediately. There's nowhere to hide, but there's also nowhere for good behaviour to go unnoticed either.

This is why building a great pod requires thinking beyond a checklist of technical requirements. The right technical skills are necessary, but they're the entry criteria, not the differentiator. The differentiator is whether the people on that pod trust each other enough to be honest, care enough to take ownership beyond their individual tasks, and stay flexible enough to keep learning as the work evolves.

What to Look for When Building or Evaluating a Pod

If you're assembling an IT pod — whether internally or through a service provider — a few questions matter more than reviewing another technical portfolio:

Does this person ask questions when they're unsure, or do they quietly guess and hope it works out? Have they ever flagged a problem early, even when it wasn't convenient to bring it up? Do they take responsibility when something goes wrong, or do they default to explaining why it wasn't their fault?

These aren't soft questions. They're predictive ones. The research is consistent across Google's internal study, hiring trend data, and academic research on team performance: the teams that last, adapt, and deliver consistently aren't necessarily the most technically decorated. They're the ones where people feel safe enough to tell the truth, early and often.

Technical skill is the price of admission. It gets a person onto the pod.

What makes that pod great — what determines whether it ships reliably, adapts when requirements change, and catches its own mistakes before they become customer-facing problems — is something closer to psychology than résumé. Ownership, honest communication, and the willingness to stay flexible aren't soft additions to a good team. According to the research, they're the actual foundation.

The next time you're evaluating a team — your own, or one you're hiring — the technical questions are easy to ask. The harder, more useful ones are about trust.