Figuring out what a Startup CTO actually does

I just passed my two year anniversary at Snapdocs. In that time, the engineering team has grown from two contractors to eight full-time members. Also in that time, I might have actually figured out what it is I’m supposed to do as the CTO.

Or at least, I’ve figured out all the things I could do.

I’m still narrowing down what I should do versus what I should delegate and what I should automate.

I’m posting this here to help get my own thoughts straight. Maybe by putting it into words, priorities will emerge.

So what does a CTO actually do? Well it could be…

You write code

• Delegate? Definitely. It’s why you hire engineers. I probably still code 15% of the time. It will be a sad but proud day when that’s down to zero.
• Automate? Where possible, definitely. (Is it possible?)

You review code

• Delegate? Definitely. But admittedly, I still code review nearly everything. I have a hard time letting this go, because I still feel responsible if anything breaks.
• Automate? Definitely. As the team has grown, adding static analysis (Overcommit, RuboCop, Brakeman) has saved an enormous amount of time. It’s also made code reviews more interesting, because the robots catch the boring stuff. And currently, our test coverage is at about 75% (I know, I know, but we’re working on it.)

You deploy code

• Delegate? Currently, we deploy about once a day. It’s a somewhat manually, needs-to-be-babysat process. I want to get to a place where we don’t need a Release Air Traffic Controller. We’ve got a CI, and wouldn’t CD be nice? But we’re not there. And this tends to only fall on a few peoples’ shoulders, which unfortunately tends to be the engineers who work late.
• Automate? Working on it.

You pick what gets coded

• Delegate? This comes from all sides– sales wants features to close a deal, the engineers want to pay down tech debt or to add something new and cool, and there are flaky specs, and there are small bugs, and there are big bugs, and there are great new features –and it’s important to balance it out
• Automate? That wouldn’t even make sense. But there is probably a better solution that keeping an imaginary formulate in my head.

You very reluctantly do DevOps

• Delegate? For reasons not worth mentioning, we can’t host on Heroku. We’ve got a mix of AWS solutions, and frankly, it’s a bit of a weak spot for the team.
• Automate? Desperately.

You talk to current customers

• Delegate? I really like talking to customers. I learn something on just about ever call. Ideally, I want every engineer to talk to customers. And I don’t want to stop.
• Automate? Maybe? We definitely leverage Zendesk pretty hard.

You spec out / design features

• Delegate? We have an excellent designer. And the engineers have pretty great wire-framing skills. But… Is it greed? Is it a joy-in-using-Balsamiq that I won’t put this one down?
• Automate? No.

You hire a team

• Delegate? As the team has grown, I’ve worked to include everyone in the hiring process. But I have no plans to ever totally exclude myself.
• Automate? I wish! This takes an enormous amount of time. I’ve tried recruiters. I’ve tried hired.com. I’ve tried an employee-referral bonus. I wish I could brag about something here, but alas…

You manage who is working on what

• Delegate? Right now, I set a direction and it’s a mix of self-management and me trying (and sometimes failing?) not to micromanage. I want to see how scalable this is.
• Automate? No. But we’ve gotten pretty deadly with Trello.

You manage your team

• Delegate? I have bi-weekly one-on-ones with my team. This was the most surprising part of my job (I’ve never worked anywhere that had a good one-on-one-culture) and I love it.
• Automate? I’ve been thinking of doing some sort of automated 360-review? Or weekly team sentiment measurements? But for now, it’s a no.

You manage out and up

• Delegate? Talking to sales? Talking to the CEO? I think that’ll stay squarely on my plate.
• Automate? We added a Github hook that tells Slack about any changes that get pushed to production. Two results from this: i) engineers write much more human-friendly commit messages, ii) the rest of the team knows exactly what we’re doing and when.

I could go on, but this is approaching the “4 min read” mark. Things I haven’t mentioned: choosing technology (this is mostly saying no to JS MVCs) and keeping an eye on security (we’ve hired pen testers and passed a SOC2 audit).

Does that sound right? Am I missing anything? Have I misspoken? I’m definitely curious for feedback.