He estado trabajando en MercadoLibre durante 2 años y algunos meses como Senior Software Developer y en el último timepo he estado estudiando hacia dónde quiero armar mi carrera dentro de la empresa. Resolví que el camino más natural que encontré es el de formarme hacia Líder Técnico. Pero, ¿qué es lo que hace un líder técnico? ¿Cuáles son sus responsabilidades? A continuación hago una recopilación las respuestas que, en mi opinión, expresan las respuestas a esas preguntas.

Índice

Citas

Before you are a leader, success is all about growing yourself. When you become a leader, success is all about growing others.

Jack Welch

Lo primero es la persona; buscamos generar una unidad resiliente más parecida a una familia unida que a una máquina perfecta.

Sebastián Luberriaga

Becoming a tech lead required me to change my focus. Work is now less about me and working on the most technically challenging idea or the most fun project; instead, my focus is more on my team. How do I empower them? How do I remove the obstacles slowing them down?

Caitie McCaffrey

… you have to act as a software developer, a systems architect, a business analyst, and a team leader who knows when to do something single-handedly, and when to delegate the work to others.

… the value of planning isn’t that you execute the plan perfectly, that you catch every detail beforehand, or that you predict the future; it’s that you enforce the self-discipline to think about the project in some depth before diving in and seeing what happens. A degree of forethought, in places where you can reasonably make predictions and plans, is the goal. The plan itself, however accurate it turns out, is less important than spending time on the act of planning.

If one universal talent separates successful leaders from the pack, it’s communication skills. Successful leaders write well, they read carefully, and they can get up in front of a group and speak. They pay attention in meetings and are constantly testing the limits of their knowledge and the knowledge of the team.

… delegation is not the same thing as abdication. When you’re delegating responsibility, you’re still expected to be involved as much as is necessary to help the project succeed.

Do remember to be kind. It’s natural and perfectly human to want to be liked by other people. Many of us believe that the way to be liked is to be seen as nice — that niceness is itself the goal. Your goal as a manager, however, should not be to be nice, it should be to be kind. “Nice” is the language of polite society, where you’re trying to get along with strangers or acquaintances. Nice is saying “please” and “thank you” and holding doors for people struggling with bags or strollers. Nice is saying “I’m fine” when asked how you are, instead of “I’m in a really crappy mood and I wish you would leave me alone.” Nice is a good thing in casual conversation. But as a manager, you will have relationships that go deeper, and it’s more important to be kind. It’s kind to tell someone who isn’t ready for promotion that she isn’t ready, and back that up with the work she needs to do to get there. It’s unkind to lead that person on, saying “Maybe you could get promoted,” and then watch her fail. It’s kind to tell someone that his behavior in meetings is disrupting the group. It’s awkward, and uncomfortable, but it’s also part of your job as his manager to have these difficult conversations.

You have 10 productive engineering weeks per engineer per quarter.

Use the doubling rule for quick estimates, but push for planning time to estimate longer tasks

The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change, de Camille Fournier.

The work of supporting people was far more important to management success.

Bethanye Blount

Pro tips

  • Visualizar la realidad: es poco probable que sólo haya una versión. Nunca se va a tener toda la información que uno quisiera. Sin esta definición, reinará la confusión.

    • ¿Qué necesita ser creado?
    • ¿En qué dirección vamos? Determinar la imagen del éxito; tener un plan.
    • Contexto tecnológico y del negocio.
    • Restricciones de tiempo.
    • Ser un estándar de productividad y excelencia técnica.
  • Tener el detalle técnico de los sistemas en la cabeza para los stakeholders: contestar tanto las preguntas internas como externas.
  • Entender y predecir la necesidad de sus clientes.
  • Priorizar proyectos en base a estas necesidades.
  • Ayudar a planificar y organizar la ejecución de los proyectos que aportan valor.
  • Mantener el ritmo de entrega de valor, entendiendo los altos y bajos de las personas dentro del equipo.
  • Involucrarse con el código ayuda a generar confianza con el equipo, pero el rol tiene otras responsabilidades que sólo programar (por ej: 1a1 con los miembros del equipo).
  • Entender el vocabulario del negocio.
  • Conocer a los miembros del equipo, sus fortalezas/debilidades, objetivos de carrera. Aplicar diferentes estrategias dependiendo de estos factores.

  • Ciclos rápidos de feedback, no 1 por año. Para que sea formativo, tiene que ser frecuente e intencional:

    • Positivo: subrayar las cosas buenas que destacan.
    • Constructivo: tiene que estar acompañado de un accionable, para saber cómo corregirlo; mejor si es discutido entre los dos.
    • Tomar nota de las observaciones (malas y buenas, para mí y para los otros).
    • Pedir recomendaciones/entrenamiento, ayuda en situaciones difíciles.
  • Aprender y mejorar es crucial para la salud de las personas y los productos (generar slack y valorizar trabajo descubierto vs planificado).

  • Mentoring del equipo.

    • Desarrollar la paciencia y empatía.
    • Hablar en un nivel que el mentoree pueda entender (comunicación efectiva).
  • Elaborar un plan 30/60/90.
  • Comunicar mi estilo y expectativas.
  • Dedicar el 20% del tiempo en cada iteración a solventar deuda técnica.

Anti-patrones

  • Tomar todas las decisiones técnicas implica volverse un cuello de botella.
  • The Ivory Tower Architect: no involucrarse con el código base.
  • No cultivar la cultura dentro del equipo.
  • No escuchar las propuestas del equipo.
  • Perder la confianza del equipo: no estar disponible para ellos y estar equivocado muy seguido.
  • Esperar a tener toda la información antes de tomar una decisión.

  • Dar mal ejemplo:

    • Escribir código pobre.
    • No seguir estándares establecidos.
    • No estar en horario.
    • Pelear contra la empresa o los procesos.
  • Aplicar el mismo criterio de comunicación con todos.

  • Ser un Alpha Geek:

    • Querer tener siempre la razón.
    • Defender siempre mi postura.
    • Tener miedo de decir que estoy equivocado.
  • No tener el control del tiempo y dejar que otros organicen mi agenda permitiendo que me incluyan en cuenta reunión se les apetezca.
  • Pedir información sobre el estado del proyecto que puede ser obtenido por otras fuentes: métricas, código, on-calls events.

Eurísticas

  • Un líder técnico debe poder ver la foto completa del problema, más allá de los problemas locales de los sistemas individuales (relacionado con “visualizar la realidad”).
  • Aún si las responsabilidades están claras, hablar con mánagers sobre setear expectativas ayuda a ejercitar que todas las partes están del mismo lado mirando el mismo objetivo. Bajarlas a escrito en lo posible.

Fuentes