There’s a particular kind of conversation that happens in Costa Rica over coffee — the kind where someone unfolds a map on the table and points at a patch of green marked by nothing but contour lines and rivers. Someone inevitably asks, “What’s out there?”
That simple question is how most canyoning adventures begin. A few friends — engineers, climbers, explorers — gathered around coffee, tracing potential routes through rivers and ravines. Within days, the idea turns into action: training sessions, gear checks, ropes and descenders spread across the floor.
Canyoning is the art of descending rivers carved through volcanic rock — waterfalls, pools, narrow walls of stone. It’s a mix of climbing, swimming, and rappelling through unpredictable terrain. Once you’re inside a canyon, there’s no turning around; you commit to the flow. Mistakes have consequences. Every knot, every anchor, every decision matters.
When I’m not navigating waterfalls, I lead a distributed team of software engineers as a Senior Security Software Architect in a large tech corporation. The difference between the two worlds seems obvious — one is made of stone and water, the other of code and systems — but the deeper I’ve gone into both, the more parallels I’ve found.
Both depend on trust, awareness, discipline, and teamwork. Both require pushing limits while managing risk. And both demand the same thing: that you care not only about reaching the goal, but about the people who make the journey possible.
This is what canyoning has taught me about leading engineering teams.
1. The Mission Isn’t Always Yours — But the Team Is
In canyoning, the mission is clear: get from the top of the river to the bottom safely. Sometimes the goal is exploration — a new canyon, a hidden waterfall. Other times it’s a rescue mission, where you go not because you want to, but because someone needs you to.
That distinction matters. In engineering, most of our missions aren’t chosen either. They’re driven by business goals, customer demands, or strategic shifts. We don’t always get to pick where we go — but we always own how we go.
Whether I’m descending a canyon or leading a distributed team through a product launch, the principle is the same: the mission might not be mine, but the team is.
My responsibility isn’t just to execute a plan; it’s to ensure that every member of the team is equipped, prepared, and supported to make it through whatever conditions arise. That’s leadership in its purest form — not commanding, but protecting the system that protects everyone else.
2. Training, Redundancy, and Knowledge Sharing
In canyoning, redundancy is survival. Every system has backups: a main anchor, a safety line, a second descender. But redundancy isn’t just about gear — it’s about skills. Everyone in the team must know how to rig an anchor, set a rappel, tie a knot, perform a rescue.
If only one person knows how to rig an anchor and that person gets injured, the entire team is stuck in a waterfall with no way out.
Now imagine the same thing in an engineering team. The “anchor rigger” is the person who knows how to deploy the CI/CD pipeline, or the one who understands the encryption module, or the one who manages production secrets. If that person disappears, everything halts.
In both worlds, knowledge silos are dangerous.
Sharing knowledge isn’t a luxury — it’s a safety mechanism. In canyoning, it keeps people alive. In engineering, it keeps systems alive.
Cross-training, documentation, pairing, and group troubleshooting aren’t just “good culture” — they’re what turn a group of individuals into a resilient, self-reliant team.
3. Awareness and the Human Factor
Inside a canyon, water and gravity never stop. You’re constantly assessing risk — not just external hazards, but the state of your teammates.
You watch how people move through the water, how they land a jump, how they breathe after a cold pool. You listen for tone changes in their voice. You learn to spot fatigue, hesitation, or fear before it becomes a problem. Saying “I’m good” is never enough; you verify it.
Engineering teams face their own kinds of pressure — cognitive, emotional, organizational. Deadlines, outages, and shifting priorities create a psychological current that can quietly wear people down. Someone who used to contribute energetically starts going silent. Another seems perpetually “busy” but disengaged.
If you don’t notice, the team’s current starts to fragment.
Just as in canyoning, awareness in engineering isn’t passive — it’s an active form of empathy. It’s reading the flow of your team and knowing when to slow down, when to push, and when to get someone out of the cold for a while.
A healthy team, like a good canyoning crew, thrives on awareness — not just of the environment, but of each other.
4. Trust, Communication, and Pragmatic Honesty
When you’re hanging midair in a waterfall, you trust that your teammate at the top built the anchor right, that the rope is correctly set, and that they’re paying attention. You can’t see them, but you trust them completely.
That level of trust doesn’t appear magically; it’s built through training, repetition, and constant communication. You shout signals over the roar of the water — short, clear, unmistakable words: “ROPE FREE!” “ON RAPPEL!” No ambiguity. No ego. No sugarcoating.
Engineering teams need that same kind of clarity. Honest, pragmatic communication is the rope that holds the group together.
When something’s wrong — technical debt, poor architecture, unrealistic deadlines — you can’t whisper around it. You have to name it directly and respectfully. Teams that speak the truth early avoid disasters later.
Psychological studies show that psychological safety — the belief that it’s safe to take risks or admit mistakes — is one of the strongest predictors of high-performing teams. It drives engagement, creativity, and innovation because people stop wasting energy on fear.
When engineers feel safe to say, “I don’t know,” “I need help,” or “This won’t work,” they behave like a canyoning team shouting through a waterfall — not afraid to be loud, because everyone’s listening.
5. Knowing When to Push, When to Retreat
In canyoning, sometimes the only safe decision is to stop. A sudden flood, a loose anchor, a thunderstorm above — and you must abort. It’s not defeat; it’s wisdom. The canyon will still be there tomorrow.
Engineering has its own versions of flash floods — failed deployments, impossible deadlines, unsustainable workloads. The pressure to “push through” can be intense, but knowing when to pause or pivot is often what keeps the team alive.
As in the canyon, retreating isn’t weakness; it’s strategic survival. It’s how you ensure the team has the energy and clarity to tackle the next descent.
Pride kills more projects than risk. Pragmatism saves more lives — and careers — than heroism ever will.
6. Adversity as a Catalyst for Innovation
The best canyoners I know are not those who never face problems — they’re the ones who improvise when problems hit. A missing rope, a blocked pool, a waterfall stronger than expected — you adapt with what you have.
That same spirit translates directly to engineering. Adversity forces creativity. A constraint becomes a challenge; a bug becomes an opportunity for learning.
But for adversity to produce innovation instead of fear, the environment must feel safe. When a team trusts each other, challenges spark ingenuity. When fear dominates, they freeze.
Research confirms this: teams with high psychological safety innovate more, learn faster, and recover from mistakes more effectively. (Open Psychology Journal, 2023)
In both canyoning and engineering, the mindset is the same: adversity isn’t the enemy — it’s the teacher.
7. Building a Canyoning Mindset for Engineering Teams
When you’re deep inside a canyon, surrounded by roaring water and slick volcanic walls, every move depends on teamwork.
No one gets out alone.
That same principle applies to engineering. The deeper and more complex the project, the more you rely on trust, clarity, and shared discipline.
Over the years, I’ve realized that the mindset that keeps a canyoning team alive is the same one that keeps an engineering team resilient.
Here are the core lessons I carry between the waterfall and the codebase:
1. Redundancy Saves Lives
In a canyon, you always back up your anchor — not because you expect it to fail, but because you know it could. In engineering, redundancy means sharing knowledge, documenting systems, and cross-training.
If one person disappears, the team should still be able to keep moving. That’s not bureaucracy — it’s survival engineering.
2. Check Your Teammates, Not Just Your Gear
Before every descent, we check each other’s harnesses and knots. Not because we don’t trust — but because we do.
The same goes for teams: check on your people, not just their output.
Metrics and dashboards are great, but they don’t tell you if someone’s mentally exhausted or quietly burning out. Awareness is the rope that holds the group together.
3. Clear Signals Over the Noise
Inside a canyon, the water is so loud that you can’t hear full sentences. You rely on short, universal calls: “ROPE FREE!” “ON RAPPEL!” “CLEAR!”
Engineering teams need the same clarity. Replace vague communication with simple, direct, honest language.
You don’t need motivational speeches — you need shared understanding.
4. Trust Your Belayer
When you step off a 40-meter waterfall, you trust that the person managing your rope knows what they’re doing.
In a team, that’s psychological safety. It’s the belief that you can take risks, ask for help, or make mistakes without being punished.
Without that trust, no one will move — in a canyon or in a sprint.
5. Know When to Stop
Sometimes the water rises too fast. The canyon floods. You call it.
Knowing when to stop, pivot, or refactor isn’t weakness — it’s maturity.
Courage in engineering isn’t about pushing harder; it’s about knowing when persistence turns into danger.
6. Water Always Finds a Way
No matter the obstacle, water always flows. It adapts, carves, and reshapes its environment.
That’s what great engineering teams do — they adapt to constraints.
Budget cuts, legacy systems, organizational silos? Flow around them. Creativity often starts where comfort ends.
7. Everyone Descends Together
In canyoning, success isn’t measured when the first person reaches the bottom — it’s when everyone does.
The same is true for engineering. A project isn’t a win if it burns out half the team in the process.
Celebrate shared outcomes. Design success so that everyone gets out of the canyon, stronger than before.
8. Final Descent: Leading with Awareness and Flow
A canyoning mindset isn’t about adventure — it’s about awareness.
It’s about backing up your systems, reading the flow, trusting your team, and adapting when the water changes direction.
The best engineering teams — like the best canyoning crews — don’t measure success by how fast they move, but by how well they move together.
They descend through uncertainty with trust, clarity, and respect for the current.
So whether you’re leading a team through code or through a canyon, remember this:
Redundancy keeps you safe. Awareness keeps you alive. And trust brings everyone home.