La colaboración no sirve
(newsletter.posthog.com)- El dicho “si vas solo, vas más rápido; si vas acompañado, llegas más lejos” puede llevar a una startup al fracaso
- La colaboración eficiente debería parecerse a la ayuda de un navegador mientras conduces, pero la mayoría de las empresas sufren una pérdida de velocidad por demasiado feedback y roles demasiado repartidos
- PostHog, bajo el valor de “Tú eres quien conduce (You're the Driver)”, enfatiza la autonomía y un alto sentido de ownership, y minimiza la colaboración innecesaria
- Las causas del exceso de colaboración incluyen las ganas de ayudar, una cultura demasiado inclusiva, pedidos de feedback poco claros, abuso de “let’s discuss” y evasión de responsabilidad
- La solución es un enfoque práctico: priorizar desplegar de inmediato, dejar claro quién es responsable, pedir feedback solo a quienes realmente hace falta, recibir feedback después del lanzamiento y cortar de inmediato la colaboración innecesaria
La trampa de la colaboración
- La frase "si quieres ir rápido, ve solo; si quieres llegar lejos, ve acompañado" mata lentamente a una empresa
- Es una trampa que justifica la colaboración excesiva
- La colaboración útil debería limitarse a dar indicaciones o información del entorno mientras alguien conduce
- Pero la mayoría de las organizaciones caen en una colaboración ineficiente, como si todos se turnaran para agarrar el volante
- El feedback adecuado ayuda a llegar rápido al destino, pero el feedback excesivo reduce la velocidad y te pone en riesgo de no llegar a donde querías
La paradoja del feedback: dar buen feedback significa saber cuándo no darlo
- Incluso en PostHog, con el crecimiento aumentó la colaboración que no agrega valor o cuyo valor es demasiado bajo frente al tiempo invertido
- Hace poco, en una reunión general, trataron el tema de que "la colaboración es mala"
- "Tú eres quien conduce (You're the driver)" es un valor central de PostHog: contratar gente excelente y no estorbarla
- Sin deadlines, con coordinación mínima, y sin managers dando instrucciones
- A cambio, se exige un nivel extremadamente alto de ownership y capacidad para lograr mucho por cuenta propia
- Marketing despliega código, ventas responde preguntas técnicas sin apoyo, y product engineers trabajan en todo el stack
- Casi siempre hay alguien que sabe más que tú y da ganas de colaborar, pero colaborar obliga a quien conduce a bajar la velocidad y explicar antecedentes, contexto e ideas
- Esta tendencia suele aparecer en algunas expresiones típicas
- "Me pregunto qué piensa X"
- "Quiero escuchar la opinión de Y"
- "Tenemos que trabajar con Z"
- A veces eso lleva a insights valiosos, pero siempre hace que quien conduce vaya más lento
- Erosiona la motivación, la confianza y la eficiencia de quien conduce, y al final reduce el volumen de lanzamientos
Si la colaboración es mala, ¿por qué la gente la hace?
- Todos contribuyen al problema
- La gente quiere ayudar: si alguien publica en Slack algo en lo que está trabajando, por la cultura de feedback los demás sienten que deben opinar
- Por otro lado, pedir feedback a personas específicas puede sentirse poco inclusivo, así que no lo hacen, aunque en realidad sí ayudaría
- No se especifica con suficiente claridad qué feedback hace falta: eso deja espacio para que la colaboración se meta donde no debe. Una discusión sobre construir una función concreta puede escalar hasta una reevaluación completa del roadmap del producto
- Cuando alguien propone una buena idea, la reacción por defecto no es "hazlo", sino "discutámoslo"
- Como prueba, en Slack aparece "let's discuss" una y otra vez
- Eso desvía de la ejecución hacia la discusión
- La gente está demasiado ocupada para ejecutar, o le da flojera, así que solo quiere hablarlo
- PR → issue/RFC → Slack (ahora la mayoría termina aquí) → "discutámoslo"
- No está claro quién es el dueño (o nadie quiere adueñarse de lo que se está discutiendo)
- Aunque moleste, a veces una sola persona no puede hacer shipping de punta a punta con suficiente calidad, y no siempre basta con lanzar e iterar
- El código roto se puede arreglar, pero un newsletter no se puede reenviar
Cómo romper la colaboración (y avanzar más rápido y más lejos)
- Si ves a la colaboración como enemiga, ¿cómo la derrotas?
- La ejecución es la opción por defecto: Pull request > Issue > mensaje de Slack
- Cuando la colaboración se pasa de rosca, hay que marcar el límite con claridad: “tú eres quien conduce, decide”
- Para pedir feedback, etiqueta a personas concretas y di exactamente qué quieres de ellas; no lo lances al aire
- Prefieren dar feedback después del lanzamiento (antes de la siguiente iteración) en vez de hacer review antes de lanzar: el feedback previo puede convertirse en una especie de proceso de aprobación
- Los líderes deben contenerse con el feedback y mantener una actitud de “simplemente puedes hacer cosas” (you can just do stuff)
- Cada persona actúa como un “capitán informado (informed captain)”
- Puede escuchar feedback, pero la decisión la toma esa misma persona
Conclusión
- No se puede erradicar toda colaboración, y parte de ella sí es útil (Ian y Andy editaron este newsletter)
- Pero hace falta esforzarse por reducir la colaboración por defecto
- Si no intentas activamente reducirla, probablemente ya estás colaborando demasiado
- Como la colaboración inherentemente reduce la velocidad,
cuanto menos colabores, más lejos y más rápido podrás llegar
- Escrito por Charles Cook, que odia el agua mineral con gas (porque las burbujas son demasiado colaborativas)
12 comentarios
Está bien trabajar juntos.
Si esa persona está ausente (fallecimiento, enfermedad, vacaciones), ¿entonces no van a atender al cliente?
Trabajo en una empresa tan pequeña que soy la única persona que trabaja aquí. Así que yo solo hago el mantenimiento y desarrollo por mi cuenta... Llevo tanto tiempo así que a veces me dan ganas de trabajar con otras personas. Trabajar solo es muy solitario...
Es un artículo con un título demasiado provocador.
¿No será que la personalidad del autor destaca tanto que no logra llevarse bien con los demás?
Para crear una sola funcionalidad,
normalmente hacen falta roles como diseñador, planificación, project manager, frontend, backend, QA, etc.
Parece que está haciendo afirmaciones exageradas para exponer el problema que percibe.
La colaboración no debe referirse a que todo avance con una dinámica tipo ágora.
Eso sí, hay dos elementos que claramente sí son un problema: abusar del ‘let’s discuss’ y evadir responsabilidades.
Pero en muchos casos eso ocurre porque no existen líderes o responsables con verdadero criterio.
Para eso justamente se investiga, se forma gente, se contrata o se compran soluciones.
También se agrava cuando se arma un equipo solo con miembros que obedecen bien.
No creo que este sea un problema causado por la colaboración o por trabajar solo.
Tengan en cuenta que Posthog siempre escribe artículos con una redacción así de fuerte.
Como el tono es demasiado fuerte, a veces se ven textos que se pasan un poco del tema y se desvían.
(¡Pero si el agua con gas es buenísima!)
¿No es esa agua carbonatada una plataforma de lanzamiento para highballs? ejem
Opiniones de Hacker News
Cada vez que surgía una colaboración, alguien aconsejaba decir: "hay demasiada gente, X es el driver, así que tú decides"
Pero cuando un gerente dice "tú decide", luego no va a la reunión y más tarde vuelve con un "yo lo habría hecho diferente" pidiendo cambios, los empleados terminan yéndose
El jefe de mi jefe siempre hablaba así, pero cuando yo subía un PR al final exigía un rediseño completo
Al final me daba miedo el trabajo mismo, porque sabía que cualquier proyecto acabaría reescribiéndose desde cero
Si un jefe revierte decisiones demasiado seguido, los integrantes del equipo terminan empujándole a propósito todas las decisiones
Al final el propio jefe se ahoga en su necesidad de control
Pero en el contexto de "que el gerente no dé instrucciones", sí mantiene coherencia
porque siempre le seguían ajustes infinitos de píxeles, cambios de layout y propuestas de rehacer todo el stack
Creo que el núcleo del problema no es la colaboración, sino la estructura de toma de decisiones
El feedback es una oportunidad para aprender, pero si no está claro quién toma la decisión final, todo se vuelve más lento
Para decidir rápido, hace falta dejar claro quién es la persona decisora y asumir que la mayoría de las decisiones son reversibles
Si hay menos colaboración, también hay menos oportunidades de aprender
La persona decisora debe estar claramente asignada, pero también debe escuchar el feedback
Además, las decisiones reversibles conviene tomarlas rápido
Se dice que la colaboración ralentiza, pero en realidad ese proceso mejora la calidad
Algunos se oponen solo por oponerse, y al final intentan arrebatar la propiedad de la idea
Incluso si el responsable final está claro, si su postura es débil al final todo deriva en consenso de la mayoría
Si marcaban "request changes", todos tenían que seguirlo, y al final la calidad del código empeoraba
Creo que es mucho mejor contratar buena gente y delegar la autoridad de decisión
Debe dar dirección, prioridades y un marco de trabajo para que el equipo pueda juzgar por sí mismo
No comparto el odio al agua con gas del autor, pero sí me alegra que se hable públicamente de los problemas de colaboración
En varias empresas me ha tocado gastar 3 veces más tiempo en revisiones de código por comentarios mínimos de estilo que en la implementación real
Mi postura es: "si no te gusta, corrígelo tú y avísame"
También compartieron este video relacionado
Para tratarlos en la etapa de revisión de código ya es demasiado tarde
El problema es la gente que no respeta el estilo del código que tiene alrededor
Eso se debería resolver con un linter o con cultura de equipo
Una funcionalidad hecha en solitario y sin colaboración se vuelve un gran riesgo cuando toca darle mantenimiento
Si el sistema explota cuando yo no estoy, ahí queda claro que el problema fue la falta de colaboración
El autor enfatiza el sesgo hacia la acción, pero si se excluye la colaboración aparecen silos y exceso de confianza
Me ha funcionado bien una cultura de Slack donde uno pregunta algo como: "voy a hacer X, ¿hay objeciones fuertes?"
Y así el trabajo realmente avanza
Hace tiempo hice entrevistas mientras escribía un libro sobre GitHub, y algunos equipos abrían un PR vacío antes de escribir código para conseguir aprobación del diseño
Eso no es colaboración durante la ejecución, sino colaboración en la etapa de planificación
Si hay buena escritura y buena comunicación, colaborar puede ser rápido y efectivo
En la era de la IA, esta capacidad va a ser todavía más importante
Si no hay reuniones ni se comparte lo que se hizo, el mérito no se ve
Si previenes problemas, nadie se entera, y por eso en algunos lugares hasta existe una cultura de "dejar que el problema ocurra"
Solo con planificación me cuesta imaginar la implementación
Como dice la última frase del texto, "sí existe la buena colaboración"
El título es clickbait, pero PostHog ya es conocido por ese estilo
Hace que uno mire críticamente el meme de la "colaboración"
Este texto es un experimento mental equivocado
El problema no es la colaboración, sino la ausencia de autoridad para decidir
Una sola persona debe decidir con claridad, y mientras más se empuje esa autoridad hacia abajo, más rápido se avanza
Este tipo de textos distorsiona el lenguaje y tiene una toxicidad que vuelve inútiles conceptos necesarios
También es un problema esa cultura de decir enseguida "pregúntale a Bob" cada vez que alguien se traba
A corto plazo parece más rápido, pero a largo plazo provoca pérdida de oportunidades de aprendizaje y sobrecarga de trabajo
A mí me gusta que mis colegas se interesen por mi trabajo
"hazlo como quieras" en realidad significa "no me importa"
El problema no es la colaboración, sino la colaboración ineficiente
En un PR hay un entregable concreto, así que la discusión se vuelve más clara
Siento que la colaboración funciona mejor cuando son dos personas
Entre dos pueden entender juntos la base de código y revisar los PR de cada quien
Pero cuando pasan de tres, explota la complejidad combinatoria
Por eso me gustaría diseñar los proyectos con una estructura de equipos de dos personas
enlace de referencia
Como en la analogía del texto, la F1 es un deporte extremadamente colaborativo
El piloto está en comunicación constante con su coach durante toda la carrera
Me pregunto si existe algo parecido en software
Los comentarios están raros. Viendo el resumen del texto, no parece que diga que trabajes solo o que no hacen falta compañeros de equipo, sino más bien que hay que reducir la colaboración excesiva entre los miembros del equipo.
Estoy de acuerdo.
Parece el resultado de combinar un título amarillista con un lector que no lo leyó con atención.
No solo con este tipo de textos; incluso en YouTube hay mucha gente que comenta viendo solo el título.
Cuando empiezas algo nuevo, por querer ir demasiado a la segura, puedes terminar pidiendo demasiadas revisiones a tu alrededor. En realidad, las personas o el equipo de alrededor quizá no conozcan bien el tema, así que también puede ser difícil que den buen feedback. Al final, la idea parece ser que primero conviene hacer algo y, aunque vaya en la dirección equivocada, luego recibir feedback más concreto y volver a trabajar sobre eso puede ahorrar tiempo en general.