Executive Summary

Insurance agencies, MGAs, and wholesalers today face a stark new reality: technology is never truly “done.” For years, many firms approached core system implementations as one-and-done projects – pour in years of effort, flip the switch, and assume the tech journey is complete. In practice, this mindset has led to stagnation and frustration. Studies show fewer than 30% of digital transformation projects fully succeed in delivering sustained performance improvements insurancethoughtleadership.com. The core problem isn’t the technology itself- it’s the organization’s ability to continuously adapt.

Resilience is emerging as the new competitive advantage for insurance distribution leaders. Resilience is defined here as the ability to absorb continuous change without losing trust. That means change no longer disrupts client service, employee morale, or data integrity. Instead, change becomes an expected part of operations – much like renewals, carrier updates, or regulatory shifts. A resilient agency can onboard new tools, update processes, and respond to market changes repeatedly without lengthy downtime or chaos. This is a fundamentally different mindset from the traditional focus on optimization and efficiency alone. In a resilient model, continuous adaptability matters just as much as quarterly performance metrics.

This white paper outlines five Rules of Resilience that progressive agencies are adopting to thrive amid rapid change. In brief, these rules are:

  • Rule 1: Stop Running Technology as a One-Time Project – Treat technology as a continual business process, not a finite deliverable.
  • Rule 2: Build Rollbacks Before You Build Rules – Design systems and processes with failure in mind, so you can recover quickly and safely.
  • Rule 3: Fix the Core Before You Automate Around It – Strengthen your data foundations and core systems prior to layering on new digital tools.
  • Rule 4: Teach Your Team That Change Is the Job – Create a culture that rewards adaptability and learning, making continuous improvement part of everyone’s role.
  • Rule 5: Measure How Fast You Can Adjust – Not Just How Efficient You Are – Track and prioritize your organization’s adaptability metrics alongside traditional performance metrics.

Each rule is explained with pragmatic examples and backed by industry data. Also included is a self-assessment checklist in the appendix, allowing agency leaders to score their own resilience maturity. Finally, we provide a simple operating model – a Build → Run → Check → Change loop – to operationalize these principles. The goal is to equip agency principals, COOs, and innovation leaders with a clear framework to lead technology in a way that drives agility and long-term growth. Resilience by design means building an organization that’s not only efficient when things are steady, but prepared and proactive when change is constant.

From Optimization to Resilience: A New Tech Leadership Mindset

For most insurance agencies, “modernizing technology” has traditionally meant choosing a new Agency Management System (AMS) or adding a digital tool, implementing it over months or years, and then declaring victory. Leaders often assumed that once the new system went live, they could stabilize operations and enjoy a period of relative technological peace. In reality, that sense of done was an illusion. Business needs keep evolving, vendors release updates, APIs change, carriers adjust their requirements – and suddenly that “finished” system is out of date. Agencies that treated technology as a one-off project found themselves slipping behind or stuck maintaining brittle workarounds.

The key insight is that technology is not a destination – it’s an ongoing operating condition of a business. Just as training your people or growing your client base are never truly finished, your technology environment must continually evolve. Resilience beats optimization in this environment. Of course, efficiency and performance are still crucial; however, the ability to adapt quickly without breaking trust is what separates firms that thrive from those that fall behind. A recent McKinsey survey found that 90% of executives ranked organizational agility as critical for business success going forward mckinsey.com – and in insurance distribution, this agility translates to being able to rapidly adjust processes, tools, and workflows as conditions change.

What does resilience look like in practice? It helps to contrast the legacy approach versus a resilient approach:

  • Legacy mindset: Systems are “set and forget.” Standard operating procedures are rigid, designed to enforce one right way. Change is treated as a disruption or necessary evil, to be minimized. Teams often resist new processes because historically each change tended to create as many problems as it solved.
  • Resilient mindset: Change is expected and even welcomed. Core systems are designed to be modular and easy to update. Processes are revisited regularly (not just during crises) to see if they can be improved. In short, adaptation is business-as-usual, not an anomaly.

An important dimension of resilience is trust. A resilient agency can absorb changes without losing the trust of its key stakeholders – clients, employees, and even the trustworthiness of its own data. For example, clients continue to get reliable service even during a system upgrade; employees trust that new automation will make their jobs better, not threaten them; leadership trusts the data coming out of systems, even as those systems change. This trust is what allows an organization to keep moving fast.“Legacy tech and legacy thinking make resilience impossible by design.” In other words, if your infrastructure is rigid and your culture fears change, your organization has inadvertently designed itself to fail in a dynamic environment. The following sections introduce five rules that can help leaders deliberately re-design their technology approach – and their culture – for resilience.

Rule 1: Stop Running Technology as a One-Time Project

Run It Like You Run the Business

In many agencies, technology initiatives are managed as large, discrete projects: select a system, implement it, roll it out, and then move on to other priorities. Once the system is live, there’s a tendency to declare “Mission Accomplished” and treat the technology as a fixed asset to be protected. The result is familiar – years-long implementations followed by years of avoidance. Staff learn the new system well enough to get by, and then both users and IT hesitate to change anything for fear of disruption. Essentially, the organization puts technology in a glass case marked “Do Not Touch.” This mindset is a major blocker to progress. By the time you finally must touch that system (due to an urgent market or business change), it’s so brittle and outdated that the update is painful, or the opportunity is missed entirely.

A resilient agency runs technology continuously, like it runs the business itself. This means core systems, workflows, and data models are treated as living aspects of the organization that are revisited and iterated on every year (just as you’d revisit your compensation plans, carrier partnerships, or sales strategies annually). Technology management shifts from a one-off project mentality to an ongoing operational function. In practice, this involves:

  • Always in beta: No system is considered “final” or permanently “done.” There is always a next version or improvement in the pipeline.
  • Ownership beyond go-live: Every platform or major tool has an accountable owner after implementation – someone responsible for continuously improving it, monitoring its usage, and ensuring it delivers value as conditions change.
  • Budget for iteration: The agency allocates budget not just for initial deployment, but for ongoing enhancements, user training, integrations, and updates. Smaller, more frequent improvements can replace massive overhaul projects.

When technology is managed in this iterative way, it stays aligned with the business over time. The organization is continually making small adjustments – adding a new data field here, automating a step there, refining a workflow after getting employee feedback – rather than letting the systems ossify. This approach also helps avoid the trap of big bang projects that overrun and under-deliver. Notably, research by Oxford/McKinsey has shown that large traditional IT projects typically run 45% over budget and 7% over time, while delivering 56% less value than promised mckinsey.com. It’s no wonder so many “transformations” disappoint – the plan itself was static and overly grandiose.

On average, large IT projects run 45% over budget and deliver 56% less value than expected.mckinsey.com

Resilient technology leadership means accepting that there will never be a finish line. Instead of trying to finish technology, the goal is to build an organizational muscle for continually adjusting technology. Leaders can start by asking a simple question about any critical system: “Who is in charge of making this system better next year?” If there’s no clear answer, that is a red flag that the system is being treated as a one-time effort rather than an ongoing responsibility. Going forward, ensure every important platform has a “product owner” or steward, and treat enhancements as part of the yearly business plan. In short, bake technology evolution into your operating rhythm.

Rule 2: Build Rollbacks Before You Build Rules

Protect People from System Mistakes

Traditionally, agencies manage change by creating strict rules and Standard Operating Procedures (SOPs) to prevent any and all errors. If a new system is introduced, leadership might bombard staff with rules: double-check every input, follow the exact steps, don’t deviate. When something does go wrong, the tendency is to blame the people – “user error” becomes the go-to explanation for process failures. In a legacy culture, mistakes often lead to finger-pointing or even punishment. This creates an atmosphere of fear around technology. Employees become afraid to experiment or even to use new features, lest they get something wrong and get reprimanded. The irony is that in trying to rule out every mistake, the organization becomes more fragile: when an error inevitably slips through, it causes panic because no safety net was built.

A resilient agency, by contrast, designs its operations with the expectation that things will occasionally go wrong – and that’s okay. Instead of only building rules to stop errors, resilient teams also build rollbacks and failsafes to minimize the damage when an error occurs. The philosophy is “let’s make it easy to recover, so that trying new things isn’t so scary.” Here’s what this looks like in practice:

  • Plan for reversal: When implementing a new automation, integration, or rating logic, the team also plans how they could quickly turn it off or revert to the previous state if it produces bad results. For example, if a new quote processing script starts creating incorrect quotes, can it be disabled with one switch?
  • Rehearse the fallback: Teams are trained on how to respond if a process or system change needs to be rolled back. There is a clear, drama-free procedure for undoing changes without blaming individuals. This might mean having a sandbox environment to test changes or scheduling major updates at low-impact times with a rollback window.
  • Blameless post-mortems: When mistakes happen, the focus is on learning and improving the system – not on punishing the person who happened to be on duty. Errors and near-misses are treated as valuable feedback. The question asked is, “How did our process allow this mistake, and how can we adjust the process or system to prevent it or catch it faster?”

By making failure recovery part of the design, you actually encourage innovation and adaptability. Employees know that if a change causes an issue on Friday at 4 PM, it can be swiftly undone without career-threatening fallout. This psychological safety is crucial. In fact, research has shown that teams with high psychological safety – where members feel safe admitting mistakes and speaking up – have significantly lower turnover (up to 27% lower) and higher productivity (+12%) blog.insights.com. People move faster and handle change better when they aren’t operating under constant fear.

Gallup finds that teams who feel their opinions and mistakes are welcomed see 27% lower turnover and 12% higher productivity.blog.insights.com

For agency leaders, Rule 2 means baking in the question “How could this go wrong?” whenever you introduce a change – and having an answer ready. Before rolling out a new software module or workflow, identify points of potential failure and establish how you would roll back or mitigate if those failures occurred. Empower your ops and IT teams to create “kill switches” for new automations. And culturally, signal to the organization that discovering a flaw in a new system is not an occasion for blame, but an expected step in making the system better. When people see that systems absorb the mistakes (because they can be quickly fixed or reversed), they feel safe to try new approaches. Over time, this creates a fearless, innovative culture that can adapt systems in hours or days instead of avoiding changes for months.

Rule 3: Fix the Core Before You Automate Around It

Clean Data Beats Clever Tools

In recent years, the insurance industry has been flooded with shiny new tech tools – AI-driven analytics, robotic process automation (RPA) bots, customer engagement apps, and so on. Many agencies have layered these on top of their existing systems in hopes of leapfrogging ahead. But layering fancy tools over a broken foundation is a recipe for frustration. Imagine adding a state-of-the-art smart thermostat and security system to a house with a cracked foundation and faulty wiring – you won’t get the benefits you expect, because the basics aren’t in place. Likewise, agencies that pile CRM software, AI chatbots, and reporting dashboards on top of disjointed policy admin systems and siloed databases often end up with more complexity and manual workarounds. Employees spend time reconciling data between systems or downloading spreadsheets to bridge gaps. The “intelligent” tools fail to deliver insights because the underlying data is incomplete or inconsistent.

Resilient agencies take a disciplined approach: strengthen the core systems and data architecture first, before aggressively automating and adding layers. The core includes your primary record-keeping systems (e.g. AMS, policy/billing systems, accounting) and the data model that ties them together (e.g. consistent client, policy, and financial data across systems). If this foundation is solid – data flows cleanly, systems integrate well, there is one source of truth for key information – then any new tool you introduce can immediately leverage reliable data and fit into unified workflows. If the foundation is shaky, new tools will only amplify the cracks. As one industry maxim puts it: “Garbage in, garbage out.”

Concretely, focusing on core before more looks like this:

  • Single source of truth: Consolidate and clean up your data so that everyone – and every new application – draws from the same well. For instance, ensure that your agency has one master repository for client information, policy details, and commission data, rather than several spreadsheets and databases that need reconciliation. This might involve data migration or integration projects, but it pays off in reduced errors and duplication.
  • Eliminate re-keying: Identify points where staff are manually re-entering data from one system into another (for example, retyping information from the AMS into an accounting system, or from carrier portals into your system). Prioritize integrating those systems or using upload/download features to stop the copy-paste madness. Not only does this save time, it also improves accuracy. Industry benchmarks show that underwriting and ops teams currently spend up to 40% of their time re-keying data between systemsinaza.com – a huge efficiency drain that adds zero value.

Underwriting operations teams spend up to 40% of their time re-keying data between systems.inaza.com

  • Real-time, reliable reporting: Invest in reporting tools or data warehouses that pull directly from core systems so that reports reflect the current state of the business, not data that’s weeks old or manually compiled. When a carrier or regulator asks for figures, you should be able to generate them confidently from your system-of-record, not scramble through Excel sheets. Clean, up-to-date data builds internal and external trust.

Agencies that do this hard work on core systems find that many downstream benefits follow naturally. They can plug in an AI tool and actually trust it to make recommendations, because the AI is drawing from clean and complete data. They can automate renewal workflows end-to-end, because all the systems in the chain are speaking the same language. They spend far less time on “information janitorial” tasks and more on analysis and service. It’s worth noting that 61% of digital projects fail or get canceled because the new apps couldn’t get the right data insurancethoughtleadership.com – underscoring how data integration is often the make-or-break factor.

61% of digital projects are canceled because a new solution couldn’t access the needed data.insurancethoughtleadership.com

To apply Rule 3, take inventory of your core. How confident are you in the accuracy and accessibility of your agency’s key data? Do you have multiple systems doing overlapping jobs (and inconsistently), where one solid system would do? Before chasing the latest automation tool, strengthen those weak links. Unsexy as it may sound, a well-implemented single source of truth or a cleaned-up database can unlock more value than the fanciest AI platform running on bad data. Clean data and a connected core create a platform on which all future improvements can stand solidly.

Rule 4: Teach Your Team That Change Is the Job

Change Isn’t a Disruption – It’s Business as Usual

Even when the technology is ready to change, the people in the organization may not be. In many agencies, employees have been through one or two painful system changes in the past and have consequently developed a reflexive dread of new initiatives. It’s common to hear groans of “Another new system? What’s wrong with the old way?” when a change is announced. In a traditional culture, change is implicitly framed as something going wrong – we only change when we’ve messed up or when something failed. No wonder people brace themselves and resist; change feels like a chaotic detour from their “real work.”

Resilient agencies deliberately reshape this narrative. They set the expectation from the top down that part of everyone’s real job is to continuously improve how the work gets done. Adapting systems and processes isn’t a distraction or a necessary evil – it is the work. This requires a shift in how leaders communicate, how teams are trained, and how performance is evaluated:

  • Normalize continuous updates: Leadership regularly communicates updates to tools or processes as a positive sign of progress, not an admission of past failure. For example, “This quarter we’re updating our client onboarding workflow to make it faster – here’s what’s changing…” becomes a routine message. Frequent, smaller changes are easier for teams to absorb and help eradicate the notion that change signals a crisis.
  • Ongoing training and support: Rather than one-off big training sessions only when a new system launches, resilient organizations embed continuous learning. They provide e-learning modules, peer mentors, or regular refresher clinics so employees are constantly getting more comfortable with evolving tools. Change is not a single event with a two-week training bootcamp; it’s a continuous learning process. This approach also uncovers power users and change champions at all levels.
  • Reward adaptability: Update performance reviews and incentives to include recognition for learning new skills, embracing new processes, and helping others through changes. When employees see that adapting is literally part of how they’re measured (“What did you improve or learn this year?”), they internalize that staying static is not the expectation. As an example, some agencies add objectives like “Participate in at least two new tool pilot programs” or “Propose one process improvement” in annual goals.

The cultural payoff is huge when people truly internalize that change is normal. The fear and eye-rolling diminish. Instead of clinging to an old workflow out of habit, teams become more open to experimenting because they assume there’s likely a better way. Mistakes made during change are met with patience (tying back to Rule 2’s safety net) and successes are celebrated. This environment is what drives continuous innovation. In fact, one of the top reasons that 70% of large change programs fail is employee resistance and change fatiguemckinsey.com. Reducing that resistance by making change less intimidating can dramatically improve your odds of success whenever you roll out improvements.

Around 70% of organizational change programs fail to achieve their goals – largely due to employee resistance and lack of management support.mckinsey.com

For leaders, Rule 4 is a reminder that technology change is also people change. Even the best new system will falter if the users are unprepared or unwilling. Thus, invest in the human side: communicate the “why” of changes, train continuously, and encourage a growth mindset at all levels. Importantly, lead by example – when your team sees leadership actively learning new tools, asking for feedback on processes, and not panicking when hiccups occur, it reinforces the message. Over time, the organization’s default response shifts from “Oh no, a change is coming” to “Ok, what are we improving next?” When your people expect change and even demand it, your transformation is truly resilient.

Rule 5: Measure How Fast You Can Adjust – Not Just How Efficient You Are

Adaptability Is a Key Metric

Insurance agencies have no shortage of metrics. Most track sales closing ratios, policy retention, average handling time, expense ratios, revenue per producer, and so on. These efficiency and performance metrics are important – they reveal how well the current operation is running. However, they don’t directly tell you how well you handle change. An agency might hit all its KPIs in a stable year, yet completely stumble when a major market shift occurs or a new technology emerges. In resilient organizations, leaders devote as much attention to adaptability metrics as they do to efficiency metrics.

What do adaptability metrics look like in an agency context? Essentially, they measure the organization’s response time and change effectiveness. For example:

  • Speed of process change: How long does it take to update an internal workflow when an external change happens (like a carrier introduces a new underwriting rule or a state passes a new regulation)? If a new carrier guideline is issued, do your processes reflect it in a week, a month, or a year? Tracking this gives you a sense of organizational agility.
  • Frequency of updates: How often are you deploying updates to your systems or processes? Is it once a year, or on a continuous quarterly or monthly basis? More frequent, smaller updates correlate with higher resilience, whereas infrequent big-bang changes can be a warning sign.
  • Time to detect and fix errors: When something goes wrong – say a batch of policies is processed incorrectly – how quickly is it noticed and corrected? Measuring the lag from issue occurrence to identification to resolution can indicate the robustness of your monitoring and feedback loops.
  • Cross-training and skill development: On the people side, you might track what percentage of your team has been cross-trained on new tools, or how many training hours are spent on new capabilities. A workforce with broad skills and up-to-date training is more adaptable.

The idea is to quantify the capacity to adapt. Some leading organizations even create a “resilience scorecard” to sit alongside their financial scorecards. It might include metrics like those above, or survey-based metrics such as “employee confidence in handling new technology” or “customer satisfaction during change events.” The exact metrics will vary, but the act of measuring sends a powerful signal internally: moving fast and safely is a priority.

This data-driven approach to adaptability is validated by industry research. Leaders widely acknowledge agility as crucial to success – nearly nine in ten executives say organizational agility is vitalmckinsey.com – and those who manage to embed agility see concrete benefits like faster time to market and higher customer satisfactionmckinsey.com. By measuring and managing adaptability, agencies can join those ranks.

In practice, incorporating Rule 5 might start with one simple addition: the next time you review operations in a leadership meeting, include a discussion of how quickly the last major change was implemented. For instance, “It took us three months to roll out the new endorsement process change required by Carrier X – was that good enough? How could we do it in one month next time?” Over time, build targets around these kinds of questions. Perhaps set a goal that any regulatory change should be reflected in agency processes within 30 days, or that any critical system bug is patched within 48 hours. These targets will be as important to your future success as your sales targets, because in a turbulent market, the durable advantage lies with the most nimble.

The Tech Stack of the Future: From Fragile Systems to Flexible Ecosystems

While the five rules above focus on behaviors and practices, true resilience also requires a supportive technology architecture. Many agencies today operate on a legacy tech stack that is fragile and slow. A typical setup might involve an AMS, a CRM, a policy rating tool, an accounting system, a claims system, perhaps a separate document management system – each one often a silo with its own database. Integrations are sparse or handled through nightly batch processes and Excel imports. Adding a new application (like a client portal or analytics tool) means yet another silo unless a custom integration is built. This kind of patchwork stack is not only costly to maintain, it also resists change. Every alteration or new integration can break something else, so improvements are delayed or avoided.

The resilient approach is to design a stack that is interchangeable and fast – essentially a flexible ecosystem of technology where components can be added, removed, or upgraded with minimal disruption. Think of it as moving from a tangled spaghetti of point-to-point connections to a more modular platform architecture. Key characteristics of a future-proof, resilient tech stack include:

  • A central data hub (single source of truth): At the heart of the stack is a robust data store or data warehouse that consolidates core business data. All applications read/write from this hub, ensuring consistency. This could be enabled by modern API-driven core systems or an integration platform that syncs data in real-time. With a central data backbone, any new tool plugged into the stack has instant access to the information it needs (and can contribute back updates).
  • An “Operating System” for the agency: Just as a computer’s OS coordinates between hardware and software, an agency needs a layer (often called a workflow or orchestration layer) that coordinates processes across systems. This might be a BPM (business process management) tool or simply a well-designed integration architecture. The idea is that you map out key workflows (e.g., new business submission, policy renewal, claim reporting) and the orchestration layer ensures data and tasks flow to the right system at the right time. If one component is swapped out (say you replace your CRM), the orchestration can adjust without everything breaking.
  • Modular business capabilities: Functions like e-signature, payment processing, document generation, communications, etc., are provided by modular services that can be updated independently. In a legacy stack, these might all be features inside one monolithic AMS that only gets major updates every few years. In a resilient stack, you might use a separate best-in-class e-sign provider, a separate client portal module, etc., each connected via APIs. The benefit is you can upgrade or change one service (e.g., switch to a new payment platform) without overhauling the entire system. The trade-off is you need solid integration and vendor management, but it pays dividends in flexibility.
  • Intelligence layer: On top of the solid core data and workflow layers, you can have an analytics/AI layer that consumes data and provides insights or automation. Importantly, this layer is last – meaning you ensure data quality and process clarity before relying on AI. When ready, AI can be plugged in to do things like recommend coverages, flag unusual claims, or automate routine communications. And because your underlying data is clean and unified (Rule 3’s work), the AI’s outputs are reliable. If a new machine learning tool comes out that’s better, you can integrate it relatively easily, because it just needs to tap into the existing data and workflow plumbing.

In a Legacy vs. Resilient Stack comparison, the difference is clear. The legacy stack is like a Jenga tower: tightly coupled pieces that, when you remove or change one, the whole structure wobbles. The resilient stack is like Lego blocks on a solid base: each piece has defined connectors and can be replaced or rebuilt without collapsing the whole. This is easier said than done, of course. It requires upfront investment in architecture and likely picking technology partners that embrace openness and interoperability. But it directly supports resilience – if tomorrow a new InsurTech solution offers a great service, a modular stack lets you plug it in quickly. If a component fails, you can swap it out without downtime.

Moving toward this future stack does not necessarily mean ripping everything out at once. It can be done incrementally: start by establishing an integration layer or central data repository, connect one system at a time to it, gradually decouple functions from monolithic systems, and replace them with services. The end state is an IT environment that actually facilitates change. When your tech stack is resilient by design, the organization can introduce new capabilities or make process tweaks rapidly, because the underlying architecture supports agility.

Operating in a Continuous Loop: Build → Run → Check → Change

One practical question remains: How do we institutionalize these rules and make resilience part of everyday operations? It helps to have a simple operating model that teams can follow. We propose thinking of resilience as an ongoing loop with four stages: Build → Run → Check → Change, repeating perpetually. This loop is analogous to continuous improvement cycles (like Deming’s Plan-Do-Check-Act) but tailored for tech and process management in an agency.

  1. Build: This is the stage of implementing something new or different. It could be deploying a new software tool, building a new workflow, or making a configuration change in a system. The key is to do this in a manageable increment – something small enough that it can be accomplished relatively quickly (remember, no multi-year “big bang” projects if possible). “Build” might also involve pilot programs or prototypes rather than full deployments at first. Under Rule 1, you’re always building with the expectation of future iterations, so you build flexibly.
  2. Run: Once the change is in place, you operate with it. Users start using the new process or system in their day-to-day work. This is where you stabilize the change, but not freeze it. Think of it as the “live” period where you gather experience. It’s important in this stage to communicate to everyone: “We’re in run mode, but this isn’t the end – we expect to learn and adjust.”
  3. Check: In this critical stage, you monitor and evaluate how the change is performing. Are there errors or issues (and do you catch them quickly)? Are the intended benefits materializing (e.g., time saved, accuracy improved)? Solicit feedback from users: what’s working, what isn’t? This ties closely with Rule 5 – you should have metrics or at least observations that let you gauge the impact and any emergent problems. The “Check” step ensures that you don’t simply set and forget; you actively look for signals that adaptation is needed.
  4. Change (again): Based on what you learned in the Check stage, you implement adjustments. Maybe a training issue became apparent and you schedule refreshers (change to process), or maybe the new software needs a configuration tweak or even a different vendor (change the tool). This flows directly back into Build – implementing the next iteration. The loop begins anew, continuously.

Importantly, this Build → Run → Check → Change loop is meant to be a permanent operating model, not a one-time project plan. It instills a cadence of regular improvement. Some agencies formalize this by having quarterly “change sprints” – periods where they plan and execute a batch of improvements (Build), roll them out (Run), review outcomes (Check), and decide on further tweaks (Change). Others embed it into existing meetings: for instance, a monthly ops review always covers any new changes and follows up on past ones (Check), then assigns next adjustments (Change/Build).

Following this loop makes the five resilience rules actionable. For example, Rule 2 (build rollbacks) fits in the Build stage – you plan the rollback as you build. Rule 4 (team expects change) is reinforced by the very existence of the loop – people know to anticipate the Check and Change steps regularly. Over time, this loop becomes part of the organization’s DNA. It also has a psychological effect: when everyone knows that change is scheduled and expected, it removes some of the anxiety of the unknown. Change isn’t something that sneaks up – it’s on the calendar.

Conclusion: Designed to Evolve

Technology will never be “finished.” Neither will your processes, your people’s skill sets, or the market conditions you operate in. Acknowledge this reality can either be daunting or empowering, depending on your approach. Resilience by design is about choosing the empowering path: deliberately building an organization that thrives on change rather than fights it. The five rules outlined – from treating tech as a continuous journey, to building safe failsafes, strengthening the core, nurturing a change-embracing culture, and tracking adaptability – all coalesce into a model of an agency that is not only efficient in steady times but also agile when turbulence hits.

As a leader, you have a strategic choice to make. You can keep protecting systems built for yesterday – patching, defending, and hesitating to change – or you can build an organization designed to evolve. The latter requires effort and mindset shift, but it ensures that external change will no longer dictate your fate. Instead, you’ll respond on your own terms, quickly and confidently.

The rewards for building such resilience are significant. You’ll find your team more engaged and proactive, because they feel prepared rather than fearful. You’ll see opportunities in market shifts (like new insurance products, customer expectations, or tech innovations) where others see threats. You’ll gain trust from your carriers and clients as a partner who can adapt to new demands without missing a beat. In short, resilience turns change into a competitive advantage.

If this vision resonates – if you’re ready to stop fighting change and start building for it – consider taking the next step for your organization. We invite you to have a conversation about how to put these principles into practice in your agency’s unique context. Irys is working with forward-thinking agencies to implement the resilient tech stack and operating models described here, and we’d be happy to share live examples and lessons learned. Schedule a conversation with our team to explore how you can design your agency to not only withstand the future, but to thrive in it.

Appendix: Resilience Self-Assessment Checklist

How resilient is your agency today? Use the following checklist to evaluate your current maturity across the five rules of resilience. For each statement, mark ✓ (yes) if it is true for your organization. This can help identify areas of strength and areas needing improvement.

Rule 1 – Technology as a Continuous Process (Not One-Time Project)

  • We have clear owners assigned to every core system after implementation, responsible for ongoing improvements.
  • We allocate budget each year specifically for system enhancements and process upgrades (beyond just maintenance or initial project costs).
  • No major system or workflow in our agency is considered “permanent” or off-limits to change – we review and update our tools and processes at least annually.

Rule 2 – Built-In Rollbacks and Safeguards

  • For any significant change (new software, automation, etc.), we have a plan in place to quickly undo or disable it if it causes problems.
  • Team members know exactly how to report issues and revert to the old process if something goes wrong – without needing emergency heroics or blaming individuals.
  • When errors or failures happen due to a change, we treat them as learning opportunities and adjust the system/process, rather than default to disciplining staff.

Rule 3 – Strong Core Systems and Data Foundation

  • We maintain a single source of truth for key data (clients, policies, finances), rather than having conflicting information in multiple systems.
  • We have minimized or eliminated manual re-entry of data between different systems (AMS, CRM, accounting, carrier portals, etc.).
  • Our reports and dashboards reflect up-to-date data (no significant lag or manual data massaging needed), and we trust the accuracy of the data.
  • We would feel confident allowing an automation or AI tool to act on our data – meaning our data quality and integration are sufficiently reliable.

Rule 4 – Culture of Continuous Change and Learning

  • Regular changes or updates to workflows, software, or policies are expected and met with a “can do” attitude by our team (rather than resistance or dread).
  • We provide ongoing training and support for new tools and process changes – not just one-off training sessions, but continuous learning opportunities.
  • Adaptability and improvement are part of our performance evaluations or recognition programs (e.g., we praise employees who find better ways to work or who learn new skills).
  • When a change is introduced, our employees generally feel safe voicing concerns or feedback, and they trust that leadership will support them through the transition.

Rule 5 – Adaptability Metrics and Improvement

  • We track how quickly we implement required changes (e.g. carrier rule changes, new compliance requirements) and strive to shorten that time.
  • We measure how rapidly we detect and fix process or system issues (e.g., errors, outages) and have targets to improve this “time to recovery.”
  • Our leadership discussions include reviewing recent changes and our organization’s response to them – not just business-as-usual metrics.

We have a clear idea of our organization’s capacity for change (such as how much change we can absorb in a quarter) and we plan our initiatives to avoid overloading the team.

Scoring: There’s no hard score that defines “resilient” versus “not,” but generally if you checked most of the boxes under a rule, that’s a strength for your agency. If you left many unchecked, that rule represents an opportunity for growth. Review the rules where you have gaps and consider actions – drawn from this white paper – to elevate your resilience in those areas. The goal is not a perfect score, but an honest baseline and a direction for continuous improvement. Each step you take will help ensure your agency is ready for whatever comes next.