I was sitting with a business co-founder Michael, discussing the growth strategy of his startup when this conversation happened.
“I hired him to implement the MVP and expected him to write the code himself, instead he hired a team to do it and became a manager.”
Just a little bit more background: this is a 10-man early-stage startup in the CRM space, with the product already launched into the market and gaining some traction. They are close to raising the next major funding before eventually depleting the seed funding.
Their investors are looking at several KPIs closely. Delivery of a few important features is one of the targets. And it seems the tech team is lagging behind on this, hence the rant from Michael.
I posted a barrage of questions to Michael. What did they discuss when he hired him (let’s call him Ray)? What are Michael’s expectations of Ray? What is Ray’s understanding of Michael’s expectations? What is Ray’s daily activity? How does he manage the tech team?
According to Michael, his expectations of Ray (and Ray’s understanding of the expectations):
- implement the MVP,
- write the code,
- be involved in the product.
Is that all?
I am certain Michael’s investors are going to do a thorough technical due diligence on his startup in the next funding round. It usually means several hours of grilling of the CTO, followed by a long list of questions via email.
Ray will have to know the code well, know the architecture, functionalities, limitations, known issues well in order to survive the grilling. Any unsatisfactory answer will dim the chances of the funding approval.
Besides having a whole-picture view of the technology at all time, Ray will have to work on a roadmap to scale up the application.
The number of users is increasing, the data they generate daily is piling up quickly in the database. It is important for the tech side to plan ahead according to this trend or they will suffer a spectacular crash one day.
That said, it is difficult for someone who is involved in low-level execution (i.e. coding, fixing bugs) to also do the planning at higher level. At some point of time, the team will need a full-time person thinking ahead of everybody else.
According to Michael, Ray works with him to understand what to build from the sales and marketing, translates the understanding into technical requirements, delegates the design and coding tasks to the engineers. He almost never write any code.
He does however review engineers’ work and spend an awful lot of time in one-to-one meetings with each of them. It seems to Michael, Ray is becoming a middle manager.
I cannot say Ray’s doing a bad job. It is certainly unusual for a CTO to not write any code in a tech team of only 6 people. And of course this is what Michael thought Ray was doing. He did not stare at his screen at the time to determine exactly what Ray was up to.
One thing is certain: Ray can code and he reads his team’s code constantly. That to me is more important than he actually wrote the code that ended up in production.
Ray still need to remain a highly relevant team member, having delegated the coding away to more capable engineers than himself. He will quickly lose the confidence of the team, if he couldn’t keep up, couldn’t participate in architectural or data model discussions, or if he always rely solely on others’ opinions to make a technical decision.
Being able to read the code makes him relevant.
There are certainly some trust issues between the two co-founders. I urged Michael to speak to Ray on his concerns.
If I hire a CTO, I would trust him entirely with the technical aspect of the business. Execution is what matters. Ray did deliver for the most part.
I often find that people expect CEO to be the guy who delegates all day everyday, but they expect CTO to be “superhuman”. I have more than once urged a CEO not to micro-manage his CTO, or whatever he called his first tech employee.
If delegation+coaching is a skill the CTO brings to the table, do have respect for what he does.
Lastly, there are ways where CTO could write some code in addition to his regular duties, to sharpen his tech skill, remain relevant and potentially contribute immense value to the company.
He can perform some “spikes” (coding experiments) that could improve the application’s performance, code up POCs of the next-gen architecture or prototype new products, or even create some internal tools that help improve the team productivity.
These look like something that could be delegated to new hires. But actually new hires often lack the technical skills and business insights to make new products work from scratch. New hires learn faster maintaining the main product line.
You can be a CTO without writing code, a better one if you do write some code.