CTOs — Scalability is not a side project
I've seen many diverse tech team configurations those last years, and I've also tested some with my teams, but there is a specific one I would like to share with you: "Splitting the scalability issues, and dedicate a team to them"
I'm going to try to walk you around this configuration, by first explaining what kind of issues we are talking about here, then why we may separate developers working on such issues, and finally how to process this team correctly. It is of course still a work in progress in my own mind, so don't hesitate to share your thoughts and ideas with me.
1) What is scalability ?
General Definition
Here's a good definition of scalability: "Scalability is a characteristic of a system, model, or function that describes its capability to cope and perform well under an increased or expanding workload or scope". I am going to focus on operations scalability in this article. (I am not going to talk about tech scalability and how code is important, and there are many books for that : Clean Code, High performance web sites…)
Here are some examples of scalability issues:
- Invoices are not sent automatically
- New employee onboardings are too time consuming
- Your main app does not communicate with your CRM
- Your servers are not supervised
Scalability as a tech (usually) sees it
I've come across many developers who have trouble realizing the importance of making a business scalable, in particular for businesses with hypergrowth goals. Many developers would consider that, for instance, automatically create and send invoices by connecting to the accounting tool API is almost a punishment.
I'm tired of working on side projects, can I work on the main product next sprint ? A developer of my team, some years ago
Side project ? Main product ? What was he talking about ? That's the moment I realized something was off, I was working at Inch (a SaaS platform for property managers) at the time, and we had some issues with invoicing properly and getting our cash as soon as possible. Therefore, the invoice automation was a top priority for us. It would help us:
- save so much money (by saving human time spent on generating invoices manually)
- add 10 to 20% to our monthly revenue by making sure the invoices amounts were correct and synced to our main database (amount = number_of_elements_in_db * price_of_element).
- make sure we are paid on time
- increase the satisfaction level of our clients as they would receive invoices on time
Notice how scalability here goes with quality, we could have made a shortcut and state that automation automatically goes with lower quality (which is sometimes true with conversation robots for instance), but it's often the other way around.
Back to where we were at, I couldn't help but getting angry at my team for not considering it a priority, until I finally understood I was the one sending mixed signals about what is and what is not a priority.
I had built my team in a way that developers working on such issues were isolated. If you experience the same situation, I believe you should consider changing your team structure and making it so you and your team share the same estimation of what's important and what's not.
Scalability as a tech should see it
Scalability is one of the main issue of a start-up, and most definitions of a start-up actually use this word : "a company that is searching for a repeatable and scalable model". Yet so many people still see scalability as something that they will either naturally achieve or that they will end up achieving. I strongly believe it should be one of your concern at any time.
As a tech leader, you should make sure your whole team understands it, and there is no better way to do it than to make sure your development process includes this part of your development.
As a developer, and if the goal of your company is to grow fast, you should understand it may be the most important part of any development in progress. It's the only thing making sure you are part of an adventure that will grow exponentially.
2) Create a scalability squad
Doctolib (Kerala invested in Doctolib from the very beginning of their incredible adventure), that I visited recently, is probably one of the company that has the best processes around scalability, and their “Data and business scale” team is now up to 30 people, which makes it the second development team of the company. I've been impressed to see how they embrace all their scale subjects as a "regular" development issue and I believe that by doing so, they achieved bringing a healthy and exciting environment to developers working on these.
Many tech teams are organised in sub-teams, sometimes called feature teams or squads. Here is an amazing video from Spotify about it : Spotify Engineering Culture.
If you already adopted this framework and depending on your business, you may profit from dedicating one of your squad to scalability. Here's why.
Scalability should not involve (monkey) patching
You need to make sure scalability features are not outside of your tech processes. Tests, code reviews, CI, CD, are even more important when working on these features because they are usually critical to your business. It may seem obvious for some of you, and you might think : "Of course, when connecting to my accounting software, I should make sure the process is applied", but speaking as someone who have made the mistake many times, it's way too easy to end up patching anyway. "I need it quick, because we are losing money, let's just do it quick and dirty and we'll improve it later" (later == never as you'll probably rebuild it from the ground up).
Scalability teams processes are slightly different
Indeed, most of the time, the “clients” are actually you or your colleagues, so the product and feedback processes are more straightforward and somewhat different from other teams. It’s also an issue where you need swiss-army knife developers, able to go from Ruby to Python to Bash to Google scripts to REST to SOAP to XML to every possible technologies you could think of. You do not drive a single compacted product when working on scalability, you drive many completely independant features, and some developers hate that, others love it. Finally, it is a subject where being able to know when to build and when to buy is essential.
Scalability should be empowered
Skipping processes (CI, CD, tests, Q&A) or isolating some coders to work on these issues is also a management issue. No dev would be fulfilled knowing they are not part of the group, and they are just patching for another team to be able to send emails more efficiently.
Make sure your devs understand the responsibility they have been given. Their features are as complex as any other one, they often require a product manager working with them, understanding the daily processes of all the other departments, marketing, sales…
If it’s not enough, take time with your developer to explain the ROI methodology that has been defined for the project.
Last but not least, when it's an internal feature, give them feedback after it has been used, let them talk to the team they have rescued from their painful processes. By doing so, it will ensure the quality of such features and the well-being of your developer are higher.
3) Process a scalability team
The scalability team is central to every other teams.
Align their objectives with other teams
It may not work in every cases, but most of the time, you can align the development team objectives (and sometimes Key results, for those of you using OKRs) with the other team that needs scaling (sales, marketing…). You can actually tell your devs : "Your objective this month is to help the marketing team deliver 3x more leads per week" or "Your objective is to help the sales team generate 2x more revenue by automating the contract production and the email sequences".
Spirit (Scalability is not only DevOps)
Of course, one part of it is DevOps, making sure you use optimal resources for your application, and that your devs are working in a frictionless environment, easy deployment, etc. But it is so much more, and you might need people working full time on the issue way before you think you need it.
It’s difficult to understand how you could gain productivity in your daily tasks if there is no specific people in your organization constantly asking you what could be done more efficiently. You and your team should, at any moment, be focused on bringing value to each other member of the company.
Pragmatism > Scalabilitism
A developer is, by nature 😅, a lazy person. So if they can build a really complicated system to solve every single edge cases of a problem, they will do it, and think : "If I do it now, then I'll never have to deal with it later". I often fall back into this pattern, someone asks me : "What's the shortcut to reply all to an email ?" And I answer : "Have you tried this new email client, it's amazing". In everyday life, it's not a big deal, but when it comes to a scale team, you should also think about feature boundaries at all time. Solve the main cases, just discard most of the edge cases and perform them manually. If you need to produce invoice manually for the 5 remaining percents of your users that are not based in your home country, it may be fine for now, just think about it in a year when your user base will have changed.
Organize meetings focused on scaling
A good way to empower your scalability team is to organize dedicated scale meetings. Your scale team product manager can take 30 minutes with every other teams (sales, marketing, dev, etc.) to discuss about their daily struggles. It gives you a nice overview of scaling priorities in your company.
Do not forget the product team
When you're hyper focused on a project, it is difficult to even see where the issues are in your teams, thus it is important to have a product team in the scalability squad team able to build and challenge a roadmap specific to these issues at all time.
A data team may be necessary
In a scale team, you often have to deal with crunching numbers and understanding their real meaning
Going further
When your business is a seasonal one
Some businesses have a really high activity on a very short period of the year, and the process for such companies is usually different, as almost the whole dev team can become a scale one when it's the off-season. I think it's important for such businesses to immediately organize a team meeting when the high season just finished to focus on identifying the main pain points the company had that time, and how they could be fixed.
Thanks for reading
My stories are mainly written for any tech manager leading a team of 1 (omg, I need to do everything here) to 20 (omg, why do I (think I) still need to do everything here) developers.
About Kerala Ventures
The Kerala team is insanely focused on bringing massive support to its entrepreneurs in tech, operations and hiring (see first20.club). We have a unique know-how in developing startups from scratch to “unicorns” (Lafourchette, Doctolib, see our story)
Kerala Ventures invests from 100k€ to 1.5m€ at Seed stage, or at the creation of startups
