Antifragile teams aren't stress-free, they're stress-trained

How to build teams that adapt when everything's changing

I once fell into a ditch full of fallen leaves so deep only my head was visible, alone in woods where there might be bears. My knee was taped with duct tape after 35km of hiking. I was lost. I laughed, climbed out, and finished the trek.

Ten years later, that experience still helps me lead teams through chaos. Not despite the stress, but because of it.

An engineer told me last week: “I feel like I’m becoming obsolete every Monday.”

New AI coding tools. Framework updates that invalidate last month’s best practices. The skill you spent years building is suddenly table stakes because AI does it in seconds.

The stress isn’t visible like a production outage. There are no customers complaining and no Slack war room waiting for you. Just the quiet anxiety of not knowing if what you’re good at will matter next year.

Some engineers are paralyzed by this. Others are adapting faster than the technology changes.

The difference? The ones handling it best already learned something most leaders try to prevent: how to use stress as a tool, not avoid it as a threat.

I wrote recently about what’s left for engineers when AI writes the code.

When AI writes the code, what's left for engineers?

The answer: judgment, curation, prevention. The skills that matter when generation is cheap.

But that essay didn’t answer the harder question: how do you actually build those skills when everything’s changing this fast?

The answer is counterintuitive: controlled stress exposure builds the capacity to handle any stress. Physical challenges build mental toughness. Emotional risks build professional courage. And recovery time is what makes it all stick.

The engineers handling the AI transition best aren’t the most enthusiastic or the most technically skilled. They’re the ones who already learned how to stay calm when they don’t know what’s coming next.

They built that muscle somewhere else. Now they’re using it here.

Same pattern shows up everywhere

You’ve seen it in my hiking story. The pattern shows up in every high-pressure situation - including how teams handle incidents at 2am.

Stressful situations either make or break people. You see who a person is at the core once you put them in an unfamiliar stressful situation like on-call or a feature release that you don’t expect to go smoothly. You have to get up in the middle of the night, something’s wrong, customers are affected, and you see how people respond to this kind of adversity.

In the past I enjoyed being part of the on-call group even if I wasn’t solving the problems. I was helping coordinate or communicate progress and solutions. But I enjoyed observing my team members stay calm, think through steps, not panic, and do those plan-do-check-act (PDCA) cycles a couple of times within half an hour. To me it was like watching a thriller where you know you are with a good guy, you’ll find way out of all the difficult situations and everything will be okay at the end.

And then there were times when a different person was on call. Nervous, jumping around without clear steps, panicking, escalating too soon or not escalating at all and at the end caving in without communicating where they are, what they’re doing. That was a totally different story to observe. I felt nervous, I felt this tension and I was not sure we’ll make it through the incident without major outage. My instinct would be, “Oh let’s call someone else.”

We had a couple of feature releases that went anything but smooth. Whatever could possibly go wrong went wrong. Regardless of pre-mortems we had, we still encountered some unpredictable situations and had to come up with solutions on the fly, pair thinking and coding at twice the speed we would have otherwise. But if the right combination of people was in the team releasing, whether it was Saturday morning or Monday evening, it was almost beautiful. It was intense, it was challenging. We were full of adrenaline. But it also bonded us, it made us believe that there is not a problem we cannot solve.

Another situation, this time regular release, something that should be simple and smooth. But there was one overly anxious person panicking at every normal little hiccup like it’s the end of the world and with this affecting everyone else to temporarily lose their cool and stress out.

So what’s the difference between these two types? Personality plays a role - some people are naturally calmer under pressure. But that’s not the whole story.

The real difference is exposure.

The engineers who handled chaos calmly had been through smaller versions of it before. They’d watched someone experienced navigate an incident and learned the pattern. Or they’d stumbled through one themselves, extracted the lesson, and built the muscle for next time.

The ones who panicked? They’d never had the chance to practice.

Maybe you kept them focused on feature work, shielding them from incidents. Maybe you always put the experienced people on the stressful stuff. You thought you were being kind - letting them concentrate on code instead of chaos.

You weren’t building kindness. You were building fragility.

They never learned how to think clearly when things break. They never saw how experienced engineers stay calm, work methodically through problems, communicate under pressure. They never built confidence that they can handle adversity.

Now when the real crisis hits - when you’re not available, when the experienced people are stretched thin - your team freezes.

Resilient vs. antifragile

Resilient teams bounce back from stress. They survive challenges and return to baseline.

Antifragile teams get stronger from stress. They don’t just survive challenges, they use them to build capacity.

The concept comes from Nassim Taleb, who distinguished between things that break under stress (fragile), things that withstand stress (resilient), and things that improve from stress (antifragile).

Your bones are antifragile. Apply controlled stress through exercise, and they grow denser. Shield them completely, and they become brittle.

Muscles are antifragile. Resistance training creates micro-tears that heal stronger during recovery. No resistance means atrophy. But constant resistance with no rest? That just breaks you down.

Like bones and muscles are for the body, team members and teams are for the company. The stronger and more antifragile team members, the stronger and more antifragile teams. You can selectively work with individuals to make them better at this and then collectively as a team as well.

A lot of leaders treat teams like they’re fragile. Shield them from all stress. Protect them from difficult situations. Take on the hard conversations yourself. I know I did in the past.

The result? A team that can’t handle the real crisis because they never practiced with the manageable ones.

Not all stress builds capacity

The stress → recovery → stronger cycle only works when all three parts are present. Stress breaks you down. Recovery builds you back up stronger. Skip recovery, and you’re just accumulating damage.

Chronic overwhelm with no recovery time just breaks people. The key is distinguishing between stress that develops and stress that destroys.

The best example is how physical challenges build mental toughness and emotional risks can build professional courage.

I learned this from my own experience and later read research supporting it. Exposure to controlled stress in one domain builds resilience that transfers to others.

Physical challenges build mental muscle

I used to do 45km orienteering treks. Amateur events where anyone could join. You’re in the middle of nowhere with only what’s in your backpack, a bit of courage, and grit to make it to the end. I was never the fastest, not even close, but I never gave up.

I mentioned that ditch earlier - here’s what actually happened. It was in a region where there could be bears. At the first 10 km my knees started throbbing. I was in the middle of nowhere - no houses, nothing. I thought: “Okay, maybe I should give up since my knee is hurting.” But I had duct tape in my backpack. I taped my knee and soldiered on for the next 35 km alone in the woods where there could be bears. Then I fell into a ditch full of leaves so deep that only my head looked out.

Still not giving up, I just found my way out. And laughed. It was funny. Happy I didn’t run into any bears. This experience, even 10-15 years later, gives me strength when I need it. If I managed to get out of that situation alone and lost, I can bear anything.

While I can’t and won’t make all my team members go on a trekking in the middle of the woods, I still do encourage them to work out, to go and take care of themselves, of their body, and go through some hardship to be stronger everywhere, including at their work.

In the last couple of years a couple of my team members and myself attended obstacle races. Not to win, but to push ourselves. They challenging but they were also fun. And they bonded us through mud and sweat, through overcoming our fears and physical discomfort jumping or climbing over or under obstacles. We even had to climb under a tank. A real one.

The pattern shows up everywhere. Engineers who run marathons approach things differently. They’ve built the mental muscle to stay patient when solutions aren’t obvious. Leaders who do endurance sports handle organizational chaos with more calm. They’ve practiced discomfort.

This isn’t some sophisticated or mystical mechanism. You’re creating concrete experiences of stress → recovery → stronger. Your brain learns the pattern. Then it applies the pattern across domains.

And that recovery matters. The 45km trek worked because I didn’t do it every day. The obstacle races bonded us because they were occasional challenges, not constant grind.

Emotional stress builds courage

Most team members I ever worked with tried to avoid presentations, especially public speaking, regardless whether it was internal or (God forbid) external. But I always encourage them to just do it, to just try.

It’s much easier to try in front of smaller teams of team members that you might be more comfortable with. Where you can make mistakes, where you don’t have to perform because they already know you. You can just be you. You can try it.

They are terrified. Then do it anyway. Their hands might shake. Their voices might shake from the beginning.

Sometimes the presentations are rough. But they survive. Next time, they present again.

And the more times they do it, the sooner they get into the zone while presenting. Then eventually they will start enjoying it. It will never be perfect, and that’s not the point. The point is building capacity by confronting the fear.

This experience helps them handle high-stakes conversations that would have paralyzed them before. Not because presenting made them an extrovert. Because confronting a fear directly builds capacity for all future fear-inducing situations.

It doesn’t always have to be presentation in front of others. It can be speaking up at a meeting where stakes are high or where you have leaders present.

I know how hard it is. In comparison to many people I know I would consider myself a seasoned speaker. I’ve been at conferences and events with hundreds of people in the audience, I facilitated hackathons and workshops... but still I feel the anxiety, the mix of fear and excitement, too. Every time. When I’m at a presentation and would like to ask a question my heart starts pounding. Boom boom, I can hear it in my ears. I can feel it in my guts. I feel nervous. I usually need half a minute to decide whether to even raise my hand or not. But I know by now that once I speak it will be okay, and these 30 seconds gives me time to collect myself and then just do it. Once you ask the first question, the second one is much easier.

The heart pounding almost never goes away. It is a clear sign for me that yes, I am out of my comfort zone, and yes, I need to do this.

This happens especially when you think your question is stupid or when you put too much importance on what others will think (of you). But you know what? From my experience a lot of people there have exactly the same stupid questions in their mind. They’re just too afraid to ask them. Once you do, they might open up and ask something themselves.

The engineers who never face their fears stay fragile. They’ll avoid difficult conversations, delegate the presentations and their visibility will suffer.

Each avoidance reinforces fragility and each confrontation builds strength.

Professional stress builds capability

The team that’s never deployed a risky change can’t handle the inevitable risky deploy. The engineer who’s never led an initiative outside their expertise can’t adapt when the company needs something new.

We had only a couple of skilled engineers in on-call rotation. We needed to expand the pool but couldn’t just throw inexperienced engineers into 2am incidents.

Inspired by Chaos Monkey, we introduced monthly incident response drills. Database failovers, service degradation, partial outages. Simulated situations where more experienced engineers coached newer ones through the pressure. The stakes were controlled, but the stress was real.

The engineers loved it. They practiced thinking clearly under pressure without the panic of a real early morning incident. Our response times improved. We identified gaps in monitoring and playbooks. Most importantly, we built antifragile engineers who could handle whatever came their way.

Usually our engineers are candidates for on-call once they’re senior but I had one team member who said, “Let me in. I want to learn. I am excited about this. I want to be exposed to this kind of stress because truth be told you learn much more in these times than you do through regular work.”

He was really excited because he knew that he had a safety net of other on-call engineers who can help him out but he wanted to try, to jump in, to do it himself. And he did it. I don’t lose any sleep when he’s on call because I know we are in good hands. No matter what comes his way, he’ll find a way to solve it.

The teams that only take on projects where success is guaranteed never build the muscle to handle real uncertainty. They stay in their comfort zone until the company needs them to step outside it. Then they’re stuck.

What harmful stress looks like

Developmental stress is challenging but manageable. There’s recovery time. There’s learning built in. There’s support when things go wrong.

Harmful stress is chronic overwhelm with no processing time. No learning loops and no light at the end of the tunnel. Just constant fire-fighting with no space to understand what made the fires start.

I’ve seen teams ground down by this. Incident after incident with no post-mortem. Sprint after sprint with no retrospective. Pressure with no release valve.

That’s not building antifragility. That’s breaking people.

The difference comes down to three things:

1. Can they handle this dose of stress with support? Or is it genuinely beyond their capacity even with help?

2. Is there recovery time? Stress without rest is just burnout. Muscles grow during recovery, not during the workout.

3. Is there learning? If you’re not extracting the lesson from the stress event, you’re just experiencing pain without growth. and you’re bound to repeat it again

No to any of those three, and you’re not building antifragility. You’re just grinding people down. Recognize these three things and do your best to turn harmful stress into manageable challenges.

But sometimes you’re not the one creating the harmful stress. The business is pushing impossible deadlines. Leadership is stacking projects with no breathing room. The pressure is coming from above, and your team is getting ground down.

This is where you step in as a buffer. Your job isn’t to shield them from all stress - that would keep them fragile. It’s to make sure those three criteria are met. Fight for recovery time between major pushes. Push back on stacking another high-stress project when the team hasn’t processed the last one. Carve out space for retrospectives even when leadership just wants the fix and wants you to move on. Make sure your people have the support they need to handle the stress, not just survive it.

In situations like this being a leader means saying no upstream so your team can say yes to the right challenges.

How to actually do this

The goal isn’t to traumatize your team. It’s to create environments where they deliberately face manageable challenges.

Run drills before the real crisis

Run drills. Chaos engineering experiments. Pre-mortems. Practice scenarios where failure is safe but the pressure is real.

The teams that do this regularly don’t panic during real incidents. They’ve built the pattern recognition. They’ve practiced thinking clearly when systems are failing.

The teams that never practice stay fragile. When the real incident hits, they’re learning under maximum pressure. That’s not antifragility — it’s hoping for divine intervention.

Give stretch assignments with safety nets

Give stretch assignments with support. Projects outside someone’s comfort zone where failure is possible but trying matters.

The engineer who’s never led anything can’t suddenly become a tech lead. But they can lead a small cross-team initiative with you providing backup. Then a bigger one. Then they’re ready.

How I start this usually with mid-level engineers is by giving them a feature that’s bigger than anything they’ve done before, but manageable with support. I ask them to understand the problem, prepare solution, prepare task breakdown, milestones, estimates - everything that in the past someone more senior did for them. I ask them to validate these things with seniors so they get immediate feedback and we go through and try to figure out what they didn’t think of. Then I just let them do this project with regular check-ins to see if they need any help or to correct course if needed. I let them fail small stuff but I would not let them fail an important thing that would hurt their reputation, customers, or the company.

The pattern works for everything. Public speaking. Architecture decisions. Client conversations. Conflict resolution.

Start small. Make failure safe. Build the capacity gradually.

And build in recovery between stretch assignments. Don’t stack them back-to-back. The growth happens in the space between challenges, when people process what they learned and build confidence for the next one.

Stop shielding, start coaching

I stopped protecting people from every difficult situation. I let them practice navigating hard conversations with me as backup. I let them present with me in the room so I can back them up. I let them handle the stakeholder who’s frustrated, with me available if it escalates.

Each exposure builds capacity. Each protection reinforces fragility.

I used to think I was being a good leader by handling all the difficult conversations myself. I was actually preventing my team from developing the skill to handle them. I was a crutch.

Now I coach them through it. They lead the conversation. If it goes sideways, I step in. But most of the time, they handle it. And the next conversation is easier.

Sometimes I still jump in too soon as a hero to guard them. But they remind me: “Mateja, let me do it myself, no need to jump in immediately. I got this.”

This makes me proud from two reasons: they want to do it themselves and they spoke up because they want the opportunity.

Extract the learning, not just the fix

Stress without learning is just suffering. The difference between teams that get stronger and teams that just survive is what happens after the stress event.

Your post-incident review process reveals it all.

If you’re only asking “how do we prevent this?” you’re missing the growth opportunity. The better questions are:

• What did we learn about our systems?

• What capacity did individuals develop?

• What would have helped us respond faster?

• Who grew through this experience?

• What should we practice now that we know we’re weak at it?

The teams that extract learning from every incident get stronger. The teams that just fix and move on stay at the same capability level.

Same thing applies to post-mortems, derailed projects, and stretch assignments that didn’t work out.

Some fixes are simple - tweaking processes or timing. Other times it’s more coaching through the hard parts. Whenever we have a challenging project, we try to do a retrospective afterwards where we speak up openly what worked and what didn’t. Not just from a technical perspective but also from a more human perspective. And a few things popped up in our retrospectives. We can’t do projects back-to-back without a cool-down period. And we can’t work on two big projects at the same time because it’s draining us.

We applied this into next quarter planning a bit better than we used to. We are still work in progress and we still do retrospectives, because we want to improve.

If you’re not asking those questions, you’re wasting the stress. You went through the pain without capturing the growth.

The pattern that matters

Teams that get stronger from challenges share a pattern. They don’t avoid stress. They create controlled exposure to it.

Physical challenges. Emotional risks. Professional stretch assignments. All three matter.

The engineering team that does a challenging sport together builds mental resilience. The individual who confronts their fear of public speaking builds courage that transfers everywhere. The engineer who takes on the unfamiliar tech stack builds adaptability.

None of this happens by accident. It requires creating environments where controlled stress is expected, where failure is safe, and where learning is extracted from every challenge.

The alternative is teams that only function in comfort. The moment real pressure hits, they fracture.

For individual contributors: seek the stress, plan the recovery

If you’re an IC reading this and thinking “my manager isn’t building antifragility,” you can still build it yourself.

Volunteer for the scary stuff. The presentation you’re dreading or the project outside your expertise. These aren’t distractions from your growth. They are your growth.

But here’s what most people miss: you have to plan recovery as deliberately as you plan the challenge.

What does recovery actually look like?

After a stressful incident or release: Take the next day lighter. Don’t stack another high-pressure deadline immediately. Process what you learned - write it down, talk it through with someone. Give yourself permission to do routine work for a day or two while your brain integrates the experience.

After an emotional challenge like a presentation or difficult conversation: Block 30 minutes after for decompression. Don’t schedule back-to-back high-stakes meetings. Acknowledge what you accomplished. The shaky hands during the presentation? That’s your system building capacity. Don’t force yourself to “power through” immediately to the next thing.

In the face of ongoing change - AI, new tools, shifting tech landscape: Pick one new thing to learn deeply, not ten things surface-level. Schedule actual downtime. Not “I’ll rest when the project is done” but planned recovery time. Protect focused work time. Context-switching is stress without the growth.

The pattern is the same:

controlled stress exposure + deliberate recovery = capacity building.

You don’t need your manager’s permission to seek challenges. But you do need to be smart about recovery. The engineers handling chaos best aren’t the ones grinding 24/7. They’re the ones who push hard, recover fully, and show up stronger next time.

What to do Monday morning

If you lead a team, ask yourself:

Are you building antifragility or protecting fragility?

When the difficult stakeholder conversation comes up, do you handle it yourself or coach someone through it?

When there’s a stretch project, do you give it to the person who can definitely do it or the person who might fail but would grow from trying?

When incidents happen, do you extract learning or just fix and move on?

The teams that survive chaos aren’t the ones that never faced it. They’re the ones that practiced with manageable versions of it first.

Start small. Run an incident response drill. Give someone a stretch assignment with support. Let your team practice being uncomfortable while the stakes are low.

Because when the real crisis hits, and it will, you want a team that’s been here before. Not in this exact situation, but in situations where they thought clearly under pressure, tried something uncertain, and pushed through discomfort anyway.

That’s what antifragile looks like.

If I learned anything in my life is this: we’re tougher than we think we are.

---