Good programmers rarely manage large teams equally well, the people who designed the biggest online worlds are usually unknown to anyone outside specialized conferences, and the largest game studios were built by people who barely played games at all. If these three facts seem unrelated to you, read to the end, because they are related — and how.
A conversation about a programmer's career often slides either into a discussion of grades — "how is L6 different from L7" — or into the "team management versus the expert track" argument, as if there were only two paths. I'll talk about game development and examples from people I know, because they're right in front of my eyes at this very moment.
A senior in gamedev has at least three fundamentally different directions of growth, and each differs not just by the line in the job title, but by an entire understanding of the world and of the project in that world. One sees a system of systems, the second works with subsystems, and the third is destined to meet the product, the market, and the people for whom all of this was started in the first place.
For the first five to seven years a programmer builds up mass — learns the language, the engine, the debugger, the hardware — and this stretch of the road is usually well marked by predecessors in the form of tutorials, courses, mentors, code reviews, and grades. Then the markings end, the person becomes a senior, and it turns out there are no signposts further on, and most people learn about the fork's existence only after they've accidentally turned onto one of the paths. The problem is that the paths often require opposite skills, and leveling up one will come at the expense of the others.
The architect learns not to write code himself, and not even to review the team's solutions, but to make decisions about where this team should go at all. The tech lead learns not to be distracted by people, both in terms of tasks and in terms of decisions being made, because any decision can be implemented in ten different ways, and which one is right can be answered only by the architect — who shouldn't care.
The producer learns not to think about code at all, and that can be hard, because in ten or fifteen years code eats so deep into your way of thinking that not thinking in categories of project and tasks becomes difficult, if not painful. The career tree after the senior position doesn't do "sometimes," and an attempt to walk all three branches, or even two at once, usually produces a person who does three jobs mediocrely. Like in that joke about kissing a girl and driving a car — try doing them together and both come out badly.
Junior ──► Middle ──► Senior ──► ???
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Architect Tech lead Producer
(system of (technology (product
systems) and depth) and market)But all three roads are just different answers to the same question: where to put the accumulated engineering mass when writing code faster no longer works, because you've accumulated knowledge worth two or three people, sometimes more, and physically writing two-three-ten times more code just doesn't happen.
Architect
You can go into architecture and start designing large-scale systems — large-scale in the sense that one, two, or even three people won't write it in any foreseeable time. Here the ratio of programming to management hovers around fifty-fifty, but for the most part the architect doesn't write code at all. Either he single-handedly builds templates and skeletons of systems, while the entire volume of work, which in any case exceeds the capabilities of a few people, has to be handed over to recruited human resources... with all that follows.
The architect's area of interest isn't always a single system, but often the interconnections between systems: what talks to what, where the boundaries are, who can bring down whom, and what it costs to negotiate an interface. The key difference from the tech lead is that the architect operates in horizons, plans, and questions like "how will this break when it gets ten times bigger."
That doesn't make him smarter — it just takes a different cast of mind, and a good architect may frankly flounder in the details of a specific lock-free container, yet "engineeringly feel" that this particular subsystem will have to be rewritten in a year, because it's tied to an assumption and won't survive the growth of the online player count.
Examples from the game world: Maxim Baryshnikov, who spent six years architecturally evolving the BigWorld engine for World of Tanks and, with his team, dragged the project to the point where the infrastructure holds a million concurrent users, if my memory serves. That's the case when the architecture rests on one person.
The price of the path is that the architect gradually loses his feel for code. Not because he's getting dumber — it's just that an hour spent on code is an architect's hour wasted on code, and those few lines of code written will leave the team without proper interfaces between three systems.
Tech lead / Tech director
This person understands technologies very well and probably programs more than anyone else on the team, researches more than anyone else, and his area of interest is subsystems, or the subsystem he's occupied with right now, plus its connections to its neighbors. Not the architect's "system of systems," but a concrete piece of real code: maybe the renderer, maybe the network, or physics, or the script interpreter. It doesn't matter what — what matters is digging down to the bottom, and if the bottom turns out to be false, then to the next one.
You don't even need to hunt for examples here: John Carmack, a man who has been doing the same thing for decades — he takes a domain (software rendering, OpenGL, VR, networking, physics) and gnaws into it to a level at which there's nothing left to argue with him about.
Tellingly, Carmack, for all his fame, almost never managed large teams and never built processes — but he built technologies, and the processes around him were built by others.
Or Robert Nystrom, a different tech lead type, with his "Game Programming Patterns" and "Crafting Interpreters." These are books by a person who's interested not just in making something, but in understanding it to the end and explaining it so that the rest of the team understands too. The tech lead has it good, because he's the only one of them all who keeps walking the road of adventure hands-on development — the thing he once fell in love with the profession for.
Everything has its price... Hmm... I've written that somewhere before. The price of this path is the height of the influence ceiling, because a technical person, however brilliant and with however many influential friends and colleagues, runs into the limit of what can be held in one head.
The industry is full of examples where a brilliant technology died because its author couldn't or wouldn't explain its value to the people who allocate budgets. Yes, this is usually the lowest-paid position of them all, because the money usually goes to the producer and the glory goes to the architect. A tech director without an influential producer and a competent architect risks spending his whole life polishing a perfect subsystem for a product that nobody will ever see or appreciate. Carmack and Nystrom are most likely exceptions.
Producer
Or Founder, if he has his own capital — he's the furthest of all from programmers and development, because he has long since stopped making games and started making money. It's more important for him to know about the product, the market, working with people, and production pipelines than about the new C++ standard.
And he almost always no longer programs, because his area of interest is the finished game as a whole, and thoughts about what the player will see and whether the unit economics will add up. The producer is no longer a "former programmer who gave up," but a person who once noticed that a project's bugs don't live in the code, and a game with a perfect engine and an unclear target audience dies just as reliably as a game with bugs and crooked code. Ultimately, the highest-quality toolkit is useless if it doesn't serve the goal of creating a finished game that not only works, but also sells and resonates in the player's hands. Don't expect a producer to understand programmers' problems — he's no longer with us, though it happens otherwise too.
Jonathan Blow is one example of a true indie producer, who, admittedly, periodically puts on either the architect's hat (his Jai language is more about the architectural layer) or the tech lead's hat, with talks at GDC. Or Nick Atamas, who by trade is more of a tech lead, since he built Slate for Unreal practically single-handedly, but by his manner of communication and the range of problems he considered he was more of a producer, and his move to a startup was only a matter of time.
The price of the path is obvious, and it's the highest of the three roads: you will no longer code. Code leaves for good; instead of code there will be organizational issues, money, attracting investors, and reporting to shareholders. Five years later, the producer opens his old repository with the feeling of looking at school-album photos — recognition without the slightest desire to go back. Money? There's money... but happiness.
Hybrids
In reality, all the types above are not cells but attractors — points of gravitational pull. A person is drawn to one of them, but over a career he can drift, and in small studios he's forced to stretch in different directions in turn, sometimes within a single workday. That same Blow (Braid and The Witness) is a producer through and through who writes a compiler in the evenings, while Carmack is a clear tech lead whose technological decisions defined the architecture of entire generations of engines, yet has to decide with his team what game to build around a new technology. But such people are exceptions rather than the rule.
Any architect of a successful MMO inevitably starts reasoning about player retention, because sharding architecture and monetization are very tightly linked, and like it or not, you end up going to marketing to sort out joint issues, or to the ad people to agree on timing and budgets. And once you step outside your cozy studio you start seeing how this gradation leaks into job titles.
I suspect this fork isn't a disease of gamedev alone. At the book-face company, when the engineers numbered not hundreds but thousands, it turned out that measuring everyone by the speed of typing letters no longer worked — someone solves hard things slowly, writes little, but multiplies the output of entire teams. They had to formalize senior archetypes, of which there suddenly turned out to be six: Generalist, Specialist, Coding Machine, Tech Lead, Fixer, and Product Hybrid (that "Coding Machine," by the way, was written up for a specific person who for years was the top committer of the entire company). It doesn't map one-to-one onto my trio, and their Tech Lead is simply called Tech Lead, without any corporate dialect, but the rakes are the same, the same set of "casts of mind," and the same caveat that an archetype is not a cell and you can "multiclass," moving between roles. So there's reason to believe this gradation is characteristic not only of game companies — it's just more visible in gamedev, because the studios are smaller and you have to switch hats more often.
Transitions between archetypes are possible, but very asymmetric. A tech lead can calmly grow into an architect, and that's more of a natural growth, when accumulated depth of knowledge converts into breadth. Or an architect can leave for producing — that's also an understandable route, because from a system of systems to the "product–market" system is only a few steps and a different set of application patterns. But the reverse move is almost never seen, and a producer returning to tech lead or architect is a character from roughly the same tall tale as a general returning to sniper duty. In theory the hands remember; in practice, during the absence both the rifles and the war have changed.
Here, however, it's worth telling about super-producers and the facts I promised at the beginning of the article — about studios built by people who never really played games. Bobby Kotick bought out the nearly bankrupt Activision in the early nineties, and he wasn't a fan; by his own admission, he was neither an avid gamer nor a good programmer. To be precise, he wasn't a programmer at all. As a student he had his hands on Arktronics and sold games for the Apple II, but they were written by his friend Howard Marks, not him — so code really was nothing more than "seed capital" for him.
What he did see was "the new oil" where everyone else saw scorched fields, and he brought managers from the world of laundry detergent and canned goods into development. He pulled all the romance out of the development process, turning game releases into a predictable assembly line, and thirty years later Microsoft bought that assembly line for $69 billion. This is the type of super-producer for whom code was never a love nor a means of earning — at best it was seed capital, and more often not even that. The architect and the tech lead build systems, small or large, their own or improving someone else's, because they're interested in how code is structured and how it works.
The producer and the super-producer build a company, because they're interested in how money works — and here we arrive at understanding why a good programmer rarely manages a large team well. Not because he's stupid or lacks skills, but because managing a team rests on questions about money, people, and the market — the very questions a good programmer escapes from into code and development. It's naive to expect he'll suddenly come to love those questions when the team grows.
Mister Toastmaster
There is, however, one more type, whom no career diagram will ever draw, because it's awkward to draw him. He's not the best architect, not the deepest tech lead, and not the coolest producer, but he always ends up at the table where, after the third toast, it's decided which project gets its funding trimmed and where the money gets handed instead. He may write code, or draw diagrams, or crunch unit economics, but what he does best is show up next to the right people at the right time, crack a well-placed joke, and win over those who hold the bank. Technically he may know how to do nothing at all, but he possesses the rarest skill in the engineering world — being memorable. And the people who make decisions remember and love him.
And over the long haul of a career this often beats architecture, and depth, and product instinct, because a brilliant subsystem nobody upstairs knows about loses to a mediocre one that found itself a cheerful and loud champion at the right table. The price of the path? Others pay it... I'll evasively call this archetype the "connector-man" or "toastmaster-man," and pretend we're talking about networking.
Bearings
If you try to assemble a unified picture, you can roughly figure out where you're being pulled by the question "what's the first thing you do on a project?" The architect will draw diagrams of connections and look for problems under load. The tech lead will go poke at the most interesting subsystem and read code until he understands how it works. The producer will go torment people with questions — or go drinking with the bosses, which also resolves a lot of issues, just on a different plane.
If that test didn't work, then look at what tires you least. The architect doesn't get tired of postmortems and reviews, the tech lead isn't sickened by documentation, and the producer can hang for hours in meetings with ill-defined agendas. Whatever tires you least — that's your road, because over a ten-year distance it's no longer talent and knowledge that win, but the low daily cost of existing in the role.
Or you can choose not to choose... That's also an option, but then the choice will be made for you, because a senior who hasn't picked a direction doesn't remain a generalist — he becomes the person who can be assigned wherever circumstances demand, usually at the moment of the next reorganization. The whole question is whether you chose that place yourself, or whether it chose itself while you were closing out the sprint.
← All articles