In this day and age there is so much knowledge about how to work effectively in different circumstances that surely there isn’t anything left to talk about. There is Scrum for projects, Lean for just about everything and pommodoro to help us pace our work in a way that is optimal for our brains. So writing about the topic is kind of like beating a dead horse right?
On the other hand being good at something is not about knowledge. I’m sure there are a lot of people who actually know a lot more about basketball tactics than Michael Jordan, but there is no one who can even come close in making that knowledge come to life in a basketball court. It takes a lot practice to turn that knowledge into a useful skill (and habit).
I feel that we are in a place right now where there is a lot of information about how work effectively and a growing amount of awareness. Yet we are not applying this new knowledge into practice is widely as we could be. Understanding why this is the case is a very complicated topic. Instead of trying to write an all clarifying answer (which I can’t do), I will reflect on an example which happened to me recently.
A service design example
I was invited to participate in a meeting/workshop to talk about the service concept for a new IT system. The meeting was very cross functional and all the relevant departments had one or more representatives. As a consequence of this the meeting was quite large (about 15 people). The meeting started out well with the chairman recapping the purpose and positioning of the new service and we had a very lively (and productive) discussion about the “big picture” and design principles. The participants were very motivated and wanted to contribute.
Soon the discussion started to move more towards the details of the new service concept and we started covering topics like:
- What high level functionality should it have?
- Do we understand all the needs of the different user groups?
- What is our mobile strategy?
- How configurable does the system need to be to fit all the different preferences of potential users?
- How do we integrate it into other systems and what information is available from them?
I noticed myself getting a little frustrated for two reasons:
- It is very difficult for everyone to contribute in an effective way. Usually a few people take over the discussion and many good ideas are not discussed. The discussion can also very easily get stuck in meaningless details. Without excellent facilitation the energy levels will inevitably go down.
- This type of design method will also very easily lead into a service that has “all the bases covert”, which usually means that the important parts (from a user point of view) are hopelessly lost in the jungle if “important” features. This is almost inevitable results of the simple fact that everyone wants to contribute something to the end result and usually this something comes from their functional viewpoint.
I interrupted the meeting with a suggestion about a different working method:
- Split up into teams of 2-3 people
- Each group has a week to design a wire frame prototype of the service. The prototype should reflect what in the teams opinion are the 3-4 most important elements in the services
- Meet up and present all the different prototypes to the group and discuss their strengths and weaknesses.
- Design a couple of new prototypes by combining some of the best ideas from the previous rounds
- Seek empirical validation for the most promising prototypes
The suggestion got a good reception and we decided to proceed accordingly. “All is well that ends well” – we decided as a group to utilize an effective working method for the situation (at least in my unbiased opinion!) and hopefully that will be reflected on the end result. Except for the fact that I was left with the distinct feeling that perhaps we got lucky and we just as well might have chosen to proceed using the “committee design approach”.
I could of course pat myself on the back for being smart and saving the day, but I don’t think that would be very honest. I think there were a lot of different things in the meeting dynamic that let to this positive end result and luck also played a large part. I think that there were also certain “forces” that could have pushed us into a more undesirable end result. This list is by no means comprehensive and only reflects my initial thoughts on possible reasons why a group would not utilize good working practices:
- Not enough knowledge about good working practices for the situation (the obvious one, but perhaps not the most important one)
- Will I look foolish if I suggest something new and the others don’t support it?
- Will I make the “chairman” look stupid and cause him to have negative feelings towards me?
- Will I look like a smartass?
- Someone else must have thought about it before and there must be a good reason why we are doing it this way
- Time pressure – it’s just easier not to try a new way
- Risk adversity – what if the new way does not work
- Not my role/job
- The new method is cool, but does not suite this context / our business culture
- If I make a suggestion I should be an expert in the method
- If I make a suggestion I will be responsible for the results
- Let’s not rock the boat
- The others won’t go for the new method (prejudice)
- This has worked for us in the past, so it will work this time as well (no need for new methods)
Help me make this list better by telling me: 1) what’s not on the list, 2) what are the most important reasons in your opinion. I would also love to hear your strategies to overcome these obstacle to new and better working methods.