Surrounded by Idiots: Insights del libro para Líderes Técnicos

Si eres CTO de una startup, seguramente has vivido esta escena. Tienes un backend senior brillante, una persona de producto con criterio y un founder que empuja con urgencia real. Nadie es mediocre, pero las reuniones acaban con tensión, los PRs se eternizan y cada decisión parece una pelea de idioma más que de ingeniería.

‍

Por eso surrounded by idiots conecta tanto con líderes técnicos. No porque tu equipo esté lleno de idiotas, sino porque muchas fricciones parecen irracionales hasta que entiendes que cada persona procesa el trabajo, el riesgo y la comunicación de forma distinta. El problema empieza cuando intentas resolver eso solo con intuición.

‍

Por qué tu equipo técnico parece 'rodeado de idiotas'

‍

En una startup española típica, el choque no suele venir de falta de talento. Viene de expectativas incompatibles sobre cómo debe trabajar un equipo serio. El ingeniero de datos quiere contexto, definición y precisión. El fundador quiere una respuesta hoy. El tech lead pide refactor antes de escalar. Ventas promete una fecha que nadie validó.

‍

Ese desfase tiene coste. En el ecosistema tecnológico, el 67% de los CTOs reportan que los conflictos de comunicación son la principal barrera para la retención de talento, según este resumen con datos citados sobre Rodeados de idiotas en España. En ese mismo contexto, el libro de Thomas Erikson ha vendido más de 150.000 unidades en España hasta 2023, lo que explica por qué el modelo se ha colado en conversaciones de liderazgo, management y hiring.

‍

No me interesa ese dato por popularidad editorial. Me interesa porque refleja algo que veo continuamente: muchos equipos confunden fricción de estilo con bajo rendimiento, y otras veces hacen lo contrario. Ahí es donde el modelo puede ayudar, siempre que no lo conviertas en dogma.

‍

El patrón que más se repite en startups

‍

El perfil analítico interpreta la urgencia como caos. El perfil dominante interpreta la cautela como bloqueo. El estable evita la confrontación hasta que el problema ya es grande. El influyente vende una visión que luego el equipo tiene que aterrizar con dolor.

‍

Si en tu equipo la misma discusión aparece cada semana con personas distintas, no tienes un problema individual. Tienes un patrón de comunicación.

‍

Ese patrón afecta hiring, onboarding y gestión diaria. También afecta cómo defines lo que realmente es cultura empresarial en una startup tech. No como una lista de valores en Notion, sino como la suma de conductas que toleras, premias o corriges.

‍

Lo útil del libro y lo que no compro

‍

Lo útil de surrounded by idiots es que convierte un problema difuso en un lenguaje operativo. Te da una forma sencilla de leer comportamientos sin meterte en teoría psicológica interminable.

‍

Lo que no compro es la lectura simplista. Nadie es solo un color. Y en equipos técnicos, una misma persona puede comportarse de forma muy distinta en un incidente de producción, una planning o una negociación de roadmap.

‍

El modelo DISC explicado para equipos de tecnología

El valor del modelo DISC está en su simplicidad. No pretende describir toda la personalidad de una persona. Sirve para leer cómo suele actuar bajo presión, cómo decide y qué tipo de comunicación le hace rendir mejor.

‍

Rojo

‍

El Rojo prioriza resultado, velocidad y control.

‍

En tecnología, lo ves mucho en founders, CTOs de etapa inicial, responsables de entrega y perfiles que disfrutan desbloqueando decisiones. Suelen cortar discusiones largas, toleran bien la ambigüedad y prefieren una respuesta imperfecta hoy que una respuesta perfecta la semana que viene.

‍

Señales habituales:

• Habla en términos de prioridad. Qué sale, qué se retrasa, qué desbloquea negocio.
• Tolera mal la fricción burocrática. Le desesperan los procesos sin impacto visible.
• Decide rápido. A veces demasiado rápido.

‍

Su riesgo no es la falta de empuje. Es atropellar matices técnicos importantes.

‍

Amarillo

‍

El Amarillo mueve ideas, relaciones y entusiasmo.

‍

En una startup tech aparece en perfiles de product evangelism, growth, developer relations, pre-sales técnico o gente muy fuerte conectando equipos. Es quien convierte algo complejo en una narrativa comprensible y contagia energía cuando el proyecto está verde.

‍

Suele aportar mucho cuando hay que abrir caminos, explicar visión o alinear a varias áreas.

‍

• Conecta personas con facilidad.
• Piensa en posibilidades antes que en restricciones.
• Improvisa mejor que documenta.

‍

Su riesgo es obvio. Prometer antes de validar. En hiring, impresiona mucho en entrevista y por eso conviene no sobrevalorar carisma frente a ejecución.

‍

Verde

‍

El Verde busca estabilidad, colaboración y continuidad.

‍

En entornos técnicos encaja con perfiles que sostienen operación, soporte especializado, MLOps, platform engineering o personas que cuidan la salud del equipo además del sistema. No suelen hacer ruido, pero son quienes evitan que todo se rompa por fatiga o desorden.

‍

Señales típicas:

• Escucha antes de posicionarse.
• Valora la previsibilidad. Cambios constantes sin contexto le desgastan.
• Trabaja bien con rituales claros.

‍

Su riesgo no es falta de criterio. Es ceder demasiado y decir tarde que algo no funciona.

‍

Azul

‍

El Azul prioriza precisión, lógica y consistencia.

‍

En tecnología lo ves mucho en data, ciberseguridad, arquitectura, QA exigente y perfiles de ingeniería muy orientados a detalle. Pregunta por supuestos, edge cases, criterios de aceptación, benchmarking y trazabilidad. Si el resto del equipo va deprisa, puede parecer “lento”. Muchas veces no lo es. Está evitando errores caros.

‍

• Necesita claridad antes de comprometerse.
• Se comunica con rigor.
• Detecta fallos que otros pasan por alto.

‍

Regla práctica: cuando un Azul te hace muchas preguntas, no siempre está bloqueando. A menudo está calculando el coste de una mala decisión que otro ya ha dado por cerrada.

‍

En equipos tech, lo importante no es etiquetar. Es entender qué mezcla tienes y en qué momentos esa mezcla te ayuda o te rompe.

‍

Los peligros de usar DISC como excusa en el hiring

‍

El mayor error que veo con DISC es este: usarlo para explicar un mal proceso de selección. El lenguaje del modelo es tan cómodo que permite justificar casi cualquier fallo con una frase elegante. “No encajó por estilo”. “Era demasiado azul”. “Necesitábamos a alguien más rojo”. Suena sofisticado. A veces es una mala diagnosis.

En el sector tech español, el 42% de las desvinculaciones en los primeros 6 meses se atribuyen a “conflicto cultural”, pero un análisis más profundo revela a menudo gaps de competencia técnica no detectados durante el proceso de selección, según el dato recogido en esta referencia sobre desvinculaciones y conflicto cultural.

‍

Cuando el problema no era de personalidad

‍

Pasa mucho en roles senior. Un candidato comunica con seguridad, cae bien al founder y parece “encajar” por energía. Entra. Tres meses después no domina arquitectura distribuida, no baja a detalle en observabilidad o no sabe priorizar deuda técnica en un sistema real. Entonces aparece el diagnóstico cómodo: “no se adaptó al equipo”.

‍

No. A veces no se adaptó porque no tenía el nivel.

‍

También ocurre al revés. Un candidato muy metódico, más seco en entrevista, genera poca química inicial. El panel lo percibe como rígido o poco inspirador. Luego descubres que era quien mejor estructuraba decisiones, documentaba trade-offs y evitaba errores de diseño.

‍

Lo que DISC sí puede hacer

‍

Usado con criterio, DISC ayuda a anticipar fricciones reales:

• Comunicación con stakeholders. Un perfil muy analítico puede sufrir si el rol exige vender internamente ideas de forma continua.
• Entorno de trabajo. Una persona que necesita orden y profundidad sufrirá en una startup que vive en cambio constante.
• Tipo de liderazgo. No todo el mundo rinde bien con un manager muy controlador o muy ausente.

‍

Eso es valioso. Pero no reemplaza una evaluación seria de sistema, código, criterio y nivel de autonomía.

‍

Un test de estilo no corrige una mala definición del puesto, una entrevista técnica débil ni una scorecard mal diseñada.

‍

La pregunta que un CTO debería hacerse

‍

Antes de decir “falta de fit”, conviene revisar tres cosas:

• El rol estaba bien definido. Seniority, contexto y expectativas eran explícitos.
• La evaluación técnica fue exigente. No solo conversación agradable, sino evidencia de capacidad.
• El onboarding fue razonable. Hubo contexto, documentación y acceso suficiente para rendir.

‍

Si fallas en una de esas tres, DISC puede convertirse en coartada. Y una coartada cara.

‍

Guía práctica para contratar perfiles técnicos con DISC

‍

DISC funciona mejor como una capa de lectura sobre un proceso de hiring ya sólido. No empieza con un test. Empieza con una pregunta incómoda: qué comportamiento necesita realmente este puesto para rendir en tu contexto.

Según esta referencia sobre DISC en selección para reducir mismatches, integrar un assessment DISC en el proceso de selección puede reducir los mismatches de contratación en un 35-40%, ahorrando a las scaleups hasta 50.000€ por contratación fallida en roles senior como Backend. La palabra clave no es “assessment”. Es “integrar”. Como complemento.

‍

Empieza por el contexto del puesto

‍

No contrates “un senior backend”. Contrata para una realidad concreta.

‍

Un backend para una fintech regulada no necesita la misma mezcla que un backend para una startup de producto que cambia prioridades cada semana. El primero quizá necesita más rigor, paciencia y gusto por el detalle. El segundo puede requerir más velocidad, tolerancia al caos y comunicación transversal.

‍

Si no defines ese contexto, DISC se vuelve decorativo.

‍

Qué mirar antes de la primera llamada

‍

CV, LinkedIn y GitHub no revelan personalidad de forma exacta, pero sí dejan pistas de estilo de trabajo.

‍

• En LinkedIn. Un perfil que explica impacto con claridad, habla de liderazgo de proyectos y toma posición suele comunicar de forma más directa. Uno que detalla certificaciones, stack, alcance técnico y decisiones concretas suele mostrar un patrón más analítico.
• En GitHub. Repos muy ordenados, documentación cuidadosa, commits consistentes y foco técnico claro suelen apuntar a disciplina y profundidad. Muchos experimentos variados, demos y proyectos exploratorios pueden reflejar curiosidad e iniciativa más visible.
• En el CV. Fíjate en cómo cuenta la experiencia. Hay quien enumera herramientas. Hay quien explica problemas, decisiones y resultados. Eso ya te dice mucho sobre cómo piensa y cómo se vende.

‍

Cómo usar la primera entrevista

‍

La primera llamada no debería intentar “adivinar el color”. Debería detectar cómo se comunica la persona cuando no tiene tiempo para ensayar.

‍

Haz preguntas que obliguen a priorizar, explicar incertidumbre y describir colaboración real. Observa más el cómo que el qué en esta fase. Interrupciones, nivel de concreción, necesidad de contexto, tolerancia a preguntas ambiguas, capacidad de síntesis.

‍

Criterio útil: si el estilo del candidato te irrita, no decidas todavía. Pregúntate si te irrita porque choca con tu preferencia personal o porque realmente haría daño al rol.

‍

Un checklist simple para usar DISC sin estropear el proceso

‍

• Define el entorno. Caos, regulación, velocidad, dependencia de negocio, trabajo remoto.
• Aísla las competencias críticas. Arquitectura, debugging, ownership, comunicación con producto, mentoring.
• Usa una entrevista estructurada. Si no comparas respuestas con el mismo marco, solo premiarás afinidad. Esta diferencia entre aptitud y actitud en selección importa más de lo que parece.
• Añade DISC al final, no al principio. Primero valida si puede hacer el trabajo.
• Comparte hallazgos con el panel. No uses etiquetas cerradas. Habla de patrones observables.

‍

Si haces esto bien, DISC aporta contexto. Si lo haces mal, mete sesgo.

‍

Preguntas de entrevista para cada tipo de perfil

‍

Muchas entrevistas técnicas fallan por una razón simple. El panel hace preguntas correctas para el contenido técnico, pero incorrectas para el estilo de la persona. Entonces interpreta respuestas pobres donde en realidad había desajuste en el formato.

‍

En hubs como Cataluña, el 37% de los procesos para Machine Learning Engineers se alargan más de 45 días por malentendidos en entrevistas. Además, Typeform reporta una mejora del 40% en hire velocity, de 60 a 36 días, tras implementar entrevistas adaptadas al modelo DISC, según esta referencia sobre entrevistas adaptadas al modelo DISC.

‍

Para perfiles con rasgos rojos

‍

Aquí conviene medir decisión y criterio, no solo velocidad verbal.

‍

Preguntas útiles:

• Priorización bajo presión. “Tienes dos incidencias críticas y una release comprometida con cliente. ¿Qué paras, qué delegas y qué comunicas en la primera hora?”
• Trade-offs reales. “Cuéntame una ocasión en la que aceptaste deuda técnica para llegar a una fecha. ¿Qué riesgo asumiste conscientemente?”
• Gestión de conflicto. “¿Qué haces cuando un principal engineer discrepa de tu decisión y el reloj corre?”

‍

Con estos perfiles, escucha si distinguen entre rapidez y temeridad. Un buen Rojo no atropella. Decide con criterio y asume coste.

‍

Para perfiles con rasgos azules

‍

Aquí no basta con preguntar “háblame de tu experiencia”. Necesitan un problema bien definido para mostrar nivel.

‍

Prueba con cuestiones como estas:

• Debugging estructurado. “La latencia sube de forma intermitente en producción. No tienes una causa obvia. ¿Cómo acotas hipótesis?”
• Rigor técnico. “Explícame qué señales revisarías antes de aprobar una migración delicada de base de datos.”
• Calidad de decisión. “¿Cuándo rechazarías una solución aparentemente válida por falta de evidencia?”

‍

Su mejor respuesta no siempre será la más corta. Valora orden mental, precisión y capacidad para separar hechos de supuestos.

‍

Una entrevista buena no premia al que habla más. Premia al que piensa mejor para el trabajo concreto que tienes que cubrir.

‍

Para perfiles con rasgos verdes

‍

Si el rol exige colaboración, soporte entre equipos o trabajo sostenido en remoto, este bloque es decisivo.

‍

Preguntas recomendables:

• Cooperación. “Describe una situación en la que dos seniors estaban bloqueados por un desacuerdo técnico. ¿Cómo ayudaste a mover la decisión?”
• Cambio. “Tu roadmap cambia dos veces en un sprint. ¿Qué necesitas del manager para seguir rindiendo bien?”
• Mantenimiento invisible. “Háblame de una mejora que nadie celebró, pero que evitó problemas durante meses.”

‍

Aquí buscas constancia, madurez relacional y capacidad de sostener sistemas y equipo sin protagonismo innecesario.

‍

Para perfiles con rasgos amarillos

‍

Son perfiles que pueden abrir mucho valor, pero también vender demasiado en entrevista si no estructuras bien.

‍

Preguntas útiles:

• Creatividad con límite. “Si te damos acceso a nuestra API este fin de semana, ¿qué construirías y cómo decidirías si merece seguir?”
• Aterrizaje. “Dame un ejemplo de una idea brillante que descartaste porque la ejecución no compensaba.”
• Influencia interna. “¿Cómo convences a ingeniería de probar algo nuevo sin generar rechazo?”

‍

Si quieres estandarizar este trabajo, una entrevista estructurada con ejemplos prácticos ayuda mucho más que improvisar preguntas según sensaciones del momento.

‍

Cómo hacer el onboarding de cada 'color' en tu equipo

‍

Contratar bien y perder a la persona en las primeras semanas sigue siendo un fallo de hiring. Solo ocurre más tarde. DISC puede ser especialmente útil aquí porque te ayuda a adaptar contexto, ritmo y comunicación sin tratar a todo el mundo igual.

Según esta referencia sobre productividad remota y uso de DISC, empresas tecnológicas que aplican activamente el modelo DISC en la gestión de equipos reportan una mejora del 34% en la productividad de sus equipos remotos, un dato alineado con el 76% de implementación del teletrabajo en pymes digitales en España.

‍

Qué necesita cada perfil al entrar

‍

No hace falta teatralizar el onboarding. Hace falta personalizar lo justo.

‍

• Rojo. Dale un objetivo visible desde el primer día. Necesita saber qué resultado importa, qué margen tiene y qué decisiones puede tomar sin pedir permiso.
• Azul. Entrégale documentación, arquitectura, accesos y criterios de calidad. Si le ocultas contexto, no se integrará más rápido. Solo trabajará con más fricción.
• Verde. Preséntale al equipo con intención. Un buddy serio, expectativas claras y rituales consistentes le ayudan más que una bienvenida muy ruidosa.
• Amarillo. Dale espacios para conectar, preguntar y aportar ideas sin convertir eso en dispersión. Necesita vínculo, pero también límites concretos.

‍

Lo que suele funcionar en remoto

‍

En equipos distribuidos, el onboarding falla cuando todo depende de mensajes sueltos en Slack y reuniones improvisadas. Conviene definir un mínimo operativo: qué leer, con quién reunirse, qué ticket o proyecto valida que la persona ya está dentro del sistema.

‍

Un recurso interesante fuera del mundo tech es esta guía para recibir clientes de entrenamiento online. Aunque está pensada para otro contexto, acierta en algo muy útil para cualquier onboarding: secuenciar expectativas, hitos y puntos de contacto para que la experiencia no dependa del azar.

‍

El onboarding no consiste en “dar la bienvenida”. Consiste en reducir incertidumbre y acelerar confianza operativa.

‍

Un criterio simple para los primeros 90 días

‍

No midas solo output. Mide adaptación al entorno.

‍

Un Rojo sin autonomía se frustrará. Un Azul sin contexto se bloqueará. Un Verde sin relaciones claras se aislará. Un Amarillo sin dirección se dispersará. Si entiendes eso, corriges mucho antes de que el problema se convierta en rotación.

‍

Conclusión: Una herramienta, no una religión

‍

Surrounded by idiots sirve porque pone nombre a fricciones que cualquier CTO reconoce al instante. Te ayuda a leer mejor a candidatos, ordenar entrevistas y evitar parte del desgaste absurdo que aparece cuando perfiles muy distintos trabajan bajo presión.

‍

Pero el modelo tiene un límite claro. DISC explica estilos de comportamiento. No demuestra competencia técnica, seniority real ni capacidad de ejecución. Cuando se usa bien, mejora la comunicación y reduce errores de encaje. Cuando se usa mal, tapa una mala definición del puesto, una entrevista floja o una decisión tomada por intuición.

‍

Mi recomendación es simple. Usa DISC para entender cómo trabajará alguien dentro de tu equipo. No lo uses para decidir si esa persona sabe hacer el trabajo. Primero valida nivel. Luego valida contexto. Después, y solo después, usa el modelo para afinar la compatibilidad.

‍

Ahí es donde deja de ser psicología pop y se convierte en herramienta de management.

‍

Si estás contratando engineers, perfiles AI/ML, DevOps, data o ciberseguridad en España y quieres estructurar un proceso de selección serio, puedes hablar con Kulturo. Trabajan con startups y scaleups que necesitan contratar bien, sin confundir carisma con nivel técnico ni “fit cultural” con improvisación.