Despidos masivos en Twitter: la perspectiva desde IT

No tenía intención de escribir nada hasta no sacar tiempo para seguir con mis posts de scripting (que sé que tengo abandonados, pero tengo buenas razones), pero nos enteramos hoy de los despidos masivos en cierta red social y, tras ver la debacle que va a ser para mucha gente (y lo mucho que se la va a pelar a su nuevo dueño), no he podido evitar pensar en que hay otro grupo de gente para el que también es terrible y del que no se va a hablar porque, sinceramente, nunca se habla de él.

Hablemos de lo que pasa cuando se despide a alguien en este gremio, y hablemos de la gente que, cuando se toma la decisión, debe ejecutarla, más allá de la visión típica de RRHH.

Hablemos de los despidos... Desde la perspectiva de IT/helpdesk.

Un despido es un despido. Pasa en todas las empresas y afortunado quien nunca haya sufrido uno, porque, como pisar una mierda de perro en la calle, es algo que te pasa tarde o temprano. E incluso aunque no suponga un gran problema porque tengas ahorros y/o una buena cobertura social, nunca es agradable.

Y, a pesar de todo, mucha gente desconoce que un despido es un proceso largo, que implica a mucha más gente que al que deja la empresa y la persona de RRHH que se lo dice: además, incluye a contabilidad (nóminas, liquidación, finiquito...), legal (si el despido es por motivos disciplinarios), seguridad (credenciales, accesos...) e IT (dispositivos físicos, accesos a sistemas), sin contar las consecuencias que tiene para el departamento y que, muchas veces, RRHH despide a un trabajador para buscar inmediatamente un sustituto.

Reducir el despido al momento en que se comunica es simplista, y lo sé porque como parte de IT mi trabajo incluye gestionar una parte de ese proceso.

De aquí en adelante vamos a suponer, salvo que diga lo contrario, que hay buena fe por todas partes: que la empresa despide porque disuelve el departamento y no puede reubicar al trabajador, que el trabajador no guarda rencor a la empresa porque siempre le han tratado bien y que todo se va a hacer con tiempo, respetando la ley... Vamos, lo que cualquiera que conoce el proceso resumiría en "supongamos una vaca esférica".

En ese caso, la primera comunicación cuando el despido es oficial no es al trabajador, sino a IT: la decisión ya se ha tomado, pero ahora hay que revocar accesos, cerrar cuentas, desasignar licencias, hacer backups, delegar permisos, transferir datos y recuperar dispositivos, y hacerlo en un plazo de tiempo determinado, generalmente al final del día.

IT, helpdesk, soporte o "informática" es un departamento con unas competencias bastante raras: el personal es generalmente técnico, ya que trabajamos con tecnología y algunas de nuestras decisiones dependen de un CTO (Chief Technology Officer, Jefe de Tecnología), pero la mayoría de nuestro trabajo es de apoyo a otros departamentos e implementación de procesos operativos, por lo que muchas de las decisiones vienen desde Operaciones (COO, Chief Operations Officer o Jefe de Operaciones) y nuestro trabajo consiste en implementarlas y ejecutarlas.

El principal problema que tenemos en IT es que siempre somos "los malos": nuestro trabajo consiste, casi siempre, en poner problemas e inconvenientes a las soluciones que vienen de otros departamentos. Un conocido mío ingeniero dice que "el papel lo soporta todo" y en IT esto es siempre cierto. Al contrario que otros departamentos todo nuestro trabajo es en producción y se da por sentado que va a funcionar a la primera, sin problemas y sin necesidad de apoyo por parte de otros departamentos, lo que sobre el papel suena muy bien pero en la práctica no pasa jamás.

Por ejemplo, cuando llevaba un par de años trabajando en una consultora hubo una internalización masiva en un cliente. En un período de dos meses, mi empresa perdió cerca de 150 trabajadores (~50% de la plantilla) y hubo que hacerse cargo de procesar los equipos devueltos y su papeleo asociado. Por zona me tocó procesar unos 100 equipos, pero incluso trabajando en paralelo era imposible hacer más de 8 equipos diarios en la media jornada que le podía dedicar, y aparecieron los problemas, como dónde almacenar todo aquel equipamiento en la oficina (lo que dio lugar a uno de los intercambios de correo con mi jefe de operaciones más absurdos e inútiles que he vivido).

La cuestión es que IT interviene en una gran cantidad de los procesos normales dentro de una empresa, lo que incluye las incorporaciones y salidas de personal, ya que es raro que un trabajador hoy no tenga al menos un portátil y un correo de empresa.

Pero vamos a mirarlo desde la perspectiva de Operaciones y Contabilidad. ¿Cuánto cuesta la parte de IT de la incorporación de un trabajador?

Como referencia, sólo en hardware (portátil, pantalla, teclado y ratón) hablamos de al menos 1500€, dependiendo del equipo que se adquiera (no cuesta lo mismo un Macbook que un Lenovo, por ejemplo) y de los complementos y gastos como pueden ser los envíos o las gestiones por ejemplo si un dispositivo viene defectuoso de fábrica. Eso sin contar el coste de mano de obra (los equipos requieren preparación antes de su entrega), las licencias que hagan falta al trabajador (MS Office, Adobe, AWS...) o el coste fijo de infraestructura, física o virtual.

Sumando todo, estimo que cada incorporación cuesta a una empresa tecnológica de 2000 a 4000€, según empresa y puesto. Si la incorporación es además en oficina, hay que sumar coste de mobiliario, alquiler de oficinas, mantenimiento de las mismas e infraestructura complementaria, como seguridad física.

Esto es un análisis de servilleta de barra de bar, pero os podéis hacer una idea. Y no es una defensa (como alguien dirá) de que "los trabajadores costamos mucho a las empresas": nadie vende duros a cuatro pesetas, y las empresas no son una excepción, pero es un dato que necesitamos para entender el contexto en el que trabajamos.

Así que supongamos que se despide a alguien. Como ya he dicho, el primer equipo que recibe la comunicación oficial es IT, porque la siguiente persona con la que va a hablar el ya ex-trabajador es alguien de IT, para organizar la devolución de los dispositivos que usaba para trabajar porque, suponiendo que el material no pierde valor (que es mucho suponer), la empresa quiere recuperar todo lo posible. Y el siguiente paso consiste en dar de baja usuarios, recuperar licencias y almacenar datos, ya que cada día que pasa que no se hace la empresa pierde dinero.

Si además el trabajador está teletrabajando, hay que enviar un mensajero (y puede que material para envolver el equipo) para recuperarlo. Y en cualquier caso necesitas un técnico que pueda preparar ese equipo para ser entregado de nuevo, más todo el papeleo y documentación interna para tener históricos y trazabilidad.

Para que os hagáis una idea, suponiendo que no haya problemas, un técnico de IT dedica al menos una hora para organizar la recuperación del equipo y dar de baja al usuario de todas partes, más uno o dos días para recuperar el equipo (hasta una semana si el equipo está en otro país de la UE, varias semanas si además está en otro continente, más las gestiones de aduanas) y al menos dos horas en preparar el equipo y limpiarlo. Sí, limpiarlo, con papel y alcohol o limpiacristales. Y si crees que exagero, mira con cuidado tu pantalla a contraluz cuando esté apagada, mira si las teclas tienen cercos o manchas y pon el teclado boca abajo y dale un par de golpecitos, a ver qué cae.

He visto cosas limpiando equipos que no creeríais. Sí, peores de lo que piensas, de las de pensar "y ahora cómo vuelvo a mirar a esta persona a la cara".

Una de las funciones de IT/helpdesk es que el equipo informático no pierda valor: un equipo sucio, que no funciona o defectuoso no vale nada y es dinero perdido, por lo que parte de nuestro trabajo consiste en mantenerlo en condiciones para que no se pierda ese valor. Dependiendo de la empresa, Operaciones considera el plazo de amortización del equipamiento en entre 3 y 5 años, y he visto equipos que han pasado por 6 personas en ese período de tiempo. Sin un equipo de mantenimiento en IT eso es imposible, y un técnico de hardware que prepare 6 equipos diarios (que es un ritmo bastante alto) maneja más de 6000€ de equipamiento por día, tirando hacia abajo.

Y si hablo de dinero no es porque me guste, sino porque estamos hablando de empresas, donde el criterio fundamental es reducir los costes todo lo posible para aumentar el beneficio o, en mi caso, el margen con el que puedo trabajar.

Si nos vamos a la parte de datos, dado que los sistemas de la empresa son propiedad de la empresa y el acceso se concede a trabajadores, en el momento en que el trabajador pasa al estado "ex" debe restringirse el acceso lo antes posible tras el despido. Esto es debido a que, aunque la mayoría de nosotros trabajamos bajo acuerdos de confidencialidad (NDA, Non-Disclosure Agreement), la validez de esos acuerdos expira poco tiempo después del despido: el trabajador no puede hablar de lo que ha visto mientras estaba dentro de la empresa, pero si conserva el acceso tras el despido podría no estar cubierto por el NDA, lo que es una fuga de datos que, más allá de las consecuencias legales que pueda tener (GDPR en Europa), puede hacer que un comercial copie la cartera de clientes de la empresa y se la lleve a su nuevo trabajo en la competencia.

Lógicamente, cada empresa implementa esto a su manera, casi siempre a base de prueba y error. Es curioso lo que se puede saber del pasado de un departamento leyendo con cuidado los manuales, sobre todo las partes donde pone "no hacer esto".

Cuando cuento esto, la gente suele preguntar "y sabiendo que van a despedir a alguien, ¿no se lo decís?" y la respuesta es que no podemos: una cláusula del NDA de IT es la llamada "de debido secreto". Generalmente la gente piensa en "no publicar las contraseñas de la empresa en pastebin", pero ahí incluye no divulgar, por ejemplo, si la empresa ha decidido despedir al 50% de la plantilla antes de que se notifique a los afectados, y trabajar en el más estricto secreto.

Para ser un trabajo de relativamente bajo nivel, IT tiene uno de los NDAs más estrictos del planeta. Normal para alguien que suele tener acceso casi ilimitado a los recursos de la empresa.

No es la primera vez que recibo un correo que, hace unos años, hubiera sido una carpeta como ésta. Y normalmente el primer y/o último párrafo suelen ser una amenaza de lo que pasará si lo divulgas. Fuente

¿Y qué pasa si se quiere despedir a alguien de IT, que puede enterarse de su despido y, hasta que se hace efectivo, liarla? Pues hay dos escenarios:

1. Si no hay peligro, el jefe de IT le dice que lo siente, pero que vaya a hablar con RRHH antes de volver al puesto. Normalmente, antes de acabar el "lo siento" ya sabes lo que va a pasar, y mientras RRHH te dice que te despiden, tus ya antiguos compañeros te quitan los accesos que tenías.
   
2. Si hay riesgo de conflicto o sabotaje, se bloquea el acceso y se manda un correo desde RRHH para que vayas a verles. Es la forma habitual de despedir a la gente de infraestructura e IT y es la pesadilla de muchos cuando el lunes no pueden entrar a algún servidor a primera hora. No es juego limpio, pero si la persona puede borrar la mitad de los sistemas de la empresa mientras tú le quitas el acceso, puede ser un mal necesario, aunque se abusa de este método.

Esto significa que puedes saber que van a despedir a tu compañero de al lado, que además es amigo, y no puedes decirle nada mientras preparas su salida de la empresa intentando que no lo note, para que luego, al volver de hablar con RRHH, sepa que lo sabías y no le habías dicho nada porque no podías decir nada.

Despedir a un jefe de departamento de IT es parecido, pero más complicado: muchas veces tienen accesos que no se comparten con el equipo por razones operativas y gestionar eso es siempre difícil. Normalmente se consigue ayuda de otro jefe de departamento (sistemas, SRE o incluso desarrollo) para conseguir los accesos, pero se intenta que sea por las buenas, ya que es difícil acotar el daño que se puede hacer cuando no sabes a dónde puede acceder alguien.

Y os hablo de casos relativamente sencillos, porque estamos suponiendo buena voluntad, pero si no la hay gestionar una devolución se convierte en una guerra en la que, al final, terminas soltando a los abogados del departamento legal contra el ex-trabajador, y es algo que, creedme, no queréis que pase.

"Pero Tach, tu trabajo no implica contactar con los ex-trabajadores". Pues sí, es la siguiente parte del proceso de despido y, en mi empresa, una de mis funciones.

Generalmente, un despido o una baja voluntaria es como una ruptura sentimental: tiene la fase de "nuestra relación debe terminar" y la de "qué hacemos ahora que la relación se ha acabado". RRHH se encarga de llevar esa conversación, pero es trabajo de IT ejecutar la segunda parte: ver el equipamiento que tiene, contactar con el ex-trabajador y organizar la recogida. Siguiendo con la metáfora, no deja de ser tu ex pidiéndote que le devuelvas sus cosas después de decirte que habéis roto. Y por más que uses plantillas, que midas las palabras y tengas las mejores intenciones, nunca es agradable.

Ya he mencionado antes que devolver un equipo cuesta tiempo en el mejor de los casos, pero veamos el proceso y cuánto es ese tiempo:

1. Contactar con el usuario y que conteste (hasta 7 días).
2. Confirmar que tiene el material (1-2 días).
3. Confirmar que tiene lo necesario para enviarlo (cajas, envoltorios) (1-2 días).
1. Si no lo tiene, enviarle material para que pueda envolverlo (hasta 7 días).
   
4. Confirmar que lo ha envuelto y está listo para la recogida (1-2 días).
5. Coordinar la recogida (1-2 días).
6. Envío a la oficina y procesamiento (de 1 a 3 semanas, según origen).
   

Eso es mucho tiempo, y es suponiendo que, aunque el ex-trabajador tarde en contestar, tiene buena voluntad, no está dando largas y que puede haber retrasos en los envíos. Si no, estos plazos se alargan, las conversaciones se agrian y terminas teniendo que pedir al departamento legal que, por favor, te eche una mano.

Os lo dice alguien que dedica la mitad de su jornada laboral a esto.

Así que ahora vamos con el caso Twitter, la perspectiva desde IT y por qué a veces me tengo que recordar que esto es sólo trabajo.

¿Creíais que apuñalar a un compañero es lo peor que se hace desde IT? Pues sentaos cómodamente, abrochaos el cinturón y sujetaos la mandíbula, porque os prometo que antes de que acabéis de leer el post pensaréis que para trabajar en IT hay que ser un poco hijo de puta, y no os faltará razón.

 

Caso Twitter: un desastre operativo

Tras la sorpresa por la noticia, lo primero que se me pasó por la cabeza fue "a ver quién gestiona la operativa de esto", porque todos los procedimientos de IT tiene un punto débil: nunca se diseñan para funcionar a gran escala. Puedes bloquear o purgar remotamente un equipo, pero no puedes hacer que vaya solo hasta la oficina. Y gestionar un envío puede ser complicado, pero gestionar 4000 es una pesadilla. Hablad de metodologías ágiles y todo lo que queráis, pero esos procesos son operaciones manuales en su mayoría, que aunque se pueden automatizar, ninguna empresa que no tenga un departamento de almacenamiento y logística va a tener tiempo, conocimiento y recursos para ponerlo en marcha.

Y no nos engañemos: una tecnológica, basada en trabajo remoto, con trabajo "en nube" en su mayoria es de lo más opuesto a una empresa que gestione temas logísticos.

Pero luego sigo pensando en que eso es algo que no se ha decidido de un día para otro: si algo tenemos la gente de IT es que no nos vale con que nos digan "da de baja a 4000 personas", sino que queremos el listado de las 4000 personas, de los departamentos afectados, del nivel de revocación y cuándo debe ser efectiva. E incluso teniendo los datos y con todos los sistemas funcionando de forma correcta y centralizada, preparar ese cerrojazo lleva tiempo.

La experiencia me dice que se ha hecho efectivo hoy, pero que la decisión se tomó como tarde el viernes pasado, se comunicó a IT el lunes y que desde entonces han trabajado en ello sin descanso.

Efecto sobre la infraestructura

Por otro lado, despedir a un departamento entero no es algo habitual, y mucho menos en plural. Al margen de lo que supone operativamente, un cambio de ese calado afecta a la infraestructura, entre otros a los sistemas de licenciamiento: muchos fabricantes ofrecen sistemas de licencias "por volumen". Microsoft es quizás el ejemplo más conocido entre los que nos dedicamos a esto, que a partir de cierto número de licencias adquiridas (no recuerdo el número, pero se contaban por cientos) te permite usar un sistema de licenciamiento a gran escala con otras herramientas y procedimientos. Uno de sus mayores éxitos es la implementación bastante simple, basado en Active Directory, de un MDM que puedes volcar en equipos usando PXE o, usando SCCM, cambiar el licenciamiento de todos los equipos con un par de instrucciones.

Traducción: un técnico puede preparar los equipos de 100 en 100 y hacer miles en una sola jornada, o lanzar paquetes personalizados de software a todos tus Windows y forzar un despliegue en el siguiente reinicio.

El sueño húmedo de muchos de nosotros.

El problema de reducir el licenciamento tan drásticamente es que puedes perder esas herramientas, o que ya no funcionen como esperabas, lo que afecta al resto de la infraestructura que tienes en producción. Al contrario de lo que diría la intuición, hacer tus sistemas más pequeños los puede hacer más complejos y difíciles de administrar.

Eso, suponiendo que reduzcas el número de licencias, porque igual no puedes (algunas licencias se renuevan anualmente) y tienes que tener los sistemas encendidos hasta que caduquen porque la renovación es automática si no. O seguir pagando un número desaforado de licencias para mantener tu sistema en un estado parecido al que tenías, lo que hace que tu infraestructura sea proporcionalmente más cara y estés, literalmente, tirando el dinero.

Ejemplo sencillo: una licencia de Windows SQL Server para producción cuesta al menos 900$ por año por servidor, más otros 200 por cliente adicional, y aunque des de baja el servidor la licencia seguirá activa hasta que acabe el año.

Y esa es la licencia barata. Fuente

Incluso aunque todo lo anterior no importase, una parte de los procedimientos de IT están ligados a ese software, por lo que también debes reorganizar IT para sacar ese software obsoleto de manuales, procedimientos, automatizaciones, imágenes de despliegue, seguridad perimetral, antivirus... Sin perder de vista, como he dicho antes, que el trabajo de IT es siempre en producción y cualquier error afecta a toda la empresa.

Pero esto es la parte de operaciones. Vamos a la parte desagradable de mi trabajo en IT.

Protocolos de purga de datos. Política de "Bring Your Own Device"

Cuando un trabajador deja una empresa, bien la ley laboral o un NDA le obligan a devolver o entregar toda la información que tiene de la empresa y que ha obtenido como resultado de su trabajo. Esto es algo que se impone desde operaciones pero que, en el caso de los dispositivos digitales, ejecuta IT. Para poder ejecutarlo, usamos una tecnología con el nombre general de Mobile Device Managament (MDM) que permite, entre otros, aplicar políticas, instalar software, conectarse remotamente para dar soporte o incluso bloquear o purgar un dispositivo remotamente, por ejemplo, en caso de robo.

Tanto Microsoft con Active Directory, como Apple con MacOS, o incluso Google con Android tienen su propia versión de MDM, con cierta interoperabilidad, pero son herramientas específicas, especializadas y complejas que requieren planificación y tiempo para su puesta en marcha.

La cuestión es que, cuando implementas teletrabajo, tarde o temprano necesitas MDM porque además de dar herramientas a soporte permite implementar seguridad que deja las VPNs a secas al nivel de cerrar la puerta de casa con cinta de carrocero en lugar de una cerradura.

De nuevo, otro sueño húmedo de los que nos dedicamos a esto y para los Blue Team de Seguridad.

Esto enlaza con otra política que suelen aplicar muchas empresas, que ejecuta IT y que estaría dispuesto a apostar que se aplica en la red social: Bring Your Own Device (BYOD), es decir, que uses tus propios dispositivos personales para conectarte a los recursos de la empresa. En pocos pasos, te traes tu tablet, móvil o portátil a la empresa, firmas una serie de claúsulas adicionales y a partir de ahí puedes configurar tu dispositivo personal para programar mientras te vas de vacaciones.

Nunca entenderé lo de seguir trabajando mientras estás de vacaciones, pero ese es otro tema.

No me ha tocado administrar este tipo de dispositivos pero, citando a un especialista que conocí con 20 años de experiencia que administraba estas políticas, "estoy hasta la ***** de esta mierda": sin un control exhaustivo y casi de policia dictatorial o un equipo dedicado en exclusiva a dar soporte a estos dispositivos, tienes tropecientos dispositivos no estándar más a los que dar soporte. Personalmente, me parece que es un dolor de cabeza y creo que un análisis coste/beneficio de implementarlo más allá de unos cuantos VIPs diría que es viable.

Pero aunque eso suele ser un problema, no es EL problema. Y aquí entramos en psicología del usuario.

Una de las cosas que más cuesta hacer entender a los usuarios, da igual el departamento, experiencia o formación previa, es que el equipo de trabajo es de la empresa y se usa para trabajar y para temas de empresa. El equipo puede estar físicamente en tu casa, pero no es tuyo, es de la empresa, y todo dato que haya dentro es susceptible de ser analizado y retenido como parte de los datos de empresa. Puedes ver porno con el portátil de empresa, pero si IT te pilla te van a sancionar. Y puedes guardar las fotos de las vacaciones de tus hijos en el portátil de empresa, pero te arriesgas a que un auditor revise tu equipo y las vea.

Os sorprendería lo que se encuentra en los portátiles que devuelve la gente. Y sí, también he visto cosas. Y no, porno casero no es lo peor que me he encontrado.

Pero si cuando el dispositivo es de la empresa cuesta hacer ver la diferencia, cuando es personal directamente es imposible, y tienes un dispositivo personal con datos de empresa y personales que no puedes diferenciar de forma clara. La carpeta "Descargas/Downloads" es el mejor ejemplo.

Pero el trabajador deja la empresa y tú no puedes permitir que haya datos de la empresa dando vueltas por ahí. Y tras purgar el equipo de empresa, llegas al personal, que bajo política de BYOD tiene datos de empresa que también hay que borrar.

¿Y qué haces?

Miras las condiciones del BYOD, coges aire, abres la interfaz del MDM y las aplicas al pie de la letra rezando porque la persona tenga backup en algún sitio de los datos personales que te acabas de cargar. Y si estás en la oficina, buscas a algún segurata que te pueda proteger cuando el usuario se dé cuenta de lo que has hecho.

Llegado el momento, bajo políticas de BYOD, puedo pedirte que vengas a la oficina, me entregues tu teléfono personal y destruirlo delante de ti sin que puedas hacer nada para evitarlo. En algunos casos, ni siquiera podría devolverte la tarjeta SIM o incluso exigirte (bajo amenaza de demanda civil por violación de contrato) acceso a las cuentas de correo, redes sociales y aplicaciones de mensajería que hayas usado en ese dispositivo y borrar parte de ellas.

En Europa en general esto está bastante restringido, pero es posible y una de las exigencias (hay muchas más) es que tiene que haber compensación económica. Pero en EEUU, que en materia laboral y de privacidad es peor que el Lejano Oeste, lo que me sorprendería es que no hubiera pasado ya.

Dicho de otro modo, con las claúsulas de BYOD en la mano, podría obligarte a mirar mientras destruyo una parte de tu vida digital y después pedir que te acompañen a la salida mientras, como Sonny Corleone, te lanzo un par de billetes como compensación por haberte roto la cámara de fotos.

Despidos en Twitter: lo que va a suceder (si no ha sucedido ya)

Cojamos todo lo anterior y recopilemos lo que ha pasado y va a pasar.

1. Todos los equipos informáticos de los trabajadores despedidos, incluidos los dispositivos que hayan usado según políticas BYOD, serán bloqueados y sus credenciales de acceso, revocadas. Probablemente, dada la naturaleza de su trabajo, esto se haga antes de que se les notifique oficialmente el despido.
2. RRHH y Legal comunicarán el despido a cada trabajador. Recordemos que, a pesar de ser EEUU, el despido debe ser personalizado y con comunicación directa al trabajador, pero visto lo visto apostaría 100 contra 1 a que va a ser un email sacado de una plantilla y enviado con algún combinador de correspondencia con firma general ("Dpto de RRHH" o similar) para evitar represalias.
3. En algún punto de ese email se indicará que IT contactará con los ex-trabajadores para la devolución de los equipos, recordándoles que sus NDAs siguen en vigor y que puede haber consecuencias legales de no seguirlos. Eso puede incluir no hablar del proceso de despido.
4. IT contactará con los afectados para la devolución de los equipos. La experiencia me dice que será un proceso del que se encargarán varias empresas externas, ya que dudo que la matriz tenga capacidad logística y personal para afrontarlo.
5. A medida que pasen los días, los ex-trabajadores irán viendo cómo los dispositivos personales que usaban para trabajar son purgados remotamente, pero si el NDA sobre BYOD es como creo que es, no podrán hablar de ello hasta dentro de unos meses a riesgo de enfrentarse a una demanda millonaria (aunque seguro que habrá filtraciones anónimas).
   
6. Internamente, la empresa sufrirá una importante reestructuración operativa y de infraestructura digital. A nivel de IT, el ahorro real en infraestructura será menor del previsto inicialmente a medida que se vayan revisando sistemas lo que, unido a las revisiones de procedimientos de IT y los muchos fallos internos que van a aparecer (consecuencia de aplicar esto en un plazo tan reducido de tiempo), hará que en unos meses veamos a gente de IT de Twitter buscando trabajo, lo que causará aún más problemas operativos a medio plazo dentro de la empresa.
   
7. Consecuencia del punto anterior, el tiempo entre nuevas funciones en Twitter o de resolución de problemas aumentará sensiblemente. Unido a que algunos de los departamentos que han sido disueltos se dedicaban a partes de Twitter que están en producción y que se van a quedar sin mantenimiento, la red social irá sufriendo un continuo y paulatino deterioro en su backend, lo que hará que algunas funciones desaparezcan antes de lo que creíamos, puede que sin previo aviso.
   
8. Dicho deterioro provocará una fuga de anunciantes y usuarios, en una espiral auto-destructiva y autónomamente retroalimentada. La desaparición de los equipos de moderación y content-curation será echar gasolina al fuego.
   
9. Para intentar compensar la caída de ingresos, la primera función que aparecerá será la suscripción de pago que, lejos de solucionar el problema, lo agravará a medio plazo al acelerar la fuga de usuarios primero y anunciantes después. Y aún suponiendo que funcionara y evitara la caída de ingresos es algo que no llegará, al menos, hasta el próximo año fiscal.
10. Esto ya es especular, pero no es descabellado: los accionistas que queden no van a esperar a la cuenta de resultados de diciembre para ver la debacle. Tras la disolución del consejo de accionistas la semana pasada, creo que el lunes veremos una caída del precio de las acciones de Twitter por las ventas de esos pequeños accionistas que no van a esperar confirmación de que el barco se hunde para abandonarlo, lo que será echar más leña al fuego.

Pero, ¿cómo hemos llegado aquí?

Este apartado ya es especulación, pero voy a basarme en mi experiencia y los pocos datos disponibles para intentar deducir lo que ha pasado tras la compra de Twitter por parte del magnate.

Creo que el magnate tenía el plan pensado de casa, y que ha dedicado la semana a intentar recopilar información parcialmente a espaldas del consejo de dirección. Sólo así se entiende pedir a ingeniería que impriman su código en papel para revisarlo con ingenieros enviados desde Tesla:

https://www.livemint.com/technology/tech-news/elon-musk-s-day-1-at-twitter-engineers-asked-to-print-out-their-code-for-review-11667033793158.html

Primero, que el código de Twitter es probablemente el principal activo de la empresa, y que siguiendo principio de mínimo privilegio y otras disposiciones legales, conseguir la acreditación de seguridad para ver algunas partes puede costar días hasta que se consiguen todas las aprobaciones. Porque el magnate puede ser el principal accionista de la empresa, pero ni siquiera un CEO tiene acceso indiscriminado ni puede forzar ese acceso.

Tuve un CEO así, que creía que sabía cómo funcionaba todo porque se sacó ingeniería informática 15 años atrás aunque no había vuelto a tocar un servidor. Pero eso sí, tenía acceso de root a todo. Y tocaba, donde le parecía, cuando le parecía, sin avisar, se enfadaba si alguien le pedía explicaciones y nos echaba la bronca cuando algo fallaba porque había tocado donde quería, cuando quería y sin avisar.

Creo que el consejo de dirección se enteró de estos movimientos y, durante la reunión con él para presentar su plan, le dijeron que era descabellado. Creo que la cosa se calentó, el magnate soltó un órdago diciendo "al que no le guste, ahí tiene la puerta" y el consejo de dirección en bloque decidió verle el farol, se levantó y se fue.

Lo he visto pasar antes, en primera persona, sólo que aquella vez era con un cliente y luego el jefe salió cagándose en todos los panteones porque acababan de perder 50M€ en contratos.

Tras aquello, al magnate no le queda otro remedio que anunciar la disolución del consejo de dirección, porque la alternativa es reconocer que se ha equivocado, quedarse al mando único de la empresa y poner en marcha su plan inmediatamente.

Un detalle importante que se pasa por alto es que, muchas veces, los altos ejecutivos de los consejos de dirección son empleados de la empresa y no inversores: la junta de accionistas nombra a un CEO y a la junta de dirección, pero suelen ser trabajadores de alto nivel, gente con más o menos formación pero que saben (más o menos) cómo funciona la empresa. Su trabajo consiste en traducir lo que los accionistas quieren en algo que se pueda poner en marcha, de modo que eliminar al consejo de dirección es el equivalente empresarial de una decapitación.

Sin ese cortafuegos el magnate ejecuta su plan a su manera, y viendo la secuencia temporal, tengo la impresión de que la única duda que tenía el magnate era el nombre de los departamentos que quería cerrar, que el código se pidió porque no sabía si cerrar algunos de ellos, pero que la decisión estaba tomada hacía tiempo, era inamovible, que sólo faltaba encontrar la forma de ponerla en marcha y que el consejo de dirección se negó a ejecutarla.

También estoy relativamente seguro de que el siguiente movimiento tras disolver la junta de accionistas fue poner esto en marcha, y que se ha tardado en hacer el mínimo tiempo imprescindible, probablemente bajo amenaza. ¿4000 bajas en 3 días? Dudo que la gente de RRHH, IT y Legal de Twitter haya dormido mucho desde el miércoles, y creo que las próximas semanas van a ser las peores de su vida laboral.

Y ahora, ¿qué?

No os voy a mentir, lo que veo no pinta nada bien. Sin ser catastrofista, es posible que hayamos asistido al fin de Twitter como lo conocemos en el peor sentido y de la peor manera posibles.

Twitter siempre ha sido una empresa y, aunque es lógico que quieran ganar dinero (o, al menos, no perderlo) y una reorganización de este calado """""podría""""" (notad el condicional y las comillas) ser necesaria, creo que se ha ejecutado por razones que nada tienen que ver con un plan empresarial, ya que si el plan consistía en reducir el coste operativo para aumentar el margen de beneficios al tiempo que se aumentaban los ingresos con nuevos planes, se ha hecho de la peor manera posible.

En sentido estricto, una empresa no deja de ser un sistema caótico: es muy complicado encontrar una estabilidad que no se altere demasiado por las perturbaciones del día a día, los cambios deben ser pequeños para saltar entre puntos estables y cualquier gran cambio hace que las consecuencias sean impredecibles. Y aunque no mucha gente sería capaz de explicarlo así, cualquiera que se dedique a organización empresarial o trabaje en operaciones de una empresa lo sabe: esos movimientos deben hacerse poco a poco, ya que aunque una reorganización puede ayudar a mejorar el funcionamiento de la empresa, si se hace demasiado rápido el impacto es siempre mayor y peor de lo previsto, que son procesos que no tienen marcha atrás y que hay unos tiempos y plazos que no se pueden ignorar: mandar un portátil cuesta dos días, y no hay nada que se pueda hacer para acelerar eso.

Y este último es un ejemplo mío, de mi trabajo, pero seguro que RRHH tiene los suyos, y Legal, y Desarrollo, y Seguridad...

El problema que como empresa enfrenta Twitter es que ha hecho un cambio monumental en un tiempo casi inapreciable, y predecir las consecuencias a medio plazo es imposible, aunque yo en su lugar iría preparando planes de contingencia, porque con este tipo de cambios o te encumbras o te hundes, sin término medio.

Y no me refiero sólo a la empresa, sino a los usuarios.

Epílogo

Al final me ha quedado un post más de análisis de empresa que de IT, pero cuanto más trabajo, estudio y analizo lo que sé más me doy cuenta de lo interconectado que está todo: ningún departamento es totalmente estanco y conocer una herramienta perfectamente sin tener el contexto en el que se maneja en la empresa tal vez te convierta en un gran técnico, pero a medio plazo trae más problemas que soluciones, y si hubiera que definir lo que hacemos en IT con una frase creo que sería "que la tecnología sea una solución, no un problema".

Por otro lado, quería hacer ver que el trabajo de IT tiene mucho que ver con el funcionamiento normal de una empresa, y que muchas veces los problemas que nos obligan a trabajar de una manera tienen más que ver con limitaciones reales que con problemas tecnológicos.

Al final, la tecnología es una solución a un problema, y por muy brillante que sea, parte de mi profesionalidad como técnico consiste en conocerla lo suficiente para no dejarme cegar por ella y decir que tal vez haya soluciones mejores a los problemas que tengo delante.

Soy técnico de IT, y aunque resuelvo problemas usando tecnología, la parte importante es la de resolver problemas, no la de usar tecnología, porque una vez conoces las soluciones empiezas a mirar las preguntas, y cuando empiezas a entenderlas y a ganar perspectiva empiezas a ver el contexto completo, a ver sus limitaciones y entonces es cuando te das cuenta de que, como Jon Snow, no sabes nada y quieres saber mucho más.

Ya para finalizar, me gusta aprovechar estos post para recordar que en IT, helpdesk, soporte o "informática" hacemos trabajo que no sólo es complicado técnicamente, sino que debemos compaginarlo con otros muchos procesos que no son de informática: cómo gestionar un envío internacional, cómo tratar con un proveedor, a quién y cómo redirigir los problemas que no son nuestros o cómo tratar con un usuario hostil son cosas que nadie te va a enseñar pero que tienes que saber hacer. Y hacerlo bien es todo un arte.

Y con esto llegamos al final del post. Espero que os haya parecido interesante, que hayáis descubierto algo nuevo o que al menos os haya entretenido un rato.

Hasta la próxima vez, sed buena gente, bebed bien de agua y recordad que en una empresa hay que hacerse amigo de cuatro grupos de personas: los seguratas, el personal de cocina, el personal de limpieza... Y la gente de IT.

¡Hasta la próxima!