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