High judgment individual contributors often take on responsibilities that can be considered management, like deciding business and technical strategy, designing products, prioritizing roadmaps, etc., but while these are management functions, taking on these responsibilities does not mean that one is in management.
From the blog post, it sounds like Carmack is a highly productive, high judgment individual contributor with the responsibilities you'd expect of a CTO (technical strategy). I would say that someone is "in management" when their chief function is managing other people. From this post, Carmack seems to be delivering work as an individual contributor and (very senior) technical lead.
Along the same lines, I recommend we discourage phrasing like "move up to management". Management is a different job, not a better or superior one. In well-run technical companies there are managers and individual contributors at all seniority levels, such that one does not need to become a manager to "move up", even to CTO level.
Oh please. Until management is no longer a more profitable career track than staying in engineering, could we stop lying to the younger folks that might believe the nonsense they read on HN?
In well-run technical companies there are managers and individual contributors at all seniority levels
Non-management contributors with C-suite pay (and occasionally titles), are still rare enough to be noteworthy. Unless they're on par in compensation and control of the company, pretending traditional corporate management doesn't consider themselves their superiors is just ego-stroking the engineers too dumb to be insulted.
Word. At Etsy, we'd occasionally call out people (in a friendly way) for saying "I got a promotion to manager!" Someone (usually a more senior manager who used to be an IC) would say "not a promotion, lateral move." Drove the point home, at least at an IC level, that management is not a move up.
As an individual contributor I can't imagine giving up my day-to-day coding for a management position. Management responsibilities, sure. I'd wager that most software developers who are given enough autonomy are doing a lot of micro-project management anyway.
Giving up on researching new technology and playing around with stuff? Not a chance.
Of course, if you're lucky enough to be in a job (I'm thinking frontend web) where playing with exciting new tech is part of the job, I can absolutely see how the move to management and the loss of overall hands-on time with the code can be a bad thing. Thankfully for me it's been somewhat liberating.
More of a "Hey guys, we're going in this direction, follow me!" over a "Hey, we're going this way, off you go!"
I'd rather hire someone with management skill who knows how to delegate to those who have the required technical skills, rather than spin constantly trying to be the master of everything and failing at it.
None of this "well I guess I knew a bit of C++, let me find another engineer to work on this Netflix app and offer micromanaging style tips and tricks" which is what I've seen from a lot of managers who used to be technical.
He's also an amazing role model for regular programmers; figure out the requirements, take a crack at it with a prototype and then iterate. The iteration doesn't have to be an overtime week affair.