CTO@Startup - How to take Design Decisions (Part 1)

Lesson #1: Do only what the team is already able to do or you will get in trouble.

A CTO is responsible of every important decision taken about the IT in a company. If the CTO works in a startup or in a little company, for example with less than 10 employees, he should also take decisions in a lower level, for example how to manage some kind of data or what algorithm must be used to meet a requirement. These kind of decisions are usually decided by a Software Engineer, but in a context in which there are few resources, the CTO have to fill many roles.

Rule #1: Do only what the team is already able to do or you will get in trouble.

When I started to work on a proprietary CMS in 2021, I wrote the technical requirements in a document, and it turned out that we had to use some kind of non structured data because of the nature of them.

When it came to choose the database, it comes naturally to think about a NoSQL database, for example MongoDB. In those days, there was a microservices trend and it seems everything had to be done with a microservice architecture.

So the idea was to make a microservice to manage users in a SQL database, because the users data were structured, and a microservice to handle the non structured data using a NoSQL database. We started a proof of concept of the product, using in the first microservice Laravel and MySQL, and in the second NodeJS and MongoDB.

After few weeks we encountered a problem: we noticed that we were not confident in the microservice with NodeJS and MongoDB because the team didn’t had enough experience to deal with it. In fact, the development of the users microservice was really fast, with a complete test suite, but the second microservice was lacking of some basics stuff such as authorization controls. On this microservice we had also a series of CRUD that we developed in some weeks, but that in a confident technology we would have done in few days.

You can think that the speed gap could be filled after an initial time, but working in a startup implies multiple switch context and the time is a crucial aspect, even more if you are building the main product.

At the end, we threw out the work of the second microservice and we started to use the technologies we were confident with. We were much faster and the product is now rich of good features, secure by design and the stakeholders are happy.

There are some exceptions to this rule: for example, if it is critical to use some kind of technology due to some requirements (for example performances or security): in this case, you should be able to learn how to use this technology and implement it. One example could be in the choice of the database, but this is valid also for the entire tech stack, including other IT things like infrastructure monitoring and server management.

Rule #2: Reinvent wheel only if extremely necessary.

When working on a product, you could think it is unique and that doesn’t exists packages or common solutions to solve your problems.

This could be true in some cases, for example when you are working with an emerging technology, but the reality is that a vast amount of problems has been already solved. I really like to write algorithms to manage data structures, or to implement a fascinating requirement, but I have to admit that should not be the rule. Indeed, this should be the exception.

Before diving in an example, I want to be clear: a good CTO/Software Engineer/Developer must be able to write algorithms by scratch, but when working in a company, you probably will not have the time to re-implement an array map function. And, probably, if you re-implement the array map function, it will be slower than the corresponding function provided by the language.

In the company I work, we are official registrar for the .it domains, so we need to use a protocol called EPP following the authority guidelines. In the first version of the product, we coded the entire implementation from the scratch, using only the basics XML functions provided by the language.

This version was builded before the 2015, and it required a very big effort to make it working and to maintain it over time. This was because the guidelines changes every 4/5 years but the legacy software was using only the primitive XML functions, instead of known packages that handles well the communication between two services with XML.

After this mistake (it’s really normal to do a mistake, don’t blame yourself!), we understood that reinventing the wheel isn’t the right choice in many cases, because you won’t notice in the short term, but instead you will notice when rules changes or when you have to fix a bug or in generally maintain it.

So we used an awesome package called Laravel Saloon that manages connectors (i.e. third party services) and how to handle the XML requests in a really easy and efficient manner. This implementation made us faster in implementing the protocol and now the maintainance issue are less likely to happen.

In another case, I had to build an integration with an email marketing platform called ActiveCampaign. Despite its popularity, I haven’t found an implementation that suits our needs, because we had to manage the customers and their tags using a sync mechanism and following certain conditions decided by the business. So I took the standard ActiveCampaign package and I built the integration from scratch, changing the way the package was sending and receiving data. At the end of the work, I noticed that I had rebuilt the entire package from scratch.
It is ok to reinvent the wheel in these situations, but these are constrained for example by an ad hoc product requirement that probably was never encountered before.

Rule #3: Create a standard approach for new requirements.

As the Manifesto Agile says, it is important to respond to changes. During the lifecycle of a product, many needs change because of the users feedback, new regulatory laws and business needs.

How to deal with continuous changes? One approach could be to trust the stakeholders idea and implement what they want. But this often brings to misunderstandings and lack of technical analysis.

It is important for a CTO to define an approach in which it’s defined how new requirements must be implemented into the product. I’m talking about establishing a pipeline in which the input is the stakeholder requirements, and the output is the implementation or the reject. Clearly, to reject a requirement, there must be an agreement between IT and stakeholders.

When working for a new enterprise customer, he asked us to implement a Single Sign On mechanism to allow their users to access using their employees credentials. This was not in our boundaries, because we already had an authentication system which is compliant to every enterprise we worked with.