Ask HN: What are the activities of a CTO in a startup? | Hacker News Reader

Ask HN: What are the activities of a CTO in a startup?

7 pointslucasprim7 comments

I've recently been offered a post as CTO in a startup company, and as i talked to the founders i realized they were asking for a CTO but actually looking for a programmer. That raised a lot of doubt. After all, what is a CTO supposed to be doing in a startup? Programming? Assembling a Team? Managing a team? How would this change as the startup grows, would it be a leadership position or just a fancy senior programmer title?

I really appreciate any help :)

View on HN

Titles are pretty meaningless in most startup scenarios. It sounds more like they are looking for a technical co-founder and are using the C-level title as a carrot.

If there is not a team already in place, you will most likely be handling the early programming efforts until a team takes shape.

That's assuming a team ever does take shape. Depending on the vision of the other founders (and funding / budget), you may end up being the entire team. The title will look good on your resume but I wouldn't take it all that literally in regard to your day-to-day responsibilities.

Regarding how it may change over time, it very well could be a vanity title until another person is installed in the position over you. That's not always the case, but I've seen it happen. If you are given the opportunity to grow a team and play an active role in the technical vision of the company (assuming you're allowed to) you will probably grow with the position.

Source: Former "CTO" at two startups.

The joke goes, "CTO" is the title a founder gets when the engineering team they hired finally takes away their commit privileges.

It has approximately the same relationship to tech startups as the term "architect" has to enterprises. Avoid.

This has not been my experience. I've only worked at 2 startups, but in both cases one of the founders had the CTO title and in both cases the CTO was one of the best programmers at the company.

I'm sure there are some amazingly talented software architects out there, too. If it were me, I'd take VP/Eng before I took CTO (but I wouldn't take VP/anything until there were 20+ employees).

I was recently in your shoes and took the CTO position, leaving behind a very cushy, well-paying job at an established software company. It's more work than I was doing at my previous company, and I'm working a lot more hours than before (much to my wife's chagrin). I spend most of my time writing code (75%), but I do participate a lot in product discussions, strategy, and general managing (1-1s, code reviews, architecture discussions, etc). It's more of a VP Eng position than a CTO since I'm so hands-on, but, for me, the title itself is not relevant.

The startup raised a big seed round, and will go through a Series A fund-raising round within the next 6-12 months. My reasons for leaving the established company were to challenge myself and learn. I'm hoping to start my own company one day, so for me I'm trading financial well-being and stability at the established company for a crash-course start-up MBA experience. And in the event that we take have a favorable exit, than that's all the better (as much as I believe in the company, I do realize that statistics say otherwise).

Depends on two things. What you think of it, and what you make of it. If you go in there demanding 5% equity talking about what you can bring the team then think of yourself as a CTO. If you get there write some code employ another developer then think of yourself as a senior developer.

I have held the CTO title at several start-ups, including VC funded, though not at a HN style web start-up (YMMV). My job, greatly simplified, mostly consisted of two things: 1) setting the technical vision for the company, and 2) communicating that vision internally and externally.

As to 1, it's never consisted of a lot of programming (that's what you hire programmers for), but looking at the hundreds of more or less showstopper technical decisions that have to be made in a company every week, making a decisive decision, and being able to justify & live with it. A CTO has to be experienced, practical and savvy enough to make very hard technical decisions well enough not to screw the company down the road (you decided to go with a vendor that folded: Fail, your back-end architecture won't scale: Fail, etc.). A CTO who jumps on "new and shiny" needs to have a much better explanation than "new and shiny rocks!".

As to 2, being able to sell the merits of those decisions is vital. Early in the companies growth, that's making your internal technical folks good with it, even if they think they would have made a different decision (as they often would): why add this feature (or not), why this database instead of that one, why this deployment strategy, why hire that person over another, why allocate resources here and not there, etc. As the company grows (hopefully), I spend more and more time making non-technical and external folks believe in the technical correctness of what we were doing: the sales & marketing team, client prospects, press/media, potential investors, etc. By this point, I really should have turned over most any remaining day-to-day stuff over to operational folks, or I'll become a bottleneck for growth.

That said, a lot of start-ups slap a C-title on all sorts of stuff that they shouldn't. C-level is a strategic role, not tactical. Your accountant isn't a CFO, your best programmer isn't (probably) a CTO. The kid who updates the web site and is reading a book on SEO isn't a CMO. This doesn't matter so much early on, but if you ever decide to go the VC route, they tend not to like a C-heavy corporate structure. If nothing else, the VC will want to add strategic heavy hitters, and people tend to get butthurt when their title goes from CTO to Senior Programmer or some such.

Reply on news.ycombinator.com