{"id":2987,"date":"2020-09-05T15:02:15","date_gmt":"2020-09-05T05:02:15","guid":{"rendered":"https:\/\/eisabainyo.net\/weblog\/?p=2987"},"modified":"2022-01-09T14:58:12","modified_gmt":"2022-01-09T04:58:12","slug":"four-things-i-wish-i-knew-as-the-new-cto-of-a-startup","status":"publish","type":"post","link":"https:\/\/eisabainyo.net\/weblog\/2020\/09\/05\/four-things-i-wish-i-knew-as-the-new-cto-of-a-startup\/","title":{"rendered":"Four Things I Wish I Knew as the New CTO of a Startup"},"content":{"rendered":"

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\u2019t know I would struggle with it as much as I did.<\/p>\n

I was hired into the role because I applied for it (note: my motto is that if you want something, you\u2019ve gotta make it happen), I had a pretty awesome CV<\/a> 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.<\/p>\n

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\u2019t enjoy the \u201csales\u201d 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\u2019t my strong point and I didn\u2019t like fixing printer issues but I actually learned a few things about networking so I didn\u2019t mind it too much. Despite all that, I wasn\u2019t 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\u2019t look forward to coming into work every day.<\/p>\n

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\u2019t because I promised myself that I\u2019d 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<\/a> role another shot.<\/p>\n

*Why I resigned (side-note):<\/strong><\/p>\n

\"\"<\/a><\/p>\n

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.<\/p>\n

CTO Toolkit<\/a> is the result of my wish \u2014 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.<\/p>\n

---<\/p>\n

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.<\/p>\n

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.<\/p>\n

Insight one: Actions speak louder than words. Data speaks louder than actions.<\/h3>\n

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\u2019t 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.<\/p>\n

Insight two: Functional skills may be necessary in early leadership journey but what got you here won\u2019t get you there<\/h3>\n

Before becoming a CTO, I had always been a developer. I started my career as a developer<\/a>. 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.<\/p>\n

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\u2019t be able to help my team member if I didn\u2019t know how to do their job. I didn\u2019t 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.<\/p>\n

Insight three: Strategy and execution are equally important<\/h3>\n

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\u2019t help. What do you think? I\u2019ve learned that they are equally important, it\u2019s 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\u2019t make an effort to understand the company\u2019s strategy. In my mind, I would be thinking, just tell me what needs to be done and I\u2019ll get it done. Too much talking, let\u2019s start executing already.<\/p>\n

The consequence of this mindset was that I couldn\u2019t see the value I was adding to the startup and I couldn\u2019t see myself working there for longer. It wouldn\u2019t be so much of an issue if I was an individual contributor, but when you\u2019re a startup CTO and when you don\u2019t 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.<\/p>\n