Over the past five years, I’ve undergone a significant professional transformation, founding and growing my own startup. This experience has taught me valuable lessons and presented me with many challenges and opportunities for personal and professional growth. In this blog post, I’ll share my story and the insights I’ve gained along the way, which I hope will be helpful to those who are considering starting their own business or seeking to learn from my experiences.
About Wilab 🔗
Wilab is a great company. We founded it in early 2018, and at the time of writing, the company is developing one of the first NWDAF (Network Data Analytics Function) in the world, a key analytics product for operating 5G networks. We started as 4 guys in a university library and now are a world class team, operating in the Americas and Europe.
I started as the CTO of the company, and was in charge of building a team, and developing a product from scratch. Many challenges arose in the way, but we were successful and delivered to our first customer, America Movil (Claro).
After that first customer, many other contracts started coming, and we even had to increase 4x our team capacity. Our ARR grew 10x for 2 consecutive years and we started facing new challenges, growth challenges. In this certain period of time the company started serving top tier customers such as Cisco and AT&T amongst others.
This fast growth led to new challenges. More people to manage, means that you need more scalable and robust processes in the company, and as the person who was in charge of thinking about scalability and hires, this led me to a new role, COO.
Some of the processes we designed as a team were:
- Hiring
- Firing
- KPI design
- Information structure and security
- Cross company communication
It was a lovely challenge, and many lessons were learnt.
Takeaways 🔗
Async communications as the base 🔗
Every company should try to stick to this principle.
Async communications, mean that a lag in the response between individual contributors in the company might exist. To make it clearer, take email for an example. This is one of the most basic forms of async communication out there, you write an email to your team and you can expect a delay in the response of each contributor. Other common forms are chat apps like Slack or Microsoft Teams, or not so common forms in apps like Trello, Jira or Google Docs, where communications also happen in an asynchronous manner.
This is an amazing concept that enables some cool things to happen company wise. Mostly, that the teams start communicating more, and time management is easier as you eliminate the need for many face to face meetings. Nonetheless when things get spicy a meeting is still a good idea.
Tooling: As little as possible 🔗
Use the right tools for the job, not more, not less. It is ok to spend some money on tools for your company, but there are lots of them out there and it might seem attractive to test them all.
More tools mean more assets that need to be managed and this means less time you spend building a great product. Also, having too many tools doesn’t help when scaling. Should we manage our development issues with Jira or Gitlab? Should we chat on Google Workspace integrated chat or use Slack? Most of the time you will end up with a mix of them, and when you have a mix and many people combined, this equals a mess.
Many of the tools you use daily suffice for the task you need to be done. My advice is that you study each of the documentations and try to use what you have before hiring a new service.
Discuss what to, not how to 🔗
Sometimes, discussions turn to how we are doing things and not to how we are delivering value, in short, what we are doing.
For example, a team of developers may spend hours debating the best way to implement a new feature, when they could be spending that time actually coding the feature. Or, a marketing team may spend weeks creating a detailed marketing plan, when they could be spending that time actually reaching out to potential customers.
It is important to remember that the goal of any discussion should be to deliver value. If a discussion is not focused on delivering value, then it is a waste of time.
This doesn’t mean that how to do things should not be discussed, but in early stage companies it is best to leave that decision to the person responsible for that task. Time is limited and delivering value and results is number one priority.
Open source first 🔗
It’s simple, open source is great, and most of the tooling you need to create a company has an open source alternative. Unless you’re looking for a really specific piece of software, open source might have the best choice.
Reasons:
- Cost savings: Open source software is typically free to use, which can save your company a significant amount of money.
- Flexibility: Open source software is often more flexible than commercial software. This is because it is not locked into a specific vendor or platform. This can give your company more freedom to choose the software that best meets its needs.
- Security: Open source software is often more secure than commercial software. This is because it is constantly being reviewed and updated by a community of developers. This helps to identify and fix security vulnerabilities before they can be exploited by attackers.
- Community support: Open source software has a large and active community of users and developers who are willing to help each other. This can be a valuable resource for your company if you need help with troubleshooting, customization, or development. And of course, support is always a cost to bear in mind, so, more savings.
A great site that has helped me save a lot of time when making a decision is https://alternativeto.net. There you can search for a specific piece of software and its alternatives. Another great list is awesome-selfhosted on Github for a lot of self hosted solutions.
Closing statement 🔗
This post is a really shallow pass over some of the challenges I personally faced when founding and scaling my own company.
Nowadays my journey has diverted to new exciting and more personal projects. But all in all, I think that while I was there we managed to build great teams and products, and now I try to share some of that knowledge for anyone that might find it useful.
In a near future I will try to share more of this experiences and go deeper in some of this topics. But for now, that’s all.