Hoe neem je beslissingen in een asynchrone werkomgeving? Onze methode bij Alan

In de meeste bedrijven heb je een vergadering om een beslissing te nemen. Bij Alan beginnen we een schriftelijke conversatie, een "issue" genoemd, in een online forum. Deze gesprekken vormen de hoeksteen van onze cultuur van transparantie, asynchronie en schrijven. Het is voor elke Alaner belangrijk om de gesprekstechnieken van dit forum onder de knie te krijgen. Dit is hoe we het doen.

Niemand komt voorbereid, het begint te laat, en de persoon met de luidste stem heeft altijd het laatste woord, terecht of onterecht. Een uur later is je hoofd nog meer in de war dan voordat je de kamer binnenkwam en vraag je je af of je nog paracetamol over hebt. Maar je bent eraan gewend, tenslotte is vergaderitis het handelsmerk van elk zichzelf respecterend bedrijf, toch?

Wat als we je vertelden dat we de dingen anders zouden kunnen doen? Bij Alan detecteerden we al heel vroeg de grenzen en risico's van vergaderingen. Onze vergaderingen waren ontworpen om kort te zijn (niet meer dan 15 minuten), goed georganiseerd (een duidelijke agenda) en dus beslissingen te produceren. Het probleem was dat we vaak van het pad afraakten - het is moeilijk om discussies onder controle te houden. Als gevolg daarvan waren we vaak teleurgesteld, hadden we moeite om te onthouden wat er was gezegd, en was het gecompliceerd met mensen die afwezig of op afstand waren.

Dus besloten we om wat we traditioneel mondeling deden... op papier te zetten!

Het resultaat: we nemen betere beslissingen, omdat schrijven ons dwingt de tijd te nemen om na te denken. De discussie is genuanceerder, beter gedocumenteerd en geargumenteerd. Kortom, het is niet langer een welsprekendheidswedstrijd. En de kers op de taart is dat het vervangen van vergaderingen door een geschreven intern forum de autonomie van iedereen vergroot: door informatie openbaar beschikbaar te maken, is de mogelijkheid om bij te dragen aan de discussie toegenomen en is samenwerking gemakkelijker geworden.

Wil je weten hoe we dat doen? We leggen alles voor je uit.

Nu, wanneer we de intelligentie van het team nodig hebben om een probleem op te lossen, om een onderwerp te verdiepen, om oplossingen te valideren, in plaats van een vergadering in te plannen, openen we een gesprek (of "issue"), op ons online forum. Dit forum wordt gehost op een platform genaamd "Github".

In eerste instantie is het een collaboratief platform ontworpen voor webontwikkelaars. Het idee is om feedback over de door hen gecreëerde code te delen en te centraliseren. We vonden de afweging tussen sociaal platform en gestructureerd feedbackbeheer interessant, dus we besloten het gebruik ervan af te leiden om al onze besluitvormingsgesprekken bij Alan te hosten.

1 - We hebben een account aangemaakt op Github.

2 - We hebben een nep "code" directory aangemaakt en deze "private" gemaakt (we noemden het "Topics" bij Alan's om te beslissen over de onderwerpen van het leven 😇)

3 - Er werd een labeling systeem gecreëerd om elk gespreksonderwerp makkelijker te onderscheiden.

4 - We gaan naar het "Issues" tabblad van onze directory om al onze huidige "open" discussies te vinden - en de genomen beslissingen "gesloten".

Open of niet open een discussie, dat is de vraag. Efficiëntie vereist, we weten dat elke beslissing niet systematisch rechtvaardigt het openen van een issue. Als sommige in een paar dagen kunnen worden opgelost, kunnen andere meer dan een week duren... Dus, om ervoor te zorgen dat we betere beslissingen nemen, sneller, hebben we een systeem ontwikkeld (we houden van ze bij Alan).

Over het algemeen wordt er een issue geopend wanneer de graad van impact en omkeerbaarheid van een beslissing als belangrijk wordt beschouwd. Simpel gezegd, hier zijn de gevallen waarin we een discussie op ons forum verkiezen boven een op Slack:

We gebruiken het LOCI (Lead, Owner, Consulted, Informed) model om de verantwoordelijkheid en de verdeling van onze gesprekspartners op een evenwichtige manier te verduidelijken in elk van onze discussies.

De Lead is verantwoordelijk voor het succes van een beslissing. Hij/zij zorgt ervoor dat de context achter elke beslissing correct wordt begrepen en verspreid binnen het team.

Aan het begin van de discussie geeft hij aan in hoeverre hij betrokken wil worden bij de beslissing, zodat de Owner alle kaarten in handen heeft om te arbitreren.

Wanneer de Lead niet de uiteindelijke beslisser (Owner) is, moet hij/zij:

Er moet slechts één "Lead" per discussie zijn.

De Owner is verantwoordelijk voor de uiteindelijke beslissing en leidt het project om het vastgestelde doel te bereiken.

Als hij een probleem tegenkomt dat hij niet kan oplossen, moet hij zich tot de Lead wenden.

Als dirigent, moet hij of zij:

Het wordt aanbevolen dat slechts één persoon verantwoordelijk is voor elke beslissing.

De "geraadpleegde" Alaners zijn degenen wiens mening telt in het besluitvormingsproces. Hun bijdrage wordt als essentieel beschouwd om de best mogelijke afweging te maken.

Ze geven de controle over aan de beslisser (Owner). In geval van sterke onenigheid moeten ze alarm slaan en, in het slechtste geval, de informatie escaleren naar de Lead.

Als actieve bijdragers aan de discussie, zijn ze verplicht om tijdig bij te dragen, zelfs als het alleen maar is om te bevestigen dat ze niets aan de discussie toe te voegen hebben.

Het wordt aanbevolen om niet meer dan 6 Alaners "geraadpleegd" per discussie te notificeren. Hoewel hun bijdrage essentieel is, zou dit een vertraging in het schema kunnen veroorzaken.

Dit zijn Alaners die op de hoogte worden gehouden van de voortgang, vaak nadat de beslissing is genomen.

Communicatie met deze Alaners is eenrichtingsverkeer.

Als "geïnformeerde" Alaner wordt er geen bijdrage van hun kant verwacht.

De beslisser moet rekening houden met de potentiële impact van de beslissing en de betrokken Alaners dienovereenkomstig op de hoogte stellen.

Oké, maar hoe evalueren we deze drempel van belang? Alan onderscheidt twee soorten beslissingen:

Dit zijn beslissingen die te veel inspanning of aanzienlijke kosten zouden vereisen om te keren. Voorbeeld: de update van onze tarieven naar boven bijgesteld (hoewel we deze al naar beneden hebben bijgesteld)

Dit zijn beslissingen die op het eerste gezicht niet te veel risico met zich meebrengen. Een onvoorziene gebeurtenis zou kunnen leiden tot een verlies van energie, dit is acceptabel.

Het kaderen van een project of discussie helpt ons betere beslissingen te nemen.

Kaders zijn werkinstrumenten, ze verbieden het denken niet. Integendeel, ze stellen ons in staat om ons standpunt te structureren en te verduidelijken.

Om ons te helpen onze gedachten over een probleem of besluit zo effectief mogelijk te communiceren, biedt elk issue een identieke sjabloon. Deze structuur stelt ons in staat om een niveau verder te gaan, terwijl we junior mensen leren hoe ze een probleem kunnen afbreken.

We voegen links toe naar alle discussies of documenten die context bieden.

We delen hier onze verwachtingen: deadline om bij te dragen, datum van sluiting van de issue, datum waarop een oplossing moet worden gevonden.

We beschrijven hier een mogelijke oplossing voor het probleem of stellen enkele oplossingen voor om uit te kiezen.

Iedereen wiens meningen en deelname nuttig zullen zijn bij het nemen van een goed geïnformeerde beslissing wordt uitgenodigd om deel te nemen. Om het debat in de juiste richting te sturen, stelt de discussieleider specifieke vragen aan de belangrijkste bijdragers om aannames te bevestigen of te weerleggen - en om te voorkomen dat er een fles in zee wordt gegooid.

Om te voorkomen dat het debat rond een beslissing aansleept, hanteren we een aantal regels om de discussie op het wezenlijke te concentreren.

We geloven in nuttig schrijven: "Wat goed bedacht is, wordt duidelijk uitgedrukt", zei Boileau. Als we iets niet eenvoudig op papier kunnen zetten, betekent dit dat we niet zeker zijn van de juistheid van onze uitspraak.

Elke keer dat we iets schrijven, lezen we het opnieuw en stellen we onszelf de vraag "So what?" Dit helpt ons om de implicaties of argumenten van onze boodschap beter te begrijpen. Als het antwoord voor de hand ligt, helpt het om potentiële vragen duidelijker te beantwoorden.

Het verzamelen van veel verschillende meningen kan verwarrend zijn, het focussen op HET belangrijkste vraagstuk of struikelblok helpt om te focussen op de prioriteit, het herfocussen van de bijdragen van collega's - zonder verloren te gaan in de zee van details.

Het verduidelijken van wat collectief is overeengekomen en wat nog besproken moet worden, is een gangbare praktijk voor de eigenaar van een Github gesprek. Het is een manier om beter zicht te geven op de bijdragelijnen aan zijn collega's, het is ook een manier om gefocust heen en weer te voorkomen op lagere prioriteitskwesties - het doel van het gesprek moet altijd de Noordster blijven volgen.

We beperken het aantal herinneringen op Slack. Twee uitzonderingen: wanneer bijdragen te laat zijn of wanneer urgentie snelle actie vereist. Om ervoor te zorgen dat de agenda wordt gerespecteerd, wanneer een eigenaar meningen moet vergelijken om een geïnformeerde beslissing te nemen, kan een herinnering op Slack worden gebruikt.

Sommige threads kunnen veel reacties hebben. Als eigenaar kan het nuttig zijn om alleen die bijdragen te bewaren die het gesprek vooruit helpen.

Als het erop aankomt een standpunt schriftelijk over te brengen, doet de inhoud er evenveel toe als de vorm. Hier is hoe we het meeste uit ons Github forum halen.

Om tijd te besparen, hier is de volledige lijst van Github toetsenbord snelkoppelingen.

Het toevoegen van titels (H1, H2, H3), voetnoten of zelfs tabellen om body aan je ideeën te geven is mogelijk op Github. Hier is de volledige lijst van instructies.

Met ons issue systeem kan iedereen deelnemen aan alle discussies. Er is geen gefluister, geen geheimen, geen politiek: iedereen heeft dezelfde informatie - maar er zijn bepaalde voorwaarden om in gedachten te houden om teleurstelling te voorkomen.

Bij Alan heeft elke beslissing die op ons forum wordt besproken een enkele aangewezen "eigenaar" die verantwoordelijk is voor het beslissen als een "verlichte despoot". Haar rol is om de best mogelijke beslissing voor het bedrijf te nemen, zonder consensus te zoeken en zonder politiek. Om dit te doen, moet ze innovatieve ideeën onderzoeken, risico's meten, gegevens analyseren, en haar collega's bevragen, zonder alles te moeten implementeren wat ze haar vertellen. In ons bedrijf is besluitvorming niet consensueel, we zijn geen "democratie". Iedereen is aandeelhouder en dus eigenaar van Alan. Elke Alaner plaatst de belangen van het bedrijf boven die van het team of het individu. We willen echter geen geïsoleerde, overhaaste of ongeïnformeerde besluitvorming.

Een effectieve beslissing is er een die zich beperkt tot de meningen van de belangrijkste bijdragers. Ken je de "twee pizza's of niets" regel van Jeff Bezos? Zijn idee is gebaseerd op een bekend feit: als er te veel mensen in een vergadering zijn, is het inefficiënt. Asynchrone besluitvorming is geen uitzondering op deze regel: over het algemeen geldt dat hoe meer mensen er zijn, hoe minder ze bijdragen. Op afstand treedt dit "toeschouwerseffect" - dat de algemene deelname belemmert en de kwaliteit van deelname verandert - op wanneer het aantal bijdragers aan een issue niet onder controle wordt gehouden (bij meer dan 6 mensen wordt het gecompliceerd).

Door het creëren van ruis, maken meldingen het moeilijk om onderscheid te maken tussen het belangrijke en het triviale. Daarom passen we bij Alan de regel van progressieve melding toe: we vertrouwen elkaar. We gaan ervan uit dat elke Alaner zijn Github-account correct heeft ingesteld om meldingen te ontvangen. Daarom beperken we het aantal tags van mensen in de "Vragen" sectie van elk issue.

Zelfs met de beste wil van de wereld is het moeilijk om alles wat er in een vergadering is gebeurd uit te leggen aan iemand die er niet bij was. Maar iedereen in een team kan zich inleven in een beslissing.

Natuurlijk is ons systeem van besluitvorming door middel van een forum niet de beste noch de enige mogelijke oplossing om dit probleem aan te pakken: het is gewoon de oplossing die het meest op ons lijkt omdat: