methodology

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!

Black computer screen showing graphs in white text.

Three tips for acquiring a remote heart beat

When you are a member of a remote team, one of your most important tasks as an employee is to ensure everyone is able to see what you are up to. I have worked in a remote team for about a year and in semi-remote scenarios for an even longer period, therefor it is time to share some of my experiences on how to communicate progress (or lack there of).

There is some responsibility on whoever manages a team to ensure these things are working. There are however some things which has to be the responsibility of the individuals. This is what I will be discussing here.

Create your own remote heart ❤ beat 📈

Showing your team when you are working and how that is going is essential to getting a good team vibe. In order to get this feeling in a remote setting you need to generate a remote heart beat to show “proof of life”.

Actively use status flags in chat tools
Telling your story through the commit history
Show work that is not complete
When communicating progress (or lack there of) take the time to do it properly so people actually understand how things are going

📣 Yell it form the roof tops! 📣

The developer stereotype is that of the lone wolf working in silence only to emerge from the cave with The Ultimate Solution™!
In 2019 this way of working should be dead and only be told as a tale to scare your grand kids. As a developer you are expected to contribute to a team and ensure you move forward together. What this means is that the way you work needs to accommodate for the fact that you are not working in a vacuum. This fact becomes even more important when the team is spread out in different physical locations. Your way of doing your work needs to be louder in order for your team mates to get an insight into how things are going.

Keep the information flowing

Ever since the emergence of Git I have been a big fan of making many small commits, as opposed to committing large chunks at a time. Luckily a “commit often” approach is ideal for remote work. It automatically gives you a heart beat and it does enables you to communicate progress without status reports.

Take pride in committing

If you take the time to write a good commit message (this is very much an aspiration for me, it is not like I am very good at this!) a team member can read the days list of commits and get a decent overview of what’s happened the past day.

When completing something, ensure it’s communicated somewhere

Picture of a leaf forest in daytime with fallen trees on the ground in the sunshine. — Photo by Chelsea Bock on Unsplash

“If a tree falls in a forrest” is a philosophical exercise which applies to remote work. When you fix a bug, it’s nice to others to know right? It is one thing to move the card in your task management tool of choice, however that is usually not something everyone in a company keeps a close eye on. When you fix a bug or complete a feature there are several things you could do when applicable:

Add a piece of documentation to the end user documentation.
Update the help pages FAQ / company blog / etc with news of the new feature or solved issue.
Notify your customer success team about a bug being fixed.
Humbly blog on your company communication tool of choice (mailing list, chat, whatever)

Take a screenshot or screen recording of a feature you have implemented and post it somewhere customer success and sales also see it. Remember, sales are only as informed as you make them. In order for them to do a better job, they rely on information from developers such as yourself.

Embrace showing work that is half done

Not everything you do as a developer is a commit and if that takes up most of your day, how do you enable others to see what you are working on? Taking the plunge and dare to show things which are not complete can feel a bit scary at times, but if you build a team culture where that is common it will be hugely beneficial for the entire team.

Develop skills in handling feedback on half-done work

As developers we talk a lot about feedback cycles and rapid responses to code that gets pushed into production. It is equally important to get early feedback on things which aren’t code.

Let’s say you are redesigning a form and you have just started on the task and you realize you are not quite certain what the interaction should be. You could implement everything and then get feedback or you could quickly create a sample implementation and create a videos which shows off what you have done.
Doing the latter you get rapid feedback with the added benefit of showing the rest of the team what you are working on. Having shown something early makes it easier for others to give quality feedback later on as they have a rough idea of what it is you are working on. Engaging in dialog early on when developing a feature is also time saving. A lack of context when talking about something is a common source of misunderstandings.

By showing off to your sketches, screen shots or small screen recordings you enable your fellow team members to get an insight into your progress. It’s also a nice way to bond the team and it is also an indication of a healthy team if members don’t feel intimidated by doing this.

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.

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.