One of my resolutions for the year is to try to write more. It’s been too long since I’ve written something down and actually published it. Not to make excuses but somewhere along the way raising twins and taking on a new CTO job absorbed all of my writing energy, and even if I didn’t always realize it I was ending my days in a state of exhaustion. One of the number one things I’ve tried to protect the folks on my teams from is burnout, and I may have been headed down that path myself. I most recently worked the last four years as a startup CTO and have a lot of interesting experiences to draw from and write about. A lot of topics that I used to publish had been “how to” style articles on technical topics that I’ve found interesting. I’m still hoping to write some of those, and I’m also going to try to publish some of the things that I learned and encountered as a startup CTO.
The role of CTO really means so many things at different stages of companies and across various industries. When I say “startup CTO” I dont mean the first or earliest engineer that is brought into a company to code the MVP. I would define my role more as the person who sits on the executive team and is responsible for the engineering side of the business. This person needs to be extremely technical to manage multiple engineering disciplines, and also be able to communicate and liaison with other key members of the business, helping them understand whats possible with the current or future technology. I won’t go much deeper than that here because this isn’t meant to be a post on what a CTO is or does since plenty of those exist. But it helps to put into context some of the work I’d been doing and what I may write about based on those experiences. A huge portion of the job centered around building the team, and at an early stage startup there is generally no HR or Recruiting teams in place, so a large portion of the job centered around defining these hiring policies and practices. Other big focus areas were putting tools in place to increase efficiency, creating a learning/blameless culture, and ensuring we had the right tech stack and architecture to meet the needs of the business. Hopefully elaborating on some of these topics can help others that are also building their own teams or processes from the ground up, now I just have to make sure to hit the publish button.