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.

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.

In praise of brutal software

Sat, 31 Jan 2026 11:00:00 -0300

Recently I’ve been watching a lot of content about architecture. Not software architecture, but actual buildings. There’s something about the way physical structures are designed and constructed that resonates deeply with how I think about software engineering.

Architecture, at its essence, is about crafting spaces where people can live, work, and connect. A building might be visually stunning or elegantly simple, but its true success lies in its livability. If it cannot be inhabited, it has missed its purpose. It might qualify as art, but it ceases to be architecture.

Engineering isn’t so different It’s easy to get caught up in abstractions, patterns, and the excitement of creating. We often fall in love with the craft: the cleverness of a design, the precision of an implementation, the elegance of the code. But elegance without purpose is just ornamentation. What we build isn’t meant to be admired from afar; it’s meant to be used, trusted, and integrated into people’s lives.

We create products through software, not the other way around. Our role isn’t to make technology fascinating — it’s to make it practical, reliable, and impactful. A system that’s technically impressive but disconnected from its purpose is like a museum exhibit: it might be admired, but it cannot be lived in.

That’s why true ownership begins long before the first commit, or even before the first line of code is written. It starts with understanding the problem, questioning the assumptions, and ensuring that what we’re building is worth building. Code may be the most visible part of the system, but clarity and purpose form the foundation that holds everything together.

And just like in architecture, we don’t build in isolation. Collaboration with design, product, and business teams is essential. Each perspective contributes to shaping a structure that is not only functional but also resilient and aligned with its purpose.

Over time, this mindset brings clarity to what engineering truly entails. It’s not about invention for the sake of novelty. It’s about creating something that earns its place, something people can rely on without ever needing to understand its inner workings.

Maybe that’s why I find myself drawn to architecture, especially brutalism.
There’s an honesty in its raw concrete, unadorned surfaces, and exposed structures. Brutalism doesn’t seek approval or admiration. It exists to fulfill its purpose, which is to provide shelter, stability, and longevity. And in that steady commitment to function, it reveals a quiet, understated beauty.

Brutalist buildings often evoke strong emotions, but their appeal is incidental, not intentional. Their beauty lies in their authenticity: every element has a purpose, and nothing is superfluous.

Good software shares the same essence.
It doesn’t rely on decoration or fleeting trends. Instead, it is purposeful, straightforward, and honest about its intent. If beauty emerges, it’s a byproduct of its authenticity, not a deliberate attempt to dazzle.

We don’t create to impress. We create to be used.
Code is merely the framework; the product is the structure it supports.
The finest architecture — whether physical or digital — is the kind that quietly fulfills its purpose, enduring long after its creator has stepped away.

Good enough to learn from

Fri, 16 Jan 2026 11:00:00 -0300

This is a reflection on choosing momentum over perfection, not as carelessness, but as a way to learn faster, decide better, and build things that actually matter.

I’ve always been drawn to beautiful systems. Clean abstractions, careful boundaries, code that feels intentional in every line. Early on, I mistook that feeling for excellence. I believed great engineering meant getting it right from the start, and that if you thought hard enough, designed carefully enough, you could arrive at something close to perfect before anyone ever used it.

That belief didn’t survive contact with reality.

A few projects that lingered too long in “almost ready” were enough to teach me that perfection doesn’t fail loudly. It fails by slowing everything down. A flawless idea, still trapped in your head or on a whiteboard, has no impact. A working version, even if an awkward one, already does.

The moment something real exists, the nature of the work changes. You stop arguing in hypotheticals and start dealing with evidence. Instead of debating what users might want, you can see what they actually do. An imperfect release creates a feedback loop that planning alone never will. It gives you signal, friction, direction. It reveals problems you didn’t anticipate and invalidates assumptions you didn’t realize you were making.

That loop of build, release, and learn ended up mattering far more than the internal satisfaction of pristine code. It’s also relieving once you accept that progress and perfection are not the same thing, momentum becomes easier to choose.

A sidenote here: There’s also a place for the opposite impulse. It’s okay to overengineer deliberately when learning is the goal and shipping isn’t. If you want to explore a design space deeply, build an overly elaborate abstraction, or follow an idea to its most complex conclusion, do it. There is real value in pushing systems further than necessary, in discovering their limits, and in understanding why certain approaches collapse under their own weight. As long as there’s no hidden pressure to release it, no illusion that this exercise must justify itself in production, that kind of work can be deeply formative. It sharpens judgment, not because the result is useful, but because the process teaches you what not to carry forward.

And back to the original track, shipping before perfect is often framed as carelessness, as if you’re lowering the bar or excusing sloppy work. I think that’s a misunderstanding. The real distinction isn’t between quality and speed; it’s between intentional trade-offs and indulgence. The question isn’t “should this be better?”, everything can be better. The question is whether the extra refinement meaningfully changes the outcome, or whether it only satisfies our own sense of craftsmanship.

There are moments when stopping to refactor is the responsible move. There are also moments when shipping and observing is the only way forward. Both can be acts of care, depending on timing. What matters is being deliberate about which one you’re choosing — and why.

When I feel stuck between polishing and releasing, I try to ground myself with a few simple questions. Does this change something important for the user, or is it mainly for me? Will waiting actually teach me anything new? If I release now, what’s the realistic downside and what information might I gain?

Those questions pull me back to impact. Because engineering, at least as I’ve come to understand it, isn’t about building elegant artifacts in isolation. It’s about creating things that matter in the real world.

Over time, I stopped thinking of software as something you finish. Software is alive. It evolves as users change, as the business shifts, as constraints move. Every release is just the best version so far. That’s not a compromise; it’s the nature of the medium.

Seeing it that way removed a lot of anxiety from my work. I no longer feel pressure to make something flawless before it’s allowed to exist. I focus on making it real. Once it’s real, improvement becomes continuous rather than blocked behind a perfectionist gate.

When I’m tempted to delay for one last improvement, I come back to a simple thought: would I rather have something to improve, or nothing to show?

The answer hasn’t changed. The best code I’ve written wasn’t the cleanest. It was the code that reached people, solved a real problem, and taught me something new. That’s what keeps me buildind one working version at a time.