Team-Dynamics on guy@secdev.uk

The Anti-Patterns That Kill Teams

Mon, 23 Feb 2026 00:00:00 +0000

Most team dysfunction isn’t unique. It follows recognisable patterns that repeat across organisations, industries, and decades. The good news is that if you can name the pattern, you’re halfway to fixing it. The bad news is that most leaders don’t recognise the patterns until the damage is well advanced.

Osmani catalogues these anti-patterns extensively, and I’ve encountered most of them across my career. Here are the ones that I’ve seen do the most damage, organised by where they originate.

The Case for Team Stability

Mon, 20 Oct 2025 00:00:00 +0000

There’s a persistent belief in engineering organisations that moving people between teams is healthy, it spreads knowledge, prevents silos, and keeps things fresh. I understand the appeal. I’ve also watched it destroy team effectiveness more times than I can count.

The research is clear, and my experience confirms it: stable teams outperform shuffled ones. Not by a little, by a lot. And the reasons are rooted in how humans actually build trust and develop working relationships, not in how org charts look on a slide.

Managing Former Peers

Mon, 05 May 2025 00:00:00 +0000

There’s a particular kind of awkwardness that comes with being promoted above people you used to sit next to as equals. Yesterday you were peers, debating technical approaches over coffee. Today you’re their boss, responsible for their performance reviews, their career development, and potentially their continued employment. The relationship has fundamentally changed, and pretending otherwise is the worst thing you can do.

I’ve been on both sides of this, promoted above peers, and managed by someone who used to be my equal. Neither side is comfortable, and both require deliberate effort to navigate well.

The Brilliant Jerk Problem

Mon, 07 Oct 2024 00:00:00 +0000

There’s a conversation that every engineering leader has at some point. It usually starts with something like: “Yeah, they’re difficult, but they’re the only person who understands the billing system.” Or: “I know people find them hard to work with, but their output is incredible.” You nod along, because you’ve probably said something similar yourself. I certainly have.

The brilliant jerk problem is one of those leadership challenges that feels genuinely hard the first time you face it, and blindingly obvious in hindsight. Someone on your team produces exceptional technical work, maybe they’re the fastest coder, the one who understands the gnarliest parts of the system, the person who can debug anything. But they also make people feel small. They dismiss ideas with contempt. They create an atmosphere where others are afraid to speak up, ask questions, or challenge anything.

Managing Conflict Without Avoiding It

Mon, 16 Sep 2024 00:00:00 +0000

I used to think I was good at managing conflict. What I was actually good at was avoiding it.

Early in my management career, I’d watch two engineers disagree about an architectural approach and my instinct was to smooth things over. Find the middle ground. Suggest we “take it offline.” Anything to get past the uncomfortable moment and back to something that felt like progress. I told myself I was being diplomatic. In reality, I was being a coward, and I was making things worse.

Trust as a Leadership Currency

Mon, 26 Aug 2024 00:00:00 +0000

Early in my management career, I inherited a team that had been through a rough patch. Their previous lead had been technically brilliant but unpredictable, generous with praise one week, dismissive the next. Decisions were made behind closed doors and communicated as faits accomplis. By the time I arrived, the team had learned a very rational behaviour: keep your head down, don’t volunteer ideas, and never be the one to deliver bad news.

Why Psychological Safety Is the Foundation Everything Else Sits On

Mon, 24 Jun 2024 00:00:00 +0000

You can have the best engineers, the clearest roadmap, and the most elegant architecture in the world, and none of it will matter if your team doesn’t feel safe enough to speak up when something’s wrong.

I’ve been leading engineering teams for over two decades now, across start-ups and large corporates, and if there’s one thing I keep coming back to, it’s this: the teams that performed best weren’t the ones with the most talent. They were the ones where people felt safe enough to be honest. Safe enough to say “I don’t understand this,” or “I think we’re making a mistake,” or “I need help.”