Galli seadus - ja mis see on seotud alustavatega

Mõistsin eelmisel päeval midagi põnevat: mõistsin, et olen alustava ettevõtja ja asutajana süsteemide ehitaja.

Teisisõnu, kogu minu ülesanne asutajana on ehitada ja ühendada üksteisest sõltuvaid süsteeme, mis (loodetavasti) töötavad ülihästi koos.

Ja kui ma suudan need süsteemid üles ehitada nii lihtsal kui ka piisavalt ligipääsetaval viisil, et neist aru saada ja teisi erutada, siis piisab, kui veenda sõltumatuid, loovaid ja motiveeritud inimesi liituma minu jõupingutustega veelgi rohkem insenerida süsteemid (ja veelgi enam nende süsteemide vahelisi suhteid ), mis lõpuks ühinevad maailmatasemel organisatsiooni näol.

Ma mõtlen, mis on äri, kui mitte süsteemide kogum, mis on korraldatud viisil, et maksimeerida läbilaskevõimet, optimeerida jõudlust ja toota väljamõõdulisi tulemusi (st kasumit)?

Ja siin on alustavatel ettevõtetel uskumatu eelis vanemate ja palju suuremate ettevõtete ees: alustaval ettevõttel on võimalus ise otsustada mitte ainult selle üle, millised on põhi- ja põhisüsteemid ning kuidas need toimivad, vaid ka viisi, kuidas organisatsioon otsustab, milliseid uusi süsteeme ehitada ning kuidas need integreeritakse ja lisatakse olemasolevasse, suuremasse metasüsteemi.

Ja “metasüsteem” on lihtsalt kogu organismis üldistatud ja normaliseeritud uskumuste ja sellest tulenevate käitumisviiside kogum. Võib nimetada seda organisatsioonikultuuri; loodetavasti on see üles ehitatud usaldusele.

Galli seadus on uute ettevõtete jaoks eriti kohaldatav ja oluline - neil tuleb võtta aega, mis on vajalik nende süsteemide tahtlikuks ja selgesõnaliseks mõtlemiseks, et neil oleks võitlusvõimalus oma maailmamuutvaid ideid reaalseteks teenusteks ehitada ja tooteid, mida inimesed tõesti tahavad.

Näete, et John Galli tööst on saanud süsteemide kujundamise rusikareegel ja seda on kasutatud väga tugeva argumendina alamspetsifikatsiooniks (sellest saavad alguse kõik idufirmad):

Toimiv keerukas süsteem on alati välja töötatud lihtsast toimivast süsteemist. Nullist kujundatud keeruline süsteem ei tööta kunagi ja seda ei saa selle toimimiseks lappida. Alustada tuleb lihtsa toimiva süsteemiga.

Siinkohal peavad alustavad ettevõtted olema ülimalt valvsad, emotsionaalselt teadlikud ja piisavalt küpsed, et teada saada, et nad võivad oma õnnestumisvõimalustele korvamatut ja püsivat kahju teha, kui nad kas tahtlikult või kogemata lahutavad end alusetust (süsteemidest), mis nende ainulaadne ülevaade on tegelikult kasutatav.

Ma tean, sest olen seda endale varem teinud: olen ehitanud liiga keerukaid ja üle kavandatud süsteeme ning tutvustanud neid oma meeskondadele ainult selleks, et avastada, et nad on teinud palju rohkem kahju kui kasu!

Lisaks kodifitseerivad mõned ettevõtted need põhimõtted ja algsüsteemid missiooni või visiooni avaldusteks või toetavad neid osana oma ettevõtte väärtuse avaldustest, teised aga mitte. Isegi arusaadava ja kasutatud süsteemi kodifitseerimine on asutajameeskonna ja juhtkonna tahtlik otsus!

Ja kiusatus midagi (midagi!) Üle konstrueerida on juba üsna suur; lisage natuke äritegevust, mõned uued töötajad, riskikapital (või palju) riskikapitali ja toode, mis näib töötavat, ja ärkate ühel hommikul äkki ja mõistate, et teie ja teie meeskond on täielikult ülespuhutud ja ülekaalulised kümnete vaevu kasutatavate SaaS-i veebiteenuste ja hulga (väljamõeldud) protsessidega, mis näivad ausa pilguga eksisteerivat nende endi huvides.

Hea töö alustamise asutaja - sa lihtsalt mängisid ennast.

Ja meil oli nii hea asi! Alustasite lihtsalt ja asjad toimisid suurepäraselt ning näiliselt olete üleöö toetanud end keerulisse süsteemivõrku, mida "ei saa selle toimimiseks lappida" - peate tagasi pöörduma mõne asja nimel baasjoon ja töötav aluspõhi “pärl”.

Sellepärast ei saa enamik suuremaid ettevõtteid konkureerida palju väiksemate ja väledamate idufirmadega - vastupidise inseneri või mittetoimiva ja keeruka süsteemi dekonstrueerimise ja demonteerimise kulud on sageli liiga suured ja liiga hävitavad, et jõupingutusi väärt olla!

Järelikult on düsfunktsionaalne süsteem enamiku inimeste jaoks "piisavalt hea" ja suurem organisatsioon - väga vähesed inimesed on motiveeritud "valge lipp heisama" ja propageerima seda, mida tegelikult vaja on: alustades töötamisest lihtsa süsteemiga.

Ilmselt lähevad idufirmad, kes on tahtlikult loonud sisekaemuskultuuri ja vaatavad halastamatult üle oma aegunud ja aegunud süsteemid, palju-palju paremini kui nende eakaaslased ja muidugi ka suuremad ettevõtluskonkurendid.

Startupid alustavad oma elu lihtsate süsteemidega ning loomulikult laiendavad ja kasvatavad uusi süsteeme, mis on tavaliselt kinnitatud viisil, mida enamik kaaluks juhuslikeks ja hodge-podge. Lihtsate süsteemide kogu moodustab keerukad süsteemid ja mõned neist töötavad pikka aega, teised aga lagunevad väga kiiresti.

Organisatsioon, mis tunnistab uute ja vanade süsteemide edukate ja ebaõnnestunud integreerimiste delta, saab edukalt hakkama (ja jääb ellu) palju kauem kui see, kes eirab tahtlikult düsfunktsiooni või eeldab naiivselt, et see kõik toimib ka ise.

Ja organisatsioonid, kes mitte ainult ei tunnista kiiresti ja sihilikult probleemi lahendamiseks aktiivselt, vaid on valmis ka juhul, kui olukord nõuab äärmuslikke meetmeid, lammutama terved süsteemid, et ehitada uued, lihtsamad süsteemid, et toetada uue ja kogu kaalu. erinev organisatsioon (idufirmad võivad põhimõtteliselt muutuda nii sageli kui iga 6 kuu tagant!).

Ütlematagi selge, et on äärmiselt keeruline süsteeme strateegiliselt ja taktikaliselt lihtsana hoida, samal ajal kui neid organisatsiooni mõõtmetega targalt ja tahtlikult lisada.

See ei tähenda, et olen ekspert; pigem olen ma emotsionaalselt piisavalt teadlik, et teada (ja mul on empiirilisi tõendeid), et organisatsioonid kalduvad kaosesse ja entroopiasse ilma järjepideva ja järjepideva ülevaateta mitte ainult seda, mida tehakse, vaid ka seda, kuidas seda tehakse.

Ja kui veel ausam olla, siis tean, et kui ma pole ettevaatlik, kipun süsteemidele entroopiat kasutusele võtma! Tegelikult tean, et isegi kui ma pingutan kõigest väest, on see igal sammul ülesmäge.

Meeskonna huvides on teha mõned, kui mitte kõik järgmistest:

  1. Planeerige õigeaegselt oma süsteemide ülevaatamine meeskonna ja / või organisatsiooni osakonna kaupa (nt ops, inseneritöö, turundus, müük jne).
  2. Tehke nii hästi kui võimalik kindlaks põhimõtteline (algne) lihtne süsteem, mis muutus lõpuks keerukaks ja selgitas selgelt (oodatavad) väljundid ja isikud, keda peaks kaasama.
  3. Visandada ja tuvastada ülevaatatava süsteemi vastastikused sõltuvused; see tähendab, et muud süsteemid, millel on otsene koostoime ülevaates kirjeldatuga.
  4. Halastamatult hindage süsteemi ja kohendage, kärpige või hävitage see otse ning seejärel ehitage uus, lihtsam versioon (või pöörduge tagasi Genesise versiooni juurde).
  5. Võimalik, et konsensus on vajalik või mitte, kuid hoolimata sellest, kuidas teie meeskond otsuseid langetab, veenduge, et kõik oleksid uue (ja täiustatud!) Süsteemiga pardal ning kõik kohustuksid kindlalt vastutama.
  6. Märgistage katse aeg ja määrake värskelt muudetud süsteemi ülevaatamise aeg. Kalender retrospektiivis.
  7. Loputage ja korrake.

See on minu ja minu ettevõtte jaoks suur asi, eriti kuna oleme oma meeskonna kasvatamise keskel. See on asjakohane ka seetõttu, et olen aru saanud, et meil on viimane aeg oma loodud süsteemid üle vaadata ja peenhammaste kammidega võtta aega, mis on vajalik ettevõtte optimeerimiseks ja (taas) ülesehitamiseks.

Kuidas muidu me kunagi Kuule jõuame? ? ? ?

John on YEN-i tarkvarainsener , sotsiaalne platvorm, mis ühendab endas sotsiaalsete võrgustike ja mitme krüptoraha vahetuse.