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"

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!

two men hugging in what looks like a dance floor

“Du får ikke venner på jobb”

Jeg hadde en sjef som sa dette en gang som et velment råd. Den gangen reagerte jeg og tenkte: det var da et jævlig dårlig råd og en pussig ting å si. Grunnen til at jeg syntes det var pussig, var fordi jeg hadde vært så heldig å blitt kjent med folk i jobbsammenheng som jeg vil kalle mine venner. Antagelig sa det utsagnet med om stedet vi jobbet og om personen som sa det.

“Er det bare meg eller er..”

Jeg har jobbet som utvikler i over tjue år og er det en ting jeg har hatt ekstremt god bruk for så er det disse vennene jeg har fått gjennom jobb. De som jeg ringer for å sjekke: “Er det jeg som er teit eller er det vi prøver å gjøre på jobb helt idiotisk?”. “Vi tenker på å innføre X og jeg tenker det er helt hjernedødt”. “Sjefen min sier jeg skal få personalansvar, hva faen gjør jeg?”. “Selskapet tilbyr opsjoner over lønn”. “Jeg trenger en ny jobb, jeg blir gal her!!”. Dette er spørsmål jeg har stilt selv og har hørt andre si til meg gjennom årene.

Særlig i roller hvor du har en form for utvidet ansvar, og ikke kan diskutere alt med de rundt deg på jobb, er det ekstremt viktig å ha noen “som vet hva det går i”. Du trenger de som kan hjelpe deg å ikke bli gærn. Å ha noen å spørre som ikke er i samme selskap, men har erfaring fra lignende situasjoner, er ekstremt nyttig. De kan hjelpe deg å navigere utfordrende situasjoner og kan dele av sine erfaringer. Dette er ikke alltid like lett å få til om du jobber i mindre selskap for eksemple.

Det å ha folk du vet du kan stole på og some du vet gir deg ærlig feedback, er uvurderlig for å ha en lang karriere i IT bransjen. Du vil komme borti situasjoner hvor du vil trenge denne gjengen for å hjelpe deg forstå situasjonen du er i. Du vil ikke alltid kunne spørre dine “vanlige” venner eller livspartnere om de samme tingene, da de “ikke har vært der”. De har ikke nødvendigvis de samme referansene og forstår helt hva du snakker om. Derfor er disse vennene du kan være så heldig å finne så viktige. Slik som rappere fra Bergen sier: “de som vet, de vet”.

Finner du en, så ta var på dem

Rådet mitt er ikke at du skal aktivt gå rundt å forsøke bli venner med alle du jobber med eller noe sånt. Det jeg råder deg til er å være åpen og mottagelig for at kanskje er det noen av de du møter som er verdt å gi sjanse til å bli en venn. Hvis du klarer det så er det noe både du og den andre personen vil ha glede av i lang tid fremover. Disse vennen kan være de som trekker deg opp av dype daler. Det er de som hjelper deg stå i stormen og jobbe gjennom utfordringer. De har ryggen din uansett hvor mye det stormer rundt deg. Jeg har skaffet meg noen sånne og jeg er så takknemlig for at de er mine venner. Uten dem ville jeg ikke vært den personen jeg er i dag. Jeg trenger ikke snakke med dem hver dag, hver måned eller alle år. Men! Jeg vet at om jeg sender en DM så vet jeg de vil hjelpe meg om de har mulighet.
Det er folka som gir deg din neste jobb, gir deg anbefalingen du trenger og som kan hjelpe deg på en realitestsjekk som gjør at du kan utvikle deg.

Vær en venn!

Du bør også være åpen for å være den som andre kan støtte seg på. Vær den som stiller opp når noen trenger å “få blåst ut” litt frustrasjon, still opp om noen vil du skal være referanse, osv. Ta den kaffen eller videosamtalen som gjør at kollegaen din finner ut hva som er riktig ting å gjøre. Det koster deg antagelig ikke mye og det kan vise seg å bety mye for begge. “Si hei, være en venn. Bli med!” som det heter i sangen.

Photo by Thiago Barletta on Unsplash

Picture of a forrest with snow and a lot of branches everywhere

The hidden meaning of complexity in the context of software development

Complexity is on the one hand something which can be measured by tools to give an objective value of how complex something is. However, this is not how I’ve come to see the word used in my work as a software developers. In this article I will talk about some of the aspects tucked away in the concept labeled complexity.
It tends to be used to cover up subjective opinions or believes getting portrayed as objective observations. Being able to detect when this happens is an essential skill to ensure you are able to no loose your confidence in your own abilities.

Fear of the unknown 👻

Image of a dark hallway with lights coming out from two open doors leaving two strips of light in the image.
Photo by Kamil Feczko on Unsplash

In my early days as a developer I worked as a contractor on a project for a client where we where hired to get a project over the finish line. They where facing a deadline and needed some people in to product. This was a Microsoft based architecture and it was in the years just after ASP.NET was released. Upon entering the project we learned about the guiding principles by the clients own architect. What we hear left us a bit puzzled as the way in which we where expected to go about coding components and pages went against everything we thought was right. Essentially we had to write our web application as if we where stilling concatenating strings in Perl, but in C# on the .Net platform. We where only two fairly young programmers from our company at the time, but we both thought this looked funny.

We tried to advocate for ASP.NET actually being a productivity enhancement and something which could help us reach the milestones with less effort. Especially since what we where making was a booking calendar solution, which would be ideal for the built in calendar components in ASP.NET. We tried to advocate this and show how it would make things easer, more robust and reduce our time to market. The architect was having none of it. Presenting reasons such as performance and complexity for reasons to keep the current pattern of development.

In reality it turned out to be fear of loosing control and fear of the unknown which lead us to having to implement a solution which was far from ideal and which ended up consisting of way more code than was needed. Writing the calendar booking component in a “Perl-style” was in an objective analysis far more complex and added may more code paths to the solution than the one we presented using the ASP.NET controls. What was diguised as something too complex, was in reality something new and unknown for one individual.

More advanced does not always mean it is more complex

Knowing everything about all different software libraries and frameworks is really hard. Therefor it quite often happens that there are different levels of experience in a team. Developers who’s spent more time with a certain piece of software will know different patterns of how to solve certain things than the novice just learning it.
In cases like this the seasoned practitioner could be faced with their solutions being “too complex”. What the person uttering this often should have said is this: “I was not aware this was a way go about solving this problem. Could you please tell me more”. Figuring out how to best leverage a framework or library takes practice. Especially senior developers are quick to jump to the conclusion of something being “too complex” because they don’t understand something or lack the practice in this particular framework or library.
When encountering this, it’s important to outline how the statement of something being “too complex” is false, it’s just a matter of a more advanced usage of the software we use.

I remember being thought this lesson as a young developer with the attitude and failures of many other young developers: I knew it all. Luckily I had a patient teacher in Per Otto who had the patience and skills to learn me new things. Where I previously would just “hack together” some code, he introduced me to the Gang of Four patterns as a way to more elegantly solve some problems. What looked liked something needlessly complex for me without knowledge of them, turned out to be elegant ways to solve common problems with fewer chance of errors.

Not to my personal taste

Man appearing to be outside is licking on a deadly mushroom.
Photo by Anton Malanin on Unsplash

I have on a few occasions opted to use a framework called Hapi for writing HTTP based APIs in NodeJS. This is not the de-facto option which most developers use (which at the time of writing is Express), but it has some traits I personally really like. With few exceptions the choice of Hapi is always scrutinized by developers accustomed to Express, as they are developed with two totally different philosohpies. Where one is about freedom of choice and providing few opinions in how to do things (Express) and the other is all about making decisions and laying out a preferred path as to how to use the framework to get the most out of it (Hapi).

Being introduced to Hapi is always a bit of a hurdle as there are conventions and ways to do things you just have to accept. If you don’t you will only spend a lot of time fighting a fight you will loose in the end. Most developers opt to follow the path outlined by the author, while others choose to fight the premises on which the framework was authored on every single occasion.

The concept of plugins is central to Hapi and seasoned users of the framework tend to rely heavy on building their solutions as a series of plugins. This concept does not exist in Express and the introduction of writing a piece of domain specific code as a plugin is often met with utterances such as “it is too complex” or “this adds needless complexity to our app”. What I think they actually mean to say is that “this is an unfamiliar approach to solve this issue” and instead opt to solve the problem at hand in their usual manner instead of using the mechanisms built into the framework to solve these things.

What is deemed complex by someone not familiar with the framework, is viewed as an elegant and preferred way by those with more experience in the framework. Writing a Hapi plugin does require some more knowledge, but it follows the architectural patterns outlined by its author.

🎬 In closing

Be on the lookout for the word complexity being thrown around in technical discussions. Much like other powerful words such as performance and security, it is often used to disguise something else.

There are of course some solutions, frameworks and technologies which are more complex (Hello 👋🏼 container managed persistence with EJBs in the Java stack of early 2000s), so there are situations where the argument of something being too complex is appropriate.

Grey laptop on top of a patterned blanket in a dark room.

3 råd til å takle Arbeid Under Pandemi

Tweeten over ☝er et poeng som drukner i alle råd om “hjemmekontor” og “slik jobber du best hjemme”. Dette vi holder på med nå er ikke det samme som å jobbe remote- / distribuert, faktisk er det veldig langt unna og det glemmer mange av de som kommer med velmenende råd. Jeg har jobbet remote i ca to år og det som jeg gjør i disse dager er noe helt annet.

Å arbeide under pandemi (AUP) handler i stor grad om å takle det mentale stresset du er under. Dette er ikke noe jeg vanligvis må håndtere når jeg jobber remote til vanlig. Det å jobbe remote handler mye om frihet til å jobbe hvor du vil og når du vil. Jobbe under pandemi er noe annet, du har begrenset frihet til å jobbe hvor du ønsker og kanskje når du ønsker. Tingene vi vanligvis gjør for å kompensere for å jobbe remote kan en ikke gjøre i situasjonen vi er i nå.

Derfor vil jeg gi noen råd om hvordan arbeide under pandemi, fordi dette er helt ekstraordinære tider.

Råd #1 – ikke les nyheter mer enn en gang om dagen 🙈

Dette handler ikke om å ha hodet i sanden, men det lages så mye saker hver eneste dag om situasjonen vi er oppe i at om du følger med på alt så vil du bli helt utmattet. Ved å redusere inntaket av nyheter vil din mentale helse bli bedre, du vil klare fokusere mer på å gjøre jobben for arbeidsgiver og familien din.

Råd #2 – vis litt ekstra omtanke ❤

Min kollega Alexandre Leisse har mange bra råd og ett av dem er å skape sosiale arenaer hvor man kan hjelpe hverandre i en vanskelig tid. Dette er viktig i remote jobb til vanlig, men ekstremt viktig i den tiden vi er i nå. I dag er det en haug folk som må jobbe alene hjemmefra for første gang. Bor du alene ser du kanskje ikke andre mennesker hele arbeidsdagen.

Derfor er det viktig å sjekke inn med hverandre: “hvordan går det?”. “Trenger du et friminutt på video samtale?”. Vær litt ekstra raus og vis litt ekstra omtanke. Fordi dette er spesielle tider vi lever i akkurat nå.

Råd #3 – bruk AUP som en mulighet til å bli bedre på skriftlig kommunikasjon 💪🏼

Å fordype deg i noe som kan gi mestringsfølelse når du lykkes er en herlig ting å distrahere deg selv fra alt som skjer. Gå all inn og fordyp deg i kunsten å kommunisere via tekst. Være det seg ved å skrive e-post, dokumenter, chat meldinger eller noe annet.

“Bruk video, bruk video chat” råder mange deg til når du jobber hjemmefra. Jada, det er nyttig å ha “høy båndbredde” samtaler via video chat. MEN! Og dette er viktig. Men, det er et supplement til skriftlig kommunikasjon. I stedet for å bare “flytte kontoret over på video chat”, hva med å benytte sjansen til å bli bedre til å kommunisere skriftlig?

I stedet for å “jukse” med å kjøre video hele tiden, bruk heller denne muligheten til å trene på skriving og tekstlig kommunikasjon. Gi deg selv muligheter til å føle mestring i en tid hvor alt er kaotisk. En ekstra fordel er at du blir en bedre arbeider også etter alt dette er over.

Arbeid under pandemi har få likheter med å jobbe remote, ikke la det skremme deg fra å prøve det en gang i fremtiden ♥️

Espen D.
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.