There I was, pressing plastic buttons and typing colorful little letters “bibipip bopopo”, when my tech manager called me into a meeting at the end of the day.
I froze cold.
I knew I had blown the estimated time on a task that sprint. In my head, that could only be a conversation about deadlines. Or worse.
Then it came.
“Elton, your performance has been exceptional and you’ve gotten a lot of praise from clients and POs. So I wanted to know if you’d be up for becoming a Tech Lead here at Cadastra.”
I locked up.
It took a few seconds to sink in.
Then I remembered my LinkedIn bio. I went to look and there it was, written by a past me who apparently knew more: “future Tech Lead”.
The future arrived sooner than I imagined. And well before I felt ready.
Because, in my head, to be a Tech Lead you had to “put in a lot of grind”. A lot more than coding well. A lot more than being a good “button presser”.
If I had still listened to my insecurities, my immediate answer would have been nope, no way. Too much responsibility. But thank goodness I said “can I think about it?”.
Impostor syndrome
I’ll admit it took me a while to write about this. Almost a year. I was waiting for two things: for the impostor syndrome to give me a break and for me to have something useful to share.
And the truth is this: becoming a technical lead isn’t a promotion. It’s a change of profession.
Being ready is a decision
I always admired my leaders: the way they speak in meetings, how they steer conversations with clients, how they navigate complex problems with an almost irritating calm. The answers came ready, sharp, as if they were obvious.
I had no idea how they thought like that, I only knew I wouldn’t rest until I could do it too.
So I accepted.
Not because I felt ready. But because after a whole day thinking about it I understood one thing:
Being ready isn’t a feeling. It’s a decision.
You’ll never “feel” ready for something that only exists after you decide to be it. Courage doesn’t come before the act. It comes alongside it.
I knew I had a gap. I knew there’d be a long road ahead. But the gap never stops existing, no matter the title.
The bug isn’t in the code
I discovered the obvious: being a Tech Lead isn’t about knowing everything, the way I demanded of myself. It’s about being a facilitator. A compass. Someone who absorbs, learns and translates the complex into the simple.
There’s a concept called “organizational debt”. It’s technical debt, but of people and processes. Same logic: if you ignore it, it accrues interest. When something doesn’t work in the team, the instinct is to think the problem is someone. It almost never is. The problem is the system around that person. If the deploy broke, the problem isn’t the guy who made a messy merge. It’s the system that allowed a merge with no review, no tests, no automatic rollback.
The transition from dev to lead is like going from writing functions to designing how they connect. A brilliant isolated function doesn’t become a system. A brilliant isolated dev doesn’t either. The value lives in the bridges: between people, between contexts, between what the client says and what the team understands.
It’s not about finding a bug in the PR before the tests do.
It’s about finding bugs in the processes. In the communication. In the way the team works. In the way decisions are made.
A number isn’t a system
Numbers are pretty. Numbers seem objective. But an isolated number is a microscope: it shows you a single cell and you think you understood the whole body.
Peter Senge, in “The Fifth Discipline”, has a mantra that stuck in my head:
The structure of the system determines behavior.
It’s not the people. It’s not individual effort. It’s the system around them. And systems have emergent properties: things that don’t exist in any isolated part, they only happen in the whole.
Quality is emergent. Performance is emergent. Culture is emergent. None of these things do you find by looking at a dev, a commit or a task. They live in the interactions, in what’s left over between the parts.
The classic example of a misleading metric is estimated vs actual. It’s the most common metric because it’s easy to calculate and fits neatly into a spreadsheet. And it’s one of the most useless, because it measures only a shadow of the work. It doesn’t tell you whether the architecture will hold up next quarter, whether the dev learned something along the way, whether the client trusts the team more now, whether the technical debt grew or shrank. None of what matters shows up there.
There’s even a name for this trap: Goodhart’s Law. When a metric becomes a target, it stops measuring reality and starts measuring how willing people are to game it. The estimates mold themselves to expectation, not to reality. The number survives. The real work doesn’t.
Senge talks about three levels of perception: events, patterns and structure. Most status meetings live at the event level: “task X slipped”, “bug Y showed up”. A mature leader climbs one level and looks for the pattern. Then climbs another and looks at the structure that generates the pattern. It’s there, at the structure level, that real intervention happens. Tinkering with events is bailing water with a sieve.
When this really works, nobody decides by looking at an isolated number. They look at the whole. They look at the trend. They look at weak signals. And they know that the most important part of the work (trust, psychological safety, collective learning) doesn’t fit in an Excel cell.
Silos aren’t a communication bug
Another place where systems thinking really got me was in knowledge management. Knowledge silos aren’t a communication failure. They’re the system working exactly as it was (not) designed. If there’s no path for the VTEX IO team’s knowledge to reach the FastStore team, the silo isn’t a bug: it’s the expected behavior.
Knowledge isn’t an artifact. It’s a flow. People leave, technology changes, memory decays. That’s automatic. Documenting is deliberate effort. If you don’t build structure for it, the organization pays to relearn what it already knew.
At Cadastra I saw this happening and decided to intervene in the structure. I built a centralized knowledge base that changed “ask the guy” into “check the docs”. I talk about it in detail in this case study.
The unplanned 1:1
One of the things that caught me most off guard was realizing that leadership has far more to do with perception than with technique.
It’s noticing that someone’s tone of voice changed from yesterday to today, and, because of that, scheduling a 1:1 ahead of time.
And in that conversation, finding out the person is going through a hard time and didn’t know how to bring it up.
And then you adjust course. You talk to the POs. You reorganize the sprint. You redistribute the load.
Not just to deliver, but to take care of whoever is delivering.
And there’s something I learned the hard way: “helping” isn’t showing up and solving. Helping is first understanding the context. Jumping in to fix something on the spot without understanding what’s around it can even make things worse.
When you understand, it becomes much easier to be a facilitator so the person can solve it on their own. And if that’s not possible, at the very least make sure they understand the process and can manage on their own next time.
This goes for code and it goes for people. The instinct when someone brings a problem is to solve it. To show that you know. But the leader’s role isn’t to be the one who solves. It’s to teach people to look in layers. Because the real solution almost never lives on the surface.
When you lead, you discover that many people on the team have a “Big Other” screaming in their heads. That invisible internal judge that paralyzes us. And part of your role is to create an environment where that Other loses its grip. Where people feel safe to make mistakes, to ask, to admit they don’t know.
There’s a nice name for this: psychological safety. It’s not being nice. It’s not avoiding conflict. It’s the opposite: creating a space where productive disagreement is possible. Google studied hundreds of internal teams and found this is the number one factor in high performance. It’s not seniority, it’s not the stack, it’s not the process. It’s the permission to be honest without fear of retaliation.
And building this starts with you. Before giving feedback to someone, ask for feedback about yourself. “What could I do or stop doing that would make it easier to work with me?” If you don’t ask that question, you’re asking for a courage you yourself don’t show.
Because if I had let my Big Other win in that meeting, I’d have said “no” and kept comfortably pressing buttons for the rest of my life.
Firmness isn’t rigidity
Being a Tech Lead is balancing project, client and, above all, people.
It’s pushing, but with awareness of reality. It’s caring, without losing direction.
It’s making hard decisions. Decisions that directly impact other people’s lives and careers. And once made, being firm about it. Firm, not inflexible. They’re very different things. Firm is not abandoning the decision at the first resistance. Inflexible is not listening when reality changes.
There’s a trap that catches many new leaders: the empathy that destroys. You care about the person, so you avoid saying hard things to not hurt them. It looks like kindness. But the result is that the person never knows where they stand. They get only generic “good job”. They know they messed up on something, but don’t know exactly what. They get no chance to grow. The kindness that omits is worse than the honesty that bothers.
And then there’s disagreement. I learned that in the vast majority of cases where there’s disagreement, all parties actually want the same thing. The end goal is the same. What differs is the path. So before defending my point, I first make the effort to understand the other person’s. Because there’s always the possibility that I’m wrong. And almost always the opinions are complementary, not opposite. The best solution usually comes precisely out of the friction.
There’s a line that stuck in my head: “Don’t move information to authority; move authority to information.” The guy with their hands on the code knows more about that context than you do. Your role isn’t to decide for them. It’s to make sure they have enough context to decide well.
And in the end, the biggest leverage is almost never technical. It’s human. It’s that 15-minute conversation that prevents 3 sprints of rework. It’s noticing that the quietest dev on the team isn’t “doing fine”, they’re stuck and ashamed to ask for help.
The biggest performance optimization you can make isn’t in the code. It’s in the people who write the code.
The first to raise their hand
Something I’ve carried since childhood: my parents taught me that, when we make a mistake, the first to raise their hand has to be us.
If you don’t look at yourself and don’t acknowledge your own mistake, it starts to look like you’ve never made one in your life. Then comes the tendency to take everything personally and waste time and energy pointing fingers, when it was much simpler to own the mistake, identify the gap and correct yourself.
You know why? Because the only thing you have absolute control over is yourself. With other people, the most you can do is create the conditions and show the way. The only one you truly change is yourself.
And from there, you teach. But you teach by demonstration, not by talking.
If you want a more communicative team, be more communicative. If you want a more technical team, bring technical solutions. If you want the team to study, study alongside them. Lead by example, not with pretty empty speeches.
And there’s one thing that holds all of this together: being in a constant state of reflection. Absorbing what you can and processing it to improve. Every conversation, every 1:1, every daily is raw material if you decide to look at it as input.
One day someone I lead sent me this message:
Man, I wanted to drop by to thank you for all this honesty you’ve been putting into every opportunity. I hope the colleagues understand what you say hahaha. This is really valuable and I’m not telling you this as a coworker but as a person.
I wasn’t expecting that. And it was one of the things that most confirmed for me that the path of honesty, even when it’s uncomfortable, is the right one. Not everyone will get it right away. But those who get it truly value it.
What I’ve learned (so far)
Those little “10 tips to be a better leader” lists are crap, and I’m not even in a position for that. But if I had to sum up what changed in my head over these months, it would go something like this:
Leadership is translation. You translate client demand into technical language. You translate the dev’s frustration into management language. You translate technical risk into business language. If you don’t know how to translate, no one understands each other.
Silence speaks louder than the code. When someone stops talking in the dailies, stops participating, stops questioning, that’s not “being focused”. It’s a warning sign. And it’s gradual. Retros that get emptier and emptier, questions that vanish from the code reviews, that person who always had an opinion and now just nods. It’s like heating water slowly: by the time you notice it’s boiling, you’ve already burned.
Vulnerability is strength. Saying “I don’t know” in front of the team was one of the hardest things I did. And one of the most powerful. Because when the leader admits they don’t know, they give everyone permission to do the same. And that’s when real learning begins. The way you react when you receive criticism defines whether people will give you feedback again or stay silent forever.
Knowing that you know is knowing, and knowing that you don’t know is also knowing!
“I don’t know much about this subject, but I’ve already talked quite a bit with about 10 people here at the company who know this stuff inside out and can help you in 2 seconds”. Better than us spending 2 hours here racking our brains or worse: giving incomplete guidance. Makes sense?
There’s no such thing as “failure”, only “crash course”. Pricey as hell, but a crash course. Every “failure” is actually a lesson in how not to do something. The problem is we treat error as an end when it’s really feedback. It’s the system telling you where to adjust. Testing until you get it right is literally the root of the scientific method and, for some reason, we forget that when the sprint gets tight.
The gap never closes. And that’s fine. Gödel proved that every consistent system has truths it can’t prove within itself. With people it’s the same: no matter how much you evolve, there will always be something that escapes your current domain. I came in thinking that one day I’d “get there”. Today I know that “there” doesn’t exist. It’s a spiral. Each turn you’re at a different level, but it never stops spinning. (If you want to know how I study to try to keep up with this spiral, I talk about it here.)
In the end, being a Tech Lead isn’t about having the answers. It’s about creating the space where the answers appear.
PS: if you’ve also thought “am I ready?”, you’re not. No one is. Go anyway and thank yourself later.