While working in and mentoring startups, I noticed there are some very common mistakes that CTOs, especially first-time CTOs, make on a daily basis. I thought the list can serve as a reference for those who’re interested in working as a CTO (or tech co-founder), or is looking for to find a CTO for your own startup but you don’t have the technical background to vet the recruit.
So here goes!
Skills and resource misalignment
Engineers, designers, PMs and other roles that work in engineering organizations comes in all shapes and sizes, it is important for the CTO to understand the nuances of each TYPE of personality and skill set, and allocate them accordingly.
Let’s focus on engineering.
Engineers are not all created the same. Data scientists, systems engineers, solutions architects, solutions developers, DevOps engineers, Front-end engineers, etc are all focused on completely different engineering roles and specializations, and the skills and processes are often non-transferrable.
A common mistake for that young CTOs make is to think that anyone who can write code can plan, design, architect or manage. For example, data scientists typically have deep scientific and field-specific expertise in machine learning algorithms and data management techniques, but in general data scientists don’t need to be concerned about maintaining fail-over and high-availability requirements of a customer-facing deployment, thus they are not suitable to be architects of an engineering organization.
Obsessed with Building, unprepared for Debugging
Young CTOs are usually engineers by trade, they’re used to building. A typical engineer’s mindset is that you take pride in not just the functionality but also the quality of the code, and typically disregard the need to write automated unit / integration tests for your own code. In fact, when asked about the requirement, many engineers tend to get defensive and dismiss the practice as a waste of time.
But this cannot be the case for someone who is managing an entire engineering organization.
When you are managing multiple engineers, designers, QAs or PMs, you have to be cognizant of the fact that any member of the team, including yourself, cannot have full visibility with granularity into every person’s code.
Therefore, you need to have proper testing and monitoring processes in place to support root cause analysis, when things go haywire.
Many startup CTOs typically ignoring the processes, and end up working themselves and their teams to death during crunch time. Some others tend to cheap out on implementation of these processes, and do only basic network monitoring and functional testing. It’ll cost you countless days later, and it’s horrible for morale.
The recommendation is to setup full-track monitoring that traces everything from network connectivity, front-end rendering, server-side execution, to data stores. (NewRelic is a decent starter option) You will need this to identify bottlenecks before they happen, and to quickly identify problems when the system goes down. Secondly, write at least some unit and integration tests for critical parts of the system, it will save you countless hours in diagnosis the system and finding where the fault is.
This is unfortunately more common than we might want to believe, most irresponsible CTOs are not malicious, but they’re simply ill-prepared mentally to cope with the stress of being the leader of an engineering organization.
The main difference is in the mindset: an engineer is only responsible for his or her code, but a CTO is responsible for everything that is produced and all the processes that produce the code.
An irresponsible CTO, is typically stuck in the engineer’s mindset, and will refuse to take responsibility for other team members, especially for subordinates.
The recommendation is that when things go haywire, the CTO needs to take the lead in diagnosing the problem, explain to other functions in the company the problem and present to the company an actionable plan to address/fix the problem ASAP.
The last thing a CTO should do in times of crisis is to attribute fault to specific engineers and take no responsibility for what went wrong under the CTO’s watch.
Misunderstanding vertical and horizontal task distribution
Again, when you’re an engineer, you don’t think about these things. You think about hitting the keyboard, writing code from end to end, and then log off and go home.
But when you’re in charge of an engineering team, you need to know how to distribute work and do it correctly, and this brings us to the topic of vertical and horizontal task distribution, which a lot of startup CTOs tend to suck at.
If you think of an engineering product as a stack, and this stack needs to be served to different channels and clients. Vertical distribution of task here refers to dividing the work by separating different parts of the stack, and horizontal distribution is when we distribute work by separating deliverables for different channels and/or clients.
Why is this a problem?
Because for startups in the early days, people tend to wear multiple hats, and it’s very common to do horizontal task distribution and ask one engineering to “make the web app” and another to “make the iOS app”.
Is this bad? not necessarily, this trains people to learn different parts of a deliverable and become more generalist so they can be switched to different projects quickly.
What’s the downside? When you do this, you are sacrificing depth of skill for breadth. Going back to the skills and resource misalignment discussion earlier, when a startup expands, it is very common for the CTO to get stuck in this “you go do everything for this deliverable” mindset, and misunderstand how to utilize seasoned engineering expertise.
As a result? Engineering output will see diminishing returns on numbers of hires, because more experienced hires are not being utilized correctly.
Ego and condescension
This doesn’t sound at all foreign, does it?
Startup world is the playground of egoistic personalities, for good and bad reasons.
You need to have an ego to fend of naysayers, but as a CTO you need to understand one thing: you can’t be the best at everything, your job is to find the best-in-class talent and glue the organization together.
With that said, the CTO’s job is to learn and to respond to change, not to lecture and teach.
A common problem for startup CTOs is the inability to hand off the task and trust people to do the job. Startup CTOs (especially tech co-founders) tend to think their approach is the best approach and end up developing a callous response to opposing opinions and new ideas.
More importantly, since most engineers fall into one category or another, there is a chance that the CTO will eventually run into a situation where he or she is unable to understand the modality of work of other types of engineers. For instance, if a CTO came from a strictly B2C app development background, he or she will have a tough time understanding what a solutions architecture is, since the CTO never had to deal with designing a solution for clients.
These are some of the most common pitfalls of technology management that many early stage startups (before series A) run into and are often unable resolve. These are my two cents and hope it’s of some value to those hoping to grow into this role.
Until next time 🙂