Team Resilience: The Three Pillars of Stability in Turbulent Times

"The sold-outs initiative from yesterday is confirmed as a top priority. We should refocus all resources on it now." The words hung in the air during a cross-team meeting and I didn't know whether I should laugh, cry, or curse. A new initiative the product team has just invented and successfully sold to a partner demanded immediate attention. My team has carefully planned the sprint two days back and all the effort was about to be thrown out the window. The suggestion? Break every team's sprint, reorganise backlogs, and pivot immediately.

A week later, the initiative was abandoned.

If this sounds familiar, you're not alone. As engineering leaders, we frequently face these sudden priority shifts that threaten to destabilise our teams. The challenge isn't just about managing the immediate chaos - but rather how are we supposed to maintain team engagement when the ground keeps shifting beneath their feet?

But here's the interesting part: Despite a stream of these disruptions, my team not only survived but thrived. We managed to deliver our key quarterly objectives, successfully onboarded three new people, and maintained high engagement levels. Rather than fighting against change or dwelling on its causes, we discovered that the key lies in building systems of stability that could weather any storm.

The Reality of Modern Software Development

Let's face it - change is as much a part of software development as code itself. In product-driven companies, or when operating in turbulent markets, this reality is amplified. The sold-outs initiative wasn't an isolated incident, even though it was the most intense - during the same quarter, we faced multiple other priority pivots, from new features related to discount cards to expanding scope in the European Entry-Exit System (don't ask...).

These constant changes affect more than just our roadmap - they impact how our teams work together. Think about how your brain feels after a day of context switching between five different projects. Now imagine doing that every week. There's fascinating research by educational psychologist Paul Kirschner that explains why this constant context switching exhausts us. His Cognitive Load Theory suggests our brains have limited processing capacity - and when we keep forcing them to juggle different contexts, we're essentially running at maximum CPU all the time. It's also something we've all experienced: trying to juggle too many changing priorities makes it incredibly hard to do good work.

As engineering leaders, we can't and we don't want to make change disappear. Our real challenge is keeping the team motivated and productive while protecting them from burning out. The "metric" can be for example that our one-on-ones and retrospectives don't turn into venting sessions.

The Obvious and the Hidden Cost

You've probably heard the standard advice about priority changes: minimise context switching, avoid partially completed work, maintain clear goals. While this wisdom isn't wrong, it only scratches the surface. Let's dig deeper into the obvious costs and, more importantly, the hidden psychological impact that makes these situations challenging.

The Obvious

Mary and Tom Poppendieck, in their groundbreaking work on Lean Software Development, helped us understand something Toyota had known for decades: constant context switching is one of the biggest sources of waste in any process. They showed us that each time we shift priorities, we're not just losing time - we're actively creating waste in multiple forms. Partially completed features gather dust, teams spend time context-switching instead of delivering value, and we accumulate the overhead of repeatedly "starting" work. In the sold-outs initiative case, we had three teams stop working on projects they already started, and shift effort to analysing how to approach the new one. Only to throw away that part as well.

There's a reason why changing goals constantly kills motivation - and it's not just common sense. Goal-setting in organisations is not just management theory - it's backed by decades of research. Fred Lunenburg's work on goal-setting showed us something crucial: humans need clear, stable targets. When goals keep shifting, we're actually working against our basic psychological wiring. How can team members commit to objectives when experience tells them these goals might vanish before completion? During this quarter, I noticed a telling pattern: when new initiatives emerged, fewer engineers volunteered to lead them. Some even actively sought ways to avoid being assigned to these projects.

The Hidden

But that's just the obvious stuff we can see in our sprint boards. The real psychological damage happens beneath the surface - the kind of things that never make it into our status reports (or even retrospectives) but show up in subtle or not-so-subtle ways during our daily work.

Frequent shifts wear down the entire team's resilience, and we start to push back even against reasonable adjustments. Also from friends in the same team! Irritation and resignation sets in - I saw this firsthand when a typically enthusiastic senior engineer responded to my request with a sigh and resigned "whatever you think is best". Publicly in a team meeting, pushing the mood further down. Organisational researchers Bernerth, Walker, and Harris gave this phenomenon a name: 'Change Fatigue'.

You can see the increased cognitive load (Kirschner, 2002) in everyday interactions. Our engineers are already wrestling with complex technical decisions - now they have to completely rethink their understanding of what matters and how everything fits together. I've caught myself talking about the wrong project in meetings simply because there was too much to keep straight in my head.

These hidden costs can be explored from the perspectives of multiple theories, but ultimately manifest in concrete ways: collaboration drops, and we can see a general decrease in proactive problem-solving. Most concerningly, it creates a self-reinforcing cycle - as team members become less engaged, they're less likely to invest in solutions that could help stabilise the situation.

As engineering managers, we are particularly responsible for addressing the hidden part. This understanding became crucial as we developed our approach to building resilience, which I'll explore in the next section.

Pillars of Team Resilience

Remember the sold-outs initiative? I found it interesting how some teams navigated the chaos better than others. Three pillars emerge that made the difference. Let me share what worked.

Process Stability

First, counter-intuitive as it might seem, maintaining stable processes during chaos actually helps. When a fellow engineering manager suggested that teams break their sprints, we didn't. Instead, we treated it like any other incoming priority - we were happy to discuss and help a bit here and there. And if it was really necessary, we could swap two or three tasks in the sprint to get started on what parts were already clear, but keep majority of the sprint as is.

This isn't about being inflexible. It's about recognising that team routines serve as psychological anchor points. The main contemporary theory of human motivation (called Self-Determination Theory) describes how we all have a fundamental need for relatedness - that feeling of being connected and supported by others. Our stable team processes tap directly into this need, giving people an anchor point when everything else is shifting. Our daily standups, sprint planning sessions, and retrospectives continued unchanged. When everything else was shifting, these steady rhythms provided a sense of continuity and control, and importantly, a sense of being a part of a stable team.

Psychological Safety

Harvard's Amy Edmondson spent years studying high-performing teams and discovered something crucial: the best predictor of team success wasn't talent or resources - it was psychological safety. Her research showed that when team members feel safe to take risks and be vulnerable with each other, they perform better across every metric that matters. It clearly manifests during turbulent times: team members felt comfortable expressing their frustrations openly: "Is this the third 'top priority' this month? Yeah, surely this one's different..."

This openness isn't just about venting, although that is important, too. It also creates space for genuine problem-solving. At another initiative the same quarter, when the Entry-Exit System scope expanded, team members freely discussed their concerns about technical debt and suggested different approaches. This kind of honest dialogue is impossible without pre-existing psychological safety.

We need to build this safety before we need it. Once frustrations set in, it's too late.

Strategic Communication

The final pillar is perhaps the most challenging: strategic communication. During priority shifts, it's tempting to either sugar-coat changes or simply relay orders from above. Neither works. Instead, we developed a pattern of transparent communication focused on value.

For discussing the new discount cards feature, instead of announcing another top priority, we explored why it mattered: "It's a nice feature for our users that we haven't been able to prioritise for years." This honesty worked. Engineers engaged with the feature's merits rather than just seeing it as another disruption.

Here's what's brilliant about these pillars - they strengthen each other. When you have stable processes and open communication, people feel safe to speak up. And when people feel safe to speak up, they're more likely to follow and improve those processes. It's like a positive feedback loop that makes the whole team stronger.

Unfortunately you can't wait for chaos to start building these foundations. The time to establish stable processes, psychological safety, and communication patterns is before you need them. Because when the next "top priority" initiative arrives - and it will - these pillars will determine whether your team bends or breaks.

Conclusion: Beyond Survival to Thriving

Looking back at that intense quarter, what strikes me isn't the chaos of multiple priority shifts - it's the challenge of keeping the team motivated and in high performance mode. The sold-outs initiative that sparked this reflection wasn't unique. It was just the most visible example of a pattern that every engineering team faces.

My key insight isn't about preventing change - it's about building a team that can absorb it. When we focus on stable processes, psychological safety, and strategic communication, we can create environment where engineers can maintain their effectiveness even as priorities shift around them.

The results speak for themselves. Despite facing multiple priority changes, my team delivered all key quarterly objectives. We successfully integrated three new team members who joined during this turbulent period (sadly, two were here temporarily for onboarding and now moved to their new teams). Most importantly, our engagement remained high, and I saw full and enthusiastic voluntary participation in new initiatives when the following quarter started.

For engineering leaders, the message is clear: Don't wait for stability to build these foundations. The time to establish robust processes, psychological safety, and communication patterns is before you need them. Because in modern software development, the next "urgent priority" isn't a question of if, but when.

So where should you start? Begin by reviewing the levels of psychological safety, there's never enough of that. If you're building a new team or inherited one, this should be one of your top priorities. When Google investigated what made best teams tick, they found something surprising: it wasn't about having the smartest people or the best processes. The secret ingredient was psychological safety. Teams where people felt safe to take risks and be themselves consistently outperformed teams that looked better on paper. So revisiting this is something worth doing regardless.

In the end, the goal isn't to create teams that never face disruption. It's to build teams that can navigate change while maintaining their core stability and effectiveness. When we achieve this, we move beyond merely surviving change to actually thriving within it.

References:

• Edmondson, A. (1999). Psychological safety and learning behavior in work teams. Administrative science quarterly, 44(2), 350-383.
• Poppendieck, M., & Poppendieck, T. (2003). Lean software development: An agile toolkit: An agile toolkit. Addison-Wesley.
• Lunenburg, F. C. (2011). Goal-setting theory of motivation. International journal of management, business, and administration, 15(1), 1-6.
• Kirschner, P. A. (2002). Cognitive load theory: Implications of cognitive load theory on the design of learning. Learning and instruction, 12(1), 1-10.
• Bernerth, J. B., Walker, H. J., & Harris, S. G. (2011). Change fatigue: Development and initial validation of a new measure. Work & Stress, 25(4), 321-337.
• Deci, E. L., & Ryan, R. M. (2013). Intrinsic motivation and self-determination in human behavior. Springer Science & Business Media.
• Duhigg, C. (2016). What Google learned from its quest to build the perfect team. The New York Times Magazine, 26(2016), 2016.