(w00t!)
Motivational tip #1: stop demotivating

Many companies spend an awful amount of resources and focus on trying to motivate their employees. This is of course I theory a great thing which should benefit employees. There is however one thing every company should look into before looking at how to motivate:
“What are we doing which demotivate?”

Are there hurdles in our organization which prevents people from doing their job? Is there something we’re doing which drive people nuts? Having leaders who recognize and remove obstacles which are making employees frustrated is the best thing you can do to motivate.
Spend time analyzing your company and talk to them about what drives them crazy. This is more important to them and will make them happier in the long run than any gimmicks.

A counter argument I often hear when uttering this viewpoint is that some people aren’t motivated by work alone and need gimmicks to be motivated. The question then becomes: why spend time motivating those who aren’t motivated by work? Are those the ones who have a big impact in your company?

Stop making people loose their motivation, remove obstacles which are preventing them from doing their job. That should be your strategy for making employees motivated.

Tribute - Evernote

There is one service I have used frequently ever since it first emerged and I thought I’d pay tribute to: Evernote!

Evernote is an amazing service I have enjoyed since it’s beginning. It is so very simple, but it solves an issue I had previously: the need to store stuff online and have it accessible anywhere. I use Evernote for loads of things. All my travels are organized using Evernote. The offline premium feature is ideal with roaming costs being ridiculous.

I scribble down the rough outline for all my talks using Evernote. Blog articles and things like that I always write up in Evernote. It is also a nice place to write down ideas, notes from meetings and as a to do list. I use Twitter to get a lot of stuff out of my system. However, there are things even I don’t blurb out on the twitters. For those kinds of things I have the “Never notes”-notebook :) The notes are there to remind me of stuff I’ve put behind me and the process of writing the notes is very therapeutic.

Slowly becoming more awesome!

Over the years the service has not changed all that much. It had been getting some awesome new features, but they’ve always done it at a slow steady pace.

The last year they’ve added some of the stuff I’ve been waiting for since the beginning: group notebooks (stacks) and the ability to draw in notes. Especially the drawing feature is just amazing, I just love it!

Evernote with it’s seamless syncing and accessibility on all kinds of devices. I just want to thank the people making Evernote.

Why NodeJS is getting a “free pass” into organizations

I remember reading about The Change Function, which was a term I first read in the book with that as the title by Pip Coburn.

I was recently reminded about this as there was a discussion at work about how NodeJS was slipping in unnoticed, while things such as Grails or Scala was having a more difficult time. I think that NodeJS is making headway in rapid fashion because it has both the parameters needed for the change function:

 f( User_crisis, Perceived_pain_of_adaption )

There is a very real user crisis when it comes to making web applications in the traditional enterprise technology stacks, such as Java and .Net. NodeJS helps ease this pain and Grails also promises to do so. Perceived pain of adoption is how difficult users think a technology is to adopt. This is not something objective, but the feeling users have. On this parameter, Grails fails as it is sometimes perceived as a bit more difficult. You have to learn Groovy with it’s new syntax, tools and frameworks. While NodeJS is just JavaScript which everyone think they master, even though this might not be true.

Scala, in my opinion (and if you disregard that Oracle is the evilest of empires), does not solve an obvious user crisis we are having right now (this is were the Scala people can fire up their flame engines). Sure, there tons of developers frustrated by Java. Scala is probably a much better fit for many of the things programmed in Java today and it probably is a better way to program robust systems with it’s functional style etc. I am not saying this is an objective truth, it is just my impression that the crisis isn’t here yet for Scala. You have stuff like Akka, but few companies actually have a need to that stuff as of right now (at least in Norway). Scala also falls short when it comes to the perceived pain of adoption, event though it runs on the JVM. The syntax, tools and frameworks seem unfamiliar. Developers doesn’t really like change (even though we try to convince ourselves we do) and a change to Scala from Java seems like a big deal.

I think the answer to why NodeJS is getting an easy way into many companies is that NodeJS solves a user crisis and it is perceived as easy to adopt_. This is not due to rational or objective thinking, it’s just how humans work. I think anyway, you may disagree.

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

image

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. 

Focus

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.