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.

• 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?

• 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…

Trust

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

Years later, I discovered the well-known trust equation by Maister, Green, and Galford. It would have been incredibly helpful back then. It goes like this:

• 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.

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.

What would you tell your 2018 self?

• 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.