IT-avdelningen finns för att någon måste översätta. Snart måste ingen.
I tio år har jag försökt bygga verkligt korskompetenta team. Det var aldrig viljan som satte stopp. Det var matematiken.
Räkna efter. Ett team som ska kunna leverera hela vägen utan att fråga någon: utvecklare, test, design. Någon som kan regelverket. Någon som kan kunden. Någon som kan affären och pengarna. Någon som kan processen på riktigt, inte som beskrivning. Data. Säkerhet.
Du landar runt tjugofem personer. Och tjugofem personer är inget team — det är en avdelning med daglig avstämning.
Det bästa försöket jag varit med om var 2019 och tog mindre än två dagar. Alla i ett rum, en enda regel — varje produkt behöver ett team med alla kompetenser som krävs för att lyckas — och ingen chef som bestämde vem som hamnade var. De optimerade för produkterna, inte för sig själva, och varje team gick därifrån med klart för sig varför det fanns.
Och vi gick in ordentligt. Verksamhetens egna översättare — de som kunde både processen och vad den innebar för ett system — hamnade i utvecklingsteamen. Inte som beställare. Som medlemmar.
Det var så långt det gick att gå 2019, och det var en verklig förbättring. Men lägg märke till vad vi faktiskt flyttade in. Vi flyttade in översättaren, inte kompetensen. Juristen satt kvar. Ekonomen satt kvar. Den som ägde processen på riktigt satt kvar. Det som fick plats var en person som kunde tala för dem — och en företrädare för ett omdöme är inte samma sak som omdömet.
Resten blev kvar utanför. Inte av ovilja. Det fanns ingen plats.
Ett första steg, alltså. Och ett bra sådant — det bästa som gick att ta 2019.
Det andra steget har inte varit möjligt förrän nu.
Låt mig vara exakt med vad som går ihop
Tesen är att affären och utvecklingen blir samma team. Inte att IT försvinner.
Det är två olika saker som brukar ligga i samma avdelning och sällan skiljs åt i samtalet. Den ena är utveckling: att göra en avsikt till något som fungerar. Den andra är core IT — nät, identitet, plattform, drift, integration, data i skala, arbetsplatsen, det som alla andra står på.
Det är utvecklingsledet som går ihop med affären. Core IT går inte ihop med någon. Det blir något annat, och jag återkommer till vad.
Det gick inte, av tre skäl
Det blev för dyrt. Tjugofem personer i ett team går att försvara en gång, för den viktigaste produkten. Inte över tjugo team. Ekonomin säger ifrån långt innan ambitionen gör det, och då blir det som alltid blir: ett riktigt korskompetent team, och nitton som får dela på resten via köer.
Det blev personberoende. Den breda täckningen vilade nästan alltid på ett par personer som råkade kunna mer än sitt eget område. Det fungerar — ända tills en av dem byter jobb eller har semester i tre veckor, och då visar det sig att teamet var korskompetent på pappret och genom en människa i praktiken.
Och det tysta skälet: modellen förutsatte en sorts människa. För att sju personer ska täcka allt måste var och en vara ungefär “så här hög” — kunna sitt ordentligt och samtidigt hela tiden plocka upp nästa sak. En del vill det och blomstrar av det. Många vill inte, och de har rätt. De är bra på det de är bra på, och de har ingen skyldighet att bli bredare för att en organisationsmodell kräver det. En modell som bara fungerar med supermänniskor är inte en modell. Det är en önskelista med ett organisationsschema runt.
Och därför hjälper det inte att lägga till folk
Ett team ska vara litet nog att alla i det kan hålla hela sitt ansvar i huvudet. Team Topologies ger begränsningen sitt bästa namn — kognitiv last — och det är ett bättre mått än bemanning, eftersom det mäter det som faktiskt binder.
Ett team på fem som bär fyra orelaterade domäner är tyngre än ett team på nio som bär en sammanhållen förmåga. Att räkna människor säger nästan ingenting. Att räkna hur många skilda saker de måste förstå säger det mesta.
Jag har sett en organisation “lösa” ett överbelastat team genom att sätta in två personer till, vilket gjorde lasten värre — mer samordning, mer sammanhang att hålla i synk, samma domäner kvar. Och sett en annan lösa det genom att flytta ut en enda domän, utan att ändra bemanningen, varefter teamet var synligt snabbare inom en månad.
Så de tre skälen är i själva verket ett: varje ny kompetens i teamet kostade en hel människa, och en människa tar plats i budgeten, i rummet och i allas huvuden.
Det som fattades var inte händerna. Det var omdömet.
Här är den delen jag är säkrast på, eftersom den går att pröva i morgon.
Leta reda på den person teamet ständigt väntar på — den vars bedömning behövs innan något kan kallas klart. Flytta in hen i teamet. Och låt hen sedan avgöra utan att stämma av, vilket är den halva som hoppas över och den halva som betyder något.
Det kommer att kosta någon en person hen anser för värdefull för att bindas upp. Invändningen är äkta och oftast fel. Specialisten som är utspridd på sex team hävstångsutnyttjas inte — hen köas. Den utväxling alla tror att de får är mest andra människor som väntar artigt.
Och när kompetensen verkligen inte går att bädda in — det finns tre av dem och elva team behöver dem — är det ärliga svaret inte en bättre kö. Det är att titta på vad de faktiskt blir tillfrågade om, och hur mycket av det som skulle kunna avgöras en gång, skrivas ner, och sluta vara en fråga.
Håll fast vid den meningen. Den är hela bryggan till det som händer nu.
Därför fanns översättningsledet
Fråga varför gränsen mellan IT och “verksamheten” finns, och du får svar om styrning, standarder och säkerhet. Alla tre är på riktigt. Ingen av dem förklarar varför gränsen uppstod. De växte upp runt den.
Gränsen finns för att det krävdes en ovanlig kompetens för att göra en avsikt till ett fungerande system. Ovanliga kompetenser samlas i en funktion, får en kö och styrs som en leverans. Kravdokumentet, beställningsflödet, prioriteringsforumet, leveransavtalet — och ordet “verksamheten”, använt av människor som jobbar i samma bolag — hänger alla på en enda premiss: att någon måste översätta.
Det är den premissen som håller på att ta slut.
AI tar bort en del av det. Inte allt.
Var noga med vad som faktiskt lättar, för det är här texten annars blir för optimistisk.
Det som lättar är bredden var och en måste bära själv. En del av den tekniska lasten kan bäras av något annat, och det frigör inte främst timmar — det frigör utrymme. Tre saker följer, och alla tre är sådana som fällde försöken förut:
Ekonomin. Samma täckning som krävde tjugofem personer får plats i nio. Ett team av den storleken går att ha på tjugo ställen, inte bara på det viktigaste.
Personberoendet minskar. En del av det som satt i ett huvud finns nu nedskrivet och körbart. Det är inte samma sak som att det försvinner, men skillnaden mellan “vi frågar Maja” och “det står i regeln Maja skrev” är hela skillnaden mellan ett team som fungerar och ett som fungerar när hon är där.
Kravet på supermänniskor sjunker. Man behöver inte längre vara bred för att vara med. Man behöver vara riktigt bra på sitt, och kunna arbeta i ett team där resten finns i rummet — som människa eller som något annat.
Det som inte lättar: omdömet, ägarskapet, ansvaret för utfallet, och viljan att lära sig. En agent gör ingen till jurist. Den gör det möjligt för juristen att sitta i teamet utan att teamet spricker i sömmarna.
Det vi byggde 2019 var en väl vald företrädare per område. Det andra steget är att företrädaren kan bytas mot personen.
Och det är skillnaden mot alla tidigare försök. Det här är inte en bättre idé än den jag hade för tio år sedan. Det är samma idé i en verklighet där den för första gången håller både ekonomiskt och strukturellt — inte bara på en whiteboard i ett rum där alla var överens.
Korsfunktionell inifrån är inte korsfunktionell utifrån
Många team som kallas korsfunktionella är det inåt. De har utvecklare, test och design — och behöver fortfarande fem andra team för att få ut något i verkligheten.
Testet utifrån är hårdare, och det är det enda som märks för någon annan: kan den som behöver något få det av teamet, utan att veta hur teamet är sammansatt?
Var försiktig med svaret. Den lägsta formen av gränssnitt är en person man måste känna — och inifrån känns den som den högsta, eftersom svaret kommer direkt för den som känner henne. Ett team kan se självförsörjande ut ända tills den personen har semester.
De team jag ser klara testet i dag arbetar nästan alltid med rena digitala produkter — och de klarar det trots att de saknar flera av kompetenserna. Det är värt att stanna vid.
De klarar testet för att hela kedjan ligger innanför deras gräns: inget lager, ingen kundtjänst som måste göra sin del, ingen fysisk leverans, ingen annan avdelning mellan beslutet och användaren. Ingenting hindrar dem. Det är inte samma sak som att de har allt de behöver för att avgöra rätt.
Det är skillnaden mellan självförsörjande och rustad. Ett team kan gå från idé till produktion på en vecka och ändå fatta ett beslut om personuppgifter som ingen i rummet kan bedöma, eller sätta ett pris vars konsekvens ingen ser förrän kvartalet stänger. Testet utifrån mäter om någon blir hindrad. Det mäter inte om någon hade kunnat säga ifrån.
Därför är beviset svagare än det ser ut, åt båda hållen. Att korskompetens fungerar där den är lättast att uppnå säger inte att den fungerar i en bank med tvåhundra år av processer, eller i ett bolag vars produkt körs ut med lastbil. Och de som klarar testet i dag gör det delvis genom att ha färre saker att ta hänsyn till, inte genom att ha täckt in dem.
Det är här förändringen biter. För dem som redan klarar testet löser den inte leveransen — den var löst. Den ger plats åt juristen, ekonomen och den som kan processen, alltså den halva som saknades. För alla andra är det tvärtom: hindren är verkliga och en del av dem tar ingen agent bort — en gräns mot något fysiskt, en myndighet, en framförhandlad överenskommelse. Men de går åtminstone att se och prata om. Bristen på plats i huvudet gjorde aldrig det. Den yttrade sig bara som att allt tog längre tid än någon kunde förklara.
Ett team som klarar båda halvorna slutar vara ett utvecklingsteam. Ordet namnger den kompetens som just slutade vara den knappa.
Och core IT, då?
Det här brukar falla bort när någon säger att IT och affären ska gå ihop, och det förtjänar att sägas rakt ut: core IT går inte upp i verksamheten. Det blir en plattform.
Nät, identitet, drift, integration, data i skala, det som allt annat vilar på — och de förmågor där det är dyrt att ha fel. Det förblir specialistarbete länge än, och det blir viktigare snarare än mindre viktigt, av en enkel anledning: när fler bygger mer behövs bättre samordning, inte mer kontroll.
Men relationen byter form. Ett tätt samarbete är dyrt och bör vara tillfälligt. Att konsumera något som en tjänst är billigt och bör vara normalläget så snart saken är stabil nog att ha ett gränssnitt. I friktionstermer: samarbetet är en överlämning man valt att behålla, tjänsten är en överlämning man tagit bort.
Det ger core IT ett annat mått på framgång. Inte hur mycket funktionen levererar, utan hur mycket andra kan göra utan att fråga den. En plattform mäts på vad som blir möjligt utan dess medverkan. En kö mäts på genomströmning, och det är därför en kö aldrig blir en plattform bara av att bli snabbare.
Och räkna med att byggandet sprids. Fler kommer att skapa mer programvara i fler hörn än någon plan förutsätter. En del blir mycket bra. En del blir ett kalkylblads affärslogik på någons laptop, vilket inte är nytt — det går bara fortare nu. Frågan är inte om man ska tillåta det, utan vilka skyddsräcken och gränssnitt som gör det tillräckligt säkert för att vara en bra sak. De tar längre tid att få på plats än verktygen tar att komma in. Det glappet är hela planeringsproblemet, och det är core IT:s uppgift.
Friktionen försvinner inte. Den byter form.
Att ta bort teknisk friktion tar inte bort komplexiteten. Den flyttar — in i ägarskap, in i gränssnitt, in i information, in i beslut.
Ta tre saker AI rimligen skulle snabba upp hos er. Fråga för var och en vem som äger utfallet. Inte vem som kör processen — vem som svarar för om resultatet var något bra.
Där det ger ett namn är acceleration en enkelt god idé. Där det ger en kommitté är läget mer intressant än det ser ut. En kommitté är en ägare, bara en långsammare, där ansvaret delats ut tills det inte är någons i synnerhet. Det kan vara helt rätt. Vad den inte kan är att svara i den takt accelerationen kräver. Gör arbetet tio gånger snabbare och ett månadsforum blir hela systemets klocka.
Samma sak från andra hållet: en agent som når en fråga ingen har avgjort stannar och frågar. En människa gissar och går vidare, och kostnaden dyker upp ett halvår senare.
Exekvering går att delegera. Ägarskap gör det inte.
Och det är här den digitala transformationen tar nästa kliv
Ordet har burits i femton år, mest av program. Startdatum, slutdatum, styrgrupp, avslutsrapport.
Drivet så behandlar en transformation organisationen som en maskin som ska byggas om och lämnas tillbaka — och den tillverkar friktion medan den pågår: egna gränser, egen styrgrupp, egen rapporteringsväg och en överlämning på slutet. Under tiden fortsätter det som skulle förändras att vara vad det alltid var, något levande som aldrig blir färdigt. Och friktionen kommer tillbaka i samma sekund uppmärksamheten flyttar någon annanstans.
Det som händer nu är inte ett program. Det är att grundenheten byter form — och när grundenheten byter form blir strukturen en annan, inte en snabbare version av den gamla.
Enheten blir förmågan, inte systemet och inte funktionen. Det är den enda gränsen som är sammanhållen av sig själv: sakerna innanför hör ihop, så att förstå en hjälper med nästa.
Affären sitter i teamet, inte på andra sidan ett dokument.
Core IT blir en plattform, mätt på vad andra klarar utan den.
Och takten sätts av vad som är avgjort. Inte av hur många utvecklare man har, utan av hur mycket organisationen faktiskt har bestämt och skrivit ner, så att arbete kan utgå från det.
Det öppnar saker som inte gick förut. Ett team som går från idé till något som fungerar inom samma vecka, utan att fråga någon. En mindre organisation som kan bära en förmåga som tidigare krävde en avdelning. Ett organisationsschema som slutar vara verktyget man ritar om när något ska förändras, eftersom förändringen sker inne i teamen i stället för mellan dem.
Det är därför jag tycker att det här är det första riktiga klivet. Inte för att tekniken är imponerande — den är det, men det har den varit förr. Utan för att det är första gången på tio år som något gör den struktur vi hela tiden sagt att vi vill ha möjlig att faktiskt bemanna.
Med en invändning mot ordet som är värd att behålla: det här blir aldrig färdigt. Det påminner mer om att sköta något levande än om att transformera något. Program tar slut. Det här gör inte det — och det är precis därför det är värt att börja med strukturen i stället för med verktygen.
Hur långt bort är det?
Närmare än det låter, och längre bort än tekniken antyder.
Den tekniska delen är i princip här. Den stora mitten — det vanliga byggandet som slukar merparten av utvecklingskapaciteten — flyttar redan till dem som vet varför saken behövs. Komplexa system, integration, data i skala och allt där det är dyrt att ha fel förblir specialistarbete länge än.
Det som avgör takten är inte modellerna. Det är hur mycket organisationen redan har avgjort och skrivit ner, och om ägarskapet ger ett namn när något går fel. Två veckor på den frågan är billigare än piloten, och avsevärt billigare än det artonmånaderssamtal om vem som äger datan som annars följer.
Så: ett par år för dem som gjort grundarbetet. Betydligt längre för dem som tänker köpa sig förbi det.
Hur många är beredda?
Färre än som tror det, och det är inte i första hand en teknisk fråga.
Den svåra delen är inte att lära sig verktygen. Den är vad som händer med en organisation när det inte längre behövs lika många människor och funktioner för att översätta mellan affär och teknik.
En chef vars mandat byggde på att äga den översättningen behöver bygga något annat. Specialister som satt centralt och svarade team efter team kommer närmare arbetet i stället.
Frågan för en teknikchef blir därför inte hur man inför AI. Det är vilken av de två delarna man leder. Den ena går ihop med affären och slutar vara en egen utvecklingsfunktion. Den andra blir core IT: en plattform som gör det möjligt för andra att bygga och förändra utan att fråga varje gång.
Båda behövs, och det är två olika jobb. Få organisationer har börjat prata om dem som två.
Och det är därför jag inte tror att det här i grunden är en AI-fråga. AI förändrar vad som är möjligt. Resten handlar om hur vi organiserar oss när en gammal begränsning försvinner: var gränsen runt ett team går, vilken kompetens som måste finnas innanför den, vem som får avgöra, och vad som ska vara gemensamt.
Det är samma frågor jag försökte förstå när jag skrev Organizational Flow. Då såg jag AI som något som skulle förstärka skiftet.
Nu börjar jag undra om det är större än så.
Kanske är AI det som för första gången gör en organisationsmodell vi pratat om i åratal praktiskt möjlig: små team som faktiskt kan bära hela förmågan, inte bara utvecklingsdelen av den.
Den intressanta frågan är alltså inte hur mycket snabbare vi kan bygga. Det är vad vi gör med organisationen när vi inte längre behöver bygga den runt översättningen.