Career Hacking Event #2: How to Scale a Tech Team?

Increasing the size of teams can be tricky for an organization. A changing roadmap and pressure from external stakeholders are just a few of the constraints managers can face. It also involves hiring lots of recruits while making sure you don’t lose any current team members as well as the momentum achieved up to that point. This raises many questions: How do you preserve the essence of the original team, its culture, its communication, its efficiency and wellbeing while onboarding a new range of people? With 66% of developers having to deal with the symptoms of burnout, finding a stress-free way through the issues associated with scaling teams might help avert this happening in some cases.

Therefore, on November 13, 2019, Welcome to the Jungle hosted a Behind the Code Career Hacking event in Paris and interviewed the following two professionals from the industry to find out more about the approach their organizations take:

• Frédéric Rivain, CTO at Dashlane, a company providing solutions to secure passwords, payment information and other personal data. It is a leader in digital identity management and privacy and has more than 13m users worldwide, across 180 countries. The company is rapidly expanding and has seen an increase in size of 75% in 2019; its engineering team currently numbers 80 people, more than 50 of whom are developers.
• Fred de Villamil, CTO of the Marseille-based startup MYLI, and former VP Engineering at Aircall and Ledger. MYLI aims to help merchants improve their customer relationship via a next-generation platform for consumer engagement and feedback management. The company’s objective is to double the current workforce over the next 6 months, currently only in full remote positions and GMT +2/-2.

Here’s a breakdown of the advice they shared with the event’s attendees.

Assign transversal management

When your organization has only up to 10 employees, it is most common to go with the flow when it comes to management. It’s a good idea to set some guidelines and build a framework using the Agile approach and sprints, and to start implementing continuous integration/continuous delivery (CI/CD) where possible to ensure good people management. As the team increases to 20, or from 20 to 30, you can reapply this model by simply duplicating the number of teams, but when the team starts exceeding 30 people, it’s time for more serious structuring. The learning phase is over and you now need to implement strong technical, cultural, and organizational fundamentals.

Integrating transversal management will ease your journey. “[Management is usually] done by lead techs at first, but at a certain point, it becomes impossible for them to keep managing people efficiently while fulfilling their technical leadership role,” de Villamil explained. Consequently, a strong need arises to recruit people specifically for a management role and to start scaling while avoiding adding extra layers of management. “If I have to fulfill the role of CTO and manage 7 to 8 people in direct report at the same time, it quickly becomes problematic. A full-time manager, on the other hand, can follow the advancement of the team, and of the roadmap.”

At Dashlane, they have chosen to split the technical leadership from the management in terms of focus. Depending on the experience of the manager, the company either has a hands-on manager who contributes to the code and has a maximum of 5 direct reports, or a senior manager who can deal with up to 10 reports. “When we scale following this kind of rule, it forces us to recruit managers or to train our current employees and make them evolve in a managerial and/or technical role,” said Rivain.

Assess the needs and organize flexible feature teams accordingly

There is no single solution when it comes to fragmenting your tech team. What matters most is that you always remain able to adjust to the circumstances and the size of your growing team. Dashlane started with 25 people in the developers team, which comprised both an iOS and Android team. As the company began to grow, it started facing synchronisation problems between the teams and so morphed them into more flexible feature teams. Rivain revealed the company’s business scope was too wide and needed to be shrunk: “Our first iteration of a feature team was [organized according to] business scope, for example converting a free user into a premium paying user. The scope was [previously] a bit too large, so we reduced the scope of each feature team to be focused on one single mission.” This has become a common practice, with the temporary mission teams always being dissolved afterwards and then reassembled when new projects arise.

Choosing between product and mission teams is not the main issue and will continue to evolve over time. MYLI manages 6 different products, and so, for now, it is more relevant for the company to have product teams only, but it intends to create feature teams within these product teams to focus on specific matters (such as conversion and use rate) when the company has grown. Teams fluctuate, but it’s important to bear in mind that they must remain autonomous if the project is to be successful. The moment some teams become dependent on the delivery of other teams, problems occur. You will need to reevaluate the feature teams’ configuration and adjust as soon as possible in order to keep moving forward.

The way your product is conceived will obviously have a strong impact on the potential dependencies between the teams working on it. Therefore, to preserve their autonomy, you should always encourage loosely coupled architecture that allows teams to work independently, deploy independently, and fail and scale independently. Remember Conway’s law: Organizations design systems that reflect their own communication structure. Whenever a team is dependent on another one, their distribution as well as the technical architecture must be reevaluated.

Keep your finger on the pulse of your team

Surveys are a first approach to seeing how your team is functioning and feeling, but nothing can surpass one-to-one contact. Anonymous feedback, while useful for revealing an overview of the company’s climate, can be incomplete and vague. Talking directly with your teams will provide a clear and accurate picture of the employees’ situation and wellbeing. “When I was a systems engineer, we had a team doing a lot of night shifts. It was crucial to regularly check their mood and their rest time after weeks of night shifts, and to avoid allowing [their hours] to stack up. Otherwise you get exhausted, unmotivated people, which soon affects the team [as a whole],” said de Villamil.

People tend to feel more comfortable about opening up in informal situations. Rivain likes to have lunch regularly with his team, while de Villamil enjoys chatting at the coffee machine. Ask your workers how often they would like to hold one-to-ones. Once every two weeks should be the minimum, especially during an active growth phase, but it can be increased, depending on your teams’ wishes and need to discuss. One-to-one contact is important for assessing your teams’ “health” but especially to make sure that your most long-standing employees always feel included and remain comfortable in a fast-changing team. As the company grows, you do not want to lose precious human assets in the process, so keep communicating and making sure everyone is adjusting well to their new work environment and colleagues.

Metrics and tools are a bonus and serve more for operational purposes, rather than reporting. “In several work-experience roles I was asked to submit reports on engineering metrics, the volume of bugs, [and so on,] but no one really reads these reports. What matters in the end is how well your business is going and if your users are happy,” advised Rivain.

Be active on growth

Changes and challenges should be anticipated to the greatest extent possible. Using one-to-ones, feedback, and general communication throughout the company, organizations should always be looking to identify the next changes (in engineering, business coordination, and so on), the patterns for improvement, and the atmosphere in the workplace. “When your velocity crashes and your [staff] turnover rate is exploding, you have failed somewhere. This is why proactivity and good listening skills are crucial,” explained de Villamil. “Keep track of any decrease in velocity—for it to happen in one sprint [is acceptable, but if it happens] two sprints in a row, there’s a problem. Either the team is exhausted or the sprint was not correctly set.” However, Rivain made a clarification: “I have a more nuanced view regarding [staff] turnover. In my opinion, it is problematic when correlated to pain points. We usually notice cycles of 3 years for our people. At certain phases of a company’s lifespan, people tend to leave, and it doesn’t always mean that there are problems within the company. You just need to check the motive for their departure and the turnover [rate].”

The best way to understand what’s going on is to talk to people, as they won’t always come to you. For good communication when teams grow, there needs to be trust between developers and engineering managers, and in turn, engineering managers need to be able to trust and open up to their CTO.

Get the right support

Dashlane had quality assurance (QA) quite early on, which evolved from manual QA testing to automation. Therefore, the company provided a lot of in-house training for the relevant roles. At MYLI, the opposite pattern was followed: They started automating and then hired a QA before allocating one QA per team, as well as a lead QA to be in charge of coordinating the teams.

Support roles are essential to scaling and can be filled either by training your employees to be able to perform new technical/managerial functions, or by hiring experts. Dashlane relies on many support positions, from IT people to in-house tech recruiters, and is planning to hire a release engineer soon to help teams with CI/CD. The company also has dedicated scrum masters and product managers, with each working with 2-3 teams.

Customer support is also important to growth and making sure the developers are not affected by any production problems. A full support team should be built and receive training on the products, including any recurring problems and useful tools. During the growth phase, in-house “tools” like this are often overlooked, despite them being able to help with saving time and fixing pain points. As always, communication is key to saving time and avoiding dependencies, as Rivain explained: “We have created a back office at Dashlane, which allows the support team to be as autonomous as possible during users’ day-to-day actions. To act as an interface between the developer and support teams, a rotating team captain is elected each week who ensures communication is maintained.”

Last but not least, ensure you have a solid security team with an IT department who knows the best practices for segmenting access to the documents. International standards remain a trustworthy source for helpful advice and their scope should be wide enough that they can be adapted to your company.

Don’t panic when velocity fluctuates

If the size of the team doubles overnight, velocity will inevitably be lost. As pointed out by Rivain, you need to keep in mind which phase you’re in. Whenever there’s active recruitment in the company, it will have an impact on delivery of a product, but this is only a transition phase. Then there will be a need for onboarding. Therefore, it is important to accept that scaling involves fluctuations and will then plateau. Just as during war, you must then divide to conquer: Everyone needs to be onboarded and assigned a role toward achieving growth. If you become anxious about losing too much velocity in the process, you could follow Aircall’s example and carry out pair reviews, always making sure that 2 people have the same code knowledge. This is especially useful in small growing teams.

Set a clear career path

Dashlane has created many iterations of the career path its employees can expect to follow within the company since its first, quite basic one. Nowadays it’s up to its technical leads and managers to make it evolve according to their needs and aspirations. At Aircall, de Villamil had adapted the career path from that used at CircleCI, applying it to the reality of Aircall’s business. There is no rigid framework to follow, but there are usually 3 levels of engineers, followed by 2 levels of senior engineers, before the management and/or technical-lead level. Whether your company’s career path is going to be flexible or not, it remains important to have an official one to refer to. Indeed, it allows new recruits to more clearly envision what a career with you has to offer them, even though the path may change, depending on their approach and the skills they develop while working with you.

Long story short

• Involve everyone in the scaling process, especially the older members of your team—in other words, those who may start feeling lost in a new configuration.
• Communicate as much and as often as possible about where you, as a CTO, come from, which goals you want to achieve, how you plan to achieve them, and any potential changes.
• Scale in a healthy way that matches the company’s vision and culture and preserves the wellbeing of your team.

Check out the full video of the event (in French):

This article is part of Behind the Code, the media for developers, by developers. Discover more articles and videos by visiting Behind the Code!

Want to contribute? Get published!

Follow us on Twitter to stay tuned!

Illustrations by WTTJ