My thoughts about… The office clean sweep


I was with an client a while ago. A company that is more than 50 years old and who used to be 100% Management 1.0. However, they are in the process of trying to change the company–make it a Management 3.0organization and apply new things such as patterns from Sociocracy 3.0. Sometimes with good results, and sometimes with no results. It will take time, but the people who are driving the change are aware that you can’ t change the culture of an organization with a history of more than 50 years in just a few years.

When I visited the client, they were discussing the sweep-through-the-office-event scheduled by Facility Management. I hear you thinking: “A sweep-through-the-office-event…?” Everyone understands an office needs to be safe–you should not block emergency exits, or have your household appliances installed that you got from your grandmother 73 years ago. 

However, a clean desk policy? Does this mean you’re only allowed to put up posters and other expressions of communications at designated areas? Of course, everyone was pretty upset by this announcement. In the end, it was as bad as expected. Yes, they cleared posters off some walls, but thank god not all sticky notes were removed.

However, it made me think about what this says about an organization. As Einstein already said: “If a cluttered desk is a sign of a cluttered mind, of what, then, is an empty desk a sign?” We offer an Agile Talent workshop to have people working with people (often called HR) experience HR. Should we create an Agile Facility Management workshop?

I believe co-workers should be allowed to personalize desks and offices. They should be allowed to stick anything they want to a wall, and even install a decent coffee machine in some organizations. It is not just the core organization who needs to change into a new way of thinking and working, but also all support departments.

Delegation Board 2.0

One of the popular practices of Management 3.0 is the use of Delegation Boards. In a delegation board, you describe which delegation level is applicable for a key decision area (KDA). You can find more information on delegation boards on this page. This blog post is not about explaining the theoretical practice, this blog post examines why at a certain moment, delegation levels just won’t work anymore!

Let me quickly refresh your memory, a delegation board makes use of the seven levels of delegation. These seven levels are:

  1. Tell, the manager decides.
  2. Sell, the manager decides and tries to sell their decision to the team.
  3. Consult, the manager asks input from the team before the manager makes the decision.
  4. Agree, the manager and team agree together on the decision.
  5. Advice, the team asks input from the manager before they make the decision.
  6. Inquire, the team makes the decision, and try to sell this decision to the manager.
  7. Delegate, the team makes the decision. If necessary they will inform the manager.

I always explain to people that a delegation board is something between control givers and control takers. In most organizations, control givers are the leads, managers, etc. and the control takers are the teams or individuals. The more traditional description could also be managers and staff.

We, Happy Melly One, practice what we preach. One of the brands we support is Management 3.0. To do this, we make use of our own delegation board. In the past, when Jurgen Appelo was part of the team, his job title was Emperor-God-Overlord. No need to say who the control giver was ;). We had one delegation board, life was simple. For example, “Company Purpose” was at delegation level 1, Tell, Jurgen was the person who would decide on this and tell it to the team.

When Jurgen decided to focus on new projects, such as Mind Settlers and his new book, we had to reorganize ourselves as a team. The team selected me to become the new CEO, and to me, the title CEO is the abbreviation for Chief Empowering Officer. I believe in teams where everyone is responsible for management, not just one person.

Earlier this year we had a retreat in Dublin. One of the to-do items was setting up a new delegation board. We reviewed the old board, removed some key decision areas and added some new ones. So the natural next step was to play the delegation poker game to gain insight into everyone’s ideas about the right delegation level per KDA.

The first KDA was Signing contracts. What kind of delegation level should we apply? That will be 1, 2 or 3 I said. This was because as a CEO, I am the only person registered at the Chamber of Commerce, and therefore the only person who is legally allowed to sign contracts. We agreed it should be a 3. I will consult the team and in the end, make the decision.

The second KDA was Spending money (>= 500 euro). We all selected our preferred delegation poker card and played it. Different cards were played: 3 – Consult, 4 – Agree and 6 – Inquire. We discussed the reasons for people proposing different levels. At one moment someone said, Ralph should be involved in the decision. “Stop,” I said, “Why me? I am not the manager in this team, I am not the control giver. We all are.” However, in this case, who actually is the control giver? Who is making the decisions in the first three delegation levels if you are not the manager? “I don’t see the need for me to be the manager, so not me,” I said. We agreed after some discussion, it should be the team.

So, the control giver was the whole team, however, the control taker also was the whole team. Hey, now, but, ehh, that is weird! How can the team empower the team? How can you empower yourself? Should it be a team member? Is the control giver the team and the control taker is a team member? Well yes, that would work, we all agreed.

With level 1, the team would decide and inform the team members. Eh? That is also weird… How can we as a team decide on something together and then inform single team members about that decision? And what about level 3? in our case, we would consult the team (that is everyone) and in the next step make the decision as a team (that is again everyone). OMG, it’s complicated!

The delegation levels didn’t work as well for us is what we then decided. It was time for a coffee break. This was giving us headaches.

Coffee always helps. We took a step back and first discussed the different delegation levels. We decided to remove a few of them and to redefine the description of the ones that were left. We ended up with the following levels and descriptions:

  1. Tell – Everyone on the team has to fully agree. In other words consensus.
  2. Agree – If there are no objections from anyone, it is OK. Consent decision making.
  3. Advice – Team member has to ask advice from other team members.
  4. Inquire – Team member has to inform other team members about the outcome.
  5. Delegate – Team member has full delegation and can decide on their own.

Why did we use the description Tell for the first level and not Everyone or Full Team? Simple, we don’t have delegation cards that say “Team Has To Agree” :).

With this new level description and also fewer levels, we played the game again. It worked! We ended up with the following delegation board:

As you see, we still have some open KDA’s and questions and being an organization with co-owners, that also creates some interesting cases on the delegation board. However, after coming up with this, we decided it was time to celebrate! Not all problems need to be solved in one day.

Have you encountered a situation like this? How did you resolve it? We would love to hear your experiences.

Certifications are great! Certifications are totally not BS!

Many, many, many years ago, I did a two-day workshop ISTQB Foundation. At the end of the two days, there was an exam: 30 multiple-choice questions about software testing. I passed the exam and I got the Foundation Certificate in Software Testing. Did this make me a great software tester? No way. It merely meant that I answered a set of questions correctly, in a specific place, somewhere in time. Was it a waste of money and time? No, definitely not.

We attended the workshop with several software testers and it gave us some great ideas on how to implement testing within an Agile context. Hey, we are talking 2005 here! There were no books yet about testing and Scrum. By doing the workshop, we created a common view on testing and it allowed us to use a common language. One of our testers did not pass the exam. On a side note, within four months that person left the team. Trust me, the exam was not that hard.

This certification was really about verifying basic knowledge. If you were not able to pass this exam, something was wrong. It could be dyslexia, but also a lack of knowledge regarding software testing. It was also about creating a common language: all testers understanding what a Risk Matrix is, and what equivalence partitioning is. It also created a mindset that testers should also develop themselves by doing training, reading books, etc.

I did a follow-up training then: ISTQB Practitioner. The training was eight full days in total and there was again a possibility to get a certification. The certification exam lasted for three hours and consisted of a number of open questions. Just five or seven open questions as I recall. I did the exam and manually wrote 15 pages or so just to answer these questions! No laptop, 15 pages of me and my pencil. It took a month or so before all exams were reviewed and we got the result. I passed the exam and got my Practitioner Certificate in Software Testing. I valued this certificate so much more. Passing this exam really did mean something. I believe only 70% of the attendees passed the exam. By passing the exam, you showed you were able to come up with solutions for complex testing problems, test strategies, test techniques, etc. Still, it did not guarantee for 100% that you were a great tester, but it had much more value for me than the first certificate. For example, when I had to recruit software testers, every software tester who had the ISTQB Practitioner certification was automatically invited for the first interview. I knew those software testers had a passion for software testing, were willing to invest in growing their skills, and definitely had a sound knowledge about testing.

I believe certificates are great as long as you give them the right value. A certificate with multiple choice questions that you can answer without much knowledge does show that you are willing to invest in your skills. If you pass the exam, it shows you have some basic knowledge about a topic. You can talk about the topic with somebody else, you have a common language. Nothing wrong with that. However, it doesn’t prove you can do the job!

A certificate with open questions, where you have to show the experience you possess, has a different value for me. It shows again that you are willing to invest in yourself, and often more than the average professional. It also often shows that you really applied the framework or techniques and that you were able to reflect on the outcome of your actions. Still, of course, no 100% prove you can do the job and of course it also depends on the questions.

What do you think? Certifications BS or not? Should we forget about Certifications? Just use badges linked to experiences?

Experience report: Team Competence matrix

If you are interested in experience reports of Management 3.0 practices, you probably already read a lot about Kudo Cards, Moving Motivators and Delegation Poker. I also shared my experiences with those practices.

In this experience report, I would like to share my experiences with the Team Competence Matrix. Jurgen Appelo does not describe it in one of his books. The Team Competence Matrix (TCM) is an “official” Management 3.0 practice and was developed by Christof Braun.

The TCM is a perfect tool to give a team, or organization insight into the skills they have, and/or need. You can use the practice when you talk about competence development in general, but also when you ask teams to completely organize and set them up themselves. Self-organization is not just a blank page to do whatever you want. TCM can help you as an organization to give team members some constraints and guidelines on how to organize themselves.

It can give you insight as a team, what are your strengths and weaknesses. If you set up a workshop where teams are going to organize themselves, you can use it as guidelines. You can describe upfront which skills you need in the teams, and people can use the TCM as a tool to check if the teams are set up correctly.

In the end, it should be a conversation starter!

Before I dive into the TCM itself, let me provide extra information. I am going to explain skills and skill levels.

Skills and Skill levels

To set up a TCM, you first need to make an overview of the skills you need for a project. So, let’s assume we are going to set up a TCM for a project that will last a long time. What kind of skills do you need? Technical skills, depending on your domain it could be how SEO works, or how to make a cup of coffee, or how to develop a microservice. Besides technical skills, you probably also need soft skills. How important is it to communicate with stakeholders, customers, and other teams? Another competence area could be subject matter expertise. Do you need to have in-depth knowledge of taxes, coffee, financial systems, etc? The discussion to decide which skills you need can already be very valuable in my experience. By choosing on the skills, all assumptions are on the table and discussed. How many skills should you define for your project? I don’t know… but 100 sounds like a bit too much, doesn’t it?  I would say, keep it to a maximum of 15 skills and otherwise split the TCM into a TCM for soft skills and another TCM for technical skills.

After identifying the competence areas, you need to agree on the skill levels. What kind of levels are you going to use to indicate which level someone has in a certain competence area? Here are different models you can use.

The first one is the Shu-Ha-Ri model. Martin Fowler wrote a short blog post about it. In short, there are three levels of knowledge:

  • Shu: In this beginning stage, the student follows the teachings of one master precisely.
  • Ha: At this point, the student begins to branch out.
  • Ri: Now the student isn’t learning from other people but from his own practice.

A second model is the one that Christof Braun describes in his practice and they are called: Apprentice, Journeyman, and Master. Based on the guild system of Western Europe in the medieval times.

A third option is to use something like:

  • Expert: I can teach it.
  • Practitioner: I can do it.
  • Novice: What is it?

Also, assign colors to the different levels. Be careful which colors. You could use red, orange and green. However, in my experience, people don’t like red. Red is negative. Maybe use colors like blue, yellow and pink. Think about it at least.

You get the point. Now, why not ten levels, or perhaps even sublevels? Well, keep it simple, In the end, it is all about the discussion and creating awareness. Introducing ten knowledge levels doesn’t help. The focus will be on determining the specific levels, instead of the actual interaction.

The Grid

The first step to create a TCM is to draw a grid. A row for every skill, and a top row for the names of your team members. Then add a column for every team member plus two extra columns. In the first column, you write down the skills. The second column is very important, it will contain the skill requirements you need.

As an example, you are setting up a team for promoting your new product. One of the important skills is SEO. You will need to think about how many experts (or Ri) people you need, how many practitioners (or Ha) and how many novices (Shu) people you need. We assume everyone is automatically a novice. If you really disagree with this starting point, and you believe there is also a difference between a novice and somebody having no knowledge, you could simply introduce one more level, something called noob or such. You just place a symbol for every skill level you defined and write down the number of people you would like to have at that skill level.

It could be that a specific skill is so important, that all team members require that skill at expert level. In that case, just write down the number of team members possessing the expert level after the green dot. Maybe you just need one expert, and the skill level of other people doesn’t matter. In that case, just write a 1 behind the green dot. Maybe you just need two novices and one practitioner. In that case, place the number 2 after the yellow dot and a 1 behind the orange dot. The total number of skills required doesn’t have to be equal to the number of team members. If you just need one master, that is OK. In that case, the skill level of the other team members doesn’t matter. Note that there are some interesting things you need to think about. For example, do you need to have back up for a skill? If so, what kind of skill level should the backup person possess? Do you really need 5 masters of a certain skill?

Dare to be honest?

The last and most interesting step is to completely fill in the TCM with the team. The first column specifies the skills, the second column specifies the required levels, and the other columns will represent your team members. The last step is that every team member fills in their skill level for a required skill. Basically, you are asking every team member to judge their skill level and make it explicit. Interesting right? Assuming you have a driving license, are you willing to state that you are a good driver? I think no one will say she or he is a bad driver. Still, when I commute by car, I always encounter some pretty terrible car drivers. How is this possible?

I believe that if you have a company culture where people feel safe, to be honest, failure is not an issue. People will honestly fill in the matrix. I often add one “rule” though. You need to ask feedback from five other people. What do those people think about your skill levels? Basically, I ask my team members to convince/prove to me that they filled in the TCM correctly. I already used the TCM several times, and I will probably make one change next time. I will add one super expert level and one super novice level. The reason is simple. If you are a novice for a certain skill, you need to select the lowest level. Some people feel a bit uncomfortable doing that, so they naturally go for the mid-level. The expert level maybe is considered a bit arrogant by some so for some skills, people will again choose the mid-level. Therefore, I want to try my next TCM with five levels, where I consider the lowest and highest level just as buffers. Management 3.0 is all about experimenting, just try things out and learn.

When all your team members have filled in the TCM, collected feedback, maybe made some changes, we are ready to analyze the TCM.

Talking about the Matrix

It is very simple, and that is what makes the TCM so powerful in my opinion. The second column contains the skills you need. Just count the number of skills people filled in. If you need one master, but there are just seven practitioners, you have a problem. If you just need one master, and you have seven masters, you could have also a problem. Maybe another team could use one or two masters from your team. However, you will also need to check the other skills in that case.

If you have a skill gap, you need to solve it, or not. You can solve it by helping team members to develop their skills, or by maybe hiring consultants, there are many solutions possible. However, there is one thing you need to take in consideration. If you need some skills and they are not on the team, you also need to ask your team members if they want to develop that skill. If, for example, you need a Cobol master in your team that only consists of millennial developers, you have a problem. I have the feeling already that there will be no team members who would like to develop their Cobol skills.

Did you use a Team Competence Matrix already? If so, what did you lean?

Grow a Growth Mindset Organization

It is no surprise, but everything is changing faster and faster nowadays. In a report by McKinsey, the authors talk about there being four disruptions impacting the global economy, and one of them is the accelerating technological change.

I did a lot of recruitment interviews in my career and one of my favorite questions during a recruitment interview is: “How do you keep your knowledge up to date?”

Taking into account that everything is changing ever more rapidly and that you need to keep up to date with the relevant developments in your profession, learning is mandatory. Keep developing your skills is mandatory, but what if you believe that you can’t keep developing your skills? What if you believe that what you can learn is limited?

First, let’s take a look at some theory. Professor Carol Dweck did research about development. According to Dweck, individuals can be placed on a continuum according to their implicit views of where ability comes from. Some believe their success is based on innate ability: these people are said to have a “fixed” theory of intelligence (fixed mindset). Others, who believe their success is based on hard work, learning, training, and doggedness are said to have a “growth” or an “incremental” theory of intelligence (growth mindset). [source wikipedia]

As always, it depends on many factors what your belief will be. Do you believe you have a fixed mindset or a growth mindset? I think everyone will say they have a growth mindset.

It is the same with Theory X and Theory Y. Are you an X Person? Nobody is an X person. Still, organizations treat their employees like they are X people. Treating people like X people implies you don’t trust them, believe they are only motivated by money, etc. I believe if you don’t trust your team members, you can’t trust them. It will become a self-fulfilling prophecy. What if the same could happen with learning?

What if an organization believes that most of their people have a fixed mindset? Maybe they will not say it out loud or do it on purpose, but what if they treat their workforce as if they have a fixed mindset. If so, why would they invest in personal development more than needed? Why would they organize exploration days? Why would they give team members time off for personal development?

Organizations who believe in a fixed mindset also don’t appreciate failures. They don’t believe a failure is a learning opportunity. It is a sign you don’t have the knowledge, it is a failure.

Let’s look at the growth mindset organization. What if an organization believes people have a growth mindset? Managers will stimulate people to learn, and employees want to grow themselves. Exploration Days are organized and people join because they like to learn and explore new stuff. The organization is not afraid of mistakes: nobody is perfect and mistakes are an opportunity to learn. People celebrate learning!

Dweck believes that the growth mindset will allow a person to live a less stressful and more successful life. One of the 12 Steps of Happiness is also an experiment, and experimenting is equal to learning.

You can help people to develop a growth mindset. You can work to give your organization a growth mindset.

It is about providing feedback on their work and on the effort people put in a task. If you just focus on the result, tell them they are great, smart, etc. they will feel complimented for the knowledge they currently have. If you compliment people for the hard work, learning, and effort, you compliment them on the actual learning and development. You can also challenge people, not with assignments that are impossible but with assignments just outside their comfort zone. Help them, or provide help, to have them bridge the gap between being in their comfort zone and realizing the assignment. By doing this, these people will develop a growth mindset, step by step.

A growth mindset is not there because you just put a lot of effort into learning. It is also about how you learn: achieve something, talk about it, see where you have a further knowledge gap, and then make the next step.

Sounds almost like being Agile, right?

(This article first appeared on LinkedIn.)