A dark forrest during sunset with some light shining through

On being open to grow

All my “On..” posts are things I write from beginning to end without any editing or thinking about structure (so it’s like all other posts?). They are just dumps of thoughts I’ve had which I deem that maybe they’re useful for something or someone, so I’ll just dump it here where nobody actually sees them.

A friend of mine told me his friends reaction when he said he was starting to learn how to play the flute. They said: “why do you want to learn that now?”. What they meant was why are you, a grown man, starting to learn to play an instrument? As if that’s an outrageous idea and that it’s not something grown up people do!

It’s a really sad outlook if we’re not supposed to learn anything new in what in most cases will be half our life time! We learn a ton of stuff and then suddenly because we’ve gained responsibilities and have obligations we are to stop learning? This is a preposterous idea. Learning and changing is the most natural thing we do, so why stop?
I know some people think it’s too late to change and things like that. What I think is the case is that we gradually neglect and pay attention to our own willingness and openness to change. That’s why we stop, because our minds are closed.

You stop growing and evolving. One example is often see is music. You can choose to stop exploring and being open to new impulses, which means you enjoy the same music as when you where in your twenties. There is another option, which is to continue being curious and open to the idea that just maybe there is the odd chance of someone being capable of creating music you might enjoy even after you’ve surpassed the age of 35 🤷🏼‍♂️ It requires a mindset of being open to new impulses and challenge what you belive is good music. Engaging and making an effort to understand something new.

Many new parents find themselves in the same position, having suddenly to deal with the fact that their lives are forever changed with the arrival of the infant. You can choose to constantly look at what you are missing out and the life you used to have, constantly looking for opportunities to get a tast for “the old life”. I believe this will only make you miserable as that life will never return. Instead one could choose to be open to the new things that your life now offers you. This huge change is a great opportunity to grow as a person. Learn new things about yourself and also be open to all the learnings your child will give you. If you pay attention, you will notice that the child is learning you just as often as you are learning it things.

Person with long hair in a dark room looking through a window with light coming through it.
Photo by Mario Azzi on Unsplash

What’s the key difference between someone “stuck” and one that evolves? It is, I think, a willingness to seek out new impulses and to be open to the fact that you might be wrong in your current assumptions. In order to grow and learn you have to be open to receive new impulses. It means you must reflect on your view points, you must and should dare to change your position on things.When someone comes to you and say that you perhaps could have solved something in a different way. It’s natural to go in defensive mode and try to explain why, that you didn’t intend it that what and you explain all the reasons why you did what you did. I’ve learned that this is not how you receive feedback. First step towards learning from feedback and input is to listen, like actually listening. Take in and focus on understanding exactly what the person said, without judgement and without trying to defend yourself. In order to achieve this, I think it’s vita to be open to the fact that you might have to change or adapt how you do things.

An office space with a long table with chairs next to it.
Photo by Jose Losada on Unsplash

Starting out in the IT industry you work on the ground floor and all you have to do is to show you know the craft. Gradually you’ll be expected to take into account things outside the realm of just the one thing you know. The progression from junior to senior is not about years, it’s about widening your perspective and to evolve you understanding of what it is that you do. Often a good senior will get offered the opportunity to lead.
This is often done without any real formal training or coaching mechanisms in place. A good crafts person is somehow automatically a leader.

This fallacy leads to many dysfunctional teams and some times destroyed careers.When accepting the challenge to lead you must be open to change. Everything you do is different when you are a leader and you have to be able to adjust your thinking and behavior. You have to put in the work to understand the power dynamics between leader and worker. In order to help your workers grow you have to learn how to activist listen to them and to turn  that input into actions. It is an entirely new job, it’s like going from a car mechanic to becoming a nurse. The requirements of you as an individual have completely changed and you have to change. You have to be open to the fact that this will change you as a person and you’ll be a different one on the other side of your new position as a leader.

This isn’t only about the classic worker-to-leader scenario where openness to change is essential. During the Covid pandemic a lot of people have had to suddenly work from home. This is a great opportunity to learn new things about yourself, if you are open to change. One option is to dig your heals in and try to mimic  “the good old office vibe” in a remote setting. We’ve all seen that it does not work and people just become really tired of the endless video calls. A different approach is to look at working remote as an opportunity to learn something. All trends point towards the new workplace being much more duos and flexible, so instead of fighting against it you should embrace it as a learning opportunity.

Neon sign on a brick wall in a dark room which says: this is the sign you have been looking for

Three ways to successfully prevent your young company from succeeding 💪🏼🎉

I have been so fortunate as to be part of several young companies and starting new teams in existing organizations. This post is is a summary of my subjective observations, you should treat it as such.

1️⃣ Introduce departments too early

All young companies wants to grow up and become proper organizations. In order to get a head start, many young companies start splitting up their organizaiton into departments way too early in an attempt to look good for stakeholders and potential hires. “See, we know how to set up a business!”

The issues is that doing this when a company is just 10-12 people (I have experience this myself on more than one occasion) is setting your self up for problems you could avoid. With the introduction of constructs such as product, sales and operations you are creating boundaries and a need for synchronization. When you have a department, of course there needs to be someone running it. Hence you need to introduce a leader. Once you have three or more leaders, then there needs to leadership meetings, etc. What the company has been doing is creating the constructs which prevent larger companies from being efficient. Communication lines multiply, hand-overs and synchronization is introduced. You also formalize the tension which is between say sales and product.

I have been part of companies lulling themselves into the corporate mentality way before it is required (yes, it might be required at some point. However not when you are so few people). As we all know, the c-title people in young companies are usually the ones who where there first. Not necessarily the ones who’s best equipped to handle the role (I have first hand experience of this, I was CTO because I was the first hire!). You might need to have all kinds of titles and thing in your pitch deck to investors, but you should probably not actually have any of it in reality until there is a dire need of them. There is no going back once you introduce it.

2️⃣ Prematurely introducing processes & practices to scale

Software organizations are like crazed teenage fans when it comes to processes and tools. They blindly follow their idols without really taking the time to contemplate why. You will see small companies mimicing companies the aspire to become, as they think that is what has made the great. That is a grave mistake, as most unicorn or gazillion euro evaluated company probably did not start out with those processes. They needed to install certain processes because of any number of things. Maybe they grew into a thousand people company in two months. Perhaps they acquired a company in a different timezone. Someone gave them a truck load of money and they suddenly need to ramp up quickly. Or they have a total lack of trust in their organization and therefor install rigid processes.

Whatever the case may be, one of the key factors for rapidly growing small companies is their lack of these processes. It is a huge competitive advantage to not have to do the Spotify model (which is the go to model of choice the past years in my country Norway). Instead of trying to do what the big ones do, young companies should cherish and embrace the time when they don’t need any of it. It is the most fun you’ll probably have and the time you’ll be having the most creativity and being the most productive. Young companies should postpone installing processes as long as possible and most likely invent their own thing once they do.

The same thing goes for tools. There are certain tools which inevitably will make your organization less efficient (yes, I am talking about that product starting with Jir). Why does a 4 person development team need a bug tracker? If you only have the capacity to do two things in a cycle, do you really need a roadmap tool? I would say no. In my first startup we had a bug tracker, it was a sheet of paper which could only fill 10 bugs. If there where more, we’d either need to solve one or take one out. The sheet was visible for everyone (this was in ancient times when we used to go to things like The Office) and when it changed there was always a discussion about priorities. We did the same thing with items to do in a cycle. To date, this has been the best tools I have used to get work done in a small company.

The problem with task managers etc is that they put focus on the items, not on what value you want to create. Everyone gets focused on the individual work items and forgets about what it is that we bring of user value this cycle. The outcomes of each cycle becomes less important than completing the things we thought was a good idea when the cycle started.

3️⃣ Letting the engineers decide on their own

Three cubs on a mommy bear over a text box which says "solving imaginary scaling issues, at scale"
From https://twitter.com/thepracticaldev

You know what is going to happen when you let some engineers have free reign and build The Greatest Technology Platform Ever™ to propel your startup into the stratosphere. They will prematurely create something they think resemble what their idols do. It will be Planet Scale from day 4 for all of the companies 4 customers and 1 concurrent user. I would not say that this is a big exaggeration, I have seen it happen on many occasions. The enthusiasm to finally be able to architect the system they’ve envisioned all this time. To finally put into practice all the blog posts that they have read, all without really paying much attention to what the company actually needs in the beginning.

You should never let the engineers decide all things on their own, they need to articulate how it relates to where the business is right now and the next three months. There is no need for planet scale if you’re shut down in two months because you’re failing to get users. Opting for a serious cloud provider because “it will enable us to scale easily later” might be a decision which prevents you from shipping what you need right now and eventually kill the company.

Engineers should be allowed to choose many things, but they should not be doing it in a vacuum without close collaboration with everyone else. Prematurely architecting something complex has prevented companies from getting the chance to succeed more than on one occasion.

What should young companies do?

Woman setting with her back towards you with her back turend, watching beautiful sunset.
Photo by Sage Friedman on Unsplash

Take a deep breath, hold it for ten seconds and then exhale. Relax, put your shoulders down and instead try to enjoy what is the best time of a companies life. Rather than rushing into becoming a proper company, you should embrace the competitive advantage you have of not being such a company. The small size, lack of processes and hacky technology is the secret sauce unicorns are made of. They are not made up of practices from Google, Facebook, Amazon and Microsoft. If investors want structure, make a power point. Don’t mess up what potentially could be the best time!


Software development as a cooperative game


This quote got me thinking today, because if it really is a cooperative game and teams are how we structure people working to solve problems, shouldn’t we look towards other team activities for inspiration?

When you work as a team, it is important to have diversity and a mixed set of skills. Especially in software development cross-functional teams is something that can be a good thing. Now, I have worked on many such teams and I’ve interacted with even more. One thing that comes to mind is that many teams miss some of the key success criteria for teams in sports: trust and the focus on making others better.

Making others better

The last point is something which was a corner stone of Norwegian soccer coach legend Nils Arne Eggen. His philosophy on how to make a team of mediocer players perform better than teams with way better players was to have a focus on making sure everyone wanted to make their team mates better. Playing a pass that puts your team mate into trouble is not good. It prevents you from making a mistake, but putting the other guy in trouble is bad for the team.

In geek-culture we always strive for the next thing. Wether it is a new tool, metholdogy or technology. Regardless of what has been don previously, we always want to opt for something else the next time we do something. This of course is fun and everyone wants to be working with “the next thing”. It’ll allow you for a small period of time, until someone else has “the next thing”, to keep your head up high and look at all the grunts who work with “what we used to do”. Our continued strive for the next thing is of course a good thing, however it can also be harmfull. Especially in a collaborative game setting, where you want to make others better. Pushing ahead with “the next thing” leaving everyone else behind is not making your team mates better. What would be better is to push for “the next thing” while making sure everyone else can cath up with you. Naturally, this approach doesn’t come with as much personal glory or will make you look better then everyone else. However it will make everyone you collaborate with better. I believe that we can strive towards focusing more on making those arround us better. I also believe that this way of thinking is good for business. What good is one amazing team, when you have six others who are just lagging behind?

Of course, I realize that my opinions are a result of my upbringing in socialist Norway and that this way of thinking is perhaps very weird for some of you.


Trust is another thing that so many teams, especially in Norway (having worked mostly in Norway I can’t really tell if it is better or worse elsewhere), lack. You can see this lack of trust manifest itself in numerous ways. Micro-management is the legendary sign of a lack of trust in team members. A lesser known one is a team where every decission must be made when everyone agreees. This “democracy” is really just a front for a total lack of trust in each other. When a team consists of memeber who don’t trust each others abilities the democratic way of making decissions ensures that there is a sense of control (which of course is true, because in such team nothing really happens).

Cross-functional teams paired with a “flat hierarchy” is of course the worst kind of team where trust is just not in play at all. Using the “flat hierarchy” as an exscuse for micro-management is a classic. The director of what-ever-the-fuck needs to make decisssions on color. Or manager of God-known-what needs to be in place for user testing. All discuised as managers “contributing” and being “hands-on”, when it really is just good old fashioned micro-management applied because of a total lack of trust in the teams abilities to make good good work.

In closing..

What was the executive summary of this rant-post? It is that we are terrible at team work and most software development teams lack what great teams of other disicplines have. We need to broaden our horizon and look outside our fucked up industry to see how we should collaborate on achieving greatness

Jeg vil ha dogmatikerne tilbake i smidig-bevegelsen

Smidig 2010 er nettopp over og jeg tror alle deltagere var rimelig fornøyde. Selv var jeg også godt fornøyd etter å ha truffet mange kule og kunnskapsrike kolleger fra rundt om i landet. Det begynne å ligne litt på en veldig trivelig re-union å være på Smidig. Litt som å komme tilbake til hjembygda også treffe igjen gamle kjente.

Det er riktignok en ting som har slått meg etter å ha reflektert over det som ble sagt under konferansen. På meg virket det som det var en opplest sannhet, og da er det alltid grunn til å bli skeptisk, at det var viktigere å stadig “bli smidigere” enn å “være smidig”. Under konferansen så tenkte jeg: “ja, det er vel bedre enn ingenting”, men i ettertid så er det ikke tvil om at det nok ikke nødvendigvis er slik.

Typisk norsk å være…

Typisk norsk å være middelmådig pleier jeg som regel å si. Vi nordmenn er oppdratt til å senke seg oss ned på nivå med gjennomsnittet gjennom tidlig innføring i jantelov og sosialdemokratiske prinsipper. Derfor er det jo bare naturlig at vi også viderefører dette i arbeidslivet. Hvorfor skal vi ikke være puristiske å kreve at man faktisk gjør det som kreves for å oppnå full effekt av smidige metoder? Det at enhver som prøver litt skal slå seg på brystet og si jo vi jobber iterativt, inkrementell og evolusjonært (dette er Reidar Sande sin herlige definisjon av smidig fra Smidig 2008 i lyntalen Ble Mona Lisa malt iterativt, inkrementelt eller evolusjonært?) trekker de som virkelig får det til ned i gjørma.
“Vi jobber stadig smidigere, og derfor vil vi vinne over de som er smidig” var noe som ble ytret på konferansen. Det utsagnet er såpass meningsløst og flåsete at det kunne vært tatt ut av FrP sitt program. Fordi man har manglende evne til å innføre smidige metoder så skal man være likeverdig med de som faktisk får det til? I stedet for å jobbe hardere så påberoper man seg en offerrolle hvor man føler seg urettferdig behandlet av “de andre” som bare er ønsker å heve seg over “folk flest”.

En gris er fremdeles en gris selv om du tar på den hatt og frakk

Du vet at det er noe fishy på gang i det noen sier: “vi kjører smidig, men..”. Etter men så kommer det alltid en eller annen bortforklaring eller tåkelegging rundt de delene som ikke er smidig. “Vi er smidig, men leverer tre ganger i året”. “Vi er smidig, men vi har design up front og massevis av kontrakter”. Det hjelper ikke å ha en intensjon eller en visjon om å være smidig. Du må faktisk legge inn den jobben og gjøre de grepene som kreves for å kunne etterleve det.
Jeg synes ikke det skal være nok å stadig “være smidigere”. Det er bare en unnskyldning for manglende evne til endring og man bruker smidig ordet bare fordi det er trendy. De som snakker om dette vil på et blunk kunne bytte til “det neste hotte”, fordi de i praksis alltid kjører som de alltid har gjort.
Hjelper ikke om du kler ut din rigide tungrodde prosess med smidige hatter og skjerf, du er hva du er uansett kostymer.

Det er bare hardt arbeid som får deg i mål

Min oppfordring er at vi skal slutte å godta at smidig begrepet dras gjennom gjørma og gruppevoldtas av tilfeldig praktikanter ved passende anledninger. Vi skal konfrontere og kle av alle de som poserer som smidig fordi det er trendy. Hvorfor skal man senke ambisjonene bare fordi ting er litt vanskelig? Hvorfor skal vi godta at “bli litt smidigere” er likeverdig med å faktisk være smidig?

Å jobbe smidig er knallhardt arbeid som tar veldig lang tid, så det er bare naturlig at mange sliter med å få det til. Derfor er det så utrolig viktig at man ikke stopper halvveis også sier det er nok. Ingen har sagt at det å få til smidig utvikling i en organisasjon er enkelt, så det er bare å brette opp armene og erkjenne hvor man står og fortsette arbeidet.

Jeg vet hvorfor du ikke lykkes med Scrum (eller noen annen metode for den del)

I artikkelserien “jeg vet hvorfor” skal jeg nå ta for meg Scrum, men jeg tror dette gjelder alle metoder. Den absolutt mest utbredte av de smidige metodene er Scrum og den benyttes på så mange ulike måte og tolkes i så mange retninger at den naturlig nok begynner å miste litt av den sølvfargede glansen metoden hadde da den først kom. Årsakene til hvorfor mange føler de ikke lykkes med Scrum er like mange som årsakene til at andre føler de får mye igjen for å benytte metoden. Jeg har vært i kontakt med mange som hevder å benytte Scrum og det er selvsagt en enorm forskjell i hvordan metoden brukes rundt omkring. Likevel vil jeg påstå at det er en fellesnevner for alle de som ikke får Scrum til å fungere.

Lille speil på veggen der…

Jeg hadde gleden av å delta på Mike Cohn’s Scrum Master “Sertifisering” i fjor og en av tingene jeg sitter igjen med er det Mike sa om at:

“Scrum løser ingen problemer, den bare viser deg problemene dine”

Dette er selvsagt ikke noe som du nevner når du selger inn metoden, ettersom ingen vil ha noe som bare viser deg problemene uten noen løsning. Følgelig blir veldig mange skuffet når det viser seg at Scrum kun visualiserer og bringer for dagen alle problemer du tidligere har forsøkt å feie under teppet. Du titter i speilet og alt du ser er utfordringene du har slitt med tidligere og dette fra noe som alle mener er så bra. Naturlig nok sitter en ofte skuffet tilbake og begynner å se etter neste ting som lover å løse dine problemer uten noe jobb. Det er også en del andre ting som Scrum lover og dette snakker Geir Amsjø om i Hva oppnår du med Scrum?.

Arbeit macht frei

Arbeidet skal sette deg fri, og slik også når det gjelder metodearbeid. Hvis du skal lykkes med å implementere en metode må du være beredt på at det krever endringer. Gjerne store endringer som vil gå langt utover f.eks et prosjekt. Scrum vil i stor grad vise deg hvor problemene er og hvorvidt du skal få ønsket effekt ved å bruke Scrum avhenger 100% av din evne til å endre omgivelsene. Uten store endringer i både prosjekt og i omgivelsene vil du aldri lykkes særlig bra med Scrum.

Klarer du ikke å ha hyppige leveranser fordi du har en driftsorganisasjon som evner å ta i mot mer enn 1 gang i året? Vel, da må du ta tak i det. Hvis du ikke har noen som kan fungere som produkteier eller være kravstiller, ja så må du ta tak i dette å stable noe på beina.

Når Scrum ikke er nok..

Dette med endringer rører ved noe av det som mange snakker om i disse dager, nemlig at Scrum er en metode for prosjekt gjennomføring. Et prosjekt er noe flyktig som har en start og en slutt, mens organisasjonen som betalte for prosjektet består. Mangelen på helhets fokus er hva jeg mener er Scrum’s akilleshæl. Metodikken gir deg kun hjelp til å belyse mangler og gjennomføre et prosjekt. Utover dette er du på egenhånd og får liten hjelp. Organisasjoner trenger et helhets fokus og en måte å tenke på som hjelper i mer enn bare praktisk prosjektgjennomføring.

Lean, the “new” kid on the block

Veldig mange har begynte å snakke om Lean som et svar på manglene vi har erfart med Scrum. Mytologien rundt Lean har mange ingredienser som gjør at det er en sikker hit blant IT-folk: et ekskluderende vokabular av Japanske ord, har sitt opphav i østlige tanker og er noe nytt. Tiltross for all hypen som vi har sett, og som vi kommer til å se enda mer av i årene som kommer, så tror jeg faktisk at helhets fokuset i Lean er hva Scrum mangler for større organisasjoner.