Diary of an Accidental CTO, Part 2

Mostafa Khattab is CTO at Wakecap Technologies in Dubai.

He has agreed to share his thoughts with CTO Academy about his experience of being an “An Accidental CTO” … aka someone who arrived in the CTO role ahead of schedule and is grappling with new challenges and very steep learning curve.

For those who missed Diary of an Accidental CTO, Part 1 you can start here but for the rest, please read on …

“Having introduced some context in Part 1 to my current role and the accelerated shift into my current CTO role, I want to use Part 2 to walk you through some of the technical mistakes I made during my own learning curve, how I would try to avoid doing them again in the future and maybe help someone else who lands in a similar situation …

After my sudden promotion in a fast growing technology startup, I was unsure about many aspects of the role. About what should I do, how I should do it, and also how I recognise whether what I was doing was correct, best practice etc. I felt at times like a rabbit in the headlights.

Re-Inventing The Wheel

People always says never build it from scratch, but when you are in charge of building something that will hopefully stay around for a long period of time, the idea of building your product from scratch allowing you to be in full control is an attractive one.

Unfortunately, people always say it because it’s largely true. Building something from scratch is not a good idea at all, unless you are building a core product that’s going to be executing better and quicker than anything else. How many of us can say that in an early stage start up?

My recommendation is definitely find something that’s already out in the market and straight off the shelf. Customise it for your needs, use it even if with some limitations and kick start from there. The world has shifted even in the last few years where you can always find quite robust kit off the shelf. Re-inventing the wheel is not good use of your limited time.

One more thing to point out here are the internal applications.

If you are about to build an internal application, don’t invest time on it, try to find other ready systems that give you an immediate application. Don’t invest time during the early days building an internal system and dashboard, when your focus must be on customer needs and validation.

Is it the right technology stack?

Choosing one technology stack for building the technology is one of the traps Startup CTOs can fall into, especially during early days with limited resources.

Usually a Startup has a core business and/or module that other stuff is built around. The issue I find is that engineers often use the same technology for building the core everywhere else, all over other products and features. This nominated technology stack might be the best for the core, but is it the best for everything else? You need to be certain of that, before jumping into one stack with both feet.

Let’s say you are a data aggregation startup, where your core business is about getting data from different sources and producing insights from this data for your customers. You and your team decide to use NodeJs to aggregate the data and save it to your data lake using nodejs.

Great, good choice!

Now your customers ask you to build a dashboard for them to access your data and ask for too many other features on the dashboard. Now you really need to think twice before proceeding with NodeJs. 

Using NodeJs for a complex dashboard may sound convenient but take care and avoiding reinventing that wheel again. It might be easier and faster using a framework like PHP Laravel and have everything ready with a framework that has most of the built-in features you need to build in your NodeJs dashboard.

Testing

With low budget and fast growth I fell into in the trap of losing the quality of the software. Testing is not only a position, but also a mindset, losing this mindset will bite you in the ass in the near future.

Testing is more important than any other part of your technology stack, this is probably my big learn from these recent experiences. Any other issue in the development process can be solved but a lack of testing and doing it late can come with a very high cost later.

Software Testing is particularly important during the early days, and most other times, because it saves money. It saves your system from malicious attacks that might seriously slow you down and potentially ruin your startup.

Testing guarantees better software quality and more satisfaction. Take care of it, and make it a high priority from day one.

Thank you for reading and I hope some of this resonates. Part 3 will look into leadership and some key learning points from my experiences.

Mostafa Khattab, July 2020