Ask HN: What are the expectations of a CTO at a small startup?
I’m currently a co-founder and CTO at a small startup of only 3 people. The 3 titles we have are CTO, CEO, and CPO. One of the things that has recently come up are what kind of expectations are warranted for a person with the CTO title? I have a general idea in a larger corporation but what would you expect of a CTO at a very early stage (3 people) vs 10 people?
17 comments
To be fair with three people in the company position titles are meaningless. You will not get to do only one thing, nor will anyone else. Each of you is required to wear many hats and contribute at all levels. Even if that means cleaning the toilet before an investor or potential client comes for a visit.
You maybe the most technical of the group hence your CTO title. So the team is probably looking to you to drive the core tech decisions. Other roles have their key priorities respectfully. But even than you should all work more closely than ever and collaborate at this early stage.
You maybe the most technical of the group hence your CTO title. So the team is probably looking to you to drive the core tech decisions. Other roles have their key priorities respectfully. But even than you should all work more closely than ever and collaborate at this early stage.
"So the team is probably looking to you to drive the core tech decisions."
Remember that "core tech decisions" include hiring and managing a development team - hopefully your company will grow to the point where you'll need one, and it could be very soon, so you need to be prepared for it. Those kinds of decisions are much more important than what stack you build on or what cloud provider you pick, and with a much higher cost of fixing mistakes. Do any of the founders have experience with hiring and managing people?
Remember that "core tech decisions" include hiring and managing a development team - hopefully your company will grow to the point where you'll need one, and it could be very soon, so you need to be prepared for it. Those kinds of decisions are much more important than what stack you build on or what cloud provider you pick, and with a much higher cost of fixing mistakes. Do any of the founders have experience with hiring and managing people?
Agree with everything here. I’ve never been a CTO but have been the only other dev working alongside a CTO and you will wind up doing many non-technical as needed for the business. Laying a good groundwork for future employees and making a best effort in every task is the best thing to do.
Most of this makes perfect sense, but allow me to disagree with one point "Those kinds of decisions are much more important than what stack you build" the most technical founder should never lose focus of the importance of this.
Of course, if you don't have a business it doesn't matter what stack you're using, to build a quick RAT (yes RAT, not MVP) you don't need to go deep on the stack, but once those experiments are moving forward you've to be careful. You've to pick the right stack and tools to build your company, focus on that even more if you are a technology company (not a consumer one). This won't only be part of the scaling plan of your company but it'll also play a big role on recruiting if you're using new technologies you've to train people if you're using more mature technologies you probably have a better hiring pool in one than another.
Plus, you need to be able to share with your team the importance of picking one stack over another, the cycle of development and the times to invest in refactor or why to re-build something that started as an experiment but now needs to scale.
Plus, you need to be able to share with your team the importance of picking one stack over another, the cycle of development and the times to invest in refactor or why to re-build something that started as an experiment but now needs to scale.
Agreed.
I'd add that if someone is (a) unwilling to wear any hat at any time or (b) trying to take over people's hats without reason then you should drop them, quickly.
I'd add that if someone is (a) unwilling to wear any hat at any time or (b) trying to take over people's hats without reason then you should drop them, quickly.
[deleted]
I hate to be so blunt, but I think you need a wake-up call. There is absolutely zero reason to give an ounce of thought to titles right now. The three of you need to be laser focused on adding the maximum value with every action the three of you take. Talking about what a role entails at this point is purely "playing house" (in pg parlance, see http://paulgraham.com/before.html).
If you need to put on a fancy title in order to close a deal then so be it, but other than that you all need to execute on whatever are the most important tasks, delegating to whomever is most capable of each given task. That is it; don't overthink it or your startup will fail while you sort paperclips.
If you need to put on a fancy title in order to close a deal then so be it, but other than that you all need to execute on whatever are the most important tasks, delegating to whomever is most capable of each given task. That is it; don't overthink it or your startup will fail while you sort paperclips.
Do you plan to raise outside capital in the near future, or bootstrap?
With a seed round: low-volume but time-intensive recruiting (and of course coding). Although you might only hire 2 or 3 people in the first year, they'll - hopefully - be your biggest contribution.
The difference in output between a good 3-person team with decent leadership, and a fantastic 3-person team with outstanding leadership, is probably bigger than your own contribution as an individual developer. If so, the quality of the people you recruit, and how well you lead that team to quickly and thoroughly test the seed round hypothesis, will probably be your biggest contributions. Of course, you're still coding too.
OR…
As long as you're bootstrapping: CTO is developer, dev ops engineer, architect, most or all of product manager, and part or all of customer support and sales engineer. That continues until you have enough revenue to consider hiring someone at least part-time, which could be months or years. Think of yourself as a very committed individual contributor, or a product manager who has 1 developer.
As a 1-person engineering team, the biggest contribution you can probably make is deciding which problems not to solve, and which large swaths of the remaining problems not to solve. Make sure you're working on something people want. What half of any scope can you cut? Is feature X really as valuable as you or others think? Can you verify that with a day of work?
Finally, in both worlds: figure how who is handling product management. Who choose the functionality? Prioritizes it? Sketches the UI wireframes? Writes the UI copy? If you all are involved, is the CEO ultimately responsible for product/market fit, and if so, do they break disagreements?
With a seed round: low-volume but time-intensive recruiting (and of course coding). Although you might only hire 2 or 3 people in the first year, they'll - hopefully - be your biggest contribution.
The difference in output between a good 3-person team with decent leadership, and a fantastic 3-person team with outstanding leadership, is probably bigger than your own contribution as an individual developer. If so, the quality of the people you recruit, and how well you lead that team to quickly and thoroughly test the seed round hypothesis, will probably be your biggest contributions. Of course, you're still coding too.
OR…
As long as you're bootstrapping: CTO is developer, dev ops engineer, architect, most or all of product manager, and part or all of customer support and sales engineer. That continues until you have enough revenue to consider hiring someone at least part-time, which could be months or years. Think of yourself as a very committed individual contributor, or a product manager who has 1 developer.
As a 1-person engineering team, the biggest contribution you can probably make is deciding which problems not to solve, and which large swaths of the remaining problems not to solve. Make sure you're working on something people want. What half of any scope can you cut? Is feature X really as valuable as you or others think? Can you verify that with a day of work?
Finally, in both worlds: figure how who is handling product management. Who choose the functionality? Prioritizes it? Sketches the UI wireframes? Writes the UI copy? If you all are involved, is the CEO ultimately responsible for product/market fit, and if so, do they break disagreements?
With only 3 people, anything that helps tick things of the checklist of tasks.
For reference, as a CTO at a startup of 5 my tasks included:
Most development work (1 other dev) Product Manager Project Manager Managing at Tech budget Negotiating Vendor Contracts Office IT help desk Network Administraton System Administrator Colo tech (racking servers and network equipment) Office furniture Builder Customer Support Working with Patent Attorneys Managing the other C levels daily tasks Recruiting more people to reduce the list above
Sometimes it’s much more than you signed up for, but if it’s a business you believe in, you just keep checking things off the task list.
For reference, as a CTO at a startup of 5 my tasks included:
Most development work (1 other dev) Product Manager Project Manager Managing at Tech budget Negotiating Vendor Contracts Office IT help desk Network Administraton System Administrator Colo tech (racking servers and network equipment) Office furniture Builder Customer Support Working with Patent Attorneys Managing the other C levels daily tasks Recruiting more people to reduce the list above
Sometimes it’s much more than you signed up for, but if it’s a business you believe in, you just keep checking things off the task list.
Why is this coming up? Did y'all talk about the expectations of a CEO and CPO? Sounds like the beginning of you doing most of the work while the others coast. Anyways, the T stands for technology. It means you are in charge of delivering the tech that drives the business. The how is irrelevant, you can build it, buy it, rent it, whatever, it's your problem. Just make it happen.
I'm in the same boat!
So, I work as a consultant for a large hospital trying to create a startup. Myself and two partners are basically in the C roles. I am the "CTO"/"Technology Lead".
We used an agency to develop the initial version of our product so my first 6 months or so where mostly heads down with that team cranking out the product. While the other developers were focused almost solely on feature development, I also spent a good amount of my time focusing on larger issues like security, deployment practices, product/market fit (still working on that part), compliance, planning/product management, and even a bit of marketing.
My role flexes from some complex backend code to writing "light and fluffy" content on our marketing site. Basically, if I'm the best person to do something, I'll do that thing.
So, I work as a consultant for a large hospital trying to create a startup. Myself and two partners are basically in the C roles. I am the "CTO"/"Technology Lead".
We used an agency to develop the initial version of our product so my first 6 months or so where mostly heads down with that team cranking out the product. While the other developers were focused almost solely on feature development, I also spent a good amount of my time focusing on larger issues like security, deployment practices, product/market fit (still working on that part), compliance, planning/product management, and even a bit of marketing.
My role flexes from some complex backend code to writing "light and fluffy" content on our marketing site. Basically, if I'm the best person to do something, I'll do that thing.
Early stage CTO is more of a business process architect. From a technology perspective you have to do everything while at the same time think about the role that will be responsible for that task when the company has 100 people.
As you do the work, document the work as a manual and processes that will be given to the employee that will eventually be hired to be solely responsible for the task.
Lots of benefits to this, the primary one is hiring new people will be easier, even jr people with less experience will be more effective with documentation. The second benefit is it makes it easier to be acquired. The buyer will be able to quickly understand the key technical components of your business and what it takes keep operations running smoothly.
As you do the work, document the work as a manual and processes that will be given to the employee that will eventually be hired to be solely responsible for the task.
Lots of benefits to this, the primary one is hiring new people will be easier, even jr people with less experience will be more effective with documentation. The second benefit is it makes it easier to be acquired. The buyer will be able to quickly understand the key technical components of your business and what it takes keep operations running smoothly.
[deleted]
I agree with all the comments about titles, get rid of them and reconsider it when you get to series A.
As for what they would expect from you: don't focus on what's possible or hard technically. Only think about the outcome and the value created, then figure your shit out and build it. They will also expect you to be involved in business and sales strategy, don't be passive and simply observe under the umbrella of "I'm doing tech only".
As for what they would expect from you: don't focus on what's possible or hard technically. Only think about the outcome and the value created, then figure your shit out and build it. They will also expect you to be involved in business and sales strategy, don't be passive and simply observe under the umbrella of "I'm doing tech only".
I agree that they are mostly unnecessary with only three people. But I'll have a stab at a blunt division of responsibilities:
- CEO: Main purpose is making sure that there is a company to run. Get funding etc.
- CPO: (I suppose you intent it to mean Chief Product Officer) Main purpose is to make sure you build a product that the market needs.
- CTO: Main purpose is making sure that the product can/will be build.
- CEO: Main purpose is making sure that there is a company to run. Get funding etc.
- CPO: (I suppose you intent it to mean Chief Product Officer) Main purpose is to make sure you build a product that the market needs.
- CTO: Main purpose is making sure that the product can/will be build.
As cto you should know every piece of your tech stack that you have built and how it works
At an early stage startup titles for the most part are meaningless. CTO in those cases is synonymous to "the one putting our ideas into code".