Chemaclass - leadership

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.

Los Niveles de Adopción de la IA

2026-05-01T00:00:00+00:00

La mayoría de empresas ya usa IA, pero pocas saben en qué punto están de la escalera de adopción. En un extremo, copias código a ChatGPT. En el otro, los agentes abren PRs mientras duermes. Más allá, la IA llega a gente que nunca tocó una terminal. Este post mapea el camino.

De dónde venimos #

Usar IA para programar era tener una segunda pestaña. Escribes una función, te atascas, pegas el error en el chat, pegas la respuesta de vuelta y rezas para que funcione. Lento, torpe, desconectado de tu código.

GitHub Copilot, sobre el Codex inicial de OpenAI, metió sugerencias dentro del editor, y a menudo se equivocaba con mucha seguridad. Estaba entrenado con código público, y el código público medio no es gran cosa. Tampoco sabía nada de tu dominio, tus convenciones ni tu arquitectura. Era autocompletado que a veces acertaba.

La primera generación de herramientas de IA para programar te daba un loro entrenado con todo internet. Fluido, seguro, y diciendo cosas que no tenían sentido en tu código.

Esto era vibe-coding en su primera forma: tú ponías el vibe pegando contexto y la IA rellenaba código que parecía correcto. Compilaba lo suficiente para parecer útil, y se rompía lo suficiente para parecer peligroso.

La generación de los IDEs #

El siguiente paso era obvio: si la IA necesita contexto, dale el editor entero.

Cursor, Windsurf y otros IDEs parecidos metieron el modelo dentro de tu flujo de programación. El asistente podía leer archivos, seguir imports y ver más de una función a la vez. El vibe-coding pasó a ser una conversación con tu proyecto, y la productividad subió. Por un momento pareció el final del juego.

No lo era. Editar archivos es solo una parte del trabajo. El resto es correr tests, leer logs, abrir ramas, revisar diffs y entender qué hace ya el código. Los asistentes que solo vivían en el editor te ayudaban a escribir más rápido, pero no sabían llevar una tarea de “arregla este bug” a “PR listo para revisar.”

El salto agéntico #

OpenAI lanzó Codex como agente en la nube: le das una tarea, trabaja en una rama y tú vuelves a un PR. Anthropic sacó Claude Code, un agente de CLI en tu terminal, sobre tu repo, con tus herramientas.

Este fue el gran salto, y no porque los modelos fueran más listos. Lo que cambió fue la unidad de trabajo. Dejaste de promptear línea a línea y empezaste a delegar tareas: lee el ticket, escribe el cambio, corre los tests, explica lo que hiciste. Un agente no necesita que lo lleves de la mano. Necesita un objetivo y el contexto adecuado.

El salto de asistente a agente no es una mejora de velocidad. Es un cambio en la descripción del puesto. Pasas de escribir código a dirigir trabajo.

Claude Code casi no necesita setup. Sin lock-in de editor. Apúntalo a tu repo, suelta una carpeta .claude con reglas y convenciones, y se adapta. Lo conté en Dentro de la Carpeta .claude.

El modelo que eliges importa más que antes. Los modelos frontera de hoy están muy por delante de los de hace un año. La distancia entre “puede esbozar una función” y “puede refactorizar un módulo con criterio” se cerró más rápido de lo esperado, y sigue cerrándose mientras Claude, Codex y Gemini se empujan mutuamente cada mes. Los precios también se están acercando, lo cual es una forma educada de decir que todos copian al primero que acierta con la versión sostenible.

Agentes con casa propia #

El siguiente salto no fueron modelos más listos, fueron agentes con su propia máquina.

OpenClaw es el ejemplo más claro. Es un gateway open source que corres en tu propio hardware (Mac Mini, portátil viejo, VPS), un agente siempre encendido conectado a tus apps de mensajería, archivos y calendario. Tú pones el cerebro: Opus, GPT o un modelo local vía Ollama. Cuando un proveedor aprieta límites o sube precios, cambias. El setup es tuyo.

Un agente de programación vive dentro de un repo durante una tarea. Un agente estilo OpenClaw vive en tu vida, a lo largo de días y herramientas. Sauron es el mío. Revisa mis PRs, abre issues, escribe código, saca contribuciones a open source y me lleva la contraria cuando estoy a punto de obsesionarme con algo. Cualquier cosa que yo pueda hacer en un ordenador, él también la hace, solo que más rápido. Deja de ser una herramienta que abres y pasa a ser un sitio donde trabajas.

Un agente de programación es un compañero al que invitas a una tarea. Un agente gateway es un compañero que vive en una máquina y aparece cada día.

Los proveedores cambian planes y límites más rápido de lo que nadie puede seguir, así que la gente monta setups que no dependen de un solo proveedor. El logo del modelo importa menos cada trimestre, y la arquitectura alrededor importa más.

IA más allá de los desarrolladores #

La IA para programar fue la historia más ruidosa porque los desarrolladores hablamos alto. La historia más grande es que las herramientas agénticas están llegando a gente que nunca escribió una línea de código.

El modo agente de ChatGPT y Cowork de Claude son los ejemplos obvios: una IA que lee tus documentos, rellena tus hojas de cálculo, redacta tus slides y corre código por ti en segundo plano. Claude Design salió el 17 de abril y tumbó la acción de Figma más de un 7% el día del lanzamiento. El pitch es sencillo: describe lo que quieres, consigue un prototipo que funciona y pásaselo a Claude Code para llevarlo a producción. Un flujo que antes necesitaba un diseñador, un PM, un ingeniero de frontend y tres rondas de revisión queda comprimido en una conversación.

Lovable, v0, Canva y la propia Figma están bajo presión para repensar su posicionamiento. Si Claude Design “mata” a alguno es la pregunta equivocada. La correcta es qué pasa cuando hacer un prototipo usable baja de “contrata un diseñador” a “descríbelo en voz alta.”

Las empresas que lo sienten primero no son las herramientas de diseño. Son los negocios pequeños que no podían pagar diseño, los founders montando un pitch deck a las tantas de la noche, los PMs probando una idea antes de convocar una reunión. Habrá una minoría de casos donde alguien sí hubiera pagado a un diseñador y ahora no lo hace, y ese coste es real. Pero en la mayoría, la IA no reemplazó a nadie: rellenó un hueco donde nunca iba a haber uno.

Los niveles de adopción de la IA #

Cada empresa con la que hablo está en algún punto de esta escalera. Los niveles no van de cuánto pagas en licencias, sino de cuán metida está la IA en cómo se hace el trabajo, y no solo en ingeniería.

Nivel 0: Negación #

Postura a nivel empresa. Nada de IA, oficialmente. Algunas personas usan ChatGPT en su portátil personal y no lo mencionan. A la dirección le preocupan las fugas de propiedad intelectual, o no lo ha puesto como prioridad. La conversación se queda en “deberíamos mirarlo algún día.”

El riesgo aquí no es la tecnología, es el tiempo. Cada mes en el Nivel 0 es un mes en el que tu competencia aumenta su ventaja.

Nivel 1: Productividad personal #

Adopción individual. La IA se tolera, quizá hasta se anima. Cada uno la usa a su manera: ChatGPT en una pestaña, Copilot en el IDE, Claude para lo más peliagudo, una herramienta de diseño para los mockups. La producción sube, pero el know-how se queda dentro de cada cabeza. Dos ingenieros, dos PMs o dos diseñadores del mismo equipo sacan resultados muy distintos porque promptean distinto.

La mayoría de empresas están aquí a principios de 2026. Es una mejora real frente al Nivel 0, y es donde nace el mito de “la IA te da velocidad”. Como ya defendí antes, velocidad sin dirección compartida es caos más rápido.

Nivel 2: Prácticas compartidas #

El equipo acuerda cómo usar la IA: convenciones compartidas, prompts que la gente reutiliza, reglas en el repo, un criterio común sobre cuándo fiarse del output y cuándo discutirlo. Las code reviews pillan los errores de IA igual que pillan los humanos, y las design reviews también. Se exigen tests tanto si escribió el código una persona como si lo escribió un modelo.

Este es el primer nivel en el que la IA pasa a ser una capacidad de equipo en vez de un hábito personal. Techo más alto, suelo más alto. La gente nueva se pone al día más rápido porque los prompts y las reglas capturan cómo trabaja el equipo.

Nivel 3: Herramientas con contexto #

El equipo invierte en contexto: archivos de reglas, convenciones, docs de arquitectura que los agentes pueden leer y servidores MCP que conectan a los agentes con las bases de datos, APIs y herramientas internas que necesitan. La IA deja de ser un asistente genérico y se parece más a un compañero que se ha leído los docs de onboarding.

A este nivel, la calidad depende menos del modelo y más del contexto que lo rodea. Un modelo más flojo con buen contexto le gana a un modelo frontera sin él. Una buena documentación y una arquitectura limpia rinden el doble: ayudan tanto a humanos como a agentes.

Nivel 4: Equipos de agentes #

En vez de un asistente, tienes un escuadrón: un coach de TDD, un revisor de clean code, un arquitecto de dominio, alguien que mantiene la documentación. Fuera de ingeniería, la misma idea aplica con agentes de research, diseño y ops. Cubrí el lado de desarrollo en Construye tu Propio Equipo de Agentes, y el leverage es real.

Los humanos dejan de competir con la IA en velocidad y empiezan a dirigirla. Revisas, decides y marcas el listón. Los agentes se encargan de teclear, y cada vez más de pensar. El pair programming con una persona sigue ganando en los trade-offs complejos, pero siempre tienes un agente disponible para el resto.

A nivel empresa, el organigrama, los roles y los procesos siguen siendo los de antes. Lo que cambia es que cada persona produce mucho más, y eso se nota en los resultados del equipo. El Nivel 4 multiplica el output dentro de la estructura existente. El Nivel 5 cambia la estructura.

Nivel 5: Flujos nativos de IA #

El cambio final es sobre cómo funciona la empresa. Los procesos se diseñan alrededor de los agentes en vez de encajarlos a la fuerza. Los tickets se redactan para que un agente pueda actuar sobre ellos, y las revisiones asumen que parte del trabajo lo escribió una máquina. Las decisiones de arquitectura tienen en cuenta lo que los agentes hacen bien y lo que no. Incluso cambia la contratación: un IC senior en el Nivel 5 se parece más a un tech lead orquestando un equipo mixto de personas y agentes que a un contribuidor individual clásico.

Pocas empresas están del todo aquí en 2026, pero la dirección es lo bastante evidente como para que ignorarla sea, en sí misma, una decisión.

No subes de nivel comprando mejores herramientas. Subes cambiando cómo se organiza y se revisa el trabajo.

La IA no te está robando el trabajo #

Sigo oyendo a gente contar esto como una historia de despidos. Ese encuadre es vago.

La revolución industrial no acabó con el trabajo. Acabó con tipos concretos de trabajo y creó otros. Los que más perdieron se negaron a reciclarse. Los que más ganaron aprendieron a manejar las máquinas nuevas en lugar de competir con ellas.

El patrón es el mismo. La IA no te quita el trabajo, está cambiando en qué consiste tu trabajo. Un desarrollador que aprende a dirigir agentes entrega más que uno que se niega. Una diseñadora que hace diez versiones antes de comer con Claude Design diseña más que una que sigue abriendo Figma desde cero. Un PM que envía prototipos prioriza mejor que uno que escribe specs que nadie lee.

La IA no reemplaza al trabajador con habilidades. Reemplaza al trabajador que cree que la habilidad es un activo fijo en vez de un objetivo móvil.

Con la formación, el modelo y el setup adecuados para tu contexto, la IA te da 10x de velocidad sin perder calidad. Lo he visto, y no es marketing. Pero el 10x solo aparece cuando ya sabes qué es “bueno”. Sin esa base, la IA produce encantada 10x más de trabajo mediocre.

Esa es la versión honesta de la promesa: la IA puede producir basura diez veces más rápido, y trabajo excelente diez veces más rápido. Cuál te toca depende de ti.

A dónde cambia tu atención #

Dejas de pensar primero en los detalles y empiezas a pensar en la dirección: qué estamos construyendo, para quién, con qué forma y con qué trade-offs. Los agentes hacen luego la mayor parte de la implementación mientras tú proteges la calidad y la coherencia.

Esto suena a buenas noticias para quien prefiera la arquitectura a teclear, y lo es. Pero hay una trampa: solo puedes trabajar en el nivel alto si conoces el nivel bajo lo bastante bien como para pillar las desviaciones. Cuando el agente produce algo sutilmente mal (un test que pasa por la razón equivocada, un refactor que cambia el comportamiento bajo carga, un diseño que se rompe en móvil), necesitas verlo al instante. Si no puedes, no estás dirigiendo. Estás dando el visto bueno a lo que aparezca.

La IA te deja dedicar más tiempo a la dirección, pero solo si ya te ganaste el derecho a ignorar los detalles. Ese derecho se gana dominándolos antes.

Por qué importa la escalera #

Veo equipos que se saltan niveles y fracasan. Un equipo salta del Nivel 1 al Nivel 4 porque la dirección leyó un post sobre escuadrones de agentes, y los agentes producen montañas de código malo porque nadie acordó qué significa calidad. Los agentes no son el problema. Lo es la base que falta.

La escalera es un orden que importa. Prácticas compartidas antes que context engineering, context engineering antes que equipos de agentes, y equipos de agentes antes que flujos nativos de IA. Cada nivel se construye sobre el anterior, igual que el clean code se construye sobre el naming y el naming sobre saber qué estás modelando.

Las empresas que van a ganar los próximos años no son las que tienen el mayor presupuesto en IA. Son las que suben esta escalera con intención, un nivel cada vez, sin saltarse las partes que parecen aburridas.

Por dónde empezar #

En Nivel 0 o 1, el siguiente paso no es comprar más licencias. Es decidir, como equipo, cómo usar estas herramientas. Escríbelo, commitéalo al repo y revísalo cada pocos meses a medida que las herramientas cambian.

En Nivel 2 o 3, mira dónde falta contexto. ¿Qué no sabe tu IA de tu codebase, tu producto o tu marca que una persona recién contratada aprendería la primera semana? Escríbelo. Una tarde de reglas y docs te rinde durante meses.

Más arriba, la pregunta se invierte. Dejas de preguntarte “¿cómo uso mejor la IA?” y empiezas a preguntarte “¿cómo tiene que cambiar mi equipo para que la IA amplifique lo que ya hacemos bien?” Esa es una pregunta de liderazgo, no de tooling.

La IA va rápido, pero el trabajo de adoptarla sigue siendo lento y humano. Las herramientas son la parte fácil. La parte difícil es decidir qué es “bueno”, escribirlo y sostener la línea.

La IA puede ejecutar, pero no sabe a dónde vas. Puede producir, pero no sabe qué vale la pena producir. Esa parte sigue siendo nuestra. La velocidad es un regalo, la dirección es una responsabilidad. Del ingeniero en solitario del Nivel 1 a la organización nativa de IA del Nivel 5, la misma verdad se mantiene: el humano supervisa, entiende y da sentido. La máquina hace el resto.

Cuando se relaje el hype (y se relajará), la pregunta no va a ser “¿usaste IA?”, todo el mundo lo habrá hecho. La pregunta va a ser “¿a qué nivel, y con qué dirección?”

Idealismo vs Pragmatismo

2026-03-01T00:00:00+00:00

Crees en la arquitectura limpia, los tests exhaustivos, los procesos disciplinados. También subiste un fix feo a las 11 de la noche el mes pasado porque el sistema estaba caído y los usuarios esperaban.

Ambas cosas eres tú. La tensión entre ellas no es una contradicción. Es cómo se hace este trabajo en realidad.

Dos fuerzas, una decisión #

El idealismo es la brújula. Código limpio, comportamiento testeado, entendimiento compartido, diseño con principios. Sin él, te desvías. Cada atajo se acumula, cada hack engendra otro hack, y al final mantienes un sistema que nadie quiere tocar. La mala calidad del software costó a las empresas estadounidenses $2.41 billones en 2022, con la deuda técnica como factor principal. Así se ve “ya lo arreglaremos después” a escala.

El pragmatismo es el motor. Deadlines, información incompleta, recursos limitados, requisitos cambiantes. Sin él, nunca entregas. Pasas semanas perfeccionando una abstracción que el negocio abandonó hace dos sprints.

El objetivo no es elegir un bando. Es saber cuándo debe liderar cada uno.

El idealismo sin pragmatismo produce código bonito que nadie usa. El pragmatismo sin idealismo produce un producto que funciona hoy y se desmorona mañana.

TDD: el beneficio y el coste #

Creo en el desarrollo guiado por tests. Red, green, refactor. El ritmo te obliga a pensar antes de programar, a especificar lo que quieres antes de construirlo. Produce mejores diseños, ciclos de feedback más cortos y código que puedes refactorizar con confianza.

Ese es el ideal. Y no es solo una sensación. Un estudio en cuatro equipos de Microsoft e IBM encontró que TDD redujo la densidad de defectos entre un 40% y un 90%, con un incremento del 15-35% en tiempo de desarrollo. Ambos lados de la tensión, medidos.

El estudio cubrió cuatro equipos: tres en Microsoft (Windows, MSN, Visual Studio) y uno en IBM trabajando en drivers de dispositivo. Cada equipo TDD fue comparado con un equipo similar en el mismo producto, usando los mismos lenguajes y herramientas, bajo el mismo manager senior. La única diferencia era TDD.

El equipo de IBM vio una reducción del 40% en densidad de defectos. Los equipos de Microsoft oscilaron entre el 60% y el 90%. Como señaló Nagappan, “en un ciclo de desarrollo de 12 meses, un 35 por ciento son otros cuatro meses, lo cual es enorme.” Todos los managers lo consideraron rentable porque la reducción en costes de mantenimiento post-lanzamiento compensaba de sobra.

Nadie fue forzado a usar TDD. Los equipos lo adoptaron voluntariamente, lo cual probablemente importa: las personas que eligen una práctica tienden a aplicarla mejor que quienes reciben la orden.

TDD es una disciplina, y la disciplina cuesta algo. Cuando estás explorando un dominio nuevo y aún no sabes cuáles son las abstracciones correctas, escribir tests primero puede parecer como dibujar un mapa sin haber visto el territorio. A veces necesitas escribir código desechable, probar una solución, tantear el espacio del problema. El descubrimiento no siempre sigue un ritmo red-green-refactor.

Hay una diferencia entre “sé lo que esto debe hacer y lo especificaré primero” y “aún no estoy seguro de lo que debe hacer.” TDD brilla en el primer escenario. En el segundo, un enfoque test-last (o incluso sin tests durante la exploración) puede ser más honesto.

La clave es lo que pasa después del descubrimiento. Una vez que entiendes el problema, vuelve y escribe los tests. Codifica lo que aprendiste. El desvío pragmático no significa abandonar el ideal; significa llegar a él por otro camino.

Como comenté en TDD vs BDD, el poder de TDD es su ciclo de feedback. Pero un ciclo de feedback requiere saber qué feedback estás buscando. Cuando aún lo estás averiguando, forzar el ciclo puede frenarte más de lo que ayuda.

El error no es elegir test-first o test-last. El error es convertirlo en una decisión religiosa en lugar de contextual. El idealista dice “siempre tests primero.” El pragmático dice “testea cuando tenga sentido.” Yo digo: tests primero cuando puedo, tests después cuando debo, pero siempre tests.

TDD es una brújula, no una jaula. Síguelo cuando puedas ver el camino. Cuando no, encuentra el camino primero y márcalo después.

Pair programming: el ideal y el overhead #

El pair programming efectivo es una de las mejores prácticas que un equipo puede adoptar. Dos personas, un problema, revisión de código continua. El conocimiento se propaga, el diseño mejora, los puntos ciegos se reducen.

Ese es el ideal. Y en muchos contextos, es la decisión correcta.

Pero el pairing tiene un coste. Exige tiempo sincrónico, foco compartido y niveles de energía compatibles. En un equipo distribuido con distintas zonas horarias, encontrar ventanas de solapamiento ya es difícil. Llenarlas con sesiones de pairing deja poco espacio para trabajo individual profundo. Algunos problemas se benefician de una persona profundizando tres horas, no de dos a medio gas durante seis.

Existen múltiples patrones de pairing: Driver-Navigator, Ping-Pong, Tourist Guide. Cada uno encaja en contextos diferentes.

Los anti-patrones también importan. El Socio Silencioso que deja que el otro haga todo el trabajo. El Dictador que no suelta el teclado. El Par Filosófico que pasa toda la sesión debatiendo convenciones de nombres en lugar de escribir código.

El pairing funciona mejor cuando ambas personas están involucradas, el problema se beneficia de dos perspectivas y la sesión tiene un alcance claro. Cuando falta alguna de esas condiciones, el pairing se convierte en un ritual en lugar de una práctica. Y los rituales sin propósito son solo overhead.

Las pull requests y el pair programming no son excluyentes. Sirven necesidades diferentes. A veces la revisión asíncrona es suficiente. A veces necesitas el ida y vuelta en tiempo real. La elección pragmática depende del problema, las personas y el momento.

El objetivo del pairing no es hacer pairing. Es construir entendimiento compartido y detectar errores pronto. Si otro enfoque lo consigue en tu contexto, úsalo.

IA: de escéptico a líder de escuadrón #

Hace un año, era escéptico con los asistentes de código con IA. Mi preocupación: una IA que no entiende la arquitectura, no le importa la mantenibilidad y prioriza velocidad por encima de calidad producirá código que impresiona pero se deteriora rápido. Escribí sobre esto en La IA te da velocidad, no calidad, y mantengo el mensaje central.

Mi preocupación no cambió. Lo que cambió es cómo los uso, y de lo que son capaces ahora.

La resistencia #

Las reacciones de otros ingenieros me sorprenden más que la tecnología. Miedo, escepticismo, rechazo total. Lo entiendo. Yo estuve ahí. Algo en lo que invertiste años de repente lo hace una máquina, al menos en parte. Se siente personal. Pero aferrarse a cómo eran las cosas no protege el oficio. Solo retrasa tu propio crecimiento.

Un equipo, no un asistente #

La mayoría de los ingenieros tratan a los agentes de IA como autocompletado con esteroides. Un asistente, un chat, un flujo de código generado. Yo empecé a tratarlos como un equipo. No un asistente parlanchín. Un escuadrón real. Uno piensa arquitectura. Otro escribe el primer borrador. Otro revisa y detecta bugs. Otro escribe tests. Cuando colaboran, el resultado no es solo más rápido. Es estructuralmente mejor.

La velocidad es la parte fácil, y todo el mundo está obsesionado con ella. La IA puede escupir toneladas de código en segundos. Sigue sin importarle la legibilidad, los casos borde o cómo se verá el código en seis meses. Tú sigues siendo quien tiene que apropiárselo, entenderlo y sentirse bien al subirlo a producción.

Antes pensaba que la IA no podía escribir código limpio. Luego lo probé en mis términos: contexto adecuado, reglas, convenciones, roles especializados, puertas de calidad. Con la configuración correcta, la IA puede escribir código realmente bueno. A veces necesita varias iteraciones, pero nosotros también.

La diferencia es que la IA llega más rápido y no se cansa entre iteraciones. Con buen contexto y restricciones claras, los resultados han sido mejores de lo que esperaba. A menudo mejores que lo que yo produciría solo bajo presión de tiempo.

Pero nada de esto funciona si no sabes cómo es una buena arquitectura. Tienes que haber leído los libros, experimentado, fallado, aprendido. Necesitas entender qué significan las decisiones de diseño de alto y bajo nivel para tu proyecto. La IA amplifica lo que tú aportas. Si traes fundamentos sólidos, obtienes resultados sólidos. Si no, obtienes basura con aspecto convincente que ni siquiera reconocerás como basura.

Seguimos siendo los responsables de mantener el sistema en buen estado. La IA nos ayuda a llegar. Pero solo si ponemos de nuestra parte.

Donde el idealismo se encuentra con la IA #

La IA me hizo más idealista, no menos. Las prácticas que describí antes, TDD y pair programming, solían competir con los deadlines. Ahora ya no tienen por qué.

Me gusta practicar TDD, pero recientemente experimenté con un agente dedicado para ayudarme con tests, y es sorprendentemente bueno. Un coach de TDD que guía el ciclo red-green-refactor. Un explorer que lee el código antes de que yo lo toque. Un revisor de código limpio, un arquitecto de dominio, un revisor de React, un mantenedor de documentación. Cada uno especializado, cada uno apoyando mi forma de pensar y mi ritmo. Si se añade lógica nueva sin cobertura, el agente de TDD lo detecta. 100% de cobertura de código solía ser el tipo de objetivo que pondrías en una retro y abandonarías silenciosamente para el tercer sprint. Con un agente dedicado aplicándolo, es simplemente cómo funciona el proyecto.

Sigo practicando pair programming con personas reales para temas complejos. El ida y vuelta humano tiene una profundidad que la IA no alcanza, especialmente cuando navegas trade-offs que requieren experiencia y juicio. Pero en el día a día, siempre tengo un agente pair buddy conmigo. Le lanzo ideas, cuestiono un enfoque, discuto casos borde, exploro un diseño antes de comprometerme con él. Apoya mis pensamientos, acelera el progreso y mantiene el listón de calidad donde yo lo quiero.

El pragmático en mí solía abandonar TDD cuando los deadlines apretaban. El pragmático en mí con la configuración de IA adecuada lo mantiene funcionando.

Uso Claude para todo. Claude Code con Opus o Sonnet como programador agéntico: flujos de desarrollo completos, lectura del código, seguimiento de convenciones, ejecución de tests, creación de PRs. Claude app y Claude como coworker para la parte conversacional: brainstorming, discusiones de arquitectura, explicar código, redactar documentación. Para asistencia inline, los plugins que ya tengo en mi IDE son suficientes. Probé Copilot y Cursor, no son para mí. Claude cubre lo que necesito.

Diferentes modos para diferentes tareas. Un asistente agéntico siguiendo mis comandos de TDD es un flujo diferente a chatear sobre patrones de diseño. Ambos son útiles. Ninguno reemplaza al otro.

El mercado ahora mismo es intenso. Claude, Codex, Gemini y otros son jugadores fuertes con productos similares, y todos mejoran mes a mes. Los resultados son impresionantes y solo se aceleran. Esa es la belleza de la competencia: obliga a todos a mejorar o volverse irrelevantes, y el consumidor gana de cualquier forma. A día de hoy, Claude Code parece la opción más fuerte para cómo trabajo. Pero no tengo lealtad a una marca. Si Anthropic dejara de avanzar y un competidor fuera claramente mejor, cambiaría sin dudar. Lo que importa es la capacidad, no el logo.

Me equivoqué con la IA de la forma en que los idealistas se equivocan a menudo: medí la herramienta contra el resultado ideal y la encontré insuficiente, en lugar de medirla contra la alternativa realista.

La alternativa al desarrollo asistido por IA no es un equipo de arquitectos senior escribiendo código perfecto. Es el mismo equipo escribiendo el mismo código imperfecto, solo que más lento.

Los ingenieros que aprendan a liderar agentes en lugar de competir contra ellos tendrán una ventaja real. Y esto todavía es el principio.

La pregunta nunca fue “¿puede la IA escribir código perfecto?” Fue “¿puedo liderar a la IA para escribir mejor código, más rápido?” Y la respuesta, con la configuración adecuada, es sí.

El juego completo #

Cada práctica en este post sigue el mismo patrón. La versión ideal existe en los libros. La versión pragmática existe en tu código bajo presión. Necesitas ambas.

La próxima vez que estés subiendo ese fix a las 11 de la noche, sabrás qué atajos tomaste y por qué. Ese es el juego completo. No la perfección. No la velocidad. Saber cuál debe liderar.

Construye tu Propio Equipo de Agentes

2026-02-07T00:00:00+00:00

La mayoría usa asistentes de código con IA como un único interlocutor. Abres un chat, describes lo que necesitas y obtienes una respuesta. Funciona. Pero es como contratar a un generalista para que haga de todo. Ningún equipo real funciona así.

La verdadera ventaja viene cuando organizas la IA como un equipo: onboarding, procedimientos estándar, especialistas y ejecución en paralelo.

En el post sobre MCP cubrí cómo darle acceso a tu entorno. En La IA te da velocidad, no calidad, por qué el juicio humano sigue siendo esencial. Este post cubre la pieza que falta: organizar ese acceso en un flujo coordinado.

El documento de onboarding #

Todo buen equipo empieza con onboarding. Los agentes de IA necesitan lo mismo.

Reglas del proyecto #

En Claude Code, el archivo CLAUDE.md en la raíz de tu proyecto es el documento de onboarding. El agente lo lee cada vez que empieza a trabajar: estructura, convenciones, guías de estilo, herramientas.

Pero CLAUDE.md es solo el punto de entrada. Puedes dividir las reglas en archivos enfocados bajo .claude/rules/, cada uno apuntando a partes específicas de tu código mediante patrones glob. El agente no solo conoce tus convenciones, está limitado por ellas. Límites de capas, patrones de nomenclatura, dirección de dependencias. Todo versionado junto al código que protegen.

modules/*/Domain/**/*.php: Sin imports de framework, sin dependencias de infraestructura, solo PHP plano.
modules/*/Infrastructure/**/*.php: Los controladores se mantienen delgados, los modelos Eloquent en su sitio.
resources/js/**/*.tsx: Convenciones de componentes, estrictez TypeScript, patrones de estilos.

Cada archivo de reglas tiene un scope limitado a los archivos que le importan. Las reglas de dominio no se activan cuando se edita un controlador.

Preferencias personales #

También existe un ~/.claude/CLAUDE.md global que aplica en todos tus proyectos. El archivo del proyecto dice cómo funciona este código. El global dice cómo trabajo yo.

Un buen CLAUDE.md es como un buen documento de onboarding. Cuanto mejor sea, menos te repites.

Procedimientos operativos estándar #

Todos los equipos tienen flujos recurrentes que viven en wikis, runbooks, o en la cabeza de alguien. Cuando viven en la cabeza de alguien, son frágiles.

Los comandos slash personalizados en .claude/commands/ convierten estos flujos en instrucciones ejecutables. Cada comando es un archivo markdown que describe un procedimiento de varios pasos. En uno de mis proyectos, cada comando de creación empieza con tests. TDD incorporado al procedimiento, no dejado a la disciplina.

Creación (TDD-first):

/create-module: Genera un módulo hexagonal con capas de dominio, aplicación e infraestructura.
/create-entity: Entidades de dominio con value objects y archivos de test.
/create-use-case: Handlers de command/query con tests mockeados.
/create-page: Páginas React con factories y smoke tests.

Calidad y flujo de trabajo:

/refactor-check: Analiza código contra principios SOLID.
/test: Ejecuta la suite con filtrado por módulo.
/fix: Auto-aplica correcciones de linting y análisis estático.
/gh-issue: De issue de GitHub a implementación y PR en un solo comando.

Los comandos convierten conocimiento tribal en instrucciones ejecutables. Lo que antes era “pregúntale a Sara cómo creamos un módulo nuevo” se convierte en un comando que cualquiera puede ejecutar.

Especialistas, no generalistas #

Los comandos codifican cómo hace las cosas tu equipo. Pero hay otra capa: skills y agentes.

Skills como bases de conocimiento #

Los skills son conocimiento estructurado del que el agente se nutre. En uno de mis proyectos, tengo skills para principios SOLID, arquitectura hexagonal, flujos TDD y patrones React/Inertia.

Las reglas restringen: “no hagas esto, haz siempre aquello.” Los skills enseñan: “este es el patrón, estos son los errores comunes.” Las reglas son barandillas. Los skills son experiencia.

Agentes como roles especializados #

En lugar de un generalista, defines agentes especializados con un rol claro, herramientas específicas, e incluso un modelo diferente según la complejidad del trabajo. No necesitas a tu arquitecto más senior para renombrar una variable.

Explorer (modelo ligero): Solo lectura. Busca en el código, encuentra archivos, entiende la estructura.
Revisor de código limpio (modelo intermedio): Violaciones SOLID, code smells, inconsistencias de nomenclatura.
Coach de TDD (modelo intermedio): Guía el ciclo red-green-refactor. Edita archivos y ejecuta tests.
Revisor de React (modelo intermedio): Estructura de componentes, estrictez TypeScript, accesibilidad.
Arquitecto de dominio (modelo más capaz): Decisiones de arquitectura, límites de módulos, patrones DDD.

El modelo adecuado para el trabajo adecuado. Rápido y barato para exploración. Capaz y riguroso para arquitectura.

Hazlos trabajar juntos #

Aquí la metáfora del equipo se vuelve literal. Un solo agente es útil. Múltiples agentes desde un plan compartido es un equipo.

Subagentes vs equipos de agentes #

Hay dos modelos de coordinación distintos, y elegir el correcto importa.

Los subagentes se ejecutan dentro de una misma sesión. Hacen trabajo enfocado y devuelven resultados al agente principal. No pueden hablar entre sí. El agente principal lo gestiona todo.

Los equipos de agentes son diferentes. Cada miembro es una sesión de Claude Code independiente con su propia ventana de contexto. Se comunican a través de un buzón compartido, reclaman tareas de una lista compartida y se coordinan sin pasar por un cuello de botella central.

La arquitectura tiene cuatro componentes:

Team lead: la sesión principal que crea el equipo y orquesta el trabajo
Teammates: instancias separadas de Claude Code, cada una con tareas específicas
Lista de tareas: elementos de trabajo compartidos con seguimiento de dependencias. Las tareas bloqueadas se desbloquean automáticamente cuando sus dependencias se completan
Buzón: mensajería directa entre agentes, incluyendo broadcasts a todo el equipo

Los subagentes son trabajadores que reportan. Los equipos de agentes son colaboradores que piensan juntos.

Usa subagentes cuando solo importa el resultado. Usa equipos de agentes cuando los miembros necesitan compartir hallazgos, cuestionar al resto y coordinarse por su cuenta.

Empezando con equipos de agentes #

Los equipos de agentes son aún experimentales. Actívalos añadiendo esto a ~/.claude/settings.json:

{
 "env": {
 "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
 }
}

Crear un equipo es conversacional. Describes lo que quieres: “Crea un equipo de agentes para refactorizar el módulo de auth. Genera tres miembros: uno para cambios de API backend, uno para componentes frontend, uno para escribir tests.” Claude configura la lista de tareas, genera los miembros y coordina el trabajo.

Puedes ver el equipo en un mismo proceso (un terminal, navega con Shift+Up/Down) o dividido en paneles (cada miembro en una ventana tmux o iTerm2 separada). Usa Shift+Tab para activar el modo delegado, que restringe al lead a solo coordinación.

Advertencia sobre consumo de tokens. Los equipos de agentes queman tokens rápidamente. Cada miembro tiene su propia ventana de contexto, y cada mensaje entre agentes suma. Empieza con tareas de investigación y revisión antes de pasar a implementación. Tres miembros explorando en paralelo cuesta aproximadamente 3x. Asegúrate de que el paralelismo se paga a sí mismo.

Los miembros cargan automáticamente el contexto del proyecto (CLAUDE.md, servidores MCP, skills) pero no heredan el historial de conversación del lead. Al crear un miembro, sé específico sobre qué archivos revisar y qué restricciones aplican. Un prompt de creación vago produce trabajo vago.

Primero planificar, después ejecutar #

Describes el problema. El agente explora el código, mapea dependencias y propone un enfoque antes de cambiar nada. Lo apruebas, modificas o rechazas. Pensar primero, programar después.

Con equipos de agentes, la aprobación de plan permite exigir que los miembros diseñen su enfoque antes de implementar. El agente trabaja en modo solo lectura hasta que el lead aprueba. Puedes moldear el criterio del lead: “solo aprueba planes que incluyan cobertura de tests” o “rechaza planes que modifiquen el esquema de base de datos.”

El modo delegado restringe al lead a solo coordinación. Sin él, el lead a veces empieza a implementar en lugar de esperar a los miembros. El modo delegado lo mantiene centrado en la orquestación, no en la ejecución.

Hipótesis competitivas #

Cuando la causa raíz no está clara, un solo agente tiende a encontrar una explicación plausible y dejar de buscar. Los equipos de agentes combaten esto haciendo que los miembros sean adversarios. Cada uno investiga su propia teoría mientras intenta refutar las de los demás.

La investigación secuencial sufre de anclaje: una vez que se explora una teoría, todo lo posterior está sesgado hacia ella. Con múltiples investigadores cuestionándose mutuamente, la teoría que sobrevive tiene más probabilidades de ser la causa raíz real.

Dimensiona las tareas para trabajo en paralelo #

No todo el trabajo se beneficia del paralelismo. La pregunta clave: ¿pueden los miembros trabajar de forma independiente?

Demasiado pequeñas: el overhead de coordinación supera el beneficio
Demasiado grandes: los miembros trabajan demasiado tiempo sin revisión, aumentando el esfuerzo desperdiciado
El punto justo: unidades autocontenidas que producen un entregable claro. Una función, un archivo de tests, una revisión

Tener 5-6 tareas por miembro mantiene a todos productivos. Que cada miembro sea dueño de archivos diferentes. Sin aislamiento, dos editando el mismo archivo lleva a sobreescrituras. Los worktrees cambian esto.

Imagina una funcionalidad que toca backend y frontend. Después de planificar:

Un agente de backend genera la capa de dominio: entidades, value objects, interfaces de repositorio, handlers. Todo hexagonal, todo test-first.
Un agente de frontend construye la página React, componentes, hooks y factories. Cada uno sigue sus propias reglas y opera de forma independiente.

No se pisan porque el plan ya definió los límites. Propiedad clara. Sin conflictos de merge. Sin esperas.

Aislamiento con worktrees #

La mayor fricción con agentes en paralelo eran los conflictos de archivos. Dos agentes editando el mismo archivo significaba sobreescrituras y trabajo perdido. Los git worktrees eliminan esto dándole a cada agente su propia copia de trabajo del repositorio.

Inicia Claude Code con --worktree para ejecutarlo en un worktree aislado. Múltiples sesiones, mismo repositorio, sin pisarse. Añade --tmux para lanzarlo en su propia sesión tmux.

claude --worktree --tmux

Los subagentes también soportan worktrees. Pídele a Claude que use worktrees para sus agentes, o añade isolation: worktree en el frontmatter de tu agente personalizado para que sea el comportamiento por defecto.

---
isolation: worktree
---

La app de escritorio tiene la misma funcionalidad: activa el modo worktree en la pestaña Code.

Para control de versiones no-git (Mercurial, Perforce, SVN), puedes definir worktree hooks para obtener los mismos beneficios de aislamiento sin necesidad de usar git.

Los worktrees convierten “propiedad clara de archivos” de una restricción de planificación en una garantía de infraestructura. Los agentes pueden solaparse en los mismos archivos sin pisarse.

Revisión tras la ejecución #

Tras la implementación, los agentes de revisión toman el relevo. En lugar de un revisor que lo pille todo, tienes especialistas: violaciones SOLID, patrones de componentes, calidad de tests, límites de módulos.

Un solo agente es un asistente. Múltiples agentes trabajando desde un plan compartido es un equipo.

Tú sigues siendo el lead #

Por muy bien configurados que estén, los agentes trabajan para ti. Tú estableces los estándares, escribes las reglas, revisas los planes y apruebas el resultado antes de que salga. Puedes enviar un mensaje a cualquier miembro mientras trabaja para redirigir su enfoque o añadir restricciones. Si alguien va por mal camino, intervienes directamente.

Como escribí en La IA te da velocidad, no calidad, el código que produce el agente es tu responsabilidad. Más paralelismo sin supervisión es solo más caos, más rápido.

Puertas de calidad #

Los hooks y git hooks actúan como la última red de seguridad. En mi setup, nada se commitea a menos que los linters pasen, el análisis estático esté limpio, los tests sean verdes y la cobertura supere el 90%. El agente no puede saltarse esto. Nadie puede.

Los equipos de agentes añaden sus propios hooks: TeammateIdle mantiene activos a los miembros inactivos, TaskCompleted impide completar tareas prematuramente. Políticas automatizadas que nadie puede saltarse.

Los git hooks ejecutan linters, análisis estático y tests antes de cada commit. Claude Code añade sus propios hooks (.claude/hooks/): comandos shell que se disparan ante eventos del agente como llamadas a herramientas o escritura de archivos.

.claude/settings.json controla lo que los agentes pueden ejecutar. Autoriza herramientas y comandos específicos, deniega operaciones destructivas. Controlas no solo lo que los agentes saben (reglas, skills) sino lo que pueden hacer (permisos). Las reglas definen la cultura. Los permisos definen los límites.

La base importa #

Los agentes te ayudan a llegar más rápido, pero ese “allí” tiene que estar bien definido. Si no sabes cómo es la arquitectura hexagonal, los agentes no la van a descubrir por ti.

No construyes todo esto el primer día. Empiezas con un CLAUDE.md. Luego notas que repites instrucciones, y escribes un comando. Un agente rompe una convención, y añades una regla. El setup crece orgánicamente a partir de fricción real. Cada adición resuelve un problema que realmente tuviste. Lo mismo con los equipos de agentes: empieza con tareas que no requieran escribir código. Revisa un PR, investiga una librería, analiza un bug. Aprende el modelo de coordinación antes de implementar en paralelo.

Si quieres un punto de partida, preparé laravel-claude-toolkit: un starter kit de Laravel con reglas, comandos, skills, agentes, hooks y permisos ya configurados.

No solo estás usando IA. Estás construyendo un equipo. Y como cualquier equipo, la calidad de su resultado refleja la calidad de su liderazgo.

Recursos #

Claude Code | claude.com
Claude Code: Agent Teams | claude.com
Claude Code Tips: Workflow Boosters | rfrolov.me

La IA te Da Velocidad, No Calidad

2025-10-10T00:00:00+00:00

He estado usando asistentes de codificación IA extensivamente: ChatGPT, Codex, Claude con Sonnet y Opus. Son increíblemente útiles. Te dan velocidad como nada más.

Pero la velocidad no es calidad.

La trampa del vibe-coding #

Los modelos de IA son excelentes imitando su entorno. Dales contexto, y harán lo que sea necesario para completar la tarea. Esto se ha conocido como “vibe-coding”: describes lo que quieres, y la IA produce algo que funciona. Rápido.

¿El problema? La IA felizmente generará código desordenado si eso es lo que hace el trabajo. No le importa la mantenibilidad. No piensa en qué pasa cuando los requisitos cambien el próximo mes. Solo produce output.

La IA es un espejo que refleja el contexto que le das. Si tu codebase está desordenado, generará más desorden. Si tus prompts son vagos, hará suposiciones.

Sin guía cuidadosa, terminas con parches sobre parches. Código legacy recién creado. Una codebase donde cada cambio se siente arriesgado y el equipo pasa más tiempo luchando contra el código que construyendo features.

El arte de preguntar #

¿Recuerdas Stack Overflow? ¿Las búsquedas en Google que te llevaban a hilos de foros de 2011 donde alguien tenía exactamente el mismo problema?

Hace diez años, ser desarrollador significaba aprender a hacer buenas preguntas. Elaborabas tu post de Stack Overflow cuidadosamente: describe el problema, muestra lo que intentaste, explica lo que esperabas versus lo que pasó. Si tu pregunta era vaga o perezosa, la comunidad te lo hacía saber. A veces duramente.

Pero esa fricción nos enseñó algo valioso: la calidad de tu respuesta depende de la calidad de tu pregunta.

El mismo principio aplica a la IA. Un prompt vago obtiene una respuesta vaga. Un prompt bien estructurado con contexto claro, restricciones y ejemplos obtiene algo útil. La habilidad de formular buenas preguntas no se volvió obsoleta. Se volvió más importante.

Aprender a hacer prompts a la IA efectivamente es el equivalente moderno de aprender a buscar en Google y preguntar en Stack Overflow. Los desarrolladores que dominen esto obtendrán mejores resultados.

Incluso cuando la IA te da una respuesta rápida e impresionante, nunca aceptes código que no entiendas completamente. Es tentador. La respuesta aparece en segundos, se ve profesional, incluso podría funcionar. Pero si no puedes explicar qué hace y por qué, estás plantando una bomba de tiempo en tu codebase. Y cuando explote a las 2am, estarás debuggeando código que no escribiste sin modelo mental de por qué existe.

Cuestiona el resultado. Pregunta: “¿Puedes simplificar esto?” o “¿Hay código repetitivo aquí que podamos eliminar?” La IA por defecto añade, no mejora. Generará abstracciones, funciones auxiliares y patrones que no pediste. No refactorizará a menos que se lo digas. Cuestiónala.

Esto es especialmente crítico con los tests. Pide a la IA que genere tests y a menudo obtendrás tests que reflejan detalles de implementación en lugar de comportamiento. Se romperán en el momento que refactorices, incluso si la lógica permanece igual. Si quieres tests que verifiquen comportamiento, necesitas decirlo explícitamente. La IA no hará esa elección por ti.

No te dejes seducir por la velocidad. A veces, una respuesta rápida que no entiendes es peor que una respuesta lenta que sí entiendes.

El factor humano #

La IA puede escribir código rápido, pero no puede entender la arquitectura general. No sabe por qué ciertas decisiones se tomaron hace meses. No puede ver el panorama general de hacia dónde va el producto. Solo ve lo que le muestras, tomando decisiones locales sin entender las implicaciones globales. Ese es nuestro trabajo.

Como exploré en diferentes creencias sobre la calidad del software, los equipos a menudo tienen estándares variables sobre qué significa “suficientemente bueno”. Cuando añades IA a la mezcla, mantener ese entendimiento compartido se vuelve aún más crítico. La IA no comparte los valores de tu equipo. Solo genera código.

La disciplina para mantener arquitectura limpia, para decir “no” a hacks rápidos, para refactorizar antes de que las cosas empeoren. Eso es únicamente humano.

Libros como Clean Code y Clean Architecture no son menos relevantes en la era de la IA. Son más relevantes. Te ayudan a detectar cuando la IA va en la dirección equivocada.

Colaboración sobre automatización #

Hay algo más que la IA no puede reemplazar: el equipo.

Una conversación con un colega sobre “¿deberíamos extraer esto en un servicio?” a menudo lleva a insights que ningún prompt de IA sacaría a la luz. Ese ida y vuelta, el cuestionar, el “¿qué si intentamos esto en su lugar?”. Ahí es donde ocurre el entendimiento real.

Extreme Programming Explained enfatiza prácticas como pair programming y propiedad colectiva del código por buenas razones. Estas no son ineficiencias para automatizar. Son cómo los equipos construyen calidad en su proceso.

Cuando saltas la discusión humana y solo dejas que la IA genere soluciones, pierdes la oportunidad de aprender, de desafiar suposiciones y de crecer como equipo.

Tú eres dueño del código #

Cuando la IA escribe código y tú lo commiteas, lo revisas, lo apruebas, lo mergeas y lo deployeas, es tu código. No puedes culpar a la IA cuando algo se rompe en producción. No puedes señalar a Claude o Copilot cuando la arquitectura se vuelve imposible de mantener.

Como escribí sobre el arte del testing, la calidad es una elección que hacemos en cada paso. Cada commit es una decisión. Cada revisión es una oportunidad de detectar problemas. Cada merge es un respaldo de la calidad del código.

Somos la última parte responsable del código que la IA escribe. El commit, la revisión, la aprobación, el merge, el deploy. Todo eso somos nosotros.

Moverse rápido en la dirección equivocada solo te lleva a perderte más rápido. Las líneas de código apareciendo en pantalla no es progreso. El valor que aportamos como desarrolladores no es la velocidad tecleando. Nuestro valor está en entender hacia dónde vamos, mantener disciplina sobre el caos, y asegurar que el código que entregamos hoy no se convierta en la pesadilla de mañana.

Usa la IA. Abraza la velocidad. Pero nunca olvides: tú eres quien conduce. Si sueltas el volante, terminarás en una pila de código imposible de mantener más rápido de lo que esperabas.

Y cuando eso pase, no hay nadie más a quien culpar.

Lo que el Éxito Significa para Mí

2025-09-15T00:00:00+00:00

Durante mucho tiempo, pensé que el éxito se trataba de alcanzar ciertos hitos. Conseguir esa promoción. Ganar un salario específico. Construir algo que la gente reconociera.

Pero me he dado cuenta de que eso no es lo que me hace levantarme por las mañanas.

La verdadera medida #

El éxito, para mí, ahora es directo: despertar sabiendo que lo que hago hace más felices a las personas a mi alrededor, y a mí mismo.

Me costó llegar a esto. Puede que esta definición no le parezca simple a todo el mundo, y está bien. Pero para mí, lo clarificó todo.

Sin fórmula complicada. Sin lista de logros.

El éxito son esos pequeños momentos: ayudar a un colega con un problema complicado, compartir algo que hace sonreír a alguien, terminar el día sintiendo que aportaste algo bueno al mundo.

Aplica tanto si lideras un equipo como si simplemente eres tú mismo. Como escribí sobre gran liderazgo, el verdadero liderazgo empieza con tu propia vida y comportamiento. Se trata de hacer mejores a quienes te rodean, no solo de alcanzar objetivos.

Por qué importa la felicidad #

Antes pensaba que enfocarse en la felicidad era algo trivial. Como si no fuera un objetivo “serio”. Pero he aprendido que hacer feliz a la gente de verdad es una de las cosas más difíciles y gratificantes que puedes hacer.

¿Qué significa esto en la práctica? #

Estar presente cuando alguien te necesita
Crear cosas que resuelvan problemas reales
Elegir la amabilidad sobre tener razón
Encontrar alegría en lo que haces, incluso en días difíciles

Cuando te enfocas en hacer felices a otros, sueles acabar más feliz tú también. No es un juego de suma cero. Se multiplica.

Conecta mucho con entender a las personas y cómo piensan. Cuando entiendes que cada uno procesa el mundo de forma diferente, te vuelves mejor creando felicidad genuina. No la que tú crees que debería hacerles felices.

La práctica diaria #

¿Cómo se ve esto en la vida diaria? #

Para mí, es preguntarme con frecuencia: “¿Lo que hice hoy mejoró las cosas?” No perfecto. No revolucionario. Solo mejor.

A veces es escribir código que ayuda a un equipo a trabajar mejor. A veces es tomarse tiempo para escuchar de verdad a alguien. A veces es simplemente tener paciencia cuando todo parece un caos.

No siempre es fácil. Algunos días fallas. Pero tener esta definición simple de éxito aclara las decisiones. Cuando dudas si aceptar un proyecto, una oportunidad, o decir que no a algo, puedes preguntarte: “¿Esto nos hará más felices a mí y a quienes me rodean?”

Consistencia sobre perfeccionismo #

Aquí hay algo que he aprendido por las malas: el éxito se construye a través de la consistencia, no la perfección.

El perfeccionismo te paraliza. Te susurra que nada es suficientemente bueno, que deberías esperar a que las condiciones sean ideales, que un error lo invalida todo. Es una trampa.

¿Qué funciona de verdad? Aparecer. Día tras día. Construir pequeños hábitos que se acumulan con el tiempo.

Como explica James Clear en Hábitos atómicos, el cambio real viene del efecto acumulado de cientos de pequeñas decisiones. No necesitas ser perfecto. Necesitas ser constante.

No intentes hacer un hábito perfecto, solo repítelo.

Eso significa:

Escribir unas líneas de código cada día supera esperar la arquitectura perfecta
Una conversación corta y genuina supera esperar el momento perfecto
Pequeñas mejoras constantes superan esperar el gran avance

El objetivo no es no fallar nunca. Es construir hábitos que te hagan más feliz a ti y a otros, y seguir apareciendo incluso cuando tropiezas.

Aquí es donde el proceso mismo se convierte en el objetivo. No se trata de llegar a un destino final de “ser exitoso”. Se trata de construir hábitos diarios que se alineen con lo que realmente te importa.

El éxito es personal #

Tu definición de éxito probablemente sea diferente a la mía. Y eso no solo está bien, es necesario.

“¿Siempre he sido así?” No. Claro que no. Lo que nos importa evoluciona mientras crecemos. Eso es parte del viaje.

Si te sientes atascado o no sabes hacia qué trabajas, prueba esto: descubre qué te hace feliz de verdad a ti y a quienes te importan. No lo que crees que debería hacerte feliz. No lo que queda bien de cara a los demás.

Solo lo que realmente funciona para ti.

Y prepárate para abrazar el cambio cuando tu definición cambie. Porque cambiará. Lo que el éxito significa hoy puede ser distinto mañana. Eso no es fracaso. Es crecimiento.

Al final del día, si despiertas sabiendo que lo que haces trae más felicidad al mundo (incluida la tuya), probablemente estás haciendo algo bien.

Eso se siente como éxito para mí.

Gracias a mi amigo Toni, por plantear esta pregunta e inspirar esta reflexión.

El hombre en busca de sentido

2024-11-29T00:00:00+00:00

Frankl comparte sus desgarradoras experiencias del Holocausto y presenta una filosofía profunda sobre la condición humana. Un testimonio de la resiliencia del espíritu humano: incluso en los momentos más oscuros, uno puede encontrar propósito y sentido.

Su visión sobre la psicología de la supervivencia y el desarrollo de la logoterapia nos dan una perspectiva única para mirar nuestras propias vidas. Al adentrarnos en su narrativa, reflexionamos sobre nuestra propia búsqueda de sentido y cómo encontrar propósito entre las pruebas que nos pone la vida.

Parte 1: Experiencias en un campo de concentración #

Frankl, psiquiatra austriaco, relata sus experiencias en campos de concentración nazis como Auschwitz y Dachau durante la Segunda Guerra Mundial.

Describe las etapas psicológicas de los prisioneros: shock al llegar, apatía (se volvían emocionalmente insensibles para sobrevivir) y finalmente desilusión o amargura si eran liberados.

Frankl subraya que incluso en las condiciones más horribles, encontrar un propósito da fuerza para sobrevivir. Quienes tenían algo por lo que vivir (un ser querido, un proyecto personal) resistían mejor.

Parte 2: La logoterapia en pocas palabras #

Aquí Frankl presenta su método psicoterapéutico, desarrollado a partir de sus experiencias. La logoterapia se centra en el sentido de la existencia humana y la búsqueda de ese sentido.

A diferencia de la “voluntad de placer” de Freud o la “voluntad de poder” de Adler, Frankl propone la “voluntad de sentido” como la fuerza motivacional primaria del ser humano.

Tres caminos hacia el sentido:

Logro: hacer una obra o crear algo.
Experiencia: vivir algo o encontrar a alguien (amor).
Actitud: la postura que tomamos ante el sufrimiento inevitable.

Incluso en situaciones extremas, uno puede elegir su actitud. Y esa elección puede ser una fuente poderosa de sentido.

Frankl también habla del vacío existencial: la falta de sentido en la sociedad moderna, que lleva a problemas psicológicos. La logoterapia busca guiar a cada persona a encontrar su propio sentido.

Puntos clave #

Sentido de la vida #

Frankl sostiene que no hay un sentido universal de la vida. El sentido es único para cada persona y puede cambiar con el tiempo.

Sufrimiento y sentido #

El sufrimiento no tiene por qué carecer de sentido. Puede ser un camino para encontrarlo o reafirmarlo.

Responsabilidad #

Cada uno tiene la responsabilidad de encontrar su propio sentido, lo que implica también la libertad de elegir su camino.

El libro de Frankl no es solo unas memorias, sino un testimonio de la resiliencia humana y del poder del espíritu para trascender las peores circunstancias a través del descubrimiento del sentido.

Citas #

“En última instancia, el hombre no debería preguntar cuál es el sentido de su vida, sino reconocer que es él quien está siendo cuestionado.”

“Teníamos que dejar de preguntar por el sentido de la vida y pensar en nosotros mismos como quienes estaban siendo cuestionados por la vida, diaria y constantemente.”

“Todo puede arrebatársele a un hombre excepto una cosa: la última de las libertades humanas, elegir la actitud ante cualquier circunstancia, elegir el propio camino.”

“La libertad no es la última palabra. Es solo parte de la historia y la mitad de la verdad. La libertad es el aspecto negativo del fenómeno completo; el aspecto positivo es la responsabilidad.”

Notas personales #

Lo que más me gusta del libro es cómo presenta la vida como un cambio continuo de perspectivas, tanto desde dentro como en relación con el mundo. Es como ajustar el zoom de una cámara según el contexto, reconociendo que somos a la vez individuos y parte de algo más grande.

Este enfoque ayuda a ganar perspectiva: ser consciente de tus limitaciones y de tu importancia en cada situación. Al final, la vida no tiene un sentido inherente. Es el sentido que elegimos darle lo que da forma a nuestra existencia.

Resumen animado del libro #

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 proyecto Fénix

2024-05-31T00:00:00+00:00

Una historia sobre un proyecto imposible donde todos juegan a la política, arreglan bugs críticos sin parar y desperdician esfuerzos en parches rápidos en vez de ayudar al negocio a prosperar.

Si IT falla, el negocio falla.

Principios DevOps: Flujo, Feedback, Aprendizaje Continuo y Experimentación. Estos conceptos impulsan mejoras en capacidad de respuesta, fiabilidad y trabajo en equipo.

Resumen #

El libro empieza con la promoción de Bill a VP de IT y la responsabilidad de entregar un proyecto imposible (Phoenix). El CEO le advierte: si no se entrega a tiempo, externalizarán todo IT y despedirán a todos.

Bill intenta entender la situación y descubre que todos apagan fuegos sin parar, con demasiadas responsabilidades y poco personal. Todo es urgente, todo para ayer. La fecha límite viene de arriba, sin planificación ni conversaciones con otros departamentos. En resumen: caos corporativo, política y reuniones infernales.

Bill conoce a alguien en la empresa que le ayuda a mejorar las cosas. No le dice qué hacer, sino que le hace preguntas para que encuentre la solución por sí mismo.

Por ejemplo, la primera pregunta: “¿Cuáles son los cuatro tipos de trabajo en IT?” La respuesta no llega de golpe, sino a lo largo de la historia:

Proyectos de negocio: afectan directamente los objetivos del negocio. Generan ingresos y dan valor a los clientes.
Proyectos internos: tareas regulares que mantienen el sistema funcionando (actualizaciones, parches de seguridad…). Suelen ser invisibles y pueden convertirse en cuello de botella.
Cambios: resultado de los proyectos anteriores. Hay que saber qué cambiar y dentro de qué.
Trabajo no planificado: el verdadero asesino de la productividad. Son todos los problemas operacionales que surgen de los otros tres tipos de trabajo.

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

Despliegues los Viernes

2024-02-25T00:00:00+00:00

He escuchado múltiples veces, de varias personas, la idea de pánico hacia desplegar los viernes. ¿Qué tan buena es esa idea de prohibir el día antes del fin de semana entregar nuevo valor a nuestros clientes?

El argumento principal a favor de NO desplegar el viernes se basa en la idea de que “deberíamos ser paranoicos” con nuestro software y que podría fallar cuando lo tocamos. Entonces, “deberíamos asumir” lo peor cada vez que desplegamos una nueva versión de nuestro sistema.

Sin embargo, el factor crítico aquí es ¿Por qué? ¿Por qué no deberíamos desplegar los viernes? ¿Está bien tener miedo de nuestro propio sistema de software, que vivimos en un pánico constante de romperlo el día después de haber hecho un despliegue? ¿Cuánto impacto deberían tener nuestras releases? ¿Cómo podemos asegurar que el despliegue no romperá el sistema en vivo?

Tus pipelines de Integración Continua/Entrega Continua, pruebas end-to-end y otros tipos de tests implementados, políticas de escalado automático, un sandbox de staging previo para realizar incluso pruebas manuales si es necesario, etc., determinarán la seguridad y confianza para cualquiera de tus releases. Sin embargo, la calidad de estos temas es un factor decisivo para tener suficiente confianza sobre cómo, cuándo y por qué tendría sentido hacer release a producción.

El objetivo es construir un sistema donde los despliegues a producción sean tan frecuentes, suaves y fáciles como sea posible; en cualquier momento, cualquier día. Tener miedo de tu sistema no debería ser el objetivo. Por el contrario, debería ser algo hacia lo que trabajar para solucionarlo.

Las dinámicas del equipo también son un factor esencial aquí. Si establecemos miedo a los despliegues los viernes, y miedo a nuestro sistema, eso terminará en falta de responsabilidad por defecto. Esto me recuerda a The Five Dysfunctions of a Team.

Si despliegas cambios pequeños y frecuentes tan pronto como pueden garantizar 100% de calidad y éxito de valor, ¿por qué retrasar tal mejora incremental a tu sistema?

Volviendo a “¿Por qué no deberíamos desplegar los viernes?” La única razón que se me ocurre es tener miedo de que tengamos que trabajar el sábado en la cosa rota que entregamos el viernes. Sin embargo, me pregunto si había alguna opción disponible, para que pudiéramos haber identificado tal cosa rota durante el propio viernes laborable.

Monitorear tu sistema en vivo es crucial para garantizar la salud después de cada despliegue. Esto es esencial para asegurar que todo funciona bien y sin problemas. Para construir un sistema resistente, esto debería activar alarmas para notificar a alguien responsable de abordar el problema, deshabilitar o revertir la última característica “rota”… hay muchas técnicas para crear conciencia y actuar sobre ellas.

En caso de duda, podrías usar feature flags para deshabilitar la característica que desplegarás. Aún así, prefieres no habilitarla durante el fin de semana mientras mantienes la opción de agregar valor y desplegar en cualquier momento siempre abierta.

Creo que las releases frecuentes y pequeñas a producción son clave; en cualquier momento, cualquier fecha, mientras tenga sentido, y haya un camino claro para traer valor pronto al cliente para obtener retroalimentación lo antes posible.

Entrega valor de calidad en pequeños incrementos, tan frecuentemente como sea posible.

Poder desplegar los viernes (si es necesario o deseado) impacta la confianza del equipo. De manera similar, prohibir los despliegues los viernes impacta la autoestima del equipo también.

El método Lean Startup

2024-01-26T00:00:00+00:00

La mayoría de las startups fracasan, pero muchos de esos fracasos se pueden evitar. El método Lean Startup es un enfoque que está cambiando cómo se crean empresas y se lanzan productos en todo el mundo.

Eric Ries define una startup como una organización que crea algo nuevo bajo condiciones de extrema incertidumbre. Da igual si es una persona en un garaje o un grupo de profesionales en una sala de juntas de una empresa Fortune 500. Lo que comparten es la misión de atravesar esa niebla de incertidumbre para encontrar un camino hacia un negocio sostenible.

Puntos Clave #

Prueba a menudo y aprende rápido
Observa y mide el comportamiento real del cliente
Enfócate solo en métricas accionables
Aprende a pivotar según lo que descubras
Adopta nuevos métodos de contabilidad
Detecta qué no funciona y cambia de inmediato: mantente lean

Resumen #

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

El Principio de Peter

2023-09-30T00:00:00+00:00

Cuando alguien es competente en su trabajo, lo ascienden a un puesto que requiere otras habilidades. Si no las tiene, será incompetente y no lo ascenderán más.

Si es competente en el nuevo rol, lo ascenderán otra vez. Y seguirá subiendo hasta alcanzar un nivel donde sea incompetente. Ahí se quedará atascado: la “meseta de Peter”.

Hay incentivos en juego. La gente trabaja duro para alcanzar cierta posición o salario. Una vez que lo logra, algunos se relajan. Cuando pierden la pasión, dejan de aprender. No se mantienen al día con los nuevos desarrollos y su trabajo empeora. Para proteger su zona de confort, rechazan cualquier idea o persona nueva que pueda incomodarlos. Los empleados incompetentes suelen estar insatisfechos.

¿Has vivido el Principio de Peter? #

Lo he visto varias veces en mis 10 años de carrera, trabajando en diferentes empresas, con personas de distintos departamentos y niveles. Es más peligroso de lo que parece porque puede matar el espíritu de un ambiente sano.

Ser consciente de esto te ayuda a evitar que te pase. O al menos a detectar las señales cuando empiece a ocurrirte.

¿Qué puedes hacer? #

Si reconoces esta situación en tu empresa, ayuda a crear conciencia. Hablad entre vosotros. Si sientes que no puedes, eso es síntoma de un ambiente de trabajo no saludable, y eso es un problema mayor.

Si eres tú quien lo está viviendo en primera persona, te recomiendo:

Habla con tu manager. Pide formación, mentoría o lo que necesites para adquirir las habilidades que te faltan: confianza, comunicación, o lo que ayude a tu nuevo rol. Quizás no recibiste la formación adecuada para un trabajo que requiere habilidades diferentes.
Considera volver a donde eras bueno y seguir dominando eso. Ayuda e inspira a quienes están a tu lado. No todo el mundo tiene que ascender siempre.

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.

La Guerra del Tamaño de Bloque

2023-06-20T00:00:00+00:00

Este libro cuenta la guerra del tamaño de bloque de Bitcoin, que duró desde agosto de 2015 hasta noviembre de 2017. En apariencia, la batalla giraba en torno a cuántos datos podía contener cada bloque. Pero el conflicto destapó algo más profundo: quién controla las reglas del protocolo de Bitcoin.

El autor explora a los personajes principales del conflicto. Ofrece cobertura desde las trincheras y también tras bastidores, durante las fases más intensas de la lucha.

El relato incluye conversaciones con actores clave de ambos bandos. Descubrimos sus motivaciones, estrategias y formas de pensar mientras la agotadora campaña avanzaba.

Capítulos #

Primer golpe
Marcha hacia la guerra
Scaling I - Montreal
Scaling II - Hong Kong
SegWit
Lightning network
Bitcoin Classic
Mesa redonda de Hong Kong
Faketoshi
The DAO
Scaling III - Milán
Bitcoin unlimited
Exchanges
ASICBoost
Dragons’s Den
Litecoin
User - Activated softfork
Acuerdo de Nueva York
Bitcoin Cash
SegWit2x
Victoria

Resumen #

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 #

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.

Lo esencial de Drucker

2022-10-29T00:00:00+00:00

Una selección de veintiséis textos sobre gestión organizacional, el individuo y la sociedad.

El libro cubre los principios básicos de la gestión junto con sus problemas, desafíos y oportunidades. Ofrece a managers, ejecutivos y profesionales las herramientas necesarias para afrontar lo que la economía y la sociedad del mañana les exigirán.

4 Principios Esenciales de la Gestión #

La gestión trata sobre humanos
La gestión debe definir los valores, objetivos, metas y misión de una organización
La gestión debe permitir que la organización y sus miembros crezcan y se desarrollen
Los resultados solo existen fuera de la organización

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.

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.

La Estrella de Mar y la Araña

2022-07-19T00:00:00+00:00

Si cortas la cabeza a una araña, muere. Si cortas una pata a una estrella de mar, le crece otra y esa pata puede convertirse en una estrella nueva. Las organizaciones jerárquicas tradicionales son como arañas. Las organizaciones descentralizadas son como estrellas de mar, y están cambiando los negocios y el mundo.

¿Qué hay detrás del éxito de Wikipedia, Craigslist y Skype? ¿Qué tienen en común eBay y General Electric con los movimientos abolicionistas y de derechos de la mujer? ¿Qué decisión puso a General Motors y Toyota en caminos tan diferentes?

Ori Brafman y Rod Beckstrom ofrecen respuestas sorprendentes, historias fascinantes y conexiones inesperadas. El libro explora qué pasa cuando las estrellas de mar se enfrentan a las arañas. Muestra cómo empresas e instituciones (IBM, Intuit, el gobierno de EE.UU.) están adoptando principios de estrella de mar para tener éxito.

Rod Beckstrom resume las ideas principales del libro en esta charla:

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 #

Red Work vs Blue Work

2021-10-21T00:00:00+00:00

“Blue Work” y “Red Work” son conceptos que David Marquet describe en su libro Leadership is Language. Ambos requieren mentalidades diferentes y tienen lenguajes distintos.

“Hacer” en nuestro estilo de liderazgo tradicional no nos llevará a donde necesitamos estar en el futuro.

¿Qué es “Red Work”? #

Red Work trata de hacer y reducir la variabilidad. Se enfoca en demostrar y en el rendimiento.

En Red Work, buscas completar una tarea sin tener que decidir mucho sobre el qué o el cómo. Es estar en control y tomar el control:

Procesar trabajo y evitar errores.
Tener previsibilidad y controlabilidad.

Hace falta un mecanismo para parar el Red Work y preguntar: ¿estamos haciendo lo correcto?

¿Qué es “Blue Work”? #

Blue Work trata de decidir, pensar, planificar. Se enfoca en mejorar con una mentalidad humilde.

El lugar correcto para hacer Blue Work es al principio y al final de un punto de decisión.

Blue Work es crucial para empezar bien. Nos permite decidir la mejor manera de hacer algo con la información que tenemos ahora mismo.

Conviene establecer iteraciones cortas entre las diferentes actividades que queremos completar. Así tenemos “tiempo de Blue Work” para reflexionar. Es perfecto para hacer retrospectivas y ver qué podemos mejorar.

Es el momento de parar, “controlar el reloj”, colaborar y comprometerse para la siguiente iteración. Blue Work también incluye:

Trabajo de pensamiento.
Toma de decisiones.
Buscar alcanzar la excelencia.
Lograr que más personas piensen de forma independiente.
Abrazar la variabilidad y buscar diferentes aportes.

Blue Work aislado es inútil. Su función es hacer mejor el Red Work. Blue Work interminable, planificar sin resultados, no trae beneficios reales.

En nuestra industria del software no hay lugar para la vieja escuela de “Red-Workers” y “Blue-Workers”. Hay “Red Work” y “Blue Work”, y todos debemos participar en ambos.

Por eso todos debemos ser conscientes de estos tipos de trabajo y encontrar un buen equilibrio. Los buenos líderes involucran a todos en Red Work y Blue Work.

Referencias #

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.

El señor de las moscas

2021-07-10T00:00:00+00:00

Un clásico que mezcla parábola, alegoría, mito, cuento moral y hasta parodia política.

Un grupo de niños británicos acaba varado en una isla desierta. Su intento de gobernarse a sí mismos termina en desastre.

El libro explora la tensión entre lo grupal y lo individual, entre la razón y la emoción, entre lo moral y lo inmoral.

Los primeros capítulos van lentos, pero construyen el contexto necesario. Después la historia escala rápido.

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

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 ;)

Abraza el Cambio

2021-03-01T00:00:00+00:00

El libro ¿Quién se ha llevado mi queso? presenta un cuento dentro de la historia principal que consiste en 4 personajes: dos ratones, Sniff y Scurry, y dos pequeñas personas, Hem y Haw.

Se publicó en 1998 y lo leí a principios de 2021. Mejor tarde que nunca. Mi hermano Jesús me lo recomendó.

Viven en un Laberinto (que representa nuestro entorno) y para sobrevivir necesitan salir de su zona de confort y buscar queso (que representa la felicidad y el éxito).

El cuento empieza cuando ambos grupos llegan a la “Estación de Queso C”, llena de queso. Los humanos establecen rutinas; los ratones mantienen sus instintos activos.

Un día los ratones llegan y no queda queso. Salen a buscar más en otro lugar. Hem y Haw, en cambio, se quejan. Hem, enfadado, exige “¿Quién se ha llevado mi queso?!”. Ambos contaban con que el queso sería eterno, así que no estaban preparados. La diferencia clave es cómo reaccionan.

Hem se niega a marcharse de la “Estación de Queso C”. Sigue yendo cada día esperando encontrar queso, cada vez más débil y con miedo de hacer algo diferente. Haw, en cambio, decide reírse de la situación, vence su miedo y sale a buscar más queso.

… Te dejo el resto del cuento para ti.

El cuento es una metáfora de las diferentes actitudes que adoptamos cuando tenemos que enfrentar cambios.

Notar pequeños cambios temprano te ayuda a adaptarte a los cambios más grandes que están por venir.

El libro está lleno de lecciones aplicables a cualquiera, sin importar quién seas o cuándo lo leas. Lo recomiendo.

Mis lecciones favoritas del libro #

El cambio sucede. Siguen moviendo el queso.
Anticipa el cambio. Prepárate para que muevan el queso.
Monitorea el cambio. Huele el queso a menudo para saber cuándo se está poniendo viejo.
Adáptate al cambio rápidamente. Cuanto más rápido sueltes el queso viejo, antes podrás disfrutar del nuevo queso.
Cambia. Muévete con el queso.
Disfruta el cambio. Disfruta el sabor del nuevo queso.
Prepárate para cambiar rápidamente y disfrutarlo de nuevo. Siguen moviendo el queso.

“Todos saben que no todo cambio es bueno o necesario. Pero en un mundo en constante cambio, nos conviene aprender a adaptarnos y disfrutar de algo mejor. No es lo que dice la historia de ‘¿Quién se ha llevado mi queso?’, sino cómo la interpretas y aplicas a tu situación lo que le da valor.” - Ken Blanchard.

“La vida sigue adelante y nosotros también deberíamos” - Spencer Johnson

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 #

Gestión de Alto Rendimiento

2020-04-03T00:00:00+00:00

Un clásico de Silicon Valley. El ex presidente y CEO de Intel comparte su perspectiva sobre cómo construir y dirigir una empresa. Es un manual práctico para navegar escenarios de negocios reales y un manifiesto de gestión que puede cambiar tu forma de trabajar.

Secciones #

Apalancamiento gerencial
Formación
Motivación
Reuniones y decisiones
Reuniones uno a uno
Delegación y madurez relevante para la tarea
KPIs
Evaluaciones de desempeño
Entrevistas
Promociones y reciclaje

Un buen resumen de las conclusiones por Marc Koenig:

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.

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 Arte de la Guerra

2018-08-10T00:00:00+00:00

El texto tiene 13 capítulos, cada uno dedicado a un aspecto de la guerra. Se considera una obra definitiva sobre estrategia y táctica militar.

Es el más famoso de los Siete Clásicos Militares de China. Durante dos mil años ha sido el tratado militar más importante de Asia.

Ha influido en el pensamiento militar de Oriente y Occidente, en tácticas de negocios, estrategia legal y mucho más.

Citas #

Aparenta debilidad cuando seas fuerte, y fortaleza cuando seas débil.
Si el enemigo es superior en fuerza, evítalo.
Ataca donde no esté preparado. Aparece donde no te esperen.
El general que pierde una batalla hace pocas consideraciones de antemano.
No hay país que se haya beneficiado de una guerra prolongada.
La excelencia suprema es romper la resistencia del enemigo sin luchar.
Si conoces al enemigo y te conoces a ti mismo, no temas cien batallas. Si te conoces pero no al enemigo, por cada victoria sufrirás una derrota. Si no conoces ni al enemigo ni a ti mismo, perderás siempre.
Puedes saber cómo conquistar sin ser capaz de hacerlo.
El estratega victorioso busca la batalla solo después de haber asegurado la victoria.
En la batalla solo hay dos métodos de ataque: el directo y el indirecto.
Un ejército puede marchar grandes distancias sin sufrir si va por territorio donde el enemigo no está.
Tendrás éxito si solo atacas lugares sin defensa.
Las tácticas militares son como el agua: el agua huye de lo alto y corre hacia abajo. En la guerra, evita lo fuerte y golpea lo débil.
Que tus planes sean oscuros como la noche. Cuando te muevas, cae como un rayo.
Reflexiona y delibera antes de actuar.
El general inteligente evita al ejército cuando su moral está alta y lo ataca cuando está cansado y quiere volver.
No avances cuesta arriba contra el enemigo ni te opongas cuando baja.
El arte de la guerra enseña a no confiar en que el enemigo no venga, sino en estar preparado para recibirlo.
Abre camino por rutas inesperadas. Ataca puntos desguarnecidos.
Quienes enfrentan la muerte pueden lograr cualquier cosa.
Para dirigir un ejército, establece un estándar de coraje que todos deban alcanzar.
Si es ventajoso, avanza. Si no, quédate donde estás.