For those that have worked their way up from developer to CTO, it can be hard to leave coding behind, especially if they love it. But there remain myriad reasons why it’s a necessary step to take and that if they haven’t already, why a CTO owes it to their team to make that leap.

Is all code created equal?

First, it’s worth defining the type of coding we’re talking about — specifically production software that needs to be shipped. Coding activities such as infrastructure, peripheral or utility application / tooling all come under the remit of a CTO, but the focus should be on enabling productivity within their team, ensuring platform delivery and identifying acute pain areas.

It also depends on where in the process a company is and the life cycle of the product as where will be times when a CTO needs to be involved in the beginning to make sure the product evolves in the right way. While CTOs in early-stage startups should have a coding background and be able to work through solutions with their developers, production software coding is not a value added activity in the same way as prototyping or architecting and ensuring quality.

Why should a CTO step back from coding when a business is scaling?

First and foremost, it’s a CTO’s responsibility to make the technology function work properly — they need to be aware of coding trends, language, best practices and developments to help inform that strategy. It’s a C-level, managerial position that orchestrates and facilitates rather than operates. CTOs should be concerned with how to build a good team — finding the right people and providing the space for them to work to the best of their ability — delivering solutions and interfacing with the rest of the business successfully. A scaling company needs a CTO that is not burdened by legacy issues and problems, but focused on driving revenue and business benefit.

The danger with giving in to ‘the love of coding’ is losing the business goals under the desire to build ‘amazing’ technology and reinforcement of confirmation bias. Understanding a particular language and everything it can offer, gives developers-come-CTOs the power to dampen a team’s innovation by quashing ideas and new languages. Instead of resisting this evolution, a CTO should be taking the knowledge and concepts from their team and using this make a judgement call.

A hands-on CTO can be distracted and fail to concentrate on the priorities that exist elsewhere, which can be wholly problematic when delivery is imminent. While the propensity to ‘get stuck in’ is always there, the need to strategise and focus on building something for the longer term should win out. Crucially, the other functions of the role don’t disappear and if ignored, the CTO is no longer capable of maintaining them and supporting their team as required. When coding is enjoyable, it can easily become an excuse to avoid doing the things that are either less interesting or more challenging.

CTOs need to be out there selling and scaling the business. By keeping a firm grip on the production code reins, they can end up holding themselves, their teams and their businesses back by undermining them, effectively training their developers and engineers to be too dependent. Before scaling, a tech team needs to be trusted to make technological and architectural decisions and every time a CTO steps back into production coding becomes a missed opportunity to build trust, relationships and skill.

‘Over-engineered platform have come from CTOs who spend all their time tweaking code, polishing it and building cathedrals.’ — Andy


Need to let go?

It’s the responsibility of a CTO as a leader to prepare their team to perform without him / her. As painful as this might be, this means putting faith in the team to deliver while allowing margin for error. It’s a matter of finding the right balance between delegation and trusting a team’s ability to problem-solve and dictating the solution. Steering the team to the desired end result can be done through clear expectations and communication rather than backing off so much that they’re left without direction.

We believe the best way to do this is:

  • If necessary, go ‘cold turkey’. If not, start care programming — let your developers write the code and you test it;
  • Delegate when possible and strategically; choose relevant parts of the architecture to pass on;
  • Build a team of quality developers and engineers. If you don’t have one, put to the founders of the business that there needs to be broader level of tech expertise;
  • Hire people that are smarter than you and if you’re unsure about stepping back from a project question whether you are really the right person for the job. More often than not, someone in your team will be so play to that advantage and let them use and build their skills;
  • Don’t make all the decisions and leave nothing for your team to explore or innovate otherwise they will leave you;
  • Ensure you create a space for your team to grow as a product and platform evolves;
  • Mentoring is invaluable — find someone a few steps ahead of you in the game and tap into their knowledge, learn from their mistakes and / or join a peer mentoring circle so you have a safe space to ask questions and share your fears; and
  • Utilise the people around that you trust and get the support that you need — don’t be afraid to ask for help you’re moving to a new area or facing unfamiliar challenges.

And if that’s not enough, remember:

‘Every line you code as a CTO is line of code your team doesn’t understand.’ — M. Blankenship