Three key focus areas for scaling effective software development teams

Improving efficiency in R&D spending is one way software companies can weather an economic slowdown.

In brief

• In periods of growth, software companies often make R&D investments on a longer time horizon, including hiring to support revenue that may be 3-5 years away.
• In a downturn, companies may need to switch to a focus on profits, not revenues, in the short term, while maintaining the software development engine.
• To preserve value in a targeted way, companies can review R&D spending to match current software development needs.

Software companies seeking to rein in their growth-at-all-costs spending in the current economic environment can focus on an often-overlooked area: the software development factory.

The decade-long boom in software venture and private equity activity fueled by near-zero interest rates created highly competitive markets saturated with well-capitalized vendors, which led to unrestrained spending. Now, more discipline is required as access to capital tightens amid rising interest rates and economic uncertainty. With software companies and the wider technology industry cutting costs, as evidenced by large-scale layoffs, there is an opportunity to reset their organizational structures and processes to power future growth.

There are several challenges inherent in scaling an effective R&D team: finding skilled talent is never easy, process change often faces cultural resistance and companies often delay platform until customer-facing technology fails.

But failing to effectively scale R&D teams can lead to lower innovation, reduced efficiency, higher operating expenses and a less competitive product. A successful long-term R&D growth strategy accounts for required investments in people, processes and technology to increase innovation velocity and quality throughout the company’s lifecycle.

1. Focus on which software development people need to be added

Growing companies rapidly deliver new features and products, creating ambitious roadmaps to expand the product set and increase the serviceable market. People are the main ingredient in developing software, so adding R&D team members seems like a clear answer. But executives may need to think critically about all their options, including whether additional people will be needed in the short or long term, and what the best approach is to grow the team.

For example, an EY-Parthenon team helped a health care IT company design a capacity tracking and planning program to provide greater visibility into the time and resources allocated across different projects. This led to a more accurate view of expenses (capex vs. opex) and the ability to shift people as needed to projects at risk of being completed late. In other words, better software portfolio management.

Areas that executives can consider when choosing the correct approach include the following:

Development priorities

Start by evaluating the current team’s projects and whether some of those activities have become less important. Aligning current roadmap priorities with the company’s strategic direction can enable leaders to shift work away from less critical initiatives to those that directly impact the company’s long-term goals. Determining the effort required for those initiatives can then indicate whether the current team can support high-priority development projects, as well as how much additional labor may be required, before identifying the proper course of action to access talent.

Hiring talent

If there are still gaps, it makes sense to bring in additional talent. This could be either from simply not having enough developers in the organization or because the roadmap requires a specialized skill set that the existing team does not possess. One example would be hiring a data scientist to support the creation of artificial intelligence and machine learning models for a new or existing product. When hiring, companies can choose between full-time and contracted labor and whether to hire in high- or low-cost geographies. Full-time hires are likely to stay longer and can take over the institutional knowledge about the company’s products and technology; the downside is that recruiting and onboarding for a full-time position is an expensive and time-consuming process, even as labor markets show signs of easing. Several major technology companies have laid off developers, but they still have to be evaluated and trained when brought into new organizations.

Onboarding contractors

If a full-time recruiting pipeline cannot support a company’s headcount growth needs, or if the company only needs short-term capacity, contractors can rapidly increase development capacity. On average, about 30% of R&D employees in software companies are either contractors or part-time employees, according to an EY-Parthenon survey of 1,000 software company chief technology officers (CTOs)¹. Contracting typically is not the right approach to build institutional knowledge, but it is much easier to bring in skill sets not currently held in house. Software executives can mitigate knowledge transfer risk associated with contracting by embedding contractors into teams with full-time employees or focusing contracted labor on noncritical development.

2. Update processes for a changing organization

Adding people forces R&D operations to evolve. A startup with a single development team of full-stack engineers will design and build software that looks dramatically different from one with multiple teams split by product or specialty. As an organization grows and transitions from one team to many, communication silos can develop between teams, affecting how individual teams build software. The problem is further magnified as the team grows across multiple geographies or the company makes acquisitions of organizations with different team structures and philosophies. Executives may need to be careful to structure the R&D organization to reduce information silos and reflect the long-term architectural vision. Doing so early can help reduce friction resulting from organizational and operational change as the company grows. Steps to consider when re-examining the R&D process are discussed below.

Evaluate the team structure and processes

Though the specific structure that an organization chooses can be based on individual business requirements, implementing leading practices can help guide organizational design decisions. Having a dedicated technology leader is a must, but companies may also choose to split product and technology responsibilities between chief technology and chief product officers. When both roles are present, it is imperative that these leaders are on the same page to keep product and technology teams moving in lockstep. Companies may also choose to organize by business unit or function: A function-based structure improves cohesion across products, but organizing by business unit may be appropriate if products have different use cases or development cycles.

Many software companies leverage cross-functional teams with a mix of specialties and are segmented by product or feature. Embedding product management in development teams while meeting regularly as a larger group to align on roadmap priorities can also help to smooth out cross-team communication challenges. Also, software architecture review boards can provide governance over architectural changes to verify that they are necessary for the product and align with management’s strategic vision. Companies will find it much easier to plan for R&D growth before it occurs, rather than shifting and reworking code once the teams are already in place.

Automate the software development lifecycle

As an organization grows, coordinating and releasing the work of a large number of people becomes difficult. This is when the software development lifecycle (SDLC), where processes mature to take on the added challenges of scale, becomes important. Improving efficiency in the SDLC is often an afterthought for young companies primarily focused on building new capabilities and acquiring initial customers, which can lead to potential obstacles for future releases to overcome. Today, many R&D departments approach SDLC enhancement through a DevOps lens (combining development and  operations into one discipline). This emphasizes code, build and test automation with continuous integration and delivery. Each of these elements improves a team’s productivity and efficiency at different stages of the SDLC, but all work together to free up developer time and effort to do what they do best — deliver more features and products.

3.  Don’t neglect technology

When managed properly, an organization’s technology can help developers accelerate development and innovation. When managed poorly, it creates friction that limits developer productivity and efficiency.

For example, an EY-Parthenon team recently worked with a FinTech vendor that had neglected to upgrade its architecture and technology stack. This led to an accumulation of technical debt that was beginning to reduce the organization’s ability to build innovative new features into its products. The EY-Parthenon team collaborated with company leadership to define a technology modernization roadmap that would reduce its technical debt, facilitate innovation and ultimately result in expected ROI of eight times the investment required to complete the modernization.

Executives can focus on the following items when addressing technology:

Controlling technical debt

Technical debt includes the cost of any future revisions required due to a past technology decision. While often related to shortcuts a company has taken to accelerate time to market, technical debt naturally accrues in any software as existing components age and new technology with improved functionality is introduced. Prioritizing and routinely paying down technical debt is a critical aspect to scale R&D operations. Failing to do so can introduce bottlenecks in the architecture that developers need to work around, reduce innovation speed, and increase the level of R&D effort and investment needed to ultimately remediate the debt when it becomes untenable. On average, 45% of CTOs with declining revenue and 33% of CTOs with growing revenue identified technical debt as the top unsolved challenge for their R&D departments².

During a sales slowdown, companies can focus on retaining existing customers rather than acquiring new ones. This change can shift a company’s priorities from building new products to remediating technical debt and bugs.

Technology stack considerations

The overall technology stack (the specific languages, frameworks and database systems used in an application) is also a critical enabler of R&D scalability. Choosing languages and frameworks that are familiar to many developers simplifies recruiting efforts. A modern stack can further attract R&D talent excited to work with new technologies. What’s more, streamlining the technology stack so that all products within an organization are built with the same (or similar) languages and frameworks improves the fungibility of R&D team members across the architecture; for example, developers on a low-priority project can easily move to support another initiative rather than being limited to working on a particular product. This improves overall R&D efficiency.

Conversely, companies that have significant technology sprawl, often from a history of poorly integrated acquisitions, create operational bottlenecks by limiting developers to the silos of the product with which they are most familiar. Decisions on the technology stack will have long-lasting implications for product performance and costs. Careful technology stack setup may be decided upon before undertaking major development efforts.

Special thanks to the contributions made by Patrick Daly, Ioannis Wallingford, and Harrison Cohn.