Pienso en seis meses vista y creo que me va a costar recordar cómo trabajábamos hace un año. No por nostalgia, por extrañeza. Como cuando vuelves a una casa en la que viviste y no reconoces las habitaciones.
Empezó como un experimento sin nombre. Hoy tampoco lo tiene, pero tiene una forma reconocible. En Dcycle, toda la empresa contribuye a la base de código del producto. No solo los ingenieros. Customer Success despliega automatizaciones. Marketing construye sus propios flujos de datos. Ops monta dashboards que antes requerían tres reuniones y un ticket. Nadie les tiene que pedir explícitamente que lo hagan. Simplemente, las herramientas se lo permiten y la curiosidad hace el resto.
Lo que pasó, durante ese experimento, es que la velocidad cambió la cultura. No al revés. No fue que primero diseñamos un manifiesto de autonomía y luego la gente empezó a buildear. Fue que una persona de CS se cansó de esperar dos ciclos para resolver un problema que conocía bien, abrió Claude Code, y lo arregló. Cuando el equipo vio el resultado, nadie preguntó si eso era "su rol". Preguntaron cómo hacerlo.
Ya teníamos el gen de la autonomía dentro, pero las herramientas lo han hecho explotar.
Lo que sí es una decisión consciente es mantenerla. Espero que cada persona en este equipo tenga el reflejo de resolver antes que el de derivar. Si ves un problema y puedes arreglarlo, arréglalo. El permiso ya lo tienes. Si no puedes, aprende lo suficiente para poder la próxima vez. Busca la forma de aprender, si no la encuentras, pide ayuda. Siempre encontrarás una mano amiga cerca.
Tu título ya no describe lo que haces
Hay algo que no se dice lo suficiente sobre lo que ocurre cuando todo el mundo puede construir soluciones: tu título deja de describir exclusivamente lo que haces.
Marina sigue siendo de Customer Success. Pero la semana pasada desplegó un bot que cruza datos de uso con señales de churn y genera alertas en Slack y sugiere acciones. Juan sigue en Finance, pero montó un sistema de reconciliación financiera que antes nos llevaba dos días y ahora, diez minutos. No han dejado de hacer su trabajo. Es que su trabajo ahora incluye diseñar las máquinas que hacen parte de su trabajo.
Sé que esto puede sonar a emprendedor de LinkedIn. Pero vivirlo tiene un sabor muy distinto al de leerlo. Vivirlo se parece más a una desorientación productiva, la sensación de que lo que sabías hacer ya no es suficiente, pero lo que puedes hacer es más que nunca. Que me lo digan a mí.
Managers de uno y de muchos
Lo llamamos "managers de uno y de muchos" y sé que suena raro. Pero captura algo real.
Cada persona en Dcycle gestiona su propio trabajo. Eso es el "de uno". Tienen la autonomía para decidir qué construir, cómo resolver cualquier cosa o cuándo iterar algo. No esperan aprobación para mejorar algo. El sesgo es hacia la acción.
Y cada persona, además, orquesta agentes. Eso es el "de muchos". No en plan ciencia ficción. En plan práctico: diseñan prompts, definen flujos, rompen cosas y las arreglan, supervisan outputs, corrigen errores. Tienen un equipo de agentes que amplifica su capacidad. Pasamos de "hacer" a "diseñar cómo se hace" y después verificar que se ha hecho bien.
El "Agent Manager" no es un nuevo puesto (si lo véis por ahí, desconfiad, es el nuevo 'Director de Innovación'). Es una nueva capa de habilidad que está debajo de todo lo demás. Da igual si eres de CS, de producto o de ventas. Si no sabes orquestar agentes, estás usando un veinte por ciento de tu capacidad e impactando un 10% de lo que podrías.
Esto no es opcional. Espero que todos dediquéis tiempo a aprender a trabajar con agentes. Es la diferencia entre ser alguien que hace tareas y alguien que diseña sistemas. Y aquí, ahora, buscamos lo segundo.
Se acabaron los silos
Y aquí está la consecuencia que menos veía venir: se acabaron los silos funcionales. No porque hagamos un taller de cross-functional collaboration. No porque tengamos un OKR compartido. Se disuelven porque cuando puedes hacer más cosas, inevitablemente tocas más territorio.
La dependencia entre equipos era el pegamento que mantenía los silos en su sitio. Al eliminar la dependencia, los silos pierden su razón de existir. Quedan las personas, que saben cada vez más de todo, y se mueven entre problemas en lugar de moverse entre departamentos.
No hay un comité de innovación. No hay un laboratorio separado del resto. Lo que hay es una bola de nieve que cada persona empuja en una dirección distinta, y el resultado es algo que ninguno de nosotros podría haber diseñado solo. La vanguardia no se planifica. Se descubre, cada día, cuando alguien cruza una frontera que nadie le dijo que podía cruzar.
Lee esa frase otra vez
La semana pasada, nuestro Talent Manager arregló un bug en producción. No se equivocó de profesión. Vio algo roto, aprendió lo suficiente para entenderlo, y lo arregló. Dentro de poco, un developer se sentará a escuchar grabaciones de llamadas a prospects, de una cadencia de prospección que un SDR habrá diseñado de principio a fin, pero no ejecuta él solo. El SDR diseña la estrategia, los agentes la ejecutan, y el developer sigue queriendo entender qué dicen los clientes para mejorar lo que sea que esté construyendo.
Un SDR que diseña pero no ejecuta. Un developer que escucha llamadas de ventas. Un Talent Manager que pushea código. Si lo miras desde la lógica del organigrama, es un desastre. Si lo miras desde la lógica de los resultados, es lo más eficiente que hemos sido nunca.
Esto es lo que pasa cuando dejas de proteger las fronteras entre roles y empiezas a proteger la curiosidad. La bola de nieve crece en todas las direcciones. Y la vanguardia no está adelante. Está en todas partes.
Las tensiones
No quiero pintar esto como un Edén. Tiene sus tensiones.
La más obvia, si todo el mundo puede construir, ¿quién decide qué se construye? La autonomía sin alineación es caos. La respuesta no es menos autonomía sino más visibilidad. Por eso espero algo muy concreto, compartir qué estás construyendo, antes de construirlo. Pensar en voz alta. Publicar antes de perfeccionar. La transparencia no es un nice-to-have. Es lo que hace que la autonomía funcione y no se convierta en anarquía.
Hay una trampa silenciosa en la capacidad de construcción, es muy fácil confundir el output con el outcome. Construir algo que funciona no es lo mismo que resolver algo que importa.
Antes de abrir Claude Code, antes de diseñar el flujo, hay una pregunta que espero que cada uno se haga: ¿qué tiene que ser diferente cuando esto esté hecho? No qué voy a construir, sino qué tiene que haber cambiado. El output es el medio; el outcome es el punto.
Esto no frena la acción: la orienta. Un builder que sabe exactamente qué está intentando cambiar construye más rápido, no más despacio, porque cada decisión tiene un norte claro.
La segunda, la identidad profesional. Si ya no eres "solo de marketing" ni "solo de ops", ¿qué eres? Eso genera incomodidad. Hay personas que encontraban seguridad en la especialización y que ahora sienten que el suelo se mueve. Lo entiendo. Pero espero que abracéis esa incomodidad en lugar de huir de ella. Porque lo que eres es un builder que sabe mucho de marketing. Un learner que domina ops. Tu expertise no desaparece. Se convierte en tu perspectiva, no en tu perímetro. Expandir el perímetro es señal de una buena dirección.
60 personas, 100x más capacidad
Somos las mismas sesenta personas. Pero el output de esta empresa será irreconocible comparado con hace un año. No porque trabajemos más horas. Trabajamos, y trabajaremos, las mismas. Es que cada persona con un equipo de agentes detrás que amplifica todo lo que hace, multiplica su radio de acción por 100. Lo que antes requería dos personas y una semana, ahora lo puede resolver una persona en una tarde. No siempre. Pero cada vez más.
Esto tiene implicaciones enormes para cómo pensamos en crecer. La pregunta ya no es "cuántas personas necesitamos contratar" sino "cuánto podemos amplificar la capacidad de las que ya tenemos". No es un argumento para no contratar. Es un argumento para contratar diferente: personas que sepan orquestar, que aprendan rápido, que se sientan cómodas en la ambigüedad de un rol que cambia cada trimestre. Y espero lo mismo de los que ya estáis aquí, que cada mes seáis capaces de hacer más de lo que podíais hacer el mes anterior. No más horas. Más capacidad.
Builders y learners
Así es como describimos lo que buscamos y como nos aproximamos al trabajo.
Builder porque construyes. No solo piensas, no solo planeas, no solo haces estrategias (mucho menos, pobrepoints). Pones cosas en el mundo. Código, automatizaciones, documentos, sistemas. Cosas que funcionan, que tienen un output, que alguien puede usar mañana. Espero que cada semana, cada persona en este equipo haya puesto algo en el mundo que no existía el lunes.
Learner porque lo que sabes hoy no es suficiente para mañana. Hace seis meses nadie en este equipo sabía orquestar agentes. Hace tres meses alguno lo hacía con dificultad. Hoy empieza a ser el estándar. La velocidad a la que cambian las herramientas, el umbral de lo posible, exige una velocidad equivalente de aprendizaje. No esperes que venga alguien a enseñarte. Ve y aprende. Es más fácil que nunca. El que para de aprender, para. Espero curiosidad incansable. Espero que rompáis cosas por probar. Espero preguntas antes que certezas. Si has aprendido algo nuevo, compártelo, dentro y fuera de Dcycle.
No son dos cosas distintas. Son la misma, construyes para aprender y aprendes para construir.
Mi parte
Todo lo anterior es lo que espero de vosotros. Ahora, mi parte.
Si os pido que construyáis, me comprometo a quitar mierda del camino. Cada proceso que no aporta, cada aprobación que solo existe por inercia, cada reunión que podría ser un mensaje, es mi responsabilidad eliminarlo. Señaladlo cuando lo veáis. Vuestra energía tiene que ir a construir, no a navegar burocracia.
Si os pido que rompáis cosas por probar, me comprometo a que romper cosas no tenga consecuencias. El error de buena fe aquí no se penaliza. Se analiza, se aprende y se sigue. El único error imperdonable es no intentarlo. Si alguna vez sentís que equivocaros tiene un coste político, decídmelo. Porque eso significará que algo se ha roto en la cultura, y arreglarlo será mi prioridad número uno.
Y si os pido que aprendáis constantemente, me comprometo a aprender con vosotros. No desde un despacho. Desde las mismas trincheras. Si yo dejo de buildear, de romper cosas, de hacer preguntas incómodas, tenéis derecho a llamarme la atención. Este pacto funciona en las dos direcciones o no funciona.
Lo más transformador de todo
No sé si dentro de un año seguiremos trabajando exactamente así. Probablemente no. Probablemente habremos descubierto problemas que ahora no vemos, y habremos inventado soluciones que ahora no imaginamos.
Y eso, creo, es lo más transformador de todo. No la tecnología. No los agentes. No el código. Es la mentalidad de alguien que deja de esperar y empieza a resolver. De alguien que ve un problema y, en lugar de derivar, construye. Eso es lo que espero de cada persona en esta empresa. Ni más, ni menos.
Así es como trabajamos en Dcycle. Builders. Learners. Managers de uno y de muchos. Y el camino se sigue haciendo al andar.
J.
