Life of a Startup CTO

When I first started out working in software, I was so removed from the CTO I'm not sure I even knew his name.  A few jobs later, I think I met a "division" CTO once, but again, I am not sure I really understood what he did.  And now that I'm a CTO myself, I had to figure out what the role is without having concrete examples to compare against.

One thing I've noticed is that there are no "how to be a CTO" style books out there.  Possibly the closest might be High Output Management by Andy Grove.  Even with that though, it seems like there could be more tactical information about how companies and teams are organizing and running themselves.

In Andy Grove's book, one of the things that stood out to me was that the goal of a manager of a team is to optimize.  They need to optimize communication so that everyone is making the best decisions.  They need to optimize the skills of the team so that they can be more productive.  Instead of trying to figure out how to be the most individually productive person, the manager needs to sacrifice their own productivity for the betterment of the team as a whole.

From what I can tell (so far),  there are different roles the CTO plays depending on the stage of the company.  Our company is still in its infancy, so I can only conjecture at what the future stages will require, but I have seen a couple phases already.

The first phase is the "Grind" phase.  In this phase,  the CTOs only job is to get something built and into production so customers can use it.  This is truly a brutal grind.  I remember waking up at 8 AM, walking 2 blocks into our Palo Alto office space and start coding.  I coded throughout the day.  I coded as everyone else in the shared office space went home. And I coded until after midnight at some point until I couldn't see anymore.  Then I would go to bed and some sleep to wake up and do it over again.  Mason and I put in a crazy few months and I can say it was the hardest grind I've ever done.  And then we went live.

The second phase is the "Fill the Gap" phase.  At this point,  mostly I think the CTO is responsible for finding people and putting them into the spots that are causing the most pain.  Once the product goes live, the CTO plays sales engineer, tech support, lead developer, and product manager.  At some point (hopefully) the company has enough growth to hire people to fill the positions and put out the fires.  We had to hire more engineers to increase our bandwidth, a project manager/client success to interface with our clients (our services are very hands on with customers), and a product manager to help keep track of client requests and roadmap.  Slowly things started to fall off my plate which allowed for a little more planning.

The third phase is the "Build the Machine" phase.  I think we have just started this in our journey.  Instead of (...or really in addition to) just putting out fires, the CTO now needs to start understanding the processes and building/optimizing the team.  This is also when longer term planning for architecture and strategy needs to be thought about. Likely there's a bunch of technical debt plus a mountain of feature requests and internal roadmap items staring down at them.  Hopefully though, there's a great team starting to be built around them to start taking ownership of the higher level problems, rather than just tackling the problems in front of them.  In my case, I've started really noticing inefficiencies, and am trying random experiments to see if they can be fixed.  For example, someone mentions that scattered meetings during the day interrupt deep thinking, and boom, all the meetings I am in control of (1-on-1s, sprint planning,  etc) are immediately after the morning standup to open the rest of the day up.

The phases after this are really unknown at this point.  My hunch is that it will be more about team building and direction than hands on work.  Though, I'm currently still contributing directly to the code base on an almost daily basis.

Some interesting questions I have been been pondering...

• When do you switch from a small flat team to more hierarchy?
• When do you offload day to day design/patterns used in the code to somebody else?
• When do you switch from "everyone is a generalist" to have engineers focus and become more specialized?
• When can I justify hiring a devops engineer so I can stop dealing with AWS... ha!

I'm excited to see what the future brings. If I continue learning at the same pace I've been going for the last 2 years, I might know a thing or two eventually.  I can definitely say it might not be for everyone, but so far it's been an epic journey.