The problem of having too junior developer as a CTO

As a longtime CTO, here’s a situation that I’ve come across all too frequently: Many early-stage business founders consider (and even hire) their Chief Technology Officer (CTO) based on their recommendation from someone within their immediate network. They meet the candidate, they ensure that they are capable of putting together some code, and they decide to give it a go. 

On the surface, there is nothing inherently bad about this kind of hiring approach. However, we should consider that a CTO working for an early-stage startup is not necessarily the same person that can foster the growth of more established companies. For the first, building (read: hacking) and delivering a MVP will be top priorities. For the latter, priorities include creating the right tech strategy and hiring the right tech team to help execute it and grow further. 

Let's pause for a moment and digest this. Consider the risks for your business and product team: If your CTO is a great hacker but has no predisposition for management, lacks interpersonal skills, or has limited experience with the topics at hand, it’s likely that you’ll experience a decay in the quality of your codebase, performance will be significantly impacted and you may have a hard time attracting proper talent to join your ranks as your organisation grows. 

In interviews with tech professionals, I often observe a desire to work in organisations that have products with proper tech architecture in place, employ clear and simple workflows, and use exciting tech stacks. All this, plus the possibility to mentor and grow in the directions that interest the candidate. 

If your CTO focuses too much on your product’s code and is preoccupied with tech challenges, they won’t allow for enough time to foster team members’ growth. This could potentially introduce a culture of non-transparency that will hinder your growth efforts. 

Possible impacts during various business phases

One of the key components of the thesis above is the notion that, depending on which stage your company is at, your CTO may need to be a different person. The various stages of company development and growth can highly depend on the industry and business context. If we imagine that we’re building an e-commerce system, the organisation's lifecycle could include the following stages:

MVP

This phase usually takes place during the first two to six months of a business’ founding. The MVP phase is when people put things together quickly, launch them, and obtain their first purchase from a customer. During this phase, certain things can be considered to be “throw away” tasks — after all, the focus is on proving that your current business assumptions will work. (I’ve seen a mix of 50:50 startups that throw away their initial MVP codebase, for instance.)

Once teams can get their model working, they’re usually able to access much better funding, which leads to hiring more senior tech experts. If that happens, even their tech stack may change entirely, meaning that certain aspects of the business remain largely fluid.

During this phase, CTOs are responsible for proactively validating the business feasibility of all brainstormed topics and ideas, solving issues as they arise, and playing a central role in suggesting technical solutions leading toward the MVP’s launch.

Early growth

This is the phase in which your MVP can be used as a foundation to further build upon. In this phase, business activities are still so early on that it might not yet be visible or obvious to everyone (including tech staff) that the business is accumulating a sizable amount of tech debt. In other words, the business will be grappling with the cost of additional work caused by choosing easy, temporary solutions instead of using a better, more complex approach.

It's critical to catch these types of issues at the early growth scale phase, as addressing them at this stage is still relatively simple and cheap (both in terms of time and money). One strategy to mitigate issues that I’ve witnessed in the past is a company’s choice to vertically scale — in other words, throwing bigger and more powerful hardware at the problem. While there is nothing wrong with this approach, it shouldn’t be seen as the sole solution to the problem. When fully relying on vertical scaling to do the heavy lifting, companies risk missing important signals of problems that are much harder to address at a later date.

For startups in early growth, having an experienced CTO on board can assist in attracting more developers to join the company. Through a focus on hiring and culture building, CTOs support company growth through careful recruitment of developers that will significantly benefit the team during the phases to come.

Scaleup growth

This is when any major mistake from earlier phases can (and will!) start to hurt. You could be experiencing lost requests if your product, site, or API are unstable. Customers may begin to complain about the speed of your services. Addressing changes in this phase can be rather expensive — there have been cases where startups were forced to pause any feature development to solely focus on resolving performance challenges and addressing bugs. 

To avoid these pitfalls, it’s important to understand what CTOs are responsible for managing within a company’s scaleup growth phase. By collaborating with key stakeholders and team leads (for example, Head of Product), a CTO can work cross-functionality to produce longer-term plans and roadmaps that revolve around the company’s ongoing growth. To support the roadmaps that are established, a CTO can then divide a technical team’s workflows according to the company’s internal structure and plans for growth. It’s at this time that processes and methodologies, such as Agile, can be implemented.

Two real-world examples of scalability practises

When looking at some past examples of companies facing issues with scaling, we need look no further than Twitter. Twitter’s scalability issues are an insightful topic to read up on. You’ll notice how the Ruby on Rails framework was at the core of the company’s scalability issues: In a nutshell, the company hit the limits of Ruby's process-level concurrency model and wound up needing a programming platform that provided higher throughput and better use of hardware resources.

This isn’t to put down Ruby, though: Using it, ecommerce platform Shopify managed to run millions of requests per minute and scaled just fine. 

This goes to show that it's not all about the tool or framework — these won't automatically solve problems without having team members in place with proper knowledge of how to use them. However, some tools are certainly better suited to some circumstances than others. 

How can I mitigate risks?

The reality is that hiring a CTO isn’t easy. It can often be both challenging and costly for businesses to find the ideal individual to step into the role, and because it’s a particularly demanding position, the incentive for CTOs to remain at a given organisation needs to be maintained. As CTOs are frequently responsible for handling highly complex issues that involve multiple members of the team, it can happen that the scope of their work can simply be too much for a single person to manage — this underscores the need to hire a highly skilled professional with the proper breadth of experience.

Coming back to the choice of your early-stage company’s CTO, the chances of finding a CTO who has both adequate experience and is seeking to join an early-stage startup are rather low. After all, the current job market is so competitive that it has become no small feat to hire regular developers (in virtually any coding language!).

With all of this being the case, my advice to mitigate the aforementioned risks is to lean on the expertise of highly experienced people who love solving these kinds of problems (so much that they willingly place themselves within them). More specifically, a partner who can offer a quality CTO as a service can take the burden off of startups and allow them to focus on the things that matter the most.

Employing the assistance offered by CTO as a service allows businesses to appointed an owner who will be responsible for the overall success and delivery of your project, service, or solution. While serving as a significant organisational aid and staff support, this service offering can also help your internal team diagnose potential pitfalls and prepare a strategic remedial plan. 

Here are some examples of tasks commonly managed by CTO as a service:

• Research and decision making driven by data
• Tech evaluation and analyses
• Various DevOps tasks
• Organisation and management of technical teams 

CTO as a service plans usually also come with predefined processes for not only running and managing the team, but also scaling it — including hiring and onboarding processes. There are even companies that specialise in setups in which guarantees can take the form of equity over immediate cash.

What will my investors say?

If you work with a well established and reputable CTO as a service partner, chances are that your investors already know (or know of) them. They’re likely to support your move to proactively mitigate the aforementioned risks, and they’ll certainly be more pleased than discovering that the company’s standing is suffering due to the simple mistakes of a single person.

In many cases, these kinds of discoveries can be uncovered during due diligence processes. Unfortunately, that can be too late and can leave your team needing to defend poor tech choices. You have the option of carrying out due diligence preemptively and learning from it. Doing so can reveal low-hanging fruit to significantly improve not only the impression of external auditors (when such an audit happens), but also to optimise your team’s existing processes, solutions, and approaches. Even if you choose to take this approach, be aware that not everything is visible in the code — instead, some of the optimisations could revolve around how your team members communicate and operate on a daily basis.

It’s important to consider what working with an external CTO as a service partner can offer to your current team. Discussing any risks (such as communication concerns, secure information sharing, and desired scope of work) with your team before moving forward with any external partnerships is crucial for maintaining transparency throughout the process.

To start things off, you can provide your team with a training session from an external agency or software house and use it as an opportunity to gain an important perspective on the inner workings of your company. If you do choose to engage with an external CTO as a service partner, it has the potential of taking your current team to the new heights, both in terms of personal growth and delivering quality results.