How To Scale Software Development Teams

We meet with a lot of software leaders here at LinearB. Throughout these conversations, we have identified some common themes and struggles. One of those common struggles is intelligently growing a team

One leader we talked to sums it up like this: “We’ve really got something going. The company is doing great, and I need to scale up my software team. The pressure is on to deliver.” 

This is an awesome, albeit scary, position to be in. So how can leaders build an amazing team? Our answer to scale using a data-driven hiring process.

Scaling A Software Organization is the Ultimate Challenge

Sometimes you’re feeling unstoppable, and sometimes it can feel like you’re Little Mac vs. Tyson in NES Punch Out (watch the video ->)

A wildly diverse set of skills is being tested, here, spanning people, projects, teams, methodology, budget, code, architecture, and communication, to name a few. In my opinion, successfully scaling an organization separates the average software leaders from the elite.

//Side Note: The LinearB co-founders previously ran engineering at CloudLock. Upon acquisition, they ran a 75 contributor global dev team spanning US, UK, Ukraine and Israel, and they were responsible for scaling the team. It was a wild ride, to say the least.

If you are in the team-scaling phase, think of it as a blessing. Your abilities and experience will level up 100%, guaranteed. The thing is, you likely need to make changes to your organization in order to gain the expected ROI from team growth. To help you on your journey, focus on some guidelines on how to scale your software team and some of the metrics that can help identify areas to grow your team.

Technical Readiness

Team growth changes everything. Bottlenecks in your value delivery pipeline become exposed, quality issues become exacerbated (think about customer growth), and things that you were able to get away with when your team was small no longer fly. No worries, though! If you can be mindful about your organization’s test methodology, delivery independence, and codebase health, then you’ll have a solid starting point for success.

Test Methodology

Test methodology impacts quality, delivery throughput, team setup, and, ultimately, an organization’s productivity. As your team scales, the importance of completing fast test cycles increases, and, as you might expect, so will the penalties for inefficient test practices. If you have fast feedback and a high quality test cycle that is fully automated, congrats! Keep that going. If your test methodology is not up to par, red alert! Improve this now, and don’t think twice (it’s alright).

//Side note: Test methodology is fascinating. I believe manual “testing” can still be useful for customer value confirmation, but your automated testing has to cover everything else. Who performs the manual “testing” is also up for debate. Personally, I think it should be the product owner. Ryan Schaffer, franchise owner of Code Ninjas, has extremely insightful thoughts about this based on his QA leadership experiences. You should ask him more about it!

My advice to software leaders regarding testability is to measure, understand, and continuously be conscious about the following metrics.

Cycle Time

This is a throughput metric that brings to light a crucial piece of your value delivery pipeline. You will see significant productivity gains by improving your test cycle time. Here is another way to think about it. The faster you provide your people with quality feedback, the faster they can iterate to improve the product. When scaling your team, its important to understand where in your delivery pipeline needs more resources. Hiring to fill a strategic gap in your process will make EVERYONE on your team better. 

Pro tip:  Measuring and improving your cycle time (your efficiency in getting code to production) will help improve your mean time to restore which can limit the negative impact of issues found in production. Start measuring your cycle time.

Automated Test Coverage

This is an activity metric, and I advise this measurement, cautiously. Like all metrics, it must be used responsibly. Test coverage is important, but only with complimentary metrics like issue rate and cycle time. It is important to understand how much effort your team is putting into automated testing and the trend of your test coverage.

Issues Found in Production

Issues or defects found in production is sometimes known as change failure rate. It measures the amount of issues that were not caught prior to code released to prod. There are many models that extrapolate on this concept including the defect removal efficiency model. Issues found in production is a lagging indicator that can be used to understand your quality. Quality is a key area to pay attention to when scaling your team. Teams with higher quality operate more efficiently, hit delivery deadlines more consistently, and have happier developers. If you have a large number of issues found in production, look at adding a resource dedicated to your QA process. They’ll make the whole team better. 
Pro Tip: No need to spend any manual effort measuring issues found in prod for your organization or for each team/iteration. All of this can and should be automated as seen above.

There are other useful metrics in the testability category. However, I believe measuring and visualizing these three metrics provides a solid baseline that promotes the mindset needed to increase productivity as your team grows.

Team Delivery Independence

When more people join an organization there are, inevitably, more software teams that need to be created. As you create more teams, the importance of delivery independence increases. This means that each team needs to have the ability to get value into production at their desired rate with zero to minimal dependence on other teams. Without this, you will struggle to increase your team size and increase your productivity. There are two areas that are important to highlight in this category.

Team Metrics

Visibility into what is happening within each team is crucial. You need to see metrics measured and visualized on a per team basis because each team will have different observable challenges. Based on my experience, I believe delivery independence is the most important area of focus for technical readiness. More specifically, I recommend paying close attention to the time from code merge to production release. This metric needs to stay the same or improve as your team grows.

Tracking how time is allocated by team and iteration help engineering leaders identify where resources are spread too thin and how performance is changing over time. Connecting LinearB to your Jira instance helps identify focus areas quickly.

Architecture and Design

The way in which your system is architected will impact the delivery independence of your teams. This is one reason why services are a good idea. Make sure that each team has the ability to own the lifecycle of their services. Your architecture and design will either hinder or promote this ability which, in turn, influences productivity.

It is also important to make sure that each of your teams have all of the necessary skill sets needed to deliver value. For now, we’ll save a deeper dive into team formation and delivery independence for a future post

Codebase Health

The state of your codebase requires constant mindfulness. If you are about to bring a bunch of new hires into your organization, you want them to hit the ground running. The faster they can do this, the better.

Commenting Ratio

The quality of your codebase will impact the journey to productivity for all new hires. Part of having a quality codebase is the ability for new contributors to understand what is happening quickly. Proper commenting helps a lot.

//Side Note: I’ve heard the theory around, “great code should explain itself”. I’m not buying it, and most of the leaders I meet with agree. That line tends to evoke an eye-roll.

Rework Hotspots:

A large amount of rework (>20%) is an indicator of a code quality hotspot in the given repository or branch. Excessive rework slows down developers and reduces the ability to efficiently create new value delivered to production.

The ability to identify and address rework hotspots allows software teams to be proactive with their quality efforts resulting in improved software delivery efficiency.

Rework displayed in LinearB

Documentation ratio

This is another quality metric and it is similar to commenting ratio. Having proper documentation in place will increase context for new hires and decrease time to productivity.

Standardization error rate:

This one is interesting. Each organization has different practices when it comes to code standards ranging from nothing to strict. I think it’s important to decide where you want to fall on the spectrum and communicate your standards prior to team growth. Your new contributors are likely to carry forth whatever you have in place upon joining.

Conclusion

Scaling a team is an awesome challenge. Incorporating the right data in the process can help you identify where your team needs resources and what skillsets to target. A data-driven recruiting process is beneficial for the engineering leader AND the recruiter. It increases the chances that you will find the right candidate for your team. 

Need help understanding your team’s metrics to guide your team growth? LinearB can help. Click below start your free trial!

Get Started Now

Start your 14-day trial of LinearB to understand and improve your quality and efficiency proactively.

Dash with Radar Angle Left