How To Scale Your Product Development Team?
Every successful start-up has the stage of scaling in its’ lifecycle. However, it’s not about adding some random people to your initial squad. If you want to scale your software development team effectively, you should be able to answer the following questions:
- When should I do this?
- Who should I look for?
- How to organize work in different teams?
- Should I somehow prepare the code if I’m adding new developers to an ongoing project?
- How to introduce new hires to my company from the psychological perspective?
- How can I avoid unneeded costs and time-efforts?
Are you ready to answer all these and other questions right away?
If no, this article will provide you with everything you should know on this topic.
If you think that yes, still keep on reading ‘cause we’re going to share some useful hints. And since we’re a start-up ourselves, we know what we’re talking about!
But before we move on to finding an effective way to scale a development team, let’s figure out when you may need this. Let’s get it started!
🗃️ The Most Common Cases When You Have to Scale Your Dev Team
There are many situations when scaling a product team is a necessary step to take. Is your issue on this list? Following cases by the Stormotion team will help you figure it out!
Case # 1: Your Startup Is Growing
This case is the most typical one for companies which develop their own product. Think of Snapchat or Waze, for example. Scaling in this type of companies often happens naturally and usually goes by the following scheme (very simplified):
- Your Start-Up grows, its MAU/DAU and other KPIs are showing good numbers.
- As the audience and the client base grows, the company has to constantly improve its product and work on new functionality even faster to stay competitive and don’t run out of funding.
- The scope of the work grows together with the complexity of the product. The initial team doesn’t have enough time or expertise to take care of all the tasks.
- That’s when scaling a product team takes place. The needed experts are invited to the company to fill the gaps and support a required development pace.
Since everything goes naturally, it’s usually clear when and who you should look for. On the other hand, if you miss the right moment to scale your software development team, your competitors may be faster than you and occupy your niche by offering a more elaborate product to your end users.
Case # 2: You’re Expanding Horizontally
Another typical situation, when scaling is needed, is the shift from a single product to a platform approach. Think of Facebook. While having the “main” Facebook application, they introduced few other ones, for example, Messenger, Ads Manager, Pages Manager, Lite versions of both Facebook and Messenger applications etc.
Despite we usually perceive all these apps like parts of a single product, they all are developed and supported by different teams. It makes Facebook a vivid example of a platform approach.
This approach can be applied to any industry. Fresh example from our working practice: Voya.AI (we cooperate with them to build an Android app) is developing a product to make business travelling easier for their clients. At some point they decided, that a Web-App isn’t enough and contacted us to expand to Android.
So if you’re also thinking about adopting the same platform approach, scaling a product team is just a matter of time. As you start new projects, you will need more developers to work on them and, thus, will have to increase the number of working teams.
Case # 3: Strong Marketing but Poor Technical Product
Imbalanced development may also be a sign that you have to invite new specialists to your company.
The company may have a brilliant marketing campaign and attract lots of users but if the application itself sucks, isn’t standing out and has many glitches, people will drop it after the first use. Not a good scenario, huh?
So if you’re facing similar challenges, wonder “should I scale our app development teams?”. Expanding your dev squad is often necessary in such a situation!
Case # 4: Can’t Handle All Projects
Let’s switch to another situation. Except for companies that are constantly developing their single product or platform, there are many others which simultaneously work on different projects.
For this type of companies scaling is mostly needed when:
- There isn’t enough employees to handle all the projects.
- The number of simultaneous projects in the pipeline from clients/investors is growing.
- The current team lacks specific skills or expertise.
Yet, if you need a new employee only for a short-term project, try to look for a Digital Agency instead.
The bright example is our cooperation with Civocracy whom we delivered them an App-Prototype using React Native. They had no time and point to hire somebody in-house since it was a short-term project with a strict deadline.
Case # 5: Constantly Failed Deadlines
Finally, you may need to horizontally scale your app development teams if they’re permanently breaking your deadlines and you get stress from your investors or clients.
As always, each case should be treated individually. Maybe the problem is in the improper organization or poor project management. However, as the experience of many startups shows, there just may be not enough manpower to deal with all tasks from your Jira Backlog.
Also, by creating more teams, you will be able to re-assign the tasks between them according to their experience and expertise.
So these were top 5 cases when expanding your team is reasonable. But how to scale your product team properly and correctly?
We’ll answer this question from 2 perspectives:
- development (or management);
Let’s start with the first one!
⚙️ Development Perspective: Top 4 Points to Remember When Scaling a Product Team
# 1: Clearly Define What Goals You Want to Achieve
This is the first step you should take before scaling.
First and foremost, answer one question: what, in your opinion, do you expect to achieve by hiring new employees? There are many possible sub-questions that may occur in the process of thinking:
- Is it about increasing development speed?
- Do you need to improve some specific side (for example, marketing or QA)?
- Do you need to work on more projects at the same time?
- Are you going to extend your product to another platform?
- What specific issue do you expect to solve by hiring new team members?
- Or maybe you want to minimize risks when one of the developers leaves?
At the end of the day, you will likely have an explicit understanding of what and who you’re looking for. Your answers will help you create a “portrait” of a missing employee. Having such a list of requirements is a part of an effective way to scale a development team.
# 2: Size Matters
Scaling often leads to changes in your company’s structure.
The optimal size of a dev team is up to 7-10 people and not more. I bet you’ve heard about Jeff Bezos’ (who is the CEO of Amazon) “two pizza rule”. It says that you should be able to feed your whole team with just 2 pizzas. Otherwise, the group is too big and you should split it.
Let’s review the 2 most common approaches to splitting your employees into teams. When scaling you will have to choose one for your company.
The “whole team” concept
The “whole team” is a team which can work as an independent unit and deliver almost any functionality from start to finish. Usually, it includes:
- 1 UX/UI Designer.
- 1 Project Manager.
- 1-2 Front-End or Mobile Developers.
- 1-2 Back-End Developers (if needed).
- 1 QA Expert.
- Don’t forget about a Product Manager as well, if you’re developing your own product.
It’s also okay to combine roles if this doesn’t harm the result.
This is especially useful when you’re cooperating with several external clients who requested to craft an app for their needs. Therefore each team can concentrate on a separate project and work on it independently from your other teams.
The “skill-based split” concept
The second approach is more suitable for companies which are concentrated on one specific product.
In this case, you will group your employees according to their role - developers should go together with developers, designers with designers etc.
The main advantage of this approach is the possibility for your employees to exchange experience, combine efforts to achieve better results in shorter time and replace each other, if needed.
# 3: Pay Attention to the Project (and Product) Management
As you will scale your app development teams you will have to pay even more attention to project and product management. Here are some key points to remember:
- Plan your Backlog in such a way, that it’s always full and each task is assigned to somebody in your team.
- Pay attention to “single responsibility” - each team should be responsible for a single part of the project, so that there aren’t any misunderstandings.
- Use effective communication and reporting tools - Jira, Slack, Trello etc.
Tip: Your Product Manager should be fluent in tech terms. It’s difficult to improve the product without deep technical understanding. Therefore, he should understand how things work and don’t get lost in the details.
# 4: Keep Old and New Teams Balanced and Engaged
When expanding your start-up, you should be sure that everyone is on the same page. How to achieve this? There are few tips for you:
- Don’t leave newcomers alone.
Every new team member should have a tutor. This should be a person from the same team that can provide guidance, instructions and any other kind of help. By doing so, you will be able to introduce the new employee into your working process and company’s culture more smoothly.
- Keep the balance.
When sticking to the "whole team" approach, keep the ratios to let all the squads stay independent.
Yet, you may change the ratios depending on the project specifications and your needs. For example, you may have 1 Designer and 1 PM for several teams if this is acceptable.
- Don’t neglect outsourcing services of Digital Agencies.
It will let you to fulfill all the tasks and keep the balance between your teams without superfluous expanding.
- Encourage the dialog.
Hold weekly stand-ups where different teams can share with each other what they’ve been doing during the previous week. This will help all the squads to be on the same page and exchange their experience.
These were key development/management tips on how to scale your product team. However, this is only one side of this process. Now let’s review it from the tech perspective!
👨💻 Tech Perspective: How to Prepare Your Code for Scaling?
Code like you’re surrounded by idiots
This may sound like a joke but, actually, this rule should become your key principle during coding. And especially if you’re dealing with shared codebases!
Sometimes you will have to add new developers to already existing projects. And every developer knows that working with someone else’s code may be a quite tough task.
However, you can minimize possible risks by writing clean code. This means that any other developer will be able to read, understand and continue to work with it without facing any serious troubles.
Bottom line: the more simple and plain your code is, the better you’re prepared to scale your software development team.
Use descriptive names
By using intention-revealing names you can keep the logic of your application clear. It may seem that giving names like dxy can save you a lot of time but it means nothing to anyone except you. On the other hand, the name distanceBetweenXY instead of dxy is far more recognizable and distinctly clarifies your intentions.
|✅ Good||❌ Bad|
Assign only one purpose to a function
Your code should be broken down into atomic pieces. Especially if you’re working with a shared codebase. To achieve this, simplify your code by replacing one complex calculation with several more particular functions.
The more specific you are, the easier it is to understand your code.
|✅ Good||❌ Bad|
|GetCreditReports(), ApplyCreditHistoryAge() and FilterOutstandingMarks()||GetCreditScore()|
Cut the arguments
Having more than three arguments are often a bad idea. To keep your code clean and your functions easy understandable try to stick with no more than 2 arguments.
If it seems that you can’t avoid using less than 3 arguments, some of them can probably be wrapped into a separate class.
|✅ Good||❌ Bad|
|Circle makeCircle(Point center, double radius)||Circle makeCircle(double x, double y, double radius)|
This rule is simple as that: pick only one word to name specific concept. For instance, retrieve, get and fetch may be interchangeable but if you use all of them to name equivalent methods of different classes you just create more room for confusion and misinterpretation.
Therefore, pick the most suitable names and don’t mix them up.
|✅ Good||❌ Bad|
|Stay consistent and use only one word per concept||Using different names for the same thing in different classes|
Try not to use output arguments
The use of specific object’s methods clarifies your intentions and strictly defines the object you’re referring to. General methods usually leave more room for misunderstanding which you’re trying to avoid, aren’t you?
|✅ Good||❌ Bad|
Design for extension via new code
From the very first minute you should design your system in a way that allows accomplishing points of extension and changes via new implementations of well-defined abstractions.
By using this approach you can easily improve the system without being afraid to break an abstraction and cause unexpected behavior.
|✅ Good||❌ Bad|
|Implement extensions via new code||Modify the abstraction and provoke unexpected behavior|
Stick to these tech tips by the Stormotion squad which we use to scale our app development teams. They’ll help to prepare your share codebase for use by other developers.
So this was the ultimate guide on how to scale your product team by the Stormotion squad.
We gathered all our knowledge and expertise and tried to look at this process from 2 totally different perspectives:
- development (or management);
- technical (or coding).
We truly hope that you’ll use our tips to scale your software development team and they’ll help you a lot. Want to share your own hints? Drop us a line on Twitter!