- Proporciona el contenido más reciente del libro Startup CTO's Handbook, y el texto principal puede consultarse en Markdown
- El libro puede comprarse en Amazon y Audible
- El enlace a la versión más reciente en Markdown renderizada como PDF está en estado Coming Soon, y el manuscrito original existe actualmente como una versión desactualizada en Google doc
- Se recomienda contribuir con issues y pull requests para reflejar adiciones, cambios, sugerencias y críticas en futuras ediciones
- La licencia permite copiar, modificar y redistribuir siempre que no se revenda, se mantenga el nombre del autor y la atribución de autoría, y las versiones posteriores se publiquen bajo una licencia similar o idéntica
1 comentarios
Opiniones de Hacker News
Definitivamente hay cosas con las que estoy de acuerdo. Por ejemplo, apoyo grabar todas las reuniones. Pero también hay muchas partes con las que personalmente no coincido, como la gestión del desempeño[0]
No lo digo necesariamente como una crítica, sino que los enfoques y estilos de liderazgo pueden variar según el área del problema. Espero que no se tome esta guía como algo sagrado e intocable. Si lo que dice aquí no coincide con tu experiencia, recomiendo confiar más en tu propia experiencia
[0] https://twitter.com/bcantrill/status/1216491216356823040
Como CTO, no veo cómo podrías hacer esa solicitud sin coerción
Dicho eso, en la práctica muchas veces sí hay brechas técnicas reales, y creo que cuando un gerente actúa como coach puede acelerar el crecimiento y el desempeño de alguien
Esa postura habla de gestión prospectiva del desempeño, es decir, cómo mejorar el desempeño hacia adelante. Pero en la mayoría de las empresas, las evaluaciones de desempeño se parecen más a una evaluación retrospectiva, que ordena el desempeño pasado en el proceso de distribuir compensaciones y ascensos
Un proceso prospectivo es excelente, pero al final también hace falta cierto grado de calificación del desempeño pasado
Tuve la oportunidad de trabajar con el autor en dos empresas, y es difícil expresar con palabras la enorme diferencia que hacen estas cosas cuando se implementan de verdad
El impacto no se queda solo en producto o ingeniería, sino que se extiende a toda la organización. Cualquier sistema o recomendación al final tiene que adaptarse a tu propia organización, pero recomiendo aprovechar todo lo posible la forma en que Zach enseña
Me gustan las grabaciones de reuniones. No porque quiera usarlas como evidencia cuando el equipo empiece a buscar culpables, sino porque es realmente útil poder volver a ver reuniones y discusiones
Si estoy en una discusión importante o una reunión de alineación que exige bastante de mis capacidades, es difícil concentrarme en el tema y al mismo tiempo tomar notas y recordarlo todo. Saber que hay una grabación me permite usar la reunión para concentrarme, hacer buenas preguntas y validar supuestos
Al día siguiente puedo volver a escuchar la llamada, pausar, escuchar a 2x o 3x, crear notas personales, escribir actas o resúmenes internos, detectar inconsistencias de pensamiento, o ejecutar una herramienta de notas con IA según mi agenda
También ayuda si alguien está enfermo, tiene que ir a buscar a su suegra al aeropuerto, tiene otra reunión al mismo tiempo o se integra una semana después de una reunión de alineación importante. Si la reunión no es importante, simplemente se ignora, y listo, con reglas razonables de borrado automático
En realidad no creo que la gente pase tiempo husmeando en lugares donde no debería entrar, así que no lo veo como un gran problema
Las reuniones de equipo también tienden a inclinar la conversación hacia quienes se sienten más cómodos hablando. Eso perjudica especialmente a quienes recién se integran o a quienes no usan ese idioma como lengua principal
No estoy en contra de las reuniones en sí. Hay personas que prefieren mucho más comunicarse por voz que por escrito, y un buen equipo debería poder acomodar las formas de trabajo que prefiere cada integrante
Pero si una reunión de equipo es importante y además exige mucho de las capacidades de los participantes, entonces no debería ser una reunión. Solo debería haber una reunión cuando todos los participantes consideren que es el mejor medio para esa conversación específica
Una reunión es como sentarse frente a una manguera: vas a perder detalles
Nos mudamos a Google Workspace porque es fácil grabar y buscar reuniones. Por ejemplo, las grabaciones están integradas dentro del evento del calendario
Si una reunión no es lo suficientemente importante como para grabarla, probablemente tampoco valía la pena hacerla
Personalmente meto más horas al día que otras personas, pero eso no sucede de forma síncrona. Las reuniones importantes pueden superponerse, y si solo lees las actas se pierde mucho matiz. Además, la gente tampoco lee bien las actas
Aun así, si grabas las reuniones, puedes revisar las actas rápido y de forma adecuada, lo cual es muy útil. Por eso estoy impulsando con bastante fuerza la grabación de reuniones
Cuanto antes entiendas la causa real, antes puedes solucionar el problema. Para entender este concepto y cómo aplicarlo a una empresa, recomiendo mucho Extreme Ownership, de Jocko Willink y Leif Babin, ex Navy SEALs
La participación asincrónica en reuniones es excelente por las razones mencionadas arriba. Hace que la información dentro de las reuniones sea buscable. Hoy las reuniones pueden subtitularse con procesamiento de lenguaje natural, y ese contenido puede ser encontrado por un LLM
Actualmente estamos entrenando un chatbot interno con contenido de Confluence, y estamos buscando ampliarlo para incluir contenido de reuniones grabadas
Haciendo un poco de promoción: estoy creando https://designpro.ai, una herramienta que convierte entradas de varias fuentes en insights y tareas. La he usado para extraer insights de transcripciones de llamadas y sé que funciona de verdad
Hace poco me convertí en CTO, y una de las mayores dificultades es la comunicación con el CEO. Quizá el libro cubra esto, pero solo leí el índice.
Durante los últimos 8 meses, el CEO no quiere reuniones de alineación, no quiere planear nada, no quiere liderar una visión y solo quiere enfocarse en killer features.
Tampoco quiere crear mockups o prototipos para probar con usuarios, y dice que, si se van a hacer, tienen que ser hermosos. No quiere hacer nada que tome más de una semana y también rechazó tener reuniones efectivas.
Lo que quiero decir es que lo que no está en el libro es justamente lo que extraño. Como referencia, somos solo 3 cofundadores.
El CTO era el “encargado técnico” del CEO, y más bien era el más destacado o importante de esos encargados técnicos, por eso recibió el título de CTO.
Es triste decirlo, pero tienes que considerar la posibilidad de que el CEO te vea como otro empleado más con un título elegante. Con esa mentalidad, desde la perspectiva del CEO, incluirte en sus decisiones se siente como una pérdida de tiempo.
Todavía recuerdo exactamente la respuesta de Marc: “Si tienes dudas, no hace falta dudar”.
Sé que es una decisión demasiado grande como para dejarse convencer por un comentario cualquiera en internet, pero igual lo digo: ya pasaron 8 meses. Probablemente ya intentaste todo lo que valía la pena intentar para arreglarlo.
¿Qué queda que todavía no hayas probado? Lógicamente, ¿qué esperas que ocurra aquí? Deberías pensar cuánto más de tu vida planeas invertir en esta situación, cuando podrías moverte fácilmente a un lugar productivo.
Hablando en serio, justo con lo que te topaste es lo que hace difícil este trabajo.
Primero, sería buena idea agendar 1:1 con otros ejecutivos. Si hay ejecutivos con los que trabajas además del CEO, puedes obtener más contexto sobre la situación en la que entraste. Si entiendes sus necesidades, también verás las necesidades más amplias de la organización.
Te contrataron para quitarle problemas al CEO, incluso si el CEO no te lo pide. Tu capacidad para integrarte al equipo ejecutivo es una de las mejores formas de demostrar tu habilidad, y lo que se necesita es consistencia, seriedad, apertura mental y la disposición de hacer preguntas genuinamente útiles.
Segundo, si el CEO y el equipo ejecutivo se reúnen con regularidad, pide participar; si no existe esa reunión, sería bueno que la planearas tú. Idealmente, después de alinearte primero con los ejecutivos que no son el CEO. Aunque el CEO no pueda asistir a todas las reuniones o a la mayoría, apreciará esa iniciativa y también se construirá confianza.
Como ya dijiste que no quiere ese tipo de reuniones, quizá tengas que moverte primero de forma indirecta a través de otro ejecutivo que tenga influencia sobre el CEO.
Tercero, si eres CTO, es muy probable que el CEO quiera algún 1:1 con cierta regularidad, aunque sea solo para asegurarse de que no te vayas. Puedes encontrar una cadencia que se ajuste a la agenda del CEO: semanal, quincenal, mensual, etc.
El propósito de esta reunión es alinearte con el CEO y recibir feedback sobre las áreas en las que lo estás haciendo bien y las que puedes mejorar. Si no puedes conseguir esa reunión, te recomiendo concluir que no es un entorno en el que puedas tener éxito e irte.
Si agendar esta reunión es difícil, conviene insistir primero con los dos enfoques anteriores para construir la relación y luego intentarlo. Si no puedes conseguir ningún espacio regular, con la frecuencia que sea, con el CEO y los demás ejecutivos, en realidad no eres CTO y deberías considerar irte.
Escribí sobre esa diferencia aquí: https://www.mooreds.com/wordpress/archives/2555
Dicho eso, la falta de planificación y la falta de impulso de una visión preocupan. Ambas son partes centrales del rol de un CEO en etapa temprana. ¿Sabes por qué está tan enfocado solo en el corto plazo? ¿Está empujando un MVP para levantar inversión o vender, o simplemente no tiene visión? Yo indagaría en esa parte para entender el motivo. O, como dijeron otros, irse también es una opción.
¿Ya llegaste a la etapa en la que le ordenas los pasos de corto plazo indispensables y el CEO dice “sí, bien, esto es lo que vamos a hacer”?
¿O estás en esa maravillosa etapa en la que, si impulsas la certificación SOC2, el CEO dice “todavía no”, pero en los pitches de ventas dice “estamos avanzando hacia la certificación SOC2”?
No te preocupes. El esquizofrénico no eres tú.
Wikipedia describe DevOps como un conjunto de prácticas que combina el desarrollo de software y las operaciones de IT, así que traducirlo como “todo lo necesario para garantizar que el software de negocio funcione en un lugar que no sea la máquina del desarrollador” parece una interpretación algo extrañamente distinta de la definición original.
En especial la parte de especialista en DevOps.
Voy a reescribirlo para comunicarlo mejor.
No conozco a ninguna de las empresas ni personas mencionadas aquí. Me pregunto si los demás sí las conocen.
Antes de dedicar tiempo a leerlo, de entrada tengo una sospecha instintiva hacia la gente que se hace llamar “director de tecnología”. ¿Vale la pena leerlo?
El público objetivo parecen ser personas con poca o ninguna experiencia profesional que heredaron el título de CTO por ser cofundadores técnicos de una startup.
Fui CTO en tres empresas durante los últimos 10 años, y quizá ya estoy viejo y con menos paciencia, pero como dicen otros, esto parece más un libro para recién graduados que acaban de convertirse en CTO como cofundadores. Estoy dando asesoría técnica a gente así.
En mi experiencia, cuanto más tiempo llevas en este rol, más buscas información concreta, como la de libros tipo Accelerate.
La tecnología aburrida es realmente importante. Las startups del sector privado ya son entidades inestables de por sí; ¿por qué aumentar el riesgo con tecnología no probada?
Por ejemplo, entre 2013 y 2016 hubo un período en el que MongoDB, de manera difícil de explicar, se convirtió prácticamente en la base de datos predeterminada. Parecía que alrededor de un tercio de las startups se habían mudado de MySQL o Postgres a MongoDB. Fue un caos total y un desastre tonto
En esos casos, cuesta imaginar por qué elegir Mongo. No hay más ventaja que acelerar un poco los primeros días de desarrollo al no tener que crear ni actualizar un esquema.
El problema es que, en cuanto los datos se vuelven complejos y se necesita algo como BI, terminas pagando esa ventaja inicial con intereses enormes.
De todos modos, incluso si los datos no son relacionales, el JSON de Postgres funciona mejor que Mongo
Algunas tecnologías nuevas desaparecen, otras permanecen.
Al comienzo de mi carrera, SQL era la tecnología nueva y brillante. Impulsé con fuerza que la empresa dejara las bases de datos de red y pasara a SQL, y el resultado fue muy bueno.
Lo mismo ocurrió con la programación orientada a objetos frente al C tradicional.
Algunas tecnologías nunca llegan a estar a la altura de lo prometido y se convierten en una atadura para las organizaciones que las adoptan.
También hubo un momento en que era demasiado pronto para adoptar responsablemente la tecnología de LLM. Pero pronto llegará el momento en que el directorio preguntará por qué no se adoptó. Tal vez para casos de uso externos, y casi seguro para casos de uso internos.
Una de las tareas difíciles del CTO es juzgar el momento para adoptar nuevas tecnologías. Hay que decidir cuándo la tecnología aburrida es lo mejor para la empresa, cuándo está bien incorporar una tecnología temprana y cuándo una tecnología nueva se vuelve un acelerador tan grande que es imprescindible adoptarla
Me parece interesante que dividan al CTO en tres tipos: orientado a la tecnología, orientado a las personas y orientado al exterior.
Una startup en etapa muy temprana me está ofreciendo el rol de CTO. Todavía no hay producto, solo algunas demos básicas, y están preparándose para levantar una ronda pre-seed.
Me pregunto qué será lo más necesario en este rol. ¿Un CTO técnico o un CTO de personas? Al principio parece que será sobre todo un rol técnico, porque hay que desarrollar el producto. Pero me pregunto cuándo se dará la transición hacia un CTO más centrado en las personas. Me gustaría escuchar insights o experiencias al respecto
Te conviertes principalmente en ese rol y sostienes los demás como puedas; cuando esas tareas se vuelvan demasiado grandes o importantes, contratas a alguien que se encargue de dos o más de las otras áreas.
La segunda pregunta, más difícil de responder, es qué quieren ellos —los otros CXO— que seas. Eso puede bloquear lo primero. En algunos casos es un CTO sin la C: solo una persona técnica a la que le dicen qué hacer, que corre demos para lucirse y que nunca escucha el “por qué” del negocio.
Tengo algunos enlaces guardados sobre “qué es exactamente un CTO”.
http://www.startuplessonslearned.com/2008/09/what-does-start...
https://www.allthingsdistributed.com/2007/07/the_different_c...
También recomiendo The Manager’s Path, de Camille Fournier
Aunque dice que “pagar la deuda de forma proactiva es una inversión necesaria para la salud general de ingeniería”, a veces es más barato, en términos generales, incumplir con la deuda técnica que pagarla.
Siempre y cuando el product manager no intente cobrarla
Pero que un proyecto de cierto tamaño y complejidad llegue a una bancarrota técnica solo ocurre cuando no se siguieron los consejos del libro. Si ignoras la deuda técnica para lanzar funcionalidades, los releases se vuelven cada vez más difíciles y los bugs cada vez más frecuentes
Felicitaciones por la publicación del libro.
Estoy escribiendo Opinionated Launch(https://opinionatedlaunch.com) para compartir ideas prácticas basadas en mi experiencia como CTO de una startup pequeña y VPoE de una empresa que cotiza en bolsa.
Al empezar a escribir, me di cuenta de que los temas se dividían en dos ramas: gestión/equipos/personas y tecnología. Terminé concentrándome en el lado técnico, que es lo que más me apasiona, y me alegra que alguien se haya encargado del resto