In one sentence: Things don’t tumble down or get stuck when he’s not around.

Everything a leader does will be connected to a meaning.
Before giving meaning, our interpretation takes place. Interpretation is not exact or objective, it’s very personal.
Interpretation is heavily influenced by your experience and your belief system … and we all have different ones.
So sometimes, we miss the right meaning if we are pushed into a situation where we need to interpret. In other words, we guess.

How to push people into interpretation?

Communicate vaguely. Follow political correctness. Try not to step on anyone’s toes. Hide your feelings.
An example: Let’s pick the sentence “How do I recognize a good CEO?”. Is this a clear question?
No, the meaning is vague! *Good for what or whom*? Maybe *when* do we need a good one; always, only in the morning? *Why* is this even relevant? *What* are the *problems* a good CEO would solve?
A good answer to *Good for whom* would be: “for the whole organization”. That’s the responsibility of the CEO; taking care of the whole system and ensuring the required interaction can happen.

Do you have children? It’s not about being an adult, it’s about what we wish for our children in 20-30 years.
Let’s separate *constraints* from *things* *under* their *control*. We want children who think and act for themselves. That’s the key to happiness.
Your general conditions (Rahmenbedingungen) or your social environment are absolutely irrelevant. To prove this, take a look at Victor Frankl’s story: In an inhuman environment, he was able to save his own will and thoughts against all odds. He became unbreakable.

Especially as CEO, everything you say and do is interpreted and takes on meaning. Even if the CEO is not there, he communicates, because the employees might ask themselves: “Is he not there because we/our things are not important? Or because he’s not interested in us or doesn’t care about us?
And if you ask him “Hey, we noticed you weren’t there. Is everything okay?”, you might get a completely understandable answer that has nothing to do with the negative, abstruse assumptions before. E.g. “I wanted to give you the stage so that everyone knows it’s your success and not mine.”
As soon as you speak to each other, replace the invented meaning with your intended meaning.
A simple trick to debunk invented meanings. Ask yourself, “Can I really know that?”

The “good” CEO

Bonuses are often negotiated once or twice a year. In between operational circumstances arise urgent other topics that would benefit from early treatment before they grow.
Imagine a manager who has a bonus on “A”. What will his priorities be? Finish “A” to get the bonus or set the bonus to risk and take care of the urgent topic?

The bonus negotiation is trapped by the assumption, that nothing strategically more important will occur in between. Another proof of our inability is to foresee the future.
Instead, we really need to stay flexible or if you call it “agile”. Yes, most of us are in a VUKA environment.

Bonuses might have a positive impact on tactical planning (in the very near future), but a really bad one on strategic issues that arise.

Timeboxes limit the amount of time spent in order to keep focus. It is okay not to finish the time-boxed task.
A sprint is a timebox of mostly 2 weeks. Is it okay not to finish the underlying work?

Happy discussions!

Recently, I coached a colleague who was attempting to transition to another position. Unfortunately, his current project manager cannot afford to lose him, making it challenging to say “Yes” to his request.

The coaching session concluded with a role-play where I emphasized several crucial points:

• In a hierarchical system, communication from top to bottom is a directive, while from bottom to top, it’s a request for assistance.
• The sequence in which you present information to your boss holds significant importance.
• Instead of seeking a “final” decision or solution, encourage a brainstorming session to explore theoretical ideas that could address the problem with your boss.

Concerning the order, it’s vital to begin by expressing your feelings about the project, the company, and possibly your current life situation. Establish a connection that conveys the importance of meaningful work to you and how it benefits the company. Conclude by discussing when you and your boss will collaboratively explore (creative) solutions to the issues at hand.

Recently, a customer asked if I would reduce my hourly rate after six months of working with them on an organizational transformation. What struck me was that there was no specific reason given for this request.

At first, I was uncertain about how to respond. I knew what I didn’t want to do: justify why my work was worth the pricing.

My assumption was that the customer wanted to save some money, which seemed unrelated to the quality of the work I had done thus far.

This made me consider the message it would send if I lowered my rate. Wouldn’t it affect my credibility? If I reduced, it by 10% it’s still insignificant peanuts. Furthermore, a larger reduction might lead clients to think, “That was easy – I asked, and he dropped the prices by 30%. Was he overcharging me before?” I firmly believe that my work is worth the price I charge, and it aligns with market standards. Additionally, considering the savings generated through increased productivity and lean methodologies, the value I provide equates to a return of “spend a dollar on me, and you get between 5-8 dollars back.” However, proving this quantitatively is challenging.

Based on my assumptions, I believed the customer was satisfied with my work, and the request was primarily about saving costs. They likely realized that transformative changes take time, and my expertise was indispensable for a more extended period than initially anticipated.

I had prepared the following dialogue in my mind (C = customer, Me = me):

C: Did you reconsider your hourly rate?
Me: Yes, I did. But before we proceed, could you share your intentions? Is it solely about cost-saving?
C: Yes.
Me: Alright, what if I propose a more effective way to save money, one that goes beyond just reducing my rate?
C: I’m listening. Go on!
Me: The most significant impact on savings lies in the pace of your company’s adaptation. I would be doing a disservice as a consultant if I signaled that it’s acceptable to slow down by lowering my rate. Imagine if my work could save 50 employees approximately 2 days a month (and considering your company’s size, this is a conservative estimate). We both understand the concept of investment: you spend a dollar, and if you get more than a dollar in return, it’s a wise investment, isn’t it?
I am just as invested in the success of this transformation as you are. Let’s focus on addressing the factors that hinder our progress. If you aim to move on from my services as quickly as possible, it signifies that I’ve done my job effectively.

The day came and I did exactly as described. The negotiation concluded at this point. My customer understood that the power to save money was in their hands, and my hourly rate was not the focal point. I was relieved that the customer grasped this perspective. Moreover, I was glad that I didn’t have to justify or defend my work, as I might have done in the past. … and of course, I kept my rate.

An experiment: Go to your backlog, and scan all User Stories by title. Ask yourself: “Is this a problem statement or already a proposed solution?”

When I did this with one of my customers, the stunning answer was:
Not a single problem statement from the user existed in the backlog (the backlog had around 150 items which is a problem on its own).

Even if the description would contain the problem statement from the customer, why are we hiding this? Just reading the solution in the title will influence the developers and stops them from thinking on their own.

This has several impacts, I believe no one wants to have:

• Slicing into tinier pieces is way harder as you are faced with a solution. How can you slice a solution?
• People are conditioned to just execute the proposed solution

Both issues will not lead to teams feeling responsible for the created solutions.

One real-life example (and there are many more):

The PO pushed hard that the team should do a specific story and ship it within 10 days. The story didn’t contain the customer’s problem at all, only a solution. The team started to complain because it was nearly impossible to finish it on time. And yes, there was a deadline.

So I started to ask:

ME: What is the customer’s need or what did the customer tell you is his problem?
PO: Oh, he just wants to see what the redesign of the UI looks like.
ME: Would a screenshot or mockup be sufficient?
PO: No, the customer wants to see how to interact with the UI.
ME: Does he want to click by himself or would a recording from a devs screen be sufficient?
PO: A recording would be ok.
THE TEAM: Ok, you can have the recording within the next 3 hours.

So instead of putting a whole team into tears by letting them do a nearly impossible thing on time, one dev made tiny UI changes, and recorded how he clicked through it – boom, done!
The trouble for the team was making it work behind the scenes, the UI part was actually very easy.
The customer and PO were happy: Instead of waiting 10 days, it was now 3 hours.

I sometimes fall into this trap, but I’m getting better:

A problem is being described to you and without asking much your head already starts producing possible solutions. Sometimes so fast, that you don’t even listen till the other person finished the problem statement.

As professionals, we need to remind ourselves that small details can change the big picture. The balance between having an overview of the problem and identifying critical details requires listening and questions. We can’t do our job properly if we try to skip this.

People I’d call “hackers”, rush into a solution without asking or verifying their assumptions. In the mid and long run, preventable failures will happen. There really is no excuse for working like that. Instead, listen and ask.