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.