Man with arms out saying something in front of an image

Så jævla enkelt å gjøre en lyntale!??🤷🏼‍♂️

Jeg hadde gleden av å snakke på årets Y Oslo konferansen. Denne posten handler om hvordan det gikk til, formålet er å vise at det er ulike måter et foredrag oppstår. Det handler ikke om å følge en mal eller oppskrift, fordi mennesker fungerer ulikt og det handler om å finne ens egen måte å gjøre ting på.

Veteranfaen, kommer og dreper alle samma
Bare bæsjer på dem, skriver mens jeg sitter på ramma
Bensin i kanna, svett i panna, fyrstikker i handa
Men jeg tenner ikke på meg sjæl selv om jeg blir forbanna
Blir forbanna, blir forbanna, jeg er sulten, jeg er sinna

“Loff” av Mae. Kilde: https://genius.com/Mae-no-loff-lyrics

Akkurat som Mae satt jeg på ramma og ble forbanna (Nesten da, jeg leste på Twitter, det er ganske likt det å sitte på dass egentlig. Det er 💩 overalt). Det var sånn det begynte. jeg leste om konferansen og 🔥ble forbanna🔥. Jeg rantet litt og det endte med at jeg i affekt 😡 sendte denne DM til Jostein i NetLife (arrangøren av konferansen):

Screenshot fra DM dialogen som startet resisen mot et fordrag

Jeg sendte etterpå en litt lengre versjon av ideen om foredraget, som var på ca 200 linjer. På dette tidspunktet hadde jeg ikke noen annen ide annet enn at jeg var forbanna på hele konseptet med en innovasjons konferanse.

Tida gikk og jeg glemte hele greia. Helt inntil det plutselig lander det en e-post fra Netlife i innboksen hvor det stod jeg var akseptert, jeg tenkte bare:

Å faen!

Meg da jeg leste e-posten om at jeg skulle holde foredrag på Y Oslo

Å gjøre ting instinktivt er noe jeg ofte gjør (litt for ofte vil noen si). Jeg har sendt inn utkast til foredrag mens jeg satt på ramma (bokstavlig talt, bare se bildet her hvor flisene fra vårt gamle bad vises). Fordi det handler om å agere på følelsene når de er de. Ikke analysere og rasjonalisere. Jeg handler uten å tenke noe mer enn at “dette har jeg lyst til”!

Utfordringen ved å gjøre noe uten å tenke det gjennom i særlig grader er at det ofte tar minst fire fem måneder fra en konferanse åpner for bidrag til du får bekreftelse. Ikke engang jeg klarer å holde på den forbanna følelsen SÅ lenge..

Hva var det jeg tenkte?

Tida fra jeg mottar et eventuelt positivt svar og til det nærmer seg deadline handler om å forsøke rekonstruere hva jeg tenkte. Enkelte ganger er det lett, andre ganger krever det ganske mye jobb å grave frem lidenskapen og tankene jeg hadde da jeg sendte inn. Samtidig som jeg irriterer meg over at jeg enda en gang har satt meg i denne situasjonen. Sånn var det også med denne lyntalen, hva i alle dager skal jeg si på tretten minutter?

Det e en vibe, det e ekstremsport

“Ekstremsport” av Myra. Kilde https://genius.com/Myra-no-ekstremsport-lyrics

Lyntaler virker kanskje enkelt, fordi det er kort tid. Likevel vil jeg si at det er ekstremsporten innen foredrag, fordi du har NULL rom for tvil eller nøling. Det skal sitte schmekk schmekk schmekk. Helst også med litt punch og kanskje litt humor. Lyntaler handler om å åpne opp fire fem ekstra knapper på skorta også forvandle deg til scenenes Tony Montana og tenke:

Al Pacino som Tony Montana i filmen Scarface

Hele verden er din, og alt som er i den

Tony Montana, Scarface

The Rules of Lyntaler is there are some rules actually…

Jeg lærte en gang at lyntaler alltid skal inneholde en påstand eller ett budskap. Aldri noe mer (en regel jeg faktisk brøt i min lyntale på Y Oslo hvor jeg hadde minst to 🤣). Lyntaler som er “korte foredrag” er i mine øyne feilaktig bruk av formen etter min mening. Du skal ha et budskap i en lyntale. Å holde en “erfarings lyntale” blir feil og bør spares til lengre formater.

O processo

Min prosess for å lage lyntaler er at jeg setter meg ned med PCen også skriver jeg ned foredraget jeg holder i hodet. Jeg transkriberer det som kommer til meg der og da. Dette gjør jeg en tre fire ganger også leser jeg gjennom også ser om det er noe som funker. Segmenter jeg føler begynner ligne noe plukker jeg ut til jeg har igjen nok. Deretter handler det om å sy sammen disse fragmentene til en historie.

Eventuelt så blir det å gå tilbake til start også tenke: “Hva er det egentlig som er budskapet jeg vil komme med?”. I forbindelse med Y Oslo slet jeg veldig med det, fordi jeg hadde innhold nok til 45 minutter i hodet mitt. Hva kan jeg koke det ned til som gir verdi på tretten minutter?

Jeg var skikkelig i tvil lenge, men heldigvis har jeg en kollega Alexandra som jeg kunne prøve ut ulike budskap på. Denne testingen gjorde at jeg etterhvert nærmet meg to hovedbudskap:

  • Innovasjonsbransjen er full av 💩
  • Det handler om å være komfortabel med å være ukomfortabel

Y Oslo hadde et opplegg som ikke passet min prosess. I det deadline for slides kom, hadde jeg ikke begynt på dem. Fordi jeg jobbet med å utforme scriptet for hva jeg skulle si, så da sendte jeg inn en text-fil 🙈🙉🙊

Helgen før hadde jeg noen timer til å snekre slides. Da pleier jeg å begynne med å lete på Unsplash etter noe visuelt spennende bilder mens jeg samtidig prøve å lage noen punchy ord eller setninger til å hjelpe meg å huske.

Øve øve øve øve

Det er ikke alltid jeg øver særlig om det er lengre foredrag. Jeg går gjennom de i hodet og visualiserer, men jeg fremføre sjelden. Denne gangen gjorde jeg det en del, fordi det var på Engelsk. Min første lyntale på engelsk og jeg var egentlig ganske nervøs. Jeg hater selv når folk knoter det til med dårlig språk og mye ståttring. Det ble mye finsliping av speaker notes (du vil se i videoen at jeg bruker de en del, jeg skylder på nerver) også holdt jeg en gjennomgang for de som hadde tid i VIBBIO via Google Meet.

 where I was doing a dry run of the talk with my co-workers hanging out
Practicing before my co-workers

Resultatet

Slik gikk det.

Pakk sekken med ting du trenger for turen

Don’t let yourself get attached to anything you are not willing to walk out on in 30 seconds flat if you feel the heat around the corner

Neil McCauley – from the movie Heat

Sitatet er fra nittitalls filmen Heat med blant andre Pacino og DeNiro, ikke nødvendigvis den beste filmen men sitatet er bra. En skal være forsiktig med metaforer, men jeg mener dette sitatet er noe du bør ha bakhodet når du jobber som programmerer (og trolig også andre roller, men jeg kan bare med sikkerhet snakke om programmerere).

Veldig mange selskaper er veldig gode på å skape gode sosiale- og faglige relasjoner blant sine ansatte. De har lagt til rette for at du får disse behovene dekket der. Det er ikke med onde hensikter nødvendigvis, men for å skape ansatte som trives og vokse sammen med det formål å gjøre best mulig jobb. Selskaper investerer mye penger i på rekruttere riktig folk og de gjør også sitt beste for at de fleste skal bli værende.

Det er ikke noe galt i dette og at selskaper forsøker skape bra miljøer er en god ting. Det er spesielt nyttig tidlig i karrieren. Disse arenaene er gode steder å trene seg på å diskutere, presentere eller på andre måter interagere med likesinnede om faglige tema. Poenget er å forstå hvordan disse skal brukes slik at de hjelper deg vokse videre.

Vær våkne og beviste

Et godt råd som lønnsmottager er å alltid være bevist rundt hva du investerer din tid i og hva det er du eventuelt får ut av det. Det er ikke nødvendigvis snakk om karriere, penger eller lignende. Å få en god følelse eller å ha bidratt til et fellesskap er også verdifulle ting å få ut av en jobb. Uansett hva du velger å bruke din verdifulle tid på, sørg for at den brukes på noe som gir deg noe. Ikke fortell deg selv at du skylder et selskap som betaler deg for å gjøre en jobb for dem noe som helst. Vær bevist og om nødvendig kynisk i alt du gjør slik at du kommer godt ut av det.

Det betyr ikke at du skal være et dårlig menneske og behandle de rundt deg dårlig. Hva jeg mener er at du ikke skal tillegge et selskap egenskaper som andre mennesker har. Et selskap har ingen følelser, lojalitet eller annet til deg. Du er en ressurs som kreves for å gjøre en jobb som igjen er for å nå ett eller annet mål.

Invester i det du kan ta med deg

I context av det å være programmerer så er det noen konkrete ting som er lurt å ha i mente. Invester tid i ting som du på ett eller annet vis kan ta med deg videre (fordi du kommer til å forlate stedet du jobber nå, tro meg).

Hvis du skal holde en presentasjon på en fagdag for selskapet ditt, sørg for at du på ett eller annet vis kan gjøre den tilgjengelig utenfor selskapet. Det vil si at du i utformingen alltid bør ha i bakhodet at budskapet må kunne deles. Hvis det er for mange sensitive ting, så kan du ofte ikke dele det. Er det konkrete erfaringer, forsøk å pakke de på en måte som gjør at det ikke hindrer deg i å spre det.

Åpen kildekode er en mulighet for deg som lønnsmottager til å kunne gjøre nytte for deg i jobben, samtidig som du har noe verdifullt å ta med deg videre i karrieren.

Ikke begrens deg

Veldig mange teknologiselskaper har i dag en eller annen chat løsning som fungerer som faglig- og sosialt lim. Det er effektivt og på mange måter nyttig, men det er viktig å ikke begrense seg i den faglige omgangskretsen (fordi husk på, du vil slutte i jobben du er i nå).

Finn deg arenaer å delta på som ikke er knyttet til ditt arbeidssted. Det finnes både fysiske arenaer som Meetups, konferanser, frokostseminarer, etc. Du kan etablere deg som en autoritet på Stack Overflow innen et emne. Hvis det er spesielle teknologier eller emner du føler er spennende har veldig mange av disse ofte en åpen chat du kan bli med i. Hvis du benytter et åpent kildekode prosjekt mye i jobben din, så er det ofte at disse har arenaer hvor du kan bli del av et større faglig miljø. Det finnes veldig mange måter å knytte faglige relasjoner på i vår tidsalder, ikke la deg begrense til selskapets egne løsninger.

Å forlate en jobb handler ofte om å bryte med noe kjent og trygt, jo mer du har av et faglig- og sosial nettverk som er knyttet til deg selv og ikke jobben jo friere står du til å ta det beste valget for deg.

Moralen er å ikke la deg begrense i hvordan du bygger ditt faglige nettverk, bygg noe som er ditt og som du tar med deg uansett hvor du går.

“Slipp fangene fri det er vår”

Photo by Jed Villejo on Unsplash

Overskriften er også film relatert og referer til filmen med sammen navn. Hittil i min karriere har jeg byttet jobb relativt ofte i følge den norske normen. I løpet av disse byttene har jeg sett altfor mange som bare blir igjen. Enkelte ganger blir folk værende ut av en følelse av at de skylder et selskap eller mennesker i et selskap noe. Andre ganger kan det være fordi det å bytte jobb virker skremmende. Hvis man kommer opp i en viss alder, som meg selv, så er det også en viss frykt at man har blitt for gammel til å bli ansatte noe som helst sted.

Guttene i Kortslutning har en veldig bra episode om dette temaet. De forteller modige sine følelser knyttet til å det å bytte jobb for første gang i episoden Det å bytte jobb. Det kan være skummelt første gang og det å bytte jobb er ikke alltid. Likevel så er det stort sett ikke så skummelt som du en tror.

Ta ansvar, ta sjansen!

Mennesker som jobber med teknologi i 2019 her i Oslo har absolutt ingenting å frykte ved å bytte jobb. Jeg er sikker på at om du stiller deg opp på Oslo S med en plakat og CV i hånda så har du jobb i løpet av morgenrushet. Det er og har vært siden tidlig 2000-tallet en brennhett jobbmarked, så hvorfor i alle dager skal man bli værende om man ikke føler man får noe ut av det?

Lærer du ikke noe eller føler du utvikler deg noe som menneske? Da er det bare å begynne finne seg et nytt sted. Du vil ikke angre, selv de gangene den nye jobben viser seg å være feil. Da vet du, om ikke annet, mer om hva du ikke liker til neste gang du bytter jobb.

Photo by Colton Duke on Unsplash

drawing of computer program

An approach to problem solving with computer programs

When you start learning to code you develop an idea of what people who does it for a living knows. I remember when I started, I was convinced that everyone around me knew everything and was never in doubt about what the correct approach would be. There was little to read about how to approach coding except for academic articles and books.

In this day and age the situation is very different. There are countless resources where you can see how people approach problem solving using computer programs. You can watch live streams of people working on popular Open Source projects or watch tutorial videos. They all give good insight into the process of coding and shows how you can reason about issues you encounter. One thing you don’t get to see in these rehearsed videos is how they come up with the solutions and how they learned to solve it. In short, you don’t get to see their frantic googling, pulling of hair and general frustration which is usually involved. You don’t see the chat messages discussing topics and expressions of doubts about the solutions.

What I’m getting at, is that there are some things related to problem solving with computer programs which we don’t discuss that often and which is not shown in most coding videos. I will try to outline my preferred way of approaching a problem in an attempt to show that even though I have done this for a living in almost two decades, my approach is not one linear process where I know the steps nor the place I want to end up.

Make it visual

Regardless of wether it is coding up an UI component or creating an API endpoint to solve a data access issue, I have to make it visual. What I mean by that is that I got to draw something somewhere. It could be doodling something on a piece of paper, drawing on a white-board or putting some boxes’n things in a Google slide. This visual I try to update as learn more about the problem I’m trying to solve. More often than not I have to start over. Usually my first assumptions where wrong. That is not a problem! It means I’ve learned something and it’s better to “scrap” a drawing or slide than to revert code changes deployed in production. 

I have met programmers who are able to process things like this in their head. They are able to find design flaws etc by visualising what happens it in their head. This is something I struggle with. I can perhaps “run” a couple of steps of a process in my head, but then I loose it. My short term memory is terrible and I’m also not that great at keeping focus when thinking. Therefor I commit my thoughts to paper or some digital tool. One nice side effect of this is that documentation comes pretty easy, as I’ve been doing that throughout the problem solving process. 

The format in which I draw or the tool I use does not matter, it’s proximity and flexibility that matters. I find modelling tools constraining rather than helpful and enabling. Therefor I tend to use generic tools for visualising / drawing / doodling. There are formal approaches on how to modell software processes and create designs. Personally I find just “drawing whatever” is more useful then ensuring it is 100% correct UML syntax. I am not saying you should not seek learning techniques for modelling software. Everything you can learn which can be added to your toolbox is always worth checking out.

Large problems only? 

My process is the same for wether I’m trying to create some distributed architecture or if it is creating a small UI component. Once the issue requires me to think more than a couple of steps ahead, this is my go to approach and it is something I feel comfortable with. I find that there is no problem too small where this does not help. Sometimes my head just isn’t in it and doing some simple drawings works wonders for me.

Solving the problem

Once the design and preparation is done it is time to solve it. I use similar approach when it comes to writing the code for solving the problem. You can visualise the problem to solve with a drawing, but you can also visualise the flow of a program using text. I learned this approach reading the book Code Complete by Steve McConnel. He said that before writing actual programming statements, you can flesh out the details just using code comments. 

someFunction () {

  // if there is an item
    // render delete button
    // if not render the add button
  
    // write the label of the item
  // then add a parenthesis and a number

}

Once you have got some thing written down, read it back and see if it still makes sense. You should refactor the code block until it makes sense and it does what you meant it to. Perhaps you should extract a method or maybe you need to call out to a service and retrieve some more data. Refactoring when all you have is code comments is easy. As opposed fixing written and deployed code. I’m not saying this is something you must do, it is just one approach which I find helpful at times. 

There are other techniques, such as test driven development, which serves the same purpose as writing code comments before coding (I am aware there are more advantages, but this is not the topic of this post). Others use pseudocode to achieve the same thing (check out Thomas’ post on the topic  “I love pseudocode”). Learning multiple ways to solve problems is useful and something that will be beneficial regardless of the technological platform you happen to be working with.

“Kids, stay in school”

This article contains methods which happen to work well for me. Others will have different approaches and techniques. What is important is staying open minded and stay curious. To keep learning is essential to having a long career as a programmer. 

Hva er en god systemutvikler?

Dusty road in a desert landscape with a car
Veien til å bli en god systemutvikler er hompete, støvete og endere kanskje ikke der du tror.
Kilde: https://www.flickr.com/photos/honzasoukup/2398942904/

Hva er en god systemutvikler? Dette er et ladet spørsmål, så først vil jeg legge ned min definisjon av systemutvikling. Det er et lagspill der man sammen leverer en digital løsning på en utfordring / problem.Legg merke til at jeg ikke sier «hva er en god programmerer». Hvorfor ikke? Fordi programmeringsdelen er bare en  del av det som inngår i systemutvikling. Så, hvilke egenskaper trengs for å være en dyktig systemutvikler i 2018 og i tiden fremover? 

Kommunikasjon 

Du trenger først og fremst å være i stand til å kommunisere med de du jobber med. Det betyr at du kan gjøre deg og dine tanker forstått enten verbalt eller skriftlig. Det er sjelden man sitter alene og utvikler noe uten at man må kommunisere med noen. Dette gjelder både i jobb, men også i stor grad i feks Open Source. En del av det å kommunisere bra er å bli forstått, men også det å gjøre det på en måte som er positiv for de rundt deg. Hvis du sliter med kommunisere det du gjør, tenker eller mener så vil du merke at det å jobbe som systemutvikler kan være frustrende. Å kontinuerlig jobbe med hvordan du kommuniserer muntlig og skriftlig er en veldig viktig det av det å drive systemutvikling. Det er også viktig å forsøke mestre både den uformelle (f.eks chat) og den mer formelle som går på å skrive dokumentasjon eller lignende. 

Empati

Du trenger å være empatisk og forstå de rundt deg. Systemutvikling er å løse problemer for mennesker (startsett, noen ganger å løse problemer for andre maskiner etc men ofte er det mennesker) og da er evnen til å sette seg inn i deres situasjon essensielt. Spesielt i løpet av de siste årene har dette blitt viktig, da teknologien vi utvikler direkte påvirker menneskers lov. Hvis vi som utvikler disse løsningene gjør det uten et snev av empati gjør vi livet til de rundt oss verre, ikke bedre. Systemer utviklet uten tanke på de det påvirker kan få fatale konsekvenser og kan være skillet mellom liv og død (se https://www.nytimes.com/2018/10/15/technology/myanmar-facebook-genocide.html). 

Oppsummert

Kommunikasjon og empati er viktige for å være en bra systemutvikler i tiden fremover. Det betyr ikke at selve faget programmering er uvesentlig og at de to egenskapene jeg nevner gjør at du ikke trenger utvikle den faglige siden av systemutvikling. Det jeg mener er at i tillegg til kunnskaper i faget må du ha menneskelige egenskapene for å være en god systemutvikler. Tiden da systemutvikling var en solo greie er over og kommer aldri tilbake (heldigvis). Ei heller vil tiden da vi laget systemer bare for lolz være det. Det vi lager påvirker verden og menneskene i den, og det ansvaret som ligger på oss som utvikler systemene skal vi ta på alvor.

Kortslutning Podcast har en episode om samme tema, sjekk den ut: “Må du være lidenskaplig opptatt av programmering for å bli en bra utviklar?”

Distribuerte produksjonsenheter er kommet for å bli – eller Remote Work FTW

Credit: https://www.flickr.com/photos/snowpeak/14351894398/

Jeg tok en sjanse i sommer, jeg gikk over i en jobb hvor jeg visste at jeg kom til å jobbe som del av et distribuert team i Vibbio. Resonnementet bak å prøve var at om det funker og jeg liker det kan det åpne nye muligheter for å gjøre morsomme ting i femtiden.

Jeg har en erfaring med å jobbe distribuert og det var under en oppsigelsestid hvor jeg var fristilt. Da jobbet jeg med en person i Seattle og vi klarte og levere det vi skulle. Riktignok varte dette bare ca tre uker. Etter det var planen å finne noe annet, det ble aldri noe av.

Å skulle jobbe distribuert uten å ha noen du kan bare snu deg til også snakke med var skremmende. Alle som har jobbet med meg vet at mitt behov for å snakke er der ganske hyppig (beklager..). Jeg har også merket at jeg liker mennesker og liker å snakke med folk. De gangene jeg har hatt foreldre permisjon har jeg snakket hull i hodet på de hjemme fordi jeg ikke har fått snakket. Så vi kan si at kona var minst like bekymret.

Antagelig jobber du alt distribuert

Jeg her nå gjort det en måned og har vel egentlig erfart at det å jobbe distribuert er ikke så ulikt å jobbe i en stor bedrift. Hvis du uansett bruker digitale hjelpemiddel for all dag til dag kommunikasjon så er overgangen til å jobbe distribuert liten. Om kollegaen er i en annen etasje, bygg eller land betyr lite. Eneste overgangen er at du ikke like enkelt kan kaste bort tid på å bare snakke med folk.

Veldig mange steder har tatt i bruke ting som Slack / HipChat eller lignende. De aller fleste styrer oppgaver og prosjekter via digitale løsninger. Hvis vi skal oppsummere så er det egentlig bare møter som må endres (og strengt tatt er vel det bare 100% positivt ettersom alle selskaper er elendige på å holde møter) til å bli digitale via videokonferanse.

Ikke nødvendigvis hør på alle råd

Hvis du får muligheter til å ta en jobb som har et distribuert team, så er det verdt å sjekke ut. En liten viktig ting er å sjekke at dere er i samme tidssone. Etter hva jeg har hørt er det en helt annen greie og kanskje ikke så chill om dere er ca på samme tidssone (selv om min første remote jobb var på tvers av tidssoner og var bra, så tror jeg det først og fremst var fordi vi var et team på to mennesker).

Hvis du leser på nettet om Remote Work er det selvsagt en mega industri som er veldig klar på at dette med å jobbe distribuert krever at du leser masse greier, kjøper bøker, handler inn kontormøbler, setter deg inn i hvordan du skal gjøre dette mega endringen. Det er litt som når du får barn for første gang og begynner lese alle tingene du bare  ha, men som du senere innser er fullstendig unødvendig.

Jeg kjøpte 37 Signals sin Remote: Office Not Required bok, som var nyttig og lese men kanskje mest nyttig for de som trenger argumenter for å begynne jobbe distribuert. Utover det har jeg ikke gjort noe. Dagene jeg er hjemme sitter jeg ved kjøkkenbordet (fordi det er ikke plass til noe kontor). Jeg har ingen spesiell rutine annet enn å levere unger dit de skal også få meg kaffe.
Folk er selvsagt forskjellige, men det er verdt å ikke lese for mye og heller bare prøve seg frem selv. Snakk med folk du kjenner og stoler på som har gjort dette alt.

Hva er anderledes?

En ting jeg merker veldig er at du må være flinkere til å formulere deg presist og kanskje bruke litt lengre tid på å utforme det du skal kommunisere. For meg personlig er det ekstremt positivt, da jeg kan være litt vel rask og noen ganger ikke helt være innforstått med at kanskje ikke alle vet alle detaljer jeg har i mitt hodet. Du merker at det å bare slenge ut noe på Slack ikke funker så bra. Tidligere har jeg gjort det mye, men da har jeg som regel tatt det “offline” rett etterpå for å liksom rette opp i ting som ble misforstått.
Jobber du distribuert så må du rette opp alt skriftlig også, noe som kan bli lange og tunge chat dialoger. Så jeg forsøker å bli flinkere til å komme med litt mer gjennomtenkte og velskrevne ting for å unngå lange chat tråder.

Dokumentasjon kommer automatisk, fordi du må formulert noe skriftlig for å gjøre noe. Dermed har du allerede før du begynner noe dokumentasjon og for å forklare dine intensjoner klart ovenfor de andre må du som regel skrive litt til når du er ferdig med en oppgave. Vanligvis kunne du bare reist deg opp også sagt “ey, jeg har laga noe kom å se” eller tatt det i lunchen. Distribuerte jobbing gjør at du er nødt til å ha en “papirsti” for at andre skal kunne forstå hva du holder på med.

Credit: https://www.flickr.com/photos/indi/3104247104/

Sjefer som er vant til å være “manager of chairs” vil bli helt åpenbart unyttige og være uten hjelpemiddel til å fortsette styre teamet på en gal måte. Å være på team hvor viktigste delen av jobben er å ha ræva si på en stol på et kontor er ikke gøy og ekstremt demotiverende. Ved å fjerne muligheten til å kalle “å se at folk er på jobb” ledelse så flyttes også fokus på hva det er som leveres av verdi. Det er ekstremt positivt og kanskje en av de aller største fordelen med distribuerte team.

Jeg merker at jeg må jobbe litt med min holdning / fremtoning i video møter. Hvis hele kroppen min og stemmen min utstråler “jeg vil gjøre noe annet, make it stop!!” så er det ganske dårlige signaler. I vanlige møter kan du rette dette opp med “koseprat” før / etter møtet, mens i videokonferanse får du liksom ikke det.

Konklusjon:

Å uttale bastant at dette er AWESOME etter rundt to måneder er i overkant naivt. Jeg vil si jeg er overrasket over at jeg liker det såpass bra allerede. Skepsisen jeg gikk inn i dette med er i ferd med å forsvinne. Jeg merker at friheten og ansvaret du får ved å jobbe distribuert passer med bra, kanskje varer det også.