Common challenges in scaling engineering teams

If you’re scaling your engineering team, that’s great news because your company is clearly progressing.

However, there’s more to team scaling than recruiting more engineers. For instance, the project management methods that worked when you managed a small team aren’t necessarily enough to support one that is twice as big.

In this article, we’ll explore the common challenges in scaling development teams and list the ways you can overcome them.

Project management

A common challenge of project management when scaling engineering teams is disregarding the increase in project scope or team size.

To keep the project running smoothly, adapt your project management practices to accommodate a bigger team and see what you can do to break the project up into more digestible chunks.

It’s important to keep in mind that bigger teams, as well as bigger projects, are more complex and carry more risk.

That’s why scaling the team shouldn’t automatically mean that the project needs to grow in scope as well.

In fact, it’s a good idea to minimize the need for big projects altogether, as shown in the Spotify engineering culture guide.

When coding projects get too big, Henrik Kniberg, the guide creator, names wrong task estimates and useless meetings as the most prevalent risks.

Another danger lies in the number of mistakes that can occur. With more people involved in coding, the code gets more vulnerable to errors.

Since it’s much easier to detect bugs and react to them in smaller bits of code, you should consider shortening sprints and increasing the frequency of releases.

This practice is also seen in Spotify’s engineering culture guide.

An additional benefit of setting smaller goals and marking them as done is that your team gets a sense of progress, instead of waiting for large milestones that take months to complete.

If you decide to break your team’s workload down into smaller pieces, it’s vital to monitor task progress and completion. You could do this with project tracking software, such as Jira.

There are numerous project management tools designed for the software industry, so you should pick one that suits your needs best.

Choosing only one is vital because nobody wants important information scattered across multiple platforms.

With that in mind, make sure your project management strategy plans for an optimal team size regardless of the scaling volume.

Management of remote teams

Scaling changes team management, which is why the task may seem challenging, especially in remote or distributed teams. Still, a bit of planning makes managing an increased engineering team doable.

Whether you’re running a fully or partially remote team, you need a strategy to bring all your newly joined engineers up to speed. Communication is a good starting point here.

If you take a look at the following image, you’ll see a Glitch team in a virtual conference, each member working from home.

Nothing unusual there, right?

Well, what if we told you not all employees that you see worked from home that day?

Glitch is a tech company that places a lot of emphasis on distributed work.

To make communication identical for all employees, Glitch encourages the NYC office employees to join Zoom conferences from their own offices or private booths, not the conference room.

If your engineering teams consist of remote and on-site employees, you could try out the Glitch approach to synchronous communication.

That way, remote engineers will feel confident expressing their ideas without feeling intimidated by the corporate environment.

Still, some engineering teams prefer asynchronous work.

Let’s see how Slite, a fully remote company, does this.

Engineers at Slite do a fair share of work asynchronously, which grants them the freedom to work independently of others. This is especially helpful in remote developer onboarding after scaling.

There’s no reason why an engineer should wait until somebody walks them through internal code documentation practices when they can browse the information at their own pace.

Here’s a brief look at Slite’s internal handbook for new employees.

Of course, some aspects of work are still better done with real interactions, even in fully remote teams.

For instance, you could allow the engineers to code asynchronously, but conduct team meetings and one-on-ones in real-time calls, as Slite does.

Since distributed and remote teams often have members in different time zones, you should ensure you always find appropriate times for synchronous interactions.

All in all, managing remote engineers can be as effective as with on-site teams.

If you’re welcoming new engineers into your team, make sure you determine the practices for synchronous and asynchronous communication that best fit your needs.

Moving to agile

Scaling an engineering team is one thing, but scaling an agile team comes with its own sets of challenges.

Familiarizing yourself with the typical pain points of this management methodology will help you prepare for a smooth transition.

The 15th Annual State of Agile Report has revealed that inconsistent agile processes across teams are the most significant Agile adoption barrier.

However, the report also shows that a lack of skills and experience with agile makes the methodology challenging to adopt.

If you’ve scaled your engineering team, chances are you’ve hired engineers with no experience with agile.

To get on the same page with the rest of the team, you could ask them to read the essentials of the methodology, provided by the Agile Alliance.

These include the agile glossary, principles, manifesto, and more.

As we’ve seen in the State of Agile report, people are sometimes confused with inconsistencies, so you should ensure you equally implement agile practices across all teams.

It’s also helpful to walk the new engineers through how agile differs from the standard software development practices.

If the new devs are used to working in the background while only the management has the input in how the project is carried out, they may be surprised to learn that engineers have a more active role in agile.

For instance, the so-called three amigos approach in agile refers to the meetings where a business analyst, a software engineer, and a quality assurance specialist are all present.

So, if you’re scaling your engineering team and working with agile, you should prepare all the newcomers to your team for working with this method.

While you shouldn’t burden them with agile-specific KPIs as soon as they join, it’s helpful to show the new engineers how agile can help with scaling and delivering excellent results.

CI/CD

Just like too many chefs spoil the broth, too many devs spoil the code. To prevent that from happening, you should use continuous integration (CI) and continuous delivery (CD) tools to organize the deployment process.

If you’ve encountered the integration hell phenomenon, you know how challenging it is to manage integration and deployment even before scaling, let alone with new engineers on the team who may not immediately be familiar with your deployment practices.

Luckily, CI/CD tools can help you ship software quickly and efficiently. They allow you to write scripts and automate significant portions of integration and deployment.

That way, even the new engineers can deploy code without waiting for assistance, which speeds up the process—as witnessed by responders in the 2020 GitLab survey on DevSecOps.

One of the most popular CI/CD tools is Jenkins. The tool is open-source and free to use.

The following image, provided by Jenkins, shows one possible CD pipeline you could create with the tool.

Automating all these elements reduces the likelihood of mistakes made with manual deployment.

Still, not every code change warrants a launch. Sometimes, you just want to test your code without pushing a new release.

For instance, this developer created a pull request review to investigate if all code checks had passed, and the Jenkins bot responded positively.

This feature is extremely beneficial if you want to check on the performance of the engineers newly assigned to your team after scaling.

To sum up, scaling your engineering team doesn’t have to affect your deployment practices negatively.

Using the appropriate CI/CD tools allows all engineers to deploy the code, while still letting you double-check their work and confirm all pieces of code work with each other.

Maintaining productivity

Putting more engineers on a team doesn’t directly translate to faster shipping time and increased productivity.

To maintain productivity while scaling, you have to identify the least productive areas of work and devise effective solutions.

Scaling, regardless of the volume, inevitably changes the way the team works.

When Tamara Gevorgyan, director of engineering at Picsart, first joined the company, the team consisted of only five or six people.

Over the years, it grew to four hundred people across three continents.

Out of all aspects of engineering, Gevorgyan pinpoints productivity as the most challenging part of the development team scaling.

“One of my main challenges was maintaining the productivity of our developers and to continue to realize the goals of the company as the organization took on volume.”

Gevorgyan’s piece of advice for this challenge is to embrace processes and technologies that may solve the problems you’ve identified, even if they’re new and unfamiliar.

For instance, if your engineers and QA analysts lose productive time on reporting and describing bugs, it may be time to try out a crash and bug reporting tool.

Reporting bugs usually includes listing the following elements:

• Bug ID
• Environment
• Steps to reproduce
• Expected result
• Actual result
• Visual proof
• Bug severity

There are many more details that need to be recorded to provide engineers with actionable information, so it’s no surprise that the process can take hours.

With a bug reporting tool such as Shake, you’ll be able to reduce the reporting time to minutes.

With Shake, testers only need to describe expected and actual results because the tool automatically records other bug details.

With a bigger team, you’ll probably generate more code, which calls for more testing. So, to streamline the development process, you should cut down on all unnecessary work.

Even if you haven’t used bug reporting tools earlier, remember what Gevorgyan said about how you can boost productivity by embracing new processes. You should give Shake a go and watch it declutter your day.

If you want more tips on getting the most out of your engineering team, you might want to check out our article about ideas for improving dev productivity.

Scaling the codebase

The preparations for scaling engineering teams go much further than finding new ways to manage more people. To help the new engineers navigate the code, you should also prepare the code for scaling.

If your team has confusing internal practices for writing and documenting code, your new engineers will have a hard time understanding the existing code, let alone writing new lines.

For instance, your engineers may be more comfortable writing horizontally long code. However, the code written like that is not easy to read.

To make things easier for the new engineers, you could ask your devs to start coding vertically before you begin scaling.

Below are two examples of horizontal and vertical code written by Burak Guzel for Envato Tuts+.

Similarly, you should also ask the engineers to review their variable naming conventions and keep the names consistent.

This will help prevent duplicate variable names when new people start working in the shared database.

Our final piece of advice for preparing the new engineers to navigate through your coding practices is to create unified modeling language (UML) diagrams.

UML diagrams provide a visualization of the design of a system, which helps the new devs understand the software background and see how the project will work.

There are multiple types of UML diagrams. The following image, designed by SmartDraw, shows an example UML activity diagram for a website.

You could use SmartDraw to create diagrams and help your new engineers better understand the way your projects are created.

Of course, if you create an effective onboarding process, you’ll be able to introduce new engineers to your coding practices even before they start working on actual projects.

Conclusion

Hopefully, we’ve managed to demonstrate that each challenge that comes with scaling engineering teams can be overcome with a strategic approach.

So, before you start hiring more engineers, you should first plan how you’ll scale up your existing practices regarding project and team management and the tools you use for writing and testing code.

If you set up your company in a way that supports growth, engineers that join will be able to start working on code with minimal downtime.