Mar 17, 2015

Role of the line management in the future - is there one?

Line management has a long history and quite often a special place in organizations. Line manager position have been something people are going after. Things have been changing, role of line management has been fading and even in some case going away. Still all organizations have some kind of line management. There's someone in every organization who is the boss.

Role of the line management in the future organizations is a difficult question. In one hand line management has it's role of bringing comfort and safety for the people, but then on the other hand it can slow down work, create competing priorities and even demotivate people. Especially difficult it is when line management has ties with operational responsibilities and company size grows over one team doing it all mentality.

In the past line management have had lot of operational responsibilities. Line manager used to be responsible that his or her people did their jobs properly. Also line managers did have content and operational responsibilities. They had to make sure right things were done and also in the right ways. That still seems quite natural, it's quite hard to guide if they can't also affect on the work their people are doing.

Then line managers started to get more and more responsibilities of the soft side of people. How people are doing? How they are developing themselves? And what worries they have? At that time there started to come more operational and content related guidance from other sources and line management didn't have that much to say about the content their people were working with.

Nowadays line management in many occasions have become almost totally HR function. Line managers arrange the one to one discussions with people, focusing on personal development and in some companies also to set targets.

Future of line management


Do we really need line management in the future organizations? What if we wouldn't have line management at all. No one couldn't tell people what to do and people would need to figure out themselves. I bet this would work in many cases. There are even examples of self guiding organizations, where people just make things happen. No guidance needed.

This sounds like an optimal approach. No one would have boss whom they would need to report to and no one would ever come to say what to do. Even though it feels like an utopia I believe organizations could work without any line management. From content point of view I don't believe people need to be told what to do, they can figure things out themselves.

So is there anything line management is still needed then? I can see two important points. First people need safety. People need to have someone they can count on in case there is something they can't figure out themselves. Things like this can be about company functions as pay or healthcare or then about how people behave. Once in a while there are misconducts and then it is important that there is line manager to help.

Second important point is personal development. It's rare that people would be that good on analyzing their own competences and the improvement needs that they wouldn't benefit from having a good teacher or coach to help them. This is what line management has a proper place in organizations. Line managers can help with competencies and guide and push people to develop their competence to right direction. They can also work as enablers to get training, coaching and peer learning from other people.

Both of these activities, safety and competence development doesn't actually need people to be bosses. The people responsible for these in organizations do need to have certain authority to do these jobs well, but they don't need to be supervisors in the old sense. I believe role of line management can actually be a service in the future. Many aspect of line management already are handled as a service, but maybe all of it could be.

So do people really need just one supervisor to help them. Why they couldn't have a small group of them working as a service guiding and helping people on in all the necessary ways. Somehow I feel this change wouldn't actually be that big to the ways many companies are already working. The change would be mainly mental. Line manager wouldn't mean your boss anymore, it would almost mean that you would be the boss and line manager would be the servant.

Written by +Henri Hämäläinen

Mar 1, 2015

Book Review: Run Less Run Faster

I try to read couple of sports books every year. I've heard from couple of different sources that Run Less Run Faster is an excellent book for busy runners wanting to develop their run.

Idea in Run Less Run Faster is easy, concentrate on your key runs and make sure you stay healthy. Book advises to get rid of junk miles, meaning the runs without specific purpose. Also it explains that three runs in a week is enough when it's supported with proper supporting training.

I do agree with the thinking in the book. I've run maximum of three runs in past years and I've been able to run much faster than previously. I've also discovered that key to improvement is different kind of runs and pushing yourself to the limits. So I do think book is good and valuable for many people.

Book also gives quite good exercises for runs and strength training. It is a good source for knowing what speeds to use in different exercises and what should be the amount of rest in different intervals. Also for strength and flexibility training it explains the basics.

What I worry with this kind of guidance to training is that it kills the joy of training. When every exercise have specific meaning and you need to watch you clock all the time, you easily lose the joy you can get from exercises. Everyone, including myself, should once in a while remember why they are training, for themselves or for some other reason.

The book in itself is easy and enjoyable. Especially for the runners who don't do enough different kind of exercises, this is a must read. For the people who already have wide range of training in their program, this might not be be worth of reading.

Written by +Henri Hämäläinen

Feb 24, 2015

Why Change Fails - 4 Key Findings

I've worked with several companies as a consultant helping and leading change projects. Also I've experienced changes from the inside and heard many stories from other companies. Based on that experience, here are the four things that are the main reasons for change to fail.

1. There is a plan for the change, but not a vision for the change


Organizations detect needs for changes easily. All the time there comes ideas from the inside or outside for the change. Once in a while change idea gets to a proper group of people and they have the power to start the Change. Then starts the short planning phase. Budgets or people are confirmed, timelines are created and benefits of the change are communicated. What often is forgotten is the underlying reasoning for the change and especially the vision of how the new model should work.

This becomes a problem when there will become changes to the Change. And this always happens, the Change will never go directly as planned, but there will be needs for re-planning. This is acceptable and normal, because there will always be learning happening during the Change. The problem arises, when the vision why the Change was done in the first place is forgotten and changes to Change project will actually turn the ideas to the wrong direction.

An example of this kind of behavior could be streamlining error handling process to cut time from error reporting to error fixing. During the change process, the team finds out that there is company level KPI of the error severity and the change would mess that measurement. So instead of removing some states of the process they decide to create an automatic ranking and assignment system based on the error location component, reporter and SW version. Then for each person handling the errors they'll advice to make sure the error ranking and assignment is correct. In the end the error process actually got longer due to the automation of one part of the process.

Even though the example is simplified and might sound silly, this kind of things I've seen to happen often. The idea behind the change is slowly modified to something else during the change process. The only way not let this happen, it to have few people to have clear vision of the backgrounds of the change and to empower them to lead the change.

2. People are not actively involved early enough


What I've learned with changes is that people do not that much like to be involved, but they hate if they are not asked to be involved. So it's not that important to get everyone involved to the change early, but it is essential that all relevant people are notified about the change early.

In many occasions I've seen people to come later to say that they would have liked to give their opinions earlier. For that reason, I've tried to involve as much people from the beginning as possible. Most often people actually don't have much to say and are not that interested to participate after all, but they are more friendly towards the Change because they were asked early.

So the learning really is, involve all the relevant people from the beginning. Don't take them in to the core group, but ask for their opinions in one to one interviews or targeted questionnaires when the group is larger. This is essential part of success of the Change. It will cut down the possibilities to be against the change later on.


3. There isn't enough time given for the change


I come from the software world, where everyone nowadays start to know that estimates always fail. Projects rarely get done on planned time frame. Still with Change Projects, these estimates will fail much more. Organizations somehow always forget that they have their daily business to take care on.

This happens always, organizations fail to estimate how much they have time and capabilities to use, to properly drive a Change through. Getting on hold of people and finding time to secondary activities in organizations easily take weeks.

Then in the long run, people will get frustrated about the speed of changes and some of the changes will die because of slow progress. There needs to be realistic schedule for changes and people who selected to drive changes forward need to empowered for the work. These feels like basic stuff, but somehow these seem to fail in many occasions.


4. Change resistance are not handled correctly


There is two types of change resistance: late adopters and the people actually against the change. Late adopters are people who take time to understand the value of the change. They often ask good clarifying questions and are valuable part of making the change better. Then the other group is the people who for a reason or another are not willing to accept the change. In some occasions they have valid arguments, sometimes they have their own personal reasons not to play along with others.

With both groups it is essential to talk with them often. The worst thing to do is to ignore them. This will raise even more resistance and it might cause a movement against the change. Best thing to do is to confront them. You don't need to agree with them, but try to understand what is the good intention they have in mind. This is the essential thing again, people need to be heard, not necessarily agreed with.

My tip is to confront change resistant people one to one. When talking to change resistant people in a group, they will never change their mind and lose their faces in front of the group. Talking with them one to one makes it possible for people to change their view. Still when talking one to one with change resistant person, the goal shouldn't ever be changing ones mind. The goal is to understand why they are against the change. You don't need to change your own mind and they don't need to change their mind, but the goal is that you both mutually agree each others view. After that there are several alternatives forward, but before mutual understanding, there isn't almost any.


Summary of my tips to successful Change Project 


Change project are difficult, but not that difficult. The approach for change often is too pragmatic, there's too much planning of communications and steps to take. There should be more focus on discussions with people and having enough time for the change.

Other key thing is to remember why the change is done. Even though it sounds ridiculous, I believe many changes fail because at some point no one remembers what was the actual problem the change was suppose to fix.

Last but not least, people working on change easily forget, that the change isn't the most important thing happening for the others. For many change is just one of the many things ongoing at daily work. Changes need active communication and involvement. It isn't enough to publish information available, there needs to be active feedback loop in making sure that the messages actually gets delivered.



Written by +Henri Hämäläinen

Feb 15, 2015

Book Review: The Lean Startup

The Lean Startup by Eric Ries was a book I had heard about so many times that I had to read it myself. I had heard about Lean Startup methodology and read about it in many blog posts, but I hadn't read the book. In a way the topic was familiar even before starting, but still there were learning to gain from the book.

Ideology of Lean Startup is really valuable. I believe there's some truth behind what Eric Ries is talking about. The main idea of Lean Startup is that is valuable to measure the ideas in the market and be willing to learn from the results and pivot the course if needed.

I especially liked what Eric wrote about what actually is an MVP. In my own believes I often seen MVP to be much less than companies are themselves thinking it to be. Also validated learning, innovation accounting and the whole build-measure-learn loop were valuable parts of the book.

What I didn't like was that the book wasn't anywhere close to minimum viable book. It was utterly too long and once in a while even boring. I believe the ideas of the subject could have been delivered in 100 pages. That would have proven the value of the thinking. Now it was as any other ordinary book, lengthened to almost 300 pages in order to seem as a "normal" book. I just hate that approach. When there isn't that much to say, why to waste so many pages on it.

I feel bit bad to criticize the book since, I think that everyone should learn about the Lean Startup methodology. It is valuable and would help many companies and startups to succeed. I believe the book just isn't the best way to learn about the subject.


Written by +Henri Hämäläinen

Jan 29, 2015

Story inside Nokia - Creating SW Solution in Enterprise Agile

Symbian has been long enough dead and Nokia has moved on from smartphone business, so maybe it's time to tell a story from inside. I was there in Symbian Multimedia for 6 years. This is a personal story about how hard it was to create new software using many existing assets of the company.

It was the time teams had been using Agile methodologies for some time. Some teams used Scrum, others Kanban. At that point there was going on a huge transformation towards Enterprise Agile. One of the main concepts was Epic based development. That basically meant that Epics (you can think those as big user stories or projects) where created to describe the customer value regardless of the organization or product limits. So the idea was excellent, to be able to exploit the software and product assets of Nokia for customer benefit, what ever needed.

Story of Epic and 113 people


So I got appointed to be the Epic Owner for one of the first Epics trying this new process out. Epic as such wasn't my idea and the contents of it are irrelevant for this blog post. In short basic idea of the Epic was to combine Entertainment and new social technologies. So it was a perfect example for the Epic thinking. It used existing SW assets, needed bit of code on top those and would create a new kind of value to the customers and new business to Nokia.

There was a small team gathered around this Epic. I can't recall exactly, but I think there was 5 of us in a team. My role was to work similarly as product owner to keep the vision of the Epic in place and make sure our team could actually accomplish the thing.

After the start, first things was to get to see the codes, API documentation and stuff like that from different SW teams. Those would help us creating the solution we were after. That already needed lot of internal selling. I flew around and had quite many online and face to face meetings to convince the involved teams to let us work with their code.

After we had everything in place to start, we were able in less than two weeks to have a well working prototype about the solution. It wasn't in the sales quality, but good enough quality to show around. At that time we started to do more internal selling to be able to actually make the final solution, which wasn't that complicated in the end. That was the point we hit the big organizational wall.

There was tens of people who wanted to have their say what was needed to take in to account before releasing the solution out. Some of the people had valid points, since releasing to basically all the countries in the world was not that easy. And all the others were still doing the job they were hired to do. It was exhausting. We had a solution, but getting it out from the company was near to impossible.

One evening I was flying home from one the internal selling sessions, when I started to count that how many people who haven't contributed anything to code I have had to agree with. The number raised to 113 people! There had been 113 people who I had to talk with, in order to get a solution that took 4 developers less than 2 weeks to prototype, to get approved and released.

It's not an extreme case


Some of you might think this is extreme example of how things can go wrong. I'm sorry to say that's not. I've seen some other product development companies to have this problem too. In many cases creating the software isn't the hard part in creating the solutions. It's all the internal sales that need to happen on top of the solution. There needs to be, even in smaller organizations, tens of people who needs to approve the plan before something can actually happen.

There's a good intention of course behind all of this control. People often mean well. They have their own view to things and they want to control that something that is under their radar get thought properly. But that is exactly the problem, companies shouldn't be build on control, but on trust. But that's a different story.

More and more organizations have extensive SW or Product Portfolio. One of the things I hear discussed in many companies is, how to leverage the existing assets better to create new kind of business in the future. This definitely makes sense, it at least these kind of solutions could and should bring competitive advantage and to be even lot cheaper to create.

Unfortunately organizations rarely are ready for this. For example internal cash flows (meaning budgets) can make cross team work harder or even impossible. Also layer of product managers looking after their own products is a common show stopper for these cross product exercises. But there are lot of other hurdles in the way and this post's purpose wasn't to go in to too many details about that one.

Overall the problem is common. Big organizations should have all the assets to compete against the smaller ones, but most often the only way to compete it to acquire the small ones. For many reasons, big companies can't create innovative product easily. My example is just one from many different barriers.

Final Words


As a final words I have to say Symbian organization in Nokia was at the time really advanced in Scaling Agile to Enterprise level. There was lot of good practices in place and lot of competent people driving those forward. In order for the Epic thinking to actually work, it would have needed years of cultural change. This change was started, but as all of us know, Symbian was left burning and change never got to the end.

Written by +Henri Hämäläinen