I detta kapitel förklarar vi varför enkla processer ofta är mycket bättre än mer akademiska, komplexa affärsprocesser.


Detta är en del av Agency Success Guide, en bok skriven av VD:n för Blue för alla ägare av byråer och professionella tjänsteföretag, baserat på hans 10-åriga erfarenhet som byrågrundare.

I denna bok kommer du att lära dig allt du behöver veta om hur man driver en radikalt framgångsrik byrå. Från kassaflöde till projektledning, och bygga kundrelationer till att skriva vinnande förslag — allt finns här.


När jag var tio år gammal hade jag en matematiklärare som lärde mig principen KISS: "Håll det enkelt, dumhuvud!". Jag har funnit att denna läxa är allmänt tillämplig, inte bara när man försöker lösa kvadratiska ekvationer, utan över nästan alla delar av livet.

Enkelhet och komplexitet är något som jag tycker är mycket binärt. Det finns ingen gråskala: antingen har du en enkel strategi för något, eller så kan du välja att göra det komplicerat. Och när du väl bestämmer dig för att göra det komplicerat, har du hoppat av en klippa. Du kommer att falla snabbare än du kan hantera mot ytterligare komplexitet.

Du kanske tänker för dig själv, "Jag är ganska smart, och jag gillar att ha nyanser i det jag gör, så jag kan hantera komplexitet."

Och du har rätt — inom ett specifikt område av ditt arbete kan du förmodligen hantera komplexitet.

Du kan ha en sofistikerad rekryteringsprocess med olika steg och procedurer och flödesscheman, och enkelt hålla koll på det utan några problem alls. Men vad sägs om alla de andra hundratals processer som utgör en modern organisation? Kan du hålla koll på allt, inklusive de olika kopplingarna och beroendena?

Mitt test för att se om något är för komplicerat är om jag kan förklara det för en junior teammedlem. Om de förstår det, då håller vi saker enkla och är på rätt väg. Om det är för komplext och de inte kan förstå det snabbt, då har vi förmodligen överdesignat en lösning på ett problem. Vi behöver gå tillbaka till ritbordet och förstå hur vi kan förenkla, vad som är överflödigt, vad som kan tas bort utan stora konsekvenser.

Jag finner ofta att jag kan få 70% till 80% av vad jag vill från en specifik process med förvånansvärd lätthet. Men, om jag insisterar på att få 100% av vad jag vill, börjar saker bli betydligt mer komplicerade. Så, jag har lärt mig att nöja mig med den bekväma 75%-nivån och njuta av att saker hålls enkla.

En annan sak som gör att det blir mer naturligt att omfamna enkelhet är att vara en liten organisation. Detta kan låta kontraintuitivt: trots allt har du lagt ner så mycket tid och ansträngning på att starta ditt företag — varför skulle du inte expandera?

Visserligen är de flesta framgångsrika företag stora, med olika avdelningar, större team och fina kontor.

Detta var också så jag tänkte. Min ursprungliga vision för Mäd var att anställa hundratals teammedlemmar i ett halvdussin kontor i Sydöstra Asien.

Så jag försökte, två gånger.

Aggressivt skala, trycka på försäljningen och anställa nya teammedlemmar. Jag hade en gång en onboardingdag med elva nya personer samma dag. Jag köpte till och med en annan konsultbyrå för att lägga till fler teammedlemmar (jag har funnit att detta inte är ett bra sätt att hålla saker enkla, för att vara ärlig).

Båda gångerna Mäd försökte skala, nästan gick det i konkurs. Uppenbarligen förstår jag nu varför — jag visste inte tillräckligt om ekonomi, att anställa begåvade teammedlemmar eller projektledning för att vara effektiv på den nivån. Men framför allt var företaget för stort och otympligt för att jag skulle ha full insyn och kontroll. Jag kunde helt enkelt inte hålla koll på alla dess människor, processer och operationer.

Stora organisationer ser bra ut på papper med sina långa listor av kunder, imponerande CV:n av teammedlemmar och glansiga marknadsföringsmaterial. De signalerar framgång, vilket kan vara upplyftande för entreprenörer och grundande team.

Problemet är att storlek inte nödvändigtvis motsvarar effektivitet. Faktum är att stora organisationer ofta lider av ett antal problem som gör dem långsammare, mindre smidiga och mindre effektiva än sina mindre motsvarigheter.

För att ge dig ett exempel: båda mina organisationer, Mäd och Blue, är små företag. De delar ett kontor, har små team, och jag känner allas namn.

Detta är inte en olyckshändelse; det är medvetet.

Det fanns aldrig några större problem när teamantalet hölls under 25, men båda gångerna det gick över detta, verkade allt falla isär. Men, när vi fokuserade på kvalitet istället för kvantitet, lyckades vi växa genom att höja våra priser istället för vår personalstyrka.

Beviset på detta är att Mäd har haft möjlighet att arbeta med hundratals projekt med dussintals kunder över en mängd olika branscher. Och jag har hört så många skräckhistorier om kunder som spenderar absurda mängder pengar och tid på att arbeta med stora konsultbyråer, med väldigt lite att visa för det. När de arbetar med Mäd, är det som en frisk fläkt — ingen bullshit (dvs. komplexitet), bara fokus på arbetet som ska göras (ofta för en bråkdel av priset av de stora konsultbyråerna).

Så, jag har kommit fram till slutsatsen att det finns en stark invers korrelation i konsultföretag mellan storleken på företaget och kvaliteten på de tjänster som erbjuds. Jag kan med säkerhet säga att sättet att hålla saker enkla faktiskt är att vara mycket medveten om det.

Och du kommer att bli förvånad över att upptäcka att det kan vara svårare att hålla ditt företag enkelt och rakt på sak än att låta det växa och bli överdrivet komplicerat!

Detta är varför det att försöka bygga och driva en stor konsultbyrå är ett säkert sätt att hoppa av klippan till komplexitet:

Stora konsultbyråer är mindre smidiga och agila.

Eftersom de är så stora, är det mycket svårare för dem att snabbt ändra riktning eller pivotera när det behövs. De är också mer byråkratiska, med fler lager av ledning som måste godkänna beslut. Detta kan göra dem mycket långsamma och oresponsiva, vilket kan vara en stor nackdel jämfört med mindre organisationer.

Stora konsultbyråer har ofta en "one-size-fits-all"-strategi.

De tenderar att erbjuda samma lösningar till alla sina kunder, oavsett de specifika behoven hos dessa kunder. Denna "cookie-cutter"-strategi är inte idealisk, eftersom den inte tillåter anpassning eller skräddarsydda lösningar för att möta de unika behoven hos varje kund.

Stora konsultbyråer kan vara oflexibla och kompromisslösa.

De har ofta mycket rigida processer och procedurer på plats, vilket kan göra dem mycket svåra att arbeta med. Detta kan vara en stor frustration för kunder som behöver mer flexibilitet och smidighet från sina tjänsteleverantörer.

Stora konsultbyråer tenderar att vara dyrare.

Eftersom de har mer overhead och högre kostnader, tar stora konsultbyråer vanligtvis mer betalt för sina tjänster än mindre organisationer. Detta kan vara en stor avskräckande faktor för kunder som letar efter värde för pengarna.

Stora konsultbyråer har ofta svårt att attrahera och behålla toppkompetens.

De bästa och smartaste anställda föredrar ofta att arbeta för mindre, mer smidiga organisationer där de kan ha större påverkan och göra mer skillnad. Som ett resultat kan stora konsultbyråer ha svårt att attrahera och behålla toppkompetens, vilket kan göra det svårare för dem att erbjuda den bästa möjliga servicen till sina kunder.

Vad som komplicerar saker ännu mer, ovanpå alla dessa tidigare punkter, är kommunikationsöverhuvudet.

Här kommer vi tillbaka till ämnet att arbeta med människor. I allmänhet beror hur enkel eller komplex din organisation är på faktorer som storleken på teamet, individuella teammedlemmars arbetsprocesser och deras resultat.

Det finns ingen organisation med 50 000+ anställda i världen som består av ett 50 000-personers team som arbetar harmoniskt tillsammans. En organisation med 50 000 består faktiskt av, ge eller ta, 2 000 team med 25 personer vardera.
Och ju fler team (och teammedlemmar) du har, desto fler kommunikationstrådar bildar de.

För att hedra min matematiklärare som jag nämnde i början av detta kapitel, låt oss tillämpa den kunskapen och räkna lite.

Vi kan använda denna ekvation för att beräkna kommunikationstrådarna inom ett företag.

n(n-1)/2 = Antalet möjliga kommunikationstrådar*

Där n är antalet personer som behöver vara involverade i projektet.

Om vi sätter in siffrorna, vid 50 000 anställda finns det 1 249 975 000 möjliga direkta kommunikationstrådar.

Men låt oss vara generösa och anta att det bara är teamen som behöver samordna, inte varje individ. Så, vi har 2 000 team, och med vår ekvation får vi 1 999 000 möjliga direkta kommunikationstrådar.

Observera att detta också är en förenkling eftersom det finns flera tillgängliga kommunikationskanaler, så vi kan enkelt multiplicera ovanstående siffror med fem.

Okej, men vad spelar det för roll?

Jo, resultatet är att detta otroliga överhuvud i kommunikationen innebär att i stora organisationer vet inte vänster hand vad höger hand gör. Och medlemmarna i dessa organisationer är medvetna om detta, så de skapar regler för att försöka bekämpa detta problem — till slut hamnar vi med högst formaliserade ritualer och regler för att säkerställa tät kommunikation i projekt.

Lägg till problemet att stora organisationer tenderar att ha teammedlemmar spridda över hela världen, och det finns frågan om olika tidszoner, så kan vi se vart detta är på väg...

Mycket byråkrati och mycket mindre arbete gjort. Mycket diskussioner och samordningsmöten, men inte mycket djupgående arbete av individer. Mer ledning, färre verkliga görande.

Kort sagt, överväldigande komplexitet.

Så, hur kan du motverka detta?

Gör det till en prioritet att noggrant välja och odla det bästa — och minsta — möjliga teamet.

När det kommer till att definiera små team, gillar jag att luta mig mot Jeff Bezos' Two Pizza Rule: om du inte kan mata hela teamet med två pizzor, är det för stort. Dela några teammedlemmar och skapa ett separat team, eller tänk om hur ni gör saker.

Roligt nog gör små team det bättre genom att göra mindre — vilket låter motsägelsefullt men verkligen är till din fördel. Detta beror på att individuella teammedlemmar i ett litet team inte bara är mer effektiva, utan de har också ett tydligt sätt att definiera vad de behöver arbeta med.

Visst, 17 000 personer i en stor organisation kan åstadkomma mycket mer än ett team på 15, och de kommer inte heller att drabbas lika mycket om deras produktivitet minskar med några personer eller halveras. När man tänker på det, i stora organisationer kan du göra nästan allt fel och ändå bli buren av den allmänna organisatoriska momentum.

Men, det finns faktiskt en betydande, men kontraintuitiv fördel med att göra mindre. Om du gör mindre, kommer du att vara mycket mer selektiv i vad du säger "ja" till. Potentiella projekt och idéer måste gå igenom en rigorös analys innan du börjar arbeta med dem eftersom resurserna är knappa.

Detta är en enorm fördel eftersom hela sättet att fokusera är genom att säga nej till distraktioner — de oändliga blanka objekten i fjärran som tar dig bort från din förutbestämda väg. Att ha ett tydligt definierat sätt att utvärdera vad som är och inte är en prioritet är utmärkt för att hålla saker enkla.

Så den centrala frågan som varje teammedlem bör ställa sig själv är:

Arbetar jag med det som mest sannolikt kommer att driva vår organisation mot våra angivna mål så snabbt som möjligt?

När de svarar på denna fråga när de utvärderar arbete, måste små team tänka på de långsiktiga konsekvenserna av arbetet. Till exempel, hur mycket overhead och underhåll kommer detta projekt att kräva i framtiden?

Dessa bekymmer är viktiga eftersom det är lätt att bygga upp tröghet över tid eftersom det finns så många rörliga delar som du måste se till att fungerar — oavsett vilken bransch du är i. Det hjälper till att eliminera onödiga komplexiteter innan de får chansen att ta över.

Små team gör också mindre eftersom de är mer benägna att använda strategier som outsourcing (särskilt vissa typer av on-demand-arbete kontra långsiktiga kontrakt) och automatisering. Detta är ett annat sätt att upprätthålla enkelhet eftersom det tar bort behovet av att expandera — och därmed komplicera — teamet och dess kommunikationslinjer.

Till exempel, istället för att anställa en heltids grafisk designer, kan ett litet team använda en online-tjänst för uppgiftsbaserat designarbete. En större organisation skulle sannolikt anställa en heltidsdesigner eller lägga ut ett stort kontrakt på budgivning för olika byråer och sedan behöva spendera tid på att intervjua olika byråer, göra urvalsprocessen, och så vidare.

När det gäller automatisering, är detta kopplat till min tidigare punkt att varje person i ett litet team måste ta fullt ansvar för det arbete de gör, och så de kommer sannolikt att vilja undvika så mycket rutinarbete som möjligt. I större team kan du ha en överflöd av junior teammedlemmar eller praktikanter som du kan sätta på vilket problem som helst, så automatisering är mindre viktigt än det borde vara.

Med min erfarenhet av att starta och driva Blue, säkerställer ett litet team också att produktfunktioner och förbättringar levereras på ett inkrementellt sätt istället för att tänka i termer av stora funktionssläpp. Detta beror på att det vanligtvis bara är en person som arbetar med en funktion, och vi vill inte vänta i sex månader på att allt ska vara perfekt innan vi får det i händerna på kunderna.

Så, den bästa idén är att granska hela omfattningen, skära ner den avsevärt, kalla det en V1, arbeta med det och leverera det. Sedan kommer vi in i den stora cykeln av att ha riktiga kunder som använder den nya funktionen, får feedback och sedan itererar baserat på det.

Faktum är att vi inte har en enda dedikerad mjukvarutestare på Blue. Personen som bygger funktionen är ansvarig för testningen, och sedan testar hela teamet funktionen också. Sedan levererar vi det till en offentlig beta-version av Blue som används av hundratals kunder, och de testar också och ger feedback. Vi har lyckats outsourca vår slutliga end-to-end-testning till våra kunder — utan kostnad.

Idén om att ha en offentlig beta som vem som helst kan få tillgång till bara genom att ändra URL:en för vår webbapplikation var en bra idé eftersom det sparade oss från att växa vårt team med 10-20% för att inkludera testare.

Med allt detta sagt, missta dig inte — att driva ett litet team är inte lätt och inte alltid enkelt. Om du är ett team på fem kan du enkelt förlora 40% av din kapacitet genom att ha en person på semester och en annan sjuk. Så produktivitet spelar roll, och varje individ är mycket viktigare för den övergripande riktningen för organisationen.

Mitt viktigaste råd här är att omfamna enkelhet och springa så snabbt du kan från komplexitet.

Vägra att ha överdrivet komplicerade processer som kräver extra arbete bara för att "så här gör vi det här."

Komplexitet föder komplexitet: innan du vet ordet av har du 50 personer som gör samma mängd arbete som kunde göras av 8.
Istället, som ledare, se till att hålla teamen små — mycket mindre än du tror är möjligt.

Du bör ständigt titta runt och känna dig överraskad över hur mycket ditt team åstadkommer. Detta bör vara en chock för utomstående också. Du bör höra saker i stil med "Åh, ni har bara x personer i ert team, det är fantastiskt!".

Världen rör sig för snabbt för överdrivet komplexa organisationer med hierarkier och politik. Framtiden tillhör de som är smidiga, de som omfamnar förändring, och de som har modet att satsa på sig själva.
Så, gå ut där och ta den utmanande men belönande vägen till enkelhet — med ett litet team!

AI-assistent

Svar genereras med hjälp av AI och kan innehålla misstag.

Hur kan jag hjälpa dig?

Fråga mig vad som helst om Blue eller denna dokumentation.

Tryck Enter för att skicka • Shift+Enter för ny rad • ⌘I för att öppna