.svg)
.png)
Tiago Franco, grundare och verkställande direktör för Imaginary Cloud, stod inför ett problem som så småningom konfronterar alla teknikföretag. Den expertis som hade gjort hans företag framgångsrikt tappade koll. Inte för att själva tekniken hade tappat teknisk mognad eller robusthet, utan för att dess marknadsrelevans hade minskat när branschen gick mot en annan teknisk stack.
Under de första åren levererade Imaginary Cloud projekt främst i Ruby on Rails. Sedan började utsikterna avvisa förslag med ökande frekvens, till stor del på grund av teknikstacken. Anledningen var enkel: React och Node.js var den nya heta saken.
Det som gör Francos erfarenhet värd att undersöka är inte att han framgångsrikt navigerade i denna övergång. Det som gör det värdefullt är inte misslyckande, utan det faktum att övergången var ostrukturerad, svår och kostsam innan ett systematiskt tillvägagångssätt uppstod som kunde tillämpas på framtida teknikförändringar. Detta är en redogörelse för den resan och de lärdomar som den avslöjade.
Den här intervjun är en del av vår serie Strategy Pattern, där vi undersöker hur organisationer anpassar sig till förändringar. Du kan läsa mer och se andra intervjuer i serien här.
Franco grundade Imaginärt moln, ett konsultföretag för digital transformation baserat i Portugal som hjälper kunder att leverera och vara närvarande i det digitala rummet. Sedan starten i maj 2010 har företaget hjälpt till att skala över 300 digitala produkter över hela Europa, USA och Mellanöstern och betjänat kunder som Nokia, BNP Paribas och Thermo Fisher. Företaget sysselsätter nu över 100 proffs på fyra kontor över hela världen och upprätthåller en kundrekommendation på 99%.
Han byggde Imaginary Cloud efter att ha arbetat som mjukvaruingenjör och projektledare för organisationer inklusive CERN, Europeiska rymdorganisationen och Storbritanniens försvarsministerium. Det som kännetecknade dessa organisationer var deras djupa beroende av innovation och forskning och utveckling, ett tankesätt Franco förde in i Imaginary Cloud.
Men det fokuset drevs till stor del ur ett ingenjörsperspektiv snarare än från användarens mål, en spänning som formade hans tro på att utvecklingsprocessen behövde förändras.
Grundavhandlingen behandlade vad Franco såg som ett återkommande problem: kvalitetscentrerad programvara är ofta utmanande att använda och benägen för mänskliga fel eftersom den inte fokuserar på användaren. På så sätt tror han att många företag prioriterar användarupplevelse men kompromissar med kvaliteten. Imaginary Cloud skulle slå samman båda tillvägagångssätten.
Ruby on Rails blev den primära tekniken eftersom den anpassade sig till denna vision. Under de första åren fungerade strategin och företaget levererade dussintals projekt över hela världen. Sedan skiftade marknaden, delvis påverkad av Facebooks beslut om öppen källkod React och främja nya arkitektoniska tillvägagångssätt som gynnade JavaScript-baserade stackar som React och Node.js framför mer traditionella ramverk. Idag står företag inför en liknande utmaning med AI-teknik, där snabba adoptionstryck kan få etablerade verktyg eller processer att kännas föråldrade.
Förskjutningen skedde snabbare än Franco förväntade sig. React och Node.js, som representerar en grundläggande arkitektoniskt skifte från monolitiska till mikroservicemönster, blev vad Franco beskriver som ”den som varje klient ville börja med.” Ruby on Rails ”slutade vara en önskvärd teknik för att starta ett nytt projekt.”
Paradoxen var kritisk. Imaginary Cloud föreslog Ruby on Rails-lösningar som var tekniskt överlägsna för de tidiga produkter som de flesta kunder byggde och 30 till 40% billigare än mikrotjänstealternativ. Ändå avvisade kunderna dessa förslag enbart på grund av teknikstacken.
” Kunden fick inte mer värde. Kunden fick mindre värde eftersom de betalade mer för en teknik som är mindre lämplig för scenen där de är, men de köpte helt enkelt inte den tekniska stacken.”
Franco bestämde sig för att överföra hela företaget till React och Node.js. Men han hade inget systematiskt tillvägagångssätt för att genomföra denna omvandling. Resultatet blev vad han nu karakteriserar som djup ineffektivitet.
På frågan hur han formulerade problemet och kommunicerade övergångsstrategin till företaget, var Francos svar direkt: ”Det gjorde jag inte. Det är poängen. Det är det som har förändrats i mig som ledare genom åren. I de tidiga stadierna visste jag inte hur jag skulle hantera den här förändringen.”
Istället för en strukturerad plan vidtog Franco omedelbara åtgärder. ”Vi har precis börjat leverera förslag i React. Vi började leverera projekt i Node och React, och allt var väldigt actionorienterat.” Vissa kunder accepterade dessa förslag till högre priser, vilket krävde fler arbetstimmar än med Ruby on Rails. Projekt började, men problem uppstod snabbt: stacken var ny, och det var företagets första projekt som använde den.
Motståndet var förutsägbart men oförberedt för. Ingenjörer som hade behärskat Ruby on Rails såg kollegor utforska andra riktningar. ”Det är naturligt för människor att experimentera med ny teknik, och det kan vara hälsosamt”, förklarar Franco. Men det är organisationen som måste bestämma vad man ska anta. Vissa ingenjörer utforskade React eller andra verktyg som Elixir.
”Vi började bara göra saker, och vissa människor visade motstånd. Det slutade med att vi använde dem i Node.js projekt, varav några anpassades. Jag skulle säga att majoriteten gjorde det efter en tid. Men jag kommunicerade inte en strategisk riktning och sa att det är här vi måste gå. Det var mer som att vi började göra saker. Det var ineffektivt.”
Vissa ingenjörer lämnade organisationen, men inte för att de experimenterade. De lämnade för att de älskade Ruby on Rails och inte ville leverera projekt i en annan teknik, medan marknaden för Rails krympte. Som Franco noterar, ”När en organisation förändras anpassar sig vissa människor med den, och andra gör det inte. Denna lektion gäller alla övergångar.”
Genombrottet kom från att känna igen ett mönster Franco hade stött på upprepade gånger.
Som han förklarar:
”Det som vanligtvis tar dig dit tar dig inte till nästa steg. Så miljön förändrades, och du måste förändras med den.
Detta händer, konstaterar Franco, ”mycket ofta. Det händer vanligtvis med några års mellanrum där du behöver anpassa hur du levererar programvara bara för att miljön förändras.
Franco påminner också om råd från en universitetsprofessor som berättade för en annan verkställande direktör:
”Den strategiska planen måste förändras så lite som möjligt och så ofta som nödvändigt.”
Paradoxen fångade vad Franco lärde sig: strategi kräver engagemang över tre till fem års horisonter, men strikt efterlevnad av misslyckade strategier garanterar föråldring.
” Teknikerna som jag använder nu för att hantera den förändringen är helt annorlunda. De är mer mogna än de var i de tidiga stadierna.” Skillnaden kom från att lära sig genom erfarenhet och också söka formell utbildning i företagsstrategi, vilket gjorde det möjligt för honom att närma sig övergångar med ett systematiskt, snarare än improviserat, ramverk.
Det som framkom från flera övergångar, Francos första var kaotisk, hans andra marginellt bättre, hans tredje mer systematiska, var vad han nu identifierar som ett repeterbart mönster.
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 algoritmer kan variera oberoende av koden som använder dem.
Det är ett beteendemönster som är utformat för att ge flexibilitet och undvika hårdkodningsbeteende. Du kan till exempel ha en funktion som calculate_time_home (strategi), där strategin kan vara den snabbaste vägen, en naturskön promenad eller ett annat tillvägagångssätt.
Precis som programvara kan byta algoritmer vid körning när den implementeras med hjälp av strategimönstret, bör ett företag inte låsas in i styva, föråldrade metoder. Organisationer kan ändra processer eller teknikstackar utan att skriva om hela systemet, vilket gör dem mer flexibla och underhållbara snarare än spröda och föråldrade.
På frågan om vad andra ledare ska göra när de står inför liknande övergångar avslöjar Francos svar kärnan i mönstret: ”Det första de behöver göra är att bestämma vad den förändringen är, vilken riktning de går. Och när det är bestämt måste du sluta göra vad som behöver för att sluta, och du måste börja göra vad som behöver startas för att nå det målet.”
Men innan något av det, Franco betonar:
”Innan du förstår vad du behöver sluta göra måste du förstå vart du är på väg. Gör en diagnos av var de är nu och vart branschen är på väg, och definiera sedan en strategi.
Detta ramverk fungerar över tre integrerade dimensioner som Franco lärde sig måste hanteras samtidigt.
Francos första lektion var att skilja strukturella marknadsförändringar från tillfälliga fluktuationer. Ruby on Rails försvann inte. Det upphörde helt enkelt att vara standardvalet för nya projekt. Denna distinktion spelade någon roll.
Under Ruby-to-React-övergången avslöjade diagnosen en obekväm sanning. Kunderna krävde teknik som levererade mindre värde till en högre kostnad. Men efterfrågan var konsekvent över marknaderna och upprätthölls över tid. Detta tyder på en strukturell förändring, inte en tillfällig trend.
Francos mogna tillvägagångssätt, utvecklat efter det första misslyckandet, innebär uttrycklig strategisk planering: ”Vi driver en strategi och utformar en strategi i tre år. Det är vad vi vill uppnå.”
Men planen måste kommuniceras med absolut tydlighet:
”Du gör diagnosen, du förbereder strategin och ser sedan till att strategin kan presenteras för alla på en sida. Och sedan delar du den strategin med alla.
Den tekniska dimensionen tar upp verkligheten Franco lärde sig genom erfarenhet: övergångar kan inte ske omedelbart. Imaginary Cloud övergav inte Ruby on Rails helt. Befintliga kundprojekt fortsatte i sin ursprungliga teknik. Nya projekt lanseras i React och Node.js.
Lösningen Franco utvecklade var att skapa praktiksamhällen.
”Det slutade med att vi skapade det vi kallar praktiksamhällen, där människor kunde dela kunskap om teknik som de använder.”
Dessa samhällen tjänade flera funktioner: påskynda kunskapsöverföring, skapa sociala bevis genom synliga framgångsfall och upprätta standarder utan centrala flaskhalsar.
Franco var också tvungen att omstrukturera lag. ”Vi var tvungna att skilja front-end från back-end-specialisering på grund av marknadskrafterna som det. Tidigare hade vi inte det. Det var fullstack.” Denna separation skapade nya samordningsutmaningar som praktiksamhällen hjälpte till att ta itu med.
Den kulturell dimension visade sig vara den mest komplexa. Franco förklarar att människor reagerar annorlunda på förändringar.
Vissa omfamnar den nya tekniken omedelbart och blir tidiga användare. Andra motstår först, men när de ser kollegor uppnå resultat och fördelarna med adoption följer de gradvis efter. Slutligen väljer vissa att inte anpassa sig och kan lämna organisationen om förändringen strider mot deras preferenser eller principer. ”När en organisation förändras anpassar sig vissa människor med den, och andra gör det inte. Att förstå denna dynamik är avgörande, och det är en lektion som gäller för alla övergångar, ” Franco noterar.
Francos ramverk erkänner tre populationer. Tidiga användare omfamnar förändring entusiastiskt. Pragmatister anpassar sig när bevis på framgång blir tydliga. Motståndare föredrar det gamla tillvägagångssättet och ser övergången som onödig eller missvisad.
” Ledarskap handlar om förändring. Ledarskap sätter riktning och ser till att förändring sker. Förändring är rörigt. När förändring sker vet vi ibland inte om du har rätt eller om du har fel, men vi måste gå i den specifika riktningen.
Valideringen av Francos mönster kommer från mätbara resultat. Imaginary Cloud behöll sin 99% kundrekommendationsgrad under hela övergången, trots inlärningskurvan och högre projektkostnader under den 18 månader långa transformationsperioden.
Mer betydelsefullt, mönstret visade sig överförbart. Franco har tillämpat samma ramverk på efterföljande övergångar, inklusive molnbaserade arkitekturer, serverlös databehandling, och artificiell intelligensintegration. Varje övergång gick smidigare eftersom det systematiska tillvägagångssättet ersatte improvisation.
Tre kategorier av aktiviteter dyker upp när riktningen är etablerad.
Investeringar i kapacitet som strider mot strategisk inriktning. Marknadsföringstjänster som marknaden inte längre värderar. Aktivt motstånd som undergräver strategiska initiativ. Som Franco förklarar: ”Om du ändrar strategi, om du ändrar riktning, kommer strategin att berätta vad du behöver sluta göra.”
Bygga strategisk kapacitet trots omedelbara kostnader. Mätning av övergångsförloppet med specifika mätvärden. Kommunicera strategiska skäl upprepade gånger tills meddelandet blir inbäddat i organisationens medvetande.
Befintliga kundåtaganden. Kvalitetsstandarder trots effektivitetstryck. Marknadspositionering samtidigt som endast den tekniska implementeringen ändras.
Franco betonar att framgångsrika övergångar bevarar mer än de kasserar. Under övergången från Ruby till React förblev Imaginary Clouds operativa modell, kundrelationer och marknadspositionering konstant. Endast den tekniska implementeringen förändrades. Detta förhindrade försök till samtidig omvandling över flera dimensioner.
- Utbytbara lösningar: Samma ramverk gäller oavsett om du byter teknikstackar, använder AI eller omstrukturerar team. Beslutslogiken förblir konstant, även när specifika utmaningar förändras.
- Kontextoberoende logik: Beslutssekvensen gäller för nystartade företag och företag, även om utförandet varierar. Ett företag med 20 personer och en organisation med 2 000 personer står inför olika implementeringsutmaningar men följer samma strategiska mönster.
- Kan underhållas i stor skala: Som Franco lärde sig förhindrar att ha ett tydligt mönster kaoset i ad hoc-förändringshantering. ”Detta händer mycket ofta”, konstaterar han. ”Det händer vanligtvis med några års mellanrum, där du måste anpassa hur du levererar programvara bara för att miljön förändras.”
Andra ledare kan anta Francos tillvägagångssätt inte för att de står inför samma tekniska utmaning, utan för att de möter samma mönster av miljöförändringar som kräver strategisk anpassning. Verktygen ändras, men beslutsramen förblir robust.
Francos resa från Ruby on Rails till React är redan föråldrad, men det var en av de första utmaningarna han var tvungen att uthärda. Men hans ram för att navigera i förändringar är fortfarande relevant eftersom det är ett strategimönster: kontextoberoende beslutslogik som anpassar sig till alla utmaningar.
Lektionen är inte ”anta mikrotjänster” eller någon specifik teknik. Lektionen är att systematiskt övervaka skift, oavsett om det är i AI, mjukvaruramar eller affärsmodeller, diagnostisera innan du agerar, testa innan du engagerar dig och kommunicera ärligt.
Detta mönster fungerar oavsett om du är ett mjukvaruföretag med 50 personer eller ett företag med 5 000 personer, oavsett om du byter teknikstackar eller affärsmodeller, och om ditt ”Ruby on Rails-ögonblick” inträffar nästa kvartal eller om fem år.
Den enda säkerheten är att ditt ögonblick kommer: förslag kommer att avvisas, kärnkompetenser kommer att bli föråldrade och miljön kommer att förändras. Vid den tidpunkten måste du välja att anpassa dig avsiktligt eller riskera att bli lämnad efter.
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.
VD @ Imaginary Cloud och medförfattare till boken Product Design Process. Jag gillar mat, vin och Krav Maga (inte nödvändigtvis i denna ordning).
Människor som läste det här inlägget tyckte också att dessa var intressanta:
