Scaling is one of the key stages in the development of any startup. Most companies manage to start a business, organize the work of a small group of people, and even achieve some kind of result. However, once it comes to expanding the business, things might start going wrong.
One of the focus areas is the scaling of a technical team. We don’t position ourselves as experts in business development, but we know quite well how software development works and how to organize the teamwork so that scaling is successful. This is what we would like to share in this article.
Let’s figure out:
- How to understand that it is time to scale;
- What problems can occur when you scale incorrectly;
- What you should do to make the scaling go smoothly;
- What typical mistakes are made when scaling a technical team.
How do you know when to scale a software development team?
Like any other team, scaling a technical team is directly related to how things are going in your business. Therefore, to decide whether you need to scale, you should understand the as-is state of your company.
If you own a service company:
A service company provides services of software developers and other members of the technical team. The size of your team fully determines the number of developers you can provide to the client and your income accordingly.
This type of company requires scaling when marketing generates demand that exceeds the production capacity. If you understand that a marketing team brings more orders than the existing team can address this is the right time to think about scaling the team.
If you are a product company owner:
A product company focuses on creating a product. If this is the case the size of your team and its technical expertise determine the speed of product development and its unique value proposition compared to the competition.
Such companies might require scaling when the team misses the timelines of another project release or when the product development progresses as expected and more human resources are required to keep on track. Scaling is an option to consider if you face one of the above cases.
Issues resulting from incorrect scaling
Suppose you need additional human resources. Intuitively hiring new team members might seem to be the best solution. Undoubtedly this is the best solution but there is a thing to consider. This step must be thoroughly planned beforehand and aligned with the company’s business strategy. Otherwise having new employees can result in issues as follows:
- Unbalanced team members workload
- Team growth leads to issues with sharing responsibility, team management, and redundant communication
- Minor improvements and bug fixes require much more time
- Project support time increases as the number of projects grow
- Application architecture and code are not adapted for a scaled team
Eventually, unconsidered scaling leads to efficiency drop, costs increase, and consequential business shakeout
Let’s take a closer look at why these problems occur, as well as how to prepare for scaling to avoid them.
Things to be done before scaling from a business standpoint
Elaborate the essentials
Start with focusing on the core business essentials. Without a clear understanding of who you are and where you are going, it is next to impossible to build a successful business. Even if you currently face no problems right now it doesn’t mean they will not appear when scaling the company.
Define your company’s mission, vision, and culture. These are the guidelines and foundation for any company uniting the team on the way to achieving goals. They predetermine company potential and appearance. A solid foundation will help you pass the scaling stage with confidence.
Define your strategy and metrics
Having a mission, vision, and culture statements finalized, determine the company’s development strategy. Scaling should be aligned with the strategy. Having no understanding of the “why” you are scaling in the context of the strategy will lead to wrong decisions and losses in the long run.
To track progress and be on the same page with teammates define the performance metrics for every department.
What we do:
We start by creating a three-year company growth plan. We elaborate and synchronize the working processes of all departments from marketing to production.
Every six months we hold an extended C-level meeting to have a candid discussion of how the growth plan is being implemented and make appropriate adjustments if required.
Assign product owners roles
With the growing number of projects, it is a good idea to extend the project manager’s responsibilities with the product owner’s ones so that this person becomes a kind of “mini-CEO”. These extra responsibilities include market analysis and finding ways to add product value to customers thus leading to business growth.
The product owner will be the link between the global development of the company and product development.
Define the minimum and maximum team size
Scaling leads to changes in the structure of your company. Remember that small teams are much easier to manage.
Determine your team’s minimum and maximum size (in our case it should not exceed 7-10 people). If the team is growing you need to split it up and create a new one. Jeff Bezos’ “rule of two pizzas” is a perfect example of how it should work. It states that the team must be large enough to be fed with two pizzas.
Teams must be independent
Small teams are the foundation of flexible scaling. However, the number of teams should not grow just like that. There is no sense to create a separate team if it is not an independent unit. This will only aggravate communication and management issues.
Ideally, a structured team should be able to deliver project increments being fully independent or as less dependent on other teams as possible. Each team member should be fully committed and responsible for the project outcomes.
Small teams make people focused and committed providing a better vision of how they contribute to the achievement of a common goal.
Optimize your communication channels
The company’s growth and changes made in the organizational structure make it necessary to revise the communication channels. This is especially true now when many employees work remotely.
If you have ever worked with remote employees, you know how easily information can be lost. Redesign the communication channels so that each team member receives the information they need promptly with minimal digital noise.
Automate your business processes
Any manual process is much harder to scale. With the growth of the development team, some tasks become too expensive and at the same time bring minimal effect.
Try to automate your business processes as much as possible. This will allow you to distribute your resources most efficiently. The IT team can benefit from JAMS workload automation software, visit: https://www.jamsscheduler.com/workload-automation/.
Synchronize the work of the teams
Previously we discussed synchronization of departments’ work (business and production). Let’s dig deeper into how product development teams can be synchronized.
When scaling product development teams coordination issues may be faced. For instance, one team has already finished its part of the project while the second team is still in progress. As a result, the entire development process slows down because all the parts are interconnected and you can’t go further without the second part being finished.
To avoid this, scale the team by the amount of work it can perform. Discuss plans with other team leaders and reallocate resources when necessary.
Hire the right people
People are the backbone of any company. All the above-mentioned tips will not have an expected result without the right people.
Understanding of ” the right person” can differ greatly. Firstly, it is determined by the culture of the company that you initiated. Do not underestimate the importance of corporate culture. The scaling stage is when the culture is being challenged greatly.
For most people, it’s difficult to perceive changes. Sudden changes in the atmosphere of the team can adversely affect its effectiveness. Therefore, it is important to consider the human factor when making decisions about scaling.
Hire people who fit into the team and do it iteratively.
If necessary, work with dedicated developers
Due to changes in the company structure and the reallocation of the workload on team members at the scaling stage, it is often necessary to quickly add a developer to a project for a short time.
Dedicated developers are ideal for this purpose. Instead of hiring a full-time developer, you can adjust the workload using much fewer resources if necessary.
Dedicated developers are not an alternative to in-house developers but their complement.
What you should do before scaling from a technical standpoint
Plan product infrastructure and architecture
Sometimes, scaling a team does not lead to proper results due to ill-conceived infrastructure and application architecture.
You start developing new functionality and realize that the infrastructure can’t handle the new load. Or the architecture is designed in such a way that certain parts of the application simply stop functioning.
Before scaling, think in advance about the design of the scaled product. This will also help you determine exactly how much human resources are needed to do this.
Pay close attention to project and product management
With the growing number of teams, the importance of quality project and product management increases. To effectively manage teams, use methods that have practically proven their effectiveness.
In our case it is Kanban. It is ideal for visualizing the development process. Each employee sees what needs to be developed and when. In combination with daily meetings, this allows you to evenly distribute the workload between employees.
One of the key advantages of Kanban is its flexibility. The way it looks depends on the issues benign faced during the project.
Apply coding best practices
Code quality directly affects the performance of an application. Therefore, at the initial stages, it is critical to create a high-quality MVP. In case of poor code quality, the project will turn into a nightmare at the scaling stage.
To avoid problems, MVP should be created by experienced professionals who are well versed in the best practices of the selected programming languages.
Use common tools, libraries, and processes to improve overall performance and reduce product support costs.
Create a dedicated team to address minor improvements
Scaling significantly increases the time spent on minor tweaks. To address this problem a separate team can be formed.
Rotate members of this team every two weeks or once per month by gradually adding and removing developers from other teams. Do not change the entire team at once – the transition should be smooth. This will help the rest of the teams focus on the core tasks.
Use pair programming
To minify the problem of new team members’ adaptation, use pair programming. The essence of this technique is that a more experienced employee works together with a novice during the first weeks. Working together allows a novice to get used to the company’s processes, tools, and team code writing style faster.
Don’t choose the best developers to work with newcomers as they have plenty of core tasks to do. Developers who are a few steps ahead in terms of their knowledge and skills are the best match.
People must be comfortable working together; personal qualities and temper are to be taken into consideration when pairing developers as otherwise the approach with not work.
Although a senior developer could give more knowledge he is too far from a “novice” status and he may miss out on simple but really important communicational moments. On the other hand, a mentor will better acquire his knowledge.
Typical mistakes while scaling software development team
Division of teams by areas of expertise
Dividing teams by expertise areas (front-end, back-end) is considered a bad idea because you don’t have a single team that can fully deliver some functional increment. This creates fragmentation, complicates communication, and makes teams dependent on each other.
Only personal responsibility of team members
There is no problem that each person is responsible for personal tasks and areas of expertise. Problems start when some part of the team has done their works and the second part is still working. Everyone in the team should understand that they are collectively responsible for their part of the product. Therefore, sometimes you should step out of your comfort zone to help the team achieve results on time.
Long sprints
Long sprints break the rhythm of development. The optimal sprint length is two weeks. Short sprints provide quick feedback loops and changes in the project, which is especially important for startups. They also give a sense of gradual, constant progress, which leads to faster results.
Hiring people only for hard skills
Undoubtedly, hard skills are important, especially in technical positions, such as a developer and quality assurance engineer, however, don’t underestimate soft skills.
Flexibility, the ability to work in a team, curiosity, the ability to solve non-standard tasks are also important, especially when working in a startup. When scaling, your teams will constantly change, new people will come, so it is important to select people with good soft skills who can adapt to changing conditions.
Thinking that more developers mean faster development
This mistake often occurs in “non-techies”. Application development is like building a house. Up to a certain point, the increase in the number of developers speeds up development, but it has a limit.
Many models show how to optimally allocate resources during the project. One of them is the optimal scheme for allocating resources during the project following the theory of B. Boyem (*COCOMO).
On our diagram, you can determine the optimal timeline for your project. And also, check how well resources are distributed at each stage of the project.
Diagram
Of course, this is a theory, and each case has its nuances, but it can give an approximate idea of how things are going on the project. For a more detailed analysis of the project, please contact us.
Conclusion
Scaling is a process that is closely related to all the processes happening in the company. It shows how well your company is already formed and reveals problems that are not visible with a small number of employees.
For scaling to go smoothly, you need a solid foundation in the form of a mission, vision, and culture, well-established processes within the company, and a technical base ready for scaling.
We hope that compliance with all of the above principles will allow you to successfully pass through the scaling stage and achieve your goals.
