Poll: Does your CTO actually Code?

Question

I've worked for a few organizations during my career, ranging from small to gigantic. In my most recent company, I've encountered something that is new to me: our CTO codes. Codes heavily, codes often. [This is not a small company].

Are any other SO users in situations where the CTO actually performs coding duties? If so, is this a good thing, or a bad thing? And why? Is this something more likely in a small, medium or large organization? And, any advice to other developers and leaders in an organization where this happens?

Answer 1

Well ... Depending on the scope of the CTO's responsibilities, it can be that he has to code to meet them.

Imagine making decisions on, for instance, programming language policy, and not being allowed to touch the languages. That would just be silly.

If the CTO is coding in the sense of "contributing to projects", then that (to me) would feel weird, if for no other reason than that the CTO often cannot take part in the rest of the project. Having meetings, talking about design, doing tests, talking to users, whatever.

Answer 2

Mine does not, and I personally think this is good. He needs to be concerned with other things like the technical vision and leave the programming up to the people who are hired specifically for it. Every time I have seen someone who thinks they should "dust off their skills" to help out ends up causing more problems than what they solve.

Answer 3

I work for a small company, arguably very small, and our CTO codes. I think the appropriateness of a CTO taking on developer responsibilities decreases as the size of a company increases, since officers should be focused on more administrative duties, and are often not in a position where they have the visibility necessary to make changes at the level of a developer.

Too often I think company officers confuse what they like to do, with what they should be doing.

Answer 4

Yes. And, after looking at his code, he most definitely should not.

Answer 5

Yes, our CTO codes and it's because we're such a small organization. This is a good thing IMO because it keeps him and his big brain involved in our product and thinking about actual coding/architecture decisions and not thinking about corporate-level junk like mission statements and other administrative debris.

Answer 6

Our CTO doesn't code. However, he has been coding twenty years ago, which is a good thing, since he can then appreciate our achievements and difficulties from a healthy viewpoint.

Answer 7

When I worked at a smaller company <20, the CTO coded and was also the chief architect. He was responsible for much of the code in the early days of the company. When I was leaving they were working on transitioning him out of the day to day code (He would troubleshoot bugs as well), and into a more strategy role.

The worst was the CEO also used to code, and I spent my last couple of months sitting next to a guy they hired to update all his old code...he had a lot of not so nice things to say about the code.

In order for a company to really grow you need to have leaders of the company who can be visionary. This means they need to detach themselves from the daily activities which includes coding.

Answer 8

In war if your general is also on the field fighting, then you are in big trouble. You don't want that. CTO is usually for big companies for someone to provide vision - how much people suck at it is another story :)

Answer 9

We have no CTO. Our VP of IS does not code. He has some background in doing some VB apps, but he wasn't really a developer per se.

Answer 10

My CTO does not code but he thinks otherwise.

Answer 11

It depends. You can't say a CTO should code or not. Depends on the person, the company's offerings, and what they need a CTO for.

Answer 12

If a CTO is coding in a medium to large company, he/she should not be in the critical path of any project at all. This should not be their role in a company of this size, otherwise they are abandoning what they were hired to do. They should experiment to stay current with the technology that's out there, but not on real projects.

If a CTO in that size company is coding on actual projects, then they are probably not really happy in a CTO position, and would probably be much better off as a lead developer, architect, or consultant.

If a CTO is coding at a small company or startup, that would be expected in the early stages. But once the company begins to grow, they'll have a decision to make. Either the CTO focuses on the CTO role, because it will require almost all of their time, or they should change their role, and bring in someone else who could focus on that role, if they still want to code.

In my opinion, it's perfectly ok for someone to remain in a coding role, even if they are an owner of a startup, IF, and ONLY if they eventually bring in someone to take on the full-time role of running the division. Many startups fail because they didn't follow this guideline.

I've been there, so I speak from experience.

YMMV, but I strongly recommend the above.

Answer 13

Yes, and his code is generally pretty good.

Answer 14

Unfortunately, our CTO does code. I can't comment on the quality of his code, because his project (which is a product sold and deployed to customer sites) is the only one in the entire company that isn't in source control, let alone built by our CI server.

Answer 15

At my current company yes, but we're 3 people right now so...

Answer 16

If he cods for fun or demos or presentations, sure, but having the CTO in the trenches writing code seems puzzling to me.

I often say, if you can say the word inebriated, you aren't.

If you are writing code, the CTO, you are not. :)

Answer 17

Well, i think, CTO should not code anymore atleast for the company, however, he should still know how and be good at it.

Answer 18

We're a big company. Nope, he just makes the decisions.

Answer 19

Our CTO codes, but usually not in the primary engineering department. He does some coding for another department that helps our users write to our external API. It helps him stay in touch with the customer needs and with the programming mindset. I think it is ultimately a good thing for the company.