Problem-solving, we all are people

Normally we are involved in the construction and/or operation of complex systems (well I’m not talking about rocket science).

IMHO this complexity has at least two components:

• the complexity of the topic the system we are building needs to manage.
• the interactions that happen inside the group of people that will be accountable for designing, building, operating and maintaining the system.

Surely we are going to face problems and our approach to the problem-solving will be very important for the success of the system’s life.

An effective problem-solving approach must provide in addition to a solution now! (full stop), a foundation to allow to cope with similar problems in the future using fewer resources (time, money, headcount).

I like to remember what is written in the first ten lines of the preface in the book ‘Peopleware’ by Tom DeMarco & Timoty Lister:

Maybe … the major problems of systems work are not so much technological as sociological

This means that the problem-solving process has a sociological side.

To solve an issue I need to interact, talk, listen to other people. This situation will trigger natural human reactions:

• Role: I’m looking for some help: does this means I’m not skilled at all?
• Role: I’m looking for some help: does this means that I feel my self-esteem is dropping to zero?
• Role: I’ve been contacted for help: I will be able to show a collaborative and positive approach toward the help seeker?
• Role: I’ve been contacted for help: after I have provided the tip for the solution, I will start saying to the world: I’m the king of the hill, all other people know nothing about this.?

When trying to solve a problem is clear that the main objective is to fix it, but is very important to hit the target without creating collateral damage in the rest of people that were trying to solve the issue. Do not forget people feelings.

If you have been called to help, you have the highest percentage of the responsibility to avoid collateral damage.

Sometimes you need to be very careful because you are by chance in the room where the problem struggling is happening, nobody has asked for your help but you feel you can do something. How you can offer your collaboration without making people feeling ‘ … hey guys, you don’t understand anything let the master save you…’. Again, people have feelings, do not hurt it.

Knowing what we have done to have this problem to solve is an important thing, to prevent it in the future.

Unfortunately, a lot of times we have been ‘launched into the area of a new project’’ as Rusell Crowe in The Gladiator without the minimal information, nobody has provided a ‘survival guide’. This affects a lot our capacities to manage problems, and again our self-esteem.

The modern approach seems to be:

• don’t worry to understand/learn too much. If you are a business analyst you can ask for a developer that will manage the issue. if you are a developer you can ask for a techie that will manage the issue and so on.
• if you learn something, do no use time to be sure this knowledge could be accessible 24 hours 7 days a week. (AKA do not document)
• the system is right now configured and functional, then if a similar configuration will be needed in the future the only thing you will need to do is ‘copy & paste the configuration’ and … probably all is going to work fine.

Ancient approaches are revisited: Instead ‘Divination reading animal entrails’, we use ‘Divination reading of System Internals’, activating or adding debug messages in order to answer the question: Why the configuration that I’ve applied does not show the expected outcome?.

Creating a network of people with the right knowledge is not a bad thing. They are the people that know how to put the right piece in the right place of the puzzle.

The wrong thing to do is not maximize the benefits of this network because we overuse it without never creating persistent all-around-the-clock accessible knowledge. It’s clear you can not ‘capture’ people genius, analysis capacity, or intuition but all other things must be ‘distilled’ for the sake of the team, and finally for the sake of the company.

Avoid to work in a ‘Hansel & Gretel’ way, do not manage your findings, your learning as bread crumbs, because when you will need it again you are going to find that ‘the birds’ have eaten it!!.

What can be one of the worst feelings when you face a problem, is the Déjà vu, you said to yourself: ‘… mmm oh no, we have had this issue x days/months/years ago, how we can be so silly to do not document how we solved it?’. At this moment we understand Sisifo, we are Sisifo.

Solve the issue now, but do not forget that sooner o later someone (mmm, maybe yourself) is going to need all the knowledge, genius, effort you have done. Without all this power, things will be solved at a slower and more expensive pace.

Creating persistent all-around-the-clock accessible knowledge is much easier and simpler that you thing, just make the first move and inspire others to follow.