A medida que una startup crece, sus flujos de trabajo deben cambiar. Me di cuenta de que esto es especialmente importante para los ingenieros. Mi papel como cofundador y director de tecnología ha cambiado significativamente a lo largo de los años. Mis responsabilidades y tareas diarias cambiaron y tuve que cambiar mi enfoque del trabajo varias veces para ayudar a la empresa a alcanzar el siguiente nivel.
En los primeros días de la empresa, el equipo estaba formado por tres tipos que trabajaban noches y fines de semana, aserrando en el sótano lo que luego se convertiría en Zapier. Antes del lanzamiento, hicimos tres o cuatro versiones del producto. Han pasado seis años desde entonces, ahora estamos procesando cientos de millones de solicitudes a nuestra API y nuestro equipo emplea a 80 especialistas de todo el mundo (incluidos más de dos docenas de ingenieros).
El crecimiento desde los días en que éramos tres hasta la actualidad ha sido muy difícil. Si quieres, puedes leer las conclusiones que hice durante este tiempo. De lo contrario, le sugiero que se familiarice con las lecciones que aprendí cuando crecía como nuevo CTO.
Árbol de desarrollo de gestión tecnológica en una startup
Antes de llegar demasiado lejos, averigüémoslo: ¿quién diablos es un CTO de todos modos? Ésta es la pregunta que me hice cuando contratamos a los primeros ingenieros del equipo. CTO: ¿un eterno dictador benevolente que en el mundo del software hace lo mismo que sigue el código? ¿O es una especie de súper administrador o súper hacker?
Le pedí consejo a mucha gente. Me comuniqué con los directores de tecnología de Buffer, Unbounce y otras startups que eran un poco más grandes que nosotros. Y obtuve la respuesta: nadie lo sabe realmente. Este es un rol difuso que no se puede introducir en ningún marco. En el proceso de comunicación, descubrí una serie de patrones de crecimiento comunes de las pequeñas empresas emergentes orientadas a la tecnología y formulé lo que el CTO debería hacer en cada etapa de desarrollo.
Como soy nerd y me encanta jugar a los videojuegos, el árbol de desarrollo me parece el más obvio. A medida que gana experiencia en el juego, aumenta su nivel y en ciertos puntos puede elegir diferentes ramas de desarrollo.
Así es como se vería un árbol STO en una startup.
Hacker solitario (1-2 ingenieros)
Este es exactamente el momento en que trabajamos en el sótano. Fue un momento divertido y fugaz. Haces muchas cosas, casi no hay comunicación y gastos generales de comunicación, porque todos trabajan en sincronía. Solo está tratando de averiguar qué funciona y qué no.
Pequeño equipo de codificadores (2-6 ingenieros)
Como fundador de una startup, desea hacer crecer su equipo, por lo que comienza a contratar personas. Por lo general, todos comienzan contratando amigos. Algunos dicen que no vale la pena contratar amigos, pero creo que es genial en esta etapa inicial. Sabe que puede trabajar con ellos, sabe lo inteligentes que son y encajan perfectamente. La etapa del equipo pequeño es cuando el CTO comienza a sentir el dolor de pasar de la piratería a otra cosa. Sigue siendo bastante bueno porque solo tienes un par de ingenieros. La sobrecarga de comunicación es bastante pequeña. Todavía estás bastante sincronizado. Entiendes lo que está pasando. Nada te sorprende.
Crecimiento del equipo (6-12 ingenieros)
Entonces todo se vuelve un poco extraño. Dejas de hablar con cada uno de los miembros del equipo. Tendrás que abordar el terrible misterio de la gestión, para mí era algo fundamentalmente nuevo, en contraste con la programación que era comprensible y natural para mí. Es en esta etapa que la sobrecarga de comunicación de escribir código aumenta significativamente. Es posible que deba considerar contratar personas que no sean sus amigos. Las cosas se complican más porque empiezan a suceder cosas que ni sabías que existían. En esta etapa, todo sucede muy rápido y también se encontrará con la primera rama del árbol de desarrollo.
Organización del equipo (más de 12 ingenieros)
Con un equipo de este tamaño, probablemente trabajes en diferentes áreas. No podrá lidiar bien con las personas y el código al mismo tiempo, por lo que debe tomar una decisión:
VP de ingeniería: enfoque en la gestión de
CTO: enfoque en codificación y arquitectura El
vicepresidente de ingeniería es la persona que configura procesos, implementa herramientas, que mejoran la productividad general y ayudan a los ingenieros a desarrollarse. Si sigue siendo CTO, continuará haciendo cosas relacionadas con la codificación directa. Es el CTO quien está familiarizado con todo el sistema desde y hacia, y también sabe dónde están escondidos los esqueletos en los armarios.
¿Deberías ser CTO?
No estaba preparado para tal decisión. Ni siquiera sabía que tendría que tomar una decisión. Pensé que el CTO sería el gerente de facto. Este parece ser el caso en más de la mitad de las nuevas empresas con las que hablé. Independientemente del camino que tome (gerencial o técnico), tendrá que encontrar a alguien que se haga cargo de la segunda rama.
Para tomar una decisión, vale la pena recordar sus orígenes. ¿Dónde pasó más tiempo, qué confianza tiene y a qué le gustaría volver?
Al principio, su equipo solo tendrá uno o dos ingenieros. Todo tu tiempo lo dedicarás a codificar, lo cual es genial. Cuando su equipo tenga alrededor de 6 personas, todo también estará bien. Aproximadamente el 80% del tiempo se dedicará a la codificación y el 20% a la comunicación. Y el flujo de trabajo seguirá siendo bueno. Estarás un 90% seguro de todo
Y luego las cosas se pondrán mucho más difíciles. Estará involucrado en trabajo directo en la mitad del tiempo, ya que estará ocupado contratando empleados nuevos y nuevos. Habrá más y más empleados que necesiten ayuda, y esto no es tan bueno, porque tendrás que hacer esto y escribir código tanto como antes. En esta etapa, debe decidir qué desea hacer: administración o desarrollo. ¿Qué le parece este movimiento a lo largo del árbol del desarrollo?
Solo necesita encontrar el que produce su dopamina.
Este es un gran consejo de un fundador de startups. ¿Se siente bien si puede ayudar a alguien a hacer frente a una tarea? ¿O disfruta resolviendo problemas técnicos? Son las respuestas a estas preguntas las que deberían ayudarlo a comprender qué camino debe tomar.
Cuatro lecciones de los CTO de diferentes startups
Hablé con 15 fundadores y directores de tecnología que intentaban decidir en qué enfocarme. Le pregunté a cada uno de ellos qué notaron en el camino y las dificultades que enfrentaron. En estas conversaciones, surgieron constantemente cuatro temas:
1. Aceptar puntos de inflexión
Les pregunté a todos sobre su mayor error: qué experiencia obtuvieron y cómo lo arreglaron. Luego les pregunté cómo intentarían prevenirlo. Todos pensaron un poco antes de responder, y luego dijeron algo como: “Sabes, probablemente no lo haría. Tenemos que pasar por momentos como este para comprender realmente lo que estamos tratando de hacer. Para aprender a hacerlo bien, es necesario familiarizarse con el otro lado ".
En términos de CTO, trate los puntos de inflexión como escalar el servicio. Si se encuentra con cuellos de botella, tendrá que solucionarlos. Esto es mucho más eficiente porque es muy difícil predecir su ocurrencia, especialmente en las nuevas empresas.
2. Tierra de nadie
Así es como puedo llamar a un equipo que consta de 6 a 12 ingenieros. En equipos así, pasa un poco de todo y es muy confuso. Notará que está diciendo frases como “¿Por qué esta persona no sabía de esto? ¿Y realmente no sabía qué hacer? " Si se enfrenta a tales preguntas, ya no podrá combinar responsabilidades: deberá hacer una cosa y transferir la otra mitad de las tareas a alguien que pueda hacerles frente. No eres lo suficientemente genio para manejar dos roles a la vez, pero no eres lo suficientemente estúpido como para ignorar esta situación. Pareces estar atrapado en el medio.
En esta etapa, la comunicación puede ayudar a construir puentes. Si se encuentra diciendo frases como "¿Por qué X hizo esto?", Entonces debería comenzar a decir ciertas cosas con más frecuencia. Repita hasta que la gente ponga los ojos en blanco y diga: "Lo mismo de nuevo". Esto es importante porque de esta manera puede garantizar un nivel igual de comprensión entre todos los empleados.
3. Mimetismo estructural
Muchas veces, he escuchado a los directores de tecnología decir algo como "Bueno, vimos cómo lo hacen en Spotify o" Vimos cómo lo hace Amazon ". Estas personas adoptaron la estructura de otras empresas. Si usted, como empresa tecnológica, innova, no debería inventar métodos de gestión innovadores. Ni siquiera debería pensar en algo nuevo en la estructura de su empresa. Necesita innovar a través de su tecnología, código y productos.
Encuentra lo que te parezca interesante e intenta aplicarlo en tu empresa. Con el tiempo, su empresa se volverá única al mezclar ideas y formas de organización que nadie más tiene. Es posible que pueda llegar a algo usted mismo, pero este no debe ser su objetivo. Debe tratar de comprender lo que hacen otras personas y esforzarse por evitarse la molestia.
4. Enfoque
La última lección se basa en mis errores personales. Cuando comenzamos a contratar ingenieros, pensamos que más personas nos permitirían hacer más trabajo. Al principio, los fundadores y el primer par de empleados contratados literalmente hicieron malabares. Nos parecía que todo el mundo podía trabajar en dos o tres proyectos, y eso estaba bien. Entonces, cuatro ingenieros pueden ejecutar de ocho a doce proyectos al mismo tiempo, ¿verdad? No, ese fue un pensamiento terrible.
Cuantos más proyectos, más hilos de comunicación. Es mucho más difícil hacer un seguimiento de todos los procesos y asegurarse de que todos entiendan todo. Mirando hacia atrás, creo que cuando contratamos a más personas, valió la pena mantener la carga de trabajo al mismo nivel y tal vez incluso reducirla un poco.
Simplemente elegimos un proyecto en el que todos se enfocaron. Dejamos en claro a todos que esta es nuestra máxima prioridad. También hubo algunas tareas secundarias, pero eran secundarias, nuestro objetivo principal era el principal.
Espero que mi experiencia ayude a quienes intentan navegar por las turbias aguas de las primeras etapas de las startups, especialmente como CTO. Sería genial si supiera todo esto de antemano, pero entonces tal vez no obtendría toda esta experiencia. Sin embargo, es absolutamente normal confundirse, posponer las decisiones para más tarde y resolverlas sobre la marcha. Todo esto es normal, porque en las primeras etapas las startups tienen una amplia variedad de necesidades.
- Discusión sobre HackerNews
- Canal de Telegram "HackerNews en ruso"