25 Strategies for Maintaining Team Performance During Periods of Change or Disruption

The most effective strategy I have used to keep a team performing through disruption is over communicating the "why" before asking for more effort. When we went through a rate environment shift and had to raise prices on our handwritten mail service, I did not just send a memo. I personally wrote handwritten notes to our top accounts explaining the change and locked their old rate for 90 days, and I explained to my own team exactly why that mattered before asking them to execute it under pressure.
That transparency did two things. It kept the team from guessing about the company's stability, which is where anxiety and slowdowns usually start. And it modeled the behavior I wanted from them toward customers: honesty first, softened by a concrete gesture, not just a policy change dropped on people.
To prepare the team to be resilient, I lean on pairing. When we bring someone new into a high pressure role, we pair them with a senior person for the first week so they are never solving a hard problem completely alone. That same structure holds during disruption. Nobody carries uncertainty by themselves.
Communicate the reason, pair people up, and resilience follows naturally.
Rick Elmore, Founder/CEO, Simply Noted (simplynoted.com)

When Google drops a major algorithm update or AI reshapes how clients find legal services overnight, panic is the enemy of performance. I've lived through enough of these moments to know that the teams who thrive aren't the ones with the best reaction plan. They're the ones who never stopped preparing.

My most effective strategy has always been radical transparency combined with continuous learning. When disruption hits, I don't sugarcoat what's happening. I tell my team exactly what changed, what we know, what we don't know, and what we're doing about it. People perform better when they feel like trusted adults rather than employees who need to be managed through bad news. But the real resilience work happens before the disruption. We built a culture where staying current wasn't optional.

Weekly internal discussions about industry shifts, AI developments, search trends specific to legal marketing. Everyone on the team was expected to bring something to the table, not just absorb information from leadership. I also made sure people owned their domains deeply. When someone has genuine expertise and confidence in their specialty, change feels like a challenge rather than a threat. A team member who truly understands technical SEO doesn't fall apart when Google changes how it evaluates content. They adapt faster because they understand the underlying principles, not just the tactics.

Another thing that made a real difference was celebrating smart pivots. When someone adjusted their approach based on new data and it worked, we talked about it. That reinforced that changing direction isn't failure. It's exactly what we want. Disruption exposes weak foundations fast. The answer is building strong ones before you need them. Strong communication, deep expertise, and a culture that treats learning as a competitive advantage rather than an inconvenience. That's what keeps a team performing when everything around them is shifting.

My most reliable change strategy is to run the new process on old work before it touches a live client. A professional-services team tested an AI proposal workflow on five historical calls, then kept senior review on every live proposal while the wording took four iterations to sound like them. Turnaround fell from 8.5 to 2.8 hours, acceptance rose from 41 to 47 percent and monthly capacity increased from 3.2 to 5.8 proposals. Rehearsal protected performance while the team learned.

We prepared the team for resilience by making change a normal part of how we worked before challenges appeared. Too many leaders treat resilience as something to discuss only during difficult times. We built it through regular habits instead of waiting for problems to force change. We reviewed possible setbacks together and discussed what could be simplified, what had to continue, and how each team would respond.
When disruption arrived, our team stayed focused because we had already practiced adapting to change. We did not have to create a response under pressure because we already had a clear plan. We had backup owners, simple routines, and shared expectations for strong execution. Resilience became less about toughness and more about preparation, which helped us recover faster and keep moving forward.

Being a leader and guiding teams through organizational disruptions for 14 years, the method of maintaining performance was always over-communication of certainties that did exist, even if the rest remained unclear. In one big reorganization event, instead of the usual empty promises, I held weekly 15-minute meetings, stating clearly what was confirmed, what was yet to be decided and when the next meeting would be, so that people didn't confuse absence of information with negative information.
Another step was the building of resilience beforehand, cross-training the team in 2-3 areas of skills that could overlap each other, which ensured that uncertainty on the part of any individual didn't disrupt the productivity of the whole team. During the period of disruption, the productivity decreased by 8%, while in the same situation two years ago without such preparations, the department's productivity was reduced by 30%.

My team went through a brutal stretch where we had to rebuild two core products at the same time while still shipping weekly content. I pulled everyone into a single 15-minute standup each morning with one rule. You only talk about what's blocked, and you name who can unblock it. That compressed our decision cycle from days to hours because problems surfaced before they compounded.
The second thing I did was shrink everyone's scope temporarily. I asked each person to own one output per week instead of three. Output quality held steady and nobody burned out mid-project. We tracked completion rates in a shared doc, and they held up during the disruption because people had clarity on what finished looked like.
When the dust settled, those morning standups never went away. I had removed the ambiguity about priorities and shortened the feedback loops so nobody sat frozen waiting for direction, and we came out of it with a faster operating rhythm than we had going in.

The uncomfortable thing I learned is that you can't build resilience during the disruption. By then it's too late. Resilience is a savings account: you fund it in the calm and spend it in the storm. And the currency isn't motivational speeches. It's slack.
A team run at 100% utilization in good times looks efficient and is secretly fragile. There's no give in it, so the first real shock—a key person leaves, a plan blows up, priorities flip overnight—cracks it, because every hour was already spoken for. The team that kept even 10-15% unallocated absorbs the same hit and bends instead of snapping. That "wasted" capacity was never waste. It was the shock absorber. Chasing maximum efficiency in the good months is quietly manufacturing brittleness for the bad ones.
The other thing that prepared our team, oddly, was changing things on purpose while the stakes were low: swapping a tool, reshuffling who owns what, small stuff. It gives people a callus. When a big disruption hits, change itself isn't the scary, foreign part, because they've done change a hundred times. It's just a larger version of something familiar.
And in the moment, the steadying move isn't flooding people with updates about what's shifting. It's naming, plainly, what's not. In a storm, people can't hold much novelty. A short list of the fixed points does more than any pep talk.

The most disruptive stretch for us was scaling the team across three countries (Morocco, Dubai, and the US) inside about a year, while client work never paused for the transition. What kept performance steady was over-communicating the reasoning behind every change before announcing it, instead of only announcing the change itself.

Before we split the team into pods by service line instead of by client, I held individual conversations with every team lead explaining exactly what was changing and why, before the team-wide announcement. That gave each lead time to process their own concerns privately instead of reacting in front of the group, and they became the ones defending the change to their own teams instead of me having to.

We also protected one thing through every reorganization: our weekly client deliverable schedule never moved, no matter what was happening internally. That gave the team a fixed point of stability to work toward while everything else was in flux. Resilience wasn't about pep talks, it was removing ambiguity early and keeping one thing constant while everything else changed around it.

I fired my entire management team six months before selling my fulfillment company, and it was the best decision I ever made for team performance.

Here's what happened. We were scaling fast, hitting $10M ARR, and my original leadership team couldn't grow with us. I had a choice: protect their feelings or protect the 100+ employees counting on us to execute. I chose the latter. The strategy wasn't complicated, but it required brutal honesty.

First, I stopped pretending everything was fine. When we moved from that vacant morgue into a proper 140,000 sq ft facility, I gathered everyone and said we're building something different now, and not everyone from the early days will make it to the finish line. That transparency killed the rumor mill. People knew change was coming, so when it did, they weren't blindsided.

Second, I promoted from within aggressively. Three warehouse associates became shift managers during our biggest growth phase. They already understood our culture and had earned trust on the floor. External hires take six months to ramp up. We didn't have six months.

The real secret? I never asked people to be resilient. I just removed obstacles so they could do their jobs. When carrier delays started crushing our SLAs, I didn't send a motivational email about grit. I renegotiated contracts and brought in two backup carriers within 72 hours. Resilience isn't a personality trait you inspire through speeches. It's what happens when people trust you're solving problems faster than new ones appear.

During the exit process, I kept the team in the loop every step. They knew we were in conversations months before the deal closed. When acquisition rumors create uncertainty, performance tanks. Transparency maintains it.

The lesson I carried into building Fulfill.com: change doesn't break teams, uncertainty does. Give people the truth and the tools, then get out of their way.

The approach that's worked best for me during disruption isn't really a strategy. It's talking to people before they have to come ask.

Here's the pattern I've seen play out on team after team. Something shifts, a reorg, a lost contract, a change at the top, anything that signals things aren't steady. The instinct at the top is to go quiet until there's something solid to say. It feels responsible. No half-answers, no false starts, just wait until you know. But the team doesn't experience that as care. They experience it as absence. And people don't sit still in an absence. They fill it, usually with the worst version of the story. Work doesn't slow down because the disruption itself is that damaging. It slows down because people are spending their energy guessing instead of doing their jobs.

I've been on both sides of that gap, the one waiting for word from above, and the one leading through it. Neither is comfortable. Only one of them is something I can actually control.

During one of the harder stretches I led, I started sending short updates on a fixed schedule, every Friday, whether or not there was real news. Sometimes it was three lines: here's what's happening, here's what isn't decided yet, here's when you'll hear from me again. No polish. No reassurance for the sake of it. Just what was true, as of that day. That was enough. People weren't looking for certainty. They were looking for someone steady enough to tell them the truth as it unfolded.

It cost me almost nothing to send those updates. Ten minutes, once a week. But I watched the guessing drop off within a few weeks. People stopped pulling each other aside to speculate and started asking me directly instead, which is exactly where I wanted those conversations to happen.

Resilience doesn't get built in the crisis. It gets built in the ordinary weeks before it, small commitments kept, over and over, until people trust that you show up even when nothing's on fire. That's what they draw on when something finally is. It's the difference between a team that freezes and one that keeps moving.

None of this takes a communications plan. It takes deciding, ahead of time, that silence is never the safer choice.

What would change if your team heard from you before they had to ask?

Something that I have found to be really helpful is lightening the load of responsibilities and tasks for my team. If we're heading into a period of change or disruption, or even just a really tough project, I'll take a look at all of the things my team is currently doing. I'll assess which responsibilities can be temporarily paused, what tasks can be pushed back or eliminated, and often I'll try to see if there is anything that I personally can take on in the meantime. Going through change or disruption can be stressful, not to mention it just simply adds more to your team's plate. As their leader, I know that I can make a positive impact here and make things easier for them so that they can focus the energy they have toward dealing with the particular period of time.

When we made significant corporate policy changes across all of our support infrastructure, we were able to maintain performance with small, 30-day phased milestones. Large organizational changes typically create so much chaos and overwhelm the employees that it will cause their productivity to drop. Pre-implementation training was conducted for our administration staff to help them prepare for the potential disruption associated with this type of rollout. Each workshop had clear expectations for what would occur in each phase. The teams focused solely on learning one specific function during each phase prior to starting another phase. Breaking down the disruption of a large change into smaller, predictable phases allowed us to keep the workload consistent while allowing the teams to build confidence as they achieved each incremental win.

The most effective approach for us at Wanderlust Wine has been to reduce uncertainty about priorities, even when we cannot remove uncertainty from the situation itself. During periods of change, I try to narrow the team's focus to the few outcomes that genuinely matter and make ownership very explicit. We also shorten the feedback cycle, so instead of committing to a plan and reviewing it weeks later, we check assumptions and operational pressure points much more frequently. That prevents people from wasting energy on work that has already become less important.

For me, resilience is less about asking a team to become comfortable with disruption and more about giving them a reliable way to operate through it. We try to build that before a difficult period by documenting critical processes, avoiding unnecessary single points of dependency, and giving people enough context to make sensible decisions without waiting for approval on every detail. The result is a team that can adjust quickly while still knowing what should remain stable: customer experience, quality of execution, and the commercial priorities of the business.

The strategy that worked best was making performance visible in a way that encouraged stability, not pressure. During disruption, broad motivation messages rarely help because teams need proof that progress is still measurable. I introduced narrower health indicators around handoff speed, revision rates, and response consistency rather than only top line output. That helped managers spot where change was creating friction before it turned into missed commitments or quality drift.
Preparation focused on relationship discipline inside the organization. Teams were encouraged to escalate early, ask for context, and surface small blockers without worrying about hierarchy. That sounds simple, but in scaled environments silence is expensive. Resilience improves when people trust the process enough to report strain while the problem is still manageable.

My most effective strategy was to reduce uncertainty before asking the team to increase speed.
During a major e-commerce system change, payment, order and fulfillment records stopped matching correctly. Some unpaid orders were shipped, legitimate paid orders were delayed, and normal sales activity nearly stopped.
We stabilized the operation by identifying the few processes that could not fail: confirming payment, releasing the correct order and protecting customer communication. Temporary manual checkpoints were introduced for high-risk transactions while the system problems were corrected.
I also made responsibilities very specific. Each exception needed an owner, a next action and a deadline. Short daily reviews focused on unresolved transactions rather than broad status presentations.
For future changes, I learned to include both enthusiastic and skeptical employees in the pilot group. Supporters help create momentum, while skeptics identify practical weaknesses that project teams can miss. When their concerns are addressed early, they often become the most credible supporters of the rollout.
Resilience came from giving employees a reliable fallback process and permission to raise problems before they became failures. A team performs better during disruption when people know what must be protected, who can make each decision and what they should do when the new system produces an uncertain result.

One of the most effective ways we've maintained team performance during periods of change has been building a culture of ownership before disruption occurs. In fast-growing fintech companies, like ours, priorities can shift quickly, so we've focused on giving people the context behind decisions. When employees understand the bigger picture and are trusted to make decisions, they can adapt without waiting for constant direction.

The pandemic is the honest test case for us. Pledge It was built around athletes raising money for causes, and when events shut down, that entire model went quiet at once. We widened the platform to serve charities directly, which meant peer-to-peer campaigns, galas, auctions, walks, and donor management. That was a substantial change of direction on short notice.

But the reason the team could move at that speed had been decided long before the pandemic. I came out of sports, and the thing I took from it is that when you relieve the fear of failure, people play with freedom. A team that's been punished for bad calls will freeze the moment the plan stops working, because the safest move becomes doing nothing. A team that knows a wrong call won't be held against them will just start trying things.

So I'd push back gently on the idea that you prepare people for disruption. You can't rehearse a specific crisis. What you can do is build a real track record of how you respond when something goes sideways, so that when it counts, nobody is spending energy wondering whether they're about to get blamed.

During significant change, I reduce priorities rather than adding more processes around them. The team needs clarity on three things: what cannot change, what can change, and who owns the next important decision. A simple weekly reset around the main outcome, biggest uncertainty, and next decision keeps people focused without pretending everything is predictable. Resilience comes from giving people enough clarity to adapt, not from trying to remove every uncertainty.

During periods of heavy disruption—which is practically the baseline when building AI products right now—the most effective strategy I’ve found for maintaining team performance is anchoring our goals to mundane, unchangeable metrics rather than the technology itself. Over the last ten years, from scaling machine learning for millions of users at Leboncoin to building autonomous customer support agents at AGO, the tech landscape has shifted under our feet constantly. If an engineering roadmap is tied too closely to a specific language model or a trending algorithm, a sudden industry breakthrough can paralyze a team. They feel like their recent work just became obsolete overnight.

To build resilience into our culture, we focus our sprints heavily on the infrastructure and the practical workflows around the algorithms. We measure our team’s success by latency thresholds, backend API stability, and whether an agent can safely process a user’s refund without breaking a partner database. When the next major model drops and disrupts the market, our engineers usually don’t panic. They just swap out the underlying engine. The guardrails, the external API connections, and the data structures they spent their time building are still the core bottleneck, so their actual work remains highly relevant.

The most effective strategy was reducing uncertainty before trying to raise morale. During major disruption, people do not lose performance first. They lose clarity first. Every change was translated into three things each team member could act on immediately: what remains true, what is changing now, and what decision standard should guide the next client issue. That prevented the panic that comes from vague leadership language and gave professionals a usable framework under pressure.

I also trained resilience through controlled exposure, not slogans. Teams were walked through difficult scenarios before they arrived, including staffing gaps, regulatory shifts, and emotionally charged client situations. After each exercise, leaders reviewed judgment calls rather than only outcomes. That built steadier decision making, stronger trust, and a culture where disruption felt familiar instead of destabilizing.

The honest answer is that most resilience is built long before the disruption arrives, not during it. By the time the ground is shifting, you are working with whatever the team already was. So the real strategy is not a crisis playbook. It is the coherence you built when things were calm, because that is what gets spent when things are not.

Here is what I mean. When change hits, a team does not rise or fall on its plan. It rises or falls on whether people still trust each other, still feel safe to say "I do not know" or "I think we are wrong," and still share the same picture of where they are going. A team with that foundation absorbs enormous disruption. A team without it fractures the moment pressure strips away the polite surface, and no amount of reassuring messaging in the moment can repair what was never there.

So my most effective strategy is to build and protect that foundation before it is needed, and to keep it visible. In the work I do with teams, we can actually measure whether a team is coherent, the trust, the psychological safety, whether people are genuinely aligned or only appear to be. That matters most in disruption, because change is exactly when a team will quietly drift and no one will say so. Being able to see the drift early, while it is small, is the difference between steering through a hard period and discovering the fracture after it has already cost you.

The other half is the leader. In disruption, a team organizes around the leader's nervous system even more than usual. If the leader is reactive and dysregulated, the team catches it and locks down. If the leader can stay grounded, the team borrows that steadiness. So preparing a team for disruption starts, unglamorously, with the leader learning to regulate their own state under pressure, because that state sets the emotional weather everyone else works inside.

How I prepare a team to be resilient, then, is not by teaching resilience techniques. It is by strengthening the connection between people while things are stable, making that connection visible so erosion gets caught early, and helping the leader stay regulated enough to be an anchor rather than an amplifier.

Resilience is not something you summon in the storm. It is the trust and coherence you banked before it, quietly, on the ordinary days no one thought mattered.

Fair warning on my lane: I run small companies, a brokerage and a training business, so this is not the view from the top of a large company. What I do see up close is teams of senior professionals going through the specific disruption of AI landing on their desk, because that is who we train.
My most effective strategy is unglamorous. During real disruption, pick one thing that does not move and protect it like a client meeting. One standing meeting, one weekly number everybody sees, one recurring slot that survives whatever else is on fire. When everything is in flux, people do not need five new initiatives. They need one fixed point to navigate by. Everyone overcorrects. They reset five things at once and by week six three of them are gone. The single anchor survives, and it quietly pulls the rest of the routine back into place.
On preparing a team to be resilient, what helped more than reassurance was letting people watch the new system be wrong. Once. In public, where it was safe.
We had a release where every automated check passed and the page was still visibly broken, because the tests were reading the code rather than what the reader actually saw. A person opened it and caught it immediately. That single incident did more for people's judgment than any amount of telling them to be careful, because nobody overrides a system they have never watched be wrong. Until you have watched it be wrong once, you either defer to it completely or you refuse to touch it. Neither of those is resilience.
So: one fixed anchor, and one honest demonstration that judgment is still required. People get steady a lot faster when you show them the tool's edges instead of insisting it has none.

The most effective strategy was keeping the decision-making layer identical to the execution layer. At Nika Finance, we run a three-person founding team. That means every conversation about what to build or what to fix is happening between the people who will actually build or fix it. There is no translation layer. No meetings where decisions get made in one room and then handed to another room for execution. When a user reports an issue, the person reading that report is the same person writing the code to address it.
This structure forced resilience during two high-pressure periods: production launches and fundraising. During launches, the feedback loop from "user hits an error" to "fix is deployed" ran in days, not quarters. We couldn't afford to slow down for coordination overhead because there was no coordination overhead to slow down for. During fundraising, we kept shipping. The product kept moving forward because raising capital was one workstream among several, not the thing that paused everything else.
The structural advantage of a three-person team is execution density. We ship faster than teams several times our size because our internal engineering surface is narrower than what users see. Perpetuals route through Hyperliquid via builder codes. Prediction markets route through Polymarket. What we build in-house is the interface, the wallet, the cross-chain plumbing, and the AI layer. The rest routes to partners who already do it better than we could if we tried to build it from scratch.
Resilience in a lean team comes from removing the dependencies that make larger organizations fragile. No separate function lines for product, growth, or marketing. No one whose job is to talk about the work instead of doing the work. When disruption hits, the team that can recalibrate and keep shipping wins. You cannot build a world-class product with a slow organization. The teams that win are the ones that stay closest to users and ship faster than everyone else.

We stopped fearing turnover and designed for it instead: if a process only works when one specific person shows up, it isn't a process, it's a dependency. An April 2025 Gartner survey of more than 2,850 employees found that 79% have low trust in change, and I suspect that's because most teams experience change as something done to them, with no system underneath.
Our stress test was real. I took over TKEG Expat when it was a suspended division in 2023, reinstated services in 2024, and spun it out as a standalone company in May 2025; revenue grew roughly 2.2x from 2024 to 2025. The team has always been fluid — remote contributors have cycled through the pool continuously, several active at any one time — so every workflow had to live in our operations portal rather than in anyone's head. New people inherit a playbook, not a mess.
Measurement came second, deliberately. We didn't survey during the turnaround; we institutionalized its lesson afterward. Since February 2026 we've run four rounds of team surveys: the IWPQ for individual work performance, LMX-7 for manager-contributor relationships, and the Team Climate Inventory for participative safety. A dip gets a targeted response on that specific dimension, not a company-wide morale speech. Resilience here is documented work plus measured climate — a property of the system, not a personality trait.

The thing I learned about teams in disruption is that people don't actually panic about the change itself. They panic about not knowing where they stand in it. Uncertainty is the enemy, not difficulty. A team will grind through a genuinely hard, scary stretch without falling apart, as long as they trust that they're being told the truth about it. What breaks performance is the silence — when leadership goes quiet or starts spinning, everyone's imagination fills the gap with something worse than reality, and half their energy goes to worrying instead of working.

So my most effective strategy wasn't a resilience program or an offsite. It was telling people the truth faster and more often than felt comfortable, including the parts I didn't have figured out yet. "Here's what's happening, here's what I know, here's what I don't know yet, and here's when I'll tell you more." That last piece matters more than it sounds — a team can sit in uncertainty if they know exactly when the next real update is coming. What they can't do is sit in an information vacuum indefinitely and stay sharp.

The other half is narrowing the focus when everything's shaking. In a stable period people can juggle a lot. In a disruptive one, that same breadth becomes paralysis, because everything feels urgent and nothing feels safe to drop. So I do the opposite of what instinct says — instead of adding, I cut. I get the team down to the two or three things that genuinely matter this month and explicitly give them permission to let the rest slide. A person with three clear priorities in a storm outperforms a person with fifteen every time, because they can actually finish something, and finishing something is what restores the feeling of control that disruption strips away.

On preparing for resilience — I don't think you build it in advance with exercises. You build it by how you behaved the last time things got hard. Resilience is mostly trust with a track record: a team is resilient in this crisis because they watched you be straight with them in the last one. So the real preparation is the ordinary honesty you bank during calm periods. Handle the small bad news well, month after month, and when the big disruption hits, they extend you the benefit of the doubt automatically. You can't manufacture that in the moment. You either earned it already or you didn't.