Developing Your Team Development Skills

I once worked with a product team that was technically brilliant but completely dysfunctional. They shipped regularly, hit their OKRs, and couldn’t stand working together.

Team development isn’t about annual retreats or trust-building exercises, though those can help. It’s about creating the conditions where people can do their best work and grow whilst doing it. That’s harder than it sounds, especially when you’re under pressure to deliver.

The Foundations That Actually Matter

Psychological Safety Isn’t Optional

This phrase gets thrown around so much it’s lost meaning. But I’ve seen firsthand what happens when teams lack it. People stop raising concerns. They don’t admit mistakes until they’re catastrophic. Good ideas die in people’s heads because they’re afraid of looking stupid.

At Spotify, they’ve built this into their operating model through blameless post-mortems and explicit norms around experimentation. When something breaks, the question isn’t “who’s responsible?” but “what can we learn?”

I tried implementing this with that dysfunctional team I mentioned. The first post-mortem was painful. Everyone was defensive, pointing fingers, covering their backs. But we persisted. We established a rule: you can critique decisions or processes, but not people. If you identify a problem, you need to suggest a solution.

A couple of months later, the same team that couldn’t have an honest conversation was voluntarily sharing failures and asking for help. The shift wasn’t dramatic, it was gradual. But it was real, and it changed everything about how we worked.

Clear Expectations and Ruthless Prioritisation

I’ve never met anyone who enjoys ambiguity at work. Yet most teams operate in a fog of unclear expectations and competing priorities. It’s exhausting and demoralising.

The best team leaders I’ve worked with are almost boring in their clarity. They repeat themselves constantly. They write things down. They check understanding rather than assuming it. When priorities shift, and they always do, they communicate the change explicitly and explain the reasoning.

Building Skills Through Deliberate Practice

Make Learning Part of the Work

Most companies separate learning from doing. You work on features Monday to Thursday, and maybe you get some “professional development time” on Friday afternoon if nothing’s on fire. This is backwards.

The best learning happens in the context of real work. When you’re wrestling with an actual problem, you’re motivated to learn. The knowledge sticks because you apply it immediately.

I tried an approach where team members lead deep-dives on technologies or techniques they’d recently learned. Not formal training sessions - just “here’s something interesting I discovered, and here’s how it might help us.” It forced people to synthesise their learning and share it in a way that was immediately applicable.

The trick is making this normal rather than special. If learning only happens during designated time, it signals that it’s separate from “real work.” When learning is woven into how you operate, it becomes part of the team’s identity.

Create Space for Mentorship

This one’s tricky because everyone’s busy and mentorship sounds like another meeting on an already packed calendar. But I’ve found that the best mentorship doesn’t happen in scheduled sessions, it happens in the flow of work.

Pair programming, design reviews, collaborative problem-solving, these are all mentorship opportunities if you treat them that way. The senior person isn’t just getting the work done; they’re thinking aloud, explaining their reasoning, demonstrating how they approach problems.

Scaling Without Losing Culture

When Informal Stops Working

Every team reaches a point where what worked at eight people doesn’t work at twenty. Communication that happened naturally now requires coordination. Decisions that everyone was involved in now need a process.

This transition is awkward and uncomfortable. People who thrived in the early chaos struggle with emerging structure. Those who want clear processes get frustrated by lingering informality.

At Slack, they dealt with this by explicitly defining operating principles as they grew. Not rigid processes, but guidelines about how they wanted to work together. Things like “prefer documentation over meetings” and “make decisions at the lowest possible level.” This gave enough structure to scale whilst preserving the culture they valued.

When the team I led grew from twelve to thirty people, we did something similar. We wrote down our working agreements—not policies, but shared expectations about things like response times, meeting norms, and decision-making. It felt bureaucratic at first, but it actually preserved the collaborative culture by making implicit norms explicit.

Building Leadership Capacity

The mistake I see most often: trying to preserve the founding team dynamic as you scale. The early team members try to stay involved in everything because that’s what success looked like when you were small. But it doesn’t scale, and it bottlenecks the entire organisation.

I’ve learned to start delegating early, even when it feels premature. Not just tasks, but actual decision-making authority. This requires building context and judgment in team members, which takes time. If you wait until you’re overwhelmed to start delegating, you’re already too late.

The way I approach this now: identify decisions I’m currently making, ask myself who else could make them with 80% of the quality, then actively work to transfer the context and authority they’d need. It’s uncomfortable because you know you could do it better, but that’s not the point. The point is building capacity so the team can scale beyond you.

The Hard Conversations

Addressing Performance Issues Early

This is where most leaders, including me, struggle. We avoid difficult conversations because they’re uncomfortable. We hope the problem will resolve itself. It rarely does, and the delay makes everything worse.

I once let a performance issue drag on for nine months because I didn’t want to have the conversation. By the time I finally addressed it, the team member was defensive, the team was frustrated, and the situation was far harder to resolve than it would have been if I’d acted earlier.

The lesson I learned: clarity is kindness. When someone isn’t meeting expectations, they deserve to know clearly and specifically what needs to change. Not in a performance review three months later - immediately, in the moment, with concrete examples.

Knowing When Someone Isn’t the Right Fit

Sometimes, despite everyone’s best efforts, it doesn’t work out. Someone might be talented but not suited to the role, the team, or the company’s stage. Recognising this and acting on it is one of the hardest parts of team leadership.

I’ve made the mistake of keeping someone too long because I liked them personally or felt responsible for making it work. It’s not fair to them, and it’s definitely not fair to the team who has to pick up the slack.

The framework I use now: can this person succeed in this role with reasonable support and time? If yes, what’s the plan and timeline? If no, what’s the kindest way to help them transition to something better suited to their strengths?

Key Takeaways

• Psychological safety is the foundation: Without it, team members won’t take risks, admit mistakes, or bring their full selves to work. Build it intentionally through how you respond to failure and uncertainty.
• Make learning continuous, not occasional: Integrate skill development into daily work rather than treating it as separate. The best learning happens when solving real problems.
• Delegate decision-making, not just tasks: Build leadership capacity early by transferring both context and authority. Don’t wait until you’re overwhelmed.
• Have hard conversations early: Clarity is kindness. If someone isn’t meeting expectations, they deserve to know specifically and quickly, not months later in a formal review.
• Adapt your approach as you scale: What worked at eight people won’t work at thirty. Make implicit norms explicit, and build structure that preserves culture rather than constraining it.

Final Thoughts

Team development isn’t a programme or an initiative—it’s how you operate every day. It’s the small decisions about how you communicate, how you respond to failure, how you make space for growth, and how you handle difficult situations.

I’m still learning. Every team is different, and what works in one context might fail in another. But the underlying principles remain: create clarity, build trust, develop capability, and have the courage to address issues directly.

The investment in team development pays compound interest. Teams that continuously improve become more effective, more resilient, and more satisfying to be part of. That creates a virtuous cycle that benefits everyone.

Have questions or thoughts? Get in touch - I’d love to hear from you!