Por qué un CIO debería seguir tocando tecnología (y no solo PowerPoints)

La tecnología no se dirige bien desde una sala de juntas

Con los años me he dado cuenta de una cosa: cuanto mayor es la responsabilidad que tienes sobre la tecnología, más peligroso es alejarte completamente de ella.

Y no hablo de pasar el día administrando servidores, revisando cada firewall o escribiendo código. Mi trabajo hoy es mucho más amplio que eso.

Pero tampoco voy a decir que haya dejado atrás esa parte. La realidad de una organización mediana es distinta a la de una gran multinacional. Aquí los roles muchas veces se mezclan y es normal cambiar de gorra varias veces a lo largo del mismo día.

Puedo empezar la mañana hablando de estrategia, presupuestos o riesgos, continuar revisando una arquitectura con un proveedor y terminar analizando una incidencia, validando una configuración o desplegando un servicio junto al equipo.

Y, sinceramente, creo que eso me ayuda a tomar mejores decisiones cuando vuelvo a ponerme la gorra de responsable tecnológico.

No porque necesite demostrar nada a nadie. Ni porque crea que un responsable tenga que hacerlo todo.

Lo hago porque sigo pensando que perder completamente el contacto con la tecnología sería perder una parte importante del criterio que necesito para decidir.

Pero hay algo que no quiero perder: el criterio.

Porque cuando dejas de entender mínimamente la tecnología sobre la que estás decidiendo, empiezas a depender demasiado de presentaciones bonitas, palabras de moda, informes perfectamente redactados y demostraciones comerciales donde todo parece sencillo.

Y la realidad rara vez se parece a una demo.

Por eso sigo tocando tecnología siempre que tiene sentido. A veces porque forma parte directamente de mi trabajo. Otras porque necesito entender mejor una tecnología antes de decidir sobre ella. Y muchas simplemente porque sigo disfrutando aprendiendo.

Sigo creyendo que las mejores decisiones nacen cuando la estrategia y el conocimiento técnico todavía conservan un punto de encuentro.

El problema de decidir solo por PowerPoint

Cuando diriges tecnología, muchas decisiones parecen estratégicas, pero tienen consecuencias muy concretas.

Elegir una plataforma cloud, aprobar una herramienta de seguridad, externalizar un servicio, cambiar una arquitectura, incorporar IA, migrar de proveedor o sustituir una solución crítica no son decisiones abstractas.

Afectan a cómo trabaja el equipo, cómo se protege la información, cuánto dependes de un proveedor, qué margen de maniobra tienes cuando algo falla y cuánto te va a costar mantenerlo dentro de seis meses.

Si pierdes el contacto con la parte técnica, corres el riesgo de decidir solo por presentaciones, promesas y casos de éxito perfectamente maquillados.

Y en tecnología, decidir solo por PowerPoint suele salir caro.

He visto proyectos magníficos sobre el papel que empezaban a complicarse el primer día de operación. No porque la tecnología fuera mala, sino porque nadie había pensado lo suficiente en quién iba a mantenerla, cómo se integraba con lo que ya existía o qué ocurriría cuando dejara de funcionar como en la demo.

Ahí es donde suele empezar el trabajo de verdad.

Con el tiempo he aprendido que mantener la curiosidad técnica no consiste en hacerlo todo. Consiste en seguir haciéndote preguntas cuando todo el mundo parece tener ya una respuesta.

Ahí es donde, muchas veces, empieza una buena decisión.

La diferencia es enorme.

No se trata de sentarte a configurar cada firewall. Se trata de entender lo suficiente para saber cuándo una solución tiene sentido, cuándo está sobredimensionada, cuándo introduce dependencia innecesaria y cuándo el proveedor está vendiendo complejidad envuelta en una palabra de moda.

---

Las preguntas que no salen de un informe

No necesito ser el mejor administrador de sistemas, el mejor desarrollador ni el mayor especialista en cada tecnología. Sería imposible.

Pero sí necesito entender lo suficiente para escuchar a quienes saben más que yo, valorar sus argumentos y hacer las preguntas adecuadas e incómodas antes de tomar una decisión:

• ¿Qué problema real estamos resolviendo?
• ¿Qué complejidad nueva estamos introduciendo?
• ¿Quién va a mantener esto dentro de seis meses?
• ¿Qué impacto tiene en seguridad?
• ¿Qué pasa si falla?
• ¿Cuál es el plan de salida?
• ¿Estamos eligiendo esto porque encaja o porque está de moda?
• ¿Nos hace más independientes o más dependientes?
• ¿Qué coste oculto aparecerá después?
• ¿Qué parte de esto entiende de verdad el equipo que tendrá que operarlo?

Con el tiempo me he dado cuenta de que las mejores decisiones rara vez empiezan teniendo todas las respuestas.

Normalmente empiezan cuando alguien hace la pregunta que nadie estaba haciendo.

Estas preguntas no salen solo de un libro de gestión. Salen de haber visto sistemas caer, de haber sufrido integraciones mal planteadas, de haber restaurado copias que no estaban tan bien como prometía el procedimiento y de descubrir que algo que en una demo parecía trivial, en producción arrastraba muchas más dependencias de las previstas.

Aprendí que la experiencia técnica no sirve para tener siempre la respuesta correcta.

Sirve para detectar antes las preguntas que todavía nadie se ha hecho.

Y, curiosamente, muchas de las decisiones más difíciles que he tomado empezaron exactamente ahí.

---

Separar el ruido de la realidad

Vivimos en una época en la que cada pocos meses aparece una tendencia que promete cambiarlo todo.

Cloud. Zero Trust. IA generativa. Automatización. Observabilidad. DevOps. Platform Engineering. Agentes autónomos. Low-code. No-code. SASE. Copilotos. Todo como servicio.

Algunas tendencias aportan muchísimo. Otras aportan algo. Y otras simplemente suenan muy bien en una keynote.

No me preocupa que aparezcan tecnologías nuevas. Llevo demasiados años viendo cómo unas sustituyen a otras.

Lo que sí me preocupa es cuando dejamos de hacer preguntas porque asumimos que una tecnología nueva tiene que ser mejor por definición.

La base técnica no te hace inmune al marketing, pero sí te ayuda a separar mejor el ruido de la realidad.

Te ayuda a entender qué hay detrás de una herramienta. A detectar cuándo algo simplifica de verdad y cuándo solo mueve el problema a otro sitio. A diferenciar entre una solución madura y una demo brillante. A saber si algo encaja en tu organización o si solo queda bien en una diapositiva.

También te ayuda a hablar mejor con tu equipo.

Cuando entiendes los límites reales de un sistema, las conversaciones cambian. Se discute mejor. Se prioriza mejor. Se evitan decisiones que luego paga el equipo técnico en forma de deuda, noches largas o mantenimiento imposible.

Ahí es donde cambió también mi forma de trabajar.

Dejé de fijarme únicamente en si una tecnología funcionaba y empecé a preguntarme quién tendría que mantenerla, qué dependencia creaba, cómo se recuperaría y qué pasaría dentro de tres años.

Un equipo técnico nota enseguida cuándo quien decide entiende mínimamente lo que está aprobando. Y también nota cuándo solo repite lo que ha oído en una presentación comercial.

---

Mi laboratorio de criterio

Muchas de las cosas que pruebo en casa terminan ayudándome después en el trabajo. No porque vaya a replicarlas exactamente igual en producción, sino porque me permiten llegar a las reuniones con algo más que una presentación comercial o una ficha de producto.

Cuando ya has desplegado una tecnología, la has roto, la has actualizado, has recuperado una copia o has visto dónde falla, la conversación cambia completamente.

Una de las formas que tengo de seguir tocando tecnología es mi homelab.

Para mí no es solo un hobby. Es mi gimnasio de criterio técnico.

En realidad nunca he dejado de aprender de la misma manera.

Empecé haciendo pequeños programas en BASIC sobre un ZX Spectrum. Después llegaron MS-DOS, dBASE, Clipper, las aplicaciones de gestión, la depuración, las redes, Windows, Linux, la virtualización, Docker, la nube, la automatización y ahora la inteligencia artificial.

Han cambiado las herramientas. La forma de aprender sigue siendo exactamente la misma.

Primero tocar. Después romper. Luego entender. Y finalmente volver a empezar sabiendo un poco más que el día anterior.

Ahí puedo probar, romper, desplegar, automatizar y equivocarme sin afectar a nada crítico. Sin ventanas de mantenimiento. Sin comités. Sin usuarios esperando. Sin impacto en negocio.

Solo yo, el terminal y el sistema diciéndome si lo que pensaba que funcionaba realmente funciona.

Ahí no hay marketing.

No hay diapositivas.

No hay palabras de moda.

Solo una pregunta muy sencilla:

¿Funciona realmente o solo parecía buena idea?

En el homelab pruebo Docker, Caddy, Uptime Kuma, servidores Linux, monitorización, backups, automatizaciones, IA local, DNS, VPN, seguridad y todo lo que me ayuda a entender mejor cómo se comportan las tecnologías cuando dejan de ser teoría.

Luego, cuando en una reunión alguien propone algo parecido, ya no parto de cero.

Más de una vez una prueba en el homelab me ha hecho cambiar de opinión antes de tomar una decisión importante.

No siempre porque una tecnología fuera mala. A veces simplemente porque, al probarla, descubres limitaciones, dependencias o costes que una presentación comercial nunca llega a mostrar.

Prefiero descubrir esas cosas en mi laboratorio que cuando ya forman parte de un proyecto real.

No significa que lo sepa todo. Sería imposible.

Pero sí significa que cuando tengo que decidir sobre una tecnología rara vez parto únicamente de lo que me cuenta un proveedor o de una demo preparada para impresionar.

Eso cambia completamente la conversación.

Porque ya no hablas únicamente desde la teoría ni desde la documentación del fabricante.

Hablas desde algo mucho más útil: la experiencia de haberlo probado antes de tener que decidir sobre ello.

---

La IA exige más criterio, no menos

La inteligencia artificial es probablemente el mejor ejemplo de por qué sigo defendiendo que un responsable tecnológico no puede vivir únicamente de informes.

Nunca había sido tan fácil utilizar una tecnología sin entender realmente cómo funciona.

Y precisamente por eso nunca había sido tan importante conservar el criterio técnico.

Con la inteligencia artificial está pasando algo curioso.

Todo el mundo habla de ella. Todo el mundo quiere aplicarla. Todo el mundo quiere automatizar algo. Pero no siempre está claro qué problema resuelve, qué datos necesita, qué riesgos introduce o qué nivel de autonomía es razonable.

Por eso me interesa probar modelos locales, herramientas de automatización y agentes de IA. También proyectos como OpenClaw, que permiten experimentar con agentes conectados a Telegram y otros flujos.

No porque crea que todo deba automatizarse.

De hecho, pienso justo lo contrario: cuanto más poderosa es una tecnología, más importante es entender dónde no deberías usarla.

La IA puede ayudar mucho, pero también introduce riesgos: privacidad, alucinaciones, dependencia de proveedores, fuga de datos, exceso de confianza, sesgos, automatizaciones mal diseñadas y decisiones tomadas por sistemas que nadie entiende del todo.

Yo no necesito ser investigador de IA para entender dónde puede aportar valor y dónde introduce riesgos que no compensan.

Y eso no se aprende solo leyendo whitepapers. Se aprende probando, comparando modelos, viendo dónde fallan, midiendo costes, analizando límites y entendiendo qué ocurre cuando la demo se convierte en proceso real.

---

Seguridad, backups y realidad

Otra razón para seguir cerca de la tecnología es la seguridad.

La ciberseguridad no es solo una política, un comité o una herramienta con dashboard bonito. Es configuración, hábitos, parches, copias de seguridad, restauraciones, accesos, logs, segmentación, revisión continua y respuesta ante incidentes.

Cuando has configurado servidores, cuando has visto servicios expuestos donde no deberían, cuando has tenido que restaurar un backup un domingo por la tarde, entiendes mejor la diferencia entre:

“Tenemos una política”

y

“Esto realmente nos protege”.

No es lo mismo.

Por eso temas como el hardening de servidores, una buena estrategia 3-2-1 de backups, MFA, segmentación de red, gestión de vulnerabilidades o pruebas de restauración no son solo “cosas de sistemas”.

Son parte de la responsabilidad de cualquier responsable tecnológico.

No necesito ejecutar personalmente cada control de seguridad.

Pero sí necesito entender qué protege, qué riesgo reduce y qué puede ocurrir si un día deja de funcionar.

---

No confundas tocar tecnología con microgestionar

Hay una diferencia enorme entre implicarte técnicamente y querer controlarlo absolutamente todo.

Yo no pretendo sustituir al equipo. Ni tendría sentido. Cada persona aporta conocimientos que yo no tengo.

Lo que sí intento es conservar suficiente criterio técnico como para entender las implicaciones de las decisiones que tomamos entre todos.

Conviene dejarlo claro: seguir tocando tecnología no significa revisar cada pull request, cuestionar cada decisión técnica o meterte en cada configuración de tu equipo.

Eso no es liderazgo. Eso es ruido.

También he aprendido que liderar no consiste en saber más que el equipo.

Consiste en rodearte de personas muy buenas, confiar en ellas y crear el contexto para que puedan hacer bien su trabajo.

Pero delegar no es desconectarse.

Delegar bien exige entender lo suficiente para acompañar, priorizar, desbloquear y proteger al equipo de malas decisiones externas.

La base técnica no debería utilizarse para imponer decisiones ni para demostrar quién sabe más.

Debería servir para hacer mejores preguntas, entender mejor las respuestas y ayudar a que las decisiones sean más sólidas.

Para saber cuándo decir “sí”. Cuándo decir “no”. Y, sobre todo, cuándo decir:

“Vamos a probarlo antes de decidir”.

Esa frase ha evitado más errores que muchas reuniones de comité.

---

La realidad de una organización mediana

Después de muchos años trabajando en tecnología, cada vez creo menos en los perfiles completamente separados.

La realidad de una organización mediana no suele parecerse a la de una gran multinacional. Los equipos son más reducidos, las responsabilidades se cruzan y una misma persona puede tener que cambiar de gorra varias veces durante el día.

En mi caso, puedo empezar la mañana hablando con dirección sobre estrategia, presupuesto, seguridad o riesgos; continuar revisando un proyecto o una arquitectura con un proveedor; y terminar analizando una incidencia, validando una configuración o entrando en un servidor para entender qué está ocurriendo.

No significa que tenga que hacerlo todo ni que deba sustituir a los especialistas. Sería imposible y, además, sería una mala forma de trabajar.

Significa que la dirección, la seguridad, la arquitectura y la operación no viven en compartimentos estancos. En muchas organizaciones forman parte de una misma realidad y hay que saber moverse entre ellas sin perder la perspectiva.

Por eso no me identifico demasiado con el responsable tecnológico que solo vive entre reuniones, presentaciones y cuadros de mando. Pero tampoco con quien se queda únicamente en la consola y pierde de vista el negocio, las personas o las consecuencias de sus decisiones.

Mi trabajo está precisamente en ese punto intermedio.

Consiste en traducir necesidades de negocio a decisiones tecnológicas, explicar riesgos técnicos en un lenguaje que dirección pueda entender, cuestionar propuestas de proveedores y, cuando hace falta, acercarme lo suficiente a la operación para comprobar qué está ocurriendo realmente.

Esa combinación define mucho mejor mi día a día que cualquier organigrama.

La tecnología no es lo que promete una presentación. Es lo que funciona cuando hay que implantarla, mantenerla, protegerla, recuperarla y explicar por qué merece la pena.

Esta forma de entender la tecnología no nació cuando empecé a dirigir equipos.

Nació mucho antes, cuando pasaba horas delante de un ZX Spectrum intentando entender por qué un programa no funcionaba, cuando programaba en BASIC, cuando depuraba aplicaciones o cuando desmontaba sistemas simplemente para comprender cómo estaban hechos.

Con los años cambiaron las responsabilidades, cambiaron las herramientas y cambió la tecnología.

Lo que nunca cambió fue esa curiosidad por entender qué ocurre debajo de la superficie.

Y, sinceramente, creo que esa curiosidad sigue siendo una de las herramientas más útiles que tengo para tomar decisiones.

En resumen

Sigo tocando tecnología porque forma parte de mi trabajo y también de mi manera de entenderlo.

En una organización mediana no siempre existen fronteras perfectas entre estrategia, gestión, seguridad, arquitectura y operación. Hay momentos en los que toca ponerse la gorra de responsable, otros en los que toca coordinar, negociar o decidir y otros en los que hace falta acercarse a la parte técnica para entender qué está ocurriendo.

No creo que un responsable tecnológico tenga que hacerlo todo. Tampoco creo que deba convertirse en el cuello de botella de su equipo o intervenir en cada detalle.

Pero una cosa es delegar y otra muy distinta desconectarse.

Yo necesito mantener suficiente contacto con la tecnología para entender las consecuencias de las decisiones que tomo, hacer mejores preguntas, cuestionar una propuesta cuando algo no encaja y distinguir entre una solución real y una presentación bien preparada.

No porque desconfíe de mi equipo.

Todo lo contrario.

Cuanto mejor es el equipo, mejores conversaciones puedes tener con él si ambos compartís un mínimo de lenguaje técnico y una misma forma de entender los problemas.

También sigo haciéndolo porque disfruto aprendiendo.

Empecé con un ZX Spectrum, BASIC, memoria y hexadecimal. Después llegaron las aplicaciones de gestión, las bases de datos, las redes, los servidores, la seguridad, Linux, Docker, la automatización y la inteligencia artificial.

Las herramientas han cambiado mucho. Mi forma de aprender, no tanto.

Lo curioso es que la curiosidad sigue funcionando exactamente igual que hace treinta años.

Sigue empezando por la misma pregunta:

¿Y qué pasa si pruebo esto?

Tocar. Probar. Romper en un entorno controlado. Entender. Documentar. Volver a empezar.

No sigo cerca de la tecnología porque quiera hacerlo todo yo ni porque eche de menos una etapa anterior.

Sigo cerca porque cada vez tengo más responsabilidad sobre las decisiones que tomo.

Y cuanto mayor es esa responsabilidad, menos me puedo permitir decidir desde la distancia.

Con el tiempo me he dado cuenta de que seguir tocando tecnología nunca tuvo que ver con la nostalgia.

Tiene que ver con la responsabilidad y con una forma de conservar el criterio.

Y probablemente sea también la razón por la que existe esta web: compartir lo que pruebo, lo que aprendo, lo que funciona, lo que descarto y cómo todo ello influye en mi manera de gestionar la tecnología.

---

Artículos relacionados