This post was originally published on this site.
There’s one in every engineering org: the person who picked up a coding agent first and started leaving everyone else in the dust. Once one or two engineers are operating at a different scale entirely, leadership is bound to notice. And, quite naturally, they want to figure out what makes those individuals special, so they can try to clone it across the whole team.
But the engineers suddenly running circles around everyone else aren’t necessarily special in some durable, identifiable way. What does this mean for engineering managers and company leadership? The “find the special ones and promote their traits” approach isn’t the best or only way to drive AI adoption and productivity on an engineering team.
A continuum, not a cast of characters
Vivek Raghunathan, SVP of engineering at Snowflake, described the shape of this on a recent Leaders of Code episode, borrowing a split from reinforcement learning: explore versus exploit.
In his account, roughly 5% of an engineering org is made up of fearless “explorers”: people who are chomping at the bit to experiment and push AI tools further than anyone’s asked them to. These are the folks bursting into your office to show you what they just built. The other 95% are “exploiters”: people who have little real interest in doing that discovery work themselves, and just want the paved path handed to them. Raghunathan is careful to note the word isn’t meant as a knock; it just describes a real and useful preference. (We’ll unpack that more as we go.)
The mistake organizations make is treating the explorer/exploiter distinction as a binary: a rigidly defined cast of characters rather than a continuum. The goal isn’t to sort people into “special” and “less special,” but to move people along the scale. Leadership’s goal, Raghunathan emphasizes, should be getting more engineers from a middling point on that scale closer to the top, not looking outside the company to discover and hire anyone who might already be there.
Why the obvious moves don’t work
You can’t necessarily identify the explorers in advance. The people posting 100x gains aren’t always the engineers who were the most senior or the most outstanding before agents showed up. Raghunathan says the traits getting amplified with AI are curiosity, adaptability, and willingness to learn, not prior seniority or reputation. Any plan designed to identify your best engineers and get them to the front of the line for AI training is aiming at the wrong population from the start.
Designing only for the exploiters caps your ceiling. If your whole AI strategy is to give everyone the paved path and call it done, you’ll raise the floor (genuinely valuable!), but you’ll never find out what the frontier actually looks like at your company, because nobody’s being given room to look for it.
Designing only for the explorers doesn’t scale. The opposite failure is just as common: Leadership gets excited about the handful of people doing remarkable things and builds the whole AI story around them, while the other 95% of the org quietly continues doing the same work slightly faster. A few dazzling case studies don’t move an organization’s actual output.
Treating this as a hiring problem instead of a movement problem. If you’re thinking, “I’ll just go hire more of the 5%,” Raghunathan bluntly cautions that you can’t reliably identify these people externally any better than you could internally. The real lever is deliberately moving people who are already on staff further along the scale.
What actually needs managing here
Let the explorers self-identify, and take them seriously when they do. Raghunathan describes these engineers as easy to spot. They’re the ones showing up unprompted, insisting something is urgent, desperate to demo what they built over the weekend. Managers should treat what explorers find as raw material worth extracting and spreading, rather than just praising them and moving on.
Build a mechanism to close the gap, not just observe it. Once you can name what the explorers are doing differently, the job becomes about narrowing the distance between the middle of the scale and the top. You accomplish this through structured learning time, building a community of practice around AI tools, and direct mentorship. People aren’t going to learn by osmosis.
Measure movement along the scale, not just presence of outliers. A handful of 100x anecdotes is a good story but a poor metric. The more useful question is something like: How many people moved up a meaningful notch this quarter? How many are still stuck at the starting point they were at six months ago?
Give the exploiters real credit for what they’re optimizing for. The 95% aren’t a problem to be solved; they’re a majority who are correctly prioritizing getting their actual work done over exploratory tinkering. The goal isn’t to turn them into explorers. Instead, it’s to make sure the paved path they’re relying on keeps getting better and faster, because someone is doing the exploring on their behalf.
The question worth sitting with
Let’s return to the one or two engineers who are suddenly operating at a different scale. The temptation is to stick these promising specimens under the microscope to understand and replicate what qualities make them special. But that strategy is a dead end, because it’s so hard to predict which engineers will emerge as explorers. The task for leadership is building a system that keeps finding whoever’s next, translating their discoveries into teachable knowledge, and moving the rest of the org up the scale—rather than waiting for lightning to strike twice.
Leaders of Code is a segment of the Stack Overflow Podcast. To suggest topics or guests, email podcast@stackoverflow.com.
