Historias para CTOs y responsables de tecnología

Es duro y arduo el camino de los responsables de tecnología, ponga en su LinkedIn CTO o no.

CTO son sólo unas siglas sin importancia y lo que importa en realidad son las responsabilidades asociadas a ellas. La gente que acaba asumiéndolas suele tener un arranque poco planificado, al fin y al cabo no existe la carrera de CTO. Muchas veces se trata de una persona que se dedicaba a algún área de tecnología y que por circunstancias se ve obligada a tomar decisiones en cuanto a qué y cómo, crecer y gestionar equipos, estar al día, anticipar el futuro… A algunas les gusta y lo buscan, a otras no y se adaptan o lo sufren.

responsable de tecnología

Como siempre dice tía Azu: «cortando cojonitos, se aprende a capar». Es cierto que a base de tortas todos podemos llegar a aprender y cuanto más tiempo lleves en esto más aprendes, sin embargo, apoyándote en las historias y aprendizajes de otros puedes hacer que ese camino sea un poco menos solitario, un poco menos duro, darte menos contra paredes que no se van a mover.

Siempre puedes tomar un té o una caña con un colega (si no tienes un colega a mano te lo puedes tomar conmigo :P) para compartir opiniones y aprender de experiencias ajenas, pero vamos a ver algunos recursos que tenemos a mano en Internet para aprender de otros que ya han pasado por un camino similar:

De personas concretas
  • Empezamos por el blog de una mujer que no sólo ha aprendido mucho en su camino, si no que sabe explicarlo y compartirlo . Se trata de Camille Fournier que además escribió un libro buenísimo que puede servir de guía a quien tenga que hacer esa transición de técnico a manager: The Manager’s Path.
  • Hablando de libros, no puedo dejar pasar la oportunidad de recomendar The Phoenix Project que cuenta la historia ficticia de un tío al que de buenas a primeras le encaroman muchas responsabilidades y de cómo lidia con este hecho. Se centra mucho en DevOps pero aunque sea sólo por lo entretenido que es, te lo tienes que leer.
  • Los blogs de los fundadores de Stack Overflow no tienen ningún despedicio. Tanto Jeff como Joel escriben artículos de temas variados e interesantes que le vendrán genial a todos los responsables de tecnología.
  • Están los artículos de Paul Graham, uno de los fundadores de Y Combinator, que ha visto pasar por delante de él un montón de empresas tecnológicas y suele plantear temas que dan que pensar.
  • Otro Graham pero Graham-Cumming, tiene una seríe de artículos en los que explica como fue el camino desde entrar como programador en Cloudflare y acabar siendo CTO con todo lo que conlleva.
  • La sección Management 101 de James Stanier cubre de una manera muy concreta distintas situaciones a las que se enfrenta quien tiene que tomar decisiones en ingeniería (el resto de los artículos también están muy bien).
De personas random
  • Aunque no soy muy fan, hay algunos sitios con entrevistas escritas o en formato pocast que hay que reconocer que son muy interesantes, por ejemplo Modern CTO o Developer to manager.
  • Por último, pero no por ello menos útil, buscando un poco puedes encontrar ciertos checklists que te ayudarán al acometer tareas en las que no seas experto pero de las que serás responsable como son el cumplimiento de la GDPR o la seguridad general de los sistemas de la empresa.

Estos son algunos recursos, pero a sabiendas de que hay muchos más, me encatará saber cuales recomendaríais vosotros. No os pediré que los dejéis en los comentarios que ya nadie escribe, pero siempre me podéis escribir a través de la web, en Twitter, LinkedIn o por donde sea.

PD: Para suplir un poco esta soledad, hemos creado un grupo sin más pretensiones que hacer una quedada al mes para charlar, pedir consejo, contarnos cosas… llamado CTOs Anónimos Valencia («responsables de tecnología anónimos de Valencia» no quedaba tan cool). Mañana será la primerísima quedada, así que ¡no dudeis y apuntaros!

Me la suda la tecnología

Todos hemos asistido a interminables debates sobre que tecnología es mejor, sobre que plataforma es mejor, sobre que lenguaje es mejor. Sin embargo, tras muchos años trabajando en una gran cantidad de proyectos de lo más variado y asistir atónito a otras tantas flamewars, he de decirlo: me la suda la tecnología.

Cada proyecto es un mundo, y en todos los casos hay múltiples factores que hacen que una tecnología se amolde mejor que otra. Pero igual que cada problema tiene múltiples soluciones, cada solución se puede implementar con múltiples tecnologías.

Hay técnicos que sólo se fijan en los factores técnicos, pero en cuanto has tenido un pie en negocio sabes que hay mucho más en lo que pensar.

Pongamos por ejemplo un caso sencillo: Ikea decide que va a dar un servicio de diseño de hogares, para lo que crea una bolsa de empresas y diseñadores freelance. La idea es que los diseñadores vayan a las casas de la gente y les ayuden a elegir los muebles y a comprarlos.

Las soluciones son múltiples: Ikea podría darles equipos iguales a cada diseñador; los diseñadores podrían llevar su propio equipo. Alguien en Ikea decide que es mejor la segunda opción. Aparece un nuevo problema y es que los clientes no siempre tienen conexión a Internet: se puede hacer un software que funcione en local y cuando haya conexión haga los pedidos; también los diseñadores podrían tener un pincho 3G para garantizar la conexión y así poder tener una simple web para que hagan los pedidos. Alguien en el departamento de ingeniería le hace ver las dificultades de la primera solución a un directivo y este consigue que se haga una partida para los pinchos, por lo que se quedan con la segunda opción. Por tanto, la solución final será hacer una simple web.

Para hacer una web las opciones son múltiples. Aquí podríamos entrar en una flamewar interminable sobre si PHP, .Net, Ruby on Rails, Node… También sobre si tener servidores propios o usar alguna plataforma cloud; si usar MySql, SqlServer, una base de datos NoSQL o guardar la información en archivos de texto plano. Las distintas opciones considerando todas las posibles combinaciones son muchísimas, y por mucho que nos guste más una tecnología que las otras, ninguno de los argumentos que se suelen usar en las flamewars debería de influir de verdad en la decisión. La verdad es que la tecnología en una solución tan simple como esta os la debería de sudar. A mi me la suda.

¿En qué nos deberíamos fijar si fuésemos el responsable tecnológico de este proyecto en Ikea? Hay que ver inicialmente si Ikea ya tiene otros proyectos y como se han hecho, con qué tecnologías se manejan mejor sus desarrolladores, etc. Si no los tuviese, podríamos mirar al mercado, ver que tipo de técnicos va a ser más fácil contratar por ejemplo, o si se espera que el proyecto evolucione y crezca o si hay previsión de otros proyectos y de que tipo serían… Hay múltiples factores que deberían afectar a la toma de la decisión, y la gran mayoría no vienen marcados por la tecnología sino que vienen marcados por los factores de negocio.

Por tanto, cuando os volváis a ver involucrados en una de esas de si «el este mola más», dejad de darle vueltas a qué lenguaje es más cool o que plataforma usa la empresa X. Plantearos los factores de negocio en casos concretos y las guerras dejarán de ser tan cruentas y se volverán mucho más objetivas y productivas. Cuando os digan que «mi tecnología mola más» responded con este grito: me la suda la tecnología.