Marketing software SendinBlue was born of Indian and French parents, with multiculturalism at its very roots. It has now become a worldwide online service that enables over 50,000 Small and Medium Businesses to manage their loyalty marketing. Teams span over Asia, Europe and North America, while its technical team of 52 members is split between India and France.
SendinBlue tech team manages a product delivering over 1 billion emails monthly, with everything developed internally for greater reactivity and adaptation. And with no billing restrictions on data for users, they also manage 500,000 separate client databases, with each client free to import potentially thousands of users, track their email and website activities, and use all of the collected data to build Segments and Marketing Automation Workflows.
How is it possible to scale a SaaS B2B product over 4 years with a tech team 8,000 kms apart? “For starters, technical choices make up your foundation to building a product from the ground up” says Mickael Arias, SendinBlue CTO.
“Still, endeavors in designing engineering teams and technology culture are critical to sustaining a product in hyper-growth mode”.
Now with a few years of perspective – after founding Plyce, successfully selling it and joining SendinBlue – Mickael Arias walks us through the crucial decisions and the hard-won lessons that will help startups to weather team turbulences and make the best out of multiculturalism to grow their technology.
Structure your system for the long run
“Everybody starting a company knows about scaling, everybody wishes their company to grow steadily, and not to simply struggle along” says Mickael. “But very few have first-hand scaling experience and have developed an innate understanding of what scaling really means. More often than not, it’s their first experience in starting or growing a company, and the young developers they have recruited do not have any experience about scalability either.”
Mickael points out that everything goes very fast in the early days, as tech teams are trying to release new features for clients. Scalability is not their top priority, and tech teams tend to unconsciously believe that adding machines when you need to is going to be enough. “Which is absolutely not true. When something was not initially designed to be scalable, you’ll indeed add 10 machines as a patch, but a bottleneck will pop up somewhere. So you might be processing 10x more data but your database crashes. Scaling is not about hardware”.
Mickael explains scalability requires a completely different mindset, “it must be integrated to your infrastructure but very few developers have nurtured this mindset. Most teams will probably end up learning scaling by doing. Now while developing, we size up everything we build to hold up to a 10x load.” That being said, here are Mickael’s top 3 technical tips to ensure good bases for scaling your product:
1) Initially choose technologies you can work with over time
“First things first, be mindful when deciding upon the initial technology choices you make”. If you anticipate your database to one day need dozens of servers and sharding, be mindful of the technology you chose to work with. For instance SQL is great database option, but MongoDB allows for sharding more smoothly. In this case, initially choosing MongoDB will save you precious time later on. So when your company is just starting it’s important to properly assess the technologies you’re opting for.
Mickael advises to have a closer look at the most trending stack of the moment, as trending stacks provide two advantages: “For one, if it is celebrated, there is some technical reason to it. Then, if it is celebrated, developers around have looked at it and use it, which means you will be able to find developers willing to work with it on your product.”
2) Build services following the KISS principle
“As your company grows so your product grows in complexity, with that many more features to deal with and that many more developers working on it. You can end up in a nonsensical place in which you’re asking dozens of team members to know and understand the detailed intricacies of a very complex system.”
What happens then is as team members do not fully grasp complex interconnections, they stop modifying anything for fear that it would ripple down somewhere else in your system and crash down another service. So although your product is still young in age, it has already started withering away. “This is why Sendinblue is structured in terms of services. Team members have a deep knowledge of the service they’re working on, and they know how interactions with other services are organized. This enables Sendinblue teams to be more independent as they own a piece of the product. We limit frictions due to relying on other code pieces to make progress.”
3) Organise transmissions between services
To keep things simple Sendinblue services are linear, organized in terms of producers and consumers. They either generate or use information, but no service uses information before copying it for other services. “We avoid this type of convoluted thinking. Each team has a service they are working on that ingest inputs and generates outputs” says Mickael.
Team members thus easily know what goes through their service, and they do not have to think about which technology is used. “We use Go, Nodejs, PHP, MongoDB RabbitMQ, Kafka, among others… It’s the whole beauty of being completely asynchronous, messages are sent everywhere, and something happening somewhere will trigger events elsewhere. For example, the ‘billing’ service that registers a user has no more credit available will trigger messages that other services receive and interpret as ‘block sending action’ or ‘send client notification’ ” explains Mickael.
Mirror your system structure with human organisation
1) Find “product minded” people
Just as your initial technology choices should be able to hold over time, so should your new hires. “We want our engineers to be willing to contribute over time, we want them to be ‘product minded’, whatever their nationality may be. And I feel Indian engineers are becoming more and more product minded. Recently massive startups have been developing over there. Six months after their initial launch, they already deal with 10 millions of clients. So you can find extremely good engineers who are willing to contribute to a product, willing to see the impact of their releases and willing to make it evolve over time.”
As a company grows, Mickael also points out the importance to find people you can trust to take the right decisions: “Doers should also be decision makers, as they have the most complete knowledge about what they are working on”. Mickael sees himself as coach helping people whenever they ask for it. SendinBlue’s focus on recruiting committed employees from different cultural background goes beyond its core tech team and is a company-wide backbone. Forbes explains Sendinblue CEO Armand Thiberge thinking as someone who “has looked to include people from many different cultural backgrounds who inherently understand the need to hustle to get what they want.” Considering the importance Sendinblue puts in recruiting long-term thinking employees, they are currently setting up equity compensation for 100% of their employees.
2) Design teams in pods
Similar to the way you broke down your system in smaller and more manageable services, you want engineers to be allocated to pods. Each pod is responsible for a service, does not exceed 7 members, and has a team leader. The latter is the service project owner and has a global view both of his own service and how it interacts with other pods services. These team leaders roles are extremely important and they need to be selected with extra care. They are able to step back and navigate within the company to find technical solutions or to check change impact on other services. And they obviously need to be technically respected by the rest of the pod members who need to trust them to get the right information.
At Sendinblue, pods are split in two types: backend and frontend types. Frontend types are then organised depending on the product family they carry to, SMS, transactional or automation emailing. “This way scaling up the team can be done quite easily, especially that engineer team growth follow more of a logarithmic trend than a linear one. In the beginning recruitments speed up but the trend slows down later on. Now when load and sales double, there’s no need to double the engineering team. Servers do not follow a linear trendline either, but it’s much more correlated to the number of clients.” Peoples are also encouraged to move from one pod to another and learn new skills. “We value expertise a lot and if you’re willing to learn new skills and experiment new things, you’ll never get bored at SendinBlue”.
3) Promote communication
Finally, organise communication among engineer teams as simply as you structured transmissions between tech services. First make sure that pod types such as frontend and backend are sitting next to each other. “As we started scaling devops were quickly recruited to take care of additional machines, and tasks started to be differentiated between the two job descriptions. Devs were testing their code and pushing it to prod without having a global perspective about the infrastructure. Sometimes they had no clue how many servers were running, or had no idea if the database had shards or not. Devops on the other end were fixing issues from the platform side, with no real feedback loop for developers to fix issues properly. To make things worse, developers were in India and devops in France, 8,000 kms apart, speaking literally two different languages, and with 4.5 hours of time zone difference.
We brought very good developers in France and great devops to the indian team. “You have to really promote interest in and communication with one another. It’s important for us that people are interested in one another, in one another’s culture. We also organise trips between countries, and I divide my time between France and India (I’m currently living in Delhi). Plus there are even funnier topics, we organised hindi classes in France for example: it’s a great success.”
The second step is to push for transparency. “We used to have many conversations held in private Slack channels. So we carefully created public channels and I was the first to ask questions or admit to problems I was a part of in the open. Now people are not fearful anymore to say something they think stupid or having done something wrong.”
“Team members are pushed to ask questions, and when there’s a problem or something is not clear, everybody knows they can ask about it publicly, or come and ask one of the team leads”. They don’t leave problems on the side, waiting for it to grow bigger and bigger. Transparency is also tangible in the way SendinBlue uses agile sprints tools. “Pods have their own sprint board, but every one of our 52 team members have the possibility to look at all tech boards and their somewhat 200-300 stories. They know extremely well what they’re working for and have access to everything.” Thus Mickael concludes “as of today, now that the team is split into pods that can communicate, it could be doubled without major strain.” As for us, we definitely hope to meet with Mickael again, once Sendinblue tech team has doubled, for new tech lessons in multiculturalism!
Let us know about your own story on Twitter @logmatic!
Love this? Share it!