4 ms·

I have a hunch that one of the good ways for a CTO to still occasionally write some code that delivers significant value for the company is to take on the "litt

by ef4 12y ago

I have a hunch that one of the good ways for a CTO to still occasionally write some code that delivers significant value for the company is to take on the "little" projects that reduce friction in the internals of the company itself. Too many companies fail to invest in that kind of software, because its value is less obvious than code that's shipping directly to customers. But I think it's very high-leverage. It's literally reprogramming parts of the business itself. It's tempting to slice off that kind of work for a new hire, because it's more self-contained and lower risk than your product. But I think that's probably a mistake -- the new hire will learn faster on a product team, and the "little" project will be bigger impact in the hands of someone deeply technical who has a vision for how the company should run.

Jormundir 12y ago
At this point in time I would not work at a company where the cto is coding, unless the entire company is less than 10 people. The managerial job of a cto is huge, so seeing them code is a big indication that management is not fulfilling their responsibilities, or doesn't understand the tremendous and necessary role of good management. [Response] - I know there are plenty of examples of good and bad CTOs who program or don't program, it's just been my experience that the likely situation resulting from a CTO coding is bad code and bad management. I see programming as something that generally requires full time attention to maintain good context, and good management is equally demanding.
- djloche 12y ago
  Exception: Carmack @ Oculus VR.
  - jotux 12y ago
    >>>Exception<<<
- Alex3917 12y ago
  The problem is that if the CTO abstracts themselves completely from the technology, then you end up with VPs of engineering who get away with making decisions based solely on the tech rather than the larger business issues.
- alex_anglin 12y ago
  The CEO of my employer[1] still programs 'from time to time' [2] and I would say understands the role of good management better than 99% of CEOs out there. That the firm is privately held means that he's certainly fulfilling his responsibilities as well, if fiduciary duties matter to him. Ultimately, outcomes are what matter and few have better track records. [1] http://www.sas.com/en_us/company-information/executive-bios/jim-goodnight.html http://www.sas.com/en_us/company-information/executive-bios/... [2] http://www.forbes.com/sites/peterhigh/2014/05/12/an-interview-with-the-godfather-of-data-analytics-sass-jim-goodnight/ http://www.forbes.com/sites/peterhigh/2014/05/12/an-intervie...
- ef4 12y ago
  I don't think a well-managed software company should keep everyone 100% allocated to their primary function. It's too brittle and it leaves too many potentially game-changing ideas unexplored. I would be happy to work at a company where everyone spends 10% of their time on skunkworks-type projects, or cross-training in a totally different part of the organization, and that would include the CTO sometimes writing code. (Obviously little startups don't have this luxury, but in those cases the CTO is justified in coding anyway.)
- 23david 12y ago
  It can definitely be weird, and particularly so if the CTO is head of both the live operations (TechOps/Devops) and product-development (frontend/backend) engineering groups. Really hard to straddle both of those well.
jameshart 12y ago
But then the CTO becomes the deskside support for a critical tool that's helping everybody get their job done...
- maerF0x0 12y ago
  Any well written code and any well trained engineer should be able to maintain it.
sahillavingia 12y ago
I totally agree. The only time I spend coding is on internal tools and process-y things. Another benefit is that there's typically less maintenance required than with product features. I actually wrote down some of my thoughts on it here: https://medium.com/@shl/write-code-sometimes-e7516c2b1f71 https://medium.com/@shl/write-code-sometimes-e7516c2b1f71
- mjwhansen 12y ago
  That's such a neat little tool. Thanks for the inspiration to build something similar for Basecamp at our next internal hackathon!

by ef4 12y ago

Jormundir 12y ago

At this point in time I would not work at a company where the cto is coding, unless the entire company is less than 10 people. The managerial job of a cto is huge, so seeing them code is a big indication that management is not fulfilling their responsibilities, or doesn't understand the tremendous and necessary role of good management. [Response] - I know there are plenty of examples of good and bad CTOs who program or don't program, it's just been my experience that the likely situation resulting from a CTO coding is bad code and bad management. I see programming as something that generally requires full time attention to maintain good context, and good management is equally demanding.

djloche 12y ago
Exception: Carmack @ Oculus VR.
- jotux 12y ago
  >>>Exception<<<
Alex3917 12y ago
The problem is that if the CTO abstracts themselves completely from the technology, then you end up with VPs of engineering who get away with making decisions based solely on the tech rather than the larger business issues.
alex_anglin 12y ago
The CEO of my employer[1] still programs 'from time to time' [2] and I would say understands the role of good management better than 99% of CEOs out there. That the firm is privately held means that he's certainly fulfilling his responsibilities as well, if fiduciary duties matter to him. Ultimately, outcomes are what matter and few have better track records. [1] http://www.sas.com/en_us/company-information/executive-bios/jim-goodnight.html http://www.sas.com/en_us/company-information/executive-bios/... [2] http://www.forbes.com/sites/peterhigh/2014/05/12/an-interview-with-the-godfather-of-data-analytics-sass-jim-goodnight/ http://www.forbes.com/sites/peterhigh/2014/05/12/an-intervie...
ef4 12y ago
I don't think a well-managed software company should keep everyone 100% allocated to their primary function. It's too brittle and it leaves too many potentially game-changing ideas unexplored. I would be happy to work at a company where everyone spends 10% of their time on skunkworks-type projects, or cross-training in a totally different part of the organization, and that would include the CTO sometimes writing code. (Obviously little startups don't have this luxury, but in those cases the CTO is justified in coding anyway.)
23david 12y ago
It can definitely be weird, and particularly so if the CTO is head of both the live operations (TechOps/Devops) and product-development (frontend/backend) engineering groups. Really hard to straddle both of those well.

jameshart 12y ago

But then the CTO becomes the deskside support for a critical tool that's helping everybody get their job done...

maerF0x0 12y ago
Any well written code and any well trained engineer should be able to maintain it.

sahillavingia 12y ago

I totally agree. The only time I spend coding is on internal tools and process-y things. Another benefit is that there's typically less maintenance required than with product features. I actually wrote down some of my thoughts on it here: https://medium.com/@shl/write-code-sometimes-e7516c2b1f71 https://medium.com/@shl/write-code-sometimes-e7516c2b1f71

mjwhansen 12y ago
That's such a neat little tool. Thanks for the inspiration to build something similar for Basecamp at our next internal hackathon!