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 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.
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.
Top comments (14)
I remember my first dev job turned into de facto CTO role because no one else in the company knew about tech. I was barely 18 at the time and I hated it. I quit within 3 months and all the points you made really resonated!
Hope you have nice day!
Nice insights put in an interesting way.
Insights two and four, about understanding beyond functional skills and integrating into a process are two things I am working on recently.
If you are that CTO now, how would you approach the different roles that you needed to play at that startup?
Thanks! I am no longer working as CTO of a startup, I am now working as a senior engineering manager at an enterprise software company. If you're interested, you can read more about a day in my life these days: eisabainyo.net/weblog/2020/09/03/a...
Great insight!
I come from a non-startup background but my experience is different, yet the same. I've been a CTO of an established medium-size business for about 12 years and came on-board with the background of a senior developer, like you.
Our IT team is small because IT is not our core product. We are a manufacturing company, and the role of IT is to support manufacturing, through internal IT, network support, DevOps, and internal software products.
I find that I've been a hands-on CTO in the same way as you were for a long time. I wish you published your post sooner :) Your insight #2 hits very close - My biggest problem was for a longest time, an inability to let go of system or infrastructure, especially the one that I built, once I hired a capable team member. Also, the feeling that I need to know as much if nor more about each and every system my team works on so that I can be their technical resource, got in the way. Took me a while to realize, that a "bonus feature" of a CTO, not a hard requirement. The main job of a CTO is to provide vision & strategy, project management, support, resources, and organizational help to the team. Functional expertise in 1-2 fields is necessary, but it can't get in the way, of the actual job.
Im also interested in more specific details on what you'd do differently. I'm currently in this same position and trying to navigate these same waters.
Hi Zach! I am no longer working as CTO of a startup, I am now working as a senior engineering manager at an enterprise software company. If you're interested, you can read more about a day in my life these days: eisabainyo.net/weblog/2020/09/03/a...
Thank you for a nice and thorough article.
I started to wonder how much more valuable it makes a developer who also understands and actually embraces the points you brought out :).
Definitely, I used to be a developer who only cared about the beautiful code. I wrote an article about how to be an exceptional developer by caring more than just code. I will share it here on dev.to when I have a chance to syndicate some of my old content soon.
True some of thisgs are just a reflection of me couple of years ago... Learnt through my mistakes and I believe kept my patience. But moral of the story should be "one should be happy in whatever they are doing"
Really awesome article I think the hardest part is delegation is your from a IC role and to focus on the strategy plus the vision to make it work.
Good. Nice.
Great read, thanks for this!
Hi! Thanks for sharing, I really enjoyed reading it 👏 👏 👏
Some comments may only be visible to logged-in visitors. Sign in to view all comments.