Gabriel Teles

Applause for the passes

Fri, 20 Mar 2026 12:23:16 -0300

I’m not someone who watches football often, even though it’s everywhere in Brazil. But every now and then, a match will be on TV, and something catches my attention. The crowd erupts when a goal happens, that last, decisive touch. And it should. The goal is what changes the score.

But if you watch closely, the real story starts much earlier. The passes, the positioning, the shared understanding between players moving in sync before anything is decided. The defender who intercepted the play two minutes before. The midfielder who saw the open space and held the ball just long enough. By the time the scorer touches it, the goal is already mostly built. The finish belongs to one person. The play belongs to everyone.

I think about this often when a team I’m part of ships something. A feature goes live, an incident gets resolved, a launch lands well, and there’s a natural pull toward the visible: who built it, who closed it, who was in the room. That’s not wrong. But it’s incomplete.

What I’ve learned to look for, and try to name out loud, are the contributions that don’t make it into the record. The refactor that made someone else’s work possible three sprints later. The code review that caught something quietly before it became a problem. The message sent at the right moment that unblocked a person who was stuck and didn’t want to say so. These are the passes. They rarely appear in retrospectives. They almost never appear in recognition. But they are, more often than not, what made the result possible.

When I lead, one thing I actively try to build is the habit of seeing those moments and saying something about them. Not as a ritual, not as a performance of good culture. Because what a team learns to celebrate shapes what they learn to value. And if only the goals get applause, people quietly start to stop making passes.

The goal still deserves the cheer. That doesn’t change. But the play that built it deserves to be seen. In the best teams I’ve been part of, it is. Not because someone instituted a process for it, but because enough people made it a habit, one acknowledgment at a time. The next play is already being built. It helps to know the passes count.

Default Mode

Fri, 13 Mar 2026 18:00:00 -0300

Picture three engineers facing the same broken production system.

The first one is already typing before anyone finishes explaining the problem. They’ve seen something like this before, not exactly this, but close enough. They’ll try something, see what happens, adjust. They move like someone who trusts their instincts more than any runbook.

The second one disappears for twenty minutes and comes back with the fix. No drama, no explanation unless you ask. The problem is simply gone, handled with the kind of precision that makes you wonder why it took the rest of the team so long to even see it clearly.

The third one fixes it too, but also writes down what happened, why it happened, and what should be done so it never happens again. The work takes longer. The pull request is larger than anyone expected. But three months later, when it happens again and they’re not around, the team knows exactly what to do.

Most teams have all three, in different proportions. The ones that struggle aren’t missing any of them. They just stop knowing when to let each one lead.

The pirate moves fast and improvises freely. They are at their best when the map runs out, when there is no established path and someone needs to make a decision with incomplete information and keep moving anyway. They ship things before they’re perfect because they understand, almost instinctively, that something real in the world is worth more than something polished in a document. They bend rules not out of carelessness but because they’ve learned that rules are usually written for situations that don’t quite match the one you’re actually in.

This is my natural mode. I’ve spent most of my career here, comfortable with ambiguity, quick to prototype, inclined to move before everything is defined. There is a real energy in this posture. Things get done. The team feels alive.

But pirate energy has a half-life. At some point the accumulated improvisation becomes its own obstacle: a codebase that only its authors can navigate, decisions made in motion that left no trace, a team of new people navigating by instinct because no one stopped long enough to write anything down.

The ninja operates with precision and economy. Where the pirate charges forward, the ninja finds the shortest path to the right outcome, no unnecessary noise, no collateral damage. They are the ones who locate the root cause while everyone else is treating symptoms. Who simplify something complex without drawing attention to it. Who resolve the thing that has been quietly degrading the system for months, without fanfare, often without anyone fully understanding what they did or why it worked.

This kind of practitioner is invaluable when a team has grown cluttered. When priorities are multiplying and the codebase is pulling in too many directions, a ninja cuts through to what actually matters.

The risk is a different kind of invisibility. Problems disappear, but the understanding of why doesn’t spread. Knowledge concentrates in a small number of people. The team as a collective gets weaker even as certain individuals get sharper. And when those individuals leave, as they eventually do, they take the map with them.

The samurai brings structure and principle. A long view. Where the pirate asks what can we do right now, the samurai asks what are we actually building, and will it hold. They care about craft not as an aesthetic preference but as a form of integrity. They write things down. They define the standards. They are the ones who, when the team is about to take a shortcut, quietly ask whether the shortcut is worth taking.

This mode doesn’t come naturally to me. But I’ve come to understand what it produces: teams that move with shared understanding, systems that new engineers can actually read, decisions that don’t need to be relitigated six months later. Samurai energy is what turns a collection of talented individuals into something that can sustain itself over time.

Taken too far, though, discipline becomes a way of avoiding the discomfort of uncertainty. Process becomes a substitute for judgment. The team produces careful, considered work and misses the window. A team so committed to doing things properly that they forgot to do them quickly enough to matter.

Every team has them, in different proportions and in different people. The mistake isn’t having too much of one. It’s forgetting to shift. Treating a mode that served the team brilliantly in one phase as a permanent identity rather than a temporary posture. Letting what worked become what we always do.

The earliest stage of building something, when the question is still whether the thing is worth building at all, demands pirate energy. You need people willing to move before everything is defined, to test ideas cheaply and abandon them without grief. Too much samurai discipline at this stage and you’ll spend months architecting a solution to a problem that doesn’t exist.

When the product starts to find its footing and complexity accumulates faster than understanding, you need ninja precision. Someone who can step back from the noise and make the minimum intervention that restores clarity. Too much pirate energy here and you keep adding speed to a system quietly coming apart at the seams.

When you’re stabilizing, scaling, or bringing new people in, you need samurai structure. The work of making the invisible visible, writing things down, establishing the shared language, building the foundation that lets a team grow without fragmenting. Too much ninja energy at this stage and the knowledge stays locked in people’s heads, fragile in ways no one notices until someone leaves.

The teams I’ve been part of that worked weren’t the ones where everyone shared the same instincts. They were the ones where different people held different defaults, and where there was enough self-awareness to let the right energy lead at the right moment.

That last part is harder than it sounds. It requires the pirate to slow down and document something even when it feels like friction. It requires the samurai to ship something imperfect and resist the pull to refine it further. It requires the ninja to surface their work and share the understanding, even when explanation feels beside the point.

And it requires everyone, leaders especially, to notice when the moment has shifted. When the energy that made the team excellent last quarter has become the thing quietly making them worse.

The goal isn’t balance in the static sense. It’s the ability to shift, in yourself, and in the teams you build. To read what the moment is asking for and move toward it, even when it means acting against your own instincts.

The sound of autonomy

Wed, 04 Mar 2026 21:40:00 -0300

I was thinking of a jazz place in Brasília, Beco do Jazz. It’s a pity it’s closed now, but years ago I witnessed something there that stayed with me. Someone would start a solo, and the rest of the band instantly adjusted. Each player found their place, made room, kept the music intact. The soloist was free to explore. But that freedom carried weight. To act meant that everyone around you adapted, trusting you to hold up your end of the song.

A brilliant tech lead I worked with, Bruno Pedroso, once described something musicians do that I remember as “beginning together.” Without counting, without looking, sometimes without even hearing each other clearly, they just know when to start. They feel the shared pulse between them, and once one begins, the others join almost instinctively. It isn’t coordination in any mechanical sense. It’s trust built slowly, through practice and attention and a quiet respect for the whole.

That’s what engineering at its best actually feels like

People trusted to take initiative, explore unconventional paths, decide what’s worth trying. And accountable precisely because of that trust, not in spite of it. Every decision touches something else: another system, another person, another promise. Autonomy isn’t the freedom to act without consequence. It’s the responsibility to think carefully about what your choices will mean for everyone playing alongside you.

Things go wrong sometimes. That’s part of it. When they do, the question isn’t who missed the note. The question is whether the rest of the band keeps playing, adjusts, and finds its way back to the melody together. A team that handles mistakes well isn’t one that avoids them. It’s one that knows how to recover without losing the rhythm. When someone slips, the others don’t stop to point. They listen, step in, and help bring things back on track. What matters isn’t the mistake itself, but what the team does next.

That kind of recovery only happens when people feel safe to act in the first place. Not safe from consequences. Safe from blame as a reflex. There’s a real difference between those two things. One produces caution. The other produces music.

That’s what autonomy feels like when it works: a kind of music. Everyone plays with intention, aware of the rhythm that holds everything together. Some moments stand out, others fade quietly into the background, but it all serves the same song. And when it works, it’s not because anyone stood out. It’s because the music held together.