As service providers helping large companies solve large problems, XL Group has to identify expedient, effective, and responsible ways to facilitate growth within the technology ecosystems of our clients. Part of this process is coaching them to solve problems iteratively by getting to the starting line with an imperfect but tactical solution so we can learn and adapt to fine-tune our execution and make outcomes relevant and predictable. There may be grand visions for a business application but the risks of building a giant platform in one enormous project greatly outweigh the benefits of a smaller, pilot application that serves the core needs of the business users. The mettle test of any leader in any field is whether or not they can take their own advice when they are faced with a challenge.

Recently, XL Group faced that challenge when we decided that the center of our operations, business processes and service model, The XLerator, was due for an upgrade to enable our own growth and agility. The original XLerator had been serving us well for 15 years and helped us implement a grand experiment in Knowledge Worker performance to test and validate the hypothesis that making work visible can make individuals and an organization more mindful, connected, and effective. The experiment has succeeded as we have had an entire company operating on this platform since its inception and are now going strong at 30+ years of operations.

No different than our clients in their businesses, we have teams of very busy professionals who rely on their established work streams to accomplish their daily tasks. Not unlike our clients, our team had come to rely on the very specific features and user experience of the legacy platform. Optimization opportunities abounded and the consensus was that our platform could and should evolve; nonetheless, team members had a handle on their responsibilities and knew how to leverage the available systems to get things done (and get them done well). Replacing the legacy application meant change, which meant disruption. There would be pain. There would be missed expectations. There would be uncertainty. We would need to navigate all of these things together and do it in a constructive, progressive and healthy fashion to ensure that change truly meant growth and didn’t get buried in the potential chaos of disruption.

What this mean to the product team responsible for displacing the legacy application is that we needed to have a deep understanding of the fundamental needs of the different types of users across the organization and the essential features and work streams they rely on daily to be effective at their work. We had to make observations and qualitative, data-driven decisions for each role to select the highest priority needs and deprioritize needs that were not truly essential to operations. This meant getting ready to communicate to our peers that there will be a balance between the vast improvements of a new application and the absence of “bells and whistles” that may impact the way they work when the Alpha product is launched. It is this very conversation that is often the most challenging when coaching clients. It is difficult and scary to deprioritize features that you know can benefit your organization but that will delay a launch and create a roadblock for implementing change. It is easy to convince yourself that you need that one extra feature, and that other one, and that other one…



Eventually, that list grows and a launch date gets further and further away and, in the meantime, your organization is choosing hypothetical perfection over progress. In a previous piece, I discussed the pitfalls of deciding things based on  , but perfection vs. progress is another common trap. The risks of imperfection are often greatly exaggerated.

So, we gathered and prioritized behaviors and translated them into core features. We made note of these decisions so we could communicate openly with our peers both pre- and post-launch. We built the application. We launched the application. We talked to our peers. They provided feedback. We consumed the feedback, fixed bugs, and began building a roadmap based on the real, emerging user needs. We displaced the old technology. There was fear. There was excitement. There was pain. Our 15 year old application just changed overnight. Everyone now had to learn the new one and fast! This was the first real test of the user experience and it was successful, quirks and all, because users were able to figure out the essentials of their work streams without coaching. We established accessible and open feedback loops so everyone in the company could communicate directly with the product team and let us know their thoughts, both positive and negative. In the end, the scary change was minor turbulence and the outcome was new technology that improved the strength of our operating model and removed barriers to the growth of our internal processes.

By practicing what we preach, we tested our mettle as it relates to our performance philosophies and brand of growth enablement. We experienced all of the same fears as our clients but with expedient, responsible, and effective iteration we enabled growth. If I’ve taken anything away from this experience, it is that the is a legitimate one. It truly is challenging no matter how iteratively you approach it. However, companies tend to allow themselves to be overwhelmed by the obstacles rather than empowered by the possibilities. This project was not without its failures. If we over-analyzed those shortcomings and let fear overcome us, we could have quit. Instead we chose to endure the challenges and learn from our failures, and in doing so we unlocked potential that greatly surpasses the sum of any failures along the way.