In June 2018, I joined mytaxi (FREE NOW), a competitor of Uber in the ride-hailing space, as Backend Chapter Lead. I was looking for an opportunity to grow in technical leadership. Honestly, I did not even fully understand what “Chapter Lead” meant. After some research, I learned it was part of Spotify’s squad (team) and chapter (horizontal domain, such as iOS, Android, Backend, Data, etc.) model, as well as tribes (groups of squads organized around vertical domains, for example, everything related to drivers).

Note: this article is a translation from the original “Soy Tech Lead y no me hacen caso. ¿Qué hago?”, in Spanish.

That role had two main components:

• Backend technical leadership (TL), driven by best practices and with a strong emphasis on continuous improvement. At the time, mytaxi was experiencing major traffic growth. Some services — for example, the one used to incentivize drivers to complete more rides — experienced significant traffic spikes and required improvements, re-architecting, and similar work. On top of that, there were a bit over 200 services to manage.
• People management in a horizontal setup. The idea was that all backend engineers would report to either Ariel, the other Chapter Lead, or me, regardless of their team. This was not a very orthodox setup, but at the time, around 3–5 backend engineers were joining every month. There was a strong need to make people productive as quickly as possible, align on architecture, and keep the product moving.

By the way, you have an incident in service X. Could you take a look?

This first interaction made several things very clear to me:

• Nobody really knows how to manage incidents, document what happened, or communicate progress. Great start.
• There is no culture of doing incident reviews or extracting actions to prevent similar incidents in the future.
• There is some coupling between domains. In this case, the Value Added Tax (VAT) concept was applied to two completely different use cases. A change in one of them caused the incident in the other.
• Many people do not know how to debug. They look at me as if the logs were talking to me, or as if I were Harry Potter.

• “Traits of a good Tech Lead”
• “I’m a Tech Lead, and nobody listens to me. What should I do?” ← This article
• “KPIs, SLOs, and operational excellence”. Coming soon. Subscribe so you do not miss it.
• To be continued…

---

Damn, nobody is listening to me. I put a lot of work into those slides and that strategy.

Today, the reason seems obvious to me. Titles do not grant influence. To influence, you need to build trust. And I had not earned enough of it yet to propose something so fundamental. Through my own experience and through coaching sessions, I have seen this exact mistake repeated several times throughout my career.

The trust equation. Generated with Gemini 3 / NanoBanana.

The first time I read it, my mind was blown because it described exactly what was happening to me. Let’s break it down:

• Credibility: knowing what you are talking about and having technical judgment. When you say something, people feel it is well-founded. In 2018, I might have had some of this credibility, but it had not yet been proven in that context, with those people, with those systems. I was coming from the outside. Imported credibility is always worth less — unless you come from a FAANG or have built a strong personal brand — than credibility earned on the ground.
• Reliability: doing what you say you will do. Being consistent and showing up when needed. In a high-paced environment like mytaxi, this matters a lot. In those first days, I was still learning where the logs lived. It is hard to demonstrate reliability if you do not even control the map.
• Intimacy: people feel they can talk to you, that you will not leave them exposed, and that you understand their fears and doubts. For a TL, this is more important than it seems. Without this, any technical proposal feels like a judgment. And when people get defensive, everything slows down.
• And then there is the denominator: self-orientation. When your proposals seem to serve your own agenda more than the team’s needs, trust collapses. That was my mistake. I arrived with a strategy too early, without listening, without seeing what they actually needed, without having earned the moral right to propose it.

In other words, even if my ideas were good, the equation still did not work out. I had some credibility, a bit of reliability still to build, intimacy yet to be created, and too much self-orientation. The result was obvious. Low trust.

Two key moments

Over time, I realized that trust is not built through big speeches, but through concrete actions that solve real, everyday problems. Looking back, two obvious moments accelerated the team’s shift in how they perceived me.

Regulatory complexity

One day, Maria — an Agile Coach — talked to me very directly about this pain. I did what I knew best at the time. I built something. I put together a portal — a bit rough, to be honest — that queried the configuration APIs of all services and aggregated that information by functionality, country, or city. Features could be browsed by city or by name. The website was very simple, generated from an HTML template by a Python service.

The features could be queried by city or by name. The website was very simple, with HTML generated by a Python service.

Debugging

Without realizing it, these two contributions did more for my reputation than any presentation or strategy deck. Building helpful things and standing by people when the system is on fire creates more trust than any title. That was when my ideas finally started gaining traction. Interestingly, these two actions reduced my self-orientation to zero. I stopped thinking about “my strategy” and started thinking about “our work”.

Looking back, one idea stands out. No, TLs don’t earn influence just because “it is their role”. It is earned every day, not through speeches, but by solving painful problems and being present when people need real support.

If you are in a similar situation, here is some advice I wish I had received in 2018:

• Before proposing a strategy, first understand what actually hurts your team.
• Pick one or two actions that deliver immediate value and execute them.
• Talk less about architecture and more about how your proposal reduces toil, risk, or uncertainty.
• Do not try to prove you are the smartest person in the room. Try to help others do their job better.
• Feedback cycles, unlike code, are slower. They are measured in weeks or months. Be patient.
• And above all, remember that trust is cumulative. It is earned in every interaction.

• For Tech Leads: a self-assessment traffic light to fight impostor syndrome and clearly understand where you are creating value and where you are burning out.
• For Engineering Managers: an evaluation traffic light to give objective feedback based on behaviors, not gut feelings. Help your Tech Leads have a real impact.
• For the team: an operational principles template to stop debating the same decisions every week and create shared criteria.

In addition, to complement this article, I will include a concrete plan for your first 90 days as a Tech Lead: what to observe, what to prioritize, what to avoid, and how to build trust through small, visible steps. It is the plan I wish I had had during my first week at mytaxi.

If you have already downloaded the toolkit, you do not need to do anything. You already have the updated version and will automatically receive the 90-day plan.