Looking back 1 year ago, I realise the biggest mistake I made this year, which is also the biggest goal I set for 2019, was this phrase that I look at daily in the morning.
Be a visionary CTO not a coding CTO
I think it’s time to turn back the clock.
Speaking and reflecting with some of our investors, I found that many technical founders remained technical for a long time.
I, on the other hand, made a decision to stop technical work earlier in the year and dive in to help my co-founder out with sales, while juggling project management of the increasingly complex projects we undertake.
I made this decision based on 3 reasons (in early 2019, not naming names, you know who you are):
- I had a capable team
- I had a capable team leader (technologically)
- I had a system in place for good engineering
By the middle of the year, especially when we added lots of interns to the mix:
- My system has been ignored for expediency, developers started getting things done fast rather than right
- My capable team leader continue to be capable in engineering, but did not seek help when failing to manage
- My capable team, who originally asked for a larger team, found their productivity drop significantly (specialisation brings about n-square communication issues)
By the end of the year, my capable team leader left, my capable team undergone some renewal, and my old systems are in tatters, requiring me and the new leader to slowly pick up the pieces, and re-establish it, the same painful way I did for the first 3 years of the start-up.
This hit me hard.
I created this ship for everyone onboard to flourish, but it wasn’t easy finding the “start-up type” when we’re 5 years old, who could look at chaos brought about by growth and help put all the technical pieces into the same trajectory.
I created this ship for people to be independent investigators, but neglected the fact that they still need a lot of guidance, even when they won’t tell you. Some thought they need to man up, find that bug. Some cruise by even as they realise the rest are glancing at him often in an open office environment.
In fact at one point, we thought we needed middle management, a strange idea partly driven by our consistent absence from office due to meetings with clients, vendors, partners, and travels.
No. They needed me (and my co-founder but that’s another story for another day).
Every single one-on-one session, anonymous feedback session, and even exit interviews, had seen my guys speaking favourably of the time they get to spend with me. The more we get to build together, the higher the morale, the more likely they will stay, and the better the product created.
Every single time I turn into an unkind monster, I shoot myself in the foot because my guys end up rolling it themselves, and them finding themselves having to get out of a deeper hole.
But we haven’t reach a stage where we can afford a big sales team, so that I can focus 100% on tech and the engineers. So starting mid year, I started to straddle, even fully reserve myself as a developer resource on one project, hoping that they can accept me back into the team like a fresh recruit.
While it was a relieve for the old guards, it was an awful feeling for some of the new recruits to be so exposed.
5 years ago one of our very first engineering recruit was an intern who eventually signed up as a full time web developer. As a fresh grad, he benefited from at least 2 hours of interaction with me per day. Today, we’re 10x the size, many developers get 1 hour with me per week only. That has to stop.
My 2020 goal will be different. Still a draft, but I’m thinking:
Be a kind CTO and a coding CTO
Firstly, I must give up doing sales, if I want a functioning engineering team. The team must:
- Become the visionary the company needs
- Be fully absorbed and dive deeply into the engineering work assigned
- See me as a peer that they have the right to interrupt, seek help, and receive mentorship
First and foremost, we must retain the independent investigator culture. We don’t want to be a sweatshop (we can outsource should the business take a strange turn in the future).
If the team shares the vision, I don’t need to go everywhere telling people about our vision – they will do it and make it appear in the products.
If the team is deep in their work, they will teach. People who spends a lot of time on something always want to share with people who can even remotely understand what they are up to.
If the team bothers to talk to me, and if (big if) I’m kind to them, then their anxiety level drops, a major contributor to low quality output and low productivity. Thus the big predicate of being a kind person, before asking to be admitted back as a developer.
Gonna have to muster some courage to put this into my work plan due next month. Maybe I’ll answer these questions.