The Mistakes I Made as a New CTO

Things usually get started for a reason, which was how I kickstarted Madison Technologies. All too often, we forget that there are reasons why we do things. I enjoy learning through failure. To fail, you have to be an idealist to pick the path you want to go down. I chose this path because of the lessons I learned as the founding CTO of GOJEK (now called GoTo and publicly listed on the Indonesian Stock Exchange.)

THE JOURNEY WITH GOJEK IN 2014

I joined GOJEK in December 2014. I was the new CTO and arrived just before launching the mobile app. We were a merry team of 3 core engineers, and I was the new addition. The hard work to get the app built had already been done, and I was ready to take the helm when we launched. Looking back, there was excitement, but I was in over my head then. It felt like there was so much to do and no time or manpower to do it with. Regardless, I got to work and split my time as best I could to eventually launch.

One of our first launch events involved gathering a small group of journalists at a restaurant in SCBD, Jakarta. Nadiem, our CEO, delivered a presentation, after which we invited the journalists to download the app and experience booking Gojeks firsthand. However, during that time, we encountered a troublesome bug: the service which displayed the map with all the drivers would crash, causing all the drivers to vanish from the map. This also meant no one could book a ride, and we would have to restart the service.

And then, 5 minutes before Nadiem finished his presentation, I glanced at my phone and saw that the driver map was blank. I sprinted to my laptop as fast as my jelly-like legs could carry me, praying that the 3G connection from my phone would let me at least SSH into the server to restart the service. Luck was on my side that day, and I managed to restart the service in the nick of time and sat there hyperventilating as journalists became excited that they could reserve their driver. Here’s a photo of us at the end of the launch event.

From left to right: Sam, Kevin, me, Nadiem, Mikey, and Rio

TECH IS MORE THAN THE CORE PRODUCT

There were many stories like the one above. The app was our primary focus, and back then, we had a lot of fires to put out. As our users grew, we encountered errors and bugs we had not seen before.

During this phase, I took on a tactical role, getting hands-on with the code and trying to debug issues that popped up. One time I was memory profiling the same driver service because it seemed like the garbage collector was making the whole service (already at 98% CPU usage) hang. It took so long that I decided to give up and rewrote the API from Java to Go, swapped it out behind our load balancer, and watched in astonishment as the CPU usage went down to 3% for that server. It felt great, but it was not what I was supposed to do.

I needed more people, and I needed them fast. I should have paid more attention to so many other areas of the company that needed help. For instance, our operational dashboard, where we tracked the onboarding and management of drivers, badly needed an overhaul. Would you believe we used Post-Its to track some of our database fields? No really:

We tracked our database fields on Post-Its.

And then there was our analytics to track how our ad spend was doing. We used many SDKs, but here’s a peek at an exchange I had with the AppsFlyer team back then:

So many other areas that needed my attention were not getting it. I was stuck in this hiring drought and in a mindset that would not have me spending our already scarce money.

WHAT I WOULD HAVE DONE DIFFERENTLY

First of all, I would have spent much more time developing a network of smart individuals from the tech space. Individuals I could bounce ideas off of or ask for help when needed. I imagined I had to closely guard all my secret IP and not talk to anyone. Worse yet, I am an introvert, and conversations do not come naturally. And as a result, I could be better at maintaining contact and cultivating relationships. Had I worked on that through my network, it would have been significantly easier to get help or recommendations on hires.

Next, I would have parallelised more. I was on a hiring spree, but there comes a time when hiring reaches a point where you have a bunch of interviews and potential candidates, yet progress stalls. I was quite cautious and hesitant to invest in an outsourced team to work on projects simultaneously. My focus was solely on filling the in-house positions, which, looking back, turned out to be a misstep. Had I shifted my mindset, I would have temporarily staffed my operations and marketing teams with an outsourced engineering team and allowed those work streams to move in parallel while I worked on more challenging problems.

WHAT WAS THE IMPACT OF THESE MISTAKES?

Looking back, my mistakes’ most significant impact was a loss of time. This is not something you can ever get back; to a startup, time is often a scarce resource when trying to compete with others in the space. We could have moved faster if I had run the work streams for operations, marketing, and HR in parallel by hiring an outsourced team. We would have also had more data to feed into our app development.
Lastly, we could have been even more attractive to the VCs by gaining back that time and would have raised cash sooner. Though having been part of a few fundraises, none go as smoothly or as fast as you expect.

LESSONS LEARNED

1. Identify where you need Tech

Though it might sound simple, it is one of the most important lessons I learned. Tech is not just your core product.
The application of technology extends beyond engineering and into various other departments such as Operations, Marketing, HR, and Finance. Newer CTOs can sometimes overlook this reality and not provide the necessary support to these functions as promptly as required. I sure was, and in hindsight, my initial step would be to broaden my focus beyond the product.

2. Give Up Control

Another rookie move on my part was to take sole ownership of all things tech. By trying to deliver the tech to the other teams myself, I slowed everyone down, including myself. Had I placed a temporary or outsourced team with a good tech lead in those functions, I could have empowered the function owners to take charge and develop solutions according to their requirements. Their reliance on me would have been limited to significant matters such as architecture and overall cohesion. I realised that by trying to control everything, I was using a 2x mindset and not a 10x one.
So, give up control, give your co-leaders the resources, and get out of their way.

This brings us right back to why I started Madison Technologies. We’re here to help you move things faster. We’re here to pick up the slack while you hire your dream team. We’ve been there before, and we will get through this together.

Feel free to reach out to me via my LinkedIn for a more in-depth conversation. Let’s connect!

About the Author

Sheran Gunasekera is a security researcher and software developer. He is co-founder and Director of Research for Madison Technologies, a software development company in Singapore, where he advises the in-house engineering team in both personal computer and mobile device security. Sheran’s foray into mobile security began in 2009 when he started with BlackBerry security research. Since then, he has been in leadership roles in both engineering and security at several startups in Asia including GOJEK, the on-demand multi-service app that is now publicly listed.