Ask HN: Should CTOs Code? | Hacker News Reader

Ask HN: Should CTOs Code?

13 pointsalcoholiday22 comments

Lately, I remember hearing that a new CTO at "well known company" stipulated that he would spend 20% (or some significant percentage) of his time "coding"... since then, I've been unable to find the reference.

1) Does anyone here have the reference? 2) What do you think - "Should CTOs Code?"

View on HN

It depends on how you define '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.

I have worked with few startups of different degrees. I really think CTO doesn't need to code but should know what code does.

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.

I was the CTO of an early stage startup that had a team of 3 developers. As a CTO your role is to have the vision of the entire platform, to pick the best stack that will get your MVP done, to think of best solutions to scale the system after you get traction. The CTO needs to have a deep technical knowledge and I think you can not do your job well if you do not code, test new technologies, build proof of concepts. If you sit around all day and just code review you are doing it wrong, you become just a glorified manager. You need to give your team the best technological advice and help them when they are stuck. Most of the time I wrote proof of concept code and tested out some libraries before I guided the team in using them.

You aren't going to get helpful answers from such a general question. Furthermore, titles are somewhat arbitrary and only have convention to define them. If you are a 2-person startup and the only employees are a CEO and a CTO, well someone better write the code. If you are the CTO of Amazon (to pick an example), I have to imagine that you are too busy with vision and strategy to even think about coding. If your company is somewhere in between there, then maybe your CTO's responsibilities are somewhere in between.

It also depends on the type of company. Does Tesla's CTO know how to code?

2) CTO's should never code. If they are spending time instead of reviewing other peoples code; trying to find new technologies to help get them where they want to go; they are not doing their job.

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.

The reason for a CTO to code isn't to get the code written; it's so that they understand what the primary hassles are when their employees try to get the code written.

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.

Who is to say? Whatever works out best in the long run should be done and if a CTO likes to code and does it well, he should probably do it.

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.

Yes

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.

That's quiet the straw man argument. Nowhere did he say anything about knowing how too code.

Not really - should CTOs who know how to read and write actually read and write for the job? Of course.

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"

As someone who came up as mostly a non-coder, I now believe that every employee of a startup should commit code. When CTOs don't code, I think of them as glorified managers, not true technologists. If the don't have an insatiable desire to create technology, then they should be in a different role.

Also: would it be wrong of me to out OP as a prominent CTO?

I really doubt that a prominent CTO would be taking time-management advice from HN.

Yes, neither wood Kardashians or Bieber.

You would be incorrect.

Which one, or at least which company? :)

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.

I should hire 150+ engineers oversea and get that Yacht-time tonight.

That's cheating, I believe.

Sounds like a good idea in theory (to have an executive involved in low level grunt work), but also seems like a waste of time because they obviously won't be as effective as someone who codes daily. The point of the CTO is see the big picture and direct accordingly.

Coding is not low level grunt work, it is (potentially) the highest leverage activity a human can do.

True, but unfortunately architects and monarchs are given credit for buildings, not builders.

I think CTO's should and must be ABLE to code...however, they should not actively code. CTO is a strategic role and if you're in the weeds, your not focused on what's next.

if the company is big enough to actually need a cto then a code review one level deeper than strategy might be fun once a month. But to think the best use of your time would be to play jr. coder (and that's all any part timer could be) is just silly.

Reply on news.ycombinator.com