Gall's Law - og hvad det har at gøre med Startups

Jeg indså noget fascinerende forleden: Jeg indså, at jeg som opstartsentreprenør og grundlægger er en bygherre af systemer.

Med andre ord, hele mit job som grundlægger er at opbygge og forbinde indbyrdes afhængige systemer, der (forhåbentlig) fungerer meget godt sammen.

Og hvis jeg kan konstruere disse systemer på en måde, der er både enkel og tilgængelig til at blive forstået og til at begejstre andre, så vil det være nok til at overbevise uafhængige, kreative og motiverede mennesker om at deltage i min indsats for at konstruere endnu mere systemer (og endnu flere relationer mellem disse systemer), der til sidst vil samle sig i form af en verdensklasse organisation.

Jeg mener, hvad er en virksomhed, hvis ikke en samling af systemer, organiseret på en måde til at maksimere kapacitet, optimere ydeevne og producere for store resultater (dvs. overskud)?

Og det er her startups har en utrolig fordel i forhold til ældre og meget større virksomheder: En startup har mulighed for selv at beslutte ikke kun, hvad de grundlæggende og vigtigste systemer vil være, og hvordan de skal fungere, men også den måde, hvorpå organisationen beslutter, hvilke nye systemer der skal bygges, og hvordan de skal integreres og føjes til den eksisterende, større metasystem.

Og ”meta-systemet” er simpelthen en samling af tro og den resulterende adfærd, der er blevet generaliseret og normaliseret i hele organismen. Man kan kalde denne organisationskultur; forhåbentlig er det en, der er bygget på tillid.

Gall's lov er især anvendelig og vigtig for nye virksomheder - de har brug for at tage tiden den nødvendige tid til bevidst og eksplicit at tænke på de systemer, de bruger, så de får en kæmpechance til at konstruere deres verdensændrende ideer til reelle tjenester og produkter, som folk virkelig ønsker.

Ser du, John Galls arbejde er blevet tommelfingerregel for systemdesign og er blevet brugt som et meget stærkt argument for underspecifikation (det er her alle opstart starter):

Et komplekst system, der fungerer, viser sig altid at have udviklet sig fra et simpelt system, der fungerede. Et komplekst system designet fra bunden fungerer aldrig og kan ikke lappes sammen for at få det til at fungere. Du skal starte forfra med et simpelt arbejdssystem.

Det er her, startups skal være hypervagante og følelsesmæssigt opmærksomme og modne nok til at vide, at de kan gøre uoprettelig og permanent skade på deres chancer for succes, hvis de enten bevidst eller utilsigtet skiller sig fra det eller de grundlæggende systemer. deres unikke indsigt faktisk anvendelig.

Jeg ved, fordi jeg har gjort dette for mig selv tidligere: Jeg har bygget over-komplicerede og over-engineered systemer og introduceret dem til mine teams kun for at opdage, at de har gjort meget mere skade end godt!

Derudover kodificerer nogle virksomheder disse principielle og originale systemer i mission- eller visionerklæringer eller understøtter dem som en del af deres virksomhedsværdier, mens andre ikke vil. Selv handlingen med at kodificere et forstået og brugt system er en forsætlig beslutning fra det grundlæggende team og ledelse!

Og fristelsen til at overudvikle noget (hvad som helst!) Er allerede ret stor; tilføj lidt forretningsmoment, et par nye ansættelser, en smidge (eller en masse) risikovillig kapital og et produkt, der ser ud til at virke, og du vågner pludselig en morgen og indser, at du og dit team er helt oppustet og overvægtig med snesevis af næsten ikke anvendte SaaS-webtjenester og masser af (sammensatte) processer, der med et ærligt blik ser ud til at eksistere for deres egen skyld.

Godt startende grundlægger - du har lige spillet dig selv.

Og vi havde sådan en god ting i gang! Du startede simpelthen, og tingene fungerede fint, og tilsyneladende natten over har du bakket dig op i et komplekst system af systemer, der “ikke kan lappes op for at få det til at fungere” - du bliver nødt til at nukleere et par ting for at komme tilbage basislinjen og den grundlæggende "perle", der fungerede.

Dette er grunden til, at de fleste større virksomheder ikke kan konkurrere mod de meget mindre og mere smidige opstart - omkostningerne ved reverse engineering eller dekonstruktion og demontering af et dysfunktionelt, komplekst system er ofte for store og for destruktive til at være en anstrengelse værd!

Derfor er det dysfunktionelle system “godt nok” for de fleste mennesker og den større organisation, og meget få mennesker er motiverede til at “hæve det hvide flag” og fortaler for det, der virkelig kræves: Start med et fungerende, simpelt system.

Det er klart, at startups, der med vilje har bygget en kultur af introspektion og hensynsløst gennemgår deres forældede og forældede systemer, vil klare sig meget, meget bedre end deres jævnaldrende og selvfølgelig deres større virksomhedskonkurrenter.

Startups begynder deres liv med enkle systemer og udvider og vokser naturligvis nye systemer, der generelt er boltet på en måde, som de fleste ville overveje tilfældige og hodge-podge. Samlingen af ​​enkle systemer danner komplekse systemer, og nogle af disse fungerer i lang tid, mens andre går i stykker meget hurtigt.

Den organisation, der anerkender deltaet i vellykkede og mislykkede integrationer mellem de nye systemer og de gamle, vil lykkes (og overleve) meget længere end dem, der forsætligt ignorerer dysfunktionen eller antager naivt, at det hele vil ordne sig selv undervejs.

Og de organisationer, der ikke kun anerkender hurtigt og med vilje arbejder sammen aktivt for at løse problemet, men også er villige til at, hvis situationen kræver ekstrem handling, demontere hele systemer for at opbygge nye, enklere til at understøtte vægten af ​​et nyt og helt forskellige organisationer (opstart kan fundamentalt ændre sig så ofte som hver 6. måned!).

Det er overflødigt at sige, at det er yderst vanskeligt at holde systemer enkle strategisk og taktisk, mens man klogt og forsætligt tilføjer dem, når organisationen skalerer.

Dette betyder ikke, at jeg er ekspert; snarere er jeg følelsesmæssigt opmærksom nok til at vide (og have empiriske beviser) for, at organisationer har tendens til kaos og entropi uden en jævn og konsekvent gennemgang af ikke kun hvad der gøres, men hvordan det gøres.

Og hvis jeg skal være endnu mere ærlig, ved jeg, at jeg har tendens til at introducere entropi til systemer, hvis jeg ikke er forsigtig! Faktisk ved jeg, at selvom jeg prøver hårdt, vil det være en opadgående kamp hvert eneste skridt på vejen.

Det er i holdets bedste interesse at gøre nogle, hvis ikke alle, af følgende:

  1. Planlæg i tide til at gennemgå dine systemer efter team og / eller organisationsafdeling (f.eks. Ops, engineering, marketing, salg osv.).
  2. Identificer, så godt du kan, det princip (originale) enkle system, der til sidst blev et komplekst system og tydeliggør de (forventede) output og de personer, der skulle være involveret.
  3. Skitsere og identificere den indbyrdes afhængighed af det system, der gennemgås; det vil sige de andre systemer, der har direkte samspil med det i anmeldelsen.
  4. Bedøm hensynsløst systemet og juster, beskær eller ødelæg det direkte og bygg derefter en ny, enklere version (eller gå måske tilbage til Genesis-versionen).
  5. Der kan være behov for konsensus eller ej, men uanset hvordan dit team træffer beslutninger, skal du sørge for, at alle er ombord med det nye (og forbedrede!) System, og at alle forpligter sig til ansvarlighed.
  6. Time-box eksperimentet og indstil en tid til gennemgang af det nyligt ændrede system. Kalender i en retrospektiv.
  7. Skyl og gentag.

Dette er en stor ting for mit firma og mig, især da vi er midt i at udvide vores team. Det er også relevant, fordi jeg har indset, at det er på høje tid for os at gennemgå de systemer, vi har bygget, og med en fin-tand kam tage den nødvendige tid til at optimere og (genopbygge) grundlaget for vores virksomhed.

Hvordan ellers kommer vi nogensinde til månen? ? ? ?

John er softwareingeniør hos YEN , en social platform, der kombinerer kraften i sociale netværk og flere kryptovalutaudvekslinger.