Difference Between a Mindset and a Process

When coaching, I frequently make this observation. People want to receive instructions about how to do something and then move on. “Tell me what to do” is the question in their mind. When I respond to their request by explaining why they should do something, I start to loose their interest. There is really no difference between a regular team member and their manager. But it seems to correlate with the culture of their organizations.

These people are interested in being shown and taught a process. First you do this, then you continue with that and finally you check that and if it’s right, then you continue here. They like a linear and predictable way of doing things. Show up for work, do the things you have to do and leave.

A while ago I read somewhere that our human brain likes linear processes. First you get hungry, then you find food by doing all these steps and then you will feel happy. If that’s the case, then these people act perfectly normal.

But then creating things - and that includes software - is so much more than finding food or shuffling information from desk to desk. It is an entirely creative activity in which there is no clear separation between right or wrong. There are many wrong ways of doing it but also many right ways of doing it. So knowing and understanding why someone is doing it in a specific way seems to be important. Important because that knowledge may guide you to further learn in the direction of that person or someone else.

What I just called ‘learn in the direction’ is a complicated and probably entirely wrong way of calling this a ‘mindset’.

A mindset is not a belief. It has to do with assumptions and with a point of view. In German there is the term “Weltanschauung”. It means how someone views the world, which is a general philosophy of understanding the world based on assumptions and cultural background.

Something like “Agile” as expressed in the Agile Manifesto is clearly a mindset. It also is a preference. By saying “Individuals and interactions over processes and tools” the speaker makes it clear that he prefers one thing over the other and on request will explain why he does. He will likely not accept the opposite until you convince him that the other provides more benefit.

A mindset is based on experience and teaching. A process is purely based on teaching. You cannot successfully follow a mindset because someone taught you the rules but you can successfully follow a process after being taught the rules.

Acquiring a mindset requires to understand the Why of all the things the other carriers of said mindset do. In the case of a process understanding why you do something is not really important. You can still use it and be successful.

A mindset will grow stronger and become more and you will defend it more and more once you make enough positive experiences of applying it. That is when a mindset starts to morph into a belief. A process is easily abandoned. After all it is just a bunch of rules to follow and after changing employers you can quickly learn to deal with a new set of rules.

“Agile” - with uppercase A - can be a process. It can be working in iterations with all the ceremony before and after. It can be the XP flavor with things like TDD. Or something else that people have come up with. “agile” with lowercase A - is - just by looking at the word itself - an attribute.

“Being agile” is different from “doing Agile”.

By being agile I am able to react to change easily without loosing my balance. I can do this because I have solid grounding due to my experience in my profession. I have my preferences for how I do things and what I use to perform my work based on experience. I want to know for whom I do something because I want to tailor what I do towards that person. My agile mindset defines who I am, what I do and how I do it.

This article has been posted to social media sites. There might be comments. Just follow the links: