You're a Multiplier
You could probably ship more than almost anyone on your team and you know it. Your team probably knows it too. But that's not what you optimise for.
Because you've realised something important: one engineer moving faster improves one part of the product. One engineer removing the bottlenecks slowing everyone else down improves the whole team.
That's the Multiplier mindset, and it's rarer than it sounds.
What this means
Where others use AI to write code faster, you use it to think bigger: to prototype ideas before committing to them, to sketch out patterns the team can build on, to stay one step ahead of where the codebase is going.
You operate at a level of abstraction most engineers don't naturally reach, because you've decided your leverage is elsewhere.
What you actually do
- Prototype solutions to novel problems using AI as a sounding board, staying ahead of default AI patterns rather than accepting average output.
- Monitor AI usage across the codebase and remove friction points before they compound.
- When you spot a recurring issue in pull requests, build a linting rule, a guardrail, or an AI reviewer prompt rather than commenting on it twenty times.
- Ship features like everyone else, but your work does two things at once: it meets the product need and leaves the codebase better for the people coming after you.
- Use AI to create artefacts (diagrams, documentation, architecture notes) that communicate direction and get team buy-in without you needing to be in every room.
- Gather feedback from the engineers closest to the code and act on it. You build guardrails from signal.
What you don't do
- Dictate how other engineers use AI moment-to-moment. You set up the conditions for good work and trust people to do it.
- Hoard the complex work. You have the capacity to take on more than most, and there's a version of this archetype that quietly keeps the most interesting problems for themselves. That's a bottleneck with good taste, and it's worth watching for in yourself.
- Take on systemic change while carrying a full delivery load without pushing back on that expectation. If you're shipping at the same rate as everyone else and trying to improve how the whole team works, one of those things will lose and it's usually the harder, slower, more valuable one.
How you use AI
You bring a hard problem to Claude as a thinking partner, work through it, and come out the other side with a prototype or a clear point of view. That output becomes an artefact (a doc, a diagram, a set of guardrails) that the team can use without you being present.
You engage with AI at the level of architecture, trade-offs, and patterns. The output of those conversations is what the team builds on.
Where you shine
- When the team hits a genuinely novel problem outside the established patterns and someone needs to figure out the approach before everyone else wastes time getting it wrong.
- When AI friction is slowing the team down (inconsistent output, creeping pattern drift, junior engineers unsure what "good" looks like) and it needs fixing systematically.
- When the team needs to move faster without hiring and you're the mechanism that makes that possible.
Your blind spots
- The further you operate from day-to-day code, the easier it is to build guardrails that feel like overhead. If your patterns are being quietly worked around, that's worth paying attention to.
- Getting so focused on team velocity that you lose touch with what it actually feels like to ship a feature right now. The Artisans on your team will feel this friction first. If they're frustrated, listen before building.
- Trying to fix everything at once. The role is about addressing bottlenecks one at a time and if you let yourself get pointed at every broken thing simultaneously, you'll make slow progress on all of it and burn out in the process.
- On smaller teams, this archetype can struggle to find its footing. Multiplying a team of three is a different problem to multiplying a team of twelve. If the context doesn't have enough surface area, some of what makes you effective has nowhere to land.
Where you might be heading
The patterns you build for one team become the patterns other teams adopt. The guardrails you set up in one codebase become the standard across the engineering org. Team-level thinking becomes organisation-level thinking.
The risk on that path is getting too far from the work. The best Multipliers stay close enough to the code to know when their own systems have stopped working.
Setting a Multiplier up to succeed
This archetype only works if the conditions are right, and getting those conditions in place is on the people managing them as much as the Multiplier themselves.
- Change what success looks like for them. If your performance conversations are still centred on individual delivery, you're measuring the wrong thing and sending the wrong signal about what actually matters in this role. Output for a Multiplier is team capability improved, not features shipped.
- Give Multipliers a clear way to spot problems early. They rely on signals from the team, and if they have to hunt for every issue themselves, they'll miss the ones that matter most. Make it easy for problems and feedback to reach them quickly.
Explore the other archetypes
Not sure this one fits? Read about the others and see what lands.
- The Builder: Treats AI as an execution engine. Operates one level up from code, steering agents rather than writing syntax.
- The Explorer: Reads systems from the outside in. Uses AI to answer their own questions about the codebase instead of pulling other people off product work.
- The Artisan: Leads AI moment-to-moment because default output isn't good enough in their area of depth. Stays close to the code and catches drift early.
- The Apprentice: Co-creates with AI through dialogue. Builds judgement one prompt at a time, and ships only what they can defend.
Or go back to the AI Engineering Archetypes overview to see the full picture.