Businesses split because they want to increase their agility, scale up innovation, and create shareholder value. Acknowledging this, it is incumbent upon IT organizations to align their efforts to these priorities.
A split as an opportunity to modernize technologies and processes in ways that solve known problems (like technical debt and ineffective processes). By promoting agility and innovation in its own technologies and processes, IT has the opportunity to overcome long-standing pain points while becoming a true partner with the business they serve. If, however, the opportunities of a split pass by, legacy technology and old ways of doing things can actually undermine the goals of a business split and expose the business to risks from which they are protected neither by size and portfolio diversity, nor from a capacity for innovation.
In this piece, I will describe important considerations for IT organizations as they support a business split, identify potential pitfalls, and provide specific suggestions for how they can get started. Innovation is the ability to quickly solve complex problems by combining disparate elements in creative ways. And a company that is innovative will, by definition, drive shareholder value. At the root of innovation, however, is responsiveness. For the purpose of this piece, then, I will focus on building capacity for agility, in the absence of which neither innovation nor long-term growth are possible.
Why businesses split
Conglomerates and other large businesses split for three main reasons: agility, innovation, and shareholder value.
Agility
Size and diversification are excellent hedges against risk associated with volatility in any single market. But the added management layers create complexity that limit visibility in ways that can significantly restrict a conglomerate’s ability to adapt to emerging challenges and opportunities in particular markets. Think about an ocean liner: It’s size alone means that it is able to withstand significant turbulence, regardless of where that turbulence might come from. With size, however, comes momentum. Once the course is set, it can be very difficult to change direction suddenly in case of catastrophe.
When businesses split, they do so in order to increase their specialization, improve brand position, reduce decision-making overhead, and optimize their systems to achieve greater visibility. By splitting into more specialized businesses, the resulting entities give up the protection afforded by diversification, but they gain in terms of their ability to quickly identify and respond to challenges and opportunities in their particular market. In this, they are less like an ocean liner, and more like a speed boat.
Innovation
In theory, conglomerates and large businesses with diverse business interests should be able to support tremendous innovation. Access to internal markets in the form of capital, personnel, and ideas sounds great. In practice, however, complex bureaucracy slows decision-making, and cultural differences between business entities can reduce transparency and even foster antagonisms that breed more competition than cooperation. Moreover, the way that conglomerates shelter individual business entities from risk, combined with the fact that leadership rarely have visibility into the day-to-day operations of those individual entities, can foster a culture of complacence that optimizes to make management happy more than focusing on what will drive long-term competitiveness.
When businesses split, they do so in order to promote innovation in two respects: product and process.
From the product perspective, businesses that split are looking to focus on investments that allow them to make real progress in the markets they serve, and in a way that is only possible if the entire organization is laser-focused on a common vision. Freed from internal competition, individual businesses are often in a better position to build a culture of cooperation. And with increased exposure to a particular market, those same businesses are incentivized to differentiate and innovate quickly because they can no longer count on the safety net represented by the conglomerate.
From the perspective of process, businesses that split have an opportunity to think about why they do what they do and identify processes and practices that are ill-suited to its vision and goals. It means streamlining management so that decisions can be made more quickly, and it means modernizing enterprise IT investment so that they are (1) purpose-built to meet the specific needs of the business, (2) can be easily customized in response to change, and (3) are not hobbled by the technical debt that can hold back so many conglomerates and other businesses with large, diverse product portfolios.
Shareholder value
A split is usually good for shareholders, because separately managing each entity often increase the profits of each such that the combined profits of individual businesses exceed the profits of the single entity they came from.
Out of a split, shareholders are asked to trade in their shares of the single entity for one or a combination of the new entities. With greater specialization in the business comes greater visibility and easier-to-understand accounting on the part of shareholders, which makes it easier to accurately value the business. Attempting to unify a broad portfolio of businesses with a single philosophy is challenging, and frequently difficult for investors to understand or explain to stakeholders. As a result of a split, the benefit that single entities experience in creating a clear vision that aligns the business around innovation also results in a clear vision that shareholders can understand and get excited about. The result are more enthusiastic investors and the potential for higher share prices.
Building capacity for agility within Enterprise IT
In business, agility is the ability to quickly respond to challenges and opportunities in ways that drive value by improving productivity and mitigating risk. In this, agility ultimately comes down to alignment between business and IT in three main areas: knowledge, communication, and support.
Knowledge and live data
Decision quality is always a function of information quality and quantity. In order for a business to manage itself effectively, it needs to have access to information that is both (1) current and (2) complete. Unfortunately, the systems that business entities inherit from their parents are frequently outdated, highly customized, and not fit for purpose. As a consequence, single entities have both a challenge and an opportunity.
The challenge is that they are using (a) legacy systems built to collect and report information required by a parent company, and (b) an unwieldy collection of shadow systems (i.e., spreadsheets on desktops) for tracking a large amount of additional information required to manage the day-to-day operations of the business itself. The result? Data silos. Lots of them. With data silos comes a lack of visibility into the business as a whole (the problem of completeness). And with the use of unintegrated systems maintained through manual processes comes a lag in information processing and unevenness in data quality (the problem of currency). In this situation, data become fragmented, less relevant, and incomplete.
When businesses split, however, they are no longer beholden to the needs of a parent, and don’t need to compromise the needs of the one for the benefit of the many. A split, then, represents an opportunity to evaluate the specific information needs of the single identity and to begin the work of creating a unified system of resources that fulfill operational requirements at the same time as it begins to surface the right data, to the right people, in the right way, and at the right time.
Process and empathy
One of the greatest points of friction in any organization lies in the relationship between business and IT. Business wants to be agile. When they identify a challenge or an opportunity that requires IT involvement, they want to see results fast. IT, on the other hand, understands complexities that the business often doesn’t. It thinks about what is possible, impacts to legacy systems, security, implications, and the long-term consequences of maintaining changes or new investments over time.
Among the most high-friction and fraught moments in this relationship is requirement gathering. Frequently, requirement gathering is something that starts somewhere in the business and in terms that the business understands. Once complete, a document 9in a non-standard format) will get thrown over the fence to IT, which has to translate the requirements in terms of the specific systems and processes that will be impacted. Based on that second requirements document, work gets done and is eventually delivered to the business stakeholders, who are frequently disappointed when the delivered solution doesn’t conform to the spirit or specifics or what they thought they requested. The result is that the entire process takes longer and delivers lower results than expected.
This kind of situation is incredibly common within large organizations. Everyone realizes that it is ineffective, but organization size and complexity make it difficult to do anything about. As a result of a split, however, an individual entity becomes smaller and more specialized, which means that the IT organization can become more specialized in meeting the needs of Business stakeholders. A time of transition represents an opportunity to rethink frustrating processes that everyone knows are broken, and to adopt a more empathetic approach that brings the needs of business and IT closer into alignment. It represents an opportunity to actually adopt Agile as a delivery methodology, and to incorporate Design Thinking principles that overcome communication barriers. It represents an opportunity for business and IT to overcome antagonisms and function as partners, with business coming to better understand the limits of what is possible, and IT being able to share what might be possible as a solution that business may not have even considered.
Agility can't only be viewed as how quickly you can take a first step. It needs to be viewed in the context of a journey, and as an ongoing set of behaviors. It’s not about finding shortcuts and workarounds, which build up over time and actually impede future agility. What is needed is a mutual understanding and trust between business and IT. They either succeed or fail together.
Technology and the inevitability of low code
Last but not least, a split represents an opportunity to modernize and abandon legacy process that may have been holding the business back. If one of the goals of a split is to become more agile, why would a resulting single entity continue to use a kludgey, legacy codebase? Why not use this as an opportunity to rethink investments in a way that eliminates worries about legacy code, bolsters security, and increases the ease with which enhancements can be made?
Developers spend 42% of their time maintaining legacy code. The result is an estimated $300 billion in wasted developer time each and every year. And that doesn’t include the impact that legacy code has on the ability of organizations to quickly make system changes because a seemingly simple changes touch multiple legacy systems which are complex to coordinate, require complex and manual testing, and are so brittle that they could break at any moment. How many opportunities are lost if creating a single SKU in support of a new product launch, for example, can take up to a year? More than this, the rate at which large businesses face public humiliation and millions of dollars in damage as a result of using systems built in the 1980’s is on the rise.
When we consider the steadily increasing amount of development time required to maintain legacy code at the expense of innovation and the increasing amount of risk that legacy code exposes large enterprises from the perspectives of security, compliance, and competitiveness, it’s obvious that we’re at a tipping point. There is no better time than a split for individual entities to modernize, and to modernize in a way that doesn’t just wipe away technical debt, but also radically mitigates the risk of accumulating that same debt again in the future.
What today’s businesses need in order to be agile is a low-code development platform that can adapt to meet any level of complexity, an empathetic approach to software development, and an ability to aggregate live data so that business leaders and other stakeholders always have access to the right information, in the right way, and at the right time.
The proliferation of shadow systems represents significant risk to a large, diverse corporation. While business teams may feel they are moving ahead by working around IT, disconnected shadow systems actually serve to fragment business processes, data, and the user experience. What today’s businesses also need, therefore, is for their low-code development environments to support the creation of relatively simple applications by citizen developers. By enabling business users to create applications for themselves, using the same environment as more complex development efforts, but in ways that are user-friendly, well-governed, and secure, IT organizations empower those to be agile in meeting basic needs without erecting obstacles and tacitly promoting the use of unsupported systems that lead to data silos and cannot be sustained in the long run. A well-run citizen development program also serves to scale innovation in two important ways. First, as more and more people within an organization become more expert in leveraging a common low-code development environment to create applications for use by themselves and their teams, democratization promotes a culture of innovation. Second, because IT is freed from less complex development activities, and freed from having to babysit legacy code, they can focus on high impact and complex activities that drive significant value in market-leading ways.
Advice for a splitting business
When given the opportunity to reorganize an IT organization in support of a business split, there are three key principles that every IT leader should keep in mind.
1. Understanding
In order to most effectively support the business during a split, it’s important for IT leaders not just to bear in mind the high-level motivations for the split (agility, innovation, and shareholder value), but that they also make an active effort to understand the specific goals of the business they serve in order to ensure that modernization efforts are aligned, and that corporate leaders and department managers are supportive. Ironically, a business split is an excellent opportunity to build bridges and to ensure that everyone in the organization is moving in the same direction, in pursuit of a common vision.
From a more technical perspective, it’s also important to understand the technology landscape from end to end – sales, accounting, support, business intelligence, etc. – including shadow systems that may have been developed so the right data can be migrated up front, and the needs of the entire organization are represented when considering modernization priorities. The key here is that IT and business need to work very closely together in a tight partnership. There will be times when IT will need to help identify and drive gaps in business processes, and times when the business will need help identify and drive gaps in the IT systems.
2. Minimalism
Yes, a business split represents a tremendous opportunity to modernize. But modernization is not easy. This kind of change can be daunting, and one can feel pressure to move fast even as they feel paralyzed by the size of the task before them. The good news is that untangling legacy systems, replacing them with others, and reshaping an organization’s culture around values like agility, empathy, and innovation takes time. And it must take time in order to do right. The key here is to avoid the temptation to address complexity by adding too much complexity too soon.
Foundational to the Pega Express delivery approach is the idea of a Minimum Lovable Product (MLP). A Minimum Lovable Product is different from a minimum viable product, which focuses on achieving something feasible. A Minimum Lovable Product delivers a solution that is not only viable but desired and embraced by end users. An MLP is packaged to quickly deliver business outcomes in a way that delights customers and makes their lives easier.
Aspire ‘big,’ but think and implement ‘small’ when it comes to execution. Frequent iteration means decreased time to value, and creates frequent opportunities for the business to provide feedback.
3. Plan for the future
Even as you adopt a minimalist approach, focused on delivering minimum lovable products, it’s important not to lose site of the future. Adopting a low-code development environment that eliminates the need to maintain legacy code is an important start, but there are other things to consider as well.
For example, does data need to be segregated now? Perhaps not. A phased approach might be more appropriate. Perhaps attribute-based access control (ABAC) is sufficient to achieve security and compliance on day one. As the business evolves and the security landscape changes, however, a more elaborate solution could be introduced to physically separate some kinds of data into different systems. So think through the approach to ensure that short term decisions align to business objectives and do not prevent the necessary long term transformations.
At the foundation of a successful split is alignment between business and IT. To the extent that IT understands the motivation for a split and the kind of value a split is meant to achieve, they have an opportunity modernize in a way that isn’t simply for its own sake, but for the sake of a well-defined set of business outcomes. And they also have an opportunity to become true partners with the business, by rapidly delivering solutions to business problems while also serving as a trusted advisor in the identification of technical opportunities and challenges that the business might not otherwise consider.
Don't Forget
- JOIN THE CONVERSATION on Collaboration Center
- FOLLOW @PegaDeveloper on Twitter
- SUBSCRIBE to the Pega Developer Podcast on Spotify or via RSS