Leadership on guy@secdev.uk

The New Shape of the Engineering Team

Mon, 30 Mar 2026 00:00:00 +0000

If AI can handle the boilerplate, the scaffolding, and a growing portion of routine implementation, what does that mean for how we compose engineering teams? It’s a question I’ve been turning over for a while now, and the answers I keep arriving at are uncomfortable.

The optimistic version is that AI frees engineers to focus on higher-value work, system design, problem framing, user understanding, architectural thinking. The pessimistic version is that it eliminates the entry-level work that junior engineers have traditionally used to learn the craft. The realistic version is probably somewhere in between, and navigating it well is one of the most important challenges facing technical leaders right now.

Rethinking Developer Productivity in the Age of AI Assistants

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

Lines of code per day was always a terrible productivity metric. With AI coding assistants, it’s become an absurd one. An engineer with Copilot or a similar tool can generate code at a pace that would have been unimaginable five years ago. If you’re measuring productivity by volume, every engineer just got a 3x raise. If you’re measuring it by value delivered, the picture is more complicated.

The more I’ve explored how AI assistants change engineering workflows, the more I’ve realised that the productivity conversation needs a fundamental reset. We’re not just doing the same work faster, we’re changing what the work is.

The AI Literacy Gap: Why Your Leadership Team Needs to Catch Up

Mon, 16 Mar 2026 00:00:00 +0000

With the emergance of AI/GenAI, I felt that I needed to think, and write, about the impact of AI/GenAI on technology leadership. The next series of articles will be exporing this topic. As an emerging topic, these articles may well be shorter, and I will try and publish them weekly when possible.

Most engineering leadership teams I talk to have a wide spread of AI understanding. On one end, you’ve got the enthusiasts, they’ve built agents, they use AI coding assistants daily, they can explain transformer architectures over a pint. On the other end, you’ve got leaders who haven’t meaningfully engaged with any of it. They’ve read the headlines, they’ve sat through a vendor demo, and they’re quietly hoping this is a hype cycle that will pass.

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.

Culture Is What You Do When Things Go Wrong

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

Every company I’ve worked at had values written down somewhere. Integrity. Innovation. Collaboration. Respect. They were on the website, in the onboarding deck, sometimes literally on the walls. And in most cases, they told you almost nothing about what it was actually like to work there.

Culture isn’t what you say you value. It’s what you do, especially when things go wrong. Ines Sombra puts it perfectly: “Culture is what happens when what we want to believe about ourselves is challenged. Culture is what we do when we get things wrong, when we witness a violation of trust, or when we stay silent when an inappropriate comment is said in our presence.”

Scaling Your Team Without Breaking What Works

Mon, 12 Jan 2026 00:00:00 +0000

I lived through this at a growth start-up where the engineering team tripled in under two years. At fifteen people, we were fast, aligned, and effective. Everyone knew what everyone else was working on. Decisions happened in hallway conversations. The culture was strong because it was small enough to be transmitted through proximity.

At forty-five people, almost none of that was true. Communication had broken down. New hires didn’t understand the culture because nobody had time to transmit it. Decisions that used to take minutes now took weeks because the number of stakeholders had multiplied. We were bigger, but we weren’t better, and for a painful period, we were actively worse.

Running Effective Retrospectives (and Actually Following Up)

Mon, 22 Dec 2025 00:00:00 +0000

Retrospectives should be the engine of continuous improvement. In practice, they’re often the meeting everyone tolerates but nobody values, a ritual performed out of obligation rather than conviction, producing sticky notes that get photographed and forgotten.

I’ve run hundreds of retrospectives over the years, and I’ve wasted more of them than I’d like to admit. The ones that worked had a few things in common. The ones that didn’t were all failing in the same ways.

Designing Good Process (Without Becoming a Bureaucracy)

Mon, 01 Dec 2025 00:00:00 +0000

Engineers hate process. Or rather, engineers hate bad process, and most process they encounter is bad. It’s imposed from above without understanding the problem it’s meant to solve. It adds overhead without adding value. It treats every situation the same regardless of risk or complexity. No wonder the word “process” makes people flinch.

But the absence of process isn’t freedom, it’s chaos. Having worked in both process-light start-ups and process-heavy corporates, I’ve seen both failure modes up close. The start-up where nobody knew how deployments worked because there was no documented process. The corporate where deploying a one-line change required three approvals and a change advisory board meeting. Neither extreme serves the team.

Outcomes Over Outputs: Measuring What Matters

Mon, 10 Nov 2025 00:00:00 +0000

Early in my career, I inherited a team with a beautiful dashboard. Every metric was green. Velocity was up. Story points completed per sprint were trending in the right direction. Code coverage was above the target. Release frequency was on schedule. By every measure on that dashboard, the team was performing brilliantly.

The product they were building had almost no users.

That was my introduction to what Osmani calls the watermelon effect, metrics that look green on the surface but are red underneath. The team was producing outputs at an impressive rate. They just weren’t producing outcomes that mattered.

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.

Onboarding That Goes Beyond Setting Up a Dev Environment

Mon, 29 Sep 2025 00:00:00 +0000

At one company I joined, my onboarding consisted of a laptop, a Confluence page titled “Getting Started,” and a Slack message saying “let us know if you need anything.” At another, I had a structured first week with an assigned buddy, a schedule of introductions, and a 30/60/90-day plan. The difference in how quickly I became effective was enormous, and it had almost nothing to do with the technical setup.

Hiring for Values, Abilities, Then Skills

Mon, 08 Sep 2025 00:00:00 +0000

Most engineering interviews are backwards. We spend the majority of our time evaluating technical skills, the thing that’s easiest to teach and quickest to develop, and almost no time evaluating values and abilities, which are much harder to change and far more predictive of long-term success.

I’ve made this mistake myself, repeatedly. I’ve hired brilliant engineers who turned out to be terrible collaborators. I’ve passed on candidates who weren’t the strongest technically but would have been exactly what the team needed. The more I’ve hired across start-ups and corporates, the more convinced I’ve become that we need to flip the order.

What Actually Makes an Engineering Team Effective

Mon, 18 Aug 2025 00:00:00 +0000

I spent the early part of my career believing that team effectiveness was mostly about talent. Get the best engineers, give them interesting problems, and get out of the way. It’s an appealing theory, and it’s wrong, or at least, it’s missing the most important part.

Google’s Project Aristotle studied 180 teams and ran 35 statistical models to find what made some teams effective and others not. The finding that surprised everyone, including Google, was that who was on the team mattered far less than how the team worked together. Individual talent, seniority, even team size, none of these were the primary drivers.

The Accidental Manager: Leading When You Didn't Plan To

Mon, 28 Jul 2025 00:00:00 +0000

Not every manager chose to be one. Sometimes the team grows around you and suddenly you’re the most senior person. Sometimes your manager leaves and someone needs to fill the gap. Sometimes the company is too small to hire a dedicated manager, and you’re the engineer who seems most capable of doing it alongside your technical work.

However it happens, you find yourself managing people without ever having made a deliberate decision to pursue management. And the question you’re left with is: now what?

When You Miss Writing Code

Mon, 07 Jul 2025 00:00:00 +0000

There’s a particular kind of melancholy that hits engineering managers around the six-month mark. You’re in your fourth meeting of the day, you’ve just spent an hour on a spreadsheet, and you glance over at your team, heads down, headphones on, deep in the flow state you remember so well. And you think: I miss that.

I still feel it. After all these years, there are days when I’d trade every meeting on my calendar for four uninterrupted hours with a codebase and a problem to solve. The feeling doesn’t go away. But understanding it, what it actually is, and what to do with it, makes it manageable.

Finding Your Leadership Style

Mon, 16 Jun 2025 00:00:00 +0000

For years, I tried to lead like other people. I’d read about a leader I admired, adopt their approach, and wonder why it felt forced. It took me longer than I’d like to admit to realise that leadership style isn’t something you copy, it’s something you discover through practice, reflection, and a fair amount of getting it wrong.

The good news is that there’s no single correct way to lead an engineering team. The bad news is that your natural style, whatever it is, won’t be sufficient for every situation. The best leaders I’ve worked with aren’t the ones with the most charismatic style, they’re the ones who can shift between styles depending on what the moment requires.

The Trap of Doing Two Jobs

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

I’ve fallen into this trap more than once. You get promoted, you take on the new responsibilities, and you keep doing the old ones too. Not because anyone asked you to, but because the old work is familiar, you’re good at it, and there’s a voice in your head saying “if I don’t do this, it won’t get done right.”

That voice is wrong. Or rather, it might be right in the short term, but it’s catastrophically wrong in the medium term. Doing two jobs doesn’t make you indispensable, it makes you a bottleneck, and it prevents your team from growing into the space you’re supposed to have vacated.

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.

Your First 90 Days as an Engineering Leader

Mon, 14 Apr 2025 00:00:00 +0000

The first 90 days in a new leadership role are simultaneously the most important and the most disorienting period of your tenure. Everything feels urgent. Everyone has opinions about what you should focus on. And the temptation to prove yourself by making immediate changes is almost irresistible.

Having started new leadership roles at both start-ups and large corporates, I can tell you that the single most valuable thing you can do in those first 90 days is slow down. Not because urgency isn’t real, but because acting on incomplete understanding almost always creates more problems than it solves.

Learning to Delegate (and Why It Feels So Wrong)

Mon, 24 Mar 2025 00:00:00 +0000

Early in my management career, I had a team of six engineers and I was still the person who knew the most about every part of the system. When something urgent came up, I’d fix it myself. When a design decision needed making, I’d make it. When a PR needed reviewing, I’d review it. I was efficient, responsive, and completely unsustainable.

It took a holiday, a proper two-week break where I was genuinely unreachable, for me to see the problem. The team didn’t fall apart while I was away. But they didn’t move forward either. They’d been waiting for me on three separate decisions, and nobody felt empowered to make them without my input. I’d created a team that was dependent on me, and I’d done it by being “helpful.”

Staying Technical as You Move Up

Mon, 03 Mar 2025 00:00:00 +0000

When I moved into my first management role, a more senior leader told me: “You’ll stop writing code within six months.” He said it like it was inevitable, a law of nature. I took it as a challenge. Twenty-five years later, I still write code. Not as much as I used to, and not the same kind, but I’ve never fully let go. And I think that’s been one of the most important decisions of my career.

What Nobody Tells You About Being a Tech Lead

Mon, 10 Feb 2025 00:00:00 +0000

The tech lead role is one of the most misunderstood positions in engineering. It’s not a title, it’s a set of responsibilities. It’s not a promotion, it’s a lateral move into a fundamentally different kind of work. And it’s where most engineers first discover whether they enjoy leadership, or whether they’d rather stay deep in the code.

I’ve been a tech lead multiple times across my career, and I still think it’s the hardest role in engineering. Not because the problems are the most complex technically, but because you’re pulled in three directions simultaneously and nobody tells you how to balance them.

The Identity Crisis of Becoming a Manager

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

The day I officially became a manager, I still wrote code. The day after that, I still wrote code. For weeks, I kept writing code, attending the same standups, reviewing the same PRs, and fitting “management stuff” into the gaps. It took me an embarrassingly long time to realise that I hadn’t actually changed what I was doing. I’d just added a new title to the old job.

That’s the trap, and nearly everyone falls into it.

The Loneliness of Technical Leadership (and What to Do About It)

Mon, 30 Dec 2024 00:00:00 +0000

Nobody warns you about this part. You get promoted, you take on more responsibility, you start leading people, and somewhere along the way, you realise you have fewer people you can be genuinely honest with. The higher you go, the smaller that circle gets.

I’ve felt this at different points across my career, at a start-up where I was the only technical leader, and at a large corporate where I was surrounded by peers but couldn’t always be candid about what was going wrong. The loneliness of leadership isn’t about being physically alone. It’s about the growing gap between what you’re carrying and who you can share it with.

Building Diverse Teams That Actually Work

Mon, 09 Dec 2024 00:00:00 +0000

This is one of those topics where I’ve watched the conversation evolve significantly over the course of my career. Twenty-five years ago, “diversity” in tech largely meant making sure the team photo didn’t look entirely homogeneous. The bar was low, and most of us, myself included, didn’t think critically enough about what we were missing. The more I’ve researched this topic and reflected on my own experience leading teams of different shapes and sizes, the more I’ve come to believe that diversity isn’t just the right thing to do. It’s the thing that makes teams actually work better. But only if you pair it with genuine inclusion. Without that, it’s just optics.

How to Have Difficult Conversations

Mon, 18 Nov 2024 00:00:00 +0000

There’s a particular kind of dread that settles in the night before you know you have to have a difficult conversation. You rehearse it in the shower. You draft opening lines in your head while making coffee. You tell yourself it’ll be fine, and then you spend the rest of the morning hoping the other person calls in sick.

I’ve been having difficult conversations as a manager for a long time now, and I want to be honest about something: they don’t get easier. What changes is that you get better at having them. You learn to sit with the discomfort rather than rushing through it. You learn that the conversation you’re dreading is almost never as bad as the one you’ve been having with yourself about it.

Communication Is a Craft, Not a Soft Skill

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

For most of my career as an IC, the code did the talking. If the system worked, the message was clear. If the tests passed, the argument was won. Communication meant writing commit messages, maybe the occasional design document, and turning up to stand-up with something coherent to say.

Then I moved into leadership, and I discovered something uncomfortable: the thing I’d spent the least time deliberately practising was suddenly the thing I needed to be best at. Not architecture. Not debugging. Communication.

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.

Giving Feedback That Actually Lands

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

There’s a moment I remember clearly from early in my management career. I’d prepared what I thought was a really well-structured piece of feedback for someone on my team. I’d thought about the situation, the behaviour, the impact, the whole lot. I delivered it calmly, clearly, and with good intentions. And it landed like a brick through a window.

The person shut down. They nodded politely, said “okay, thanks,” and I could see the shutters come down behind their eyes. Whatever I’d intended to communicate, what they’d received was something entirely different. That gap, between intending to give helpful feedback and having it actually received that way, is enormous. And I’ve learned the hard way, more than once, that closing it takes far more than just getting your words right.

The Art of the One-on-One: Beyond Status Updates

Mon, 15 Jul 2024 00:00:00 +0000

In the first article in this series, I wrote about psychological safety, the foundation that makes everything else in leadership possible. If there’s one place where that foundation gets tested every single week, it’s the one-on-one.

I’ll be honest: my early one-on-ones were terrible. I’d sit down with a report, open Jira, and essentially run a standup for two people. “How’s the migration going? Any blockers? Cool, see you next week.” I thought I was being efficient. What I was actually doing was wasting the most valuable recurring meeting on my calendar, and probably theirs too.

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.”