Empowering people

On 27th of May I was privileged to attend second time for lecture by Wolfgang Steffens. This time he talked to us about lean, self organized teams and cost of delay.

Again there were a lot of good points and interesting topics in Wolfgang's lecture, but what probably hit me the most was the topic of victim versus empowered. Generally this applies to everything and can have a major impact of person's life. It boils down to this question: in case of some issue occurs, do you tend to be a victim or are you empowered and willing to do something about it?

Being victim is easy as you can blame external entities, there wasn't enough time, money or knowledge, I didn't have the power to make that decision, specifications were incomplete so I couldn't complete my work and so on. Although all of these can be true, empowered person would start to wonder what can I do about this. If the specifications are incomplete, maybe I could ask the other team to complete this by tomorrow. If we don't have enough money to implement all wanted features we will try to implement as many as we can as well as we can. Empowered person always thinks there is something I can do.

Being empowered is extremely important for productivity. But what can you do in order to empower the people around you, what does it require to be empowered? Few major things I wrote down from Wolfgang's session were ownership over what you do, being committed (I choose to ... because) versus being complied (I have to) and having meaning (clear vision, feeling of being part of something bigger).

Wolfgang said it well: "people want to be the best they can be". Of course there are exceptions, but generally this applies to everyone, I believe it is part of most human's nature to try to be the best they can be. At least I get satisfaction when I know I've done a good job. Give responsibility, let people make mistakes, let them learn and let them earn trust, let them be the best they can be and you will surely empower people in your organization.

Focus on the Product

One of the things I've picked up from application lifecycle management course that has had maybe the most influence in my daily work was when the following product lifecycle management principle was introduced to us.

"PLM puts the focus on the product"

Summarized this meant that in PLM both customer and product are important, but product comes before customer. In Humap Software I am constantly involved in service business and in service model this is not such a great principle as is. But I noticed this made me to think about the service paradigm.

Customer rarely has high level expertise about the field of technology in which we are creating the services them for. Because of that it is also unlikely that the customer can create exact specifications about what they want. Or actually customers can define what they want, but because we have the technological expertise, we can come up with more sophisticated solutions which customer might not even consider in the first place. What customers can very well do is to define what kind of problems they have. Our job is to analyze those problems and create as good solutions as we can.

I know that was bit provocative. Usually customers have good ideas and they have more or less good vision about what they want. This just got me thinking that we should always pursue towards the most excellent outcome and be brave enough to question the customers' views when we see a better solution.