Gabriel Teles

Getting into the taxi

Sun, 12 Apr 2026 17:27:50 -0300

Leandro was the first person who taught me something about leadership before I understood I was being taught. I was an intern at Brazil’s Supreme Federal Court, eighteen years old, doing work I didn’t fully grasp yet. One learning he shared stayed with me since then.

He talked about a man with a package that had to reach the airport. If it missed the flight, everything depending on it collapses. The only uncertainty was the city between him and the runway.

In one version, the man hires a taxi, hands over the package, gives the destination, and stays behind. From that moment, the task stops being something he does and becomes something he expects. Minutes turn into an hour. Traffic thickens. A collision blocks a major avenue. When the car returns empty-handed, the conclusion is immediate: the driver chose the wrong route, should have known better. The failure is clear, and it belongs to someone else.

In the other version, the man gets into the taxi with the package. The city is the same, the traffic is the same, the accident still happens. But when the car slows, decisions are shared. They talk about detours, about side streets that might be risky but faster, about calling ahead to buy a few extra minutes, about when to accept the flight will be missed and focus on minimizing the damage. Some choices help, others don’t. The package still arrives too late. But when the taxi stops, there is no argument, no frustration redirected at a single person, no illusion that competence alone would have beaten congestion. There is only a clear understanding of what was known, what was tried, and what the constraints actually were.

I’ve spent years watching both versions play out. People who delegate a destination and evaluate from a distance, armed with outcomes but blind to context. And people who sit in the car, watch the clock, argue about routes, take responsibility for the wrong turns, and face the delays together. The difference isn’t always visible from outside. But the people in the car always know who was there.

People don’t need leaders who only point at the airport and wait for updates. They need leaders willing to sit in the taxi, share the uncertainty, and own the detours. When failure happens in the car, it becomes collective and therefore useful. When success happens, it’s understood rather than mythologized. I don’t remember exactly what Leandro was responding to when he told me this. It was many years ago, and the specific situation has dissolved. What stayed was the image.

And the question it leaves behind: am I in the taxi?

Make it boring

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

There is a moment I recognize by now. I am moving through a codebase — fixing something, reviewing something, sometimes just reading — and a corner of it catches my attention. Not because it is broken. Because it bothers me. A pattern that could be cleaner, an abstraction waiting to exist, a decision that made sense two years ago and no longer does. The code is not stopping me. But it is talking to me, and I am starting to listen.

I have learned to notice when this happens, because what comes next is expensive. The mind shifts. The original task — the product problem, the user-facing thing that actually needed solving — moves to the background. What fills the foreground is the code itself. And the code, I have to remind myself, is not the product.

This distinction sounds obvious until you watch how rarely it governs decisions. Most teams treat code quality as a proxy for product quality, and up to a point that is not wrong. Poorly maintained code slows you down, introduces risk, makes the next decision harder than it needs to be. The correlation is real. But the relationship is not symmetric. A clean, elegant, architecturally satisfying codebase can coexist with a product nobody wants. The code can be a pleasure to work in and still be building the wrong thing.

Time and attention are finite. Every hour spent on an abstraction that was never causing pain is an hour not spent understanding why users are dropping off, or what the next feature should actually do, or whether the current direction still makes sense. These are not equivalent trade-offs. One of them compounds into product understanding. The other compounds into a codebase that feels good to its authors.

What I have come to believe is that the right goal is not a beautiful codebase. It is a boring one.

Boring means predictable. It means a developer can open a file they have never seen and understand what it does without effort. It means patterns are consistent, names say what they mean, the structure does not surprise. It means the code has no personality — no clever solutions, no idiosyncratic choices that reflect a particular developer’s taste on a particular afternoon. Boring code does not ask to be noticed. It simply works, and then it gets out of the way.

This is harder to build than it sounds, because the instinct moves in the opposite direction. Developers are problem solvers by disposition, and a codebase is a permanent, visible surface full of problems to solve. The senior ones know better, mostly — they have seen enough to understand that cleverness has a cost, that the brilliant abstraction you are proud of today becomes the thing a new teammate cannot decipher six months from now. But knowing better does not make the pull disappear. It just makes you more conscious of it when it arrives.

A boring codebase is not something you build once and move on from. It is something you maintain, in small acts, continuously. The naming convention you enforce in a review even when it feels pedantic. The refactor you decline because the existing code, however imperfect, is clear enough. The new pattern you resist introducing because the old one, however unsexy, is what everyone already knows. These are not passive choices. They are the daily work of keeping the code uninteresting — of preventing it from accumulating the kind of complexity that starts to demand attention it was never supposed to receive.

The discipline is in knowing what you are protecting. You are not protecting the code. You are protecting the attention that would otherwise go to it.

When a codebase is genuinely boring, something shifts. The non-obvious decisions become visible again. Not the ones about which pattern to use or how to structure a module, but the harder ones: what this feature should actually do, whether this is the right problem to be solving, what the user is really asking for underneath what they said. These are the decisions that determine whether the product works. They require the same cognitive resources the code was consuming, and they deserve them more.

I still feel the pull. I probably always will. But I have come to understand it as a signal worth questioning rather than following — a reminder that the codebase is trying to become interesting again, and that my job, in that moment, is to make it boring.

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.