How to Succeed at Modernization

Better communication with other technical disciplines may help

Bryon Robidoux February 2023

---

In a previous The Actuary article, “Actuarial Modernization Errors,” I discussed why actuarial modernization efforts sometimes disappoint. In this article, I am going to show you how to overcome the issues addressed in “Actuarial Modernization Errors,” so you can improve your modernization outcomes. Neither the reasons for disappointment nor the solutions I propose are exhaustive, but they show patterns I have witnessed in my experience.

In “Actuarial Modernization Errors,” I described the following potential reasons why actuarial transformation and modernization projects sometimes disappoint:

• As complexities arise within projects, new multidisciplinary teams will have to work together. They will need to find new ways to communicate and collaborate, which means evolving their cultures. Not accounting for this reality can lead to overpromising and underdelivering in my experience.
• Information, knowledge and know-how may become fragmented or lost over time as people migrate. Recovering these items can be exceedingly difficult and time-consuming.
• As a possible byproduct of our lengthy training, actuaries and other highly trained disciplines may overlearn practices, making adaptations to circumstances and technologies challenging.

Addressing Communication in New Multidisciplinary Teams

Different teams, such as software developers, valuation actuaries and risk managers, will have different cultures because they have diverse practices and adaptations to their environments. The idea of “one company, one culture” is a myth.¹ Each team culture has its own language and acronyms to describe common terminology. The reality of different cultures may make it difficult for various technical disciplines to interact, such as the all-too-familiar battles between actuaries and IT developers over the years, as explained in “Excel Is Not the Culprit.” To succeed in transformation and modernization (T&M), people working in different technical disciplines must learn to communicate with one another.

Effective Modeling

A useful book for helping teams in various domains collaborate is Domain-Driven Design. It was written for software architects and developers to work with subject-matter experts, such as actuaries, to build large-scale software solutions. But I would argue that it is not just a software engineering book; it is mainly about modeling, bridging communication between technical disciplines and combining cultures. Domain-Driven Design describes effective modeling ingredients as:²

• Cultivating a language based on the model
• Developing a knowledge-rich model
• Binding the model and the implementation
• Distilling the model
• Brainstorming and experimenting

Cultivating a Language Based on the Model

Cultivating a language based on the model of the problem domain requires team members to create a ubiquitous language the entire team will use uniformly across the project. The team must remove any ambiguous language if it confuses any team members. This process of clarifying language is iterative and ongoing.

All groups must be willing to learn the big-picture concepts of the others’ domains to create the ubiquitous language. No one should need to be an expert, however. For example, software developers and architects must be willing to understand the business domain to appreciate the problems they are trying to solve. But it should be reciprocated by the actuaries’ understanding of how software architects and developers solve problems. Learning cannot be a one-way street. It must be continuous and ongoing. This mutual understanding will allow all the various technical disciplines to contribute to crafting their shared language. This language is the foundation of the culture, just as everywhere else in our lives.

Developing a Knowledge-rich Model

I need to address the word “model” because software developers and architects define it differently than actuaries. A software architect will look at the model as a conceptual representation of the domain space. Each concept is called an abstraction and will have no underlying code. Each abstraction has a responsibility within the domain. A pattern is a group of abstractions that communicate and collaborate to solve a more significant, commonly understood problem through the properties and actions they can perform. The patterns and abstractions allow modelers to quickly share solutions to challenges without being submersed in unimportant minutiae.

For example, various insurance products are patterns for solving different insurance needs. A variable annuity (VA) is a pattern for solving the problem of ensuring lifetime retirement income, which is a liability for the company. The abstractions that make up a VA are policyholder, interest, decrements, benefit bases, account value, separate account and general account. A separate-account abstraction might have properties, such as risk appetite and underlying funds, and an action called calculating fund weights. The abstractions communicate and collaborate to calculate the overall VA liability.

Binding the Model to the Implementation

What actuaries would define as the model is what software developers and architects would consider the implementation. Commercial actuarial software is for implementing actuarial calculations. These are not models because they contain executable code. The distinction between modeling and implementation is fundamentally essential and highly recommended for actuaries to adopt in my view. Neglecting the distinction has actuaries worrying about details too early in the design process, which almost certainly leads to overcomplicated and brittle implementations. Therefore, working through the model and ubiquitous language is vital to avoid implementing anything too soon. Once the language and model are in good shape, implement the code in a self-documenting manner. This allows for a much more rapid and stable development process.

Distilling the Model

The mission-critical activity to effective modeling is that the ubiquitous language, model and implementation must stay synchronized. If any of the three becomes ambiguous or difficult to describe relative to the other two, then everyone must work to resolve the discrepancies. Depending on the situation, this resolution can either mean adding or dropping language concepts, abstractions or implementation code. Resolving issues will be a very iterative process, requiring teams to be nimble and frequently change. Tasks are never genuinely done because they constantly evolve as problems arise, and new solutions are needed based on constant stakeholder feedback. Given the rapid evolution of the modernization effort, the language and model become the folklore of the project team so that the implementation can be clearly explained by everyone. Constantly documenting details in a rapidly changing environment is a significant headwind and very quickly becomes out of date.

Brainstorming and Experimenting

Brainstorming and experimenting are fundamental to this process in a culture geared toward learning. Modernization is an empirical process—a series of experiments where you test a hypothesis, measure the outcome and formulate next steps based on those measurements. A successful team accelerates the pace at which they can experiment—no easy feat. Tasks generally become more complex the bigger they become, especially as people migrate in and out of a project.

Now that we have covered the art of technical team collaboration, I will describe how effective modeling reduces operational risks, such as key-man risk, fragmented knowledge and know-how.

Dealing With Fragmented Information, Knowledge and Know-how Issues

Effective modeling makes knowledge and know-how contagious and generally will efficiently spread them throughout the organization, giving the expertise and know-how their resilience. But to understand why it is important is to understand the various contagions.

Contagions

In Change: How to Make Big Things Happen, Damon Centola describes how information spreads throughout networks so that ideas grow and spread. Regarding networks, there are two types of contagions: simple and complex. The difference is in how the contagions propagate. What people associate with “going viral” are considered simple contagions—for example, gossip, headlines and viruses. Simple contagions spread through simple contact by their reach to weak ties to others in the network.³

Unfortunately, not all contagions are simple. Complex contagions spread through strong ties that require significant personal investment, such as world-historical social and political movements or understanding the complicated language, models and implementation of a modernization project. Any belief or behavior perceived to cause financial, psychological or reputational risk that people try to resist is a complex contagion. The more resistance to the belief or behavior, the more social reinforcement is needed to adopt it and the more complex the contagion becomes.

To better compare contagions, consider Figure 1. Boxes A and C are specific to simple contagions. The firework network comprises several weak connections, creating narrow bridges between a cluster of nodes. Hence, there is little redundancy in network connections between nodes. Boxes B and D are specific to complex contagions. The fishing-net network has robust and redundant links, creating a wide bridge to form many powerful connections. Network geometries have costs and benefits associated with each.

Cost and Benefits of Wide Bridges

Change: How to Make Big Things Happen states that wide bridges start with slow communication because the network’s redundancy causes an echo chamber of ideas with neighboring nodes. They provide safety and security because innovations, behaviors or beliefs are socially accepted.⁴ But once the idea hits its tipping point, the wide bridge causes ideas to gain speed quickly, creating a much more robust and reliable acceptance of the behavior or belief. This snowball effect allows for easy onboarding of new people into the network due to its superior ability to transfer knowledge and better coordination of organizational change. The strong ties of the wide bridge promote trust and intimacy by holding people accountable because the neighbors can apply peer pressure.

Most of all, wide bridges promote organizational stability and sustain the continuity of knowledge transfer over the organization’s lifetime. If a few nodes leave the fishing-net network, the redundancy will make it resilient and fill in the gap. But there is a big catch: Stability comes at a cost because it has a strong propensity to cause overlearning.

Managing the Propensity to Overlearn

Fostering a learning culture is key to preventing stable complex contagions from overlearning. Think Again: The Power of Knowing What You Don’t Know by Adam Grant is an excellent guide for creating such a culture within an organization. A learning culture is more likely to rethink the status quo, where growth is a core value. A learning culture is for people who know what they don’t know, question existing practices and stay curious about new routines to prototype.⁵

For a learning culture to thrive, it is a generally accepted principle that there must be psychological safety to question authority without retribution. Psychological safety is not about lowering standards or going easy; it’s about fostering a climate of trust, respect and openness so people can raise concerns. Beyond psychological safety, there needs to be accountability for rethinking best practices within the organization.

Tragedies, such as the Challenger and Columbia shuttle disasters, occurred when employees were not allowed to question authority in results-driven performance metric cultures. Results-driven performance metrics are a poor method of accountability for learning cultures. Results-driven stable cultures with wide bridges will be locked into their current methods, and social reinforcement will make it nearly impossible to change due to the links becoming very stiff and rigid. This rigidity is the opposite of what transformation and modernization projects need to succeed.

My article, “Improving Strategic Risk Management,” argues that it is just as important for risk management as it is for modernization projects to establish accountability for the judgments taken to achieve results. In my opinion, judgment-based accountability is more challenging than results-driven accountability, but it is more worthwhile because it asks whether the best decisions were made—regardless of the outcome. I think the network will be more socially open to change and adapt. Furthermore, employees may be less likely to fear taking risks and challenging the status quo when their managers show their vulnerability and past errors.⁶ Finding the best answer may trump the traditional power dynamic that produces fear.

Satya Nadella, who writes about the transformation at Microsoft in Hit Refresh, gives much credit to the growth mindset, summarizing that teams need to move from a “know it all” to a “learn it all” culture.⁷ This requires team members to be vulnerable with one another, which creates empathy and trust. Trust is the foundation of any high-functioning team; if you want great results, you need great teams.

Conclusion

Among other things, successful modernization projects include the following:

1. Finding a shared model-centric language for everyone involved.⁸ For transformation and modernization projects to succeed, they need to create their own culture. The prerequisite for a successful culture is to build a shared language with everyone involved. This language connects the internal models of participants to the external model of the problem domain. Effective modeling is driving project implementations through language and models. In my opinion, it greatly accelerates solution development and improves project outcomes while making the projects more robust to change. Furthermore, effective modeling accelerates knowledge transfer and solution development.
2. Creating a complex contagion for ideas to grow.⁹ The power of effective modeling is its ability to construct communication networks that resemble fishing nets. This network geometry creates strong bonds among all the participants in the project, promoting trust, accountability and easier coordination of tasks. Furthermore, it creates organizational stability and accelerates knowledge transfer.¹⁰
3. Establishing a learning culture.¹¹ In my opinion, the performance cultures based strictly on outcomes must be ditched for effective modeling to work correctly and improve transformation and modernization projects. For transformation and modernization projects to succeed, I think the correct move is to take the road less traveled by establishing learning cultures with judgment-based accountability. Learning cultures give people the security, comfort and accountability to question the status quo. This makes effective modeling powerful because clarifying language can challenge current methods. Social reinforcement will allow for methods to be examined, producing more malleable links and creating more resilient and adaptable networks. Even skyscrapers sway in the wind to make them more resilient to changing weather conditions—because they will collapse if built too rigid.

Statements of fact and opinions expressed herein are those of the individual authors and are not necessarily those of the Society of Actuaries or the respective authors’ employers.

Copyright © 2023 by the Society of Actuaries, Chicago, Illinois.