For the software engineering company scaling faster than their legacy systems can handle, breaking up is hard to do. These organizations stick to familiar paths of reorganizing rather than taking time to rearchitect their software and shift operating models. But this is the path of least resistance and, ultimately, the least impact. Only companies that get ahead of the forcing function are really taking destiny into their own hands.
A functional reorg moves teams around but doesn’t address the systemic and cultural problem of short-term projects taking precedence over longer-term product, platform and portfolio goals. The bigger an organization grows with a project and feature mentality, the more production gets bogged down by dependencies and quality-control issues. Teams may come together to focus on a software feature, but once delivered, they return to their regular jobs. Sustainable ownership, accountability and expertise are lost.
To embark on a journey to change this model, companies have a three-fold task.
- To change the organization.
- To change systems to match the organization.
- To change the operating model and teach teams how to be mini CEOs.
Becoming a product- and outcome-driven organization requires all three steps. We need to invest in an internal reorganization, leveraging platforms and giving teams the autonomy to take full ownership of a product under a single-threaded leadership model.
Change The Organization
Most companies are either organized by function (with separate engineering, product and business and marketing arms) or by the leadership model pioneered by Amazon, which gives end-to-end ownership of products and platforms to multidisciplinary teams with a single leader.
In this digital world, we are always working backward from the customer. However, siloed development can hinder a company’s product offering. The obvious example is an organization that has acquired a company selling software as a service. The first thing they do is rebrand, but that only puts marketing collateral behind the same features. Nothing has actually changed in the product experience.
Changing or maintaining the reporting lines won’t necessarily change how teams work. To truly create a product- and outcome-driven organization, we need to focus less on moving entire teams around and more on giving tech teams the autonomy and ownership they need to focus on their projects. This requires a mindset shift.
Instead of moving teams around to focus on temporary projects, we need to adopt a product-over-project mentality. This is where product and feature ownership comes into play.
Change Ownership
Legacy companies are often organized into functional silos, where resources are spread out across numerous projects. This means that teams are temporarily dedicated to certain projects, but once the product or feature is deployed, the teams disperse and work on something else. After a linear phase is completed, teams start all over again.
The principle is the same when different teams build different projects and then disband. That product or feature lives on, but because nobody’s an expert, they don’t know how to fix and maintain their own work or integrate it with other products. Often the result is technical debt and a lack of agility because no one is truly an expert on the product. To effectively change ownership, you need to first get a long-term view of your stack to understand the products and platforms and then organize around it.
By contrast, when you create “mini CEOs” who have control over their domain, you’ll successfully establish a team that is constantly focused on improving the product and experience. When you give these “mini CEOs” control over their product and domain, they’re in the best position to innovate quickly on behalf of customers.
Change The Operating Model
Making the shift to a product- and outcome-driven organization always comes back to first principles of identifying your pain points and the problem you are trying to solve. Typically when the speed to market is slow, it means there are constraints in the system. Moving to a single-threaded model is not just a change in mandate but a change in mindset where the buck stops with the leader.
This is one of the reasons why Amazon created the two-pizza rule limiting the size of teams to foster greater collaboration. Instead of ticking boxes, they focused on developing stable code so they could iterate quickly, constantly improve and make better recommendations. In these cases, bigger is not always better. To be able to iterate and release products and updates as quickly as possible, we need small and focused teams that aren’t bogged down by having to rely on other teams and approvals.
On the organization side, the Amazon experience also showed that temporarily bringing non-specialist teams together to work on a feature or product only led to dependencies, slowdowns and quality and platform issues.
As a result, Amazon had to slow down to speed up. The company devoted resources and time to developing a single-threaded leadership model. Teams and their leaders were held accountable for their process from start to finish. This modern approach allows teams to be more concerned with preserving architectural integrity than meeting arbitrary schedules.
Create Sustainable Teams And Build For Continuity
To create a product- and outcome-driven organization, keep short- and long-term customer, business, and portfolio outcomes aligned. Instead of operating as a features factory, take a broad view approach to even individual products because they can serve multiple customer segments and goals. To create this environment, start by creating small, dedicated engineering teams with the autonomy to design and build products tailored to meet customer needs.
You also need to consider how market changes can affect outcomes, especially regarding product evolution. Adopting an agile approach to product development allows for quick response times and pivoting as needed. Creating an accountable environment where builders can build not only makes for happier, more productive teams but better products. Breaking up is hard to do, but embarking on this transformation is an investment in the future of your customer relationships.