Chemaclass - communication

Trabajar con la Puerta del Garaje Abierta

2026-07-14T00:00:00+00:00

La mayoría trabaja con la puerta del garaje cerrada. Trabajan en privado y solo la levantan cuando el coche está pulido y aparcado. Los vecinos ven algo terminado. Nunca el trabajo.

La frase viene del escritor Robin Sloan. El investigador Andy Matuschak la convirtió en una práctica: notas e ideas a medio hacer visibles para cualquiera que pase por delante.

Abre la puerta.

Significa mostrar el trabajo cuando todavía está en marcha. El borrador con los nombres de variables feos. El experimento que llevas a medias. No la demo. El proceso.

Por qué la mantenemos cerrada #

Miedo, sobre todo. Una puerta cerrada te protege. Nadie juzga un desorden que no puede ver.

Así que escondemos los borradores. Solo subimos código cuando está limpio para sobrevivir a la revisión. Para cuando alguien ve el trabajo, cada decisión de verdad ya se tomó en privado.

Ese instinto parece seguro. Te cuesta justo los momentos en los que la ayuda todavía era posible.

Un resultado terminado solo se puede admirar. Un trabajo en marcha se puede moldear.

Lo que te da la puerta abierta #

Cuando la gente ve el proceso, puede cambiarlo. Un compañero detecta el enfoque sin salida antes de que le dediques otro día. Un junior hace la pregunta “tonta” que resulta ser el problema de verdad. El pair programming es esto en estado puro: la puerta abierta, en directo.

La puerta abierta también mata el mito de que los seniors no sufren. Cuando un junior te ve atascarte y buscar en Google un error que “deberías” saber, aprende cómo es el trabajo real. No los mejores momentos.

Yo viví esto con bashunit, mi librería de testing para bash. La publiqué imperfecta. Todo el que miró dentro del garaje la moldeó: bugs reportados, peticiones de features, pull requests. Igual con Phel y mi carpeta .claude pública. El espíritu del open source.

Pero una puerta abierta no basta #

Aquí está la trampa. Dejas la puerta subida, abres una PR, escribes notas en un documento compartido y esperas.

No llega. Nadie se pasea por tu garaje.

La visibilidad es pasiva. “Público por defecto” es el suelo, no la meta.

Dejar la puerta abierta no es lo mismo que invitar a alguien a entrar.

El skill no es la apertura. Es empujar la señal correcta a la gente correcta, a propósito.

Empuja la señal a la sala correcta #

Cada canal viene con una expectativa de quién lo lee. Ajustar tu update a ella es todo el juego. Publica en la sala equivocada y serás ruido o invisible.

Toda la empresa lo lee. #general. Publica solo lo que le importa a todo el mundo.
El equipo técnico lo lee. #engineering. Donde va un update de trabajo en marcha.
Quien tiene interés se apunta. #insights: novedades del sector, señales de clientes. Útil, pero nadie tiene que leerlo.
Nadie tiene que leerlo. #random. Di lo que quieras.

Mismo update, cuatro resultados distintos según dónde caiga. Aprende el mapa antes de emitir.

Cómo es una buena señal #

Un buen update no es “eh, he subido algo”. Lleva suficiente contexto para engancharse sin hacerte ni una sola pregunta.

Digamos que voy por la mitad de un piloto: una nueva forma de trocear y revisar pull requests, probada en un equipo. No espero al final. Un update corto va a #engineering: dónde estoy atascado, más una petición explícita. “¿Alguien ha probado esto con un monorepo?” recibe respuestas.

Cuando el piloto termina, el resultado va a la misma sala:

Qué probé y por qué importaba.
Qué funcionó, con un antes y un después concretos.
Qué no, con honestidad. La parte que falló es la más útil.
Qué harías tú para probarlo por tu cuenta.

Ambas son señales, no estados. Convierten el experimento de un equipo en algo que toda la organización puede copiar o tumbar. Esto es Ship, Show, Ask aplicado más allá del pull request.

Empieza poco a poco #

Elige una cosa esta semana. Un experimento, un borrador, un momento de atasco. Haz dos cosas: deja la puerta abierta y luego sal y dile a la sala correcta que está ahí.

Recibirás ayuda que no esperabas. Enseñarás a alguien sin pretenderlo. Y el miedo que mantenía la puerta bajada se verá más pequeño desde el otro lado.

El resultado pulido impresiona a la gente. La señal empujada es lo que mejora el trabajo.

Abre la puerta. Y luego señálala.

Habilidades Interpersonales

2024-09-02T00:00:00+00:00

Así que eres desarrollador de software, y has dominado lenguajes de programación, algoritmos y todo lo técnico. ¡Genial! Pero aquí está el asunto: las habilidades técnicas por sí solas no te llevarán tan lejos como podrías pensar.

Si no puedes trabajar bien con otros, no importa lo bueno que sea tu código, nadie querrá trabajar contigo.

Por qué las habilidades interpersonales importan en software #

En el desarrollo de software, la colaboración lo es todo. Los proyectos no son solo esfuerzos en solitario. Serás parte de un equipo, con otros desarrolladores, diseñadores, o incluso personas no técnicas como gerentes y clientes. Cómo comunicas, colaboras y manejas las opiniones que recibes puede determinar tu éxito.

El compañero brillante pero difícil #

Piénsalo. ¿Alguna vez has tenido ese compañero de equipo que es brillante pero difícil o casi imposible de trabajar con él? Quizás no escucha, se lleva todo el crédito, o hace todo más complicado de lo necesario. A nadie le gusta trabajar con esa persona, ¿verdad? Es lo mismo para ti. Si no puedes llevarte bien con tu equipo, no importa lo bueno que sea tu código.

Qué significa ser un buen compañero de equipo #

Ser un buen compañero de equipo significa escuchar a los demás, estar abierto a la crítica constructiva, compartir ideas, y lo más importante, ser respetuoso y considerado. Quieres que la gente disfrute trabajando contigo, no que lo eviten.

Las buenas habilidades interpersonales te ayudan a construir relaciones de trabajo sólidas, resolver problemas más rápido y crear un mejor ambiente de trabajo para todos. No solo aspires a ser un experto en programación, asegúrate de que también seas genial para trabajar.

El impacto a largo plazo #

A largo plazo, tus habilidades interpersonales pueden impulsar tu éxito tanto, si no más, que tus habilidades técnicas. Juegan un papel vital en el éxito de un equipo y hacen que la experiencia de trabajo sea agradable para todos los involucrados.

Las habilidades interpersonales son tan necesarias como las habilidades técnicas. Nadie querrá trabajar contigo si no eres un buen compañero de equipo.

¿Qué son las habilidades interpersonales? #

Las competencias que te permiten interactuar efectiva y fluidamente con otros.

Habilidades de comunicación fundamentales #

Comunicación: La capacidad de transmitir ideas claramente, escuchar activamente y participar en conversaciones significativas. Esto incluye tanto la comunicación verbal como la no verbal.
Empatía: Entender y ser sensible a los sentimientos, pensamientos y experiencias de otros. Implica ver las cosas desde la perspectiva de otra persona.
Inteligencia emocional: Reconocer y gestionar tus propias emociones y entender e influir en las emociones de otros.

Habilidades de colaboración #

Trabajo en equipo: Trabajar bien con otros para lograr objetivos comunes. Esto incluye colaboración, compartir responsabilidades y apoyar a los colegas.
Resolución de conflictos: La capacidad de manejar desacuerdos y disputas de manera constructiva, encontrando soluciones que satisfagan a todas las partes involucradas.
Negociación: Encontrar soluciones o compromisos mutuamente aceptables durante discusiones o desacuerdos.

Crecimiento e influencia #

Adaptabilidad: Ser flexible y abierto al cambio, ajustando tu enfoque según sea necesario para enfrentar diferentes situaciones o personalidades.
Liderazgo: Inspirar y guiar a otros, proporcionar dirección y fomentar un ambiente positivo.
Networking: Construir y mantener relaciones profesionales que puedan proporcionar apoyo, oportunidades y recursos.

Estas habilidades son esenciales en casi cualquier trabajo y ayudan a construir relaciones sólidas, mejorar el trabajo en equipo y crear un ambiente de trabajo positivo.

Por qué son más difíciles de lo que piensas #

A menudo se les llama habilidades interpersonales o blandas, pero dominarlas puede ser sorprendentemente desafiante, quizás incluso más que muchas habilidades técnicas. A diferencia de las “habilidades duras”, que son tangibles y a menudo se pueden aprender a través de unas pocas horas o días de estudio, las habilidades interpersonales implican navegar la intrincada red de emociones, experiencias y expectativas humanas.

Mientras que las habilidades técnicas pueden requerir que te sumerjas en documentación, ejecutes experimentos y refines tu enfoque, entender y relacionarte con las personas es mucho más complejo.

Los humanos traen sus sentimientos, antecedentes y rutinas a las interacciones, añadiendo capas de complejidad más allá de la lógica directa de las máquinas. Estos detalles personales moldean la realidad que percibimos, haciendo que las habilidades interpersonales sean una parte esencial pero compleja de la comunicación y colaboración efectiva.

El Dilema del Prisionero

2024-06-27T00:00:00+00:00

El Dilema del Prisionero es un experimento mental que muestra por que a veces no colaboramos, aunque nos convenga hacerlo.

Dicho de otra forma: a nadie le gusta que se aprovechen de uno. Es teoría de juegos básica.

El dilema plantea una decisión difícil: cooperar o traicionar. Y revela mucho sobre cómo sopesamos el interés propio frente al beneficio colectivo.

Premisa #

Fuente: Wikipedia

Dos miembros de una banda criminal son arrestados y encarcelados. Cada prisionero está en confinamiento solitario sin medios para hablar o intercambiar mensajes con el otro. La policía admite que no tiene suficiente evidencia para condenar a la pareja por el cargo principal.

Planean sentenciar a ambos a un año en prisión por un cargo menor. Simultáneamente, la policía ofrece a cada prisionero un trato. Si testifica contra su compañero, quedará libre mientras el compañero recibirá tres años en prisión por el cargo principal. Oh, sí, hay una trampa…

Si ambos prisioneros testifican uno contra el otro, ambos serán sentenciados a dos años en la cárcel. Se les da a los prisioneros un poco de tiempo para pensarlo, pero en ningún caso ninguno puede saber lo que el otro ha decidido hasta que haya tomado irrevocablemente su decisión.

Cada uno es informado de que al otro prisionero se le está ofreciendo exactamente el mismo trato. Cada prisionero solo se preocupa por su propio bienestar, por minimizar su propia sentencia de prisión.

Esto lleva a cuatro posibles resultados diferentes para los prisioneros A y B:

Si A y B ambos permanecen en silencio,
- cada uno cumplirá un año en prisión.
Si A testifica contra B pero B permanece en silencio,
- A quedará libre mientras B cumple tres años en prisión.
Si A permanece en silencio pero B testifica contra A,
- A cumplirá tres años en prisión y B quedará libre.
Si A y B testifican uno contra el otro,
- cada uno cumplirá dos años.

El Dilema del Prisionero Iterado #

Es igual que el juego normal, pero lo juegas varias veces con el mismo oponente y sumas las puntuaciones. Puedes cambiar de estrategia entre rondas. Tiene aplicaciones reales porque se parece a cualquier relación continuada.

Todo esto tiene que ver con la confianza, cómo nos comportamos y las normas sociales que influyen en nuestras relaciones.

La mejor estrategia en el Dilema del Prisionero iterado es empezar cooperando y luego imitar lo que hizo el otro en la ronda anterior. Así recompensas la cooperación y castigas la traición.

No confíes, verifica.

¿Qué Mata la Agilidad?

2024-05-30T00:00:00+00:00

Docenas de documentos y hojas de cálculo, reuniones tras reuniones, y sin embargo sin mucho impacto, resultan en desalineaciones del equipo, descubiertas demasiado tarde.

Cómo gestionamos una organización define su calidad. Una excelente gestión es crucial para evitar la trampa del Waterfall si buscamos construir un entorno Agile. Pero ¿por qué querríamos eso? ¿Qué hay de malo en la forma en que ya trabajamos?

Si ya estás feliz con cómo tú y tu equipo trabajan juntos, está bien. Sin embargo, ¿qué hay de reevaluar cómo trabajas para buscar mejoras potenciales?

Me refiero a evaluar tu sistema y cómo tú y las personas a tu alrededor actúan dentro de él. Lo que funcionó hace meses o años podría diferir de lo que podríamos descubrir hoy, como parte de la mejora continua.

No me gusta la política en el lugar de trabajo, donde cada equipo va a lo suyo en lugar de tener una dirección compartida más grande. Esto resulta en trabajo diario lleno de miedo desde arriba, pasado a las personas de abajo, manteniendo un ambiente de trabajo no saludable. Game of Thrones es genial como serie de ficción, pero no algo con lo que lidiar en el negocio diario.

Agile nació precisamente como respuesta al desperdicio excesivo generado por la política y la microgestión organizacional.

Controlar y el “rendimiento lento” necesitaba un enfoque más flexible. Cuando las personas adoptan una mentalidad fija, resisten el cambio, temen al fracaso y priorizan procesos rígidos y jerarquías. Esto entra en conflicto con las ideas centrales de Agile de abrazar el cambio, entrega continua con desarrollo iterativo, planificación flexible y fomentar la colaboración e innovación.

Una mentalidad fija lleva al miedo a la experimentación y una reticencia a desafiar el statu quo, reduciendo el progreso y el potencial de aprendizaje y crecimiento.

¿Qué mata la agilidad? #

Mentalidad fija: Resistencia al cambio, miedo al fracaso y priorizar procesos rígidos sobre aprendizaje y adaptación estrangula la innovación y flexibilidad.
Burocracia excesiva: Procesos complejos y documentación excesiva ralentizan la toma de decisiones y la capacidad de respuesta.
Microgestión: Liderazgo demasiado controlador socava la autonomía del equipo.
Falta de colaboración: Mala comunicación y trabajo en equipo dificultan el progreso.
Bucles de retroalimentación inefectivos: Impiden ajustes y mejora continua.
Miedo a la experimentación: Una cultura que castiga el fracaso desalienta la experimentación y el aprendizaje de errores.
Procesos inflexibles: Adherencia estricta sin adaptarse a las necesidades del proyecto.
Objetivos desalineados: Prioridades conflictivas reducen la eficiencia.
Falta de apoyo del liderazgo: Sin respaldo de la alta dirección, las iniciativas Agile pueden tener dificultades para obtener los recursos y el compromiso necesarios.
Malas prácticas técnicas: Descuidar la excelencia técnica y el buen diseño puede llevar a una base de código frágil que es difícil de adaptar y extender.

¿Qué puedes hacer al respecto? #

Aprende los básicos de Extreme Programming (XP) y Lean Software Development.

XP: Enfocado en prácticas de desarrollo de software y excelencia técnica, con prácticas específicas como pair programming y Test-Driven Development (TDD).
Lean: Toma un enfoque más amplio, enfocándose en eliminar desperdicio, optimizar flujo y mejorar procesos en toda la organización.

Radical Candor

2024-04-17T00:00:00+00:00

Kim Scott, ex líder de Google, desarrolló esta filosofía de gestión. Es un curso intensivo sobre cómo ser un gran manager: empático y orientado a resultados. La clave está en crear un entorno donde la gente se sienta segura para decir lo que piensa y hacer su trabajo con respeto.

Ideas clave #

El estilo de mando y control frena la innovación y daña la eficiencia del equipo. La colaboración florece cuando las relaciones humanas sustituyen al acoso y la burocracia.
Radical Candor busca que managers y líderes logren juntos lo que no pueden lograr solos, preocupándose de verdad por su gente.
Se trata de ser radicalmente honesto y abierto, sin dejar de ser amable y respetuoso.

Las dos dimensiones #

Preocuparse personalmente: Mostrar interés genuino en la vida, bienestar y metas de las personas. Ser humano y empático.
Desafiar directamente: Dar feedback específico, oportuno y útil, que sea amable y claro a la vez. Ser directo y orientado a resultados.

Los tres comportamientos a evitar #

Agresión desagradable: Ser demasiado crítico o agresivo.
Empatía ruinosa: Ser demasiado comprensivo o permisivo.
Insinceridad manipuladora: Ser falso o manipulador en tu feedback.

Radical Candor en acción #

Da elogios específicos y sinceros. Las críticas, amables pero claras.
Crea un entorno donde la gente se sienta segura para hablar con libertad.
Prioriza la colaboración y la innovación sobre el mando y control.
Preocúpate por tu equipo y desafíales a dar lo mejor de sí.

Al aplicar Radical Candor, managers y líderes construyen relaciones sólidas, motivan a sus equipos y logran mejores resultados.

Pair Programming Efectivo

2024-03-28T00:00:00+00:00

¿Qué es el pair programming? Dos personas trabajando juntas en el mismo problema, al mismo tiempo.

No se trata de que una persona muestre sus habilidades frente a otra, ni de que una persona tenga miedo de cometer errores debido al síndrome del impostor.

Cada persona tendrá un rol:

Navegador: prestará atención al panorama general; ej: arquitectura, relación entre colaboradores, diseño de objetos, etc.
Conductor: prestará atención a los pequeños detalles; ej: naming, convenciones de código, sintaxis de escritura, diseño de objetos, etc.

La pareja podría, y debería, intercambiar roles ocasionalmente; ej: cada X commits pusheados, cada 10 min,… depende de ellos.

El pair programming no debería considerarse una práctica solo para “seniors” hacia juniors, sino independientemente del nivel de experiencia de los miembros del equipo.

Se trata del flujo de colaboración, la comunicación de calidad, la ausencia de sentirse juzgado y la idea de dar la bienvenida a la vulnerabilidad con tus compañeros, sabiendo que te apoyarán y ayudarán.

Se trata de desafiarse constantemente mutuamente, buscando la solución más pragmática mientras se mantiene simple. Siempre buscando retroalimentación rápida al hablar entre ustedes, pero también sobre la solución que acordaron implementar y su dirección.

Se trata del bucle de retroalimentación corto, rápido e inmediato mientras hablas con tu compañero, quien revisa tu código sobre la marcha. Puedes guiar como navegador o ayudar al conductor a validar sus ideas en un panorama más amplio.

Se trata de la atmósfera constante de compartir conocimiento por defecto, reduciendo bus-factors y áreas de conocimiento aislado al máximo. Aumentando el enfoque al tener dos mentes trabajando en la misma tarea simultáneamente.

Se trata de cohesión de equipo y afilar el sentimiento de que pertenecemos. Cuando entendemos las fortalezas y debilidades de cada uno, nos daremos cuenta de cuánto podemos ayudarnos a crecer mutuamente.

¿Cómo puedes practicar pair programming? #

El pair programming puede hacerse de diferentes maneras:

Puedes empezar y terminar una tarea con pairing. Puedes limitarlo a 30, 60, 90 minutos. De cualquier manera, se recomienda tener pausas en el medio - Pomodoro.
Puedes empezar la tarea juntos y parar cuando uno de tus compañeros se sienta lo suficientemente confiado para continuar solo.

Depende del equipo, y de la tarea en contexto, decidir cuándo y cómo aplicar pairing para sacar lo mejor de ello.

Esto no significa que debas trabajar constantemente “sin importar qué” en pareja. No se trata de crear reglas; por el contrario, se trata de abrazar esta práctica hasta el punto de que te sientas confiado para elegir cuándo y cómo usarla para sacar lo mejor de ella.

El pair programming podría convertirse en una de las mejores herramientas en la caja de herramientas de tu equipo para las interacciones diarias. No porque lo hayas leído en algún lugar, sino por los beneficios que tú y tu equipo encontrarán.

Patrones Comunes #

Diferentes estrategias para pairing efectivo #

Driver-Navigator: Una persona está conduciendo el código (con el teclado), enfocándose en el aspecto de detalle de la tarea en sí. La otra es navegadora (sin teclado), teniendo una imagen más abstracta de la tarea en mente.
Ping-Pong: Cambio frecuente de roles driver-navigator en pequeñas interacciones, ej: cada N minutos, cada N commits, etc.
Backseat driver: El navegador se involucra activamente con el conductor.
Tourist guide: El navegador aprende pasivamente con el conductor.

Anti-patrones mientras haces pairing #

The silent partner: El navegador no participa, está en silencio.
The solo act: El conductor ignora todas las aportaciones del navegador.
Distracted pair: La pareja no se enfoca en el problema a resolver.
The Dictator: Una persona está diciendo qué hacer, ignorando las aportaciones del otro.
Philosophical pair: La pareja está haciendo bikeshedding en temas irrelevantes.
The code war: La pareja no llega a un acuerdo y comienza una guerra innecesaria, que desperdicia tiempo y esfuerzo.

¿Quieres más? Mira esto: Learning Through KATAS

La conclusión #

El pairing no es una regla que imponer, es una herramienta a la que recurrir. Úsalo cuando la tarea es compleja, el conocimiento está aislado o lo que está en juego es importante. Sáltalo cuando el trabajo es trivial. El objetivo nunca es “hacer siempre pairing”, es mejor software y un equipo más fuerte. Elige una tarea real esta semana, hazla en pareja e intercambia roles a menudo. Los beneficios aparecen más rápido de lo que esperas.

Gran Ingeniería

2023-12-30T00:00:00+00:00

Programar no es solo otro trabajo. Escribir software puede ser realmente divertido y, aún más, ¡puede ser tu hobby personal también! Podrías estar enfocado en programar, programar y más programar para subir de nivel tus propias habilidades profesionales.

Eso no tiene nada de malo. La práctica hace al maestro, y programar mucho te ayudará a mejorar tus habilidades de codificación. Pero hay otros aspectos que debes tener en cuenta para crecer como gran ingeniero.

Como ingeniero de software, tu trabajo no es “solo escribir código”, sino usar el software para resolver problemas reales de negocio. Para lograrlo, existen muchas metodologías. Pero en algo hay que estar de acuerdo: necesitas identificar y entender las necesidades de tu cliente para saber qué construir.

Necesitas conocer tu producto, al menos hasta cierto nivel, para diseñar tu software usando un lenguaje cercano al negocio. Esto ayuda a su evolución y calidad, y facilita el mantenimiento presente y futuro.

IT, Software, Producto y Personas están muy conectados. Entender la relación entre estos campos ayuda a cada persona a cumplir mejor sus objetivos.

Un gran trabajo en equipo no es solo la suma de las partes: multiplica el valor creado entre los compañeros. Para eso, saber comunicar bien es clave para generar claridad a cualquier nivel.

Por eso un gran ingeniero conoce de negocio, cliente, producto y programación. Entender estos puntos marca la diferencia entre un ingeniero promedio y uno excelente.

Imagen original de Nicola Ballotta.

Forming, Storming, Norming y Performing

2023-11-25T00:00:00+00:00

En 1965, el psicólogo Bruce Tuckman creó un modelo que describe cómo un grupo se forma y madura hasta convertirse en un equipo cohesivo y efectivo.

El modelo inicialmente consistía en cuatro etapas: “forming, storming, norming, y performing,” añadiendo una adicional “adjourning” en 1977.

Los equipos no siempre avanzan de forma lineal por estas etapas. A veces vuelven a una etapa anterior según las circunstancias.

Forming #

En esta etapa inicial, los miembros del equipo son cordiales pero tímidos, inseguros sobre sus roles. Dependen del líder para orientarse.

Objetivo: Los miembros se están conociendo, y hay un enfoque en definir el propósito, objetivos y roles del equipo.

Enfoque de liderazgo #

Proporcionar dirección y orientación claras
Definir claramente los objetivos, roles y expectativas del equipo
Actuar como facilitador, fomentando la comunicación abierta y ayudando a los miembros del equipo a conocerse.

Storming #

Surgen conflictos y desacuerdos cuando los miembros empiezan a expresar su individualidad. Pueden aparecer luchas de poder y desafíos a la autoridad del líder.

Objetivo: El equipo clarifica sus objetivos, los miembros aprenden a resolver conflictos y abordar diferencias de manera constructiva.

Enfoque de liderazgo #

Facilitar la resolución de conflictos
Reconocer y abordar conflictos de manera constructiva
Fomentar la comunicación abierta y honesta mientras guía al equipo a través del proceso de entender y apreciar perspectivas diversas

Norming #

La cohesión empieza a desarrollarse. Los miembros establecen normas y valores. Los roles se aclaran y surge un sentido de unidad.

Objetivo: El equipo se esfuerza por establecer normas, valores y un entendimiento compartido. Los miembros aprenden a apreciar las fortalezas y debilidades de cada uno.

Enfoque de liderazgo #

Fomentar la colaboración y la inclusividad
Animar a los miembros del equipo a establecer normas y valores colectivamente
Reconocer y celebrar las fortalezas individuales, fomentando un sentido de unidad y respeto mutuo

Performing #

El equipo funciona a pleno rendimiento, enfocado en lograr sus objetivos. Los miembros colaboran, confían entre sí y se apoyan mutuamente.

Objetivo: El equipo está comprometido con su propósito común y opera a un alto nivel de eficiencia y efectividad.

Enfoque de liderazgo #

Empoderar la autonomía y la confianza
Proporcionar oportunidades para que los miembros del equipo tomen propiedad de tareas y proyectos
Fomentar un ambiente donde los individuos se sientan seguros de sus habilidades y puedan colaborar sin problemas

Adjourning (o Mourning) #

Esta etapa marca el final de la tarea o proyecto. Los miembros pueden sentir cierta pérdida cuando el grupo se disuelve.

Objetivo: Reconocer y celebrar los logros del equipo, proporcionar cierre y reflexionar sobre la experiencia general.

Enfoque de liderazgo #

Reconocer logros y proporcionar cierre
Reconocer los logros del equipo y expresar gratitud por las contribuciones individuales
Facilitar una sesión reflexiva para capturar lecciones aprendidas y crear una experiencia de cierre positiva

Para llevar un equipo a alto rendimiento usando el Modelo de Tuckman, los líderes deben conocer las etapas y adaptar su estilo según la situación.

Esto significa dar orientación y estructura en forming, facilitar la resolución de conflictos en storming, fomentar colaboración y comunicación en norming, dar autonomía en performing, y reconocer logros en adjourning.

La comunicación regular, las actividades de team-building y resolver conflictos de forma constructiva son claves durante todo el proceso.

Resumen en video #

Conversaciones Cruciales

2023-10-31T00:00:00+00:00

Cuando hay mucho en juego, las opiniones difieren y las emociones se disparan, tienes tres opciones: evitar la conversación y sufrir las consecuencias, manejarla mal y sufrir las consecuencias, o leer este libro y aprender a comunicarte mejor cuando más importa.

Si no lo hablas, lo actuarás.

Capítulos #

Conoce tu corazón
Asegura la seguridad
Cuidado con volver a tu estilo bajo estrés
Haz el contenido seguro
Controla tus emociones
Comparte tus historias
Pasa de la conversación a los resultados

Puntos clave #

Una conversación crucial es una confrontación delicada con tres características:

Hay mucho en juego
Las opiniones difieren
Las emociones son fuertes

Ejemplos:

Llamar a un cliente que no ha pagado
Hablar con tu jefe sobre un ascenso que se retrasa
Confrontar a un compañero que no cumple con su parte
Discutir la herencia familiar con tus hermanos

Navegar una conversación crucial es como desactivar una bomba. Un movimiento en falso y las emociones explotan. La clave está en mantener un diálogo honesto y productivo.

Son conversaciones no planificadas. Las evitamos porque creemos que las empeoraremos. Reaccionamos mal porque somos humanos, y los humanos “se comportan peor en los momentos más críticos”.

La “Historia” #

Todos llegamos a una conversación crucial con una historia ya armada:

“A mi compañero no le importa el proyecto porque no viene a las reuniones”
“A mi jefe no le importa mi carrera porque no me ha ascendido”

Si entras con esa historia en mente, no hay espacio para el diálogo. Tu mente ya decidió.

Framework Cuando… Yo… #

Para abrir espacio al diálogo, asume que no conoces toda la historia. Necesitas la ayuda de la otra persona. Usa este formato:

Cuando [no vienes a las reuniones del equipo], Yo [temo que no te importe este proyecto].

Invita a la otra persona a compartir su propio “Cuando… Yo…”. Así pueden descubrir juntos el problema, malentendido o desalineación que existe.

La clave es ser asertivo y honesto con los hechos, no pasivo-agresivo. Esto reduce la actitud defensiva y facilita aclarar la situación.

Objetivo común #

Para evitar el choque y volver a un diálogo productivo, convence a la otra persona de que no eres su enemigo. Estáis del mismo lado. Comunica un objetivo, valor o propósito compartido:

“No quiero pelear. Solo busco una forma de que ambos consigamos [objetivo común].”

“Sé que a los dos nos importa [valor común]. Veamos cómo conseguir lo que ambos queremos.”

Asume buena fe. Cuanto más te involucres en un diálogo productivo, más fácil será encontrar acuerdos y trabajar juntos para resolver el problema de fondo.

Keynote: Dominando el Arte de las Conversaciones Cruciales #

Resumen en Video #

Ambiente de Trabajo No Saludable

2023-10-11T00:00:00+00:00

Un ambiente de trabajo no saludable tiene varios síntomas que afectan el bienestar físico y mental de las personas.

Cuando escribía sobre El Principio de Peter, mencioné: “Hablad entre vosotros. Si sientes que no puedes, eso es síntoma de un ambiente de trabajo no saludable, y es un problema mayor.” Pero, ¿cuáles son esos síntomas?

Síntomas #

De todos los posibles, estos son los que destacaría: alto estrés, mala comunicación, falta de reconocimiento, microgestión, falta de equilibrio trabajo-vida, trato injusto, pocas oportunidades de crecimiento, conflictos tóxicos entre compañeros, falta de objetivos claros, alta rotación, baja moral y cansancio constante.

Vamos uno por uno.

Alto estrés #

Estrés y presión excesivos. Puede venir de cargas de trabajo pesadas, expectativas irreales o falta de apoyo.

Mala comunicación #

La comunicación ineficaz (entre compañeros, equipos o con los jefes) lleva a malentendidos, frustración y conflictos.

Falta de reconocimiento #

Cuando sientes que tu esfuerzo no se reconoce ni recompensa, te desmotivas y tu satisfacción laboral baja.

Microgestión #

Los jefes excesivamente controladores asfixian la creatividad y la autonomía. Eso frustra y reduce la satisfacción en el trabajo.

Falta de equilibrio trabajo-vida #

Un equilibrio sano entre trabajo y vida personal es esencial. Jornadas largas, horas extra excesivas o expectativas irreales llevan al agotamiento y bajan la productividad.

Trato injusto #

La discriminación, el favoritismo o las oportunidades desiguales crean una atmósfera tóxica y divisiva.

Falta de oportunidades de crecimiento #

Cuando sientes que no hay espacio para avanzar profesionalmente, te desconectas y te sientes insatisfecho con tu rol.

Conflictos tóxicos entre compañeros #

Desacuerdos constantes o una atmósfera hostil entre compañeros crean un ambiente tóxico.

Falta de objetivos claros #

Necesitas orientación clara sobre tu rol, responsabilidades y lo que se espera de ti. Objetivos difusos o que cambian constantemente generan confusión y frustración.

Alta rotación #

Si la gente se va constantemente, es señal de que el ambiente no funciona para retener talento a largo plazo.

Baja moral y motivación #

Cuando la gente está desmotivada de forma constante, la productividad baja y el ambiente se vuelve negativo.

Cansancio físico o emocional constante #

Exponerse mucho tiempo a un ambiente así lleva al agotamiento físico y emocional, incluso a problemas de salud mental.

Estos síntomas varían de un sitio a otro. Abordarlos rápido es clave para crear un ambiente sano y productivo.

¿Qué puedes hacer al respecto? #

Tú mismo #

Abraza el cambio ¿Quién se ha llevado mi queso?
El proceso en sí mismo es el objetivo Cómo enfocarse y tener autodisciplina
¿Siempre has sido así? Cómo encontrar un equilibrio entre crecimiento y felicidad

Tus managers y líderes #

Gran liderazgo El liderazgo comienza dentro de tu propia vida y comportamiento
Entendiendo a las personas Malentendidos, comunicación efectiva y autorreflexión

Es Tu Barco

2023-09-20T00:00:00+00:00

D. Michael Abrashoff comandó el USS Benfold, un destructor de misiles guiados. En este libro cuenta cómo transformó el rendimiento y la cultura de su barco aplicando principios de liderazgo centrados en las personas.

Puntos clave #

Dar poder al equipo: Cuando la gente siente que confían en ella, se apropia de su trabajo y rinde mejor.
Escuchar y comunicar: La escucha activa y la comunicación abierta construyen confianza. Abrashoff se esforzó por conocer las opiniones y preocupaciones de su tripulación.
Liderar con el ejemplo: Los líderes marcan el estándar con sus acciones. Abrashoff trabajó para ser el modelo que esperaba de los demás.
Delegar responsabilidad: Dar control a la gente sobre sus áreas de experiencia les permite apropiarse de sus roles.
Fomentar la innovación: Abrashoff animaba a su tripulación a proponer e implementar mejoras en eficiencia y efectividad.
Celebrar los logros: Reconocer las contribuciones del equipo motiva a seguir rindiendo al máximo.
Asumir riesgos calculados: Abrashoff no dudaba en desafiar procedimientos establecidos si creía que llevaría a mejoras.
Construir confianza y respeto: Las relaciones sólidas crean camaradería y confianza mutua, pilares del liderazgo efectivo.
Ser adaptable: En entornos cambiantes, hay que ajustarse rápido a nuevas circunstancias.
Mejorar continuamente: Animó a su tripulación a buscar desarrollo profesional y aspirar siempre a la excelencia.

El libro ofrece perspectivas valiosas sobre liderazgo aplicables a cualquier organización. El enfoque de Abrashoff se centra en empoderar al equipo, fomentar la comunicación abierta y buscar siempre formas de mejorar.

¿Cómo Consigues que Todos se Sumen?

2023-08-02T00:00:00+00:00

Fui invitado al WeAreDevelopers World Congress para dar una charla técnica sobre mi experiencia con XP y los profundos beneficios de abrazar el cambio en tu trabajo y vida.

Con más de 12k asistentes, 300 speakers y ~10 tracks en paralelo, fui invitado a dar no una sino dos charlas. Una es sobre mi experiencia con Extreme Programming y los profundos beneficios de abrazar el cambio en tu trabajo y vida.

Disfruté especialmente la participación de la audiencia y las opiniones que me dieron después de cada charla. En particular, una pregunta que había enfrentado muchas veces durante mi carrera: “¿Cómo tratas con personas reacias al cambio?”

Este es uno de los temas más complejos que afecta a cualquier equipo, independientemente de su profesión. Pero, especialmente en nuestra industria del software en constante cambio, si eres reacio a abrazar el cambio, harás más daño que bien a tu equipo, carrera y a ti mismo.

Como se indica en Peopleware, “nuestra profesión del software es menos sobre computadoras y más sobre humanos y sus interacciones”. Este es usualmente el problema raíz para las personas; es un problema humano primero.

Para convertirte en verdaderamente agile, debes tener una buena base de confianza entre tus compañeros. Sin confianza, no hay equipo, y la responsabilidad principal de un buen líder es ayudar a crear un ambiente de confianza sin miedo a conflictos saludables. Todos sienten que pueden hablar y expresarse libremente en un ambiente seguro.

Un ambiente seguro significa que no necesitas llevar una armadura todo el día para protegerte de otros, así que tendrás más energía para impulsar la excelencia en tu lugar de trabajo.

Pero aún así, a pesar de tu esfuerzo por crear un ambiente de confianza y seguro, podrías encontrar personas reacias al cambio. Para esas, podrías necesitar probar diferentes enfoques. ¿Cómo puedes ayudar a crear confianza entre todos?

No tengas miedo al fracaso; en cambio, piensa que todo lo que haces es un experimento del que aprenderás algo. Y cualquier cosa que te acerque a un mejor estado es mejor que nada.

La clave aquí es encontrar una manera de conectar con las personas entendiendo cómo entienden su potencial para que puedas empoderarlas y ayudarlas a crecer.

Concede tiempo para leer #

Las reuniones 1:1 son ideales para establecer conexiones personales con tus compañeros. Sin embargo, podrías sentir que la situación requiere un empujón adicional, especialmente si tienes a alguien a quien no le gusta hablar de sí mismo, y es difícil saber qué piensan sobre lo que está pasando.

Aquí hay una idea que podrías probar:

Dales un libro que contenga ideas o conocimiento que podría beneficiar a todos.
Permite leer este libro durante el tiempo de trabajo, ej: los viernes después del almuerzo. Esta es una inversión de la empresa para el desarrollo de tu equipo.
El libro debería leerse en 3-4 horas, o un par de viernes, dependiendo del número de páginas.
No esperes hasta que el libro esté terminado para hablar sobre él. Sigue el progreso.
Tendrás grandes temas para discutir durante tu próximo 1:1.

Podrías usar cualquier libro para este ejercicio #

Cualquier libro estaría bien. Aún así, si estás buscando grandes ejemplos, estos son mis tres favoritos para empezar a impulsar una conversación:

Who moved my cheese? es una metáfora de las diferentes actitudes que las personas adoptan como parte de su identidad en la vida cuando tienen que confrontar cualquier cambio.
Extreme Programming Explained contiene una compilación de valores, principios y prácticas altamente relacionados con el toque humano en nuestra industria del software. Enfocándose en el aspecto del equipo, colaboración con tus compañeros y creando un sentido de maestría y propósito en nuestro oficio.
Start with Why aborda la importancia de empezar con “¿Por qué?” para definir un propósito para todo lo que hacemos.

Experimenta con cualquier libro, marco de tiempo, persona o grupo para crear un entendimiento compartido de los valores y motivaciones fundamentales del equipo. El objetivo es participar en el intercambio activo de conocimiento mientras cultivas un equipo que siente que pertenece, fomentando la pasión en el trabajo. Esto ayudará a crear confianza, y puedes empezar a construir sobre ella.

Si estás buscando libros para ayudar a escalar tus habilidades de liderazgo, aquí tienes: “Gran Liderazgo”.

No puedes forzar a las personas a cambiar. Por el contrario, cuanto más intentes forzarlo, más difícil te lo pondrán. En cambio, enfócate en entenderlas reconociendo lo que sienten y pensando sobre lo que hacen para crear un terreno común de entendimiento mutuo.

Fotos mías en WeAreDevelopers World Congress, Berlín 2023.

Gestión Ágil de Proyectos

2023-05-31T00:00:00+00:00

Una visión general básica y directa de lo que es Agile, presentando algunos ejemplos de frameworks bien conocidos hoy, como Scrum o Kanban, todo condensado en un libro de unas 100 páginas que puedes leer en un par de horas.

Capítulos #

El manifiesto fluido
Siendo ágil
Proceso ágil
Planificando para el éxito
Comunicación ágil
Fundamentos de Scrum
Introducción a Kanban
Construyendo un equipo adaptativo
Liderazgo y gestión colaborativa
Errores comunes detrás del fracaso ágil
Palabras finales: ágil es adaptación

“Los beneficios de los proyectos Ágiles se extienden no solo al equipo que lo usa, sino también al cliente que recibe el producto final.”

“Hay una métrica crítica subyacente que consistentemente lleva al éxito de un proyecto Ágil: la comunicación. La mala comunicación, la poca comunicación, o la comunicación deficiente de cualquier tipo lleva al colapso y fracaso de dicho proyecto.”

Puntos clave #

Los proyectos que seguían una metodología Waterfall tendían a exceder sus gastos con el tiempo, mientras que el producto entregado estaba por debajo del estándar y era difícil de usar.

Esa situación originó que un grupo de desarrolladores firmara un breve manifiesto de 68 palabras en 2001.

Un breve trasfondo #

Durante los años 1960, el software entró en una gran crisis; crear software era complejo pero cambiarlo después se convirtió en puro caos. Waterfall al rescate.

Waterfall delineó un conjunto simple y lógico de procesos que una empresa necesitaría seguir para que un proyecto fuera exitoso. Su nombre viene de la metáfora del agua cayendo suavemente en una corriente predecible, constante e incremental. Su ciclo de vida de desarrollo de software estaría en seis pasos simples.

Requisitos
Análisis
Diseño
Código
Testing
Operaciones

Durante 10 años, Waterfall fue la metodología estándar en el universo del software. Y durante 10 años más, el caos persistió. Aunque la intención era buena, la realidad es que el conjunto siempre cambiante de restricciones no se lleva muy bien con esta metodología porque cada paso depende del anterior.

El 86% del tiempo que una empresa usa el método Waterfall para gestión de proyectos, el cliente recibe software inadecuado o inútil. Muchos proyectos de software no se usaron o nunca se terminaron.

Durante los años 70 y 80, Desarrollo Iterativo e Incremental (IID) probó ser una opción viable. En los 90 surge la Entrega Evolutiva (ED), que cambia la situación. El desarrollador es responsable de escuchar las reacciones del usuario temprana y frecuentemente. El usuario comienza a jugar un rol directo en el proceso de desarrollo.

Unos años después, surgió un nuevo método Prototipado de Producción Iterativa Rápida (RIPP), más tarde llamado Desarrollo Rápido de Aplicaciones (RAD), que afirmaba “Software funcionando en 90 días… o te devolvemos tu dinero.”

Por último, durante los 90 se definieron en detalle Extreme Programming (XP), Scrum y Crystal.

Estas soluciones distintas pero similares estaban descentralizadas, trabajando independientemente unas de otras. Esta realización llevó a esa noche en Utah la unificación de estas ideas bajo una bandera, en un documento.

Agile se convirtió en el estándar definitivo para el desarrollo de software.

El Manifiesto Ágil #

Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación comprehensiva
Colaboración con el cliente sobre negociación de contratos
Responder al cambio sobre seguir un plan

Es decir, aunque hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda.

Trabajo Remoto Efectivo

2023-04-17T00:00:00+00:00

Un buen entorno de trabajo remoto trata a todos por igual: mismo acceso, misma información, sin importar dónde estés.

Parte 1 - Orientándose para el trabajo remoto #

Establece las bases del trabajo remoto. Hoy parece sentido común, sobre todo tras el covid, cuando no tuvimos más remedio que trabajar desde casa durante más de un año. Aun así, viene bien tener estos fundamentos por escrito para cuestionar suposiciones en los siguientes capítulos.

Capítulos #

Un futuro remoto: Una breve historia del futuro. Confinamiento. El remoto llegó para quedarse. Hora de prepararse.
Preparándose: La oficina: lo que queremos y lo que no. Lo básico, brevemente. En el mundo real. Instalando andamiaje mental. La regla de oro.

Parte 2 - Construyendo equipos remotos efectivos #

Seguro que alguna vez trabajaste desde casa antes de que fuera tendencia y te sentiste apartado de la dinámica del equipo. Por eso “tratar a todos como remotos” es tan importante cuando al menos una persona trabaja en remoto.

La forma de comunicar depende de la urgencia, la intención y cuánto debe durar el mensaje. Es la diferencia entre comunicación síncrona y asíncrona.

La calidad de los mensajes importa tanto como el canal. Una llamada no es lo mismo que un chat o un email. Usa la herramienta adecuada para cada mensaje y contexto.

Capítulos #

Tratar a todos como remotos: Ojos que no ven, corazón que no siente. Un principio para el cambio cultural. Tomando acción práctica. ¡Construyamos un modelo!
El espectro de la sincronicidad: Sincronicidad. Permanencia. Restaurando tu humanidad. Adelante a Hyrule.
Lo mismo pero diferente: Un día normal en la oficina. A través del espejo mágico. Conquistando el mundo oscuro. Descubramos algunos artefactos.
Artefactos para un futuro mejor: Comparando artefactos. Artefactos escritos. Artefactos de código base y grabados. Subiendo a bordo con el onboarding.
Onboarding y orientación: La curva de contribución. La ecuación del onboarding. Y aquí está el truco. Considerando la comunicación.
Técnicas de comunicación efectiva: Por qué los humanos comunican. Principios para mejor comunicación remota. Técnicas para mejorar las interacciones. Las herramientas correctas y cuándo usarlas. Volviéndonos hacia adentro.
Gestionándote a ti mismo: Una base organizacional. Sobre ser no observado. Navegando picos y valles. De ti mismo a los equipos.
Gestionando equipos: La ecuación de output revisitada. Reduciendo el factor de escala. Potenciando el factor de escala. Hora de subir de nivel.

Parte 3 - Creando una cultura remota de primer nivel #

Puede que una empresa 100% remota no sea posible por razones que escapan a nuestro control. Pero si la empresa dice ser “remote-friendly”, hay aspectos que vale la pena evaluar:

¿Tratas a todos como remotos?
¿Proporcionas configuración de espacio de trabajo remoto?
¿Gastas dinero equitativamente en personal de oficina y remoto?
¿Optimizas para la comunicación asíncrona?
¿Creas artefactos de las interacciones síncronas?
¿Mides al personal por su impacto?
¿Permites que el personal elija horarios flexibles?
¿Los miembros del equipo ejecutivo son trabajadores remotos?
¿Usas las mejores herramientas colaborativas que el dinero puede comprar?
¿Contratas personal en cualquier parte del mundo?
¿Apoyas a las familias así como a los empleados?
¿Devuelves algo a la comunidad local del empleado?

Un “Test de Joel” adaptado al trabajo remoto. El original nació en el año 2000, durante la burbuja punto-com: preguntas de sí/no para medir la calidad de un equipo. Si respondes “sí” a todo, probablemente el equipo funciona bien. Más sobre el Test de Joel original.

Capítulos #

El test de trabajo remoto: El test de Joel. Doce preguntas sobre trabajo remoto. Haciendo cambios en tu empresa. Algo que nos guíe.
Creando un handbook: El handbook de GitLab. Creando un handbook para tu equipo. Un handbook para la empresa. Haciendo el cambio completamente.
Volviéndose completamente remoto: El espectro de la remotidad. El desafío de adaptar cultura completamente remota. El triángulo de transición. Aprendiendo de pioneros. Ahora lo difícil.
Las partes difíciles: Caminando las curvas. El impacto físico y mental de trabajar remotamente. Apoyando a otros remotamente.
El camino hacia la igualdad es remoto: Diversidad e inclusión. Remoto: El gran igualador. Esto es solo el comienzo.

Resumen del libro #

Introduciendo un Nuevo Stack Tecnológico

2023-04-14T00:00:00+00:00

Cuando introduces una nueva tecnología en tu equipo, necesitas explicar el porqué y tener una estrategia clara. Va a afectar a todos.

¿Por qué ese nuevo stack tecnológico? #

Antes de decidir, recuerda que es una decisión de equipo. Piensa en la estandarización y mantenibilidad del proyecto. Pero lo más importante: ¿qué problema quieres resolver? ¿Es porque mola? ¿O hay una necesidad real que esta tecnología resuelve?

La dirección de la tecnología #

Cuando propones adoptar una nueva biblioteca, framework o tecnología, hay que conocer su trasfondo y hacia dónde se dirige.

¿Cuál es la motivación detrás de esa tecnología? ¿Por qué quieres añadirla a tu stack actual?

Acoplamiento y dependencias #

Al adoptar nuevas tecnologías en el día a día, es fácil acoplarse a ellas. Eso hace más difícil dar marcha atrás si después nos arrepentimos.

No me malinterpretes: aprender y experimentar con nuevas tecnologías está genial. Pero introducirlas en tu trabajo diario es otra historia. Afecta a todo el equipo, así que hay que ser cuidadosos.

El enfoque de la conversación #

¿Qué aporta esta nueva tecnología al proyecto?
¿Qué problema queremos resolver?
¿Podemos resolverlo con nuestra tecnología actual?
Si ya tenemos algo similar, ¿queremos mezclar ambas?
¿Cuáles son los trade-offs de usarla vs. no usarla?
¿Vale la pena la complejidad extra a largo plazo?
¿Cuál es la estrategia para que todos se suban al carro?

Architectural Decision Records (ADRs) #

Sea cual sea el resultado, escríbelo como un ADR para poder revisarlo con el tiempo. Un ADR documenta las decisiones del equipo: pros, contras y los argumentos que encontrasteis juntos para decidir qué hacer y por qué.

Los ADRs ayudan a entender decisiones antiguas. Guárdalos en el control de versiones, en el mismo proyecto si es posible. Son útiles para el equipo actual y para los nuevos que lleguen.

Gran Liderazgo

2023-02-27T00:00:00+00:00

Cuando el negocio crece, el foco de los líderes debe pasar de los clientes a los empleados. Quiero compartir los puntos clave que cualquier líder debería trabajar regularmente.

Para cada punto tendrás recomendaciones de libros que profundizan en el tema, con referencias de expertos reales.

Ya escribí sobre la belleza del liderazgo, y como un rápido resumen, para convertirte en líder, necesitas habilidades específicas:

Excelente comunicación, dando apoyo y habilitando a tu gente
Liderar con el ejemplo, especialmente para convertirte en una mejor versión de ti mismo
Pasión por compartir tus habilidades de liderazgo, para que construyas otros líderes

Para ampliar ese post con recursos y ejemplos, aquí encontrarás libros sobre los siguientes temas:

Motivación
Liderar a través del cambio
Empoderar a tu gente
Comunicación efectiva
Persuasión
Disfunciones de equipo
Principios de gestión
Mentalidad de CEO
Liderazgo de ingeniería

Para líderes “principiantes” #

Motivación #

Primero necesitas definir un propósito para tu liderazgo. Recomiendo “Start with Why” (Empieza con el porqué), que ayuda a clarificar la diferencia entre grandes líderes y los que no lo son.

“La capacidad de inspirar a quienes te rodean y lograr cosas notables comienza con POR QUE.” - Empieza con el porqué

El liderazgo no es ser el jefe de nadie sino servir a otros. Deberías ser un ejemplo que tu gente copiaría y seguiría, especialmente en tiempos difíciles. Esta es una filosofía donde el líder busca servir. “Leaders Eat Last” (Los líderes comen al final) profundiza en este tema.

Si quieres más, la guinda es “The infinite game” (El juego infinito), el tercer libro de Simon Sinek. Cuestiona nuestra mentalidad al confrontar problemas de negocio: la necesidad de una causa justa, liderazgo valiente, equipos de confianza y un rival digno.

“No existe la organización ‘correcta’. Solo existen organizaciones, cada una con fortalezas distintas, limitaciones distintas y aplicaciones específicas. Una organización no es absoluta. Es una herramienta para hacer que las personas sean productivas trabajando juntas.” - The infinite game

Liderar a través del cambio #

Liderar a través del cambio es algo que hay que afrontar muchas veces en la vida, te guste o no. “Who moved my cheese?” (¿Quién se ha llevado mi queso?) es una fábula sobre las diferentes actitudes que adoptamos al confrontar el cambio.

¿Cómo eliminas malos hábitos y creas buenos? “The Power of Habit” (El poder de los hábitos) y “Atomic Habits” (Hábitos atómicos) ayudan a entender que los hábitos son como un músculo. Puedes entrenarlos.

“Cambia cómo te identificas. El entorno es más importante que estar motivado. Reduce la fricción para los buenos hábitos y aumenta la fricción para los malos hábitos.” - Atomic Habits

Empoderar a tu gente #

Deberías empoderar a tu gente para que se conviertan en líderes. Recomiendo “Turn the ship around!” (¡Gira el barco!), donde el autor desafía el modelo de líderes vs. seguidores hacia una relación de líderes-a-líderes.

“El liderazgo es comunicar a las personas su valor tan claramente que se inspiran para verlo en sí mismas.” - Turn the ship around!

Comunicación efectiva #

La comunicación es una de las habilidades más difíciles porque constantemente te comunicas con personas de diferentes orígenes, experiencias, expectativas y visiones de la vida. Lo importante no es solo lo que dices sino cómo lo dices para que tu mensaje llegue bien al receptor.

“Leadership is Language” (El liderazgo es lenguaje) desafía el modelo de la era industrial (donde los líderes dan órdenes y los empleados las siguen), con estrategias como: controlar el reloj, colaborar, comprometerse, completar y mejorar.

“Tus palabras importan más de lo que piensas.” - Leadership is Language

Es importante reconocer nuestras emociones y no dejar que controlen nuestras acciones. Crear un ambiente abierto, honesto y seguro es clave para generar confianza.

“Dare to lead” (Atrévete a liderar) plantea que los líderes necesitan ser más vulnerables. Los valores sólidos te guían a hacer lo correcto en lugar de lo fácil. La confianza y las conversaciones difíciles importan, aunque te hagan sentir incómodo.

“Los grandes líderes deben ser valientes y siempre atreverse a dar retroalimentación constructiva, decir la verdad y ser claros sobre sus expectativas.” - Dare to lead

Persuasión #

En comunicación, necesitas buenas habilidades de persuasión para convencer a otros. “Never split the difference” (Rompe la barrera del no) es un libro sobre negociación de un ex negociador de secuestros del FBI. Ofrece ideas para negociar bien: empezar escuchando, usar espejos para fomentar empatía, empatía táctica para llegar a acuerdos, etiquetar emociones…

“La negociación comienza con escuchar, haciendo que se trate de las otras personas, validando sus emociones y creando suficiente confianza y seguridad para que una conversación real pueda comenzar.” - Never split the difference

Para líderes “experimentados” #

Asumiendo que has leído los libros anteriores (para “líderes principiantes”) puedo darte más recomendaciones.

Disfunciones de equipo #

Una de las áreas más difíciles en comunicación es gestionar conflictos. “The Five Dysfunctions of a Team” (Las cinco disfunciones de un equipo) aborda la “ausencia de confianza, miedo al conflicto, falta de compromiso, evasión de responsabilidad e inatención a los resultados” como una pirámide de disfunciones a vigilar.

Principios de gestión #

Aunque liderazgo y gestión no son lo mismo, conocer algo de teoría de gestión es útil. “High Output Management” es un gran punto de partida.

Si quieres más, recomiendo “The Essential Drucker” (Lo esencial de Drucker), que cubre los principios esenciales de la gestión.

“La gestión es sobre humanos.” - The Essential Drucker

Mentalidad de CEO #

No todos los líderes quieren ser CEO, pero “The Great CEO Within” (El gran CEO interior) ayuda a entender las responsabilidades desde el punto de vista más alto de cualquier organización.

“Adapt or Die” (Adaptarse o morir) cubre los aspectos fundamentales para prosperar en cualquier negocio: Producto, Estrategia, Motor de Crecimiento, Modelo Financiero, Personas, Operaciones, Proceso y Liderazgo.

“El liderazgo es sobre ayudar a las personas a adaptarse y liderar a través del cambio para que el negocio y su gente puedan prosperar.” - Adapt or die

Liderazgo de ingeniería #

Sobre ingeniería y crecimiento, recomiendo “The Manager Path” (El camino del manager) y “The Art of Leadership” (El arte del liderazgo). Ambos son fáciles de leer y llenos de sabiduría.

“Los managers te dicen dónde estás; los líderes te dicen hacia dónde vas.” - The Art of Leadership

Espero haber captado tu atención sobre las áreas clave en las que trabajar. Sé que hay muchos otros libros que podrían estar aquí. Quizás tienes otros en tu estantería. Estos son solo referencias, no necesariamente mejores o peores que otros.

Tengo muchos más libros pendientes de leer. Aun así, me pareció útil compilar estos para quienes no saben por dónde empezar o cómo convertirse en mejores líderes.

Los puntos esenciales a recordar:

Ten pasión por tu trabajo y compártela con quienes te rodean. No puedes esperar pasión de tus compañeros si tú no la tienes.
Empodera a tu gente, creando líderes en lugar de gente que sigue órdenes.
Aprende a crear un ambiente seguro, clave para la confianza y las relaciones honestas.
Ayuda a crear acuerdos al resolver conflictos. Evitar conflictos saludables no ayuda a largo plazo.
Busca oportunidades para crecer en todas partes y ayuda a tu equipo a crecer contigo.

Tu responsabilidad principal es ayudar a otros a mejorar. Y eso solo es posible si abrazas el cambio y empiezas contigo mismo.

Todos los autores mencionados #

Simon Sinek: Start with Why, Leaders Eat Last, The infinite game
Spencer Johnson: Who moved my cheese?
Charles Duhigg: The Power of Habit
James Clear: Atomic Habits
L. David Marquet: Turn the ship around!, Leadership is Language
Brené Brown: Dare to lead
Chris Voss: Never split the difference
Patrick M. Lencioni: The Five Dysfunctions of a Team
Andrew S. Grove: High Output Management
Peter F. Drucker: The Essential Drucker
Matt Mochary: The Great CEO Within
Thomas H. Douglas: Adapt or Die
Camille Fournier: The Manager Path
Michael Lopp: The Art of Leadership

Extra: Leadership Guide for the Reluctant Leader #

Especialmente si eres un desarrollador de software, este video es para ti.

“El liderazgo es para todos. Es para todos vosotros.”

Adapt or die

2023-02-26T00:00:00+00:00

A través de la historia de People First IT, este libro presenta El Algoritmo del Éxito: un sistema con potencial para transformar todos los aspectos de una organización.

Cada capítulo revela parte de la fórmula que las pequeñas y medianas empresas necesitan para triunfar. Con ejemplos reales, investigación y herramientas prácticas, el libro explica cómo crear innovación, resolver problemas de personas y ganar en los negocios.

“El liderazgo consiste en ayudar a las personas a adaptarse al cambio para que el negocio y su gente prosperen.”

¿Por qué fracasan los negocios? #

Los negocios fracasan porque…

no pueden o no quieren tener conversaciones valientes
se enfocan en el dinero demasiado pronto, olvidando a las personas
saben crear valor pero no escalarlo
no priorizan a las personas como responsabilidad principal
se enfocan en las personas pero carecen de las habilidades para marcar diferencia
escuchan para responder, no para entender
creen que sus problemas son únicos porque su idea lo es
viven dentro del negocio sin trabajar sobre el negocio
esperan que las cosas pasen sin liderar el cambio
luchan contra la verdad en lugar de abrazarla

¿Cómo hacer crecer tu equipo? #

“Cuando un negocio escala, el foco del dueño y el liderazgo debe pasar de los clientes a los empleados.”

La clave está en tener conversaciones valientes sobre las habilidades necesarias para el siguiente nivel. El objetivo: mejorar la experiencia profesional de cada persona y de quienes la rodean.

Puntos clave que todos podrían desarrollar:

Buenas comunicaciones
Enfoque y lograr metas y resultados
Todos contribuyen
Ofrecerse apoyo mutuamente
Buen liderazgo
Organización clara y buena
El conflicto constructivo impulsa la innovación

“Las personas no suelen ser el problema raíz. La taxonomía es 3Ps: producto, proceso o personas. ‘Personas’ va al final porque los líderes deben revisar primero producto y proceso. Es decir: las personas primero en valores, pero al último en culpa.”

El Algoritmo del Éxito #

Como muestra el diagrama, todo esto depende del liderazgo. Si liderar es ayudar a otros a adaptarse al cambio, debe ser central en nuestras organizaciones.

Producto #

Promesas
Resolver un problema o necesidad
Disparadores de liberación de efectivo
La forma en que creamos valor
Dolor o Placer
Innovación
Conexiones: Lógicas, emocionales y competitivas

Estrategia #

Perfil del cliente objetivo (Quién)
Estrategia de Creación de Valor (VCS)
Valores Fundamentales
Visión compartida
Ciclo de valor
Procesos clave

El Motor de Crecimiento #

Propuesta única de venta
Marketing dirigido
Canales de venta
Pasos de venta
Medición del Motor de Crecimiento
Gestión de embudo y oportunidades
Retorno sobre Ventas

El Modelo Financiero #

Gestión de ingresos
Costo de bienes vendidos (COGS)
Costos de ventas y marketing
Administración general
EBITDA, ITDA, NOI
Categorización
Reportes

Personas #

Alineación
Elevadores de personas
Resolución de problemas
Bancos de personas
Código de conducta del liderazgo
Planes de carrera
One-on-one’s
Gestión de ingresos

Operaciones #

Identificar las operaciones centrales
Responsabilidades
Gestión de cadencia
Reuniones
GSD (Get Shit Done)

Proceso #

Promesas Cumplidas
Downstream / Upstream
Responsabilidad
Repetible
Eficiencias

Puedes encontrar el libro en https://www.adaptordie.com/the-book/.

El juego infinito

2023-01-29T00:00:00+00:00

¿Cómo ganamos un juego que no tiene fin? Los juegos finitos (fútbol, ajedrez) tienen jugadores conocidos, reglas fijas y un final claro. Los juegos infinitos (negocios, política, la vida misma) son diferentes: los jugadores van y vienen, las reglas cambian y no hay línea de meta. No hay ganadores ni perdedores, solo avances y retrocesos.

Los líderes con mentalidad infinita entienden que “el mejor” no es un estado permanente. Se esfuerzan por ser “mejores”. Esa palabra sugiere un viaje de mejora constante y nos invita a contribuir con nuestros talentos y energía.

La pregunta clave es: ¿cómo jugamos para tener éxito en el juego en el que estamos? Simon Sinek ofrece un marco para liderar con mentalidad infinita:

Causa Justa
Liderazgo valiente
Equipos de confianza
Rival digno

#1 Necesitas una Causa Justa #

Una Causa Justa responde a: ¿Por qué existe tu organización?

Tiene que ser una causa por la que la gente esté dispuesta a sacrificarse. Trabajar más horas, dar sus mejores ideas, rechazar otras ofertas porque creen en lo que hacen.

Para ser felices necesitamos propósito. Los negocios no son diferentes. Al desarrollar una Causa Justa, hay que defender algo inclusivo que exista principalmente para beneficio de otros.

En resumen: una Causa Justa es una visión de futuro tan convincente que la gente quiere construirlo, aunque quizá nunca lo vea terminado.

#2 Necesitas liderazgo valiente #

Los líderes valientes sacrifican el corto plazo para avanzar en el largo plazo.

Liderar significa aceptar la responsabilidad de crear un ambiente donde las personas puedan dar lo mejor de sí.

Los más senior en una organización no son responsables del resultado. Son responsables de las personas que producen ese resultado.

#3 Necesitas equipos de confianza #

Un equipo de confianza es un ambiente donde la gente puede levantar la mano y decir “Me equivoqué. No me siento preparado para este trabajo. Necesito formación. Necesito ayuda. Tengo miedo.” Sin miedo a humillación ni castigo.

Sin equipos de confianza, tienes un grupo de personas mintiendo y fingiendo. Y les estás forzando a ello. No es su culpa. Has creado un ambiente donde nadie comparte errores porque teme meterse en problemas. Al final, todo se acumula y explota.

El líder es responsable del ambiente. Si el ambiente es correcto, tendrás equipos de confianza. Si no, estarás forzando a la gente a protegerse de ti.

#4 Necesitas un rival digno #

Tu único competidor real en un juego infinito eres tú mismo. Pero la competencia ayuda a revelar tus debilidades.

El objetivo no es ser el número uno (eso no existe en un juego infinito). Se trata de construir una base sólida y mirar a largo plazo.

El dinero es un resultado, no un propósito.

No existe la organización “correcta”. Solo hay organizaciones, cada una con fortalezas, limitaciones y aplicaciones distintas. Una organización no es absoluta. Es una herramienta para que las personas sean productivas trabajando juntas.

Los líderes con mentalidad infinita construyen organizaciones más fuertes, innovadoras e inspiradoras. Son ellos quienes nos lideran hacia el futuro.

Entrevista sobre XP y Agile

2023-01-09T00:00:00+00:00

Mi entrevista con devm.io sobre Agile y Extreme Programming.

devm.io: Hablamos con Chema, un desarrollador de software y experto en Extreme Programming, sobre su tema favorito y su próximo evento en vivo Update Your Team To Be More Extreme.

¿Podrías contarnos un poco sobre ti, quién eres y qué haces? #

Chema: Mi nombre es Jose Maria Valera Reales, pero todos me llaman Chema. Soy originalmente de España pero vivo en Berlín desde 2015. He estado trabajando como desarrollador de software desde 2013. En los últimos años, me he enfocado en alcanzar la excelencia y descubrir cómo ayudar a mis compañeros y, con ellos, a toda la comunidad de software a mejorar en nuestra profesión.

Actualmente soy Tech Lead en Lautsprecher Teufel GmbH, donde trabajo con el equipo del webshop de e-commerce. También disfruto del software de código abierto, así que me gusta crear pull requests para otros repositorios, y también me encanta cuando recibo pull requests de otros.

¿Cómo describirías Extreme Programming? ¿Qué lo hace tan “extremo”? #

Extreme Programming es el enfoque más directo y pragmático para abrazar Agile en tu equipo de software. Incorpora soluciones basadas en valores, principios y prácticas. No tienes que usar o hacer todo, sino lo que se ajuste a ti y a tu equipo en tu contexto. Sin embargo, estas son soluciones generales útiles que funcionan mejor cuando se combinan.

Desde mi experiencia, la palabra “extremo” puede ser engañosa, pero la veo como una oportunidad para enfatizar la dificultad de los fundamentos detrás de ella. El punto crítico es darse cuenta de que nuestro “sentido común” no es tan “común” como tendemos a pensar, ni las mejores prácticas para el trabajo en equipo efectivo. Por lo tanto, esto se trata de llevarnos a la efectividad extrema, colaboración y satisfacción mientras trabajamos con otros.

Organizarás un evento en vivo en devm.io sobre el tema el 19 de enero. ¿Podrías darnos un adelanto de lo que tu audiencia puede esperar? #

Exploraremos cómo funciona un equipo de software hoy en día, los problemas comunes que encontramos y qué soluciones podríamos aplicar para mejorar las rutinas de nuestro equipo. Buscaremos el verdadero significado de Agile, enfocándonos en las ideas de Extreme Programming.

Además, compartiré algunas ideas para ayudar a tu equipo a crear oportunidades de aprendizaje con ejemplos concretos que cualquier equipo puede incorporar en su trabajo actual.

Durante el evento, también nos contarás algo sobre Katas. ¿Qué son exactamente las Katas? #

El término “kata” proviene de los movimientos repetitivos hechos en karate que te ayudan a mejorar tus habilidades de combate.

¿Por qué “katas de código”? Porque como grupo, necesitamos practicar más. La mayor parte de nuestro aprendizaje ocurre en el trabajo, por lo que la mayoría de nuestros errores también se cometen allí. Y porque queremos mantener PROD, somos reacios a probar cosas nuevas.

Las katas existen para ayudar a los desarrolladores a obtener los mismos beneficios que obtendrías de la práctica en cualquier otra profesión. Estos ejercicios simples de simulación te permiten experimentar y aprender sin la presión de PROD. No hay respuestas correctas o incorrectas en ninguna kata de software: el beneficio viene del proceso, no del resultado.

Hay katas para ayudarte a mejorar tus habilidades de refactoring (como Gilded Rose Refactoring Kata de Emily Bache) o tus habilidades de testing (fáciles como Fizz Buzz o Roman Numerals, o más avanzadas como Bank Kata de Sandro Mancuso). También son geniales para construir confianza al programar con otros, observar y practicar diferentes roles colaborativamente, fomentar la cohesión del equipo, etc.

¿Qué papel juegan los métodos Agile en el desarrollo de software para ti? #

La primera pregunta aquí es definir qué son los métodos Agile. Al final, todos se comunican de alguna manera, dan retroalimentación a otros y simplifican hasta cierto nivel. A veces las personas tienen el coraje de decir lo que piensan y a veces no, y usualmente intentan respetar a sus compañeros. Así que, para mí, Agile es más sobre “cómo” haces ciertas cosas en lugar de “qué” cosas haces.

Agile es un proceso de trabajo altamente colaborativo a cualquier nivel, que podría tener una curva de aprendizaje desafiante al principio, pero vale la pena antes de lo que podrías esperar.

¿Qué tema en el área de agile debería recibir más atención? #

La construcción de equipos y abrazar la agilidad, empezando por preguntar “¿por qué?” Necesitamos desafiar el statu quo más a menudo y preguntarnos por qué trabajamos de la manera en que lo hacemos y cómo y qué podríamos hacer diferente para seguir mejorando y nunca dejar de aprender.

También puedes leer la entrevista desde el enlace original: https://devm.io/agile/extreme-programming-agile.

¿Ignorar Scrum para ser más Agile?

2022-12-06T00:00:00+00:00

Hablando con un amigo sobre agile, me hizo una pregunta interesante: a veces Agile y Scrum encajan mal, especialmente con las reuniones. Aquí van mis reflexiones.

“¿Crees que tendría sentido simplemente usar agile e ignorar scrum (sprints) completamente en una empresa basada en producto? Siento que es difícil ser agile cuando tienes 10 horas de reuniones por semana.” Filip G.

Esto conecta con la esencia de Extreme Programming: el primer valor es la Comunicación Efectiva.

“Probablemente algunas empresas no saben usar bien las reuniones y las hacen por costumbre.” Filip G.

No diría ignorar Scrum del todo. Scrum (bien hecho) es un gran “Framework de Gestión de Producto”. Para entenderlo mejor recomiendo: Scrum: The Art of Doing Twice the Work in Half the Time.

El problema principal con Scrum hoy es que la gestión tomó el control y los desarrolladores no saben practicarlo de forma realmente Agile. Ahí empieza el problema. Recomiendo Zombie Scrum Survival Guide, un libro divertido y fácil de leer que aborda los problemas típicos de equipos Scrum.

No es “Agile sí, Scrum no”. Son compatibles. El reto es enfocar los procesos del equipo desde una perspectiva agile.

Agile en pocas palabras #

Recientemente escribí un post sobre fundamentos agile, que te recomiendo leer para entrar en los detalles: Trabajando agile con equipos no agile. Pero, el tl;dr: Agile es sobre retroalimentación rápida. Es sobre comunicación efectiva y reducir desperdicio mientras se apunta a la simplicidad.

Agile es sobre mantener estos valores siempre presentes:

Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación de contratos
Responder ante el cambio sobre seguir un plan

Aunque hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda.

Scrum en pocas palabras #

Scrum es un framework de gestión de proyectos orientado al desarrollo de software, aunque se usa en ventas, marketing y más. Está pensado para equipos de 5-9 personas (ver número de Dunbar) autónomos y responsables de dividir su trabajo en partes pequeñas para completar en iteraciones llamadas sprints (1, 2 o 4 semanas).

Las ceremonias/reuniones típicas son:

Stand-up: 15 min (o menos) para sincronizar al equipo y actuar si alguien está bloqueado o necesita ayuda.
Refinement: ~2h para asegurar que los tickets están listos antes de planificarlos.
Planning: ~2h para planificar el trabajo del siguiente sprint.
Demo/Review: ~2h para mostrar el trabajo hecho al equipo, stakeholders e interesados.
Retrospectiva: ~2h para que el equipo reflexione y mejore.

La pregunta clave es cómo organiza tu equipo estas reuniones y, sobre todo, si son efectivas. Estas son solo algunas de las reuniones de cualquier “Equipo Scrum”.

Pero además de estas, se acumulan muchas otras reuniones. De pronto el día entero se ha ido y sientes que no has producido el valor esperado. Si tu trabajo no consiste en estar en reuniones constantemente, algo está mal.

Reuniones aburridas #

¿Has estado alguna vez en una reunión pensando “Esto es aburrido, qué pérdida de tiempo…”? Yo lo he vivido más de una vez. ¿A quién culpar? Esa suele ser la primera pregunta. Seguida de: “Mi jefe, obviamente. Él organizó esta reunión, me invitó, estoy obligado a asistir, y esta pérdida de tiempo es su culpa.”

No creo que sea una respuesta honesta. Culpar a otros y alejar responsabilidades es mucho más fácil que mirarse a uno mismo.

“Estoy obligado a asistir, y esta pérdida de tiempo es su culpa” puede ser cierto. Quizás estabas obligado y estás perdiendo el tiempo. Pero, ¿de verdad no hay forma de actuar al respecto?

Cuando algo no funciona como espero (no me gusta el resultado, creo que algo está mal), antes de culpar a otros prefiero reflexionar: ¿cuál es la raíz del problema? ¿Qué puedo hacer para mejorar la situación?

¿Qué puedes hacer al respecto? #

Volviendo al tema de “muchas reuniones”: si estás en una que se siente mal o aburrida, pregúntate:

¿Me aburro? ¿Por qué? ¿Quizás no participo en el resultado de la reunión? Si es así, ¿mi presencia es realmente necesaria? ¿Podría pedir un resumen después y salir para hacer algo más productivo?

O al revés: ¿está bien aburrirse en esta reunión? ¿Debería participar más y contribuir al resultado?

Veo este patrón:

Si la reunión no aburre, es productiva y dará buenos resultados para todos.
Si aburre, hay dos opciones: A) está bien que aburra, pide salir educadamente y pide el resumen después; o B) no está bien que aburra porque tu participación es necesaria. Involúcrate más con tus compañeros y la reunión dejará de ser aburrida.

Hay muchas estrategias. Depende de ti actuar cuando veas algo mejorable.

Está bien señalar el “elefante en la habitación” y pedir ayuda para mejorar cualquier situación que sientas que no funciona como debería.

Trabajando Agile con Equipos No Agile

2022-11-11T00:00:00+00:00

Asumamos que ya sabes qué es el manifiesto agile. Consideremos que aplicas la mayoría de los valores, principios y prácticas de “extreme programming”. ¿Cómo puedes trabajar con otros equipos que no son agile?

Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación de contratos

Responder ante el cambio sobre seguir un plan

Estás usando bucles de retroalimentación cortos, donde las cosas cambian constantemente. Puedes sentir que el equipo está vivo y cada uno es esencial.

Abrazas el cambio hasta el punto de que disfrutas saliendo de tu zona de confort cuando es necesario. Buscando crear valor para tu equipo y sus dinámicas, y siempre considerando el crecimiento personal.

Pero claro, asumamos todo eso, y todo lo demás que pueda haber olvidado respecto a la “agilidad”, ¿cómo podrías trabajar con un equipo externo que no es agile? ¿Cómo podría tu “equipo perfectamente agile” trabajar con otro grupo de personas que no tiene nada que ver con software? Por ejemplo, un médico.

Un médico no tiene tiempo para aprender sobre tus “valores y principios agile para desarrollo de software”. Un médico no tiene tiempo para aprender sobre “extreme programming”. De manera similar, no tienen tiempo para aprender sobre testing, diseño, arquitectura y buenas prácticas relacionadas con el software en general.

¿Cómo podrías crear un puente entre ese médico y tu equipo de software?

¿Cómo podrías trabajar agile con ese médico? #

Si necesitas trabajar con ese médico es porque él/ella debería ser un experto de dominio. Sugiero que uno o dos miembros de tu equipo se reúnan con ese experto durante 30/60 min, para que puedan hablar y compartir sus impresiones. Y luego repetir esto tanto como sea posible para acortar el bucle de retroalimentación. Por ejemplo, una vez a la semana.

Recopilar esos requisitos e impresiones de los expertos y luego dirigir el diseño de tu software de acuerdo con eso es Domain-Driven Design. Puedes encontrar mucha documentación sobre DDD en libros (como Domain-Driven Design Distilled) o en muchos blogs en Internet.

Sin embargo, el aspecto crítico aquí no es qué requisitos o impresiones se están resolviendo sino cómo. ¿Cómo podrías trabajar agile con ese médico?

Agile es sobre retroalimentación rápida. Es sobre comunicación efectiva y reducir desperdicio mientras se apunta a la simplicidad.

Al aplicar verdaderamente estos cinco valores, ya estás actuando de forma agile #

Comunicación
Retroalimentación
Simplicidad
Coraje
Respeto

Estos objetivos abstractos aplican a cualquier profesión, e incluso a la vida, no solo al software.

La comunicación continua ayuda a acortar el bucle de retroalimentación, lo que simplifica las tareas. Siempre con el coraje de abordar la verdad y respeto mutuo.

Las prácticas son las cosas que haces #

Sentarse Juntos
Pair Programming
Test First
Diseño Incremental
y muchas más

Y a pesar de tener un nombre técnico, podrían aplicar a cualquier profesión:

Sentarse Juntos & Pair Programming: pensar y hacer con otros compañeros

Test First: verifica tus suposiciones primero, luego resuelve el problema

Diseño Incremental: lo que sea que hagas, hazlo mejor incrementalmente

Los principios guían y motivan las prácticas hacia los valores #

Beneficio Mutuo
Diversidad
Fracaso
Oportunidad
Pasos Pequeños
Calidad
y muchos más

El beneficio mutuo es el más importante porque se trata de encontrar prácticas que nos beneficien ahora, a nosotros después, y también al cliente.

Otros principios incluyen la diversidad de ideas. No tengas miedo del fracaso. Mira todo lo que haces como una oportunidad de aprendizaje. Evita pasos gigantes porque tienen mayor riesgo de fallar. Apunta a un sistema de alta calidad porque son más predecibles y más fáciles de cambiar.

La pregunta permanece: ¿eres agile? #

Creo verdaderamente que un equipo agile es el que puede lidiar con el cambio a nivel de equipo. Por lo tanto, primero debes dominar agile dentro de tu equipo, y luego puedes colaborar con otros equipos de “manera agile”.

Una vez que hayas interiorizado estos puntos anteriores, puedes aplicarlos mientras trabajas con cualquier persona de cualquier equipo.

Aunque estas ideas aisladas son buenas, son aún más poderosas cuando se combinan. Crean una atmósfera de curiosidad y aprendizaje activo. Incluso podría despertar alguna pasión por tu profesión que construye un aura de cohesión de equipo, y así sin más, el equipo respira por sí mismo.

Todos se preocupan y asumen plena responsabilidad de mantener al equipo saludable construyendo confianza. No hay miedo a conflictos saludables. Se sienten empoderados y responsables de sus compromisos. El equipo celebra sus resultados y aprende de sus errores; ya no hay necesidad de máscaras.

Es entonces cuando la magia empieza a suceder, y de repente puedes trabajar agile con cualquier equipo, especialmente el tuyo.

Diferentes Creencias sobre la Calidad del Software

2022-10-08T00:00:00+00:00

Hace poco recibí una pregunta en Twitter que me hizo pensar bastante. Decidí compartir mis reflexiones al respecto.

El tweet que empezó esto #

Primero, algo de contexto: me siento muy bien porque el código base donde trabajo mejora cada vez más, así que tuiteé esto:

“A medida que el software mejora con el tiempo, puedes sentir que lo estás haciendo bien.”

Y entonces recibí una pregunta pidiendo sugerencias:

Así que aquí vamos…

Mi respuesta #

Crear acuerdos #

Lo primero es crear acuerdos sobre qué significa software de calidad para tu equipo y para ti. Esto aclara qué cultura de software quieres construir. Dejar tu empresa debería ser el último recurso.

Antes de pensar en irte, pregúntate:

¿Por qué crees que no puedes mejorar el código base de tu empresa?
¿Qué puedes hacer para reducir la fricción entre tus diferentes creencias sobre calidad?

No existe un código base perfecto. El software es una entidad viva que cambia constantemente. Para mí, software de calidad es el que puede adaptarse al cambio con facilidad.

Una vez que acordéis ese objetivo, hay muchas formas de lograrlo. Mi favorita es mantener una mentalidad agile con dosis de valores, principios y prácticas de Extreme Programming.

El software es sobre personas #

El software no es solo escribir código limpio y sólido. Eso es deseable, claro, pero primero hay que entender por qué lo queremos. El “por qué” se basa en los valores del equipo.

Si no compartís el mismo propósito, el mismo “por qué”, no disfrutaréis trabajando juntos. En ese caso, buscar otra empresa que comparta tus valores es una opción. Pero antes, intenta arreglar el problema de raíz y ayuda a tu equipo a mejorar.

Entendiendo tu por qué #

Primero necesitas entender tu “por qué” a fondo para transmitirlo a tus compañeros. ¿Has hecho todo lo posible para comunicar tu “por qué”?

Algunas ideas: fomentar la programación colaborativa (pair/mob), dar charlas técnicas internas, crear una cultura de compartir conocimiento a diario, cuestionar el statu quo y buscar oportunidades de mejora en todas partes.

Tu trayectoria profesional #

Si después de varios meses intentando estas ideas de verdad ninguna funciona, busca una empresa que comparta tus creencias. Al fin y al cabo, tú eres el principal responsable de tu carrera profesional.

Hilo de twitter original.

Pensamientos adicionales #

Si quieres que algo sea diferente, no esperes a que cambie solo. Intenta cambiarlo; si no funciona, déjalo. Quizás no es tu sitio.

Eso sí, reflexiona si ves este patrón repetirse a menudo (cambiar de empresa demasiado rápido). Si es así, quizás el problema no son las empresas sino tú.

El desarrollo de software no es solo código, es negocio. Hay que encontrar un equilibrio justo entre velocidad, costes y calidad según la situación. A veces conviene asumir algo de deuda técnica para llegar antes al mercado.

Ningún equipo debería tener “baja calidad” como parte de su identidad. Cada equipo tiene expectativas de calidad. La clave está en acordar qué es buena calidad.

Atrévete a liderar

2022-09-30T00:00:00+00:00

El liderazgo no va de títulos, estatus ni poder sobre los demás. Los líderes reconocen el potencial en las personas y las ideas, y se comprometen a desarrollarlo. Este libro es para quienes están listos para elegir el coraje sobre la comodidad y marcar la diferencia.

Coraje y vulnerabilidad #

Los líderes necesitan ser más vulnerables #

El problema es que la mayoría de las personas asocian esa vulnerabilidad como sinónimo de debilidad, pero eso no es cierto.

“La vulnerabilidad es la emoción humana universal que sentimos cuando nos exponemos a otros durante momentos de riesgo o incertidumbre.”

Y de esto se trata el núcleo del liderazgo: el coraje para actuar como debemos a pesar del miedo, la incertidumbre o el peligro en nuestro camino.

Valores #

El lugar de trabajo moderno puede sentirse como una “arena de gladiadores”. Aunque puede que no sea una cuestión de vida o muerte, todavía requiere valentía, y mucho esfuerzo y lágrimas, al punto de que podemos sentirnos tan abrumados que estamos tentados a irnos. Entonces, según Brené:

“Una de las fuentes más significativas de motivación para aguantar es tener absolutamente claros nuestros valores fundamentales.”

Los valores son los ideales que tenemos y que dan propósito a lo que hacemos en nuestra vida. Nos guían y nos dan algo a lo que aferrarnos durante tiempos oscuros y difíciles. Los valores fuertes nos guían a hacer lo correcto en lugar de lo fácil.

Honestidad #

Un gran líder fomenta el potencial en las personas y posee el coraje de guiar este potencial mientras se desarrolla. Una de las habilidades críticas para hacer esto es el coraje y la capacidad de dar retroalimentación honesta y abierta.

Desafortunadamente, muchos líderes tienen miedo de dar retroalimentación difícil y dejan a sus empleados en la oscuridad. Sí, a veces la verdad duele, pero a menudo evitamos las conversaciones difíciles porque nos hacen sentir incómodos a nosotros.

“Los grandes líderes deben ser valientes y siempre atreverse a proporcionar retroalimentación constructiva, decir la verdad y ser claros sobre sus expectativas.”

A largo plazo, esto es más amable y más productivo.

Confianza #

“La confianza es un aspecto esencial de nuestras relaciones laborales.”

7 comportamientos que fomentan la confianza #

Expresados junto con el acrónimo: BRAVING

Establecer Boundaries (Límites) - respetar los límites de cada uno
Reliability (Fiabilidad) - lo que significa seguir las palabras con acciones
Accountability (Responsabilidad) - ser responsable y reconocer los errores
Vault (Bóveda) - la capacidad de mantener privada la información confidencial
Integrity (Integridad) - elegir el coraje sobre la comodidad
Non-judgment (No juzgar) - hablar entre nosotros sin juzgar
Generosity (Generosidad) - asumir que las personas se encuentran contigo con las mejores intenciones

Fracaso #

La capacidad de fracasar y recuperarse de ello es una habilidad esencial para cualquier gran líder. El miedo al fracaso nos frena y nos impide alcanzar la verdadera grandeza.

Es crucial quitarse la armadura del perfeccionismo y saltar a la incertidumbre de la vida. Solo de esta manera ganamos realmente el coraje para tener éxito y liderar.

Resumen #

La Belleza del Liderazgo

2022-09-25T00:00:00+00:00

El liderazgo no es sinónimo de gestión, no tiene nada que ver con títulos o atributos personales. Entonces, ¿qué es? ¿Cómo podemos convertirnos en líderes? Y lo más importante, ¿por qué?

Investigando este tema, encontré “What is leadership” de Kevin Kruse, que me gustó mucho. Quiero compartir los puntos clave de ese post porque explica muy bien qué es y qué no es liderazgo.

¿Qué no es liderazgo? #

El liderazgo no tiene nada que ver con títulos. Tener un cargo de nivel C no te convierte automáticamente en líder. No necesitas un título para serlo.

Tampoco tiene que ver con atributos personales. No hace falta ser extrovertido ni carismático para practicar el liderazgo.

Liderazgo y gestión no son lo mismo. Gestionar implica planificar, medir, monitorear, coordinar, resolver, contratar, despedir… Los managers gestionan cosas. Los líderes lideran personas.

¿Qué es liderazgo? #

“Un líder es alguien que tiene seguidores.” Peter Drucker.

Esta definición es demasiado simplista y puede ser peligrosa. Que tengas personas “bajo ti” haciendo lo que dices porque “siguen órdenes” no te convierte en líder. Podrías ser un comandante, pero no necesariamente un líder.

“La capacidad de traducir la visión en realidad.” Warren Bennis.

Cada sprint, visualizas frutos en tu jardín. Y trabajas hacia ello y lo haces realidad. Esto te hace jardinero, no líder.

“Los líderes serán aquellos que empoderen a otros.” Bill Gates.

Empoderar a otros es esencial, pero falta la visión u objetivo común.

“El liderazgo es influencia.” John Maxwell.

Un manager tiene el poder de despedir miembros del equipo, lo que da mucha influencia. Igual que un ladrón con pistola tiene “influencia” sobre sus víctimas. Nos falta la fuente de esa influencia.

Entonces, ¿qué tal combinarlas todas? #

“El liderazgo es un proceso de influencia social, que maximiza los esfuerzos de otros hacia el logro de un objetivo.” Kevin Kruse

Elementos clave de esta definición:

El liderazgo comienza desde la influencia social, no la autoridad o el poder
El liderazgo requiere otros, no necesariamente subordinados directos
Incluye un objetivo
No hay mención de un título o atributos de ningún tipo

Fin de los puntos clave de “What is leadership” por Kevin Kruse.

¿Por qué alguien querría convertirse en líder? #

Hay dos concepciones diferentes en esta pregunta, y conviene separarlas desde el principio.

Por un lado está el “título de líder”, asociado normalmente con puestos de gestión. No me refiero a eso. Puedes ser un gran manager y un pésimo líder.

Un líder es alguien con actitud de multiplicador. Busca desarrollar habilidades (relacionadas con su influencia social) para potenciar el valor que genera.

Entonces, ¿puede cualquiera convertirse en líder? ¿Cuáles son esas habilidades necesarias?

¿Puede todo el mundo convertirse en líder? #

Con esta definición clara, podemos ver que el liderazgo tiene distintos grados según la persona y las responsabilidades que quiera asumir.

Para convertirte en líder necesitas habilidades específicas. Estas son las que considero más importantes:

Excelente comunicación, dando apoyo y habilitando a las personas a tu alrededor
Liderar con el ejemplo, especialmente para convertirte en una mejor versión de ti mismo
Pasión por compartir tus habilidades de liderazgo, para que construyas otros líderes

El liderazgo comienza dentro de tu propia vida y comportamiento.

Sé que no todos quieren aceptar los cambios necesarios para convertirse en líder. Pero creo de verdad que cualquiera puede desarrollar ciertas habilidades de liderazgo, lo que también significa inspirar a quienes te rodean.

¿Cómo convertirse en un mejor líder? #

Puedes inspirarte en muchas fuentes. Aprendes de tus errores y éxitos, y de quienes te rodean. Pero también es muy útil escuchar la sabiduría de gente fuera de tu círculo: podcasts, charlas TED, libros, audiolibros…

La belleza del liderazgo es que no pide permiso. Ni título, ni promoción, ni organigrama. Empieza en el momento en que decides elevar a quienes te rodean.

Entendiendo a las Personas

2022-08-22T00:00:00+00:00

Uno de los mayores retos es evitar malentendidos y aceptar que los demás no piensan igual que tú.

Percepciones diferentes #

Cada persona tiene experiencias y antecedentes distintos. Todos percibimos la realidad de forma diferente. Ser consciente de esto es el primer paso para entender tu rol en la comunicación con otros, y para desarrollar empatía.

Muchas veces, el verdadero problema detrás de la fricción en un equipo es la mala comunicación. A veces nadie sabe cómo ni por qué dos miembros del equipo ya no se llevan bien. Pero el conflicto es obvio.

El problema es que impide al equipo trabajar con eficacia. La razón suele ser la incapacidad de entender las motivaciones y problemas del otro.

Y eso lleva a malentendidos.

Malentendidos #

Lo que tú entiendes de una conversación puede diferir de lo que percibe la otra persona. Eso causa problemas. Y puede convertirse en algo serio que afecte la relación entre ambas partes.

¿Cómo resolverlo? #

Evitar malentendidos no es fácil, pero puedes mejorar paso a paso trabajando tus habilidades de comunicación.

Empatía #

Empatía es la capacidad de entender lo que sienten otras personas. Ver las cosas desde su punto de vista e imaginarte en su lugar. Ponerte en su posición.

Comunicación efectiva #

La solución no suele empezar por arreglar a la otra persona. Lo que ayuda es trabajar en ser más explícito. Por ejemplo:

Clarifica las expectativas sobre el objetivo común
- Crea conversaciones abiertas y honestas sobre lo que esperas
- Las suposiciones son peligrosas
Da tanto contexto como sea necesario
- Aunque te parezca evidente
Cada detalle cuenta
- Más información siempre es mejor que menos

Para comunicarnos bien, hay que reducir el riesgo de malentendidos al mínimo.

Autorreflexión #

Los conflictos saludables son normales y aceptables. No hay que tener miedo a los desacuerdos. Está bien cambiar de opinión al descubrir nuevas posibilidades. Cuanto antes, mejor.

En mi experiencia, entender a las personas es complicado por muchas razones. Pero sobre todo por los malentendidos que generamos por falta de contexto, más que por desacuerdos reales.

Si algo no funciona como esperabas, empieza mirándote a ti mismo. No culpes a otros. ¿Qué podrías haber dicho para crear más claridad? ¿Qué harías diferente?

La autorreflexión es esencial para mejorar y corregir tu actitud. Para adaptarte al cambio constante que nos rodea, especialmente cuando tratas con personas.

Mira más allá de tu área de influencia. Comparte tus ideas y no te avergüences de tus errores si los tomas como oportunidades de aprendizaje.

El Gran CEO Interior

2022-08-01T00:00:00+00:00

Matt Mochary hace coaching a CEOs de las empresas tech de más rápido crecimiento en Silicon Valley. Comparte sus herramientas de liderazgo y operaciones con cualquier CEO o manager del mundo.

El libro enseña a escalar tu negocio de startup a empresa con sistemas de responsabilidad, resolución de problemas y feedback transparente.

Leer, hablar con expertos, practicar y enseñar son las mejores formas de aprender y mejorar.

3 ideas clave #

Aprende a gestionarte a ti mismo antes de gestionar tu negocio.
No ignores los conflictos. Sé transparente, da y recibe feedback a menudo, y escucha activamente.
Obsesiónate con conocer a tu cliente. Haz mejores preguntas.

Resumen #

El equipo #

Evita sociedades 50/50. Aunque suena ideal, genera problemas cuando hay que desempatar.
Busca un socio con habilidades complementarias. Dale un buen porcentaje de la empresa; vale la pena.
El equipo fundador no debería crecer más de seis personas hasta tener product-market fit (PMF).
Las métricas de PMF importan: ingresos, tasas de renovación…

Hacer las cosas #

Lee “Organízate con Eficacia” (Getting Things Done) de David Allen.

Inbox cero #

Mantén tu bandeja de entrada limpia, como el triaje de un hospital.
- Distingue lo urgente de lo que no lo es.

Meta principal #

Reserva dos horas cada día para trabajar solo en tu meta principal.
Cuanto más temprano en el día, mejor.

Puntualidad y presencia #

No desperdicies el tiempo de los demás.
Si vas a llegar tarde, avisa cuanto antes.
Estate presente y enfócate en lo que se discute.

Si lo dices dos veces, escríbelo #

Documenta todos los procesos. Ante la duda, escríbelo.

Gratitud #

Enfócate en lo positivo.
Rendimos mejor cuando disfrutamos y nos sentimos bien.
Sé agradecido. Dile a la gente cuando hace algo bien.

Auditoría de energía #

Analiza tu tiempo: qué actividades te dan energía y cuáles te la quitan.
- Delega o externaliza lo que te drena tanto como puedas.

Salud #

Tu salud mental y física es tu recurso más importante.
- Cuídate y cuida a quienes te rodean.

Toma de decisiones #

Exige que quien quiera discutir un tema lo escriba antes, junto con la solución propuesta.
Lleva tiempo, pero produce decisiones mucho más reflexivas.

Conseguir compromiso #

La gente se compromete cuando siente que es parte de la decisión y su opinión importa.
A más influencia, más involucración.

Problemas y solución propuesta #

Quien presente un problema en una reunión debe traerlo por escrito.
- Incluir descripción del problema y solución propuesta. Nada de “no sé”. Al menos una hipótesis.
Los problemas se presentan en la reunión semanal.
Da 5 minutos para discutir cada solución.
- Si hay consenso, perfecto.
- Si no, usa el framework RAPID en lugar de seguir debatiendo.

La voz más fuerte en la sala #

Piensa quién está en la sala durante las discusiones grupales.
Evita influir en los demás: que escriban su voto o ideas antes de que tú compartas las tuyas.
Deja que los juniors pregunten y hablen primero.

Acuerdos descuidados #

Acuerdos descuidados: la gente no llega a tiempo o no cumple lo que prometió.
El antídoto son los “acuerdos impecables”:
- Definidos con precisión
- Acordados por todas las personas relevantes
Tiene que haber consecuencias por romper acuerdos.
Si no puedes cumplir, avisa cuanto antes a los involucrados.

Transparencia #

No ocultes información negativa.
La imaginación es más poderosa que la realidad.
Comparte toda la información relevante con tu equipo, buena y mala.
- Deja que se adapten.

Resolución de conflictos #

Los conflictos interpersonales casi siempre ocurren porque la gente:
- No comparte del todo sus pensamientos y sentimientos
- No se siente escuchada
Demuestra que has escuchado resumiendo lo que dijeron hasta que respondan “exacto”.

Identificación de problemas #

Pide a la gente que imaginen ser el CEO y respondan:
- “¿Cuáles son los 3 problemas más importantes a resolver en los próximos 90 días?”
Pide que escriban sus pensamientos sobre la empresa cuando sientan alegría, emoción, tristeza, ira o miedo.

Liderazgo consciente #

Interésate más en aprender que en tener razón.

Obsesión por el cliente #

Enfócate en el resultado, no en el output.
Resuelves un problema del cliente, no solo haces un producto.

Cultura #

No eliges tus valores. Los tienes.
Úsalos como guía para contratar y despedir.
Celebra. Reconoce los logros públicamente.
No midas horas. Mide resultados.
Evita la política de oficina: nunca dejes que el lobbying funcione.

Wiki de empresa #

Ten una wiki y haz obligatorio que los nuevos empleados la lean.
Si haces algo dos veces, documenta exactamente lo que hiciste.
- Todo el equipo debería contribuir.

Seguimiento de metas #

Nunca asignes una acción sin que la persona la acepte verbal o por escrito.

Áreas de responsabilidad #

Cuando varias personas comparten una responsabilidad, a menudo se hace mal o no se hace.
Asigna una persona a cada función en la empresa.

Sin punto único de fallo #

Documenta todos los procesos.
Entrena a una segunda persona para cada rol.

KPIs #

Conoce tus 5-6 KPIs más importantes y haz seguimiento constante. Que sean visibles para todo el equipo.

Colaboración #

Define visión y metas para empresa, departamento e individuo.
Comunícalas a cada miembro del equipo.
Haz seguimiento semanal del progreso.
Da feedback sobre qué va bien y qué hay que ajustar.

OKRs #

Apunta a 3 objetivos con 3 resultados clave cada uno.
Para empresa, departamento, equipo e individuo.
- Que estén alineados en cascada.
Objetivo = “¿a dónde queremos ir?”. No tiene que ser medible.
Resultados clave = “¿cómo sabemos que llegamos?”. Tienen que ser medibles.
Reúne a tu equipo de liderazgo con sus propuestas de OKRs para el trimestre.
- Deja que cada persona proponga los suyos. Se involucrarán más.

Feedback #

Nunca des feedback negativo por canales unidireccionales (email, mensaje, buzón de voz).

El problema de no dar feedback #

No verás los problemas de tu empresa.
La comunicación se romperá.
Tu mejor talento se irá.

Las 4 A’s para pedir feedback #

Pídelo.
Reconócelo: repite lo que dijeron. Que se sientan escuchados.
Agradécelo.
Actúa.

Cómo dar feedback negativo #

Pide permiso.
Describe el comportamiento (hecho).
Di cómo te hace sentir (sentimientos).
Comparte tus pensamientos y opiniones (historia).
Haz una petición: qué cambio te gustaría ver.
Pregunta si aceptan el feedback.

Recaudación de fondos #

Elige un socio, no una empresa.
Para contactar a un inversor, pide a 3-5 personas de tu red que lo conozcan que envíen un email de recomendación.
Concentra las referencias en la misma semana para que te noten.
Habla de tu empresa cuando el inversor ya confíe en ti.
Véndete a ti mismo, no solo la empresa.

Reclutamiento #

Dedica poco tiempo a candidatos que no vas a contratar y mucho a los que sí.
Como hiring manager, escribe un plan de 90 días para el puesto.

Onboarding #

Dale al onboarding más atención que al reclutamiento.
Asigna a cada nuevo empleado un compañero con quien reunirse 15 minutos diarios las primeras 2 semanas.

Despido #

Al anunciarlo, elogia las contribuciones de la persona y asume la responsabilidad de no haber podido encajar sus habilidades con las necesidades de la empresa.
No culpes ni critiques. Asume la responsabilidad de la situación.

Ventas efectivas #

Construye confianza.
Vende resultados, no características.
Identifica los dolores de los clientes.

Construir confianza #

Pregunta a los clientes sobre ellos mismos.
- Escucha activamente y refleja lo que dicen.
- En la segunda reunión, demuestra que recuerdas lo que dijeron en la primera.
Deja claro que no vas a hablar de tu empresa.
Pide poco tiempo.
Invítalos a un evento social sin agenda.

Desarrollo de clientes #

Las preguntas correctas te ayudan a identificar los desafíos del cliente.
Entiende su dolor antes de presentar tu solución.
1. ¿Cuáles son sus metas?
2. ¿Qué les impide alcanzarlas?
3. ¿Cuáles serían sus soluciones ideales?

Vende resultados, no características #

A la mayoría no le importan las características de tu producto. Les importan sus resultados de negocio.
Enfócate en el por qué.
Pinta la visión de un mundo donde el cliente logra lo que quiere gracias a tu producto.

Equipo de ventas y pipeline #

No contrates vendedores de inmediato.
En general, los vendedores no venderán mejor que los fundadores. Y no podrán vender si tú no puedes.
Contrata un equipo de ventas solo si:
- Tienes una versión inicial de product-market fit (tus clientes de pago renuevan).
- Sabes qué vendes y a quién.

Estructura del equipo de ventas #

Generar leads y cerrar son funciones distintas. Sepáralas.
Los vendedores senior son caros. Que se enfoquen en cerrar tratos.
Estructura ideal:
- Calificadores (SDRs): generan leads.
- Cerradores (Account Executives): cierran leads.
- Cultivadores (Customer Success): atienden clientes existentes.

Generación de leads #

Leads predecibles es el primer paso hacia ingresos predecibles.

Marketing #

Empieza por la fruta al alcance de la mano: el segmento de clientes cuyo problema tu producto resuelve 10x mejor que la competencia.
Pasa al siguiente segmento cuando tengas recursos para ello.

Product-market fit (PMF) #

Diseña una solución claramente mejor que las existentes para el problema de tus clientes objetivo.
¿Cómo sabes si tienes PMF?
- Tus clientes te lo dicen: renuevan, compran más, te recomiendan.
B2B: PMF = contratos a largo plazo.
B2C: PMF = segunda compra, renovación, compartir en redes sociales.

Matt Mochary habla sobre su método de coaching, cómo entender y superar el miedo primigenio, el síndrome del impostor y más.

El Camino a la Seniority en Software

2022-06-08T00:00:00+00:00

Todos hemos sido desarrolladores junior en algún momento. Esto es fácil de saber porque es al principio de tu carrera. Tus responsabilidades fueron delimitadas por otros compañeros que cuidaban de ti.

En algún momento, después de meses o años, conseguiste tu promoción u otro trabajo, donde ya no eras junior, sino intermedio.

Un intermedio (también conocido como middle) es algo entre junior y senior. Ahora sabes que ya no eres junior, sabes cómo entregar valor pero aún tienes sentimientos encontrados sobre la seniority. Quieres ser senior, pero no sabes cómo. No hay un camino claro para alcanzar este objetivo.

Espera un segundo… ¡en realidad hay dos formas fáciles de conseguir el título de senior! Puedes ser promovido como tal en tu empresa, o puedes empezar una nueva posición como “senior” en otra empresa, ¿fácil no?

Marketing y política #

Desafortunadamente, el nivel de “seniority” está muy contaminado por marketing y política. Primero, ¿qué significa “senior” en este contexto? En todas las empresas donde he trabajado (si no todas) siempre he estado rodeado de personas que afirmaban ser “seniors” cuando en realidad solo a unos pocos los consideraría como tales.

La etiqueta de senior está inflada por la necesidad de las empresas de tener expertos en papel más que en la realidad, y es un problema con el que debemos lidiar y del que debemos hablar.

Seniority generalmente significa más experiencia, pero ¿cómo calculas esto? Es fácil desde el punto de vista de una empresa: más años en la industria. Pero, ¿es realmente relevante el número de años que has estado trabajando en una industria que está en constante cambio y evolución? En realidad, esto no sería un gran problema si tienes los fundamentos del software bien interiorizados, pero curiosamente, he visto estos fundamentos solo en ~10% de los seniors que he conocido a lo largo de muchos años y varias empresas.

El hecho de que hayas estado trabajando durante 10 o más años no significa necesariamente que seas un “senior” con el software. ¿Qué más podemos medir para identificar si realmente mereces este título?

No todo se trata del dinero #

Seamos honestos, los títulos senior están mejor pagados que las posiciones junior o middle. Si tienes la oportunidad de conseguir un salario más alto porque tienes “senior” en tu título de trabajo, bueno, no sería inteligente rechazarlo. Pero, independientemente de la política y el marketing, debemos abordar algunos fundamentos de seniority para entender mejor qué significa la palabra “senior” en este contexto.

No todo se trata del dinero, sino también de las responsabilidades que vienen con la seniority.

Fundamentos de la seniority #

Ser senior en nuestra industria del software no se trata del “número de años de experiencia” sino:

¿Qué tan bien transmites tu conocimiento a otros? Compartir lo que sabes es una tarea esencial para una persona senior.
¿Qué tan bien colaboras con otras personas, incluyendo al PM/PO y a otros equipos? La colaboración es crucial para crear un bucle de retroalimentación constante.
¿Qué tan bien trabajas en conjunto con tus compañeros? El pair-programming fomenta la cohesión del equipo y ayuda a que todos mejoren.
¿Qué tan fuertes son tus habilidades de testing? El testing está ligado a la calidad de tu trabajo, y un senior debería apuntar a un diseño incremental.
¿Qué tan bien entiendes entregar valor constantemente en pequeñas partes? Cuanto antes entregues valor, antes obtendrás retroalimentación sobre ello.
¿Qué tan profundo es tu conocimiento técnico sobre software de calidad y los trade-offs para llegar allí? Principios SOLID, código limpio, TDD, refactoring como parte de tu trabajo diario, bajo acoplamiento, alta cohesión, estructuras de datos apropiadas y elegir la solución correcta (KISS, YAGNI…).
¿Qué tan bien te adaptas y lidias con el cambio? El cambio es inevitable, así que debemos aprender a gestionarlo, especialmente lo que no podemos controlar.
¿Qué tan desarrollado está tu pensamiento emprendedor? Siempre manteniendo los objetivos de la organización en mente.

Como puedes ver, no hay mención de tecnología concreta o años de experiencia. ¿Por qué? Porque la tecnología es solo un “detalle de implementación”, y la experiencia viene de practicar y la actitud, no de dejar pasar el tiempo.

La actitud es importante #

Tenemos dos personas:

A) una persona que trabaja desde hace 15 años, haciendo relativamente lo mismo cada día, y sin preocuparse por sus propias habilidades. Simplemente hace lo que otros le dicen que haga.

B) una persona que trabaja desde hace 5 años, desafiándose a sí misma cada semana, probando diferentes enfoques al lidiar con problemas, y afilando sus propias habilidades constantemente.

¿Puedes ver la diferencia principal? No, no son los 10 años de diferencia de “experiencia” entre ellos, sino su actitud.

Entendemos erróneamente que un año de experiencia debe venir con aprendizaje y conocimiento, así que tendemos a usar el tiempo como medida de seniority. Pero argumento que el “factor actitud” es igual o incluso más importante. He estado rodeado de muchas personas que se llaman a sí mismas seniors con 3, 6, 10 y más años de “experiencia” pero sin actitud, y podías ver claramente este problema a diario.

Necesitas esta combinación para construirte como un desarrollador verdaderamente senior; tiempo, experiencia, y lo más importante: actitud hacia mejorar tus propias habilidades y las de quienes te rodean.

Por dónde empezar #

La seniority no se concede, se practica. No esperas el título, construyes el comportamiento hasta que el título te alcanza. Empieza pequeño, y empieza ahora:

Enseña lo que sabes. Elige una cosa que entiendas y explícasela a alguien esta semana. Si no puedes explicarla, aún no la dominas.
Busca lo incómodo. Ofrécete para la tarea que te queda algo grande. El crecimiento vive en el borde de lo que ya sabes hacer.
Reflexiona con intención. Después de cada proyecto, pregúntate qué harías diferente. Experiencia sin reflexión es solo repetición.

El camino no es una promoción. Es la decisión diaria de mejorarte a ti mismo y a quienes te rodean. Hazlo el tiempo suficiente, y el título se vuelve un trámite.

Bikeshedding

2022-05-27T00:00:00+00:00

El término se acuñó como metáfora de la Ley de trivialidad de Parkinson. La gente en las organizaciones suele dar demasiada importancia a los asuntos triviales.

Bikeshed-ing #

El concepto apareció como corolario de la “Ley de Parkinson”, una parodia sobre gestión. “Bikeshedding” es una versión dramatizada de la “Ley de trivialidad”.

C. Northcote Parkinson observó que un comité que debe aprobar planes para una central nuclear puede pasar la mayor parte del tiempo en temas fáciles de entender pero poco importantes. Por ejemplo, qué materiales usar para el cobertizo de bicis del personal. Mientras tanto, descuidan el diseño de la central, que es mucho más importante pero más difícil de criticar. Como él dijo:

“El tiempo dedicado a cualquier tema será inversamente proporcional al dinero involucrado.”

La gente da demasiada importancia a lo trivial #

Lo he visto en todas las empresas donde he trabajado. Cuando mezclas temas importantes con otros no tan importantes (o nada importantes), es muy común acabar discutiendo lo trivial con tus compañeros. Mientras tanto, las cosas importantes que darían valor real al cliente quedan aparcadas.

Pasa más de lo que pensamos, y le puede ocurrir a cualquiera.

¿Qué podemos hacer? #

Crear conciencia de este problema en tu equipo. La comunicación honesta y la confianza son claves.

Pasos a seguir:

Sé consciente del problema.
Ve valor en cambiar este comportamiento.
Señala el problema cuando lo veas ocurrir.
Espera lo mismo de tus compañeros.

Referencias #

El Número de Dunbar

2022-04-02T00:00:00+00:00

Un límite cognitivo de cuántas relaciones sociales estables podemos mantener. Saber quién es cada persona y cómo se relaciona con las demás.

El estudio muestra que:

Relación cercana: 5 personas.
Confianza profunda: 15 personas.
Relaciones significativas: 50 personas.
Contactos activos: 150 personas.

¿Por qué este límite es 150? #

Por nuestra capacidad cognitiva limitada. Nuestra capacidad para razonar, resolver problemas y entender ideas complejas tiene un tope. Al crecer el equipo, aumenta la carga cognitiva y la comunicación sufre. Por eso un equipo muy grande pierde sus beneficios.

Origen #

En los 90, el antropólogo Robin Dunbar encontró una correlación entre el tamaño del cerebro de los primates y el tamaño de su grupo social. Extrapoló los resultados al cerebro humano y propuso que podemos mantener unas 150 relaciones estables. Dunbar teorizó que:

“Este límite depende directamente del tamaño del neocórtex, que a su vez limita el tamaño del grupo […] El límite impuesto por la capacidad de procesamiento neocortical es simplemente el número de personas con las que se puede mantener una relación estable.”

Este número incluye también colegas del pasado, como amigos del instituto, con los que querrías reencontrarte si os volvierais a ver.

¿Cómo se aplica esto a los equipos? #

Equipos individuales: 5-9 personas.
- Confianza compartida entre los miembros.
- La confianza se construye con el tiempo.
- Deben ser equipos a largo plazo.
Grupo: 50 personas.
- Relaciones significativas.
- Comparten un dominio o subdominio.
- Entienden los retos y se ayudan mutuamente.
Division: 150 personas.

Referencias #

El Poder de la Autoridad y la Obediencia

2022-01-24T00:00:00+00:00

Milgram quiso investigar hasta dónde llegaría la gente obedeciendo una orden que implicara dañar a otra persona. Y qué tan fácil era influenciarles para cometer atrocidades, como ocurrió con los alemanes en la Segunda Guerra Mundial.

El experimento #

En los años 60, el psicólogo Stanley Milgram hizo una serie de experimentos sobre obediencia. Quería entender el poder de la autoridad, incluso cuando las órdenes podían tener consecuencias fatales.

Milgram estudió las justificaciones de los acusados en los juicios de Nuremberg. Su defensa era simple: solo seguían órdenes de sus superiores. El experimento buscaba responder esta pregunta:

¿Podría ser que Eichmann y sus millones de cómplices en el Holocausto solo estaban siguiendo órdenes? ¿Podríamos llamarlos a todos cómplices?

El procedimiento #

Reclutaron a 40 hombres mediante anuncios en periódicos para un “estudio sobre aprendizaje” en Yale. A cada uno le pagaron $4.50.

Cada participante fue emparejado con otra persona. Un sorteo (amañado) decidía quién era el “aprendiz” y quién el “maestro”. El participante real siempre era el maestro. El aprendiz era un cómplice de Milgram fingiendo ser participante.

Al aprendiz lo llevaron a una habitación y le conectaron electrodos. El maestro y el investigador fueron a otra habitación con un generador de descargas. Los interruptores iban desde 15 voltios (descarga leve) hasta 450 voltios (XXX).

El aprendiz daba respuestas incorrectas a propósito. Por cada error, el maestro debía darle una descarga. Cuando el maestro se negaba, el investigador le presionaba con estas órdenes:

“Por favor, continúe.”
“El experimento requiere que continúe.”
“Es absolutamente esencial que continúe.”
“No tiene otra opción; debe continuar.”

Resultados #

El 65% de los maestros llegó hasta el nivel máximo de 450 voltios. Todos llegaron al menos a 300 voltios.

Milgram hizo 18 variaciones del experimento. Alteraba la situación para ver cómo afectaba la obediencia.

Conclusión #

La explicación fácil sería que había algo mal en esas personas. Pero la explicación real es que la situación les hizo comportarse así.

Varios factores influyeron: la ubicación, el comportamiento del investigador, y el hecho de haberse ofrecido voluntarios y recibir pago.

La gente tiende a obedecer si reconoce la autoridad del otro. Esta respuesta se aprende en la familia, la escuela y el trabajo.

La teoría de agencia de Milgram #

Milgram explicó que las personas tienen dos estados de comportamiento en situaciones sociales:

Estado autónomo: diriges tus acciones y asumes responsabilidad por los resultados.
Estado agentivo: dejas que otros dirijan tus acciones y transfieres la responsabilidad a quien da las órdenes. Actúas como agente de la voluntad de otro.

Para entrar en estado agentivo hacen falta dos cosas:

Percibir que quien da las órdenes tiene autoridad legítima.
Creer que la autoridad aceptará la responsabilidad de lo que pase.

Cuando a los participantes se les recordaba que eran responsables de sus acciones, casi ninguno obedecía. En cambio, muchos que se negaban a continuar lo hacían si el investigador decía que él asumía la responsabilidad.

Variaciones del experimento #

Algunas de las variaciones más interesantes:

Uniforme #

Cuando una “persona común sin uniforme” asumía el rol de investigador, la obediencia bajó al 20%.

Cambio de ubicación #

La obediencia bajó al 47.5% cuando el experimento se hizo en unas oficinas normales en vez de la prestigiosa Universidad de Yale.

Otros dos participantes (cómplices) eran también maestros pero se negaron a obedecer: uno a 150 voltios, el otro a 210. Ver a otros desobedecer a la autoridad redujo la obediencia al 10%.

Experimentador ausente #

Cuando el investigador daba instrucciones por teléfono desde otra habitación, la obediencia bajó al 20.5%. Muchos participantes hicieron trampa: omitían descargas o daban menos voltaje. La proximidad de la autoridad afecta la obediencia.

Las cuestiones morales #

¿Por qué tantos participantes hicieron algo aparentemente sádico al recibir órdenes de una autoridad? Según Milgram, varios factores situacionales lo explican:

La presencia física de una autoridad aumentó el cumplimiento.
Yale es una institución de confianza, así que el experimento parecía seguro.
La selección de maestro y aprendiz parecía aleatoria.
Los participantes asumían que el investigador era un experto.
Les dijeron que las descargas eran dolorosas, no peligrosas.

El experimento de Milgram se convirtió en un clásico de la psicología. Demostró los peligros de la obediencia. La situación influye más que la personalidad a la hora de obedecer.

A menudo no es tanto el tipo de persona que uno es, sino la situación en la que se encuentra, lo que determina cómo actuará.

Stanley Milgram, 1974.

Recursos #

Modern CTO

2022-01-23T00:00:00+00:00

Los desarrolladores no son CTOs, pero pueden aprender a serlo.

Joel Beasley ofrece una guía práctica para pasar de desarrollador a CTO. Comparte desde su experiencia los retos, las lecciones aprendidas y los errores típicos en este camino.

Estos son los temas que encontrarás en el libro:

Un CTO moderno sabe… #

Los desarrolladores no son CTOs
La epidemia del código espagueti MVP
La sobre-ingeniería es un problema
Si contratar, comprar o superar a la competencia
Cómo no escalar prematuramente
Cómo resolver cualquier problema
Cómo trabajar con programadores cuando no eres uno
Errores de UX a tener en cuenta
Cuándo hablar
Cuándo contratar y despedir consultores
Cómo analizar el fracaso
Cómo recuperarse de restricciones imprevistas
Responder la pregunta: “¿Qué tan difícil es codificar…?”
Cómo evitar al “tipo del noveno inning”
Cuándo responder a la retroalimentación
Cómo validar a un experto en cualquier campo
Cómo comunicar efectivamente ideas complejas

Citas favoritas #

Si me apoyo en logros pasados, nunca creceré.

APROVECHA LA EXPERIENCIA DE OTROS. Los libros condensan toda una vida de experiencia en unas pocas horas de lectura.

Solo hay dos razones por las que escribes mal código:

Sabes cómo escribir buen código, pero eliges escribir mal código.

No sabes cómo escribir buen código. Y ambas apestan.

Como CTO, debes tener un enfoque de negocio.

Siempre vuelve a tus metas principales. […] Me aseguro de que cada meta tenga un “por qué” claro detrás. Así, cuando me pierdo, vuelvo a mi “por qué”.

Referencia a “Empieza con el Por Qué” de Simon Sinek.

Cuando eres el jefe, recuerda esta regla de oro: Pregunta a la gente qué piensa en lugar de decirles qué hacer.

Si no puedo evaluar el componente humano, no puedo liderar un equipo. […] La composición del equipo pesa tanto o más que la experiencia técnica.

Como CTO, si no puedes explicar el valor de forma simple, significa que no entiendes el valor de negocio detrás de tu tecnología.

Los líderes comen al final

2022-01-16T00:00:00+00:00

La mayor fortaleza de una empresa no está en sus productos o servicios. Está en su gente y su capacidad de cooperar y unirse, sobre todo en las crisis.

Pero la lealtad y el compromiso hay que ganárselos. Hoy el trabajo es una relación contractual y transaccional en muchas organizaciones. La competencia intensa y los despidos son la norma. Casi nadie cree en la lealtad a una empresa, mucho menos en el empleo de por vida.

Los 4 químicos (E.D.S.O.) #

Somos individuos y parte de grupos sociales a la vez. Cada día tomamos decisiones que requieren sopesar nuestros intereses personales contra los del grupo. Este dilema también ocurre en nuestro cuerpo a través de 4 químicos clave:

Las endorfinas y la dopamina nos impulsan a satisfacer necesidades personales: encontrar comida, desarrollar soluciones, perseverar ante problemas. Nos ayudan a hacer cosas para sobrevivir.
La serotonina y la oxitocina nos animan a trabajar con otros. Construyen confianza, lealtad y camaradería. Fortalecen nuestros lazos sociales y aumentan nuestra inclinación a cooperar para lograr lo que no podemos solos.

Círculos de seguridad #

La familia tradicionalmente proporciona un Círculo de Seguridad donde nos sentimos seguros y apoyados. Dentro del círculo tenemos un equilibrio saludable de E.D.S.O. y niveles bajos de cortisol. En las organizaciones, los Círculos de Seguridad dan a la gente un sentido de pertenencia y seguridad. Facilitan la comunicación, cooperación, resolución de problemas e innovación. La gente puede dirigir su atención a amenazas y oportunidades externas. Cuando se sienten amenazados por políticas y luchas internas, miran hacia adentro para protegerse. El grupo se vuelve más vulnerable.

Los líderes deben ganarse el respeto y la lealtad haciendo los mayores sacrificios y estando dispuestos a comer al final. Hay que dar confianza para ganar confianza.

Una sociedad desequilibrada #

Los 4 químicos E.D.S.O. juegan roles importantes en nuestra supervivencia. Cuando están en equilibrio, las personas prosperan como están diseñadas para hacerlo. Sus grupos y organizaciones también prosperan. El problema es que el lugar de trabajo moderno está inundado de cortisol y adicción a la dopamina. No tenemos Círculos de Seguridad y estamos peligrosamente desequilibrados. ¿Cómo llegamos aquí?

Abstracción y deshumanización: gestionar con números, sistemas globales e interacciones virtuales puede ser peligroso y llevar a actos descuidados.
Abundancia destructiva: respondemos diferente a la escasez y al exceso. Los líderes se han cegado tanto por el interés comercial que olvidaron a quién deben servir.
Cambios sociales: nuestras normas y valores han cambiado con los Boomers post-WWII, la Generación X y los Millennials. Cada vez más adictos a la dopamina y desequilibrados.

Simon Sinek ofrece muchos ejemplos e historias de líderes en todos los ámbitos: militar, política y negocios.

TED Talk: Por qué los líderes comen al último #

Las cinco disfunciones de un equipo

2021-12-07T00:00:00+00:00

Una fábula de liderazgo sobre una empresa tech que no consigue crecer. El equipo directivo no trabaja como equipo, les cuesta llegar a acuerdos y la moral está por los suelos. Hasta que llega la nueva CEO, Kathryn Petersen, que identifica los problemas y ayuda al equipo a superarlos.

Es el primer libro que leo de Patrick Lencioni, escritor estadounidense especializado en gestión empresarial. Es fundador y presidente de The Table Group, una consultoría enfocada en salud organizacional.

Resumen del libro #

Kathryn Petersen, CEO de Decision Tech, enfrenta la crisis de liderazgo definitiva: unir a un equipo tan disfuncional que amenaza con hundir la empresa. ¿Lo logrará? ¿La despedirán? ¿Fracasará la empresa?

A lo largo de la historia, Lencioni revela las cinco disfunciones que explican por qué incluso los mejores equipos tienen problemas. Presenta un modelo claro y pasos concretos para superar estos obstáculos y construir un equipo cohesivo.

El modelo de las 5 disfunciones #

1) Ausencia de confianza #

El miedo a ser vulnerable impide que el equipo construya confianza.

Pasa cuando nadie quiere mostrarse vulnerable ni admitir errores, debilidades o que necesita ayuda. Sin ese nivel de comodidad, no hay base de confianza posible.

2) Miedo al conflicto #

El deseo de mantener una armonía artificial ahoga el debate productivo.

Los equipos sin confianza no pueden tener debates apasionados sobre temas importantes. El conflicto se convierte en comentarios velados y murmullos. Cuando la gente no expresa sus opiniones abiertamente, las decisiones son peores.

3) Falta de compromiso #

Sin claridad ni aceptación, el equipo no toma decisiones firmes.

Sin debate real, cuesta comprometerse con las decisiones. La ambigüedad domina. La falta de dirección y compromiso hace que los empleados, sobre todo los mejores, se sientan descontentos.

4) Evasión de responsabilidad #

Nadie quiere la incomodidad de exigir cuentas a los demás.

Cuando no hay compromiso claro con un plan, incluso los más motivados dudan en señalar comportamientos contraproducentes de sus compañeros.

5) Desatención a los resultados #

Las metas individuales y el estatus personal erosionan el enfoque en el éxito colectivo.

Cuando no hay rendición de cuentas, la gente pone sus necesidades (ego, carrera, reconocimiento) por encima de las metas del equipo. Si el equipo pierde de vista los logros, el negocio sufre.

Video Resumen #

Empieza con el porqué

2021-11-28T00:00:00+00:00

¿Por qué algunas personas y organizaciones son más innovadoras, influyentes y rentables que otras? ¿Por qué algunas consiguen mayor lealtad de clientes y empleados? Incluso entre las exitosas, ¿por qué tan pocas pueden repetir su éxito?

La capacidad de inspirar y lograr cosas notables empieza con el POR QUÉ. Quienes empiezan con el POR QUÉ no manipulan, inspiran.

Martin Luther King Jr., Steve Jobs y los hermanos Wright tenían poco en común. Pero todos empezaron con el POR QUÉ. Entendieron que la gente no compra un producto, servicio o idea hasta que entiende el POR QUÉ detrás.

Inspirar y lograr cosas notables empieza con el POR QUÉ.
Cualquier organización puede explicar qué hace. Algunas pueden explicar cómo lo hacen. Muy pocas articulan claramente por qué.
Tu POR QUÉ es tu propósito, causa o creencia.
Todo líder y organización inspiradora, sin importar tamaño o industria, empieza con el POR QUÉ.
Cuando tu POR QUÉ se vuelve borroso, cuesta mantener el crecimiento, la lealtad y la inspiración que impulsaron tu éxito original.

La gente no compra LO QUE haces, compra POR QUÉ lo haces.

Los grandes líderes inspiran a la gente a actuar. Quienes inspiran dan un sentido de propósito o pertenencia que tiene poco que ver con incentivos externos.

Video Resumen #

Leadership is Language

2021-10-22T00:00:00+00:00

Un manual radical para empoderar a tu gente y poner a tu equipo en un camino de mejora continua.

El ex comandante de submarino L. David Marquet analiza el hundimiento del El Faro, uno de los desastres marinos más investigados. De ahí extrae ideas clave sobre liderazgo y lenguaje.

Quizás piensas que un líder efectivo toma decisiones rápidas, da discursos inspiradores y emite órdenes claras para que su equipo ejecute el plan. Ese modelo de liderazgo está obsoleto.

Tus palabras importan más de lo que crees.

David presenta seis jugadas que todo líder debería usar para mejorar cómo opera su equipo. El problema de muchos líderes hoy es que siguen usando el manual de la era industrial. Antes el líder daba órdenes, los empleados las seguían, y ya. Esa forma de liderar ya no funciona.

Las seis jugadas #

Controla el reloj, no lo obedezcas. Planifica puntos de decisión y da a tu gente las herramientas para pausar si ven algo mal.
Colabora, no coacciones. Como líder, sé el último en dar tu opinión.
Comprométete, no solo cumplas. En vez de esperar que sigan instrucciones específicas, explica las metas generales y consigue su compromiso para lograrlas paso a paso.
Completa, no continúes. Si cada día se siente igual que el anterior, algo estás haciendo mal.
Mejora, no demuestres. Pide a tu gente que mejore los planes y procesos, no que demuestren que pueden cumplir metas fijas.
Conecta, no conformes. Aplana las jerarquías y conecta con tu gente para que contribuyan a las decisiones.

Video Resumen #

Turn the Ship Around!

2021-09-12T00:00:00+00:00

Marquet comparte sus teorías de liderazgo y cómo implementó un modelo diferente. Explica las limitaciones de la jerarquía tradicional, por qué falló antes al intentar empoderar a su equipo, y cómo el submarino Santa Fe fue el lugar perfecto para probar el enfoque líder-líder.

Casi todos dividimos el mundo en líderes vs seguidores sin darnos cuenta. Asumimos qué puede o no puede hacer cada grupo. Esas suposiciones afectan cómo pensamos y actuamos, impactando el rendimiento de cada persona y de la organización.

Es muy común: un empleado entusiasta propone una idea nueva y le dicen “eso no es tu trabajo” o “eso no va a funcionar”. La gente se frustra y al final deja de intentarlo o se va. Los jefes también se frustran cuando su equipo prefiere hacer lo mínimo en vez de innovar o asumir responsabilidad.

El modelo líder-líder parte de que todos tienen capacidad y potencial para liderar. Aprovecha ese potencial en todos los niveles, reduce la dependencia de un solo líder y logra un rendimiento sostenido.

Los 3 componentes clave: Control, Competencia y Claridad #

Control #

El control es la libertad y autoridad para decidir el por qué, el qué y el cómo de tu trabajo. La meta es delegar las decisiones lo más abajo posible en la organización.

Encuentra el código genético del control y reescríbelo.
Actúa para llegar a un nuevo pensamiento.
Las conversaciones cortas y tempranas hacen el trabajo más eficiente.
Usa “Tengo la intención de…” para convertir seguidores pasivos en líderes activos.
Resiste el impulso de dar soluciones.
Elimina los sistemas de monitoreo de arriba hacia abajo.
Piensa en voz alta (tanto jefes como subordinados).

Competencia #

Cada persona debe ser técnicamente competente para tomar buenas decisiones en su nivel. Si das más responsabilidad sin el conocimiento y recursos necesarios, todo se desmorona.

Toma acciones deliberadas.
Aprendemos en todas partes, todo el tiempo.
No informes, certifica.
Repite el mensaje de forma continua y consistente.
Especifica metas, no métodos.

Claridad #

Para tomar buenas decisiones en cualquier nivel, hay que estar alineado con el propósito de la organización. Hay que entender bien los objetivos y los criterios para decidir.

Busca la excelencia, no solo evitar errores.
Construye confianza y cuida a tu gente.
Usa tu legado como inspiración.
Usa principios guía para los criterios de decisión.
Usa el reconocimiento inmediato para reforzar los comportamientos deseados.
Empieza con el fin en mente.
Fomenta cuestionar las cosas en vez de obedecer ciegamente.

Citas favoritas #

El liderazgo es comunicar a las personas su valor y potencial tan claramente que se inspiran a verlo en sí mismas.

Resumen #

David Marquet habla sobre el liderazgo que cambia el rumbo en su keynote en el Worldwebforum.

Responsabilidades de un Tech Lead

2021-07-01T00:00:00+00:00

El Modelo de Carrera Tridente de Patrick Kua tiene tres vías. Cada una representa dónde uno pasa la mayor parte de su tiempo o energía.

Historia Arquetípica #

Contribuidor Individual #

70-80% del tiempo dedicado a “Ejecutar, hacer”.
Diseñar. Testear. Programar.

Gestión #

70-80% del tiempo dedicado a “Gestionar el sistema”.
Planificar. Organizar. Apoyar. Presupuestar.

Líder Técnico #

70-80% del tiempo dedicado a “Liderar Temas Técnicos y Equipos”.
Alinear al Equipo. Visión Técnica. Aumentar el Conocimiento Técnico. Gestión de Riesgo Técnico y Deuda Técnica.

¿Qué es un Tech Lead?

“Un Tech Lead es un ingeniero de software, responsable de liderar un equipo de desarrollo, y responsable de la calidad de sus entregables técnicos.” (fuente)

Un Tech Lead es un Desarrollador que es un Líder #

Un buen líder se asegura de que el equipo vaya en la misma dirección. Juntos se avanza más lejos que siendo solo personas que trabajan “juntas”.

Habilidades de liderazgo en las que invertir #

Empatía
Autoconciencia
Motivación
Resolución de Conflictos
Comunicación
Coaching
Dar retroalimentación
Influencia
Delegación

El rol de Tech Lead es una posición de liderazgo, no necesariamente una posición de gestión.

Sorpresas y Luchas #

Sentirse solo: te conviertes en un “outsider”. Tienes un rol diferente. Eres escudo y filtro.
Incertidumbre: no hay respuesta correcta. Vienes del hábito binario del código. Trabajas con información imperfecta.
Las personas desconciertan: son únicas, con diferentes fortalezas y arquetipos.

Un Gran Tech Lead #

Un gran Tech Lead se enfoca en desarrollar a otros para que el equipo mejore sus capacidades.

¿Decir o Delegar? #

El objetivo es alcanzar una delegación completa, paso a paso. Hay que trasladar responsabilidades a otras personas para que también crezcan. Esto depende de sus habilidades, motivaciones y la urgencia de la tarea.

“Nadie es perfecto, pero un equipo puede serlo.” - Meredith Belbin

Puntos clave #

Tech Lead es un cambio de rol.
Requiere habilidades de liderazgo.
Otros han estado en este camino.
Hay muchos recursos disponibles.
Pasa del modo creador al multiplicador.

Libros recomendados en este campo #

Referencias #

Cómo ser un Engineering Manager efectivo

2021-06-27T00:00:00+00:00

Una recopilación completa de temas clave para la gestión: 1:1s, evaluaciones de desempeño, contratación, despidos, política laboral y trabajo remoto.

El libro tiene 3 partes: la primera cubre lo que un manager nuevo debería saber; la segunda y tercera profundizan en temas que todo manager debería dominar.

Aunque asentía con los consejos, a veces sentía que era demasiado extenso o entraba en detalles que no me interesaban. Aun así, me alegro de haberlo terminado. Saqué muchos consejos útiles.

Mis aprendizajes de este libro:

Parte 1 - Orientarse #

Capítulo 01: Una nueva aventura #

Consejos prácticos para tu primera semana y cómo detectar señales de desalineación.

Capítulo 02: Gestiónate a ti mismo primero #

Buen recordatorio de que ordenar tus propias cosas es lo primero. Es prerrequisito para ser eficiente como manager.

“Tu calendario es para ti y para los demás. Mantenlo ordenado y con sentido. Te representa. Hacer las reuniones públicas por defecto ayuda a otros a entender cómo agendar tiempo contigo.”

Parte 2 - Trabajar con personas #

Capítulo 03: Comunicarte con humanos #

Mucho terreno sobre cómo comunicarte con otros.
Piénsalo dos veces antes de compartir información.
Sé consistente en tu estilo de comunicación.

“No comuniques cuando quieras, sino cuando necesites.”

Capítulo 04: Uno a uno #

Es su reunión, no la tuya.

“Intenta que hablen el 70% del tiempo. Si quieres resolverles el problema, no lo hagas. Haz otra pregunta y deja que lleguen solos a la conclusión. Es un arte que requiere práctica.”

Capítulo 05: El trabajo adecuado para cada persona #

Motivación y jerarquía de necesidades. Ejemplos prácticos de cómo desarrollar habilidades.

“Como manager, puedes trabajar con ellos para situar sus metas de carrera en la base de su árbol de habilidades. Luego planificar hitos intermedios con progreso medible, empujando la frontera de su zona de desarrollo cada vez más lejos.”

Capítulo 06: Evaluaciones de desempeño #

Prepáralas con antelación. Recoge feedback de compañeros, por ejemplo por email.

Capítulo 07: Contratación #

No siempre necesitas al candidato más senior.
El encaje cultural importa.
Cómo montar un proceso de entrevistas.

Capítulo 08: Rotación #

Que la gente se vaya es normal.
Renuncias voluntarias:
- “Buenas razones”: no podrías haber hecho mucho.
- “Malas razones”: podrías haber detectado y abordado cosas antes (conflictos, falta de reto, salario).

“Estás condenado al fracaso si crees que vas a retener a todos indefinidamente. […] No luches por retener a alguien si no puedes ofrecer las condiciones para que sea más feliz. Solo retrasarás su partida.”

Capítulo 09: Construir tu red #

Hacer presentaciones, mantenerte en contacto.
Coaching y mentoría.

Parte 3 - El panorama general #

Capítulo 10: Las personas son difíciles #

No te centres en trabajar más duro o más rápido. Crea las condiciones para que tu equipo sea feliz y productivo: autonomía, maestría y propósito.

“En niveles senior, cuando las cosas van mal, te señalarán a ti. Eres el responsable aunque no sea tu culpa.”

Capítulo 11: Los proyectos son difíciles #

“El ojo de Sauron”: trabajar en proyectos de alto riesgo.
Todo se ralentiza cuando el equipo crece. Más código legacy, más problemas.
Equilibrio entre alcance, recursos y tiempo.

“Lidera desde el frente. Da el ejemplo. Pon el trabajo. Los proyectos difíciles pueden definir tu carrera. Adueñátelos y estate ahí.”

Capítulo 12: La bolsa de información #

Espías y guardianes.

“Como manager, deberás decidir constantemente cuánto compartes y cuándo.”

Política laboral.

“Tu red de compañeros te permite saber cómo el resto del negocio percibe tus iniciativas y prioridades.”

Capítulo 13: Soltar el control #

Elimina distracciones y recarga fuera del trabajo.
Dedica el 10% de tu semana a no hacer nada y dejar que tus pensamientos fluyan.

“Suelta los resultados que no puedes controlar. Haz lo mejor que puedas y fomenta lo mismo en tu equipo. Los resultados impredecibles son normales. El fracaso es aceptable. Si haces lo mejor que puedes, no tienes de qué preocuparte.”

Capítulo 14: Buen mantenimiento #

Convierte problemas en oportunidades de aprendizaje.
Mejora la comunicación del equipo.

Capítulo 15: Escaleras duales #

Diseñar trayectorias de Contribuidor Individual y Manager es vital para una cultura de ingeniería sana.

Capítulo 16: El lugar de trabajo moderno #

Diversidad e inclusión.
Trabajo remoto.
Lidera con el ejemplo: equilibrio vida-trabajo.

Capítulo 17: Startups #

Gestión no es burocracia.
La buena gestión es toque ligero y colaboración continua.

“La experiencia en startups es muy valorada porque implica ser emprendedor, automotivado, colaborativo y rápido aprendiendo. Aunque la startup fracase, tu siguiente trabajo será mejor por ello.”

Capítulo 18: La bola de cristal #

Tu visión de carrera. Mirar atrás, mirar adelante.

“Una parte importante de una vida larga y satisfactoria es el propósito. No se trata de estatus ni de sentirse bien. Se trata de una vida que valga la pena vivir.”

Experimentos de Conformidad

2021-06-01T00:00:00+00:00

¿Hasta qué punto las fuerzas sociales alteran las opiniones de las personas? ¿Qué aspecto de la influencia del grupo es más importante: el tamaño de la mayoría, o la unanimidad de opinión?

El psicólogo Solomon Asch #

Durante los primeros años de la Segunda Guerra Mundial, cuando Hitler estaba en la cúspide del poder, Solomon Asch empezó a estudiar el impacto de la propaganda y el adoctrinamiento. Era profesor en el departamento de psicología del Brooklyn College y luego estuvo 19 años en Swarthmore College.

En los años 50, Asch se hizo famoso por sus experimentos sobre la presión social y la conformidad. ¿Hasta dónde llega la gente para encajar con otros en un grupo? Su investigación mostró que los participantes tendían a conformarse con el grupo, incluso cuando creían que estaba equivocado.

Asch preguntó #

¿Hasta qué punto las fuerzas sociales alteran las opiniones de las personas? ¿Qué aspecto de la influencia del grupo es más importante: el tamaño de la mayoría, o la unanimidad de opinión?

Asch creía que las personas se comportan según cómo perciben el mundo, no según cómo es realmente.

El experimento de Asch #

Asch diseñó un experimento basado en un “simple test de visión”.

Metió a un participante en una sala con otros actores (cómplices). Los actores habían acordado dar respuestas incorrectas a propósito la mayoría de las veces.

El participante real no lo sabía. Creía que todos eran participantes como él.

Cada persona en la sala decía en voz alta qué línea (A, B o C) se parecía más a la línea objetivo. La respuesta siempre era obvia. El participante real se sentaba al final y respondía en último lugar.

Asch quería ver si el participante se conformaría con la mayoría. Los actores daban la respuesta incorrecta la mayoría de las veces (las llamadas pruebas críticas).

Hallazgos #

Casi el 75% de los participantes en los experimentos de conformidad siguieron al resto del grupo al menos una vez.

Asch también descubrió algo clave: cuando uno de los actores daba la respuesta correcta mientras el resto se equivocaba, la conformidad bajaba drásticamente. El apoyo social es una herramienta poderosa para resistir la presión del grupo.

Después de combinar las pruebas, los resultados indicaron que los participantes se conformaban con la respuesta incorrecta del grupo aproximadamente un tercio de las veces.

Por qué la gente se conforma con un grupo con el que no está de acuerdo #

¿Por qué los participantes se conformaron tan fácilmente? En las entrevistas posteriores, la mayoría admitió que no creían en sus respuestas conformistas. Simplemente siguieron al grupo por miedo a quedar en ridículo.

Unos pocos sí creían que las respuestas del grupo eran correctas.

La gente se conforma por dos razones principales: quieren encajar (influencia normativa) o creen que el grupo sabe más que ellos (influencia informativa).

La conformidad puede ser influenciada tanto por una necesidad de encajar como por una creencia de que otras personas son más inteligentes o están mejor informadas.

Factores que influyen en la conformidad #

Asch siguió experimentando para entender qué factores influyen en la conformidad. Descubrió que:

Aumenta cuando hay más personas presentes.
Aumenta cuando la tarea es más difícil.
Aumenta cuando los otros miembros tienen un estatus social más alto.
Disminuye cuando la gente puede responder en privado (cuando nadie ve su respuesta).

Recursos #

Solomon Asch | Wikipedia

Peopleware

2021-05-28T00:00:00+00:00

El desarrollo de software va de personas: cuándo, cómo y dónde trabajan mejor juntas. No de lenguajes de programación ni herramientas. No de ordenadores rápidos, redes o internet.

Las habilidades blandas importan más de lo que la gente cree en IT.

Desarrollar software va de personas que se comunican con clientes y stakeholders, reciben apoyo de sus managers y colaboran en equipos.

Citas favoritas #

Quedarse hasta tarde o llegar temprano es una acusación al entorno de oficina.
Alguien que ayuda a dar forma y avanzar un proyecto vale por dos que solo ejecutan.
Hay que preguntarse por qué las cosas se hacen como se hacen.
Siempre debe haber equilibrio entre calidad y cantidad.
Las organizaciones tienden a crear “días ocupados” con muchas reuniones, en lugar de confiar en que sus empleados se autoorganicen.
El factor humano suele ser el cuello de botella de un proyecto.
La gente no trabaja más duro bajo presión. Puede que rindan más un tiempo, pero se quemarán y se irán.
El rol del manager es facilitar que la gente trabaje, no forzarla.
Cualquier cosa que necesites medir puede medirse de alguna forma, y eso es mejor que no medirla.
El pecado capital de la gestión es desperdiciar el tiempo de la gente.
El cambio no arranca si la gente no se siente segura.
El cambio solo funciona si un poco de fracaso está permitido.
La experiencia se convierte en aprendizaje cuando la organización se adapta a lo que ha descubierto.

Los profesionales quieren crecer y ser felices en el trabajo. Este libro da ideas sobre lo que managers y desarrolladores pueden hacer al respecto. Si te importan las personas y buscas mejorar cómo desarrollas software en equipo, este libro es para ti.

El todo es mayor que la suma de las partes

Usamos la palabra “equipo” de forma muy imprecisa en el mundo empresarial. Llamamos equipo a cualquier grupo de personas que trabajan juntas. Pero muchos de estos grupos no parecen equipos. No tienen una definición común de éxito ni espíritu de equipo. Algo falta: un fenómeno que llamamos cohesión (jell).

El equipo cohesionado

Un equipo cohesionado es un grupo tan unido que el todo supera la suma de las partes. Su producción es mayor que si las mismas personas trabajaran por separado. Y el disfrute que obtienen de su trabajo supera lo que esperarías por la naturaleza del trabajo en sí.

Una buena serie con reflexiones sobre cada capítulo del libro.

El arte del liderazgo

2021-04-19T00:00:00+00:00

Notas destacadas #

Liderar son pequeñas cosas hechas de forma consistente.
La empatía es una habilidad poderosa.
Los uno a uno son clave para conectar con el equipo.
Pedir feedback genera confianza y fortalece relaciones.
Ante el feedback, da las gracias y haz preguntas para entender mejor.
El feedback es un regalo.
No es personal, es profesional.
El liderazgo es un traje que eliges ponerte para que otros lo vean.
Los managers te dicen dónde estás; los líderes, hacia dónde vas.
Tus compañeros se convierten en tus aliados.

97 cosas que todo Engineering Manager debería saber

2021-04-05T00:00:00+00:00

La lección principal #

Tu trabajo como manager es crear claridad. Claridad y más claridad.

Ideas clave #

Trabaja en corregir tus propias manías.
Haz experimentos en lugar de tomar decisiones definitivas.
“Test de malas noticias”: si tienes dos tareas, delega aquella sobre la que preferirías dar malas noticias.
Cuando un equipo tiene problemas, responde primero dos preguntas:
- ¿Cómo creo claridad?
- ¿Cómo creo capacidad?
Pide que te aclaren las cosas.
Para dar feedback constructivo, observa dónde la persona se bloquea, se desvía o se descuida.
Gestionar no es un ascenso. Es un cambio de carrera.
La mayoría de las disfunciones vienen de objetivos poco claros.
Con fecha límite fija, el alcance y la calidad siempre son negociables.
El contagio emocional existe.
Si eres nuevo como manager, escucha y entiende antes de cambiar nada.
Buenas preguntas de entrevista:
- ¿Qué has aprendido en los últimos seis meses?
- Cuéntame de una vez que fallaste y qué aprendiste.
- ¿Tienes las habilidades y experiencia para este trabajo?
Las quejas son buenas: significan que confían en ti.

Otro artículo con ideas clave más detalladas: Danlebrero Blog ;)

Pull Requests vs Pair Programming

2021-04-01T00:00:00+00:00

Hablemos de los beneficios de los Pull Requests y el Pair Programming, y mis reflexiones sobre estos después de algunos años de experiencia con ellos.

Pull Requests #

Un Pull Request (PR) es una forma de mostrar tus cambios de código para que se comparen fácilmente con el código existente. Es parte de un flujo de trabajo que ayuda a compartir conocimiento sobre los cambios que se hacen en el sistema.

Un Pull Request es el momento donde pides a tus compañeros que revisen y examinen tus cambios de código.

Normalmente, también se usa:

Para discusiones sobre estilo de código.
Para detectar bugs potenciales.
Para discusiones de arquitectura o diseño una vez que la solución está hecha.

Los Pull Requests no son la mejor herramienta para todo #

El problema es que los PRs suelen estar listos cuando la funcionalidad o bug ya está terminado, en la última etapa del desarrollo. Un PR es una “propuesta de cambio ya hecha para fusionar en el sistema actual”.

El concepto de “Draft PR” existe para indicar que el PR aún no está listo para fusionar, pero ese es otro tema.

Los Pull Requests son una de las mejores herramientas para compartir conocimiento sobre cambios en el sistema, pero a veces se usan mal:

Discusiones sobre estilo de código. El estilo no debería discutirse en un PR. Ya debería haber un CI ejecutando un linter. Si quieres cambiar algo, proponlo en el linter, no en un PR aleatorio.
Detectar bugs. Los bugs y comportamiento esperado deberían cubrirse con tests automatizados. El desarrollador es el primer responsable.
Discusiones de arquitectura o diseño. Cuando una solución está desarrollada y lista para revisión, es difícil “deshacerla” y reescribirla. “¿Por qué lo harías? Ya está hecho y funciona.”

Tener a alguien extra revisando decisiones de diseño puede ayudar, pero podríamos haber resuelto posibles desacuerdos antes.

¿Cuál debería ser el propósito de un Pull Request? #

Compartir conocimiento sobre los cambios propuestos con el equipo.
Asegurar que el equipo está alineado con los múltiples cambios que se envían cada día. Sí, puede incluir verificar el diseño, pero… ¿y si ya es demasiado tarde?

Pair Programming #

El “Pair Programming” puede entenderse de varias formas: pair thinking, roles conductor-navegador, live coding… En realidad es más sencillo de lo que parece:

Miras y ayudas a la otra persona a escribir código, o
Escribes mientras tienes otro par de ojos mirándote y ayudándote.

El Pair Programming ayuda al equipo a trabajar juntos.

El pair programming es trabajar con un cerebro extra y otro par de ojos. La clave es construir un contexto donde ambos compartan el mismo objetivo para encontrar la mejor solución posible, aprendiendo el uno del otro. No se trata de dar con la mejor solución desde el principio. Se trata de hacerlo funcionar, compartir ideas y mejorar juntos. Luego ya refactorizas y limpias el código.

El Pair Programming es una revisión de código continua #

Los Pull Requests son una forma asíncrona de compartir cambios de código, mientras que el Pair Programming es totalmente síncrono porque sucede al mismo tiempo.

Los Pull Requests y el Pair Programming no son excluyentes, pueden coexistir. Son herramientas, y hay que elegirlas con criterio según nuestros objetivos.

El miedo más común que he visto al animar a hacer Pair Programming es la timidez. A algunas personas no les gusta tener ojos encima mientras programan:

Miedo a no saber qué programar o por dónde empezar.
Miedo a que otros se rían de sus soluciones.
Miedo a no tener éxito en público.
Miedo a no poder desarrollar la solución esperada por múltiples razones: malentender la tarea o falta de conocimiento.
Miedo a cambiar de opinión frente a otros.
Miedo a discutir y tomar decisiones en voz alta.
Miedo a estar en desacuerdo con otros.

Después de varios años de experiencia en este tema #

El patrón que rechaza el Pair Programming es básicamente el miedo a salir de tu zona de confort. Y viene de no entender qué es realmente el Pair Programming.

No se trata de presumir ni de ser juzgado, sino de ser transparente (mostrar tus habilidades tal como son) y mejorar como equipo.

Programar es un proceso iterativo que requiere refactorizar continuamente nuestra forma de pensar. Programar con otra persona (con otra forma de pensar) ayuda al equipo a sacar lo mejor de cada uno y a descartar malos hábitos.

El Pair Programming no tiene que usarse siempre ni para todo. Es una herramienta flexible: puedes elegir cómo, cuándo y por qué.

Una regla personal: antes de empezar tareas que tocan múltiples módulos o reglas de negocio complejas, haz un Pair Thinking rápido con un colega más experimentado en ese área.

Todo depende de un contexto y personas particulares: los desarrolladores, las parejas, las tareas, el estado de ánimo.

¿Todavía incómodo con el Pair Programming? #

Si aún te sientes incómodo con alguien a tu lado mientras programas, quizás no estés contento con tu propio código o con el proceso que sigues. Mi forma favorita de trabajar esto es practicar por mi cuenta y mejorar mis habilidades como desarrollador.

Crea y juega con tus propios proyectos personales.
Trabaja en katas de código por tu cuenta y con otros.

La práctica hace al maestro.

Mantén las pull requests, añade pair programming #

No me malinterpretes, los Pull Requests son geniales. Sigue haciéndolos.
La colaboración en equipo es esencial. El Pair Programming apunta a esto.
El Pair Programming anima al equipo a trabajar juntos proactivamente.
No tengas miedo de programar mientras tienes ojos a tu alrededor. Haz preguntas cuando algo no esté claro. Pide ayuda cuando no sepas cómo resolver algo.

Está totalmente bien no saber todo. Lo más importante es saber cómo trabajar juntos.

Compartiendo tus Parches de Git

2020-12-01T00:00:00+00:00

Descubre otra forma de compartir sugerencias con tu equipo de desarrollo.

Imagina esta situación #

Estás revisando un Pull Request (PR), y ves algunas mejoras menores o sugerencias que te gustaría compartir con el autor. Podrías escribir algunos comentarios, y normalmente, eso sería suficiente.

Imagina que para transmitir tu “idea completa” necesitarías cambiar algunos archivos porque simplemente comunicar la imagen completa acabará en un comentario enorme que podría no ser tan claro como podría ser.

¿Qué posibilidades hay aparte de solo comentarios en un PR? #

Bueno, hay múltiples opciones. La clave es ser consciente de ellas y usarlas sabiamente dependiendo de la prioridad de la tarea y los cambios en sí:

Como ya se mencionó, escribir un comentario como retroalimentación es una buena idea por defecto, pero no la única.
Siempre podemos hacer algo de pair-thinking, hablar en cualquier momento. La comunicación siempre es buena para aclarar la posible incertidumbre.
Compartir tus parches de git es otra buena opción.

¡Git diff al rescate! #

¿Y si tú (como revisor) pudieras compartir tu idea sin ningún commit o comentario en el PR, pero compartiendo tus cambios directamente con el autor?

Bueno, eso es realmente posible y muy fácil. Como ya sabes, el comando git diff te da las diferencias entre dos ramas cualesquiera.

git diff origin develop > ../my-origin-develop.patch

Lo que estamos haciendo aquí es redirigir la salida del comando diff a un archivo (también conocido como: parche), para poder compartir esa salida con cualquier otro compañero de equipo.

¿Y ahora qué? #

Bueno, teniendo ese archivo de parche, es bastante fácil aplicar esos cambios en tu máquina local sin hacer ningún commit:

git apply ../my-origin-develop.patch

Aplicar este parche simplemente cambiará tu sistema local de la misma manera que se creó el parche.

“Cómo hacerlo” por pasos #

Dividamos las responsabilidades en dos: el creador del parche y su usuario:

El creador del parche: la persona que creará el parche #

# Cambia a esa rama
$ ~/myProject git:(the-branch) ➜ git pull origin the-branch
# Haz tus sugerencias y cambios en la rama objetivo
# Genera el archivo de parche usando el comando diff
$ ~/myProject git:(the-branch) ➜ git diff > ../your-diff.patch
# Comparte el archivo de parche con el autor del PR

El usuario del parche: la persona que verá el parche #

# Asegúrate de estar en esa rama
$ ~/myProject git:(the-branch) ➜ git pull origin the-branch
# Aplica el archivo de parche
$ ~/myProject git:(the-branch) ➜ git apply ../your-diff.patch

Referencias #

Documentación oficial de “git apply”

Rompe la barrera del No

2020-06-12T00:00:00+00:00

Chris Voss pasó de patrullar las calles de Kansas City a ser el negociador principal de secuestros internacionales del FBI. Ahora enseña negociación en universidades de élite. Las técnicas de este libro las ha probado en todo tipo de situaciones y funcionan.

Aprendizajes #

Negociar empieza por escuchar. Hay que hacer que la conversación gire en torno al otro, validar sus emociones y crear la confianza necesaria para hablar de verdad.
Usa el “espejo” (repetir las últimas palabras del otro) para generar empatía, mantener la conversación viva, ganar tiempo y hacer que el otro revele su estrategia.
La empatía táctica te ayuda a ver tanto los obstáculos emocionales como los caminos posibles hacia un acuerdo.
Etiquetar emociones (ponerles nombre) te acerca al otro sin necesidad de preguntar por cosas que desconoces.
Un “no” es una oportunidad. Te permite a ti y al otro aclarar qué quieren realmente, descartando lo que no.

Video resumen #

El Camino del Manager

2020-03-26T00:00:00+00:00

Lecciones clave #

Las reuniones uno a uno con tu manager son esenciales para una buena relación laboral.
El trabajo de un manager es facilitar que su equipo haga las cosas, creando entornos donde el trabajo pueda fluir.
Mentorear a los nuevos empleados es crítico.
El feedback funciona mejor cuando lo combinas con coaching.
Es poco realista pensar que puedes o debes proteger a tu equipo de todo.

Programación Extrema Explicada

2020-03-05T00:00:00+00:00

Definición #

Extreme Programming (XP) es un framework ágil que busca producir mejor software y mejor calidad de vida para el equipo de desarrollo. Es el más específico de los frameworks ágiles en cuanto a prácticas de ingeniería.

Valores #

Los cinco valores de XP son comunicación, simplicidad, feedback, coraje y respeto.

Comunicación #

El desarrollo de software es un deporte de equipo. Depende de la comunicación para transferir conocimiento entre los miembros. XP enfatiza la comunicación cara a cara, preferiblemente con una pizarra a mano.

Simplicidad #

Simplicidad significa “¿qué es lo más simple que funcionará?” El objetivo es evitar el desperdicio y hacer solo lo necesario. Mantener el diseño lo más simple posible facilita el mantenimiento y la revisión. También significa abordar solo los requisitos que conoces ahora, sin intentar predecir el futuro.

Feedback #

Con feedback constante sobre el trabajo previo, los equipos identifican áreas de mejora y ajustan sus prácticas. El equipo construye algo, recoge feedback sobre el diseño e implementación, y ajusta el producto en consecuencia.

Coraje #

Kent Beck definió el coraje como “acción efectiva ante el miedo”. Necesitas coraje para:

Plantear problemas organizacionales que reducen la efectividad del equipo.
Dejar de hacer algo que no funciona y probar algo diferente.
Aceptar y actuar según el feedback, aunque sea difícil de escuchar.

Respeto #

Los miembros del equipo necesitan respetarse mutuamente para comunicarse bien, dar y recibir feedback de forma constructiva, y trabajar juntos en diseños y soluciones simples.

Principios #

Humanidad #

Los seres humanos desarrollan software. El libro menciona 5 cosas que necesitan los desarrolladores para crecer: seguridad básica, logro, pertenencia, crecimiento e intimidad.

La magia de los grandes equipos es que, una vez que desarrollan confianza, sus miembros se sienten libres de ser más ellos mismos.

Economía #

El software cuesta dinero. Alguien pagó o invirtió en él.

Asegúrate de que lo que haces tenga valor de negocio y sirva a sus necesidades. Resolver primero la necesidad más prioritaria maximiza el valor del proyecto.

Cuanto antes el software genere dinero, antes el desarrollo será valioso.

Beneficio Mutuo #

El beneficio mutuo en XP busca actividades que beneficien a todos los involucrados: a mí ahora, a mí después, y a los clientes.

El libro presenta 3 formas de comunicarte con el futuro:

Escribo tests automatizados que me ayudan a diseñar e implementar hoy. Los dejo para que los futuros programadores también los usen.
Refactorizo para eliminar complejidad accidental. Menos defectos y código más fácil de entender para quien venga después.
Elijo nombres de un conjunto coherente de metáforas. Acelera mi desarrollo y hace el código más claro para nuevos programadores.

Auto-Similaridad #

Copiar la estructura de una solución a un nuevo contexto.

Por ejemplo, la estructura básica del desarrollo: escribes un test que falla y luego lo haces funcionar. Esta estructura opera a todas las escalas. Ojo: es un buen comienzo, pero no siempre funciona.

Mejora #

Haz lo mejor que puedas hoy, pero esfuérzate por hacerlo mejor mañana. XP brilla aquí: se trata de mejorar siempre.

Pon la mejora a trabajar sin esperar la perfección. Encuentra un punto de partida, comienza y mejora desde ahí.

Diversidad #

Los equipos necesitan personas de diferentes orígenes, experiencias y actitudes. Así tienen diferentes formas de pensar y resolver problemas.

Los programadores deberían trabajar juntos en el problema y valorar ambas opiniones.

Reflexión #

Los buenos equipos reflexionan después de la acción, regularmente. Piensan sobre por qué y cómo están trabajando.

¿Por qué tuvimos éxito? ¿Qué deberíamos seguir haciendo?
¿Por qué fallamos? ¿Qué podemos hacer mejor?

Aunque todo parezca perfecto, siempre hay espacio para mejorar:

¿Por qué las cosas parecen perfectas? ¿Qué hacemos bien? ¿Qué podemos mejorar?

Flujo #

El flujo en desarrollo de software es entregar valor constante participando en todas las actividades simultáneamente. No entregues software en grandes porciones. Despliega incrementos más pequeños con más frecuencia.

Oportunidad #

Aprende a ver los problemas como oportunidades para aprender y mejorar.

Parte de ser extremo es elegir conscientemente transformar cada problema en una oportunidad: para el crecimiento personal, profundizar relaciones y mejorar el software.

Redundancia #

Los problemas difíciles deberían resolverse de múltiples maneras.

El costo de la redundancia se paga con creces por los ahorros de evitar un desastre.

Fracaso #

A veces no sabes qué camino tomar. Prueba las ideas que tienes, aunque fallen. El fracaso no es desperdicio, sino aprendizaje.

Cuidado con la trampa de discutir o pensar eternamente sin hacer nada.

Cuando no sabes qué hacer, arriesgarte al fracaso puede ser el camino más corto hacia el éxito.

Calidad #

Los proyectos no van más rápido bajando la calidad. Suele ser al revés. Resulta en entregas más tardías y menos predecibles por el tiempo dedicado a corregir bugs.

Aumentar la calidad suele resultar en entregas más rápidas.

La preocupación por la calidad no es excusa para la inacción. Si no conoces una forma limpia de hacer algo que hay que hacer, hazlo lo mejor que puedas. Si conoces una forma limpia pero tomaría demasiado tiempo, haz el trabajo tan bien como el tiempo te permita. Resuélvelo de forma limpia después.

Pasos Pequeños #

Da pasos pequeños. Hacer grandes cambios de golpe es peligroso. Las personas y equipos pueden dar muchos pasos pequeños y parecer que avanzan rápido.

Los pasos pequeños reconocen que su sobrecarga es mucho menor que cuando un equipo retrocede desperdiciando cambios grandes abortados.

Responsabilidad Aceptada #

La responsabilidad no puede asignarse; solo puede aceptarse. Si alguien intenta darte responsabilidad, solo tú puedes decidir si la aceptas o no.

Prácticas #

Se pueden hacer de forma aislada, pero muchos equipos han descubierto que algunas prácticas refuerzan a otras. Hacerlas juntas elimina los riesgos típicos del desarrollo de software.

Sentarse Juntos #

La comunicación es uno de los cinco valores de XP. Haz que tu equipo se siente junto en el mismo espacio sin barreras como paredes de cubículos.

Equipo Completo #

Incluye personas con todas las habilidades y perspectivas necesarias para que el proyecto tenga éxito.

Espacio de Trabajo Informativo #

Configura el espacio para facilitar la comunicación cara a cara, permite algo de privacidad cuando la necesiten, y haz el trabajo transparente para el equipo y las partes interesadas.

Trabajo Energizado #

Eres más efectivo en el desarrollo de software cuando estás enfocado y libre de distracciones.

Programación en Parejas #

Todo el software de producción lo desarrollan dos personas en la misma máquina. Dos cerebros y cuatro ojos son mejores que un cerebro y dos ojos. Obtienes revisión de código continua y respuestas más rápidas a problemas que podrían bloquear a una persona sola.

Los equipos que usan programación en parejas descubren que mejora la calidad sin tomar el doble de tiempo. Resuelven problemas más rápido y se mantienen más enfocados, escribiendo menos código para lograr lo mismo.

Los programadores en pareja:

Se mantienen mutuamente en la tarea.
Hacen lluvia de ideas sobre mejoras al sistema.
Clarifican ideas.
Toman la iniciativa cuando el compañero está atascado, reduciendo la frustración.
Se hacen mutuamente responsables de las prácticas del equipo.

La programación en parejas es un diálogo entre dos personas programando simultáneamente (analizando, diseñando y probando) e intentando programar mejor.

Si necesitas privacidad y tiempo para trabajar en una idea, adelante. Necesitamos tanto compañía como privacidad. Rota parejas frecuentemente y toma descansos: el pairing puede ser agotador, pero es gratificante.

Historias #

Describe lo que el producto debería hacer en términos significativos para clientes y usuarios. Son descripciones cortas de cosas que los usuarios quieren hacer. Sirven para planificar y como recordatorios para conversaciones más detalladas.

Dale a las historias un título corto y una descripción. Escríbelas en tarjetas y ponlas en una pared visible.

En XP las historias se estiman muy temprano. Esto hace que el equipo piense en cómo obtener el mayor retorno de la pequeña inversión.

Ciclo Semanal #

El Ciclo Semanal es una iteración. El equipo se reúne el primer día de la semana para reflexionar sobre el progreso. El cliente elige las historias que quiere entregar esa semana, y el equipo determina cómo abordarlas.

La idea es producir algo para mostrar al cliente y obtener feedback.

Build de Diez Minutos #

El objetivo es construir automáticamente todo el sistema y ejecutar todos los tests en diez minutos.

Integración Continua #

Los cambios de código se prueban inmediatamente al añadirse al código base. El beneficio: detectas y corriges problemas de integración antes.

Requiere disciplina extra y depende mucho del Build de Diez Minutos y el Desarrollo Test-First.

Programación Test-First #

Escribe un test automatizado que falle antes de cambiar cualquier código.

El libro menciona 4 problemas que aborda:

Expansión del alcance: Es fácil dejarse llevar y poner código “por si acaso”. Al declarar explícitamente lo que el programa debe hacer, te das un foco. Si quieres ese otro código, escribe otro test después.
Acoplamiento y cohesión: Si es difícil escribir un test, tienes un problema de diseño, no de testing. El código débilmente acoplado y altamente cohesivo es fácil de probar.
Confianza: Es difícil confiar en el autor de código que no funciona. Al escribir código limpio que funciona y demostrar tus intenciones con tests, das a tus compañeros razones para confiar en ti.
Ritmo: Es fácil perderse horas programando. Con test-first, siempre sabes qué hacer: escribir otro test o hacer que el test roto funcione. Se desarrolla un ritmo natural: test, código, refactorizar, test, código, refactorizar.

Diseño Incremental #

Invierte en el diseño del sistema todos los días.

Haces un poco de trabajo inicial para entender el diseño general, y luego profundizas en los detalles cuando entregas características específicas.

Este enfoque reduce el costo de los cambios y te permite tomar decisiones de diseño basándote en la información más actual.

Roles #

XP especifica prácticas, pero no establece roles específicos. Según la fuente, o no hay orientación, o hay descripciones de cómo los roles tradicionales se comportan en proyectos XP.

El Cliente #

Responsable de tomar todas las decisiones de negocio del proyecto.

Se asume que es una sola persona, pero la experiencia muestra que una persona no puede proporcionar toda la información de negocio de un proyecto.

El Desarrollador #

Como XP no necesita definición de roles, todos (excepto el cliente y un par de roles secundarios) se llaman desarrolladores. Son responsables de realizar las historias identificadas por el Cliente.

El Rastreador #

Su propósito es llevar el seguimiento de métricas relevantes para rastrear el progreso e identificar áreas de mejora.

El Coach #

Usualmente un consultor externo (o alguien de otra parte de la organización) que ha usado XP antes. Ayuda a mentorear al equipo en las prácticas XP y a mantener la autodisciplina.

¿Qué es XP? (en 2 min) #

Tech Talk de Kent Beck: XP 20 años después #

Cómo Mejorar tu Charla Técnica (o Cualquier Otra Presentación)

2019-11-18T00:00:00+00:00

A todos nos ha pasado estar en reuniones que parecían una pérdida de tiempo, con un “monólogo” difícil de seguir o menos interesante de lo que podría ser. Vamos a arreglar esto.

Por eso estuve pensando en ello e intenté obtener algunas claves para mejorar su calidad general. Se aplica a todas las presentaciones, pero también a las charlas técnicas y otras presentaciones técnicas en las que los ingenieros suelen estar involucrados.

Estructura de la charla #

Para explicar cómo creo que debería ser una buena presentación, abordaré tres temas principales relevantes para estructurar y diseñar tu presentación.

Contenido de la presentación: ¿qué mensaje quieres transmitir, a quién y cómo?
Diseño y maquetación: cómo puedes diseñar una presentación fácil de seguir que apoye tu charla en lugar de desviar la atención de lo que realmente intentas decir.
Por último, creo que la audiencia también es responsable de que una charla técnica sea exitosa, así que añadiré un recordatorio sobre el rol y las responsabilidades de los oyentes.

Considera tu audiencia #

Cuando prepares tu presentación, pregúntate:

¿Quién asiste a la charla?
¿Qué formación tienen?
¿Qué posición ocupan?
¿Qué información es relevante para ellos?
¿Tienen que conocer todas las palabras clave que te gustaría usar?

Introduce el tema #

Crea algo de atmósfera. Intenta responder estas preguntas:

¿Por qué deberían escucharte?
¿Por qué deberían pasar su tiempo en otra reunión?
¿Qué habrán aprendido al final de la charla?
¿Cuál es tu mensaje principal?

Cada reunión debería tener un resultado tangible y un objetivo claro. Tenlo en mente.

Crea una línea argumental #

Al preparar el contenido principal de tu charla, piensa en una línea argumental que conecte tus argumentos. Esto facilita que la audiencia te siga.
Limítate a los mensajes necesarios para explicar tu idea o concepto.
Deja fuera cualquier información innecesaria que no sea relevante para el núcleo de tu mensaje.

Construye una conclusión #

Resume la(s) conclusión(es) principal(es) de forma concisa:

¿Cuál es la conclusión de esta reunión?
¿Cuáles son los aprendizajes de esta reunión?
¿Cuáles son las preguntas abiertas o los siguientes pasos?

Diseño y maquetación #

Escribe menos, habla más #

Una charla técnica trata sobre aprender nuevas ideas y conceptos.
Una presentación debería apoyar tu charla, no reemplazar o replicar lo que has dicho.
Cuantas más palabras en la diapositiva, menos se recordarán.
Usa visuales/gráficos que apoyen tu charla en lugar de texto adicional.

Fuentes grandes #

Si tienes código que presentar, considera:

Si es una imagen: usa fuentes grandes dentro. Recomiendo usar https://carbon.now.sh/ para snippets simples. O simplemente capturas de pantalla de tu IDE favorito.
Si programas en vivo: prepara tu editor de antemano. Usa el Modo Presentación de tu IDE.

Rol de la audiencia #

Responsabilidades del asistente #

Nada de uso innecesario del móvil, como Twitter, Instagram, Facebook, WhatsApp, Telegram, etc.
Guarda tus preguntas para el tiempo de preguntas, a menos que el presentador mencione al principio que puedes preguntar en cualquier momento. Normalmente es mejor no interrumpir el tema, así que podemos hacer las preguntas al final.
Muestra interés en el tema. El presentador ha dedicado tiempo a preparar las diapositivas para ti.
Comparte el entusiasmo del presentador por el tema. Esto también es responsabilidad del presentador: ambos deberíais tener ganas de aprender más sobre el tema.

Preguntas internas #

¿Valió la pena el tiempo que todos pasamos en esta sala?
¿Nos arrepentimos de haber asistido a esta reunión?

Al final de la reunión, deberíamos hacernos estas preguntas para mejorar. Pide opiniones a otras personas para que podamos crecer más y juntos.

El Programador Limpio

2016-08-01T00:00:00+00:00

Los programadores que triunfan bajo presión e incertidumbre comparten algo: les importa de verdad crear buen software. Lo tratan como un oficio. Son profesionales.

Aprenderás #

Qué significa ser un verdadero artesano del software
Cómo lidiar con conflictos, plazos ajustados y jefes difíciles
Cómo entrar en flujo y superar el bloqueo
Cómo manejar la presión y evitar el agotamiento
Cómo combinar actitudes clásicas con nuevos paradigmas de desarrollo
Cómo gestionar tu tiempo y evitar atascos
Cómo crear entornos donde los programadores y equipos prosperen
Cuándo decir No y cómo hacerlo
Cuándo decir Sí y qué implica realmente

Resumen #

Capítulo 1: Profesionalismo #

Ser profesional significa asumir responsabilidad total de tus acciones.
Primera regla: no dañes ni la función ni la estructura del software.
Siempre cometerás errores, pero aprende de cada uno.
Confía en el código que liberas. Espera que QA no encuentre nada.
- Prueba una y otra vez.
- Automatiza tus tests.
- Diseña el código para que sea fácil de probar.
Sigue la regla del Boy Scout: deja el código un poco más limpio de como lo encontraste.
Tu carrera es tu responsabilidad, no la de tu jefe.
- Dedica 20 horas semanales extra a mejorar tus habilidades.
- Lee, experimenta, practica (katas), habla con otros, colabora, mentoriza.
- Que sea divertido.
Conoce tu dominio e identifícate con tu cliente (nunca “nosotros vs. ellos”).

Capítulo 2: Decir No #

Los profesionales tienen el coraje de decir no a sus jefes.
Managers y desarrolladores a menudo chocan porque sus objetivos a corto plazo entran en conflicto.
Cuanto mayor el riesgo, más valioso es un “no” y más difícil de decir.
Los buenos equipos trabajan hacia un sí, pero solo un sí correcto que funcione en la práctica.

Capítulo 3: Decir Sí #

Hay tres partes para hacer un compromiso:
- Dices que lo harás
- Lo dices en serio
- Realmente lo haces
Tu compromiso debe respetar los límites de lo que esperas (basado en tu experiencia) poder y no poder hacer.
- Si reconoces que probablemente no podrás cumplir un compromiso, necesitas levantar una bandera roja inmediatamente.

Capítulo 4: Codificación #

Programar requiere un nivel de concentración que pocas disciplinas exigen.
“La zona” (o flujo) no es tan buena como parece: serás productivo localmente, pero puedes perder la visión global y producir diseños mediocres.
Las interrupciones son malas distracciones.
- El pair programming ayuda a gestionarlas.
- TDD hace que el contexto pre-interrupción sea reproducible.
  - Minimiza el tiempo de depuración.
Programar es una maratón, no un sprint. Conserva energía y creatividad.
Vete cuando sea hora, aunque estés en medio de algo importante.
Reestima continuamente tu tiempo de finalización y avisa en cuanto veas que llegarás tarde.
- No dejes que nadie te meta prisa.
- Define bien qué significa “terminado”, con requisitos de calidad altos.
Programar es difícil para todos. Pide ayuda y ofrécela, especialmente como mentor.
- No tengas vergüenza de preguntar.

Capítulo 5: Test-Driven Development #

TDD no es una cura milagrosa y es impráctico o inapropiado en algunos casos (raros).
Ciclo TDD:
1. Añade un test
2. Ejecuta todos los tests. El nuevo test debería fallar por razones esperadas
3. Escribe el código más simple que pase el nuevo test
4. Todos los tests deberían pasar ahora
5. Refactoriza según sea necesario
6. Repite

Capítulo 6: Practicar #

Una Kata de programación es un conjunto preciso de pulsaciones de teclas y movimientos de ratón coreografiados que simula la resolución de algún problema de programación.
- Una Kata es sobre el proceso, no la solución.
- No estás resolviendo el problema porque ya conoces la solución.

Capítulo 7: Tests de Aceptación #

Evita “basura entra, basura sale”. Asegúrate de entender los requisitos.
- Entenderlos bien significa eliminar ambigüedad.
La mejor forma es definir tests de aceptación:
- Los tests automatizados verifican que el software cumple las condiciones del cliente.
- Pasar esos tests define “Terminado”.
Empieza a implementar solo cuando los tests estén definidos.
Los tests unitarios son para programadores. Los tests de aceptación son para negocio y desarrolladores.
Ejecuta todos los tests en integración continua y arregla los fallos de inmediato.

Capítulo 8: Estrategias de Testing #

QA es parte del equipo. Escriben tests de aceptación, casos de fallo, casos límite y hacen testing exploratorio.
Pirámide de testing:
- La mayoría son tests unitarios: por y para desarrolladores.
- Muchos son tests de componentes o integración: por QA/Negocio con ayuda de desarrolladores, para ambos.

Capítulo 9: Gestión del tiempo #

En desarrollo de software, gestionar bien el tiempo es esencial.
Las reuniones son necesarias pero a menudo una pérdida de tiempo. Evita las que no aporten valor claro: es una obligación profesional.
Las reuniones deben tener agenda y objetivo claro.
- Las dailies ágiles son un formato eficiente.
- La planificación de iteración debería ocupar el 5% de la iteración.
La concentración es un recurso escaso.
- Úsala cuando la tengas y recarga con tareas simples y descansos.
- Para mejorarla:
  - Haz deporte.
  - Busca estímulos creativos.
  - Toma descansos cortos cada 45 minutos.

Capítulo 10: Estimación #

Las estimaciones son la mayor fuente de desconfianza entre negocio y desarrolladores. Los desarrolladores dan estimaciones que negocio trata como compromisos.
- Ambos olvidan que una estimación es una distribución de probabilidad, no un número fijo.

Capítulo 11: Presión #

El profesional mantiene la calma bajo presión. Sigue sus disciplinas porque sabe que es la mejor forma de cumplir plazos.
Evita situaciones de presión:
- Haz solo compromisos que puedas cumplir.
- Mantén tu código limpio.
- Trabaja de forma que no necesites cambiar de método en crisis.
No entres en pánico. Habla con tu equipo. No te aceleres. Confía en tus disciplinas.
Ofrece hacer pairing a compañeros en crisis.

Capítulo 12: Colaboración #

A la mayoría de programadores les gusta trabajar solos. Pero hay que entender los objetivos de quienes nos rodean, incluido negocio.
- Eso requiere comunicación.
Dentro del equipo: solo la propiedad colectiva del código y el pairing producen buena comunicación.
- Programar es comunicarse.

Capítulo 13: Equipos y proyectos #

Los equipos necesitan meses para consolidarse, conocerse y aprender a trabajar juntos.
- Asignar personas a varios proyectos a la vez es mala idea. Romper un buen equipo también.
- Mejor asignar varios proyectos a un mismo equipo.

Capítulo 14: Mentoría, aprendizaje y artesanía #

Los programadores jóvenes necesitan mentoría, ya sea implícita o explícita.
El software controla todos los aspectos de nuestras vidas. Un período de entrenamiento y práctica supervisada es más que apropiado.

En esta lección, Uncle Bob explica por qué es necesario escribir código limpio y establece las bases para lograrlo, tanto sociales como técnicas. El futuro de la programación se basa en un código ético y bien educado.

En esta segunda lección, Uncle Bob habla del propósito de los comentarios. Rompe la idea de que comentar es algo que “hay que hacer” por ser supuestamente buena práctica. Para él, escribir un comentario es señal de fracaso: el buen código se explica solo. Menos comentarios = mejor código.

En esta tercera lección, Uncle Bob quiere crear conciencia sobre la necesidad de elevar el criterio al producir código. Señala la falta de preparación de muchos programadores como una de las principales causas de la ineficiencia en el desarrollo de software actual.

En esta cuarta lección, Uncle Bob introduce el Test-Driven Development (TDD). Es una práctica con curva de aprendizaje larga, pero produce código más robusto, seguro, mantenible y desarrollado con mayor eficiencia.