John Carmack is a good role model for any techies that move up to management. If you want to keep in touch with the base tech that your devs are using, you have to dive into a project like this where all your tech knowledge is brought to bear on a problem and you learn lots of new things.
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.
Why do you say that Carmack is in management? I don't get the impression that he's a people manager. A CTO does not necessarily have people reporting to them in a people management sense. From what I've read, I would assume he does not. (I could be wrong - I don't really know.)
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.
In some of his recent keynotes (especially the later quakecon ones) he focuses a lot on how he's changed his mind and that he now believes that software development has a lot of "social science" aspects to it. I think he's given a lot of consideration to how one manages a software team, and even though he sometimes disappears into his office to write something like this Netflix app, he still does manage people.
Management is a different job, not a better or superior one.
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.
>I recommend we discourage phrasing like "move up to management".
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.
The problem is that most techies who move up to management don't have Carmack's brain. This guy is a machine! For a normal person, it is almost impossible to get a workload done that's comparable to Carmack's.
Especially combined with management tasks; I find coding and management hard to combine. At least in my brain they feel very different and as a CTO I feel I must do both. I do not want to end up like a CTO that is out of touch or has his current tech knowledge from buzz words in management magazines like so many tech management people I know who are my age.
I wonder if part of it is that some techies who aspire to management do so because they don't actually like developing software.
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.
I'm in this boat at the moment (one man band contractor of many years finally starting to take on employees). I'm finding that as I delegate more of the routine day-to-day work away, I'm actually finding myself with more time to play around with new stuff. Trouble is, in my line of work (corporate .NET stuff) customers aren't interested in anything new and exciting - they just want Windows applications and ASP.NET forms connected to SQL Server databases.
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.
I can imagine. I think you can do both by focusing on one for awhile and then moving back to the other role. In the short term it is a set back but long term you can develop both skills. Meanwhile you can share management responsibilities with others and find out who makes the team gel the most and who are the great coders. Eventually if you can retain all this trained talent I believe you'll have a really strong team. Of course this happens naturally as people are promoted and moved around but I think if we could admit to ourselves that a manager once does not need to be a manager always, we'd all be so much better off.
In the Netherlands, where I am from, at least (I think it is less so in the US?), you are a complete failure/loser if you are a coder > 35 y/o (I am 40). You are supposed to be a manager then. My path was different than that but I cannot help thinking this attitude which is pushed in university and by (a lot of) parents influenced some decisions I made. Coders over 45 are considered sad and when you meet them in companies they are usually in the basement and treated like idiots. We were hired to give this mobile app development course to a large company in the Netherlands; it turned out this was just to fill out the training responsibilities the company had with their employees. All of the trainees were over 45, most over 50 and the company didn't care what we did and they would never use it there but apparently their employees expressed interest to learn about app development. Sad.
Yikes that is sad. Hopefully things like open source and github will allow aging developers to show their value. If a business sidelines an employee based on their age then that's the company's loss right? And hopefully the employee can find a smarter employer.
I hope this 'tradition' is ending/will end, but the past 5 years working with medium to large companies in NL showed me it was still alive and kicking.
I struggle with this every day. The amount of juggling priorities and helping a dozen different people that a technical manager has to do is completely at odds with the focus required to write non-trivial code.
I wonder what Carmack's managerial responsibilities are like. I imagine if he's developing/designing for most of the week, how much time does he really devote to being a CTO/manager?
I would be interested in examples of people (besides Carmack) who are able to handle day to day management responsibilities and stay technically sharp in new technologies coming out. There's only so much time in a week, and your performance drops as you exceed 40-50 hrs/week.
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.