La fal·làcia LEGO: per què les peces validades no fan un framework validat
He vist prou presentacions de frameworks per saber-me el patró de memòria: cada pràctica individual té recerca que la sustenta, les citacions són bones, i el framework sencer es presenta com la suma de la seva evidència. És estructuralment seductor i sovint fals. El framework integrat pot produir resultats diferents dels que prediu cap dels seus pilars per separat, perquè els pilars interactuen.
El paper recent The Honey Badger Management Framework for Human-AI Hybrid Organizations: A Proxy Validation and Integration Analysis (Fradelos, gener de 2026) fa una cosa que poques vegades veig en aquest àmbit: posa nom explícitament a aquest risc — la fal·làcia LEGO, «composició lineal no sustentada de parts sustentades» — i prova d'afrontar-lo de cara.
Val la pena entendre-ho perquè la fal·làcia LEGO no és exclusiva d'un framework concret. És un patró que es repeteix en totes les metodologies de gestió que s'han venut com a «basades en l'evidència». Reconèixer-lo canvia la manera com avalues qualsevol framework, i també com hauries d'avaluar les metodologies que ja fas servir.
La validació proxy admet allò que no pot demostrar
La validació proxy és una postura evidencial concreta. Diu: no tenim cap estudi longitudinal del framework integrat en una organització real, i per tant no afirmarem que el tenim. El que fem, per a cada pilar del framework, és identificar la base empírica més propera que hi ha a la literatura, classificar la solidesa d'aquesta evidència i assenyalar explícitament les tensions d'integració on l'evidència de cada pilar pot deixar de compondre's.
El paper de l'HBMF aplica aquest mètode a quatre pilars:
- Sprints de 7 dies cancel·lables: avalats per la teoria d'opcions reals i l'economia de la mida de lot. L'evidència és sòlida.
- Competició intraequip governada: la teoria de tornejos prediu efectes sobre l'esforç. L'evidència sobre l'esforç és real, però la de la versió governada (amb governança antisabotatge, rutines d'ajuda, salvaguardes de seguretat psicològica) és contingent. El sabotatge i l'erosió de la cooperació sota competició estan ben documentats; que la governança aconsegueixi mitigar-los depèn molt del context.
- Treball en equip amb IA: la productivitat a escala individual té el suport de RCT recents i estudis de camp. L'evidència a escala d'equip és entre moderada i escassa.
- Coixins de redundància: ben avalats per l'enginyeria de fiabilitat i la psicologia de les organitzacions.
L'enquadrament honest importa més que els resultats concrets. «Aquí l'evidència és sòlida, allà moderada, aquí contingent, allà escassa» és la mena de postura que la majoria de defensors de frameworks eviten, perquè fa el framework més difícil de vendre. Adoptar-la, en canvi, el fa més creïble per a la gent que s'hi hauria de jugar l'organització.
Per què la fal·làcia LEGO és endèmica
Si aquesta fal·làcia reapareix una vegada i una altra és per una raó estructural: qui dissenya frameworks de gestió normalment no pot fer els estudis longitudinals que validarien el framework integrat. Són estudis cars, lents i pobres en contrafactuals. Per això la literatura és plena d'evidència a escala de pilar i va escassa d'evidència a escala d'integració.
Les opcions honestes són limitades:
- Esperar l'evidència longitudinal abans de parlar de validació. Acadèmicament impecable i operativament inútil: els frameworks que esperen la validació completa queden avançats pels que no s'hi esperen.
- Afirmar la validació integrada a partir de l'evidència dels pilars. Això és la fal·làcia LEGO, i porta a prometre més del que les dades permeten.
- Adoptar una postura de validació proxy: classificar l'evidència de cada pilar, assenyalar les tensions d'integració i proposar un pilot mínim per posar a prova el framework integrat.
L'opció 3 és més difícil d'escriure i més fàcil d'avaluar. I resulta que també és més útil per als equips d'enginyeria que han de decidir si adopten el framework, perquè els diu per on és més probable que es trenqui.
Tensions d'integració que cal anomenar pel seu nom
Les tensions d'integració que l'anàlisi de l'HBMF fa aflorar són generals: valen per a qualsevol framework que combini cicles curts, competició interna, augmentació amb IA i redundància. Val la pena entendre-les encara que no adoptis l'HBMF.
Competició vs. seguretat psicològica
La teoria de tornejos prediu més esforç sota competició. Els estudis conductuals també prediuen que la competició erosiona els comportaments d'ajuda, augmenta els incentius per al sabotatge i pot reduir la seguretat psicològica. Aquests dos efectes no són independents: els produeix el mateix mecanisme.
La resposta de governança del framework és el rol de Guru, més sessions diàries d'ajuda obligatòries i una cultura explícitament antisabotatge. Que això funcioni depèn de l'execució. L'enquadrament honest és que aquest pilar és contingent, no validat. Un CTO que avaluï qualsevol enfocament de gestió amb components de competició interna no hauria de donar per fet que la governança en mitiga correctament els efectes secundaris.
Augmentació amb IA vs. aprenentatge d'equip
L'augmentació amb IA a escala individual té evidència sòlida: els estudis aparellats mostren millores de productivitat quan la IA s'aplica a tasques individuals. A escala d'equip, l'evidència és més fina. El mecanisme pel qual els guanys individuals es converteixen en guanys d'equip no està ben establert, i hi ha modes de fallada plausibles: dreceres generades per la IA que es salten l'aprenentatge, pèrdua d'habilitats en les tasques que la IA resol, acumulació asimètrica de capacitats entre membres de l'equip.
La resposta del framework és la transferència estructurada de coneixement (declaració obligatòria de llacunes, sessions diàries d'ajuda, accés a la IA per a tots els rols, direcció inclosa) perquè els guanys individuals continuïn alimentant la capacitat de l'equip. Que això funcioni a escala és una qüestió empírica.
Redundància vs. velocitat
Els coixins de redundància — expertesa solapada, sub-equips duplicats — milloren la resiliència i el ritme d'aprenentatge a canvi de velocitat nominal: estàs «fent dues vegades la mateixa feina». L'enginyeria de fiabilitat avala la part de resiliència. Però la penalització de velocitat és real, i els frameworks que prometen alhora més velocitat i més resiliència han de concretar com es resol aquest compromís.
L'argument és que els efectes d'integració (aprenentatge més ràpid, millor feedback, caigudes més barates) compensen amb escreix la penalització de velocitat nominal. És plausible, però depèn del context. En entorns de poca incertesa i molt de volum, la redundància pot no sortir a compte.
Un pilot que ignora les tensions no valida res
La part més útil del paper de validació proxy, al meu parer, és la proposta d'un pilot mínim: què comptaria de debò com a validació del framework integrat, dit en un llenguatge que qualsevol CTO reconeixeria.
El pilot proposat inclou:
- Mètriques de rendiment d'enginyeria a l'estil DORA: lead time, freqüència de desplegament, taxa d'error en els canvis, MTTR. Són les mètriques de resultat estàndard per a organitzacions d'enginyeria.
- Mesura de la seguretat psicològica: enquestes repetides i validades (p. ex., instruments a l'estil Edmondson) per detectar-ne l'erosió sota estructures competitives.
- Mesura de l'efecte de l'augmentació amb IA: comparar la feina feta amb i sense assistència d'IA, controlant el tipus de tasca i l'experiència de qui la fa.
- Mesura de l'efecte de la redundància: mètriques de caigudes i de recuperació en configuracions de doble equip i d'equip únic.
L'enquadrament és correcte: un pilot que no mesura les tensions d'integració no et pot dir si el framework funciona com a sistema. Un pilot que només mesura velocitat produirà validacions falses positives cada vegada que la competició generi guanys d'esforç a curt termini mentre erosiona la capacitat a llarg termini.
Què implica això per a qualsevol decisió de framework
Tres coses que tot CTO hauria d'endur-se del mètode de validació proxy:
1. L'evidència dels pilars no valida frameworks integrats
Quan et venguin un framework amb citacions, pregunta quines són a escala de pilar i quines a escala d'integració. La majoria seran de pilar. Això no el desqualifica — és l'estat de l'evidència —, però el framework s'hauria de presentar honestament com el que és.
2. Els frameworks fallen a les tensions d'integració
On els frameworks fallen en producció és, normalment, a les tensions d'integració, no als pilars individuals. Un framework capaç de posar nom a les seves pròpies tensions d'integració és més fiable que un que no en sap, perquè les tensions són justament on hauràs d'invertir governança extra.
3. El pilot que fas és la validació que tens
Si adoptes un framework, les dades del teu pilot són tota l'evidència de framework integrat que tindràs. Dissenya'l per mesurar les tensions d'integració, no només els resultats de velocitat. Un pilot que només mesura velocitat no et diu res sobre si el framework és sostenible.
Aquest patró arriba a tots els frameworks que ja fas servir
La postura de validació proxy és vàlida més enllà de la gestió d'equips híbrids. El mateix patró s'aplica a:
- Models de maduresa DevOps: cada pràctica té evidència; la transformació integrada, sovint no.
- Frameworks de desplegament d'IA: les avaluacions de models individuals estan molt treballades; el rendiment integrat dels agents sota distribucions del món real, molt menys.
- Transformacions d'organitzacions d'enginyeria: cada pràctica individual té recerca que la sustenta; la transformació sencera gairebé mai no està validada.
Adoptar internament la postura de validació proxy — dir què està validat a escala de pilar, on hi ha tensió d'integració i què depèn del context — produeix avaluacions de frameworks més honestes i decisions d'adopció més defensables.
Els frameworks que val la pena adoptar són els que saben anomenar les seves pròpies contingències. Els que val la pena evitar són els que prometen beneficis integrats sense posar nom a les tensions d'integració.
Font: Fradelos, G. The Honey Badger Management Framework for Human-AI Hybrid Organizations: A Proxy Validation and Integration Analysis (Ginebra, 6 de gener de 2026). SSRN 6306679.
Si estàs avaluant un framework de gestió per a un equip d'enginyeria híbrid i vols una visió sòbria del que està validat de debò, parla amb un CTO sobre com seria un pilot que valgués la pena fer.
