.svg)
Intervjuserien Strategy Pattern avslöjar hur teknikledare fattar kritiska beslut i komplexa, föränderliga miljöer. Med utgångspunkt i verkliga exempel och repeterbara ramverk ger den handlingsbara insikter för att förutse utmaningar och vägleda organisationer med förtroende. Du kan läsa mer och se andra intervjuer i serien här.
David Linten, CTO för TrustPortal, stod inför en utmaning som så småningom konfronterar varje teknikledare. Hans team hade samarbetat med EY och vunnit Telefónica-kontraktet för att leda det som vid den tiden var en av de största implementeringarna av robotprocessautomatisering i världen. Vad de ännu inte hade var ett systematiskt tillvägagångssätt för de strukturella misslyckanden som skulle börja ackumuleras nästan omedelbart efter att arbetet startade.
Sprint-tidslinjer vägrade att synkronisera. Omfattningen smög sig när klienten arbetade runt problem snarare än att lösa dem. Nyckelpersoner lämnade och tog kritisk kunskap med sig. Sedan släppte robotprogramvaran en versionsuppdatering som bröt varje automatiserad process teamet hade byggt, och kunskapen som behövdes för att fixa det satt inne i en partnerorganisation med ett inkompatibelt sätt att arbeta. Varje kontrollpunkt var ett avtalsenligt åtagande som Telefónica redan hade gjort gentemot sina egna kunder. Att sakna en var inte ett leveransbesvär. Det var ett kaskadmässigt kommersiellt misslyckande.
Det som gör Lintens erfarenhet värd att undersöka är inte att han levererade programmet. Det är så att vägen dit var ostrukturerad, kostsam och upprepade gånger bruten innan ett systematiskt tillvägagångssätt uppstod. Detta är en redogörelse för den resan och ramverket han byggde utifrån den.
TrustPortal grundades 2017 av Chris Lamberton, och två andra, och Chris fungerar nu som strategisk rådgivare. David Linten började som CTO och tog med sig en bakgrund som flyttade från fysik till programvaruteknik.
TrustPortals kärnförslag har utvecklats från integrering av robotisk processautomation (RPA) till vad företaget nu beskriver som realtidsagent HyperAutomation: orkestrering av människor, AI-agenter och äldre system samtidigt för att leverera komplexa arbetsflöden på några sekunder, utan att ersätta befintlig infrastruktur. Dess plattform är betrodd inom bank, försäkring, verktyg och telekom, med kunder inklusive Telefónica, EDF, IBM, OVO Energy och andra.
En av dess flaggskeppsinstallationer förblir transformering av kontaktcenter, där TrustPortals plattform visar ett ”generativt användargränssnitt” i realtid som skapar guidade arbetsflöden för rådgivare, eliminerar systemhopping, minskar omnyckning och slutför resultat på samtalet snarare än i en uppföljningskö.
Företaget arbetar över hela leveransstacken, från back-end banksystem till front-end kundgränssnitt, och har byggt ett hållbart leveranspartnerskap med Imaginary Cloud som sträcker sig över elva år.
Från början var Lintens filosofi: han arbetar inte med utvecklare, han föredrar att kalla dem ingenjörer, och skillnaden är viktig för honom. En utvecklare skriver kod. En ingenjör förstår arkitektur. ”Vi anställer inte utvecklare”, säger han. ” Vi anställer ingenjörer. Alla har sin hand i arkitekturen ända ner till att faktiskt skriva kodrader.
Den filosofin formade varje beslut han fattade om Telefónica-programmet, inklusive de som han önskar att han hade fattat tidigare.
Telefónica-engagemanget förde TrustPortal in i en leveranskedja tillsammans med EY som systemintegratör och Blue Prism som leverantör av robotprogramvara. Det konkurrensutsatta anbudet hade ställt TrustPortal och EY direkt mot tio andra systemintegratörer. TrustPortal vann, till stor del för att dess ingenjörsteam kunde röra sig snabbare och med färre fel än en större organisation som förlitar sig på separata avdelningar och långsammare återkopplingsslingor.
Vad ingen sa vid den tiden var att vinna ett kontrakt genom att vara liten, snabb och arkitektoniskt rigorös inte skyddar dig från vad som händer nästa när du arbetar i en struktur som inte är någon av dessa saker.
Programmet var uppbyggt kring tre månaders checkpoint-cykler, var och en ett hårt kommersiellt åtagande som redan gjorts gentemot Telefónicas B2B-kunder. Problemen kom nästan omedelbart.
Sprint-tidslinjer mellan partners synkroniseras aldrig naturligt. TrustPortal skulle slutföra sin del av en cykel före schemat och sedan spendera återstående tid på att dra andra partners mot kontrollpunkten.
”När du arbetar med partners stämmer sprinten aldrig riktigt i den verkliga världen”, förklarar Linten. ”Du måste ta hänsyn till mycket tid för att backa och försöka komma ikapp deras sida av leveransen för att konsolidera slutet på tremånaderscykeln.”
Scope creep följde. Telefónica justerade kontinuerligt sina krav allteftersom programmet fortskred. ”Många företag på den här nivån kommer inte att lösa problemet. De kommer att koda runt problemet.” Varje ändring av omfattningen utan utvärdering mot den ursprungliga uppdraget var teknisk skuld som ackumulerades tyst i bakgrunden, med en framtida faktura bifogad. Forskning inom mer än 5 400 IT-projekt fann en kollektiv kostnadsöverskridande på 66 miljarder dollar, med varje ytterligare år av projekttid ökar överskridanden med 15 procent, ett mönster som TrustPortal tittade på formuläret i realtid.
Sedan kom Blue Prism-uppdateringen. Och projektpersonalen började lämna.
Varje problem såg annorlunda ut på ytan. Linten skulle så småningom förstå att de alla hade samma orsak.
TrustPortals inledande strategi för att stödja programmet var logiskt. Tilldela de personer som har störst domänexpertis som enskilda kontaktpunkter i varje arbetsflöde. De förstod projektet bäst. De kunde kommunicera mest effektivt med partnerteam. De var bindväven i leveransen.
Risken var inte synlig förrän den förverkligades.
”Under projektet fick vi många människor att gå vidare och skulle förlora den domänkunskapen”, minns Linten.
När en nyckelperson lämnade överfördes inte kunskapen de bar till en kollega eller ett dokument. Det försvann helt enkelt från programmet.
Hans svar var strukturellt snarare än procedurmässigt. Han införde ett minimikrav på två personer med djup expertis inom alla kritiska områden. Inte för att det var god praxis i abstrakt, utan för att han just hade sett vad som hände när den redundansen inte fanns.
”När det var gjort sjönk våra bugstackar till nästan ingenting.”
En buggstack är en kostnad. Kunskapskoncentration är ett ansvar. Att kräva att två personer innehar varje kritisk domän är inte en personalkostnad. Det är en riskkontrollmekanism med en mätbar avkastning. MIT Sloan Management Review identifierar teknisk skuld som affärsansvar kostar amerikanska företag över 2,41 biljoner dollar årligen, en siffra som fångar exakt den typ av ackumulerade kostnader som kunskapsluckor producerar när de lämnas obehandlade. Vad Linten hade gjort var att tillämpa en arkitektonisk princip, eliminera enstaka misslyckanden, på programmets mänskliga system snarare än bara på dess tekniska komponenter.
Han förstod ännu inte hur långt denna princip skulle ta honom.
Stående mitt i ombyggnaden av Blue Prism såg Linten anslutningen han hade saknat.
De feljusterade sprintarna, omfattningen, kunskapsförlusten, de trasiga processerna: de var inte separata problem som krävde separata korrigeringar. Det var samma problem uttryckt på olika sätt. Var och en av dem orsakades av avståndet mellan de människor som förstod domänen och människorna som byggde lösningen. Avstånd mellan organisationen som hade kunskapen och teamet som behövde den. Avstånd mellan affärsproblemet och ingenjören som tilldelats att lösa det.
Kunskapen för att återuppbygga vad Blue Prism hade brutit fanns. Det satt med EY-utvecklarna som arbetade med IVR-integrationen. Under en normal programstyrningsstruktur skulle det rätta svaret ha varit att ta upp frågan formellt, vänta på att partnerorganisationen mobiliserar sig och hantera förseningen mot kontrollpunkten. Linten gjorde inte det.
”Vi tog beslutet att anställa dessa personer för att arbeta för TrustPortal.”
Det var pushback. Att absorbera en annan organisations resurser är aldrig enkelt, och Linten erkänner att motståndet var omedelbart. Men den kommersiella logiken var svår att argumentera med.
”Att föra dessa människor närmare utvecklingsströmmen och utvecklingsprocessen som vi byggde var helt avgörande för att påskynda leveransen.”
Genom att minska avståndet mellan kunskapen och teamet tog Linten bort den enskilt största källan till fördröjning i programmet. Återkopplingsslingan som hade löpt över organisationsgränser kördes nu inom ett enda team. När något gick sönder var personen som förstod varför det gick sönder i samma rum som personen som fixade det.
Det var insikten. Inte en ledningsprincip eller en teambuilding-filosofi. En strukturell observation: varje lager av organisatoriskt avstånd mellan kunskap och utförande är en källa till fördröjning, fel och risk. Minska avståndet och de tekniska problemen blir lösbara. Lämna det på plats, och ingen teknisk ansträngning kommer att kompensera.
Fixa den mänskliga arkitekturen först. Den tekniska arkitekturen kommer att följa.
Det som sedan hände på TrustPortal var inte en enda omorganisation. Det var den stegvisa tillämpningen av samma princip över alla dimensioner av hur företaget fungerade.
Den första ändringen var kunskapsredundansregeln, tillämpad över hela programmet. Två personer som innehar varje kritisk domän, minst. Inte för att nästa person som lämnar nödvändigtvis skulle orsaka en kris, utan för att programmet inte hade råd att ta reda på det.
Den andra förändringen var mer radikal. Efter att ha sett TrustPortal växa från en startup till ett företag och samla de välbekanta lagren av mellanchefen tog Linten bort dem helt. Varje utvecklare, ända ner till den yngsta ingenjören, fick direkt tillgång till beslutsfattare på styrelsenivå. Säljare lärde sig hur ingenjörer tänker. Styrelseledamöter blev tillgängliga för alla med en idé.
”Alla utvecklare kan fråga vem som helst på affärssidan, från säljare hela vägen upp till direktör: Jag har den här idén. Kan du berätta vad affärsproblemet egentligen är?”
Detta är inte en kulturell preferens. Det är en hastighetsmekanism och en kvalitetskontroll. Ju längre en ingenjör sitter från affärsproblemet de löser, desto mer sannolikt är det att de löser fel version av det. Att ta bort lagren får inte bara organisationen att må bättre. Det gör utgången mer exakt. Harvard Business Reviews forskning på högpresterande team identifierar konsekvent öppen åtkomst och uppriktighet mellan nivåer som en primär drivkraft för teamets effektivitet och genombrott på marknadsnivå, förhållanden som ledningshierarkin systematiskt undertrycker.
Den tredje förändringen var onboarding. Nyanställda på TrustPortal spenderar minst tre månader på att integrera innan de bidrar till produktionskoden. Processen är utformad för att bygga ömsesidig förståelse över hela teamet, inte bara teknisk kompetens i den nya anställningen. Ingenjörer lär sig affärsdomänen. Verksamheten lär sig ingenjörerna. Frågor uppmuntras utan kvalifikationer.
”Eftersom du har gjort de tre månaderna, eftersom alla känner varandra på en personlig nivå och förstår hur de tänker, blir frågorna mer anpassade till att få resultat.”
För alla CTO som utvärderar om denna investering är motiverad: team som förstår varandra och affärsdomänen producerar färre missförstånd, färre omarbetningscykler och färre buggar. Tre månaders integration är inte långsam. Det är den snabbaste vägen till ett team som kan fungera utan konstant ledningens ingripande.
När det gäller själva integrationsstrukturen gav Telefónica-programmet en princip som Linten har tillämpat konsekvent sedan dess. Robotisk processautomatiseringsprogramvara fungerar genom att definiera processer på skärm- och gränssnittsnivå: skrapa specifika fält, tolka specifika utgångar, navigera i specifika användargränssnitt. När Blue Prism uppdaterade sin underliggande arkitektur bröt alla dessa processdefinitioner. Korrigeringen krävde en fullständig ombyggnad, inte en patch.
Lektionen var att integrationsstabilitet kräver ägande av hela stacken där det är möjligt. Varje lager av avstånd mellan teamet som bygger automatiseringen och teamet som definierar processerna det automatiserar är en underhållsrisk inbäddad i själva arkitekturen. TrustPortal har medvetet upprätthållit en full-stack ingenjörsmodell sedan dess, med domänkunskap distribuerad över team snarare än koncentrerad till individer eller roller.
Ingen av dessa strukturella förändringar gjorde Telefónica-programmet lätt. Genom att integrera nya teammedlemmar från EY i ett leveransteam som redan är under press, på ett program med avtalsenligt fastställda tidslinjer, skapade exakt de förutsättningar som ingenjörsteamen kopplar av.
Lintens svar var det som överraskar människor mest när de hör det.
Han skyddade tio procent av varje ingenjörs arbetsvecka för självstyrd forskning och utveckling, och han upprätthöll det engagemanget under de mest pressade perioderna av programmet.
Motiveringen var inte generös. Det var operativt. Ingenjörer som utsätts för ihållande leveranstryck utan autonomi över någon del av sin arbetsvecka slutar tänka som ingenjörer. De optimerar för mätvärdet framför dem, vilket i ett leveransprogram är sprintslutförande, snarare än för kvaliteten och livslängden på det de bygger. Den skyddade tiden hindrade den förträngningen från att hända. HBRs forskning om uppdragskritisk kunskap finner att Storskalig hållbar tillväxt är beroende av att människor överför djup expertis över domäner, något som bara händer när ingenjörer har utrymme att tänka bortom den omedelbara leveranscykeln.
”Det finns inget värre än att ta med någon från någonstans och sedan sätta dem i en kanal för att fungera som en fabrikslinje. Det är inte hur ingenjörer verkligen tänker.
Avkastningen på detta åtagande blev konkret synlig nyligen. En skyddad FoU-sprint som kördes i tre månader gav grunden till en helt ny TrustPortal-produkt, levererad av två ingenjörer som arbetade inom sin tilldelade tid.
Linten gjorde också en poäng av att visa ingenjörer den direkta effekten av deras arbete. På ett program av denna skala är det lätt för någon djupt inne i en enda komponent att tappa ur sikte vad de bidrar till. Han gjorde en praxis att ansluta människor till helheten. ”Det här är den biten du gjorde. Se hur det fungerar i det största projektet i världen. Det här är din bit som faktiskt gör en betydande skillnad.” Det är ingen motiverande teknik. Det är information. Ingenjörer måste se systemet för att tänka arkitektoniskt om sin del av det.
Detta ramverk fungerar över tre integrerade dimensioner.
Den strategiska dimensionen kräver en disciplin framför alla andra: att äga diagnosen innan du delegerar lösningen.
De flesta leveransfel börjar som planeringsfel. Problemet kommer förklädt som en teknisk fråga. Instinkten är att vidarebefordra den till ingenjörsteamet. Den instinkten är fel.
”Anledningen till att du har ett affärsproblem är att det inte var planerat ordentligt från början. Det är mycket orättvist att sedan ta det problemet och skapa en ETA på en fiktiv lösning.”
Lintens svar var att bygga en mildrande arkitektur vid sidan av leveransarkitekturen. För varje arbetsflöde fanns en beredskapsplan innan kontrollpunkten anlände.
”Du kan aldrig ta ett affärsproblem till ingenjörerna och förvänta dig att de ska göra ditt jobb åt dig. Du måste ta ansvar på C-nivå.”
Beredskapsplanering kostar mindre än avtalsbrott. Det är affärsfallet. Allt annat följer av det.
Den tekniska dimensionen tar upp en verklighet: varje lager av organisatoriskt avstånd mellan kunskap och utförande är en underhållsrisk inbäddad i arkitekturen.
När Blue Prism uppdaterade sin underliggande arkitektur mitt i programmet bröt varje processdefinition. Kunskapen om att fixa det satt tillsammans med EY IVR-utvecklarna på ett parallellt arbetsflöde. Linten väntade inte på standardprogramstyrning för att mobilisera den.
Återkopplingsslingan som hade löpt över organisationsgränser kördes nu inom ett enda team. När något gick sönder var personen som förstod varför i samma rum som den som fixade det.
TrustPortal har upprätthållit en full-stack ingenjörsmodell sedan dess. Varje ingenjör har arkitekturansvar vid sidan av leveransansvaret. Domänkunskap distribueras genom design, inte av misstag.
Den kulturella dimensionen visade sig vara den mest komplexa. Strukturella förändringar som är logiska på papper ger verklig friktion när de tillämpas på personer under leveranspress.
Linten fann att människor svarar i igenkännliga mönster. Vissa anpassades omedelbart. Andra behövde synliga bevis innan de begick sig. Ett mindre antal är aldrig helt anpassat. Hans svar på varje grupp var strukturellt, inte motiverande. Strukturen ändrades så att den nya modellen gav bättre resultat, och människor fattade sina egna beslut därifrån.
Förvaltningsskikten togs bort helt. Varje utvecklare fick direkt tillgång till de människor som definierade affärsproblemen.
”Alla utvecklare kan fråga vem som helst på affärssidan, från säljare hela vägen upp till direktör: Jag har den här idén. Kan du berätta vad affärsproblemet egentligen är?”
Nyanställda lägger tre månader på att integrera innan de bidrar till produktionskoden. Tio procent av varje ingenjörsvecka är skyddad för självstyrd RnD.
Den skyddade tiden skapade grunden för en helt ny TrustPortal-produkt, levererad av två ingenjörer inom deras tilldelade sprint. Investeringen var operativ, inte kulturell.
Den Strategimönster, med ursprung i programvaruteknik, definierar en familj av algoritmer, kapslar in var och en och gör dem utbytbara, vilket gör att beslutslogiken kan variera oberoende av det specifika problemet som löses. Det är ett beteendemönster byggt för flexibilitet: ett system som kan byta sitt tillvägagångssätt vid körning utan att kräva att den omgivande arkitekturen byggs om.
Tillämpat på organisatoriskt ledarskap är logiken identisk. Ett företag bör inte låsas in i styva, föråldrade strukturer mer än ett väldesignat mjukvarusystem bör låsas in i en enda algoritm. När miljön förändras förändras det specifika tillvägagångssättet. Den underliggande beslutsramen gör det inte.
Linten använde inte detta språk för att beskriva sitt tillvägagångssätt. Men i varje beslut han fattade om Telefónica-programmet och varje förändring han har gjort på TrustPortal sedan dess, är samma mönster synligt: diagnostisera det strukturella problemet först, ta itu med den mänskliga arkitekturen före den tekniska och tillämpa samma logik oavsett om utmaningen är partnerns felanpassning, kunskapsförlust eller ankomsten av agentisk AI.
Telefónica-programmet slutfördes i tid. TrustPortal förvandlade verksamheten för det största företaget i Spanien.
Mer signifikant har mönstret visat sig överförbart. Linten har tillämpat samma diagnostiska ramverk på varje större beslut på TrustPortal sedan dess: samma sekvensering, samma strukturella lins, samma instinkt att titta på den mänskliga arkitekturen innan man sträcker sig efter en teknisk fix.
Det nuvarande testet av denna överförbarhet är agentic AI. TrustPortals ingenjörer går från att skriva kod direkt till att rikta AI-agenter mot arkitektoniska resultat. Motståndet som Linten möter är igenkännligt. Kapabla människor som har byggt sin professionella identitet kring en uppsättning verktyg uppmanas att ändra sin relation med dessa verktyg helt. Instinkten är att fortsätta sträcka sig efter det bekanta. Gartner förutspår att 40% av företagsapplikationerna kommer att integreras med uppgiftsspecifika AI-agenter I slutet av 2026 hanterar Linten inte en framtida överväganden utan en leveransutmaning i nuläget.
Hans svar följer samma mönster. Han kräver inte adoption eller mätning av produktivitet mot AI-utgångsmål. Han omformulerar rollen på arkitektonisk nivå: inte en utvecklare som skriver kodrader, inte en snabb ingenjör som matar in instruktioner, men någon som förstår affärsarkitekturen tillräckligt bra för att styra ett program mot rätt resultat. Och han skyddar utrymmet där ingenjörer kan experimentera med det nya tillvägagångssättet innan det blir ett leveranskrav.
Den djupare utmaningen han redan designar för är social. ”Människor använder agentiska verktyg och blir faktiskt mindre kopplade till de människor de känner, eftersom de blir mindre beroende av den information de har i huvudet och går igenom AI för att få samma information.” De mänskliga kopplingarna som får hans modell att fungera kan komma under press eftersom AI absorberar mer av den informationshämtningsfunktion som mänsklig konversation brukade tjäna. Att upprätthålla förutsättningarna för genuint samarbete över ett team vars medlemmar i allt högre grad interagerar med AI snarare än med varandra är nästa strukturella problem han förbereder sig för att lösa.
Han vet ännu inte svaret. Men han vet vilken fråga han ska ställa först.
Tre kategorier av aktivitet dyker upp när den strukturella diagnosen är klar.
Investering i leveransstrukturer som koncentrerar kritisk domänkunskap till enskilda individer. Ledningsskikt som ökar avståndet mellan affärsproblem och de människor som löser dem. Tidslinjer och ETA tillämpas på problem som ännu inte har diagnostiserats korrekt och ägts på lämplig organisationsnivå.
Strukturell redundans för kritisk domänkunskap i varje program, med minst två personer med djup expertis inom varje område. Direkt åtkomst mellan ingenjörsteam och beslutsfattare på styrelsenivå som standard driftsvillkor, inget undantag. Skyddad tid för autonom utforskning, även under leveranspress, som en operativ investering snarare än en kulturell gest.
Befintliga kundåtaganden och kvalitetsstandarder i alla aktiva program. Den diagnostiska vanan att bedöma den mänskliga arkitekturen innan man försöker fixa den tekniska. Onboarding-processer som prioriterar ömsesidig förståelse före produktionsbidrag.
Linten är direkt om vad som gör detta svårt i praktiken. ”Du kan aldrig ta ett affärsproblem till ingenjörerna och förvänta dig att de ska göra ditt jobb åt dig. Du måste ta ansvar på C-nivå.”
Det är ingen kulturell iakttagelse. Det är ett strukturellt krav. Fram till dess att affärsmisslyckandet diagnostiseras korrekt och ägs på rätt nivå, ger det till leveransteamet exakt den typ av kostsamma, felriktade insatser som Telefónica-programmet mötte innan de strukturella förändringarna gjordes.
De specifika detaljerna i Telefónica-programmet är redan historiska. De involverade partnerna, versionskonflikterna, IVR-integrationerna: inget av det är poängen.
Det som fortfarande är relevant är den beslutsram som Linten utvecklade genom att arbeta igenom varje misslyckande som programmet gav upphov till. Inte genom att planera för dem i förväg, utan genom att känna igen mönstret i dem efter att de inträffat, och bygga ett strukturellt svar som skulle förhindra att samma misslyckande återkommer i en annan form.
Lektionen är inte att skaffa partnerutvecklare, ta bort mellanchefen eller skydda tio procent av ingenjörstiden. Det var de specifika implementeringarna av en mer allmän princip. Lektionen är att fixa den mänskliga arkitekturen innan du når den tekniska fixen, att minska avståndet mellan kunskap och utförande och att tillämpa den logiken konsekvent när miljön förändras runt dig.
” Tekniken förändras, men människor gör det inte på lång sikt. Människor beter sig på ett visst sätt och du måste kunna hantera det.
Det enda som är säkert är att den strukturella utmaningen kommer att komma. En nyckelperson kommer att lämna. En partner kommer att hamna efter. En versionsuppdatering kommer att bryta det du byggt. En ny teknik kommer att anlända och ingenjörerna som behärskar den tidigare kommer att motstå övergången. Frågan är inte om man har rätt teknik. Det är om du har byggt den mänskliga arkitekturen som kan svara på den.
Om du vill diskutera hur detta ramverk kan tillämpas på din organisations teknikomvandling, plattformsmigration eller strategiska teknikbeslut, vänligen kontakta vårt team.
Alexandra Mendes är Senior Growth Specialist på Imaginary Cloud med 3+ års erfarenhet av att skriva om mjukvaruutveckling, AI och digital transformation. Efter att ha avslutat en frontend-utvecklingskurs tog Alexandra upp några praktiska kodningskunskaper och arbetar nu nära med tekniska team. Alexandra brinner för hur ny teknik formar affärer och samhälle och tycker om att förvandla komplexa ämnen till tydligt och användbart innehåll för beslutsfattare.
Människor som läste det här inlägget tyckte också att dessa var intressanta:
