Article 5 of 12 — Building Design Teams

Most onboarding, if we’re honest, is just a boring logistics exercise involving the waving of a welcome banner. The laptop arrives, or doesn’t. IT provisions the accounts, well some of them before you go into a screaming rant in a teams call. Then there’s the mandatory e-learning module about phishing and another about fire exits and on and on it goes.

By Friday everyone agrees the onboarding is “sorted,” and the new designer has learned precisely one thing that is carved into the back of their skull - where the company keeps its compliance training. None of that is onboarding - it’s admin. I’m sure we can all agree that admin has never once made anyone feel wanted.

The person sitting through the phishing module isn’t marvelling at the wondrous way this organisation looks after its cyber hygiene. They’re wanting answers to quesrtions a sharepoint page cannot answer: who are these people, how do they actually work when nobody’s on show for the induction schedule. They may be wondering if there actually is room here for the specific thing they were hired to do? The first ninety days will answer that question, whether or not you deliberately tried to produce the right answer or not.

Most of us don’t, and then spend the following year wondering why the perfect new hire never quite solved the problem we identified in the first place.

You hired for a gap. So get in there and prise one open!

Last time, I made the case for hiring the person who fills a gap in the team rather than the one who simply dazzles. That’s the harder half of the job, but it isn’t the whole job.

So, you’ve found the person whose instinct is exactly what the team was missing. Congratulations! You’ve also just created a problem that the interview process was never going to solve for you: a team that has spent months or years optimising itself to work around the gap now has to actually make room for the new person standing in it.

Teams, like most established systems, are definitely not ‘ok’ about newcomers. They have weird habits, off-the-wall inside jokes, and unwritten rules about who gets the final word in a critique (we have someone I jokingly call ‘The Sheriff’). There is a familiar, organic, way of doing things which no one ever questioned because it worked well enough. Then into this walks someone whose entire value, in theory, is that they think differently. The team’s first instinct, not malicious or mean but just very human, is to smooth them out. They explain, kindly, “this how we do things here” until the very difference in the person you hired for gets sanded off.

This is the part of hiring for the gap that nobody warns you about. You don’t just have to find the right person. You have to actively and robustly defend the reason you hired them. Worse still, you have to do this for at least ninety days, against a team that will otherwise absorb them without meaning to. ‘One of us, one of us’ is now chanting in my head…

The two ways it goes wrong

There are two failure modes here and they sit at opposite ends of the same problem, which is why it’s so easy to fix one and simultaneously, accidentally cause the other.

The first is the obvious one: the new graft doesn’t take. The newcomer stays visibly, permanently, apart from the rest. They’re talked over in meetings, their suggestions get a polite nod and no follow-through, but after a few months of this they conclude, not unreasonably, that there was never really space made for them. Some leave. The ones who don’t end up in a worse situation, because they stay and stop trying altogether. The team loses everything it hired them for, through no one team member’s fault, but holistically the game is lost.

The second failure is more subtle, and I think it’s the one that has a more negative effect on design teams, because it looks so much like success. The newcomer, sensing, quite reasonably, that fitting in is the path of least resistance, works out what the team rewards and starts producing exactly that. Within a few months they’re indistinguishable from everyone else. Everyone’s pleased. The onboarding is declared a triumph and the gap you spent months hiring to fill has just quietly reopened, because the reason you hired them, that different insight and approach or ability to ask the awkward question, whatever made them worth the risk, has been sanded down to nothing by a team that was, without any bad intent, trying to be welcoming.

You can hire brilliantly and still lose the entire point of the hire in the first three months, and it will look, from the outside, exactly like things going well.

What actually protects the gap

Protecting against the first failure is the half everyone already half-knows: give the newcomer a real, finishable problem early, rather than either drowning them in the highest-stakes project in the building or parking them on busywork “until they find their feet.” Both of those, in different ways, tell a new hire there isn’t really a place for them yet. A real problem, sized so they can actually land it, is worth more in week three than any amount of onboarding paperwork.

Protecting against the second failure, what I’m calling the ‘sanding-down’, takes something most onboarding plans never mention, which is telling the newcomer, explicitly and more than once, what you hired them for. Not the job description, but the gap. “You ask the question the room usually skips” or “you slow things down in exactly the place we need slowing down” is a completely different piece of information from a list of responsibilities, and it changes how someone behaves in their first critique. Without it, most new designers assume their job is to prove they belong by fitting in as fast as possible, which is exactly backwards. Named early enough, the difference becomes something they’re allowed to keep, rather than something they trade away, one small accommodation at a time, out of politeness.

The other lever, and the one I got wrong for years, is who you pair them with. The instinct is to buddy the newcomer with whoever’s most similar. The same seniority and speciality, the same general interests and attitude, on the theory that like understands like. Resist it!

Similarity produces comfort, not integration; two people who already think alike will happily reinforce each other’s blind spots and call it bonding. Pair the newcomer instead with someone who works differently from them, ideally someone senior enough to have real standing in the room, and ask that person to do one specific thing: notice, out loud, when the newcomer’s different instinct produces a better answer, and say so in front of the team. That single sentence, repeated a handful of times over three months, does more to protect a gap-hire’s distinctiveness than any induction pack ever written.

Ninety days, not ninety minutes

None of this happens in the first week, which is exactly why it gets skipped. The first week is incredibly loud and can be joyfully chaotic. Laptops, logins, introductions, a slightly too-enthusiastic welcome message in Microsoft Teams (yes, I’m that guy). The real work of onboarding happens in the quiet stretch after that, week six or seven, when the novelty has worn off and the team has started treating the newcomer as a known quantity, for better or worse. That’s the moment the gap either survives or doesn’t, and it’s usually happening without anyone in the room actively deciding it.

Ninety days isn’t a countdown to “fully onboarded.” It’s the window in which a genuinely different person either gets folded into a team as themselves, or just gets folded in by becoming slightly less themselves. Only the first version was worth the hiring panel’s trouble. Nobody schedules a one-to-one for the second version and so it just happens, quietly and unremarkably, while everyone congratulates themselves on a smooth start.

Next up: you’ve protected the gap in one designer. Now try doing it across four time zones, three cultures, and a team that’s never once been in the same room. Cohesion gets a lot harder, and a lot more interesting, once “the team” stops meaning “the people near my desk.”

Article 4 of 12 — Building Design Teams

There is a particular kind of CV that arrives once or twice a year and ruins your judgement for the rest of the afternoon. Their education is immaculate. Their portfolio is the sort of thing that makes you quietly close your own portfolio in a different tab. Every position they have held is a place you’d kill to have worked, or a problem you’d kill to have solved and (worst of all) a logo you recognise. You finish reading it and the only coherent thought in your head is: yes, obviously, hire this person, what are we even discussing here?

That feeling is the single most reliable way I know to miss the best hire.

Not because the person is bad. Usually the opposite because they’re confident and technically excellent, and that’s the whole problem. The danger is that “excellent” is doing all the work in your head, and you’ve quietly stopped asking the only question that actually matters, which is: excellent at what we already have too much of, or excellent at the thing we’re missing?

A team is a shape with a hole in it

Back in the first piece in this run, I made the case that you grow a team, you don’t assemble one. That treating hiring as a series of individual acquisitions gets you a list of people, not a team. Hiring for the gap is where that idea stops being a nice sentiment and starts costing you actual decisions.

Here’s the thing about a team that’s been running for a while: it has a shape. It’s brilliant at certain things and curiously often, consistently terrible at others. That part is rarely random. It’s the silhouette of who’s already there. Take a team of confident, fast, opinionated designers who will ship beautiful work at speed yet will also constantly talk all over the one quiet opposing person in the room and never once stop to check whether the thing they’re shipping so beautifully is the right thing at all.

That team does not need another confident, fast, opinionated designer. It is drowning in those. It needs the person who slows the room down and asks the unfashionable question. But that person, on paper, often does not out-dazzle the confident others. Their CV is quieter. Their portfolio has fewer fireworks and more “here’s the disaster we avoided,” which is the hardest kind of work to put in a portfolio because by definition nothing visible happened.

So you hire another firework, because fireworks interview much better, but the result is that your team gets even faster at being wrong.

The gap is usually not a skill

When people first hear “hire for the gap,” they reach for the skills matrix. That spreadsheet with names down the side and competencies along the top, hunting for the empty cells. There’s nothing against motion design. Right, hire a motion designer. Fair enough, sometimes the gap really is that legible, and a spreadsheet will find it.

The gaps that actually hurt are rarely on the spreadsheet, because they aren’t hard skills. They’re temperaments, behaviours, perspectives, or simply just ways of seeing.

In the enterprise design teams I have led, our worst stretch always comes when we are, on paper, at our strongest. Every seat has been filled, every skill has been covered, and everyone is genuinely good. Yet we would still ship things that were elegant but wrong because we were solving the problem cleanly without ever checking that it was the actual problem worth solving.

No cell on any skills matrix was empty. The gap in the team was a person who instinctively distrusted a brief, who’d been close enough to a real user’s frustration that “the requirements say so” made them twitch. That reflex wasn’t anywhere in the room. A group of people who could answer any question beautifully and backed up with heuristics, but nobody whose first move was to ask whether it was the right question.

You cannot put “twitches at a bad brief” in a job posting. Yet it was the most expensive thing we were missing.

Find the gap by looking at the failures, not the people

The trap is to figure out your gap by listing what your team is good at and inverting it. That gives you a tidy list and the wrong answer, because teams are good at things in flattering ways and bad at things in embarrassing ways, and the embarrassing ways are almost always where the gap lives.

So stop asking “what are we good at?” and start asking “what do we get wrong in the same way every single time?” Not the one-off disasters because those are just part of life, but the patterned ones. The mistake the team makes so consistently that everyone’s learned to shrug at it like the weather (although in the UK that might not be the best analogy!).

In one team I led, the pattern only became clear once I said it out loud: the team was over-engineering every time. Give us a small building to design and we’d return a cathedral. That wasn’t a skills gap, it was a missing instinct toward restraint. Once it was named, I knew exactly who I was hiring for. Not the most technically impressive designer in the CV pile. The one whose work was conspicuously, almost suspiciously, simple.

The consistent failure is the negative space. So hire into the negative space!

This is harder than it sounds, and not for the reason you think

The difficulty isn’t spotting the gap. The difficulty is that hiring for it means, fairly often, choosing the candidate who is less immediately impressive than someone else in the pile — and then defending that choice to a hiring panel who all read the same dazzling CV you did and arrived at the same afternoon-ruining conclusion.

You will sit in a debrief and watch a genuinely excellent candidate get five enthusiastic yeses, and you’ll be the one going “I know, I know, but I think we should pass on this one.” That is an uncomfortable sentence to say out loud. It sounds like you’re being difficult, or have impossibly high standards, or you secretly didn’t like them for a less acceptable reason. What you’re actually doing is your job: holding the shape of the team in your head while everyone else is holding a single brilliant CV.

One guardrail, because this idea is easy to abuse: hiring for the gap is not a licence to hire someone mediocre and call it diversity of thinking. The gap still has to be filled by someone genuinely good. You’re not lowering the bar, but you’re moving it sideways. You’re saying that ‘good’, for this seat, means something different from what it meant last time, and that the quiet candidate who fills the gaping hole is, for this team, the stronger hire than the loud one who’d have made the hole deeper. If you ever find yourself using “fills a gap” to wave through someone you have private doubts about, you’ve stopped hiring for the gap and started hiring for the excuse.

What you’re actually building

The shift, in the end, is from ‘collecting people’ to ‘completing something’. A great hire doesn’t have to be the most impressive person who applied. That is a huge factor, don’t get me wrong, but it’s the person who makes the people you already have be better. This is achieved by being unlike them in exactly the way the team really needs.

This is a far less flattering way to hire, of that there’s no doubt. There’s no thrill quite like landing the candidate with the spectacular CV, and the gap-hire won’t give you that hit unless you have the team shape in mind. The reward comes three months later, when you notice the team’s predictable old failure mode has quietly stopped happening, and you realise it stopped happening the week that one new person started.

Next up: you’ve hired for the gap. Now you have to fold the person in. Without the team’s immune system rejecting them, and without them quietly reshaping themselves to match everyone else and filling no gap at all. That’s the first 90 days, and it’s a team event, not an HR checklist.

Article 3 of 12 — Building Design Teams

Nobody walks past an engineering team and suggests the database might be nicer in blue. Nobody leans over a data scientist’s shoulder to say the regression model feels a bit cold and have they tried warming it up by softening the edges? But everyone (and I mean everyone), up to and including a colleague’s visiting in-law who wandered into the wrong meeting, feels qualified to redesign your product’s screen layouts and UI.

That’s the first weird thing about leading a design team. The work is visible, it looks like it is ruled by personal taste, and taste is the one form of expertise that every single person believes they already possess.

Over the better part of two decades I’ve led a number of enterprise software design teams. Most of the management advice I absorbed along the way assumed that the team’s output could be measured cleanly and that nobody outside the team, after reviewing the output, would feel entitled to crudely redraw it by themselves with a marker. Design isn’t that. It’s messy and the output is judged the second it’s seen. Oh, and the judging feels very pointed and personal. Managing my way through all of that required trying a few things that generic leadership books don’t quite prepare you for.

Keeping it simple, here’s three of them.

Critique without ego

In most disciplines, the work and the person are separated by at least a thin layer of abstraction. Code gets reviewed, but the reviewer or tester is looking at logic, not at the engineer’s inner mind. Design has no such buffer. A designer puts their screen design up on the full screen view, bearing in mind that it is a thing they made dozens of small decisions about, each one a tiny act of judgement. Then hearing someone say “This isn’t working” can sound, if you’re not careful, like “You aren’t working.”

So critique, which is supposed to be the engine that makes the work better, becomes the thing designers often start to dread. A designer who dreads critique stops taking risks. They start showing you the safe option, the one nobody can object to, which is also the one nobody will remember and sadly often isn’t best for the user.

The solution then is not to be gentler. Gentle critique that never says anything true is just a longer way of wasting everyone’s afternoon. The fix is to make the critique focus relentlessly on the work’s job to be done rather than the maker’s worth. Every piece of design is trying to do something: help someone finish a task, understand a number, not rage-quit a form. So the question in the room is never “Do I like this?” It’s “What is this trying to do, and (more importantly) is it doing it?”

That sounds like a small reframe. It is not. It moves the whole conversation away from focusing on the designer and onto a shared target that everyone, including the designer, is now standing beside and squinting at together. But this reframe only works on a foundation that can’t work without trust. When designers genuinely believe the room is on their side and that the people critiquing the work understand both them and what they were trying to do, then critique stops being a delicate event you have to choreograph. It becomes a quick, tactical, almost throwaway thing. Move that left. Why two type sizes here? This label’s doing too much. Ego-free critique doesn’t mean a room with no feelings in it. It means a room where the bonds are strong enough that the feelings can show up and nobody flinches.

It is easy to say ‘you need trust’, but the honest truth is that this takes time and effort from a leader that values culture and outcomes over pressure and output.

Autonomy without chaos

Designers need room to make decisions. Take that away, and you get an order-taker. Just someone who executes your taste, resents you for it, and updates their CV in the margins. Creative people who aren’t trusted to be creative don’t stay, and the ones who do stay stop being much use.

But hand over total freedom and you get a different problem, which is a product with eleven shades of grey, four competing ideas about what a button is, and a navigation pattern that changes depending on which designer was closest to the ticket. Each screen on its own meets its requirements and is defensible. However, together they look like they were made by a committee that never met and the end result is disjointed and annoying to the user.

The resolution to this is the least intuitive thing I learned as a design leader: constraints are not the enemy of creativity; they’re the delivery mechanism for it. A shared design system, a few genuine principles, and a clear statement of the problem to be solved. These aren’t a cage and they’re the thing that lets a designer stop over-analysing tiny details in the width of margins and spend their creative energy on the part that actually matters. This is autonomy within a frame.

Building and holding that frame is the leader’s job, and almost nobody outside the team sees you doing it. When it works, the team looks like it’s just naturally aligned. It is not naturally anything. None of this is an accident. It works because you built the entire team ethos around a shared understanding and agreement on the rules of engagement.

Defending design to people who think it’s just making it look pretty

Here is a sentence I have heard, in various contexts, more times than I can count: “Can you get the designers to make it a bit more sexy? ”. Worse still, they could ask you to “Make it pop”.

To a lot of the business, ‘design’ means ‘decoration’; the coat of paint you roll on at the end so the real work looks nice for the demo. Which means the design team is forever at risk of being treated like a paint shop: handed something nearly finished and asked to prettify it on a deadline that assumes prettifying is all it is.

The design leader’s job, more than anything else in this list, is translation. Not because the business is stupid (it isn’t!) but because it speaks a different language. Design decisions are worthless to it until they’re connected to a consequence it already cares about. “This spacing is more elegant” is true but is guaranteed to land on deaf ears. “This is why people stopped abandoning the form halfway through” is the same decision but translated into a language that the budget holders understand: value.

So you learn to do the translation constantly, and you learn to do something harder: to stand as a barrier between the design team and the demands to “just-make-it-pretty”. To keep insisting, politely, with evidence, that the team is solving problems, not applying gloss. You absorb that pressure so your designers don’t have to. They get to do the craft. You get to spend your meetings explaining, for the hundredth time, that they are not the paint shop.

The actual job

None of these are leadership techniques bolted onto the side of running a design team. They are running a design team. The work is personal, so critique has to protect the person while improving the work. The work is creative, so autonomy has to coexist with coherence. Finally, the work is chronically misunderstood, so someone senior has to keep translating its value to the people holding the money.

So here’s the part that took me longest to see: you don’t achieve these three things separately, with three different toolkits. They rest on the same foundation: a shared culture. This consists of real bonds of trust and a genuine understanding of one another and the work lying ahead. This is also the thing that makes critique tactical instead of fraught, makes autonomy safe instead of chaotic, and makes the team trust you to go and absorb the business pressure on their behalf. Building that culture is the actual job. The three weird requirements are just what it looks like, from the outside, once you’ve done it.

Do all three of these things well, and the team looks, from the outside, like a group of productive, talented people who happen to get along really well and enjoy their work. It should be perceived by stakeholders in all directions as ‘just another functional team’ in the business because the weirdness and quirks of the design function have been absorbed and translated by you so completely that nobody can see it any more.

Which raises the obvious next question: if this is what design teams look like inside and out, how do you actually assemble one? Not necessarily by hiring the most qualified individuals, it turns out (not that I would ever hire someone who isn’t impressive 🙂), but curating talent in a team is not done in a straight line. That’s where most of us go wrong.

Next up: hiring for the gap, not the résumé — why collecting the most qualified individuals is the fastest way to build a team that’s counterintuitively less than the sum of its parts.

Article 2 of 12 — Building Design Teams

There’s a thing people say about certain leaders, usually in a slightly lowered voice, as though they’re describing a medical condition: “He’s just not a people person.”

The phrase does a lot of quiet work. It suggests that being a people person is a fixed trait — like being left-handed, or tall, or able to wiggle your ears. Some leaders have it. Some don’t. The ones who don’t are off the hook, because you can’t reasonably ask a short person to be taller (trust me, I’d know!).

I believed a version of this for years. I assumed that empathy was something you were issued at birth in varying quantities, and that my own allocation was unremarkable. I’d backed into management because I was good at the craft, and I privately suspected that the warm, intuitive, reads-the-room leaders I admired were simply built differently. They had the gene. I had spreadsheets.

It didn’t help that someone had said as much, out loud, with great confidence. Early in my career a boss I respected sat me down and explained, kindly and as though he were doing me a favour, that I’d never be a people leader. I was too technical. I thought in systems, not feelings. I’d be happier, he reckoned, left alone with the hard problems where I belonged. He meant it as career guidance. I took it as a diagnosis, and I carried it around for years like a note from a doctor excusing me from a sport I’d assumed I was bad at.

This turned out to be one of the more expensive things I’ve been wrong about — and the many designers I went on to lead across several product areas would, I hope, agree.

Empathy is a skill, and skills are boring in the best way

Here’s the reframe that took me far too long to reach: empathy isn’t a personality. It’s a skill. Like every skill, it’s mostly made of unglamorous, repeatable practice that nobody puts on a slide because it doesn’t photograph well.

We accept this logic everywhere else. Nobody says “she’s just not a guitar person” about someone who has never picked up a guitar. We understand that the people who play well are, without exception, people who once played badly and kept going. Yet empathy gets filed under character rather than craft, so the people who aren’t naturally good at it conclude they’re permanently excused, and the people who are naturally good at it never bother to get better.

What empathy actually is, mechanically, is the skill of building an accurate model of what’s going on inside another person — and then checking that model against reality instead of trusting your first guess. That’s it. That’s the whole sport. The reason it feels like a personality trait is that some people have simply been practising it, unconsciously, since they were small. They’ve got a head start. They do not have a different brain. As it turns out, building a precise model of a messy system and testing it against the evidence is exactly the sort of thing a systems thinker is good at — the trait my old boss filed as a disqualification was, with the labels swapped, the qualification.

The soft-leader slander

The other half of the myth is that empathy makes you soft — that the empathetic leader is the one who can’t deliver hard news, lets deadlines slide because someone had a rough week, and generally runs the team like a particularly anxious golden retriever.

In my experience, it’s almost exactly backwards. The leaders I’ve watched avoid hard conversations were, nearly always, the ones who hadn’t bothered to build the model. They didn’t duck the difficult feedback because they cared too much. They ducked it because they had no idea how the person would take it, and the uncertainty frightened them. Avoidance isn’t an excess of empathy. It’s the absence of it.

Real empathy is what lets you have the hard conversation well. When I had to tell a designer on an enterprise software team I led that his work wasn’t at the level the role needed — a conversation I’d been quietly dreading for a fortnight — the reason it went all right wasn’t that I softened it into mush. It’s that I’d spent enough time paying attention to him to know he’d respect directness far more than padding, that he was more worried about his trajectory than his ego, and that the worst thing I could do was be vague to spare my own discomfort. The empathy didn’t make the message softer. It made the delivery land. He stayed, he course-corrected, and we shipped the release on time — which is the unglamorous business case for empathy that nobody writes on a slide either: it’s how you keep good people and keep delivering while you do it.

Caring about people and holding them to a standard are not opposites. The leaders who think they are usually end up doing neither.

The same skill works in the other direction, too — upward and sideways, on the people who don’t report to you and have no particular reason to be charitable. The most useful place I ever deployed it was with a sceptical executive two rungs above me who was convinced design was slowing delivery down. Reading what he actually feared — not “design is slow” but “I’ll be the one explaining the slipped date” — let me make the entire case in his currency rather than mine, and the conversation turned in about ninety seconds. Empathy isn’t only how you look after your team. It’s how you defend them in rooms they’re not in.

How you actually practise it

The good news about empathy being a skill is the same as the good news about any skill: you can get better on purpose. The bad news is the same too: you have to actually do the reps, and the reps are not exciting.

Here are a few that worked for me, offered without any promise they’ll make you charming at parties:

Ask the boring follow-up question. When someone tells you they’re “fine”, or that the project is “going okay”, the whole game is in the next question. “Okay how?” “Fine in a relieved way, or fine in a please-stop-asking way?” Most of us, terrified of being intrusive, never ask it. The model you build of people is only as good as the questions you’re willing to sit through the awkward silence for.

Say what you think they’re feeling, out loud, and let them correct you. “It sounds like you’re frustrated this keeps getting deprioritised — am I reading that right?” Half the time you’ll be wrong, and being corrected is the point. That’s the model-checking step. Empathy without correction is just confident projection, which is how well-meaning leaders end up solving problems nobody had.

Notice what people do, not just what they say. The designer who goes quiet in critiques isn’t necessarily fine with the feedback. The one who suddenly stops replying to non-urgent messages isn’t necessarily lazy. Behaviour is data, and it’s usually more honest than the verbal report.

None of this requires a personality transplant. It requires paying attention, on purpose, more often than is comfortable. The part that actually compounds, though, is when you stop hoarding the skill and start building it into the team — coaching it into your managers, baking it into how you onboard, treating “can this person build a model of someone unlike them?” as a real signal when you hire. A leader who is privately empathetic is useful. A leader who makes empathy a habit the whole team runs on is the thing worth paying for.

The point

If empathy were a fixed trait, this would all be a bit cruel — telling people to be more of something they can’t change. It isn’t, so it isn’t. The most empathetic leaders I know aren’t the ones who were born warm. They’re the ones who decided, somewhere along the way, that understanding the people they worked with was part of the job rather than a nice-to-have, and then practised it the way you’d practise anything you’d chosen to take seriously.

Which brings me back to the boss who told me I was too technical to lead. He wasn’t being cruel; he was working from the same myth I was, the one where some people are wired for the human stuff and the rest of us should stick to the systems. He was wrong — and not, I should be honest, because I had hidden reserves of warmth waiting to be discovered. He was wrong because the thing he thought I lacked wasn’t a trait at all. It was a practice. Practices are available to anyone prepared to be a little uncomfortable on purpose — the systems thinker very much included.

You don’t have the empathy gene. Nobody does. There’s no gene. There’s just attention, repeated until it looks like instinct.

Next up: what makes design teams weird — critique without ego, autonomy without chaos, and defending craft to people who think it’s just “making it pretty.”

Article 1 of 12 — Building Design Teams

There’s a version of team-building that looks something like this: a role opens up, you write a job description that’s half wish list and half therapy session, you interview twelve people, you pick the one who seemed sharpest, and you repeat the process six months later when another role opens. After a few rounds of this, you look up and you have a team.

Except you don’t. You have a collection of individuals who happen to share a Microsoft Teams workspace.

I did this for longer than I’d like to admit, across more than one team and several years of being quite sure I knew what I was doing. I was proud of the people I was hiring — genuinely impressive, each one of them — and I couldn’t quite understand why a roomful of that much talent kept feeling more like a relay race than a relay team. Everyone ran their leg. The baton was technically passed. But nobody seemed particularly invested in whether the person behind them was about to drop it.

The problem wasn’t the people. The problem was my mental model.

Hiring as addition, not composition

When you treat team-building as a series of individual hires, you’re doing arithmetic. One great designer plus one great designer plus one great researcher equals three great people who are technically employed together. What you don’t get — what arithmetic cannot produce — is the thing where someone notices their colleague is underwater and picks up a piece of their work without being asked; the thing where a junior designer pushes back in a critique because they feel safe enough to; the thing where institutional knowledge lives in the team rather than in the heads of whoever’s been there longest.

Those things aren’t hired. They’re grown.

Growing a team means thinking about composition before you write the job description. It means asking not just “is this person excellent?” but “what does this person change about how we function together?” It means understanding that a team isn’t the sum of its members — it’s the product of how those members interact, and that product is either something you’re intentionally shaping or something that’s happening to you.

Most of us are letting it happen to us.

The jazz band problem

Think about a jazz quartet that’s been playing together for three years. They’re good — genuinely good — but what makes them good isn’t just that each musician is talented. It’s that they’ve learned each other’s instincts. They know who takes the lead when a set goes sideways. They know whose solos need room and whose need a push. They’ve developed a shared language that doesn’t exist in any sheet music, because it evolved in the space between the players.

Now drop in a fifth musician. Excellent player. Conservatoire training, impressive solo work, strong on paper — and watch what happens.

The music doesn’t automatically improve. For a while, it might actually get worse — not because the new person is bad, but because their instincts don’t yet match the room. They reach for a fill the drummer was already planning. They hold a note the pianist was about to resolve. They’re playing the right notes, just not the right notes for this band.

A team of impressive individuals who’ve never learned to play together is a jazz band on its first session — lots of talent, variable results, occasional moments of accidental beauty. What you’re trying to build is something that sounds like a band that’s been on the road together for a year.

That takes longer than a hire. It takes intention, repetition, and a fair amount of uncomfortable silence while people figure out when to play and when to listen.

What this actually looks like

Thinking about team-building as growing rather than hiring changes a few things practically.

It changes how you write roles. Instead of describing an ideal individual in a vacuum, you describe what’s missing from the current ensemble. The question isn’t “what does a great senior designer look like?” It’s “what does this team need that it doesn’t currently have, and what kind of person would provide it while also benefiting from what we already do well?”

It changes how you interview. You start paying attention to how candidates talk about their past teams — not just what they achieved, but what they made possible for others, and what they needed from others to do their best work. Someone who talks exclusively in “I” when describing collaborative work is telling you something.

It changes what you do after someone joins. Onboarding stops being an HR process you half-heartedly shepherd them through and starts being a deliberate act of integration — introducing them to the team’s unwritten rules, its existing tensions, its in-jokes, its history. You’re not just getting them up to speed. You’re helping them find their voice in a band that already has its own sound.

It also changes how you think about loss. When someone leaves a team you’ve hired, you lose a person. When someone leaves a team you’ve grown, you lose a node — a set of relationships, a kind of knowledge, a way of working that existed in the gaps between people. That’s worth grieving differently, and worth rebuilding differently.

When a merger hands you a whole new section

Everything above assumes you have some control over who joins. Mergers would like a word.

At one point an enterprise software team I led absorbed a chunk of another team almost overnight — different manager, different culture, different way of running a critique, different opinions about when to push back on a brief and when to just get on with it. Nobody had asked for this. The announcement framed it as an exciting opportunity. The Teams announcement got twelve thumbs-up emojis and a distinct lack of actual enthusiasm.

The instinct in that situation is to treat integration as an organisational chart problem. You redraw the boxes, you reassign the work, you hold an awkward all-hands where you say the word “synergy” and watch twelve people have the same internal response simultaneously.

What it actually is, is a band merger. Your quartet suddenly has eight people in it, and four of them learned to play in a completely different room, with different instincts, different shorthand, different assumptions about who leads and when. The music will be strange for a while. Some of the strangeness will eventually become your new sound. Some of it will need to be actively resolved rather than hoped away.

The only thing I found that reliably helped was making the awkwardness explicit rather than plastering over it. Not in a “let’s all share our feelings in a circle” way — in a “let’s actually talk about how each side does X, because we’ve noticed we’re doing it differently and pretending otherwise isn’t working” way. Name the dissonance. Play it out loud. Then figure out what the new arrangement sounds like.

It took the better part of a year. The first few months were every bit as bad as you’d fear — two cultures politely refusing to admit they did things differently, work crawling along at the pace of the least-resolved disagreement. But naming the dissonance out loud, repeatedly, in meetings nobody enjoyed, did the work. By the end, the 16 of us were one team rather than two factions sharing a backlog; we’d lost nobody we wanted to keep through the wobble; and the work that came out the far side was sharper than either original team had managed alone. None of which troubled the org chart. All of which showed up in what we shipped.

The harder ask

None of this is technically complicated. The hard part is that it requires you to think about the team as the unit, not the individual, which runs against almost every instinct management culture has trained into us: the performance review is individual, the promotion is individual, the hire is individual, the improvement plan is individual.

Notice that none of those incentives actually reward you for the unglamorous work of making people fit together. So you do it anyway — not on faith, but on a fairly cold bet that the output will eventually argue your case for you.

In my experience, it does, and it argues in the only language the business actually speaks. A team that’s been grown — intentionally, with as much thought given to how people fit together as to how good they are individually — ships faster when it counts, recovers from a bad quarter without haemorrhaging the people you most need to keep, and stops re-solving the same problems every six months. A collection of impressive individuals manages none of that reliably. It’s harder to explain in a planning meeting. It shows up a quarter later in the numbers, and rather sooner than that in the room.

The goal was never to hire a team. It was always to grow one. Most of us just forgot.

Next up: the empathy myth — why caring about your team is a skill, not a personality trait, and why the “soft” leaders are usually the toughest ones in the room.