After a long week of audits, late meetings, and code reviews, I needed to remember why I started building things in the first place. This reflection grew from that need — a reminder of what craft still means in a world that moves too fast.
It is Saturday. Rain hits the roof in long, slow bursts. The sky over the valley is gray and heavy. The house smells like wet wood.
The week that just ended was full of audits, code reviews, and meetings that stretched into the night. Everyone had a piece of the puzzle, but no one had the full picture. I left the office drained.
On Friday, a friend who plays the oboe asked me to help film a concert for a Baroque festival. I packed my camera and batteries, checked light levels, and cleaned lenses. The small routine of setting up gear gave me calm. It always does. The precision of it, the quiet focus before pressing record, resets my mind.
When the musicians started to play, I forgot about work. The sound filled the old theater. Every note was a reminder of time. Humans have played this music for hundreds of years. Each generation learns, repeats, and adds a trace of itself.
Why keep doing it? Why keep perfecting the same pieces?
Because repetition is not waste. It is care. Every player finds something new inside what already exists. The point is not novelty but mastery.
I thought about that later at night. The rain was stronger. My porch was soaked, but I sat near the small stove and watched the fire move. The conversation I had earlier that day with my friend Laureano came back to mind. We had talked about how many people now join engineering only for the promise of money or image.
It is a strange time to be an engineer. My social feeds are full of success stories that read like formulas: salary multiplied, promotions achieved, ladders climbed. Few talk about the work itself.
I closed the browser and looked again at the fire. The rhythm of the wood crackling was slow and steady. I needed that quiet to ask myself the question I keep postponing: What does engineering mean to me?
The first spark
The answer always takes me back to a small room in 2012. I was twelve years old. My father brought home an old computer from work. It did not start. He told me I could take it apart and see what was inside.
I had already seen computers before. The first one I ever saw was an old IBM XT. The shape of that machine, its sound and weight, stayed in my memory. Now I could open one.
I removed screws, cables, and boards with the care of a surgeon. When I looked at each part, I felt I was reading a secret language. My cousin, who was a systems engineer, helped me find replacement parts. After days of tinkering, the computer turned on again.
He told me I could try a system called Linux because it could still run on old machines. That name stayed with me. Around the same time, I started reading about the companies whose logos I had seen on big machines at my dad’s office: Sun Microsystems, Dell, Compaq, IBM. The more I read, the more I wanted to know who built them and why.
That led me to books on the history of computing. I learned about Ada Lovelace, Dennis Ritchie, Ken Thompson, Margaret Hamilton, Barbara Liskov, Grace Hopper, and Radia Perlman. They worked not for status, but for progress. Their work built the ground that we now walk on.
Those books became like music sheets. They preserved the story of how our craft began. They prevent us from forgetting the structure and intent behind what we build today. Just as musicians return to written notes to keep tradition alive, engineers can return to history to remember why we create. Without that memory, the practice loses its shape.
I was drawn to their discipline. They built not because it was profitable, but because it was necessary. They wanted to create tools that made human life better.
The noise and the signal
Years later, I work inside one of those large names. I help design and build systems that protect and maintain other systems. The scale is enormous. The problems are complex. But the feeling that started with that first broken computer still guides me.
Lately, though, I see a shift in how many people see this craft. Engineering feels less like a calling and more like a currency. The value of work is measured by salary brackets and visibility. The joy of building fades behind metrics and slogans.
But when I watch musicians play old pieces, I remember what real craft looks like. They rehearse for years to play notes that already exist. They do not chase novelty or fame. Their pride comes from control, precision, and honesty.
Engineering used to feel that way too. It still can. The code we write, the systems we design, the things we repair — these acts matter when they come from care, not from fear of being left behind.
The return to balance
The rain has slowed. The last logs in the stove glow orange. I think about the coming week, the meetings, the audits, the fixes waiting in the backlog. The work will be the same, but I will return to it with more intention.
Because what matters is not how far we climb, but what we build that lasts. Like the musicians who keep playing the same music, our work becomes part of a long chain of people trying to leave the world slightly better than they found it.
The weight of craft is not a burden. It is a kind of inheritance.
In recent years, I’ve spent time mentoring early-career engineers and designers. Some experiences stay with you, not because of a single project, but because they remind you what learning looks like when it’s new and fast. This short reflection comes from those moments.
“Some lights do not need to be lit. They only need space to burn.”
Rare talent shows up early. The person learns fast. They spot patterns before you finish the brief. Their code or design feels clean on the first pass. You notice it in the first week.
Mentoring this person requires a simple plan. Give real problems. Give context. Set high standards. Remove noise and politics. Offer a short feedback loop with clear examples.
Do not overprotect them. Friction builds judgment. Let them meet hard deadlines. Let them defend choices in review. Step in only when risk grows beyond their reach.
Keep your bar visible. Write crisp requirements. Model careful thinking in design docs. Ask for measurable outcomes and dates. Praise specifics, not traits.
Your own craft will sharpen. You will explain ideas in fewer words. You will cut filler from meetings. You will read code with new care.
The best mentors do not mold talent. They reveal it. They give direction without taking the wheel. If you meet someone like this, treat it as a rare privilege. Give them room. Hold the line. Grow with them.
Written after years of learning that good mentorship teaches the mentor first.
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.
