1) Does anyone here have the reference? 2) What do you think - "Should CTOs Code?"
Should the CTO be given a chunk of the backlog to complete for this sprint? No, that's probably not a good use of their time.
Should the CTO lend a hand when the team gets stuck and have an active role in code reviews? Certainly! That seems well within the scope of their duties.
I think part of being a technical leader for a company is getting your hands dirty when your experience/insight could save the team significant time/headache. Coding for coding's sake isn't advisable, but coding as a teaching/mentoring tool could be very valuable for the members of your team.
One of our CTO (where I am a developer with) is good at MySQL, PHP and other stuff, he just checks our DB schema or does pull data by himself for any data points or how our recent conversion does affect our sales etc., this really helps so we can still do and focus on our consumer changes rather than pulling data which ofcourse is important but not something relevant to development.
On one weekend one of my code created an issue with cron job and halted sales and he just aware of what might be causing it and just altered a DB value and it run off smoothly and I fixed it over Monday. So it probably helps as a team. But he doesn't do any single code commit. I am very happy with him and love to work with him.
So I really think a CTO need not code but definitely need to know what code does.
It also depends on the type of company. Does Tesla's CTO know how to code?
The only time it's all right for a CTO to code is in the beginning. After 5-7 people have joined the company they should be reviewing code and tech.
1) My references are personal experience as well other managerial types in Seattle's Startup's.
In any large engineering organization, there are usually several architectural decisions made long ago (often, back when the CTO still coded) that are hampering the productivity of everybody else. Usually, these decisions are so ingrained in the system that nobody questions them, and even if they did, changing them requires the cooperation of many different people or even departments and no individual contributor has that much authority. The CTO is uniquely positioned to actually fix these problems, but when the CTO (or even CEO, if the company has a technical founder) doesn't code, he's usually completely unaware of them or their impact on the organization.
FWIW, I've been founder and CTO for more than 14 years and I've done a lot of coding throughout this time. It worked out well for me and the company, but it's hard to say what would have happened otherwise. My successor as CTO won't be coding though.
I think we are entering an era of software literacy, where coding will be an expected part of a persons skillset - as much as reading and writing.
So let me rephrase the question - should CTOs read and write?
If it now seems silly, then think about how much more coding could be possible at a company than just that working on the main product output. And ask why at your company it is hard to use code in those areas.
Imagine a newspaper managing editor or the head of a medieval scriptorium. We would not expect either of them to be doing the day to day lettering or articles, but the idea they should not use their literacy I. Support of the rest of the business is crazy. As is the idea that the only coding one should do is "on the product"
Also: would it be wrong of me to out OP as a prominent CTO?
Anyways, I think that CTOs should code until their organization is large enough that they are off of the frontlines and can manage their engineers to make progress. When the company grows further, they can focus on new technologies, pet projects, and pinch hitting. Once they're technologically behind the curve, they should move on to a new thing.
My intuition is that a CTO kind of goes through 3 phases, mostly as a function of available resources (and I'm just spitballing headcounts here):
1. Prototype and initial product development (0-3 engineers, call it). CTO is end-of-line responsible for meeting business deadlines, creating lean version of product, and training others on the product architecture (because bad things happen to good people at the worst times). CTO has put in first set of policies for managing projects, workflow, and suchlike. CTO has to code every day, because there aren't enough hands around and because the overhead of explaining things in sufficient detail to others dwarfs the immediate business returns.
2. Engineering growth (4-35 engineers). CTO has somebody running mainline development, and is responsible now for either pinch-hitting on hard product problems/legacy that hasn't been transferred over to new people or for improving the daily lives of their engineering team. This is the time to scrub out legacy mistakes, to write and document things so that others can learn and build quickly, and to fix problems in the workflow as they become obvious. CTO might still lend a hand for some projects, but they should be focusing on making others productive and coordinating with business.
3. New frontiers (36-150 engineers). CTO has senior engineers and leads who can handle everything up to a year's worth of planning, and no longer needs to be involved in the day-to-day (except to make sure the front-lines are happy). Engineering culture (established previously) should now be on second- or third-generation employees, and no longer needs tight management. CTO is now free to look at new development lines, new emerging technologies, and maybe start small teams to work on proofs-of-concept for different ideas or product rewrites. CTO probably can go back to daily coding, because there are now people who are handling the management and planning of everything else. CTO gets to try out new things again and think of long-term issues.
4. Yacht-time (150+ engineers). Seriously, what are they doing? Sell their shares and buy a goddamned yacht already. :)
~
That's my thinking on it.
