Cómo una startup pierde su chispa
(blog.johnqian.com)- En una startup en etapa seed bien gestionada, los ingenieros detectan problemas de los usuarios y se encargan directamente de implementarlos y lanzarlos, pero a medida que la empresa crece ese ciclo se vuelve más lento y se fragmenta en tareas separadas
- Los equipos de menos de 10 personas avanzan rápido en la velocidad de implementación gracias al contacto con usuarios, la selección de ideas, el feedback de colegas, una base de código pequeña y despliegues ligeros
- En organizaciones de más de 100 personas, el contacto con usuarios se separa hacia PMs, y al acumularse revisiones de seguridad, CI, revisiones de PR y procesos de infraestructura, la velocidad de trabajo se reduce mucho
- Detrás de este cambio están la disminución de intereses compartidos, la comunicación O(N^2) que surge al aumentar el número de empleados y una menor tolerancia al riesgo a medida que crecen los usuarios y las regulaciones
- Es difícil evitar por completo la desaparición de la diversión, pero puede retrasarse si no se copian apresuradamente los procesos de las grandes empresas, si se diseñan equipos pequeños e independientes con buenos incentivos y si se contrata más lentamente
Por qué trabajar en una startup pequeña se siente tan adictivo
- En una startup en etapa seed bien gestionada, el trabajo principal de un ingeniero consiste en entender los problemas de los usuarios, crear ideas, discutirlas con colegas, implementarlas y luego repetir el ciclo de lanzamiento y retrospectiva
- En equipos de menos de 10 personas, cada etapa de ese ciclo puede ser divertida
- Puedes contactar directamente a usuarios que te interesan y hablar con ellos mientras te tomas una cerveza
- Si encuentras una idea valiosa para la empresa y personalmente interesante, puedes detener lo que estabas haciendo y empezar a trabajar en ella de inmediato
- Tus colegas tienen un interés directo en el éxito de la empresa, así que están motivados para impulsar las buenas ideas y explicar los problemas de las malas
- Un colega puede incluso ser usuario de esa idea, querer trabajar contigo en ella o conocer una gran parte de la base de código, lo que hace probable que aporte ideas útiles
Implementación rápida y altas expectativas
- En equipos pequeños, la velocidad de implementación es alta
- Puedes elegir las herramientas que quieras y no hay revisión de seguridad
- La base de código es pequeña, así que puedes mantener la estructura completa en la cabeza y atreverte con refactors grandes con relativa comodidad
- Gracias al hot reload rápido, puedes repetir con rapidez el ciclo de depuración por prueba y error
- Integrar cambios también es algo ligero
- No hay pruebas lentas en CI y, para cambios seguros, puede que no haga falta una revisión bloqueante de PR
- En algunos casos puedes hacer push directo a
master, o pedirle a un colega que revise un cambio riesgoso dándole un toque en el hombro - Si no hay muchos usuarios, puedes aceptar downtime para hacer cambios rápidos en backend o base de datos
- En una startup pequeña hay una fuerte expectativa de que todo es posible
- Una nueva función podría aumentar el valor de tu participación, y luego otras personas podrían seguir construyendo sobre ella
- También puedes esperar que un usuario te diga: “¿Tú tuviste esta idea? Me cambió la vida”
- Como todo el equipo comparte los mismos intereses, se genera un ambiente donde todos celebran el éxito de los demás
Cómo cambia ese mismo ciclo cuando la empresa crece
- En organizaciones de más de 100 personas, el contacto directo con los usuarios disminuye
- Hablar con usuarios pasa a ser función del PM, y el ingeniero puede quedarse solo con un resumen de insights de usuarios y una lista de prioridades
- En el peor caso, recibes una lista confusa de tareas basada en una mala comprensión de los usuarios o en la visión egocéntrica de un manager, y puede que no haya nadie que explique por qué cada tarea importa
- Se vuelve más difícil elegir de inmediato en qué quieres trabajar
- Si todos hacen lo que quieren, aparece un caos de comunicación O(N^2)
- Los managers diseñan los planes individuales considerando también el resto del trabajo de la organización
- Puede que tengas que dejar tus ideas para después de terminar lo asignado, o desarrollarlas a escondidas en tu tiempo libre
- Todavía puedes hablar de ideas con colegas, pero hay menos interés y menos tiempo
- Tus colegas obtienen poco beneficio del éxito individual y hasta pueden convertirse en competidores por un ascenso
- Cada quien tiene una lista larga de tareas y ya no tiene la libertad de soltar lo que está haciendo para colaborar contigo
- También es más probable que les falte memoria o contexto sobre ese código en particular
Por qué la implementación se vuelve lenta en organizaciones grandes
- En organizaciones de más de 100 personas, la elección de herramientas ya está definida
- Aunque exista una herramienta nueva y mejor, puede considerarse que no vale la pena adoptarla por el costo de romper la consistencia
- Para usar una herramienta nueva, tienes que preguntarle a tu manager y mandar un correo al equipo de revisión de seguridad
- Las bases de código grandes suelen crecer por motivos de legado
- Hay mucho código que da miedo tocar, y mucho que ya nadie entiende
- Las pruebas exhaustivas se vuelven la única base real para confiar en que no vas a romper todo el sistema
- Hace falta depuración por prueba y error, pero los tiempos de compilación largos vuelven lento el ciclo de iteración
- Incluso fusionar un PR pequeño puede tomar 2 semanas
- Esperas 20 minutos para que pase CI, y si las pruebas son flaky tienes que volver a ejecutarlas
- Mientras esperas revisión, se acumulan conflictos de merge
- El revisor puede no tener suficiente contexto o motivación, así que en vez de hacer sugerencias importantes termina señalando detalles menores
- Aplicas los cambios solicitados, haces push otra vez y vuelves a esperar otros 20 minutos; este proceso puede repetirse tres veces por PR
- Un cambio de infraestructura puede convertirse en un proceso de 14 pasos para evitar downtime o pérdida de datos para 10 millones de usuarios
- Incluso si trabajas en silencio durante 3 meses y luego lanzas algo, la recompensa y el reconocimiento pueden ser limitados
- Tal vez consigas una oportunidad para hacer una demo en la reunión del viernes que verá el CEO, pero en la práctica solo una parte de tus colegas estará realmente prestando atención
- Tu manager puede decirte que eso ayudará en tu evaluación de desempeño dentro de 5 meses
- En el mejor de los casos obtienes un aumento salarial del 20% y un cambio de título; en el peor, 4 meses después llega una reorganización, tienes un nuevo manager y el proyecto pierde prioridad o se cancela
Cómo retrasar la muerte de la diversión
- Este cambio se parece más a un problema de retrasarlo que de impedirlo por completo
- Las causas de fondo son la disminución de intereses compartidos, la comunicación O(N^2) y la menor tolerancia al riesgo
- La disminución de intereses compartidos y los problemas de comunicación se vuelven difíciles de evitar a medida que aumenta el número de empleados
- La menor tolerancia al riesgo es resultado del crecimiento del número de usuarios y, en parte, también está relacionada con la regulación gubernamental
- Las startups pueden adelantar innecesariamente su corporativización al copiar procesos de grandes empresas
- Si contratas managers que vienen de grandes empresas, puede que también traigan consigo el playbook que usaban allá
- Muchas startups usan Jira solo porque lo usan las grandes empresas, pero aquí la postura es que ese tipo de forma de trabajar debería evitarse
- Puede decirse que Y Combinator ayudó a difundir la idea de que las grandes empresas deberían intentar operar como startups
- El playbook de las grandes empresas está hecho para las grandes empresas, y para cuando una startup crece quizá ya existan mejores soluciones para manejar los problemas de escala
- Cuando aparecen los dolores de escalar, es mejor resolverlos desde primeros principios o inspirarse en startups del mismo tamaño que se mueven más rápido
- Vale la pena intentar, dentro de lo posible, estructurar la empresa como varias startups independientes
- Se menciona a Rippling como un caso que hasta cierto punto logró hacerlo
- Aun así, normalmente hay límites porque los componentes del producto están demasiado conectados y la mayoría no puede generar ingresos por sí sola
- Diseñar bien los incentivos puede retrasar de forma significativa la pérdida de intereses compartidos
- Pero son raros los incentivos tan fuertes como tener una gran participación accionaria y el poder de cambiar su valor
- Uno de los mejores métodos es contratar menos
- Muchas empresas contratan demasiado rápido por desalineación en los incentivos de los managers, presión de inversionistas para parecerse a otras startups que crecen rápido y falta de comprensión del costo real de una sola contratación
- Cuanto mejores sean las herramientas, especialmente la IA, más usuarios podrá atender un equipo pequeño
- Los fundadores del futuro podrían preocuparse menos por estos dolores de escala, y el trabajo podría volverse más divertido para todos
1 comentarios
Opiniones de Hacker News
Me encantaba la forma en que trabajaba Netflix hace 10 años, cuando todavía era chica. Podían contratar a personas maduras y eliminar procesos; de hecho, intentaban desprocesar todo
Como resultado, las cosas simplemente avanzaban, y en Netflix en esa época a menudo se esperaba que algo “saliera naturalmente sin grandes incidentes”. Las regiones active-active se lograron en unos meses, también salió Asgard, una herramienta de despliegue fácil de usar, y el plan de crear su propio CDN y asociarse con ISP se concretó en 6 meses con unas 12 personas
Desde el punto de vista de un ingeniero, solo había una reunión semanal de equipo, y los managers y directores hacían muchas reuniones para alinear el contexto entre equipos, de modo que los ingenieros podían trabajar con plena productividad. En ese momento me parecía natural, pero después me di cuenta de que era un estándar altísimo
También se necesitan desarrolladores capaces de terminar el trabajo sin que los lleven de la mano, pero los managers igualmente deben saber coordinar en lugar de controlar llevando de la mano
Pero si el producto necesita mejoras iterativas a partir de aportes subjetivos de más de una persona, la comunicación y la colaboración distribuida son importantes y necesarias. Eso no significa que necesariamente tenga que ser doloroso, pero el modelo de Netflix de arriba no aplica en todas partes y no debería copiarse a ciegas
En los lugares donde trabajé, el producto no estaba bien definido, no por descuido, sino porque era nuevo y su forma era incierta, así que nadie sabía qué debía ser. En cambio, Netflix tenía un objetivo claro —“enviar video a una pantalla de la manera más eficiente posible”—, lo que lo acercaba a resolver un problema puramente técnico
Por supuesto, seguiría habiendo desarrollo de productos como publicidad o back office, pero me pregunto si, al tener una misión central bastante sólida, necesitaban dedicar menos tiempo a alinear a la gente en la misma dirección
Cada vez que veo textos así, pongo los ojos en blanco. Me da la impresión de que quien lo escribió es bastante junior, o el tipo de fundador con expectativas extrañamente distorsionadas sobre por qué los empleados trabajan para su empresa
Es algo que viene en gran medida de la cultura peculiar de la industria tecnológica de SF, pero fuera de ella la gente no piensa así sobre su trabajo. Los mejores desarrolladores con los que trabajé no estaban “embriagados” por el trabajo; eran profesionales que sabían lo que hacían, estaban bien remunerados por ese conocimiento y tenían vidas plenas fuera del trabajo, con amigos e intereses personales
Esta narrativa se parece más a propaganda para hacer que ingenieros jóvenes e influenciables entreguen más de su vida al trabajo de lo que justifica su salario. Si eres un ingeniero joven, no deberías hacerlo. Hay muchos jefes que se aprovechan del entusiasmo y la ingenuidad para destrozar por completo la vida personal de la gente, pero también hay muchos lugares que esperan una relación empleador-empleado normal
Cuando propuso posponer los salarios hasta el lanzamiento del producto, las tácticas de confianza acumuladas durante años finalmente se cobraron, y poco a poco me di cuenta de que el sueldo miserable había sido intencional. Podían pagar un salario decente por ese trabajo, pero cuando pedí una compensación adecuada, solo recibí resistencia, promesas en migajas y bloqueos
Más tarde, cuando reclamé el dinero atrasado, dijo que “no tenía dinero para pagar”, pero después de que renuncié furioso, contrató a otra persona para rehacer desde cero mi segundo proyecto. Yo no era el desarrollador más rápido, y parece que el nuevo contratado también era bastante bueno, pero tanto para mí como para otro desarrollador, mi trabajo estaba cumpliendo lo suficiente
Son situaciones del tipo: “Despidieron a tres compañeros y ahora estoy haciendo el trabajo de cuatro personas; le digo a mi jefe que estoy sobrecargado y no me escucha”. Una persona profesional probablemente ya se habría ido antes de los despidos o, si surgiera una situación así, habría puesto límites y negociado qué haría y qué no haría dentro de una semana laboral normal
La empresa puede despedir gente sin pensarlo, pero hay demasiadas personas lavadas del cerebro para preocuparse más por la empresa que por su propia vida, hasta un punto absurdo
Después me pasé a una startup y no me arrepiento. Trabajo más, pero lo disfruto mucho más, y aunque no podría hacerlo para siempre, la recompensa económica también mejoró, así que probablemente no tenga que trabajar hasta los 65 como en aquel empleo estable y aburrido
Eso no significa que no tengan una vida plena, ni que estén siendo explotados. De hecho, quienes dicen lo contrario parecen estar obteniendo menos de lo que se puede obtener del trabajo. Es una pena pasar así 40 horas a la semana
Básicamente tomó el Kool-Aid y ni siquiera sabe lo que no sabe
También hay factores que van un paso más allá de la “chispa” y provocan destrucción total
Esta es una lista incompleta de lo que hasta ahora he visto que contribuye mucho a deteriorar o derrumbar equipos de ingeniería y productos: líderes demasiado técnicos, líderes no técnicos, ingenieros problemáticos y micromanagement
Cuando una startup crece, los ingenieros superestrella pasan a roles de liderazgo como VP Engineering, arquitecto o CTO, pero si no tienen perfil de líder, es fácil que el equipo se convierta en un zoológico sin visión; por el contrario, un líder no técnico con muy poca experiencia en ingeniería también es igual de peligroso
Si por entrevistas superficiales entran ingenieros problemáticos y además los despidos son laxos, aunque solo el 5~10% del equipo sea de ese tipo, bloquean el avance, evitan responsabilidades, solo acumulan reputación y empujan resultados basura, dañando mucho la moral. Mantener un buen equipo y una buena cultura de ingeniería parece tan difícil como parar un lápiz sobre la punta de la mina
Los fundadores primerizos suelen dudar demasiado a la hora de dar feedback negativo, degradar a un manager demasiado técnico que debió quedarse como IC, o dejar ir a un empleado que no encaja
Una startup local puso como VP de producto a un amigo diseñador UI de un ejecutivo C-level; no podía manejar el trabajo en absoluto, pero lo mantuvieron 2 años con el argumento de “darle la oportunidad de crecer”. Todos los que estaban debajo de ese VP sabían que era incompetente y hablaban de cómo rodearlo
Al final, las iniciativas de producto ni siquiera pudieron arrancar y la empresa tuvo que pivotar por completo hacia trabajo basado en servicios. Es mejor no quedarse en una startup que sigue manteniendo a un líder no calificado al que la gente de la empresa ya dio por perdido
Esa misma empresa tuvo, durante una reducción de tamaño, la oportunidad perfecta para desmantelar el imperio de ese VP de producto, que casi no trabajaba con él, pero lo evitaron por sus conexiones con el C-level y en su lugar despidieron ingenieros. Empezaron recortando a los ingenieros mejor pagados y terminaron perdiendo ingenieros clave; enviaron la señal de que la incompetencia se tolera si conoces a las personas correctas, y en los meses siguientes se fueron muchas más personas clave
Cualquiera comete errores de contratación, pero cómo se responde a esos errores determina el destino de la empresa
Se pueden enunciar reglas de experiencia como “a los IC hay que darles tanta autonomía como puedan manejar”, pero toda regla tiene excepciones. La sabiduría comprimida pierde contexto y se malinterpreta con facilidad, o alguien con poca experiencia puede seguirla como culto de carga
He visto pequeñas dinámicas surgidas de matices en la personalidad individual y la estructura organizacional convertirse en enormes disfunciones y pérdidas de productividad, aun cuando todos actuaban con buena intención y hacían su mejor esfuerzo. No se logra buena ingeniería con órdenes desde arriba y planificación centralizada
Tiene que haber suficientes personas que entiendan el producto y el negocio de punta a punta, incluyendo a los ingenieros en terreno, para que las decisiones pequeñas se tomen alineadas con la visión general y las preocupaciones correctas puedan subir al liderazgo. Hay que sopesar juntos los costos de corto y largo plazo de producto, diseño, legal, finanzas, soporte, seguridad y operaciones
Esto solo es posible cuando hay alta confianza y seguridad para que los expertos puedan opinar y encontrar los trade-offs adecuados; como el ego y los choques de personalidad lo obstaculizan fácilmente, se necesita madurez en el liderazgo. La analogía de parar un lápiz sobre la mina encaja bastante bien
Esa persona revisa la app y empieza a llamar deuda técnica a todas las decisiones que no tienen contexto para ella. Lo he visto varias veces, y una vez le dije a un nuevo VP Engineering que se veía ignorante al decir que habían sido malas decisiones cuando no estuvo presente en los problemas originales, las decisiones ni el cronograma
Por suerte, más tarde me llamó aparte para agradecerme y pidió más contexto. Después de escuchar toda la historia, estuvo de acuerdo en que habíamos tomado la decisión correcta. Pero también he visto casos que fueron en la dirección opuesta, y ahí sí es realmente difícil
Metía a todos los equipos en una hoja de cálculo e intentaba automatizar la gestión con métricas uniformes, en vez de enfocarse en gestionar y desarrollar a sus reportes directos
En cambio, he visto llegar a un líder menos técnico y a los ingenieros alrededor poner los ojos en blanco con un poco de machismo, pero en la práctica sacó a las malas contrataciones, contrató jugadores estrella y alineó las prioridades de todos para volverlos productivos. El liderazgo es algo completamente distinto de la excelencia técnica, y demasiadas veces se recompensa con ascensos una capacidad que debería recompensarse con aumentos o bonos
Alguien con experiencia de liderazgo, pero también con capacidad práctica, que si se le da suficiente tiempo puede entender hasta los detalles de un nuevo stack tecnológico o de los movimientos financieros, puede ganarse el respeto de las superestrellas de primera línea por su contribución de liderazgo a largo plazo
No estoy de acuerdo. He fundado una empresa pequeña y también he trabajado en gigantes, incluidos FAANG y grandes bancos, pero ese tipo de entorno inmersivo se puede crear en cualquier lugar.
La clave es que un líder dinámico forme un equipo donde la gente sepa exactamente por qué está ahí, asigne a cada quien lo que hace bien y haga que quienes son buenos en algo ayuden a quienes no lo son. Luego hay que dejar claro qué valor tiene la misión del equipo para la misión de la empresa y su propósito en el mundo, y eliminar con insistencia las barreras que bloquean la producción y el impacto.
Argumentos como la comunicación N² son reduccionistas e inexactos. Ningún equipo depende de todos los equipos de la organización; normalmente el ámbito es pequeño y los equipos adyacentes son finitos. Los equipos core son la excepción, pero un equipo core que funciona bien no opera como overhead N², sino como un punto de enfoque, una estructura N a la que los equipos acuden.
N puede ser grande, así que son importantes un filtrado eficaz, automatización, autoservicio, plataformas coherentes que se documenten solas y miembros del equipo a quienes realmente les guste enseñar. Armar equipos así es tremendamente difícil desde el punto de vista de gestión y terminé agotado, pero se supone que gestionar debe ser tremendamente difícil. En mi próximo trabajo volveré como distinguished engineer en una startup de etapa tardía, para regresar un rato a mis raíces.
Dicho eso, es cierto que ese entorno inmersivo se puede crear en cualquier lugar, y que es importante un líder dinámico que forme un equipo donde la gente sepa por qué está ahí. Aun así, creo que sí tiene que ver con la escala y los malos incentivos. Incluso en FAANG he oído que algunos departamentos se sienten como startups y otros son un aburrimiento que te chupa el alma.
El contraejemplo que das no es un ejemplo de que la complejidad N² no exista, sino de que esa complejidad se gestionó correctamente.
Si dices que no todos los equipos dependen de todos los demás equipos, en realidad estás de acuerdo con el artículo. Entonces no entiendo qué parte dices que está equivocada.
La eficiencia de escala que supuestamente se obtiene en organizaciones grandes en realidad no se siente como eficiencia. Me refiero a eficiencias como tener especialistas en contratación, RR. HH., aseguramiento de calidad o investigación de usuarios.
En vez de crear una estructura organizacional más “eficiente”, quizá sería mejor hacer crecer la organización replicando una y otra vez el equipo más pequeño que haya funcionado de manera efectiva. Aunque cómo lograr que esas “miniempresas” se comuniquen eficientemente entre sí es otro problema.
Cuando la valoración de la empresa crece y entran accionistas y directivos con menor apetito de riesgo, hay que gastar mucho dinero en gestión y evitación de riesgos. En una empresa anterior, un competidor violaba la ley de forma bastante descarada para resolver necesidades de los usuarios, pero como era pequeño y ni siquiera tenía ingresos, parece que salió ileso.
Además, por experiencia personal, la mayoría de los empleados no invierte tanta energía como los fundadores, lo cual es completamente entendible. A medida que baja la proporción de fundadores frente a empleados, terminas contratando a tres personas para terminar de forma estable y a tiempo algo que tú podrías hacer solo.
Las primeras contrataciones están cerca de los fundadores y tienen mucho que ganar si la empresa tiene éxito, así que se parecen más a ellos; pero el empleado número 213 vende 40 horas semanales de trabajo y, en la práctica, lo único que obtiene es un salario fijo. La idea romántica de una gran empresa formada por varias startups independientes suena bien, pero nunca he visto que funcione y me cuesta imaginarlo.
Creo que la mejor forma de escalar es crear procesos que refuercen las características que quieres en los equipos y contratar managers que entiendan que los equipos son conjuntos de individuos distintos. Los managers deben tener libertad para gestionar a su gente de forma que optimice las entregas y reduzca la rotación.
Entre equipos debe haber estándares muy altos de comunicación y calidad de entregables, y la cultura organizacional debe construirse sobre el respeto por cada persona contratada y una concentración obstinada en ubicar a cada quien en un equipo donde pueda trabajar de manera efectiva.
Los frutos del trabajo cuelgan cada vez más alto. En las etapas tempranas de una startup, el espacio de problemas es abundante, el impacto que puede generar una persona es anormalmente grande y la cantidad de personas con quienes hay que compartir ese logro es la menor posible.
Cuando la empresa crece, los tres factores quedan bajo presión. El espacio de problemas se vuelve más escaso, el reconocimiento por los grandes impactos lo acaparan cada vez más los niveles superiores de la jerarquía, y aumenta la cantidad de personas que comparten el impacto, mientras el reconocimiento se vuelve breve y difuso.
Pero al final terminó convirtiéndose en una sola organización enorme. La estructura organizacional horizontal de Valve es parecida. Cuando algo crece lo suficiente, al final todo termina volviéndose un bloque.
El arte de gestionar el crecimiento consiste en gran medida en encontrar formas de liberar a la gente en vez de encadenarla.
La frase “La mayoría de las startups copian los procesos de las grandes empresas y aceleran innecesariamente su corporativización. Por lo general traen managers de grandes empresas, y ellos traen su propio playbook” es dolorosamente precisa.
He pasado por este ciclo varias veces. Mi startup favorita y la última que fue exitosa fue adquirida en 2007, en su cuarto año, por una enorme empresa global, y yo me quedé 2 años más.
Después del lanzamiento del producto, definitivamente nos volvimos más lentos por la necesidad de soporte al cliente y apoyo a ventas. El excelente VP Engineering pasó a ser CTO, y cuando contrataron a un idiota de mandos medios como VP, se acabaron los buenos tiempos. El nuevo VP contrataba “team players” en lugar de buenos ingenieros, premiaba la lealtad por encima de la capacidad, y empezaron a pasar cosas ridículas.
Mi etapa divertida tipo startup se redujo a exactamente una semana al año, entre Navidad y Año Nuevo. Esa semana no había nadie, así que podía trabajar con mucha más libertad en lo que yo consideraba importante, y crear una versión alfa de alguna función nueva y brillante que obligara a la organización a seguirme.
Entre los candidatos hay una cantidad sorprendente de gente tipo tiburón. Aparecen, detectan que eres nuevo, te dicen todo lo que quieres escuchar y prometen resolver todos los problemas. Aseguran que en cada empresa anterior hicieron exactamente lo que tú necesitas, te adulan y dicen que estaban esperando la oportunidad de trabajar con alguien como tú.
Imagínalos como una versión cinco veces más intensa y más difícil de detectar que el candidato IC más labioso que hayas entrevistado. Tienen un carisma increíble, pero no muchas ganas de hacer el trabajo difícil; se incrustan en la empresa y luego intentan extraer valor de ella.
Extraen su propia compensación, puestos para contratar a sus amigos, compensación para esos amigos, contratos rentables para amigos proveedores, e incluso puede haber comisiones clandestinas. Generan mucha actividad, así que pueden pasar años antes de que la gente se dé cuenta de que en realidad no hicieron gran cosa. En el proceso, los empleados capaces se cansan de tanta basura o son desplazados por señalar la incompetencia, y terminan yéndose.
Loonshots, de Safi Bahcall, explica bastante bien este fenómeno. Alrededor de las 150 personas se produce una “transición de fase” en los incentivos, que puede ser letal para muchas organizaciones.
El secreto está en cómo una startup supera ese número de personas. Sinceramente, muchas empresas de software quizá no necesiten más de 150 empleados.
El número de Dunbar es un concepto propuesto como límite cognitivo a la cantidad de personas con las que se pueden mantener relaciones sociales estables. Aquí, relación significa saber quién es cada persona y cómo están conectadas entre sí.
https://en.wikipedia.org/wiki/Dunbar%27s_number
El mundo ya escaló más allá de ese límite hace miles de años, y las empresas también pueden escalar por encima de él.
No se puede exagerar el valor de la recomendación de contratar menos. Dicho de otro modo: contrata solo cuando no haya otra forma de resolver el problema, y aun entonces, hazlo con cuidado.
Hay que aceptar que este principio alargará bastante los plazos. El costo de mediano y largo plazo de contratar de más es mucho peor que el costo de retrasar un lanzamiento. Por desgracia, el entorno de financiamiento de startups y las expectativas de crecimiento a menudo incentivan lo contrario.
Dicho eso, subestimé bastante lo mal que se había puesto la situación de contratación en las startups de Silicon Valley. Mucha gente usa las startups como un puesto para poner en el currículum mientras se recupera del burnout de FAANG o se prepara para entrevistas.
En esa estructura, por miedo a perderse a las pocas personas capaces de construir una empresa, los hiring managers tienden a ser demasiado optimistas. Al final, hay que sacar agresivamente a quienes no encajan.
Hubo partes de este artículo que me gustaron y otras con las que no estuve de acuerdo.
La parte con la que más coincido es “no contrates demasiado rápido”. No se me ocurren muchas startups o empresas que hayan fracasado o sufrido porque contrataron demasiado lento, pero sí se me ocurren muchísimos problemas causados por contratar demasiado rápido, incluida mi experiencia personal.
En cambio, la parte de “no uses Jira” me hizo poner los ojos en blanco. Así como el sol sale por el este, criticar Jira es el pasatiempo favorito de los ingenieros. Según el tipo de startup, Jira puede ser una herramienta muy buena para ese trabajo.
Si la empresa tiene muchos workflows que debe soportar, cuando el seguimiento es deficiente y la propiedad de los issues no está clara, se pierden muchas cosas y se desperdicia mucho tiempo. Claro que también es fácil perder tiempo si se complica Jira en exceso creando un millón de estados innecesarios, pero creo que hoy Jira se ha vuelto fácil de usar de forma productiva y rápida para equipos pequeños.
No quiero decir que Jira sea la mejor herramienta para empezar; en mi startup anterior empezamos con Trello y nos fue bien. Pero cuando entras en operación y tienes que gestionar y priorizar muchos issues operativos junto con el desarrollo de nuevas funcionalidades, es muy probable que necesites una herramienta como Jira para alinear a todos y compartir información.