A Vision.

To me a vision is not a list of items to do. It is not bullet points on a slide. Nor is it a graph which points upwards. It is not numbers added together to make an even larger number. A series of the above things is definitely not a vision.

A vision is something that appeals to emotions and which triggers images to appear in the minds of the listeners. It does not require additional text. Any vision that does not appeal to the heart is a flawed one and it will never become a reality.

The kind of leaders that will succeed in the future will be those who can go beyond talking facts, figures and tasks. In his book “Redesigning Leadership” John Maeda talks about how leaders will need to adapt more of the mentality of the artist and the designer. You can no longer rely on facts, figures and Mackinzie power points.

You should take any opportunity and never pick your battles

Countless times throughout my career I have heard (and I think I’ve said it too): “you must pick you battles”.

I have always struggled to believe this. Why should you not make the case for what you believe? It shouldn’t be a limit for anyone for how many times they can voice their concerns.

If you have a climate where people are taught by example that you must pick your battles, what does that mean? It means that initiative and innovation is being held back by culture.

Why should you pick your battles?

The usual respons is that you can’t “win” every battle and you should save your energy. Having thought about this for some time I think this is just wrong. Asking questions or voicing concerns isn’t the same as picking a fight. People who think so are just insecure. If you’re confident on the subject at hand you won’t see opinions of others as a fight / battle or quarrel. You will see it as an opptunity to learn by having to rethink your own opinions.

Labeling a concern, suggestion or frustration as an act of starting a battle is a pretty absurd thing. If your culture can’t deal with people questioning or arguing about things you have a problem. A better suggestion than to label things or trying to prevent discussions is to instead embrace it and let everything be open and up for questioning. After all, asking questions about things is what we as professionals are supposed to do. Just let all opinions and concerns run freely and you will soon have a culture of self justice, instead of a culture were avoiding confrontations and discussions is a good thing. Embrace openness and let everything be aligable for questions. Let your people pick all the battles they want.

Don’t pick your battles, engage often and never see anything as too big to be questioned or challenged. Of course, you need to show other the same respect you expect and sometimes things must be just left alone because it’s going nowhere. However that should only be done when you feel it’s not worth it, not because someone else tells you to.
Burning Out

Having read recent articles about members of our community and how they have burned out [Burnout, Reset], I decided it was time I told mine.

I learned my most valuable work related lesson the hard way. It was my second job and I was taking on what seemed like an awesome project. Creating an application for the Palm Pilot IV. With the courage of any you programmer I embarked on it without only some C++ skills to help me out. 

At first everything was sweet and things were going ok, I loved creating something new and exciting that nobody else in the shop was doing. After a while I realized I was in way too deep with my only my college c++ skills to handle what turned out to be very much a C project. I am an average programmer with an average intelligence. To compensate I put in what ever effort is required to get past any hurdle.

I had been working quite a bit previously, but now I had to step it up a notch. My week consisted of working and going out having a drink with my friends three four times a week. The diet I was on was one of overtime pizza and late night kebabs. This went on for a while, but I was having a hard time at work getting things done. As a result I started having problems sleeping the days I wasn’t out drinking after work. It got slowly worse as time went on and at a point I was unable to sleep. I tried taking a drink to get some sleep, but nothing worked. Naturally solving difficult problems got even harder as my health deteriorated more and more. People around me was starting to ask if I was OK, because I looked like a pale ghost without any enthusiasm. I knew I was at a point where I needed to do something. The next day I went in to work and called in the project manager and the person handling the client account and said I needed a break. I could not complete this project. I was lucky and had sensible people working with me, so I got four weeks leave.

I went back to my parents to try get my shit together. It took me a week to get into a normal sleeping rhythm. After two weeks I was starting to look like my old self and not some pale looking ghost that I was when I came home. The third week I went on my own for a trip to London, in order to get a better perspective. I had been so dedicated to my work that I had completely forgot about the outside world. This trip made me realize that I was wasting my life by driving all my passion into work. Being on my own in London and taking the train all the way up to Glasgow, Scotland, was a therapeutic experience. Even though it meant celebrating my birthday alone in an Italian restaurant in near Paddington station, it was a life changing experience.

You are not your work

The lesson I learned by driving myself so hard that I turned into a different person is still with me today. I am more than the value of my work. I am a human being who’s value can not be measured in my achievements making computer programs. This is something most people know, but I had to learn this the hard way.

In our industry there is a great deal of secrecy and the topic of burnout is a tabù. One place I worked had something like a code of silence were nobody talked about people who ended up getting burned out. You could notice they were absent, but nobody “knew” what was going on. Later I found out that there had been numerous colleges who had been burned out during my time there and I didn’t know about it. This is of course bullshit and we as an industry need to stop that kind of ridiculous behavior.

I hope my story will help someone avoid making the same mistake. Work is  NEVER more important than living your life and you should NEVER let work affect your own self image. Work is just something we do, it is not life. There are some many amazing things to experience which is in no way related to work, go do them. Fuck work!

On Trust


In my previous post I wrote about Culture for Collaboration. One thing I didn’t go into was that in order to create a culture of collaboration, you must first establish basic trust.
Trust is something that is extremely hard to just “establish”, it is something you earn. In short, establishing trust is not done over night. So were to start?

Empower individuals and teams
If you by your actions and words show that you trust a team or individual you will in time earn their trust. You will also learn yourself to trust them, which is equally important.
You break this trust when you do this like sending detailed instructions on tasks to be done.  What you should do is present challenges. Make the team or individual themselves come up with tasks, experiments or changes which would work as solution to the problem. This was what we all learned when we took CE courses at colleges. We solve problems. Too often in corporate life you get presented tasks rather than challenges. Sending tasks or assignments is a display of mistrust (or even worse it displays a belief that the sender has the answer and just needs help to execute).
How am I doing in this department? I lead a team so I guess they’d be the ones to ask. Personally I feel like an addict with relapses. Having used to think I could keep control if everything I do sometimes forget this. It’s hard. Once again it’s like with parenting.  Seeing your kid suffer the consequences of learning from own mistakes is torture and it goes against your instincts. It is similar with letting go and empowering teams and individuals, you just have to let go and trust them.

Growing Pains

If the general vibes are that there is a lack of trust and a continued presentation of a Us vs Them scenario you will have an organization without trust, and in return with little actual collaboration.
What happened? The explanation is usually “growing pains”. However that is false, as growing pains have a tendency to pass as you get older. The so called growing pains of an organization never does that. In fact it just gets worse, because the effort required to change something that’s grown too big is too large. The risk is too great and the daunting prospect of change has too many potential down sides.

What to do? You could just give up and go with the flow and when shit hits the fan (and it always does), you just move on. Another option is to tackle the problem of growth at the root cause of the problem. Growth.

Large problems should be divided into smaller ones

Make it small. It is what we as developers do when tasks are too high right? We split them up into smaller more tangible tasks. Why not refactor your organization? What are the benefits of doing this refactoring?  Reducing size will help reduce the alienation between teams and those managing teams. There is no room for “free riders” in small organizations (Well, there is room of course. But those organizations won’t last very long). You reduce the number of communication lines drastically. This means everyone is closer to the actual production. No need for reporting or endless meetings where people, who should know the product on the first place, gets to learn about what is happening with their product.

Another thing is that reducing size increase a sense of ownership and increase the feeling of being in it together. You know that feeling you once had? When there were just 30-40 people and everyone was going for it? If you speak to people who’s been with a growing company for a while and they talk about that time,  it sometime feels like they’re talking about a lost love.

Now, reducing size has it’s down sides. There will be much greater responsibility for everyone. You will probably have to do things which isn’t really “what you’re supposed to do”. Of course this is actually a good thing, as doing unfamiliar tasks gives you the chance to see things from a perspective and it could help you become better at your regular tasks.

Another side effect is that some of the parts being “cut loose” won’t handle the situation. This is a good thing. Reducing size increases the level of transparency. There is no hiding when all the layers of people are gone. You can not blame anyone else when you’re on your own. What this does is that it gives everyone a feeling of ownership and it also makes everyone more focused on the task at hand. When there is nobody to blame, behavior tends to change for the better.

In closing…

Yeah, so that’s it basically. Easy no? Just go ahead and refactor your organization. Use the “Extract Team from division” refactoring, or perhaps the “Push Down manager” refactoring? How about you just do the classic Remove Middle Man(ager) refactoring? 
Of course this could be just plain stupid. I mean I have no actual education or real experience doing any of this, so what do I really know about this? What I do know, is that it is people who’re supposed to know these things who create these bad organizations with inefficient work environments, so perhaps it’s time to let someone else have a go at it?

Culture For Collaboration

"It is so cumbersome to have go round talking to people and submitting pull requests. Can’t we just go ahead and just duplicate or do whatever we want?"

Yes, working together and collaborating is hard. It requires a willingness to listen to others and learning about different points of view. This is of course something which takes time to get right.  Because it is about people and dealing with people is different each time and for each interaction.

The past few years there has been a tendency to focus only on a team. The team is always entitled to do whatever they feel is correct and requires at the time. Especially a team should always shy anything that is common. Libraries, frameworks and any common component will only slow a team down. This is the mantra of many agile thought leaders.

Now, if you look at this in a short perspective and with only an isolated project I would agree. However if you are looking at this from cultural and a human level, I disagree. If ever team shy away from anything created by outsiders, how can you create a sense of community? A Not Invented Here on a team level will really hurt a company. It makes collective code ownership almost impossible of course.

Having a culture for collaboration does not equal a culture of building massive frameworks and over engineered architectures. I think it boils down to making choice based on the common good and not what is fastest or easiest right then and there. It is about taking into account how you can make things better for the next person being in your position. 

It is kind of like the boy scout principle on a team level. When a team encounters an issue: a library which is outdated, some code which needs refactoring or a module which isn’t quite generic enough for their use case. The team tries to see how they can improve it and still get things done. Naturally there will always be a balancing act, but the instinct should be to seek to improve the whole.

Never listen to thought leaders

The mantra of the thought leaders tend to be quite the opposite. They have one great enemy, the software architect. In order to conquer this nemesis they say that all developers should go choose what’s best for them and it will always be the best solution. To me, that is someone speaking who haven’t been staying with a company for very long. It is a short sighted approach, to instruct teams to build walls around them. That kind of strategy works really well for contractors and especially when you have fixed price or goal price style contracts. You deliver really quickly and reach your targets, without the slightest thought about those who’ll be living with that code when you’ve left. 

Embrace openness

Having a culture where teams embrace openness and which tries to reach out to improve the whole will prove beneficial in the long run. It will help you build an organization which will gradually improve and continuously build with better quality and quantity. 


To me focus is binary, you either have it or you don’t. You can’t somewhat focus on something. Either you do it or you don’t.

I also have a strong opinion that focus can only be kept on one thing, if you’re a human without mutations. It is not only my subjective opinion, it is  scientific fact that we can only focus on one thing with our eyes.

Now, how come every time you hear the word focus in a work setting none of the two previous truths apply?  “We will now focus on these five important things”. Or “we need to broaden our focus”.

You can’t succeed unless you follow the two principles I first mentioned.

On Contributing

A couple of months ago I made a pledged to contribute more in the open source community. How’s that going? Well, it isn’t going in rocket speed but I have published my first public NPM module. In addition I have submitter some pull requests to other projects. Working at my day time job I have the privileged to put some of our modules out on GitHub and try to make gradual improvements to them. 

This isn’t all that much, but at least I haven’t forgotten about my pledge.

On Leadership

Yesterday I tweeted that “I’d rather choose someone with experience from kindergarden than some one from the armed forces as a leader”. It might seem like good old fashioned trolling, but I am serious.

I speak from a Norwegian perspective and things might be different in other countries. When working in kindergarden you acquire some skills which I think are essential for leaders in general, but especially in knowledge companies. In Norway the law says that children shall always be included in decisions [1]. 

I have never been in the military as I’m a pacifist, so my facts are based on information found on Norwegian military web sites. Like the introduction for students at Norske Krigsskole, which is considered one of the best schools in the military sector.

I am not an expert at any of these things, so there is the odd chance I am talking out of my back side. However, let me just generalize enormously just to explain why I think the qualities required to lead a group in kindergarden are closer to the ones you want a leader in my industry to possess.

In all of military there is one truth which undermines everything and which is the thing that is not negotiable: you obey orders. Without soldier following orders without questions, military operations become really hard to perform. That is not the same as suggesting there never are objections or discussions, but a chain of command is essential in heated combat. 

When trying to get a “platoon” of 3-6 year olds to agree on something, at least in Norway, you can not rely on obedience. Granted the kids can’t do whatever they please, but you are obliged by law to make sure the kids are in on the decisions. It is like a consensus based democracy, where anyone can block but everyones opinion must be heard.

Another difference I think is important is that in kindergarden you’re learning kids how they themselves can find ways of acquiring knowledge and lear skills. In a military context your job is to repeat and drill those you command so they act without hesitation. These are quite different ways to operate.

I would argue that the skills required for enabling kids to learn are more important than those required to train for military operations. That was basically the basis for my rather tabloid tweet. You can of course learn useful stuff in a military education too. I was generalizing that it isn’t the skills that makes a good leader in my opinion. 

These were my subjective opinions on things I have only a little bit of knowledge about. You are welcome to disagree and you are welcome to enlighten me on the importance of military education. If you were offended by my words, I apologize as it was not my intention to offend. 

After having had a Pie laying around for over a year and ordering miscellaneous parts on eBay from China I got it running with a touch screen. It felt like an achievement, even though all I did was add power and connect some wires.
I am complete blank when it comes to electronics. Back in the days I was capable of making simple repairs om computers, but when it comes to signals and circuten boards I am a complete novice. I have no real idea what to make using the Pie. First task is to get the drivers for the touch screen enabled.

After having had a Pie laying around for over a year and ordering miscellaneous parts on eBay from China I got it running with a touch screen. It felt like an achievement, even though all I did was add power and connect some wires.

I am complete blank when it comes to electronics. Back in the days I was capable of making simple repairs om computers, but when it comes to signals and circuten boards I am a complete novice. I have no real idea what to make using the Pie. First task is to get the drivers for the touch screen enabled.