This article is more personal than technical.
I want to express my views on being a CTO and comparing them with those presented in Greg Bockman’s article.
As a CTO, I really liked the article and I found it very inspiring. Defining roles is challenging and talking openly about it eases the job.
The different paths
Greg defined 4 different options where a CTO can contribute to the organization: Do the work, Plan the work, Observe the work and Talk to lots of people.
The “Do the work” path
The conclusion of that article left me a little bit disappointed. I don’t share the opinion that “coding” is where a CTO can bring more value to a company.
As an early employee, your experience gives you an obvious advantage: you have learned from past mistakes and kept a couple of tricks up your sleeve. But is that the most efficient path?
No way Jose! My advice is to surround yourself with people who are better engineers than you. You can transfer your learnings and code along with them. Every time I committed to big coding adventures I was not able to attend other areas I could have brought more value to.
The “Plan the work” path
I think planning is something that should always be in the Product team’s field. At Redbooth they are the ones that keep the beat up. They plan the releases and prioritize what developers have to work on.
As a CTO I’m highly involved in those decisions. I give visibility to both development and product teams and also review the requirements.
This facilitates a better understanding between both.
The “Observe the work” path
This is similar to “Do the work”. Your experience from past decisions is important and being involved in architecture matters can be really productive too.
It is good to be aware of how things are done so that you can aid your team with solutions to a given problem. That being said, you should always leave room for your team to own more of those decisions or they won’t grow or be motivated.
A team that only executes orders is not a team you want to belong to!
The “Talk to lots of people” path
This is what I think a CTO does best and where you should invest most of your time. As an early employee you are used to wearing many hats and probably understand more than one part of the business.
In my experience most of the problems in a company can be reduced to communication issues. It’s the CTO’s job to reduce these obstacles and ease communication among teams, although I have to admit that to work on a startup that solves that problem makes it much easier!
Conclusion
I think the role of a CTO works best by sticking to the “Talk to lots of people” approach while, at the same time, keeping in mind the other 3 paths. Focus on your team as it’s likely to be the most valuable asset in your company; even more than the product you are currently building.
It’s crucial to concentrate on building a great team remembering that a manager who is not a “doer” is often not followed.