Opinión: ¿Qué hace un CTO emprendedor?

¿Qué hace un director de tecnología (CTO) de un emprendimiento en realidad?

Por Eric Ries  

¿Qué hace su director de tecnología en todo el día? Muchas veces, parece que la gente está pensando que es sinónimo de "el tipo que se le paga para sentarse en la esquina y pensar pensamientos " técnicos" profundos" o "el tipo que llega a sola vez en un reorganizar mi proyecto en el último minuto por un capricho”. He tratado de no estar a la altura (¿o bajeza?) de los estereotipos, pero no es fácil. Carecemos de una definición clara y coherente del trabajo.

Cuando le he pedido a mentores míos que han trabajado en grandes empresas sobre el papel de un CTO, por lo general hablan de la importancia de ser la cara externa de la plataforma tecnológica de la empresa, un evangelista de desarrolladores, clientes y empleados. Eso es un trabajo importante, por cierto, y he tenido que hacerlo de vez en cuando. Pero no creo que la mayoría de los emprendimientos realmente tengan una necesidad de que alguien haga ese trabajo a tiempo completo.

Entonces, ¿qué quiere decir CTO, además de simplemente " técnico fundador que realmente no puede manejar a alguien?"

Siempre he asumido que no tendría que gestionar a nadie. Ser un gerente no sonaba divertido – bien metido, que realmente quiere ser responsable por las acciones de otras personas? Quiero decir, ¿usted ha visto a otras personas? ¡Ellos pueden hacer cualquier cosa! Por lo que inicialmente gravité hacia el título de director técnico, y no vicepresidente de ingeniería. Yo pensé que volvería a traer a un profesional para hacer la gestión y programación de tipo material, y que podría mantenerse enfocado en asegurar que construimos la tecnología realmente impresionante. Pero en el camino, algo extraño sucedió. Se hizo más difícil y más difícil separar el funcionamiento del software de cómo el software está estructurado. Si usted está tratando de diseñar una arquitectura para aumentar la agilidad, ¿cómo puede funcionar si algunas personas no están trabajando en Test-Driven Development (TDD) y los demás? ¿Cómo puede funcionar si algunas personas usan el pre-building y otros usan el “5 why’s” para tomar decisiones? ¿Y qué pasa si el despliegue tarda una eternidad? Algunas opciones pueden mejorar el rendimiento del software a expensas de la legibilidad, la capacidad de despliegue, o la escalabilidad. ¿Debiera tomarlos? Estos me sonaban a problemas técnicos, pero cuando lo hace cualquier tipo de análisis causal resultaban ser problemas de la gente. Y no hay realmente ninguna manera de abordar los problemas de la gente desde la barrera.

Así que terminé aprendiendo la disciplina de dirigir a otras personas. Resulta que yo no era demasiado malo en ello, y me di cuenta qué tan gratificante que puede ser. Pero desde que pasó un largo tiempo en un rol híbrido CTO / VP de Ingeniería, todavía tengo esa molesta pregunta. ¿Qué se supone qué el CTO debe hacer?

Esta es mi opinión. La tarea principal del CTO es asegurarse de que la estrategia de tecnología de la compañía sirva a su estrategia de negocios. Si esto suena demasiado simple o demasiado genérico, piense por un segundo si los hay compañías que usted conoce hace la inversa. ¿Alguna vez has oído a un técnico el uso de galimatías para hacer que suene como una idea de negocio que él o ella no le gustaban y era prácticamente imposible de implementar? Eso es lo que se debe tratar de evitar.

Voy a tratar de dividirla en cinco habilidades específicas.

• Selección de plataforma y diseño técnico - si su estrategia de negocio es crear un emprendimiento de bajo capital, altamente iterativo es mejor utilizar herramientas fundamentales que la hagan fácil en lugar de difícil. ¿Masivas bases de datos propietarias? No lo creo. ¿Puede la compañía meterse en sus herramientas cuando fallen y corregirlas? Si no, ¿quién va a insistir en cambiar a software libre y de código abierto? Cuando los proyectos son para despegar del suelo, quién puede consultar con el equipo para asegurarse de que sus planes son viables?  ¿Quién se hará responsable por el impacto de sus proyectos en la plataforma en su conjunto?       
• Ver el panorama general (en detalles gráficos) - El director técnico debe ser la persona en la sala que se puede mantener en su cabeza todo lo que su tecnología puede y no puede hacer. Eso significa saber lo que está escrito y lo que no, lo que la arquitectura puede y no puede soportar, y cuánto tiempo se tardaría en construir algo nuevo. Eso es más que dibujar diagramas de arquitectura, sin embargo. Ser capaz de ver la macro y micro al mismo tiempo es una característica de todos los técnicos realmente grande que he tenido el privilegio de trabajar con ellos.
• Proporcionar opciones - otra característica de un buen director técnico es que nunca dicen "eso es imposible" o "nunca haría eso." En su lugar, se encuentran las opciones y puede comunicar a todos en la empresa. Si el CEO quiere cambiar por completo el producto con el fin de servir a un nuevo segmento de clientes, usted necesita a alguien en la sala que pueden digerir las necesidades de la nueva (propuesta) de negocios y diseñar los costos de cada uno de los enfoques posibles. Algunos técnicos tienen una tendencia sólo para "decidir por ti" y le dará la "mejor" opción, pero eso es peligroso. No se puede tener un diálogo honesto, si una de las partes conoce todas las respuestas.
• Encontrar el 80/20 - esta fue mi parte favorita del trabajo. A veces, estás en una reunión en la que alguien quiere construir una nueva característica del producto. Y en su mente, lo tiene todo especificado de rabo a cabo. Sus rebanadas, sus cubitos, y probablemente hasta como hará para lavarte tu coche también. En mi mente, se están acumulando los costos (de un mes para que una parte, dos meses para que la otra parte, uh oh!). En un mal día, acababas de darles la noticia aleccionadora. Pero un buen día se veía de este modo. En el momento que entendía cual era el  objetivo de la característica adicional para los clientes, a veces podía ver una manera de obtener el 80% del beneficio al 20% del costo. "¿Sería usted capaz de aprender lo que usted necesita saber si esta característica sólo estuviese en rodajas, pero no en cubitos? Porque si no es necesario agregar un módulo de corte en cubitos, se puede reutilizar el condensador de flujo a través de las llamaradas solares ...." Me quedé sorprendido constantemente sobre la frecuencia con la respuesta fuese algo así como "¿en serio? ¿Cortar en cubos es lo caro? ¡Sólo lo dije como un capricho nomás!"

• Crecer a los líderes técnicos - Me gusta formalizar esta responsabilidad al final designando a algunos ingenieros como "técnico líderes" y delegar en ellos el trabajo de guiar a la dirección técnica de los proyectos más y más. Esta es la única forma de escalar. También me obligó a poner en claro qué aspectos de la dirección técnica de nuestra compañía eran realmente principios importantes, y que eran simplemente artefactos de cómo llegamos allí. Con varias personas tratando de trabajar con el mismo estándar, tenía que ser mucho más nítidos en nuestras definiciones. ¿Fue el hecho de que estábamos utilizando principalmente PHP esencial, o se podría agregar nuevas herramientas escritas en otros idiomas? ¿Fue un hecho importante o irrelevante que la mayoría de nuestro código web era de procedimiento y no orientada a objetos? ¿Y qué si alguien quería escribir su módulo en el estilo de programación orientada a objetos? Mediante la delegación y la formación, creamos un cuerpo de líderes que intervenir para proveer servicios tipo CTO a sus subordinados. Y trabajando juntos, creamos un equipo cuyo conjunto era mayor que la suma de sus partes.

Quiero agregar una última idea, aunque reconozco que es objeto de controversia, en la frontera en el límite entre la CTO y vicepresidente de ingeniería. No sé lo mucho que estoy influenciado por haber llevado dos sombreros, pero creo que es lo suficientemente importante como para salir en una extremidad y agregar.

• Aprópiese de la metodología de desarrollo - en una instalación de desarrollo de productos tradicionales, el vicepresidente de ingeniería o algún otro directivo a tiempo completo sería el responsable de asegurarse de que los ingenieros escribieran las especificaciones adecuadas, bien conectadas con control de calidad, y también ejecutaran la  "trenes" de cronogramas  para las versiones. Pero creo que en un emprendimiento lean, la metodología de desarrollo es demasiado importante para ser considerado "sólo de gestión". Si el equipo se va a utilizar TDD o escalabilidad JIT (just-in-time), por ejemplo, estas decisiones tienen un impacto enorme en cómo la arquitectura debe parecerse. Como mínimo, creo que el CTO y los líderes de tecnología tienen que ser responsables por los análisis de los defectos por análisis causal usando los 5 why’s. De lo contrario, ¿cómo pueden saber cuáles son sus puntos débiles y asegurarse de que el equipo y la arquitectura los arregle? Esa tarea requiere de alguien que ve todo el panorama.

Su director de tecnología (CTO) puede ser un gran arquitecto, evangelista, diseñador de la interfaz o depurador increíble. Esos son grandes habilidades para tener y tengo curiosidad de ver que funciona o no para usted. Yo seré el primero en admitir que mi experiencia es limitada, así que estoy recogiendo anécdotas. ¿Ha trabajado con o para un gran director de tecnología? ¿Qué los hizo tan excepcional? ¿Qué es una cosa un nuevo director de tecnología por primera vez podría aprender de ellos?

StartUp Lessons Learned

Posted in: cargos,CTO,Eric Ries,lean startup,opinión,organización