Most hiring processes are built backwards. We write a job description around a stack, a level, and a list of skills, then we spend the interview loop trying to confirm the candidate has those skills. Culture gets a single, late-stage conversation, usually framed as “team fit,” usually run by whoever has the least structured interview of the day. That ordering is the mistake. Skill is the easiest thing to evaluate and the easiest thing to build once someone is on the team. Culture fit, or more precisely behavioral type, is the hardest thing to evaluate and nearly impossible to change once someone is in the seat. We’ve built our hiring processes around the variable that matters least and treated the variable that matters most as an afterthought.

I don’t mean culture in the foosball-table sense. I mean something closer to operating temperament: how a person handles disagreement, how they behave when a deadline and a quality bar are in conflict, whether they say the uncomfortable thing in the room or wait until the hallway afterward. That temperament is set long before someone interviews with you. You can teach a strong engineer a new language, a new framework, a new domain. It’s far harder to move someone off a propensity to avoid conflict, or a compulsion to win every architectural debate, in the six months it takes to onboard them. Those are personality-level patterns, reinforced throughout a life and expressed in a career, and they show up in every standup, every code review, and every incident retro whether you hired for them or not.

This is why culture has to be evaluated first, deliberately, and separately from competency. Not because skill doesn’t matter. It matters enormously. But skill gaps are visible, correctable, and cheap relative to the cost of a type clash that quietly degrades a team’s ability to tell each other the truth.

None of this starts from a blank page. DISC and its popular color derivative (Red for dominance, Yellow for influence, Green for steadiness, Blue for conscientiousness) have shaped hiring and team conversations for decades, and they’re worth knowing. A Yellow reads as a natural leader in that model because DISC measures energy and influence, not judgment or technical instinct. Meredith Belbin’s team roles go further: nine roles, each with a real, named weakness attached to its strength, and an explicit warning against doubling up on any one role. That warning is close to an argument I make later in this piece. Both frameworks are legitimate and worth understanding before you build a hiring process. Neither one speaks the specific language of engineering work. They won’t tell you whether someone will argue for the theoretically correct schema while the business needed something shipped two weeks ago, or whether they’ll take the page at 2am without complaint and let the documentation slide. The archetypes below come out of watching engineers specifically, not general team behavior.

The Archetypes

Over enough years and enough teams, the same handful of behavioral types keep showing up. None of them are inherently good or bad. Each is a reasonable adaptation to some environment, and each becomes a liability in the wrong concentration. People rarely change type. What a leader can actually influence is how much of the strength gets used, how much of the liability gets absorbed, and where each type grows.

Almost nobody is a pure type. Most engineers carry traces of three or four of these, and the mix shifts a little with context, a design review versus an incident versus a performance conversation. What matters for hiring and team design is the dominant one, the pattern that shows up by default under pressure when there’s no time to choose a persona. That’s the one to identify, and the one this piece describes archetype by archetype.

The Architect

What it is: sees the system before the ticket. Wants the bounded context right, the data model right, the failure modes accounted for before a line of code ships. On a team, an Architect shows up in design review, in the RFC nobody else wanted to write, in the moment someone asks “but what happens when this needs to scale ten times.” They set the technical north star for the system and keep pulling it uplevel by uplevel toward that target. They raise the ceiling on what the system can become and give the team a real point of view on direction instead of an accumulation of one-off decisions.

The cons: they will treat every problem as a design problem. Left unchecked, a team can spend a quarter arguing the right abstraction for something that needed to exist in production two weeks ago. They anchor on theoretical correctness and can lose the thread on what’s actually good enough for now. Given the choice, they’ll trade feature delivery speed for another step closer to the north star, and they won’t always flag that they made the trade.

Can you have more than one: no. Two Architects on the same team is usually a standing argument. Each has a defensible, well-reasoned position, both are optimizing for correctness rather than speed, and neither has a natural incentive to yield. I’ve watched two strong architects burn a full sprint on a schema debate that one decisive Architect paired with an Operator would have closed in an afternoon.

What they don’t want to do: maintenance and support. An Architect wants to design something new to fix a problem, not keep an existing system alive. They’ll volunteer for the greenfield rewrite and go quiet during the on-call rotation. Left to their own preference, they’ll drift away from the unglamorous keep-the-lights-on work every system actually needs someone to own.

Where they grow: their development interest is technology itself, almost independent of the business problem. New patterns, new frameworks, the next paradigm. This makes them your natural guild leads and centers-of-excellence owners, because spreading technical direction is exactly what they want to be doing anyway. The thing to watch: they’ll gravitate toward technology that’s theoretically superior over technology that’s practical to run, and they’ll underweight whether the rest of the org can staff, hire for, or maintain what they pick. A guild led by an unchecked Architect can leave a team with a stack that’s elegant and that nobody else wants to touch.

Natural opposite: the Operator.

How to test for it: Give them a real system design problem and ask for a technology decision they’d defend, not a menu of options. If the data looks like a time series, ask why they’d reach for Cassandra over MongoDB, or the reverse, and press on what access pattern makes one wrong. A real Architect reasons from data shape, failure modes, and long-term maintenance cost, not familiarity or what’s trending. Then ask what they’d ship in week one if the ideal design was three months out. If they don’t have an answer, you’ve found the cost of the type, live.

The Operator

What it is: ships. Reactive, pragmatic, comfortable under pressure. On a team, an Operator is the one who takes the page at 2am without complaint and has the incident stabilized before the retro even gets scheduled. They keep the business running and build trust with stakeholders because things visibly get done.

The cons: their time horizon is short by design. Debt accumulates that nobody planned for, shortcuts go undocumented, and symptoms get patched faster than root causes get found.

Can you have more than one: yes, but only if something else in the system is holding the long view. A team of Operators without a counterweight will out-execute their own foundation until the foundation gives out.

What they don’t want to do: sit in the long design cycle. Multi-week architecture review, a roadmap doc, a debate about the right abstraction three quarters out. They read that as theory getting in the way of getting something done, and they’ll disengage from a meeting that doesn’t produce an action item by the end of it.

Where they grow: their interest is operational range, becoming the person who can walk into any part of the system and fix it. That makes them strong incident commanders and natural leads for reliability and on-call structure. The thing to watch: they can start to enjoy being the one who’s needed, quietly under-investing in documentation or delegation because being indispensable in a crisis is where their value feels most visible.

Natural opposite: the Architect.

How to test for it: Tell them: “You’re seeing a sudden spike in errors and it’s now triggering alerts. What do you do? Walk me through it.” A real Operator triages fast: checks blast radius, mitigates or rolls back before they’ve confirmed root cause, communicates status without waiting for certainty. Then ask what they’d change and who owns it. The strong answer is a specific system change with a rollout plan and an owner, not “we’d document it in the postmortem.”

The Diplomat

What it is: reads the room, smooths conflict, keeps morale intact after a hard sprint. On a team, a Diplomat is the person who checks in after a tense meeting, translates between two people who talked past each other, and is often the reason a team survives a bad quarter with its relationships intact.

The cons: their instinct is to preserve peace over surfacing truth. In a disagreement between two other archetypes, they’ll often broker a compromise that avoids the real decision rather than forcing it.

Can you have more than one: not in senior roles, without deliberate correction. Two Diplomats in senior positions is one of the more dangerous concentrations I’ve seen, because the team develops a durable habit of not saying the hard thing out loud. Problems get managed instead of solved.

What they don’t want to do: deliver hard feedback, performance-manage someone who’s underperforming, or be the one who says no to a peer. They’ll find a way to soften a message until the substance is gone if you let them.

Where they grow: their interest is people, coaching, facilitation, the relational side of the work. That makes them a natural fit for the people-manager track. The thing to watch: they’ll optimize for “the team feels good” as the success metric unless explicitly told that accountability and hard conversations are part of the job, not a failure of the culture they’re trying to protect.

Natural opposite: the Challenger.

How to test for it: Pick a real architectural fault line, real-time compute versus precompute-and-cache, or synchronous versus async processing, and take a position that’s either wrong or genuinely controversial. State it flatly: “We should just compute this in real time on every request, precomputing is just technical debt.” Watch whether they push back at all. The test isn’t whether they’re right. It’s whether they’ll name the disagreement out loud to the person interviewing them.

The Challenger

What it is: says the uncomfortable thing. Points out the plan doesn’t account for the failure case, the estimate is fiction, or the last three retros named the same root cause and nothing changed. A Challenger is your devil’s advocate, a forcing function for truth, and a team without one drifts into groupthink without ever noticing.

The cons: uncalibrated, they become adversarial for its own sake, exhausting to work with, and if they’re wrong often enough, the team stops listening even when they’re right. When it’s every meeting and every decision, the exhaustion compounds and drags down team morale even when each individual objection was fair on its own.

Can you have more than one: it can work if they’re calibrated, since they check each other and split the load of raising hard points. Uncalibrated, it plays out differently than most doubled archetypes: instead of clashing with each other, two Challengers tend to team up, and raising the next roadblock becomes how each one competes to get a word in. The team doesn’t get a standing argument so much as a pile-on.

What they don’t want to do: quiet, heads-down execution with no voice in the decision. Routine ticket work where nothing is up for debate reads to them as being sidelined, and they’ll disengage from a role that’s pure implementation with no input on direction.

Where they grow: their interest is influence over decisions, being in the room where direction gets set. That’s a natural staff or principal track. The thing to watch: give them a real, standing forum for raising concerns, or they’ll create their own by hijacking meetings that weren’t meant for it, and coach them that being right once doesn’t buy unlimited credibility for every objection afterward.

Natural opposite: the Diplomat.

How to test for it: Ask when the last time was they disagreed with a decision, and press for specifics: how they actually brought it up, in the room or after, to the person directly or around them. Then ask how the people they work with know the difference between a real objection and a minor concern. A calibrated Challenger has an answer, a habit or a signal that tells the team when something is a hard line versus a preference. An uncalibrated one delivers everything at the same volume, so nobody can tell the difference until it’s too late. Last, ask what they did the time it went the other way, when they raised the objection and lost the argument anyway. Commit fully to the decision and you’re looking at a Challenger worth having. Keep relitigating it for the next three sprints and you’re looking at the cost of the type.

The Craftsman

What it is: holds the quality bar. Reviews code like the system’s reputation depends on it, because it does. A Craftsman is how you build seniors out of juniors, through real, substantive review instead of a rubber stamp, and they protect the codebase’s integrity over the long run.

The cons: uncalibrated, every review becomes an opportunity to impose personal style rather than catch actual defects, and throughput suffers. It also costs morale in a specific way: people start to feel lectured to instead of given a real chance to learn something. A great Craftsman knows what actually matters and when, and raises the bar in a way that feels collaborative rather than punitive.

Can you have more than one: two Craftsmen without an Operator or a decisive lead in the mix will gold-plate everything and miss the market. One strong Craftsman, paired with people who can push back on scope, is high leverage.

What they don’t want to do: ship fast and unreviewed under pressure. Asking a Craftsman to skip proper review to hit a date is asking them to violate the thing they’re actually there to protect, and they’ll resist it, sometimes past the point where the business needed them to just let it go.

Where they grow: their interest is craft and mentorship, becoming the person whose review makes people measurably better. Give them the mentorship mandate directly, it’s the same instinct pointed at people instead of gatekeeping tickets. The thing to watch: their personal bar needs to become the team’s documented bar, not just their own taste, or the quality standard leaves the building when they do.

Natural opposite: the Cowboy.

How to test for it: Give them a real, well-scoped task, say, syncing inventory across three warehouses with proper reconciliation, test coverage, and monitoring, and ask for their plan at two weeks. Then compress it: “You have one week.” Then again: “You have two days.” Watch what they cut at each turn, and in what order. The revealing part isn’t the first cut, it’s the last thing they refuse to cut, that’s their actual bar, not the one they’d claim in the abstract. Then ask them to say it out loud: is the two-day version good enough to ship, with the corners named explicitly. Last, how do they go back and fix what they cut, and when. The sharpest answer names where the fix slots naturally into the roadmap, paired with a related feature, early enough that repaying it also unlocks something else, not a ticket with a date bolted on and no home. That shows they think about technical debt as sequencing, not as a chore to schedule and hope for.

The Teacher

What it is: optimizes for making everyone else better. Explains the why, not just the what, in code review and design discussion. A Teacher is how a team’s average skill level rises over time instead of staying flat while headcount grows.

The cons: they slow decisions down to make sure three people understand the reasoning, when sometimes the team just needs the call made.

Can you have more than one: better than most doubled archetypes, since teaching isn’t inherently competitive. The risk is a team that talks about the work more than it does the work, if neither one is also willing to just decide and move.

What they don’t want to do: make a fast, unexplained unilateral call, or work in a silo with no one to bring along. Solo work with nobody to teach feels like a waste of what they’re good at, and they’ll disengage from it.

Where they grow: their interest is developing people, visible in onboarding and mentorship. Natural fit for the people-manager track and for guild or community-of-practice leadership, since spreading understanding is exactly their instinct. The thing to watch: put a clock on decisions so teaching doesn’t become a way to stall, and make sure what they’re teaching is the practical tradeoff, not just the theory behind it.

Natural opposite: the Type A.

How to test for it: Ask them to roll out something new to the team, a practice, a process, a pattern, not review someone else’s code. “You think the team should adopt structured design docs before any new service gets built. Walk me through how you introduce that.” Watch how they sequence it: who goes first, how they teach it rather than mandate it, how they’d know it’s actually landing versus just being tolerated. Then ask what would make them hold off or slow down, mid-crunch, a team that just absorbed another new process, senior engineers with informal habits that already work. The limiting factors they name, unprompted, are the signal. A Teacher who can’t name any is optimizing for the idea landing, not for the team absorbing it. Notice the shape of this question and the ones for Operator, Craftsman, and Hero: in every case, the real signal isn’t the first answer, it’s whether follow-through, ownership, or timing shows up unprompted. That’s not a coincidence. Across every archetype, what separates the strength from the cons is almost always what happens after the first good decision, not the decision itself.

A Craftsman and a Teacher are easy to confuse, because both show up hardest in code review. The difference is what they’re optimizing for. A Craftsman is protecting whether the artifact meets the bar, and the review can be excellent even when it’s terse. A Teacher is protecting whether the person understands why the bar exists, and the review is only doing its job if the explanation lands. You can have a brilliant Craftsman who’s a poor teacher, exacting, correct, and nearly silent on the why. You can have a generous Teacher who’s a mediocre Craftsman, patient and clear, but permissive on the standard itself. Neither failure mode is hypothetical, and knowing which one you’re looking at changes what you coach them on.

The Type A

What it is: driven, high standards for self and others, uncomfortable with ambiguity or loose ends. A Type A is often your most reliable executor, the person who catches what falls through the cracks and follows through without being chased.

The cons: their standard becomes the team’s implicit standard whether anyone opted in or not, and they read a different pace or process as a deficiency rather than a difference.

Can you have more than one: real risk. Both assume their way is correct, and the clash plays out as quiet territorial friction over process rather than open technical disagreement, which makes it harder to see and resolve.

What they don’t want to do: loosely scoped, ambiguous work with no clear finish line, or unstructured “let’s figure it out together” exploration. They want a defined outcome to drive toward.

Where they grow: their interest is ownership and rigor, process design, being the one who ensures nothing slips. Natural fit for project or program lead roles, release management. The thing to watch: tell them directly their standard is a standard, not the standard, and give them a lane, a system or a process they fully own, where their intensity is theirs to apply without becoming the default bar for everyone else.

Natural opposite: the Teacher.

How to test for it: Ask, “Describe a time you had to choose between shipping code quickly or refactoring it to be clean. How did you decide?” A Type A will often lean toward completion, closing the ticket, hitting the date, over deferring for a cleaner pass. Watch for whether they can name what got sacrificed, and whether it ever got revisited. The tell isn’t which way they leaned. It’s whether the deferred work stays alive in their head or disappears the moment the ticket closes.

The Hero

What it is: steps in, works the weekend, saves the launch. Every team has moments that need a Hero, and in those moments they’re genuinely valuable, visibly reassuring to stakeholders when things are on fire.

The cons: their presence removes the pressure to fix the actual process failure that keeps creating emergencies, because the emergency keeps getting absorbed instead of surfaced. They can start to need the crisis, consciously or not, because it’s where they get noticed.

Can you have more than one: dangerous in a specific way. Two Heroes compete for the rescue, which gives both a quiet incentive to let things get bad enough to need saving, and both under-invest in prevention since prevention doesn’t get you noticed.

What they don’t want to do: the unglamorous prevention work. Runbooks, postmortem action items, process fixes that would quietly eliminate the next fire. It doesn’t carry the same payoff as the rescue.

Where they grow: their interest is impact in high-stakes moments, which makes them strong incident commanders. The thing to watch: recognize the prevention work at least as publicly as the rescue, and ask directly in the retro after every save what process failure made the rescue necessary in the first place.

Natural opposite: the Soothsayer.

How to test for it: Ask, “Describe a time you had more work than you could possibly finish. How did you prioritize, and did you ask for help?” A Hero will often describe absorbing all of it themselves, quietly, without escalating. The tell is whether asking for help or naming a bandwidth limit shows up anywhere in the story, unprompted. A collaborative engineer brings in a manager or a peer early, before the overload becomes a crisis worth admiring.

The Cowboy

What it is: works outside the system by default, not just under duress. Sees process, and the protection that process is supposed to provide, as friction, full stop. Would rather solve the problem alone and show results than get buy-in first. On a team, a Cowboy is the one who ships a fix to production without review, stands up a workaround nobody asked for, or rewrites a service over a weekend because the proper process would have taken three sprints of alignment. They move fast, unblock themselves, and sometimes save real time by refusing to wait on a permission that would’ve taken a week to arrive.

The cons: the unpredictability compounds. Nobody else knows what changed, why, or where the edges are, so the team inherits systems only one person can debug. Bypassing review isn’t a one-time shortcut for a Cowboy, it’s the default operating mode, and the debt shows up as tribal knowledge that walks out the door when they do.

Can you have more than one: no. Two Cowboys means two people independently deciding what the right call is and building around each other instead of with each other. You end up with duplicated, conflicting fixes to the same problem and no shared source of truth for what state the system is actually in.

What they don’t want to do: sit through a design review, a sign-off, or a sprint planning cycle to solve a problem they can already see the fix for. Make a Cowboy wait through three meetings before touching the code and they’ll either disengage or go do it anyway and tell you after.

Where they grow: their interest is autonomy and speed, being trusted to just handle it. That makes them genuinely valuable on small, high-trust pods or true zero-to-one work where there’s no process yet to violate. The thing to watch: give them a lane wide enough that moving fast doesn’t require going around anyone, ownership of a bounded system, a greenfield project with a real charter, and be explicit that the instinct that makes them fast without guardrails is the same one that makes them dangerous without them.

Natural opposite: the Craftsman.

How to test for it: Ask, “Tell me about a time you fixed something without asking permission first. What happened, and did anyone find out before you told them?” A Cowboy’s answer centers on the fix and treats the lack of communication as a footnote, or a virtue, they saved everyone the trouble. Watch specifically for whether the story includes telling anyone before the change went live. If the honest answer to “who knew” is “nobody, until it was already done,” that’s the type talking, not the incident.

A Hero and a Cowboy can look identical from a distance, both bypass the normal process to get something done fast. The difference is visibility and timing. A Hero acts in a declared emergency, in the open, and the team knows in real time. A Cowboy decides alone that something qualifies as urgent enough to skip the process, and the team finds out after. One is a crisis response you can build a runbook around. The other is a standing risk to what anyone can trust about the system’s actual state.

The Soothsayer

What it is: sees the failure coming. Flags the risk in the design review everyone else waved through, months before it becomes an incident. Enormously valuable if the team has a real mechanism for acting on early warnings.

The cons: they’re right often enough to be trusted and wrong often enough to be dismissed as the person who always thinks the sky is falling, and the team has to actually work to tell those apart in the moment rather than in hindsight.

Can you have more than one: can reinforce well if they’re reasoning independently rather than groupthinking each other into the same conclusion. If the team ignores the warnings anyway, doubling the voice just doubles the frustration, not the outcome.

What they don’t want to do: execute blindly on a plan they weren’t consulted on. Being kept out of design and planning conversations, then asked to just build what was decided, wastes the thing they’re best at.

Where they grow: their interest is judgment and pattern recognition, becoming the person whose foresight is trusted. Natural fit for staff or principal roles focused on risk and architecture, or guild leadership around reliability. The thing to watch: log their calls somewhere durable so the team builds a real track record instead of relying on memory, and coach them to pair every warning with a proposed mitigation so they’re not only ever the bearer of bad news.

Natural opposite: the Hero.

How to test for it: Give them a system, ideally the one they just designed earlier in the loop, and ask them to imagine it’s completely failed six months from now. Have them trace backward and name the exact hidden flaw or bad assumption that caused it. The specificity is the signal, a real Soothsayer names a mechanism, not a mood. Then ask what they’d do about it today, before it fails. That gap, a prediction paired with a mitigation versus a prediction on its own, is what separates a Soothsayer worth having from one the team eventually stops listening to.

A Hero and a Soothsayer are worth naming as a pair, because a Hero thrives on the fire a Soothsayer tried to prevent. A team that rewards Heroes and ignores Soothsayers is training itself to keep having emergencies.

The general pattern

Across all ten, the doubling problem has one shape. Two of the same archetype are comfortable with each other, which is exactly why the imbalance persists past the point where it should have been obvious to everyone else. The teams that survive a doubled-up archetype are the ones where the leader actively compensates for the concentration: forcing a decision between two Architects, protecting the roadmap from two Operators, mandating candor from two Diplomats, fixing the process two Heroes keep getting rewarded for rescuing.

The more common failure isn’t two of the same type anyway. It’s the wrong mix of different types without a shared understanding of how to disagree. An Architect and an Operator have a legitimate, structural disagreement about time horizon, and if the team culture doesn’t have a mechanism for resolving that disagreement openly, it gets resolved through politics instead. A Challenger or a Soothsayer paired with two Diplomats will get worn down over time, not because they’re wrong, but because the team’s operating norm is to avoid the friction they generate. I’ve seen strong individual contributors leave otherwise healthy teams for exactly this reason: they kept saying the true thing, the team kept smoothing over it to preserve comfort, and eventually they stopped bothering to say it at all.

Why culture has to come first

This is the actual argument for hiring culture before skill. It isn’t that skill doesn’t matter. It’s that skill gaps are legible and fixable in a quarter, and type clashes are not, they take years of deliberate, constant effort to shift, against a bias someone has spent a lifetime reinforcing. You can put someone through a training program to close a technical gap in a quarter. Breaking someone of an instinct to avoid conflict, or a compulsion to win every debate, is a different order of effort entirely, and pretending otherwise is how teams end up with unresolved tension dressed up as “personality differences.”

The real cost of getting this wrong isn’t the obvious friction. It’s the silence that follows it. Teams that mismanage archetype clashes don’t usually blow up in a dramatic way. They quiet down. People stop raising the objection they raised the first three times, because raising it cost them socially and changed nothing. The retro stops surfacing real root causes and starts surfacing safe ones. The team looks calm from the outside and is actually just conflict-avoidant, and conflict-avoidant teams don’t fail loudly, they fail slowly, through a hundred small decisions nobody challenged.

Hiring for culture first means being explicit, before you ever open a req, about what your team’s operating norms actually are and which archetype gaps you’re solving for. It means asking a candidate how they’ve handled disagreement with a peer, not whether they know the tech stack. It means being honest that a brilliant Architect who can’t tolerate being overruled is a worse hire than a solid engineer who can disagree, lose the argument, and still commit fully to the decision. Get the type wrong, and you’ve hired a slow-motion culture problem that no ramp-up plan will fix. Get skill wrong, you have a training gap. Only one of those is actually a crisis.

Type doesn’t change. Calibration does.

None of this is a life sentence, and it would be a mistake to read it that way. An Architect doesn’t become an Operator, and I wouldn’t want them to, the instinct that makes them push for the right abstraction is exactly what makes them valuable. What can change is the calibration: whether they’ve learned to ask “does this decision need to be right, or does it need to be made” before digging into a design debate that doesn’t deserve one. That’s not becoming a different type. It’s the same type, with years of scar tissue teaching it when to hold the line and when to let it go.

The more useful kind of growth is outward, not inward: learning to recognize the other nine types well enough to stop reading their friction with you as a personal failing. A Challenger who understands what a Diplomat is protecting stops experiencing their reluctance to escalate as cowardice and starts seeing it as a different read on the cost of conflict, one that’s sometimes right. An Operator who understands what an Architect is protecting stops experiencing a design review as a delay and starts seeing it as the reason the system will still make sense in three years. None of that requires anyone to change who they are. It requires them to understand who they’re working with, and why the friction is structural, not personal.

The best engineers I’ve watched over a career aren’t the ones who transcended their type. They’re the ones who learned exactly where their own edge is, and built the self-awareness to catch themselves leaning past it before someone else had to catch it for them. That’s the actual skill leaders should be developing in people, not conformity to a single house style, the judgment to know when their default instinct is the right call and when it’s just the comfortable one.

What this looks like on an actual team

A good team isn’t a collection of the strongest individual engineers you can hire. It’s a deliberate composition, the same handful of complementary types, chosen on purpose, with someone accountable for noticing when the mix has drifted. A team of five excellent Architects will fail in the same predictable way five mediocre ones will, just later and more expensively. What makes a team durable isn’t the average talent in the room, it’s whether the room contains the right friction.

This matters more, not less, as AI compresses team size. A pod that used to need six or seven people to cover its blind spots now runs on two or three, and there’s no longer a fourth or fifth person around to quietly absorb a bad concentration. Every seat in a three-person pod carries more weight than it used to, which means the composition of that pod matters more than it ever has.

Take the pod I’d actually build for AI-era delivery: an Architect, a Craftsman, and an Operator. The Architect owns the plan, the artifact that matters most now that AI has compressed inception, catching a bad bounded context or a wrong technology choice before a single line gets generated against it. The Craftsman owns the review gate on everything AI produces, moving at AI speed without becoming a rubber stamp, because the model can generate a thousand lines of plausible-looking code faster than any human can verify it’s actually correct. The Operator keeps the other two honest about production reality, incidents, actual customer pain, the thing that stops a technically elegant plan from drifting away from what the business needed.

That pod has a known weak spot, and it’s worth naming instead of pretending otherwise: there’s no Diplomat or Challenger in the room. When the Architect and the Craftsman disagree, and they will, both have a real stake in doing it right, there’s no natural tiebreaker except the Operator’s default bias toward shipping. That’s not a design flaw. It’s the same tradeoff every composition makes, and the reason a leader’s job doesn’t end once the pod is staffed. Knowing what your team is missing, and staying close enough to catch it before it costs you something, is the actual work.

The same logic scales up. A traditional four-to-eight person team has room to seat a Diplomat or a Challenger alongside the core three, room the three-person pod doesn’t have. That’s not an argument for bigger teams, it’s the actual price of going smaller: you’re trading redundancy for velocity, and you’d better know exactly which types you gave up.