How we are building a first-class Engineering team at Alan

We started Alan with Jean-Charles Samuelian. Both of us had strong engineering backgrounds, but we had never held a position of Software Engineer in the past.

Therefore, to build the best company on solid engineering ground, we needed to surround ourselves with great and senior software engineers, who could take us to the next level in web development and architecture, and bring their unique skills to a complementary team.

We needed “jacks of all trades, masters of a few”.

This meant to create a culture of excellence as a network, not as a hierarchy.

Hierarchies have been engrained in our culture for many thousands of years, and have certain benefits, mostly for those on top of it. However, it doesn’t allow everyone to express themselves and get access to the most information, because people get less connected in the organisation.

So what is the alternative? 🤔

To be able to function without these clear pathways for information, we’ve been needing to create knowledge accessible for everyone, that can be referred to, and with clear owners.

We are organizing ourselves as a network, where the person who knows the most about a project is responsible for it, and gathers information from others, in order to execute himself.

In a small structure, each person is key, and their knowledge is invaluable. However, that exposes us to a big risk: what if they weren’t around tomorrow?

As a network, we are increasing our “Bus Factor”. The Bus Factor is the minimum number of members of the team that would lead Alan to sink if they were simultaneously “hit by a bus”.

By allowing ourselves to share information efficiently and being able to work on many parts of the application, we are making sure that knowledge can’t die.

However, this cannot work with strict equality among all members of the team at all times.

We need ownership. 💪

That’s why we are having rotating project leads among the team. It allows each engineer to:

• Be responsible for a part of the product

• Be the referent and communicate with the rest of the company for that project

• Dispatch informations and tasks to use the rest of the engineering team as resources

Here are some examples of project leads:

• Rob led our product for independents. 🕊

• Antoine was the project lead on our Journal. 🕊

• Daphné was responsible to allow companies to cover their employees’ partners and children. 👪

Scaling 🚀

In the long run, the most important is iteration and adaptability. We know how to learn from our mistakes and iterate, so we’ll be able to adapt this model from 5 engineers to 300 in a few years, in order to collectively build the most efficient model for the size and environment we’ll be in.

This type of model (just like holacracy), is only interesting if it is sustainable as the team grows. Traditional teams grow through the addition of managers in charge of feeding tasks to their team, which brings its whole load of issues with it.

In our model, everyone manages their time and has access to the relevant information for achieving their mission, in an Auftragstaktik (mission command) fashion. As more people join the team, more projects can be tackled in parallel, and more resources are available through free agents.

This model can only work if the team is truly engaged, and incentivized to build the best company. This is why we put aside a significant part of our capital to be shared with the team as BSPCE (French stock-options), and why we are trying to build a great work environment where people are happy to work 🙂

But we will tell you all about that very soon. Stay tuned… 😉

Please feel free to share, comment and contact us to improve our methodology!

Charles Gorintin (CTO & Cofounder @ Alan)