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.

Iedereen haat vergaderingen

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".

Wat is 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".

💡We hebben nu de 17.000 issue mark gepasseerd. Zoveel vergaderingen die niet het daglicht zagen en zoveel uren bespaard! Deze geschiedenis van onze kennis is waardevol: doe gewoon een beetje onderzoek op onze Github om de ins en outs van elke beslissing te begrijpen. En als we het willen bevragen, weten we al welke argumenten in het verleden hebben gewonnen.

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).

Stel jezelf de juiste vragen

• Wie zal worden beïnvloed door de beslissing?

• Hoe omkeerbaar is de beslissing?

• Is dit een dringende beslissing om te nemen?

• Heb ik meer context nodig om te beslissen?

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.

Lead

Beschrijving

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.

Bijzonderheid

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.

Missie

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

• ➡️ Zorgen dat hij/zij het eens is met de beslissing die in overweging wordt genomen.

• ➡️ Vertrouwen hebben in de "Owner" en verantwoordelijkheid accepteren voor wat er door het team wordt geproduceerd.

• ➡️ Mening uiten wanneer er een sterke onenigheid is.

Verdeling

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

Owner

Beschrijving

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

Bijzonderheid

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

Missie

Als dirigent, moet hij of zij:

• ➡️ Zorgen dat elk van de bijdragers op de hoogte is van de discussie (en tijdig bijdraagt)

• ➡️ Het probleem onderzoeken, antwoorden verzamelen en de opvolging van het project doen.

• ➡️ De discussie openen en sluiten. De uiteindelijke beslissing nemen en delen.

Verdeling

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

Geraadpleegd

Beschrijving

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

Bijzonderheid

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.

Missie

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.

Verdeling

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.

Geïnformeerd

Beschrijving

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

Bijzonderheid

Communicatie met deze Alaners is eenrichtingsverkeer.

Missie

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

Verdeling

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:

Eenrichtingsbeslissing (moeilijk om te keren)

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)

Tweerichtingsbeslissing (gemakkelijk om te keren)

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.

"Scope" - Definieer de reikwijdte en verduidelijk het "waarom" van de discussie

• "Het doel van deze uitkomst is..." -

• "Dit issue gaat NIET over..."

"Context & materialen" - Voorzie context en nuttige bronnen

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

"LOCI" - Verduidelijk verantwoordelijkheid en verdeling van contactpersonen

• Lead

• Owner

• Geraadpleegd

• Geïnformeerd

Stel een deadline

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

Deel een oplossingsvoorstel

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

Richt je tot vragen

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.

Effectiever schrijven

Wees bondig en duidelijk

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.

Pas de "So what?" test toe.

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.

Opvolging

Focus op de "Million Dollar Question

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.

Regelmatig samenvatten van overeengekomen punten

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.

Herlanceren op Slack als laatste redmiddel

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.

Verberg irrelevant commentaar

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.

Toetsenbord snelkoppelingen

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

Pagina-indeling

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.

Vermijd consensusbesluitvorming

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.

Beperk het aantal bijdragers

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).

Adopteer een progressieve meldingsaanpak

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.

Stel je account in om meldingen te ontvangen

• Ga naar de "Instellingen" pagina

• Vink de "Web en mobiel" vakjes aan in de "Deelnemende" en "Kijkende" secties

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:

• We beperken de onderbrekingen: vaarwel de ongeplande vergaderingen en de vloedgolf aan bijbehorende meldingen.

• We verminderen het toeschouwerseffect: vaarwel geremde deelname en aanwezigheidsdruk.

• We verbeteren de kwaliteit van onze beslissingen: welkom bij het nemen van afstand en feitelijk zijn.