🗃️ The Most Common Cases When You Have to Scale Your Dev Team
⚙️ Development Perspective: Top 4 Points to Remember When Scaling a Product Team
👨💻 Tech Perspective: How to Prepare Your Code for Scaling?
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:
Scaling is a need, not a choice (image by Andrew Millar)
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!
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!
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):
Growing KPIs may be a signal for you to scale (image by Grégoire Vella)
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.
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.
Screenshot from the Voya app
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.
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!
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.
Scaling is also needed when your team is overwhelmed with the number of tasks (image by Burnt Toast Creative)
For this type of companies scaling is mostly needed when:
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.
Civocracy: Our Case Study
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.
Failed deadlines are often a case for scaling, too (image by Svetlana Tokarenko)
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:
Let’s start with the first one!
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:
Set clear aims. It'll help (image by Olivier Lord)
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.
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.
Take care of your team's size (image by Fireart Studio)
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” is a team which can work as an independent unit and deliver almost any functionality from start to finish. Usually, it includes:
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 second approach is more suitable for companies which are concentrated on one specific product.
Skill-based concept is a pretty good approach to splitting the team (image by Aleksandar Savic)
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.
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:
How to Prioritize the Feature Development
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.
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:
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.
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 forget to keep the balance (image by Oleg Levin)
It will let you to fulfill all the tasks and keep the balance between your teams without superfluous expanding.
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.
Encourage the experience exchange between your squads (image by Anton Fritsler (kit8))
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!
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.
Your code should be crystal clear (image by Alex Kunchevsky)
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.
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.
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.
getUserInfo(), getInternetConnectionStatus() and getServerURL()
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.
Ray makeRay(Point initialPoint, double angle)
Ray makeRay(double x, double y, double angle)
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.
Stay consistent and use only one word per concept
Using different names for the same thing in different classes
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?
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.
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:
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!
Was it helpful?
What Stormotion's Project Management Flow Looks Like
How to Develop a Drone Control Application?
Top IoT Security Challenges and How to Deal with Them
Our clients say
They make the whole business work for us, and their improvements are fundamental to our operations. They’re reliable, honest, and willing to try new things that will help us. We appreciate how flexible and easygoing they are.
Pietro Saccomani, Founder