Over Ons
      Healthy Business
      |
      Blog

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

      Hoe neem je beslissingen in een asynchrone werkomgeving? Onze methode bij Alan
      With
      Jean-Charles Samuelian
      Jean-Charles SamuelianCEO d'Alan
      Bijgewerkt op
      19 oktober 2023
      With
      Jean-Charles Samuelian
      Jean-Charles SamuelianCEO d'Alan
      Bijgewerkt op
      19 oktober 2023
      Deel het artikel

      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.

      Introductie

      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.

      1 - Een platform omvormen tot een online forum

      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.

      Concreet, hoe hebben we dit gedaan?

      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.

      2 - Definieer de regel: wanneer open je een "issue"? "

      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?

      Bepaal de graad van impact

      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:

      Belangrijke contacten

      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.

      Nuttige definities

      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.

      Een "probleemoplossende" benadering aannemen

      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.

      De typische architectuur van een issue

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

      Jezelf uiten in schrift

      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.

      Beheers de opmaak

      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

      .

      Vermijd de valkuilen: beslis asynchroon

      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

      Het laatste woord

      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.

      gepubliceerd op 27/02/2023

      Over hetzelfde onderwerp

      Healthy business is nu een Europese community.
      Healthy business is nu een Europese community.
      Nov 9, 2023

      Ontdek Healthy Business