• Tweet

• Tweet

Startups usually have a big growth after receiving investments. Many people think that the challenge is to find the candidates in a city as competitive as London, but that’s the easy part. I will share what I learned being part of a team that multiplied its size in just a few months

Before we start, let’s take a look to these two pictures to understand better the challenges. Believe it or not, it is the same team with just a few months difference.

As you may imagine, the communication and the processes are not the same when you have a small team than when it grows, and it is needed to adapt them quickly to keep delivering what customers need.

Set expectations to the business

They will think that increasing x times the team will increase x times the performance, but this is not going to happen. It takes time to train the new members and the star developers that used to do most of the work won’t have much time to write code because they will be busy doing interviews and onboarding the new ones. Expect a decrease of the performance at the beginning that will pay off in the long term, so don’t do it just before a big project or onboarding a big customer, it has to start much earlier.

Share responsibilities like code reviews and interviews

Their number will grow dramatically and the tech leads won’t be able to do all of them, so include the seniors in the interviews and code reviews, being accompanied by tech leads at the beginning so they learn how to do it.  Also adding the new members to the code reviews will allow them to learn from the code that others write and understand better the coding standards and how the projects work.

Don’t lower the bar

You may get pressure from the business to hire faster but it is better to push back and ensure that you only hire the right people that are as good or better than the current members of the team. And don’t check only their skills, focus on their attitude and how they will fit in the team.

Think in the long term

if you hire people when you have big projects and tight deadlines, try not to make them feel the pressure or work crazy hours, as they may burn out and resign after a few weeks. And the last thing that you want is to see people coming and leaving as it is quite bad for the morale of the team, as they will think that they are in an unstable company and consider leaving too.

Focus on the onboarding of the new members

There is no point on hiring them and not telling what to do or how to do it. Consider creating guides so they can set up the environment and learn about the projects on their own. It may take some time to prepare them, but it is better than explaining the same multiple times. Also start giving them small pieces like bug fixes so they get feedback quickly. This way they will improve, their self confidence will increase and they will feel part of the team.

Don’t forget those who have been longer at the company

You may think that they can work on their own and it is not needed to pay attention to them. However they may think that the company has changed and that it is not the place that it used to be. They may also feel alone because they won’t be able to talk as much as before with the initial members and it will take time until they know the new ones. Chat regularly with them and ask how are they handling the changes and if they need any help.

Train those who you promote

They may be great developers and have social and leadership skills, but they still have a lot to learn about how to cope with stress, how to push back when customers or other teams ask for features that shouldn’t be implemented, how to prepare estimates, …

Reinforce the team values and culture

This way the new members will get used to them quickly and will adapt better to the team. If the company hasn’t defined yet the values, consider those based in team work, love to learn, … as they are the ones that will help the team overcome together all the challenges.

 Break the team into smaller ones

There will be many projects going on at the same time and people should focus on each one instead of having to be context switching all the time. You will have to improve the communication so people know what others are doing and how it may affect them. This way they won’t reinvent the wheel and will be aware of breaking changes. What many companies do is to organise a weekly scrum of scrums in which the team leads meet and share what they are doing, and organise regular meetings by role like testing or frontend catch ups. You could also rotate people through the teams every few months so they disseminate what they have learnt and they don’t get bored of doing always the same.

Split the code base into smaller pieces so you can scale the team

Everything gets complicated when the team grows and everyone is working on a big monolith. A broken build affects many people, it gets difficult to add more tests, people won’t be confident about doing changes because they won’t know the impact in other areas, … There are different approaches to do this depending on what the teams need such as creating modules or moving to microservices. I will publish soon a post about it.

Ownership

In a small team everyone knows about everything, but when it grows each team will be specialised in smaller parts. Assign owners to each project that will be responsible of their deployment and how they evolve. It is also good to create a page where the new members know who to ask about them as it is frustrating to need help and not knowing who to ask.

Promote a learning culture

You could organise drop in sessions where people share what they are learning with others, promote going to meetups, post articles, start a technical blog where you share what the team is learning, … I shared in this post some ways to help your team improve their skills.

Organise events so people know each other

People cooperate better when they trust others and this is built day to day every time they interact with each other, not just working together but also having casual chats. A way to promote this is to organise events where they meet without the pressure of implementing a task. You could organise team lunches or breakfasts, go out for a drink together after work…

Summary

There are many challenges but it is doable and it is quite exciting to be part of a team growing this fast. I hope these steps help you if have to do the same transition.

Have you experienced a similar growth or are you about to do it? If so I would love to read your opinions and concerns in the comments.