7 Steps to Scaling Software Teams Faster [with Startup Case Studies]
There comes a time in the development of a startup when the need for scaling becomes obvious. Here is where things get tricky. Many companies fail when it comes to growing their business.
When it comes to needing more human resources, usually people try to hire intuitively. While this may work, you can’t succeed without some solid planning and alignment with your business strategy.
We have gathered a few useful steps to follow to make make the scaling go smoothly and achieve faster software development. To illustrate better the challenge of scaling software teams, we are going to dive into some successful start-up case studies.
Let us start with a review of high-growth engineering leaders’ challenges.
- What can go wrong when you scale a team incorrectly?
- 7 Steps to Scaling Software Teams Faster
- Startup Case Studies
What can go wrong when you scale a team incorrectly?
Assume you need to hire extra personnel. Recruiting additional team members intuitively may appear to be the greatest option. While this is undoubtedly the greatest solution, there is one point to ponder. This stage must be carefully prepared in advance and must be consistent with the business strategy of the organization.
Planning and project management
As a team grows, planning and team management become more difficult. Unplanned scaling eventually results in decreased efficiency, increased costs, and a subsequent business reversal.
Architecture and codebase not prepared for scaling
You need first address your software platform scalability before you start scaling software teams. World-class engineering organization needs to stand on solid architecture and high-quality code foundations.
Keeping up with productivity and quality
As the software team expands, little challenges with basic processes and management can create bottlenecks, decreased efficiency, increased, and a subsequent business pullback.
7 Steps to Scaling Software Teams Faster
Build strong foundations before you start scaling. These are the mission, vision, strategy, values, team culture, and success measures. Much of that depends on the size of the company, the number of projects, and other factors.
Here are some of our suggestions on how to scale your team faster.
1. Define your goals and objectives
Before starting the scaling process it’s crucial to define your goals and objectives. Do you have in mind some expansion into new territories? Does that come with a need for new leadership and guidance? Maybe your developers need a fresh perspective to boost their ideas. No matter what combination of reasons applies to you, in the end you should have a clear objective for scaling.
It’s easy to get carried away when hiring new people but you need a solid answer for why you’re doing it. Think about your staff. Be transparent with them when you’re making major changes. Explain how these actions will steer the company towards accomplishing its goals and vision.
No matter your project your team should seek continuous improvement. Here is where establishing goals come in. By doing this you create an efficient workflow and you can answer questions like: Should the designers work ahead of software developers to keep up with the release cadence? Or is there a need for more frequent check-ins from development leads?
2. Prepare roadmap
Anyone who’s worked in software development can agree that documentation is essential for brainstorming and finding and implementing workflow improvement ideas.
You can find more on documenting projects in our article Step-by-Step Software Projects Outsourcing Guide. On top of the standard documentation, we also recommend to:
- Turn milestones into priorities Milestones need to be planned strategically to ensure that project teams will meet deadlines.
- Rely on visuals Rather than talking about something you should show it. Visualizations and pictures are a more efficient way of explaining your goals and needs.
- Put some time aside for reviews and eventual changes Even with an SOW in use, there’s just so much that planning can account for. When planning your project schedule and deliverable timeline you need to add space in it for reviews, pivots, or changes in priorities.
3. Put the right technology and processes in place
Technology can make your life easier when it comes to managing and communicating with disparate teams. When taking an agile approach you should prioritize keeping in touch with tools like video conferencing and project management software. Your team’s focus should be on high-impact work. For this reason, you should eliminate mundane processes and automate what can be automated.
When it comes to outsourcing software development, your partners should be the ones to offer your developers the tools they need. But at the same time, you should ensure you’re in-house teams have all the tools they need.
4. Have a process improvement plan
Once the roles have been assigned and understood you can start planning for how your development team will work. If you’re an agile company this means you have to build a cadence of ceremonies that will include sprint planning, sprint review, backlog grooming, sprint retrospectives, and daily standups.
You should prepare ahead for the situation when someone points out that an assigned task is outside their role scope. This means a specific process should be created for assigning these tasks to someone else or handling unaccounted tasks.
5. Stay Agile
Agile is a very popular concept in the software development industry. As an approach to software delivery Agile boils down to engineering team adaptability. This means that before scaling your development team you need to make sure each member is capable of self-organization. While each member plays a specific role in the completion of projects, at the end of the day an Agile team is cross-functional and shares responsibility for the result.
Agile teams work on a basis of a collaborative effort to meet end goals. To function efficiently, a team will assess the priority of features and start working on the ones that bring the most value. By adopting an Agile approach software development teams can deliver incrementally at a set time period and cost, allowing for a faster release.
6. Develop leaders
Engineering leadership development is a key component to a successful software project scaling. Make sure that all the roles and their scopes are clearly defined for everyone. You can’t start your project without assigning a Scrum master, a product owner, a development leads, a business analyst, or a product manager.
Ownership is a factor that can boost productivity so make sure to assign roles and outline responsibility. Grow engineering leaders so that they can act as executive assistants and help you handle the scaled team structure.
7. Hire efficiently
Sometimes it’s not possible to deliver the final product without putting excessive pressure and burden on your existing team. The best solution for this issue is outsourcing because it allows you to scale up or down to fulfill your development requirements. Also, it comes with the benefit of not having to let people go at the end of the project.
You should consider outsourcing when building a distributed team and lacking internal manpower. Another benefit of outsourcing is the lower cost in comparison to maintaining internal or disparate development teams. A simple conversion of permanent cost (salaries) into the variable cost ( project fees) will show you that.
Startup Case Studies
Ex-Spotify CTO explains how to build and scale successful startups
We want to start with a very well-known story, that of Spotify’s ex-CTO Andreas Ehn. He was responsible for hiring the engineering teams at Spotify, leading and scaling them. This was the start of Spotify’s journey towards agility and building an agile model specific to their company.
The Spotify model can be viewed as Spotify’s perspective on scaling from a technical and cultural perspective. This approach is different and works so well because it’s people-driven, autonomous and it focuses on culture and network to enable agility.
Handling user growth and team growth
Ehn considers that there are two types of growth that you will battle as a start-up: user growth and team growth. While user growth is positive, team growth is directly influenced by it and can be the deciding factor in maintaining an efficient organization.
He mentions that while working at Spotify, in the first 3 years, they doubled their developers every year. He considers that to be the limit for sustainable growth to retain the culture of the organization.
His warning to founders was to be aware of the existence of false positives when identifying product-market fit. Fast growth doesn’t ensure sustainability, and for this reason, he emphasizes understanding the growth mechanisms. This will ensure a constant, sustainable evolution for your organization.
Hire exceptional talent
A good part of success is hiring and using people with great skills. Ehn recommends hiring exceptional talent even when you don’t have a specific job for them because, in the end, they will prove to be valuable.
When possible, it’s ideal to keep staff count lower because this will enable the organization to be more focused and eliminate overhead due to headcount growth.
Ehn admits that hiring is a constant challenge for most organizations regardless of size, industry, or geography. He goes ahead and illustrates that in some places there aren’t that many candidates while in others the competition for the workforce is high. No matter the place or the industry, hiring can prove to be a struggle.
Nurture tech leaders
Ehn has experienced the role of a leader in multiple forms across his career. From all these roles he learned about the importance of information and accessibility around it.
When these conditions are met you obtain transparency which is crucial especially for technical leaders dispersed all around the globe.
Focus on Architecture and Platform Engineering Squads
If you are interested in implementing the Spotify Agile model we recommend starting with Architecture and Platform Engineering Squads as is illustrated in this IBM Garage article.
When starting all of them at the same time you’ll find out that the architecture Squad struggles to keep up and never quite catches up. By starting with the Architecture and Platform Engineering Squads first, you will give them the necessary time to finish building the Reference Architecture.
- Use automation To err is human or so they say, that means your teams are not immune to errors. For this reason, you should rely on automation within the platform. Being able to execute code confidently or to isolate bugs and errors within the code, to do continuous deployment, can only benefit your developers and your organization.
- Focus on efficiency To move faster in the software delivery process, you need to build an efficient platform. Things like fixing bugs fast to build efficiency, creating features on a necessity basis, reusing code, and creating reference implementation are key actions. When it comes to the bigger picture, all these things will lead to a higher lead time to market and give the business a competitive edge. Efficiency involves failing, you just have to make sure you fail fast and fix it on time. It helps tremendously if the platform is transparent when showing errors because this way, your teams achieve faster debugging and deployments.
- Enable self-service Things like interactive training labs and developers portals are helpful all around. They can be used for MVP discovery or to reference implementation, also they are helpful in onboarding recruits. DIY discovery within the platform is preferred to the wasteful use of shadow Platform Engineering Squads.
- Assign authority The success of the platform team relies on the quality of their decision. While building the foundations of the platform this team has to make decisions that will affect the rest of the teams.
- Support advocacy Constant advocacy of the platform team will allow software engineers to build more and eliminate a significant part of the cognitive overhead. This is why the platform team deals with the details that can be reused and automated.
- Reinforce accountability at a team level accountability is an obligatory condition, meaning that whenever a breaking change happens, the whole team is well informed. A sense of ownership should be present to build a better system.
- Value expertise Expertise is extremely valuable and necessary for the platform team to function efficiently. But you have to keep in mind that the distribution of expertise and experience varies based on the structure of the organization.
Uber - Scaling Software Teams Faster During Hyper-growth
Another great example of scaling software teams comes from Oliver Nicholas, ex-Staff Engineer at Uber. Find out how Uber successfully scaled software teams during their hyper-growth and what Nicholas advises for start-ups!
Take note that before diving into his list of recommendations Nicholas affirms that “scaling during hyper-growth is much easier if you make smart decisions before the hyper-growth part”.
Tips for Scaling Software Teams from Oliver Nicholas ex-Staff Engineer at Uber:
Focus on hiring "A Players" and Generalists By generalists we mean dynamic software engineers, that can solve rising problems without you having to bring someone else in. Your progress can be stunted by the people you hire or don’t actually hire. “A Players” can be described as passionate and intelligent individuals who are not afraid to get involved and dedicate themselves to the project.
Leverage documentation Don’t procrastinate on documenting and graphing your processes and knowledge base. Build a wiki with the processes and lessons that should be followed and learned.
Use what you know There’s no such thing as boring technology, taking risks with new technologies is useless especially if you don’t intend to innovate. Your old software is efficient for a reason: the bugs are solved and you can have your choice when hiring new staff.
Go for Service-Oriented Architecture It results in smaller codebases, deployable units, and overall better-defined areas of responsibility. At the same time, you have to treat service boundary the same as a network boundary and expect failure. As for critical functions, they need to be separated into their own services, and you should accept different deploy schedules for them.
Expect failure and design for it Stateless processes where possible are recommended at service levels. Design reasonable time-outs for calls to unreliable systems and all 3rd parties. Allow for functionality to degrade when particular sub-services are inaccessible.
Start tracking everything Rapid iteration is founded on automated, comprehensive testing and the possibility to know if something has gone wrong. Use post-mortems, write them on your documentation as well, to add more monitoring. Maybe it will take some time to implement the tracking but once it’s done, your team will be faster and less afraid to deploy.
Focus on security Security might be hard but dealing with the aftermath of unreliable security is a much bigger challenge. Instead of wasting time to make up for lapses in security, you can start encrypting your offsite database backups and the PKs shown to the front-end. You need to have in place a proper RBAC framework, even if the first implementation is naive.
Create and use frameworks These frameworks need to contain your best practices. Put these frameworks to work and ensure that your software engineers build their new projects on them.
Successful software development scaling can be best achieved through a solid foundation built on a clear mission, vision, and culture, as well as some solid processes and technical base.
While each organization is unique, one thing remains true for all, it’s crucial to implement agile practices and make use of technology and processes to nurture collaboration among teams. The right people, whether they are in-house developers or outsourced, will help you implement best practices and achieve a better understanding of the final goal.