Cuando todo depende de una persona: capacidad técnica sin montar un departamento

Un departamento técnico externo es un equipo que mantiene y evoluciona los sistemas de tu negocio de forma continua, con una capacidad mensual acordada y documentando todo lo que toca. Es la alternativa a que la operación dependa de una sola persona o a contratar un departamento completo que quizá todavía no puedes llenar ni dirigir.

Casi todos los negocios digitales que crecen pasan por la misma fase. Alguien del equipo, o un freelance de confianza, montó las primeras automatizaciones. Conectó los formularios con el CRM, preparó los avisos por WhatsApp, configuró el tracking y resolvió los problemas de los lanzamientos a base de horas y buena voluntad. Funcionó. Y ahora esa persona es la única que sabe cómo funciona casi todo.

No escribo esto contra esa persona. Suele ser la más valiosa del equipo técnico. Lo escribo porque esa situación es un riesgo operativo que casi nadie trata como tal hasta que se materializa.

¿Por qué es un problema que todo dependa de una persona?

Porque el conocimiento no está en el sistema, está en una cabeza. Mientras esa persona está disponible, todo parece ir bien. El problema aparece en tres momentos previsibles:

• Cuando no está. Vacaciones, enfermedad, otro proyecto, un cambio de trabajo. Una integración falla un viernes y nadie más sabe dónde mirar.
• Cuando sube el volumen. Esa persona pasa de construir a apagar fuegos. Las mejoras se aplazan y la operación empieza a acumular parches.
• Cuando hay que cambiar algo. Nadie conoce el impacto de tocar un flujo, así que o no se toca o se toca con miedo. Las dos opciones frenan el negocio.

Imagina una academia online con un lanzamiento programado. Las credenciales de la plataforma de email están en la cuenta personal del freelance que lo montó, los webhooks apuntan a un escenario de Make que solo él entiende y el reparto de leads vive en una fórmula de una hoja de cálculo. Nada de esto es raro. Tampoco es un sistema: es una operación que funciona mientras una persona concreta esté atenta.

¿Cómo sé si mi negocio tiene este problema?

Hazte estas preguntas con honestidad:

• Si mañana la persona que montó las automatizaciones desaparece, ¿cuánto tardaríais en entender qué hace cada una?
• ¿Las credenciales de las herramientas críticas están en cuentas de la empresa o en cuentas personales?
• ¿Existe un documento que explique qué integración mueve qué dato y hacia dónde?
• ¿Cuando algo falla, lo detecta un sistema o lo detecta un cliente?
• ¿Hay tareas que se aplazan porque “solo él sabe hacerlo”?

Si más de una respuesta te incomoda, el riesgo ya existe. La buena noticia es que se reduce con trabajo ordenado, no con una reestructuración.

¿Contrato a alguien, busco un freelance o trabajo con un partner?

Es la duda lógica en este punto, y la respuesta honesta es que depende de dos cosas: cuánto trabajo técnico continuo tienes y si alguien en tu empresa puede dirigirlo.

Contratar en plantilla es buena idea cuando hay trabajo para llenar el puesto y alguien capaz de priorizar, revisar calidad y tomar decisiones de arquitectura. Si no existe esa figura, la persona contratada acaba sola tomando decisiones que afectan a todo el negocio. Has cambiado un freelance del que dependes por un empleado del que dependes.

El freelance funciona muy bien para trabajos con principio y final. Funciona peor cuando se convierte, sin que nadie lo decida, en el responsable de toda la operación técnica.

La agencia suele resolver un proyecto concreto. El problema es lo que pasa después: ¿quién mantiene lo entregado, quién responde cuando falla, quién lo evoluciona?

Un partner tecnológico cubre arquitectura, implementación, despliegue, monitorización, mantenimiento y evolución. No es la opción correcta para todo el mundo. Es la adecuada cuando tu operación necesita capacidad técnica de varias especialidades pero no llena ni puede dirigir un departamento propio.

¿Qué tiene que exigir mi negocio a quien lleve la parte técnica?

Da igual si es una persona interna, un freelance o un proveedor. Estos mínimos no son negociables, y son los mismos que aplicamos en FCG Systems a cualquier proyecto:

Documentación que sobreviva a quien la escribió

Cada sistema recurrente debe tener arquitectura, instrucciones operativas, checklist y una definición de terminado. No hace falta una enciclopedia. Hace falta que otra persona competente pueda entender qué hace cada pieza sin preguntar.

Credenciales en cuentas de la empresa

Las herramientas críticas se contratan a nombre del negocio. Las contraseñas se gestionan en un gestor de contraseñas, nunca en un documento compartido, un chat o un Markdown. Si hoy no sabes dónde están tus credenciales, ese es el primer punto a resolver.

Ownership claro de cada pieza

Para cada integración, cada automatización y cada servidor debe haber un responsable con nombre. Ownership no significa que esa persona lo haga todo: significa que responde de que funcione.

Logs y avisos

Un proceso crítico sin logs no está terminado. Si una automatización falla y nadie recibe un aviso, el sistema depende de que alguien lo revise a mano, que es otra forma de depender de una persona. Lo desarrollo en el artículo sobre automatizaciones que fallan en silencio.

Backups probados

Si un dato no puede reconstruirse, necesita backup. Y un backup que nunca se ha restaurado es una suposición, no una garantía.

Cambios con proceso

Los cambios en producción se validan antes. Lo que queda fuera del alcance se registra, se estima, se aprueba y después se ejecuta. Absorber continuamente cambios “pequeños” sin registrarlos es cómo un sistema ordenado vuelve a convertirse en un conjunto de parches.

¿Por qué desconfío de quien ofrece “todo lo que necesites”?

Porque no es verdad y porque impide priorizar. Ningún equipo tiene capacidad infinita. Cuando un proveedor promete todo, en la práctica atiende lo que más ruido hace, no lo que más importa.

Lo que funciona es lo contrario: una capacidad mensual explícita. Sabes cuánto trabajo cabe cada mes y decides con tu proveedor qué va primero: una incidencia crítica, una mejora del proceso comercial o la preparación del próximo lanzamiento. Esa conversación obliga a ordenar prioridades, y esa es buena parte del valor.

En FCG Systems el formato Technology Partner se organiza así, en tres planes:

• Core: mantenimiento y mejoras pequeñas.
• Growth: desarrollo continuo y nuevos sistemas.
• Scale: partnership tecnológico completo.

Tampoco prometemos soporte instantáneo por defecto. Las incidencias se clasifican por gravedad (sistema crítico caído, función importante degradada, bug no crítico, mejora) y la respuesta depende del plan acordado. Prefiero decir esto claro al principio que descubrirlo en mitad de un lanzamiento.

¿Cómo se sale de la dependencia sin romper nada?

No hace falta despedir a nadie ni rehacer la operación. El orden que recomiendo es este:

1. Inventario. Qué herramientas hay, qué integraciones las conectan, dónde están las credenciales y quién toca qué. Es la base de la arquitectura de sistemas.
2. Documentación mientras la relación sigue activa. Si la persona que montó todo sigue disponible, es el mejor momento para escribir cómo funciona. Hacerlo después, a partir de ingeniería inversa, es mucho más lento.
3. Fuentes de verdad. Decidir qué herramienta manda para contactos, ventas, pagos y accesos. Mucha dependencia nace de que solo una persona sabe dónde está el dato bueno. En la parte comercial esa herramienta suele ser el CRM, y qué debe sostener exactamente conviene decidirlo antes de elegir producto.
4. Logs y avisos en lo crítico. Que los fallos los detecte el sistema, no alguien que se acuerda de mirar.
5. Repartir ownership. Cada pieza con un responsable, sea interno o externo.
6. Decidir el modelo. Con el mapa hecho, ya puedes valorar con datos si necesitas contratar, mantener al freelance para tareas acotadas o trabajar con un departamento técnico externo.

Un Systems Audit de 5 a 10 días laborables cubre los tres primeros puntos y termina con un roadmap de 90 días. Si quieres ver cómo encaja todo esto dentro de la operación completa, la guía de sistemas para negocios digitales explica las capas y por dónde empezar.

Checklist para reducir la dependencia de una persona

• Las herramientas críticas están contratadas a nombre de la empresa.
• Las credenciales viven en un gestor de contraseñas con acceso de al menos dos personas.
• Existe un mapa de integraciones actualizado.
• Cada automatización crítica tiene logs y un aviso cuando falla.
• Hay instrucciones operativas para las tareas recurrentes.
• Cada pieza del sistema tiene un responsable con nombre.
• Los backups de datos no reconstruibles se han restaurado al menos una vez.
• Los cambios en producción se validan antes de aplicarse.
• La capacidad técnica mensual está definida, sea interna o externa.
• Alguien que no montó el sistema podría explicar qué hace cada flujo.

¿Qué parte de vuestra operación solo sabe tocar una persona?

La dependencia de una persona no se arregla con más horas de esa persona. Se arregla convirtiendo su conocimiento en sistema: documentación, fuentes de verdad, logs y responsables claros. A partir de ahí, decidir si contratar o trabajar con un partner es una decisión de negocio, no una urgencia.

Si te has reconocido en este artículo, cuéntame qué proceso os está frenando y quién lo sostiene hoy. Te respondo con una primera lectura de dónde está el riesgo y qué haría primero. Si quieres saber quién hay detrás de FCG Systems, lo tienes en la página de empresa.