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?

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.

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:

1. Plan your Backlog in such a way, that it’s always full and each task is assigned to somebody in your team.
2. Pay attention to “single responsibility” - each team should be responsible for a single part of the project, so that there aren’t any misunderstandings.
3. 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.

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.

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.

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.

Stay consistent

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.

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?

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.