.svg)
Interviewserien Strategy Pattern afslører, hvordan teknologiledere træffer kritiske beslutninger i komplekse, skiftende miljøer. Med udgangspunkt i eksempler fra den virkelige verden og gentagelige rammer giver den handlingsbar indsigt til at foregribe udfordringer og vejlede organisationer med tillid. Du kan læse mere og se andre interviews i serien her.
David Linten, CTO af TrustPortal, stod over for en udfordring, som til sidst konfronterer enhver teknologileder. Hans team havde indgået et samarbejde med EY og vundet Telefónica-kontrakten for at lede det, der på det tidspunkt var en af de største implementeringer af robotprocesautomatisering i verden. Hvad de endnu ikke havde, var en systematisk tilgang til de strukturelle fejl, der ville begynde at akkumulere næsten umiddelbart efter arbejdet startede.
Sprint-tidslinjer nægtede at synkronisere. Omfanget sneg sig, da klienten arbejdede omkring problemer snarere end at løse dem. Nøglepersoner rejste og tog kritisk viden med sig. Derefter udgav robotsoftwaren en versionsopdatering, der ødelagde hver automatiseret proces, teamet havde bygget, og den viden, der var nødvendig for at løse det, sad inde i en partnerorganisation med en inkompatibel måde at arbejde på. Hvert kontrolpunkt var en kontraktlig forpligtelse, som Telefónica allerede havde indgået over for sine egne kunder. Manglende en var ikke en leveringsulempe. Det var en kaskaderende kommerciel fiasko.
Det, der gør Lintens erfaring værd at undersøge, er ikke, at han leverede programmet. Det er, at stien dertil var ustruktureret, dyr og gentagne gange brudt, før en systematisk tilgang opstod. Dette er en beretning om denne rejse og de rammer, han byggede ud fra den.
TrustPortal blev grundlagt i 2017 af Chris Lamberton og to andre, og Chris fungerer nu som strategisk rådgiver. David Linten tiltrådte som CTO og bragte en baggrund, der flyttede fra fysik til software engineering.
TrustPortal's kerneforslag har udviklet sig fra integration af robotisk procesautomatisering (RPA) til det, virksomheden nu beskriver som realtids Agentic HyperAutomation: Orkestrering af mennesker, AI-agenter og ældre systemer samtidigt for at levere komplekse arbejdsgange på få sekunder uden at erstatte eksisterende infrastruktur. Dens platform er betroet på tværs af bank, forsikring, forsyningsselskaber og telekom med kunder, herunder Telefónica, EDF, IBM, OVO Energy og andre.
En af virksomhedens flagskibsinstallationer er fortsat transformation af kontaktcentre, hvor TrustPortal's platform viser en „generativ brugergrænseflade“ i realtid, der skaber guidede arbejdsgange for rådgivere, eliminerer systemhopping, reducerer re-keying og fuldfører resultater på opkaldet snarere end i en opfølgningskø.
Virksomheden arbejder på tværs af hele leveringsstakken, fra back-end banksystemer til front-end kundegrænseflader, og har opbygget et vedvarende leveringspartnerskab med Imaginary Cloud, der spænder over elleve år.
Fra begyndelsen var Lintens filosofi: han arbejder ikke med udviklere, han foretrækker at kalde dem ingeniører, og forskellen betyder noget for ham. En udvikler skriver kode. En ingeniør forstår arkitektur. „Vi ansætter ikke udviklere,“ siger han. “ Vi ansætter ingeniører. Alle har deres hånd i arkitektur helt ned til rent faktisk at skrive kodelinjer.
Denne filosofi formede enhver beslutning, han tog om Telefónica-programmet, herunder dem, han ønskede, at han havde taget tidligere.
Telefónica-engagementet bragte TrustPortal ind i en leveringskæde sammen med EY som systemintegrator og Blue Prism som leverandør af robotsoftware. Udbuddet havde stillet TrustPortal og EY direkte op mod 10 andre systemintegratorer. TrustPortal vandt, hovedsagelig fordi dets ingeniørteam kunne bevæge sig hurtigere og med færre fejl end en større organisation, der var afhængig af adskilte afdelinger og langsommere feedbacksløjfer.
Hvad ingen sagde på det tidspunkt var, at det at vinde en kontrakt ved at være lille, hurtig og arkitektonisk streng ikke beskytter dig mod, hvad der sker næste gang, når du opererer inde i en struktur, der ikke er nogen af disse ting.
Programmet var struktureret omkring tre måneders checkpoint-cyklusser, hver af dem et hårdt kommercielt engagement, der allerede blev indgået over for Telefónicas B2B-kunder. Problemerne kom næsten øjeblikkeligt.
Sprint-tidslinjer mellem partnere synkroniseres aldrig naturligt. TrustPortal ville gennemføre sin del af en cyklus forud for planen og derefter bruge den resterende tid på at trække andre partnere mod kontrolpunktet.
„Når du arbejder med partnere, stemmer sprinterne aldrig rigtig overens i den virkelige verden,“ forklarer Linten. „Du er nødt til at tage højde for meget tid til at gå tilbage og forsøge at indhente deres side af leveringen for at konsolidere slutningen af den tre måneders cyklus.“
Scope creep fulgte. Telefónica justerede løbende sine krav, efterhånden som programmet skred frem. “ Mange virksomheder på dette niveau vil ikke løse problemet. De vil kode rundt om problemet.“ Hver ændring af omfanget, der blev imødekommet uden evaluering i forhold til den oprindelige brief, var teknisk gæld, der akkumulerede stille i baggrunden, med en fremtidig faktura vedlagt. Forskning på tværs af mere end 5.400 it-projekter fandt en samlet omkostningsoverskridelse på 66 milliarder dollars, med hver yderligere år af projektvarighed øger overskridelserne med 15 procent, et mønster, som TrustPortal så på form i realtid.
Så kom Blue Prism-opdateringen. Og projektpersonalet begyndte at rejse.
Hvert problem så anderledes ud på overfladen. Linten ville til sidst forstå, at de alle havde den samme årsag.
TrustPortal's indledende tilgang til at støtte programmet var logisk. Tildel de personer med den største domæneekspertise som enkeltkontaktpunkter på tværs af hver arbejdsstrøm. Disse mennesker forstod projektet bedst. De kunne kommunikere mest effektivt med partnerteams. De var bindevævet i leveringen.
Risikoen var ikke synlig, før den materialiserede sig.
„Under projektet havde vi mange mennesker, der gik videre og ville miste den domæneviden,“ minder Linten.
Når en nøgleperson forlod, blev den viden, de havde, ikke overført til en kollega eller et dokument. Det forsvandt simpelthen fra programmet.
Hans svar var strukturelt snarere end proceduremæssigt. Han indførte et minimumskrav på to personer, der havde dyb ekspertise inden for alle kritiske områder. Ikke fordi det var god praksis abstrakt, men fordi han lige havde set, hvad der skete, da denne redundans ikke eksisterede.
„Når det var gjort, faldt vores fejlstakke til næsten ingenting.“
En fejlstak er en omkostning. Videnskoncentration er en forpligtelse. At kræve, at to personer besidder hvert kritisk domæne, er ikke en bemandingsomkostning. Det er en risikokontrolmekanisme med et målbart afkast. MIT Sloan Management Review identificerer Teknisk gæld som erhvervsansvar koster amerikanske virksomheder over 2,41 billioner dollars årligt, et tal, der præcist fanger den slags akkumulerede omkostninger, som videnhuller producerer, når de ikke adresseres. Det, Linten havde gjort, var at anvende et arkitektonisk princip, eliminere enkelte fejlpunkter, på programmets menneskelige system snarere end kun på dets tekniske komponenter.
Han vidste endnu ikke, hvor langt dette princip ville føre ham.
Stående midt i genopbygningen af det blå prisme så Linten den forbindelse, han havde savnet.
De forkert justerede sprints, omfangskrybningen, videnstabet, de ødelagte processer: de var ikke separate problemer, der krævede separate rettelser. Det var det samme problem udtrykt på forskellige måder. Hver eneste af dem skyldtes afstanden mellem de mennesker, der forstod domænet, og de mennesker, der byggede løsningen. Afstanden mellem den organisation, der havde viden, og det team, der havde brug for den. Afstand mellem forretningsproblemet og den ingeniør, der er tildelt til at løse det.
Viden om at genopbygge, hvad Blue Prism havde brudt, eksisterede. Det sad sammen med EY-udviklerne, der arbejdede på IVR-integrationen. Under en normal programstyringsstruktur ville det korrekte svar have været at rejse spørgsmålet formelt, vente på, at partnerorganisationen mobiliserer, og håndtere forsinkelsen mod kontrolpunktet. Det gjorde Linten ikke.
„Vi tog beslutningen om at anskaffe disse mennesker til at arbejde for TrustPortal.“
Der var tilbageslag. Det er aldrig ligetil at absorbere en anden organisations ressourcer, og Linten erkender, at modstanden var øjeblikkelig. Men den kommercielle logik var vanskelig at argumentere med.
„At bringe disse mennesker tættere på den udviklingsstrøm og udviklingsproces, som vi byggede, var helt afgørende for at fremskynde leveringen.“
Ved at nedbryde afstanden mellem viden og teamet fjernede Linten den største enkeltkilde til forsinkelse i programmet. Feedbacksløjfen, der havde kørt på tværs af organisatoriske grænser, kørte nu inden for et enkelt team. Når noget gik i stykker, var den person, der forstod, hvorfor det gik i stykker, i samme rum som den person, der reparerede det.
Det var indsigten. Ikke et ledelsesprincip eller en teambuilding-filosofi. En strukturel observation: Hvert lag af organisatorisk afstand mellem viden og udførelse er en kilde til forsinkelse, fejl og risiko. Reducer afstanden, og de tekniske problemer bliver løsbare. Lad det være på plads, og ingen teknisk indsats vil kompensere.
Løs den menneskelige arkitektur først. Den tekniske arkitektur følger.
Det, der derefter skete på TrustPortal, var ikke en enkelt omorganisering. Det var den trinvise anvendelse af det samme princip på tværs af alle dimensioner af, hvordan virksomheden arbejdede.
Den første ændring var videnredundansreglen, anvendt i hele programmet. To personer, der besidder hvert kritisk domæne, minimum. Ikke fordi den næste person, der forlader, nødvendigvis ville forårsage en krise, men fordi programmet ikke havde råd til at finde ud af det.
Den anden ændring var mere radikal. Efter at have set TrustPortal vokse fra en startup til en virksomhed og samle de velkendte lag af mellemledelse, fjernede Linten dem helt. Hver udvikler, ned til den mest junioringeniør, fik direkte adgang til beslutningstagere på bestyrelsesniveau. Sælgere lærte, hvordan ingeniører tænker. Direktører blev tilgængelige for alle med en idé.
„Enhver udvikler kan spørge enhver på forretningssiden, fra sælger hele vejen op til direktør: Jeg har denne idé. Kan du fortælle mig, hvad forretningsproblemet egentlig er?“
Dette er ikke en kulturel præference. Det er en hastighedsmekanisme og en kvalitetskontrol. Jo længere en ingeniør sidder fra det forretningsproblem, de løser, jo mere sandsynligt er det, at de løser den forkerte version af det. Fjernelse af lagene får ikke kun organisationen til at føle sig bedre. Det gør udgangen mere præcis. Harvard Business Reviews forskning på højtydende teams identificerer konsekvent åben adgang og åbenhed mellem niveauer som en primær drivkraft for teamets effektivitet og gennembrud på markedsniveau, forhold, som ledelseshierarkiet systematisk undertrykker.
Den tredje ændring var onboarding. Nyansatte hos TrustPortal bruger mindst tre måneder på at integrere, før de bidrager til produktionskoden. Processen er designet til at opbygge gensidig forståelse på tværs af teamet, ikke kun teknisk kompetence i den nye ansættelse. Ingeniører lærer forretningsdomænet. Virksomheden lærer ingeniørerne. Spørgsmål opmuntres uden kvalifikation.
„Fordi du har klaret de tre måneder, fordi alle kender hinanden på et personligt niveau og forstår, hvordan de tænker, bliver spørgsmålene mere afstemte for at få resultater.“
For enhver CTO, der vurderer, om denne investering er berettiget: teams, der forstår hinanden og forretningsområdet, producerer færre misforståelser, færre omarbejdningscyklusser og færre fejl. Integrationen på tre måneder er ikke langsom. Det er den hurtigste vej til et team, der kan fungere uden konstant ledelsesindgriben.
Hvad angår selve integrationsstrukturen, frembragte Telefónica-programmet et princip, som Linten har anvendt konsekvent siden. Robotisk procesautomatiseringssoftware fungerer ved at definere processer på skærm- og grænsefladeniveau: skrabe specifikke felter, fortolke specifikke output, navigere i specifikke brugergrænseflader. Da Blue Prism opdaterede sin underliggende arkitektur, brød hver enkelt af disse procesdefinitioner. Rettelsen krævede en fuld genopbygning, ikke en patch.
Lektionen var, at integrationsstabilitet kræver ejerskab af hele stakken, hvor det er muligt. Hvert lag af afstand mellem teamet, der bygger automatiseringen, og teamet, der definerer de processer, det automatiserer, er en vedligeholdelsesrisiko indlejret i selve arkitekturen. TrustPortal har bevidst opretholdt en full-stack ingeniørmodel lige siden, med domæneviden fordelt på tværs af teams snarere end koncentreret om enkeltpersoner eller roller.
Ingen af disse strukturelle ændringer gjorde Telefónica-programmet let. Integrering af nye teammedlemmer fra EY i et leveringsteam, der allerede er under pres, på et program med kontraktmæssigt fastsatte tidslinjer skabte præcis de betingelser, hvor ingeniørteams afbryder sig.
Lintens svar var det, der overrasker folk mest, når de hører det.
Han beskyttede ti procent af hver ingeniørs arbejdsuge til selvstyret forskning og udvikling, og han fastholdt dette engagement gennem de mest pressede perioder af programmet.
Begrundelsen var ikke generøs. Det var operationelt. Ingeniører, der er udsat for vedvarende leveringspres uden autonomi over nogen del af deres arbejdsuge, holder op med at tænke som ingeniører. De optimerer efter målestokken foran dem, som i et leveringsprogram er sprintfærdiggørelse, snarere end for kvaliteten og levetiden af det, de bygger. Den beskyttede tid forhindrede, at denne indsnævring skete. HBRs forskning i missionskritisk viden finder det bæredygtig vækst i stor skala afhænger af, at folk overfører dyb ekspertise på tværs af domæner, noget der kun sker, når ingeniører har plads til at tænke ud over den umiddelbare leveringscyklus.
“ Der er ikke noget værre end at bringe nogen fra et sted og derefter sætte dem i en kanal for at fungere som en fabrikslinje. Det er ikke sådan ingeniører virkelig tænker.“
Forrentningen af denne forpligtelse blev for nylig konkret synlig. En beskyttet R&D-sprint, der kørte i tre måneder, skabte grundlaget for et helt nyt TrustPortal-produkt, leveret af to ingeniører, der arbejder inden for deres tildelte tid.
Linten gjorde også et punkt i at vise ingeniører den direkte indvirkning af deres arbejde. På et program af denne skala er det let for nogen dybt inde i en enkelt komponent at miste synet af, hvad de bidrager til. Han gjorde en praksis med at forbinde mennesker til helheden. „Det er den del, du har gjort. Se, hvordan det fungerer i det største projekt i verden. Dette er din del, der faktisk gør en betydelig forskel.“ Det er ikke en motiverende teknik. Det er information. Ingeniører har brug for at se systemet for at tænke arkitektonisk om deres del af det.
Denne ramme fungerer på tværs af tre integrerede dimensioner.
Den strategiske dimension kræver en disciplin frem for alle andre: at eje diagnosen, før løsningen delegeres.
De fleste leveringsfejl begynder som planlægningsfejl. Problemet kommer forklædt som et teknisk problem. Instinktet er at videregive det til ingeniørteamet. Det instinkt er forkert.
“ Årsagen til, at du har et forretningsproblem, er, at det ikke var planlagt ordentligt i første omgang. Det er meget uretfærdigt at tage det problem og skabe en ETA på en fiktiv løsning.“
Lintens svar var at opbygge en afbødningsarkitektur sammen med leveringsarkitekturen. For hver arbejdsstrøm eksisterede der en beredskabsplan, før kontrolpunktet ankom.
„Du kan aldrig tage et forretningsproblem til ingeniørerne og forvente, at de gør dit job for dig. Du skal tage ansvar på C-niveau.“
Beredskabsplanlægning koster mindre end kontraktfejl. Det er business case. Alt andet følger af det.
Den tekniske dimension adresserer én virkelighed: Hvert lag af organisatorisk afstand mellem viden og udførelse er en vedligeholdelsesrisiko indlejret i arkitekturen.
Da Blue Prism opdaterede sin underliggende arkitektur midt i programmet, brød hver procesdefinition. Viden til at løse det sad sammen med EY IVR-udviklerne på en parallel arbejdsstrøm. Linten ventede ikke på, at standardstyring af programmet kunne mobilisere den.
Feedbacksløjfen, der havde kørt på tværs af organisatoriske grænser, kørte nu inden for et enkelt team. Når noget gik i stykker, var den person, der forstod hvorfor, i samme rum som den person, der reparerede det.
TrustPortal har opretholdt en full-stack ingeniørmodel lige siden. Hver ingeniør har arkitekturansvar sammen med leveringsansvar. Domæneviden distribueres ved design, ikke ved et uheld.
Den kulturelle dimension viste sig at være den mest komplekse. Strukturelle ændringer, der giver logisk mening på papir, skaber reel friktion, når de anvendes på mennesker under leveringspres.
Linten fandt ud af, at folk reagerer i genkendelige mønstre. Nogle tilpassede sig straks. Andre havde brug for synlige beviser, før de begik. Et mindre antal er aldrig fuldt tilpasset. Hans svar på hver gruppe var strukturelt, ikke motiverende. Strukturen blev ændret, så den nye model gav bedre resultater, og folk tog deres egne beslutninger derfra.
Ledelseslag blev fjernet helt. Hver udvikler fik direkte adgang til de mennesker, der definerer forretningsproblemerne.
„Enhver udvikler kan spørge enhver på forretningssiden, fra sælger hele vejen op til direktør: Jeg har denne idé. Kan du fortælle mig, hvad forretningsproblemet egentlig er?“
Nyansatte bruger tre måneder på at integrere, før de bidrager til produktionskoden. Ti procent af hver ingeniørs uge er beskyttet for selvstyret RnD.
Den beskyttede tid skabte grundlaget for et helt nyt TrustPortal-produkt, leveret af to ingeniører inden for deres tildelte sprint. Investeringen var operationel, ikke kulturel.
Den Strategimønster, der stammer fra softwareteknik, definerer en familie af algoritmer, indkapsler hver enkelt og gør dem udskiftelige, så beslutningslogikken kan variere uafhængigt af det specifikke problem, der løses. Det er et adfærdsmønster bygget til fleksibilitet: et system, der kan skifte sin tilgang under kørsel uden at kræve, at den omgivende arkitektur genopbygges.
Anvendt til organisatorisk ledelse er logikken identisk. En virksomhed bør ikke låses fast i stive, forældede strukturer, ligesom et veldesignet softwaresystem skal låses fast i en enkelt algoritme. Når miljøet ændrer sig, ændres den specifikke tilgang. Det gør den underliggende beslutningsramme ikke.
Linten brugte ikke dette sprog til at beskrive sin tilgang. Men på tværs af hver beslutning, han tog om Telefónica-programmet, og hver ændring, han har foretaget på TrustPortal siden, er det samme mønster synligt: diagnosticer først det strukturelle problem, tag fat på den menneskelige arkitektur før den tekniske, og anvend den samme logik, uanset om udfordringen er partnerfejl, tab af viden eller ankomsten af agentisk AI.
Telefónica-programmet blev afsluttet til tiden. TrustPortal forvandlede driften af den største virksomhed i Spanien.
Mere markant har mønsteret vist sig overførbart. Linten har anvendt den samme diagnostiske ramme på alle større beslutninger på TrustPortal siden: den samme sekventering, den samme strukturelle linse, det samme instinkt til at se på den menneskelige arkitektur, før man strækker sig efter en teknisk løsning.
Den nuværende test af denne overførbarhed er agentisk AI. TrustPortal's ingeniører går fra at skrive kode direkte til at dirigere AI-agenter mod arkitektoniske resultater. Modstanden Linten møder er genkendelig. Dygtige mennesker, der har bygget deres professionelle identitet omkring et sæt værktøjer, bliver bedt om at ændre deres forhold til disse værktøjer fuldstændigt. Instinktet er at fortsætte med at nå ud til det velkendte. Gartner forudser det 40% af virksomhedsapplikationer vil blive integreret med opgavespecifikke AI-agenter Ved udgangen af 2026 klarer Linten ikke en fremtidig overvejelse, men en leveringsudfordring i nutiden.
Hans svar følger det samme mønster. Han pålægger ikke vedtagelse eller måling af produktivitet i forhold til AI-outputmål. Han omformulerer rollen på et arkitektonisk niveau: ikke en udvikler, der skriver kodelinjer, ikke en hurtig ingeniør, der indtaster instruktioner, men en person, der forstår forretningsarkitekturen godt nok til at lede et program mod det rigtige resultat. Og han beskytter det rum, hvor ingeniører kan eksperimentere med den nye tilgang, før det bliver et leveringskrav.
Den dybere udfordring, han allerede designer for, er social. „Folk bruger agentiske værktøjer og bliver faktisk mindre forbundet med de mennesker, de kender, fordi de bliver mindre afhængige af de oplysninger, de har i deres hoveder og går gennem AI for at få de samme oplysninger.“ De menneskelige forbindelser, der får hans model til at fungere, kan komme under pres, da AI absorberer mere af den informationshentningsfunktion, som menneskelig samtale plejede at tjene. At opretholde betingelserne for ægte samarbejde på tværs af et team, hvis medlemmer i stigende grad interagerer med AI snarere end med hinanden, er det næste strukturelle problem, han forbereder sig på at løse.
Han kender endnu ikke svaret. Men han ved, hvilket spørgsmål han skal stille først.
Tre kategorier af aktivitet dukker op, når den strukturelle diagnose er afsluttet.
Investering i leveringsstrukturer, der koncentrerer kritisk domæneviden i enkeltpersoner. Ledelseslag, der øger afstanden mellem forretningsproblemer og de mennesker, der løser dem. Tidslinjer og ETA'er anvendt på problemer, der endnu ikke er korrekt diagnosticeret og ejet på det relevante organisatoriske niveau.
Strukturel redundans for kritisk domæneviden på tværs af hvert program, med mindst to personer med dyb ekspertise inden for hvert område. Direkte adgang mellem ingeniørteams og beslutningstagere på bestyrelsesniveau som standard driftsbetingelse, ikke en undtagelse. Beskyttet tid til autonom efterforskning, selv under leveringspres, som en operationel investering snarere end en kulturel gestus.
Eksisterende kundeforpligtelser og kvalitetsstandarder på tværs af alle aktive programmer. Den diagnostiske vane med at vurdere den menneskelige arkitektur, før man forsøger at rette den tekniske. Onboarding-processer, der prioriterer gensidig forståelse før produktionsbidrag.
Linten er direkte om, hvad der gør dette vanskeligt i praksis. „Du kan aldrig tage et forretningsproblem til ingeniørerne og forvente, at de gør dit job for dig. Du skal tage ansvar på C-niveau.“
Det er ikke en kulturel observation. Det er et strukturelt krav. Indtil virksomhedens fiasko er korrekt diagnosticeret og ejes på det rigtige niveau, vil overdragelsen af den til leveringsteamet resultere i præcis den form for dyre, forkert orienterede indsats, som Telefónica-programmet stødte på, før strukturændringerne blev foretaget.
De specifikke detaljer i Telefónica-programmet er allerede historiske. De involverede partnere, versionskonflikterne, IVR-integrationerne: intet af det er pointen.
Det, der fortsat er relevant, er den beslutningsramme, som Linten udviklede ved at arbejde igennem alle de fiaskoer, som programmet gav anledning til. Ikke ved at planlægge for dem på forhånd, men ved at genkende mønsteret i dem, efter at de opstod, og opbygge en strukturel reaktion, der ville forhindre, at den samme fiasko gentager sig i en anden form.
Lektionen er ikke at erhverve partnerudviklere, fjerne mellemledelse eller beskytte ti procent af ingeniørtiden. Det var de specifikke implementeringer af et mere generelt princip. Lektionen er at rette den menneskelige arkitektur, før du rækker ud efter den tekniske løsning, at reducere afstanden mellem viden og udførelse og at anvende den logik konsekvent, når miljøet ændrer sig omkring dig.
„Teknologien ændrer sig, men mennesker gør det ikke i det lange løb. Mennesker opfører sig på en bestemt måde, og du skal være i stand til at håndtere det.
Den eneste sikkerhed er, at den strukturelle udfordring vil komme. En nøgleperson vil forlade. En partner vil falde bagud. En versionsopdatering vil ødelægge det, du byggede. En ny teknologi ankommer, og ingeniørerne, der mestrede den forrige, vil modstå overgangen. På det tidspunkt er spørgsmålet ikke, om du har den rigtige teknologi. Det er, om du har bygget den menneskelige arkitektur, der er i stand til at reagere på den.
Hvis du gerne vil diskutere, hvordan denne ramme kan anvendes til din organisations teknologitransformation, platformmigration eller strategiske teknologibeslutninger, bedes du venligst Kontakt vores team.
Alexandra Mendes er Senior Growth Specialist hos Imaginary Cloud med 3+ års erfaring med at skrive om softwareudvikling, AI og digital transformation. Efter at have gennemført et frontend-udviklingskursus fik Alexandra nogle praktiske kodningsevner og arbejder nu tæt sammen med tekniske teams. Alexandra brænder for, hvordan nye teknologier former erhvervslivet og samfundet, og hun nyder at omdanne komplekse emner til klart og nyttigt indhold for beslutningstagere.
People who read this post, also found these interesting:
