The most common answer to that question often times ranges from "None at all" to "Not as much as I would like". And that's typically because most CTO's (Chief Technology Officers), are too busy managing developers and attending meetings at all hours of the day, which has more to do with what a CTO should be doing. At least on paper.
My answer is a bit different though. Because it's definitely not "None" and on most days it's probably closer to "too much". Because working for a startup, which is what I've been doing for several years now, is 100x different than working for an established corporate entity.
So let's start there and expand upon why the role of CTO really will depend on a large number of factors, but mainly the stage of the company and just how big your team is. And how that usually means that I get to write a substantial amount of code on a daily basis.
Startups are different
Almost every startup that I have encountered in my career has started off in the exact same manner. With 1-2 people and not enough funding to last more than 6 months. And those limitations are what sets a startup apart from everything else.
For one, you can't just hire developers, or else your 6 months of runway will dwindle down to 1-2 months, and that's just too risky.
So there's very little managing of developers usually that needs to be done in the beginning.
But more importantly, startups don't typically have much (or any) code to start out with. And that initial phase of the company is what a CTO will spend most of their time working on. Not always, of course. I've worked with startups with established CTO's that pretty much outsource development to other companies, at a huge cost. Not very common.
You're still attending meetings, sure, but there typically won't be someone else to hand off the meeting notes to. Because you're that person.
And even if you are lucky enough to have a small team of developers, there's a good chance that they won't be senior lead developers with a decade of experience, because the costs associated with hiring someone at that level are prohibitively high.
And that's where the majority of my time as CTO actually goes and has gone through several companies now.
Architecture
Ideally, you would think to just type out:
npm i create-react-app
And voila, your architecture is set up and you have a website up and running.
Except that this architecture is probably better suited for a personal blog or a hobby website, at least without heavy modification.
But production/enterprise level architecture is more complex than that, and there's alot more to take into consideration, such as performance, security and separation of concerns. And even costs, because it's pretty much the CTO's job to also gauge development costs and measure ROI on different tools and services.
And there's also business specific requirements that need to be addressed as well. For example, if you're building a website targeting multiple countries, then having some level of localization logic baked into your product will be important.
Often times, such as in my case, much of this initial architecture is coded out the by me. Not always of course, but as I mentioned above, most startups start out with 1 or 2 people. And typically one of those 2 is the technical founder.
And this initial architecture can be incredibly complex and time consuming to build.
And to add to this complexity, often times business logic changes on the daily, meaning that giant chunks of logic and code will need to be either removed, or transformed into something completely different. Whatever you think that you are building is going to look completely different after 6 months. Some features will be wiped out, other features added, and some will even function in a completely different manner.
Once you have a stable codebase however, typically somewhere around the 4-6 month range, then you might notice that development time is reduced. At least daily development, as maintenance is pretty much ongoing for the life of any project.
And alot of these changes require some heavy changes to the architecture (named above). I recall recently having to work on an internal video chat tool for our company. There were several routes that we could have taken to accomplish this, and we ended up choosing the one that would get us there the fastest.
After having spent a few weeks coding out this particular library, we almost immediately began to see the limitations and issues that were present. And after much research and various tweaks, we decided to scrap the code and to go with our 2nd runner up solution.
That initial choice came at a cost, not just time for development, but a financial one as well. And this is pretty common overall during the pre-beta build of any software solution.
Aside from writing code myself for new features and maintaining the initial architecture, I also do indeed have to manage a small team of developers.
If your company is lucky enough to have developers to manage, then for sure you will spend some portion of your time reviewing code and making changes if necessary.
This comes down to years of experience more than anything else. Every developer early on writes code based on their current skill and knowledge set focusing mainly on the programming language and framework.
But things such as security, performance, policy and even SEO often times get left out of the equation. And that's often times where I step in to fill in those gaps as I have done those things many times over now.
However, because I do have several years of experience as a web developer, I am also mindful of knowing what I have to code myself versus what I can simply npm install.
And often times, maybe not surprisingly, I do favor the quicker 3rd party implementation over a custom approach. So while I do have to spend a huge portion of my day actually writing custom code, I also leverage pre-built components as much as I can in order to save time and reduce costs.
But quite possibly the biggest reason why I do have to spend so much time writing code myself, is because the role of CTO is kind of high on the corporate list and that means that there is an expectation that I should have my eyes on every part of the companies tech stack. Particularly during the early stages of the company.
And that's a part of being CTO that very few people actually talk about. That rift between engineer and manager is often times larger than you would estimate, and the expectations are typically towards the manager side.
In the future
Undoubtedly as the codebase becomes more stable and as the development team grows in the future, my role will look a bit different in the company. There will probably be less code to write, for me personally, and more code to write for the rest of the team.
Because I have read plenty of stories time and time again of established CTO's working on billion dollar projects who have not seen any code in years. Their days are so filled to the brim with meeting after meeting and typically senior level engineers take over as the actual project managers.
For now though, I'm still enjoying the process and I still get to practice my coding chops almost 2 decades into this field. So I will enjoy it while it lasts.
Walter Guevara is a software engineer, startup founder and currently teaches programming for a coding bootcamp. He is currently building things that don't yet exist.
Stay up to date
Sign up for my FREE newsletter. Get informed of the latest happenings in the programming world.