When I first became a Chief Technology Officer (CTO) of a startup, I was young and inexperienced. I was technically capable, had led multiple software projects and had a great track record on delivering software projects on time and within budget. But I really had very little idea about how startups work. I had no idea how I was going to be challenged when I took on the role of a CTO. I understood working at a startup, as a hands-on CTO, was going to be different from working as a developer in large corporations. I knew there would be unknowns but I truly didn’t know I would struggle with it as much as I did.
I was hired into the role because I applied for it (note: my motto is that if you want something, you’ve gotta make it happen), I had a pretty awesome CV and I guess I did well in interviews. As it was a small startup, I reported directly to the founders of the startup. I was basically the face of IT and software development arm of the startup. The startup model was a combination of Managed Services and SaaS. The role and responsibilities were many and I got a chance to wear many hats; I was responsible for internal IT infrastructure and operations such as maintenance of LAN system, DNS configuration, back up of internal services, data redundancy plan, and even printer issues. I was also responsible for bringing in businesses; meeting potential clients, pitching and talking about our solutions and liaising with existing clients and making sure they are happy. Then I was responsible for technical design and architecture of web applications; making sure they are robust and secure. Lastly, there is people management aspect; hiring, growing and providing suitable assignments for my team members.
Funnily enough, for the four main areas that I was responsible for, IT, client liaison, software development and people, I thought I did most of them quite well. Even though I didn’t enjoy the “sales” aspect of client liaison and pitching, I won a few clients as a result of my honest and straight-to-the-point approach. Founders were delighted and it was all good. Software development was my jam so I did well there and I really enjoyed that aspect of my role. I also had a great relationship with my team members; we were a close-knit team and we would even hang out outside work hours. Internal IT wasn’t my strong point and I didn’t like fixing printer issues but I actually learned a few things about networking so I didn’t mind it too much. Despite all that, I wasn’t feeling happy and I always doubted that I was doing a good job as a CTO. Everything was so chaotic. I questioned my own abilities and the value I brought into the company. I didn’t look forward to coming into work every day.
As a result, I quit my well-paying job as a CTO after just a year and went back to being a developer. I remember wanting to quit sooner but I didn’t because I promised myself that I’d stay at the startup for at least a year. I kept my promise; I resigned* in the month of my one-year anniversary. After that, I was so much happier and thus, I never really sat down to think about why I felt so unhappy as a CTO of a small startup. Until much much later when I decided to give the engineering management role another shot.
*Why I resigned (side-note):
I resigned because I felt lost. My wish then was to have someone show me the ropes, walk me through step by step, share best practices and point out the pitfalls so I could take the quantum leap to a smarter, sharper, wiser CTO.
CTO Toolkit is the result of my wish — rather than going through trial and error and learning from your own mistakes, you can learn from seasoned technology leaders and apply the best practices that have been proven to work.
---
Almost more than a decade later, just a few months ago, I was speaking to a new startup CTO and I saw my younger self in him. He is technically capable, is an awesome team player, and has an impressive CV. He has recently taken on the role of a CTO at a small startup and he told me he is struggling.
I am putting together this article with the hope that it will help new startup CTOs in challenges that they might not necessarily find the answers for in leadership books. A lot of the challenges that I faced were due to not having a strong foundation of business acumen and lack of strategic and forward-thinking.
Insight one: Actions speak louder than words. Data speaks louder than actions.
Many times, I was asked to come up with a proposal for a project by founders. It could be a new business idea or an additional feature to an existing solution. I then usually provided an estimate on how long it would take to deliver the project, how many developers would be needed and so on. I never questioned the status quo. These days, I have come to realise that leaders don’t want someone who would just execute without questioning. Leaders want someone who would come back with research, data and finding on whether something is worth doing or not. Especially at a small startup.
Insight two: Functional skills may be necessary in early leadership journey but what got you here won’t get you there
Before becoming a CTO, I had always been a developer. I started my career as a developer. So I was very comfortable with my functional domain; when my developers asked me about programming best practices or when they needed help with debugging a tricky code, I would be there giving all the right answers or worse, solving the problems for them. When there was a need to hire a server administrator who would be reporting into me (back then, they were called server administrators instead of devops engineers), I freaked out.
After freaking out for a few days, I started reading all the books that I could find about server administration. For a few weeks, Bash was my best friend. I was worried that I wouldn’t be able to help my team member if I didn’t know how to do their job. I didn’t realise that having functional skills are not as important as having a vision, knowing and understanding what needs to be done and being able to take people on a journey of why we are doing what we are doing. If only I knew that, I would spend less time trying to upskill myself on technical skills of server administration and spend more time with my server administrator explaining the why.
Insight three: Strategy and execution are equally important
There is conflicting advice in the business world on which one is more important; strategy vs execution. Some say that strategy is more important; without a clear strategy, everyone will be shooting in the dark. Others say execution is more important; if there was nobody on the frontline working on delivering results, having a strategy printed and stuck on every wall couldn’t help. What do you think? I’ve learned that they are equally important, it’s not about one or the other because they are not mutually exclusive. I wish I had known this because earlier in my career, I was in the latter group, those who think execution is more important than strategy. I didn’t make an effort to understand the company’s strategy. In my mind, I would be thinking, just tell me what needs to be done and I’ll get it done. Too much talking, let’s start executing already.
The consequence of this mindset was that I couldn’t see the value I was adding to the startup and I couldn’t see myself working there for longer. It wouldn’t be so much of an issue if I was an individual contributor, but when you’re a startup CTO and when you don’t understand the vision and strategy that the company has, let alone buy into it, your team members are going to feel the same; lack of clarity, uncertainty, and enthusiasm in general. After all, no employee, even the most introverted developer who enjoys low-level programming, wants to be a cog in a machine.
Insight four: Not all processes are evil
It’d be hard to imagine in this day and age, but I did indeed run an engineering department at a startup with no formal process for a year. There was no project management or collaboration tool in sight, everything was done via emails. I’d come into work early every Monday and list down priorities for the week. I would then assign tasks to my team members via an email. We would then discuss the tasks when everyone was in the office. It wasn’t a standup because sometimes we would do it via an email, or face to face while getting our morning coffee, and other times, we would just huddle around someone’s desk to discuss. There is no consistency. Every Wednesday and Friday, all of us would send an email updating each other about the progress of our work. Code reviews were done mostly by me, my developer would ask me to come over to their desk, and I’d provide feedback on their code there and then.
Not having any kind of process meant it was hard for us to know if we were working efficiently. A lot of tasks couldn’t be shared because there is no way for a different person to know how to even begin doing something. Documentation was non-existent. I was lucky that there was no staff turnover in the year that I was there. Otherwise, handover and onboarding new people would be quite expensive, not to mention chaotic. Another problem with not having any kind of process is that I felt like I was a gatekeeper for many things. I couldn’t scale myself. But I had to admit, back then, scaling myself wasn’t something I had in mind. I just remember feeling very overwhelmed every single day. These days, I strongly encourage startup CTOs to make use of agile project management templates to keep track of progress through a light process.
Final words
Those were the four things that I wish I knew as a CTO of a startup. Firstly, I wish I knew how to challenge the status quo with data. Secondly, I wish I knew how to add value to my team beyond functional knowledge. Thirdly, I wish I knew strategy and execution are equally important, and how to communicate strategy in a way that’s relatable and motivating for others. Fourthly, I wish I knew not all processes are evil, in fact, having no process is eviler.
Last but not least, I wish I knew everything in life can be learned, whether it’s technical skills, business skills or something else; you just gotta stay curious and have the willingness to improve.
---
If you enjoyed this article, you might like to check out my latest book on engineering management. It's a practical guide for engineering managers at tech companies.
The Engineering Manager’s How-to Guide is very targeted for engineering managers, and in this book, you won’t find generic advice like having regular 1:1’s, giving feedback, etc. Yes, those things are absolutely important, but they are not specific to an engineering manager’s role. It’s my goal to make sure this book provides a concise and actionable guide for engineering managers, the specific and niche content for engineering managers that you won’t find in other leadership and management books.
