When I started hiring, I used to look for the 10x programmers, the rockstars, the embarrassingly named “ninjas” (I blame you for starting the trend, Srinija). I quickly learned that these were impossible to hire – they looked exactly like every other “good” programmer, until one day you realized that they’d significantly improved performance by rearranging the functions in core libraries so that the most commonly called methods were loaded together to reduce paging.

Some were great at architecture, others were constantly improving the tooling, others could debug the most inscrutably intractable problems. Some weren’t even great coders at all, but somehow multiplied everyone around them. Each had their own itch to scratch and ecological niche to fill, ultimately taking on a unique role in the organization. These roles weren’t assigned, weren’t officially recognized, and frequently weren’t even consciously understood for what they were. They were, however, implicitly accepted, encouraged, and respected.

Alpha nerd

In any strong engineering culture, there’s one engineer whom other engineers, even senior ones, make Jeff Dean jokes about. The alpha is quiet but self-confident, doesn’t get engaged in any of the usual email chatter, and is extraordinarily effective at both listening and shutting out the world. She avoids all meetings except for ones at which significant decisions about the code base – her code base – are being discussed. She often doesn’t say much at these meetings, but when she does, it closes the conversation. Strange, incomprehensible forces are released when she touches code, and she can do in a day or two what would take anyone else a month, if at all. She frequently acts as a floater, following some unknowable process in determining the next area to greenfield, optimize, rearchitect, reimagine. It isn’t always clear to whom she reports (if anyone), or if she has specific responsibilities and externally defined goals. Other engineers are in awe, and a little terrified of her. The business leadership doesn’t really understand what she does, but some deep, primordial instinct for survival tells them that their success depends inordinately on her efforts, and they shower her with money, equipment, privacy, and hard problems.

Fixer

In larger companies, there’s always an unofficial way of getting things done that’s faster and more effective than going through official channels. You could create a ticket and wait your turn in line, or you could wander over and talk to Sally, who’s been here forever, knows everyone, and can put you in touch with the person who would be doing it anyway. She knows little things like who to call to get lunches ordered, big things like how to speed up procurement, and important things like how the review process works. You’d imagine that this would be an HR ombudsperson role, but the bigger the company, the more bureaucratic HR seems to get, and the more important this role becomes. The fixer acts as organizational grease, quietly increasing throughput.

Enforcer

Sometimes, you need someone who can poke at long-standing, annoying problems and force people to take action. This is primarily useful when a lingering problem is being caused by culture, rather than some intractable technical issue. The enforcer is willing to be the bad guy, follow up relentlessly, and generally make a nuisance of herself until the problem is fixed. No one likes being on the wrong end of an email from the enforcer, and depending on environment and personal style, she can be viewed as a force for positive change, a nag, or both.

Tinker

Some engineers just can’t stop playing with things, automating every aspect of their workspace. Most of their tools are so customized to their personal workflows that they’d be completely useless to anyone else, but tinkers occasionally release tools to the larger organization that instantly become indispensable to the development process.

Institutional memory

As a company gets bigger and its code base grows older (or, in industry doublespeak, “matures”), it becomes harder and harder to understand why things are done the way they are. New people come on board, old people leave, and code slowly rots beneath sedimentary commits. It can be extremely useful in debugging to look at a blame line and discover that yes, it was written by X three years ago when she was on team Y, during the wild rush to get project Z to market. But if X quit two years ago, team Y has since split in two, and Z has morphed into something completely different from its original conception, then you’d be forgiven for not having the slightest clue as to WTF the original engineer was thinking. It’s like moving to a new town and having someone tell you to turn left “where the gas station used to be.” Engineers who’ve been around for years, particularly in companies that have gone through rapid growth, are the unofficial historians of a thousand projects and a half million commits.

Mascot

Part class clown, part cheerleader, part Kramer, the mascot is the goofball that goes so far over the top in promoting the company culture that it almost becomes an ironic, post-modern statement. But it doesn’t, and the mascot gives everyone else cover to unselfconsciously take pride in the company, its goals, successes, and quirks.

Den mother

Bagels and cream cheese on Monday mornings. Home-made muffins and pumpkin bread. Tea time on Thursday afternoons. Tech talks, book groups, unofficial outings to the rock gym, dim sum, etc. etc. These don’t just happen – someone decides on her way into the office that today would be a good day to pick up donuts for the team. Or that, instead of reading a technical book on her own, getting her team to do it together (with a senior engineer leading the discussion) would be more fun. Or decides that the loading dock would be a great area for an after-work yoga class. Or sets up an after-hours ping pong competition. This might be the manager, but doesn’t need to be – some people just seem to naturally organize group activities, include others, and build team cohesion. After an activity is started, it can take on a life of its own – if you’re stopping at the local bakery, of course you pick up croissants for everyone – that’s just what your team does. If you’re interested in a book on a technical topic, of course you suggest it at your ongoing reading group.

Scout

More of the same is always the path of least resistance, and most engineers use the tools and processes that have been provided them. In most cases, this is the right thing to do – constantly switching technologies is expensive, and adding in <insert random technology> “because why the hell not?” is generally… sub-optimal. But sometimes, the library you need just isn’t in the standard set, or the hot new gizmo on HackerNews actually is the most appropriate tool for the job at hand. The scout is constantly playing with shiny new toys, and doesn’t have to go looking when a challenge presents itself – the right tool is already at hand, and the scout has little internal resistance to adding it into the code base (which can also sometimes cause problems). Usually, a fairly small group of scouts are disproportionately responsible for bringing new technologies into the organization.

–

None of these roles are filled intentionally – they’re simply an outgrowth of how some people approach the world. The tinker doesn’t consciously decide that this will be her role in the organization, she just likes to build things. The den mother doesn’t calculate that bringing in fresh baked cookies will earn her a special place on the team, it’s just something she does. From time to time, I’ve tried to suggest some of these as simple things that people could do to stand out, but no one does – it just isn’t natural for them. And that’s ok – this isn’t an exhaustive list, nor do you have to fill a special role to be happy or successful.

Let me know if there are other roles you think should be added to the list!

Follow me on Twitter