Leading Change: A Story of Organisational Culture, Reward and Reprimand

Leading Change: A Story of Organisational Culture, Reward and Reprimand

This is a story from an organisation which I hated working for, but stayed for a couple of years because my then manager was a kind person and we both disliked the place equally. We were also comfortable with each other in talking about the incompetent people, who made the majority of that place and the organisational culture.

 

This place was a model organisation for all the wrong reasons. There were trust issues, toxicity, bad culture, nepotism, questionable management competence, lack of integrity, lack of empathy for employees as well as for customers among many other dysfunctions.

 

In simple words, it was a clusterfcuk. (A friend suggested that I replace it with “omnishambles”, which sounds more posh and sophisticated. Nah! doing so would dilute the effectiveness of this post. And more importantly, if I do use that fancy word, I will not be happy.)

 

Leading to win (that’s what I thought):  

At one point of time at that place, I was leading a digital transformation team. Even though the whole thing was completely screwed up, and the consultants were screwing it up even more, I am thankful for all the lessons I learned there. Plus, the bonus was that I got all the stories to share like this one.

 

The people in my team were part of the same system. Some of them were new, and  some had fused the organisation’s DNA with theirs. The environment was so bad, that all new people got influenced within weeks and became political quickly. If you don’t know how cults work, you can get an idea here.

 

Anyway, long story short. I was in the role for just a couple of months before I went for my planned leaves for about three weeks. The team was delivering the outcomes and I was doing my best to enable the achievements of those goals. I was coaching them, mentoring them and at times, holding hands to get work done.

 

Look, the problem with being too focused on your objectives is that sometimes you fail to read the room. People can be two faced and if you don’t realise that soon enough, they will do good enough damage. 

 

Airlines teach pilots situational awareness. Which is about being aware of one’s surroundings, and not just rely on the instrument. Not being situationally aware can cause trouble and that was the mistake I made too. I should have been more diligent in keeping an eye on environmental factors. It is like product companies keeping an eye out on subtle feedback coming out on Twitter and fixing problems before they become issues.  

 

Anyway, back to the story of the screwed up project and place.

 

Hoping for a reward:

 

When I returned from the leave and joined the work back, the CTO called me in his cabin.

 

The CTO was a nice person, but he wasn’t a charismatic leader and he lacked conviction (I was going to say ‘he lacked balls’, but that wouldn’t be nice, right?). His demeanor was of a person who is trying hard to stay in his job and not ruffle any feathers. But you know what, an appease-all policy makes your position weaker. In my opinion, stronger and assertive people command more respect and have better chances of staying or growing in their jobs than others.

 

So yeah, he called me for a quick meeting in his office.  

 

“Recognition time!”, I thought. 

 

Yes, you guessed it right. I was not going to get recognition. I was there for a reprimand. 

 

With a serious face, and a deep tone, he said that the team told him that Rajesh was gone, and no one noticed. It seemed that I wasn’t making an impact. And that I did not have control on the team. In his opinion, the team should have been dependent on my leadership.

 

Honestly, I felt betrayed by the team. I treated them as friends, and they behaved like grade 3 kids who tell on you to the teacher. I also felt bad that the team couldn’t see the bigger picture. They had much more freedom than other teams. 

 

So, when I replied to the CTO, he was instantly remorseful. 

 

I said, “I am actually quite happy to hear what the team said to you.”

 

He looked confused, and said, “What do you mean?”

 

I continued, “It seems that I was able to achieve my goal much earlier than expected. If the team believes that they were able to function without having someone guiding and driving them, then they have become a self-contained, self-organised team. They have learned much more about delivering innovative products than anyone else in the entire group. I know that there are many other organisations and teams that try their best to achieve self-organisation and never reach there. We should celebrate that we are doing the right thing.”

 

There was a long pause.

 

Then the CTO said, “I should have thought that, and I should have said that to the team. You are right. Sorry that I didn’t manage it well.”

 

WHOA! I never expected that I would ever hear those words. While there was no formal recognition, at least he understood what I was trying to do.


Culture change is hard: 

You might be wondering what happened next. When I tell this story to people, some assume that there was a happy ending with rewards, awards, recognitions, and a case study of organisational improvement.

 

No, nothing of that sort happened. Culture problems often have deep roots and resolving them takes time, courage, integrity, congruence, openness and willingness by the leaders first. I think it all starts with accepting that there are problems.

 

In this case too, culture problems were deep rooted.

 

To me, it was clear that trust was an issue. It was broken.

 

I did have an open discussion with the team and we discussed having honesty meetings. Someday I will write about that too. 

 

Most of the team members understood what they had achieved and that I was there to help. Yet, some of them were not onboard. They were laggards. After leaving that organisation many years ago, I came to know that the laggards were still there where they were.

 

Not long after that incident, I left that organisation. I knew that I was a square peg in a round hole. 

 

One can only try to change a system. Most of the time you can only influence a small part of a system and there is a high likelihood that this small part will go back to its old ways due to other parts of the system. 

When you try to change a system, not all parts of the system will react the same way. But that doesn’t mean that we stop trying.

 

I tried, I succeeded a little, and then I failed.

 

Change takes time. Effect of change can take even longer. And recognition and reward will not always be part of the process.

 

As change agents, we must be patient while remaining pragmatic.

I shared the team’s mistakes with everyone, then this happened…

I shared the team’s mistakes with everyone, then this happened…

A few years ago, I led a product development effort at an enterprise. We were constantly experimenting, so had our fair share of wins and failures. But I had the feeling that we weren’t learning from mistakes quickly enough.

Large organisations maintain risk registers, which usually keep details of risks and issues. We also had a risk register, but it was being treated as one of those documents created for the sake of documentation.

Frustrated, I decided to put a poster on the wall with the title “Failure log”.

Why the heck a failure log?

The team reacted differently to the failure log. Some were amused, some confused, and some annoyed.

The annoyed ones saw this as exposing their weaknesses.

The confused ones didn’t know how showcasing our mistakes was going to help the project.

Others were happy that we were taking an initiative that could not only build psychological safety, but could also help us learn from our mistakes.

My challenge was that the organisation was not very mature. It was very much a command and control environment, so having the courage to publicly admit you’d made a mistake was a bold move, and to some extent a risk.

It was a risk because the board and the management team had invested heavily in the program and they were watching our progress very carefully. It was quite possible to face unintended consequences of making mistakes. In other words, it could have been a career-limiting – or perhaps even career-killing – move.

Luckily, the Chief Product Officer I worked with was progressively minded. He encouraged and supported experiments. Plus, the Program Director and I had become friends and she supported everything I did. Both could understand my vision and wanted to be part of it.

We were like a start-up within a traditionally managed enterprise.

Many of the team members, including the Product Leads and the Innovation Manager, were itching to do more and my bold step encouraged almost everyone to step up and forward.

I started adding smaller mistakes and things on that poster that could have been improved.

The Blunder!

And then one day… it happened!

A team member mistakenly sent a test email to hundreds of customers. It was a PR and Communications disaster.

You may be wondering why a test web page was connected with a production database?

The web page was built for a fake door experiment and the idea was to expose a very small number of customers to that page.

We got through that issue… but the question around recording that mistake on the Failure Log felt almost as tough.

The team was divided on sharing an embarrassing mistake with everyone else. Specifically in an environment where we were expected to have Gantt charts, detailed project plans, roadmaps, scripted test cases, and God knows what else.

So, what did we do about sharing the mistake?

After a bit of discussion within the team, we decided to include the mistake on the Failure Log because that was the right thing to do. There was a consensus about being congruent.

What happened after taking that major step?

I was sacked… right?

No. Nothing major happened at all. We were warned to be more diligent in future. That’s it. I thank my lucky stars for that.

Lessons that I learned:

But something did happen that was major for me:

  • The team became bolder
  • The experiments we quietly discussed earlier turned into open discussions
  • More items appeared on the Failure log, which by now had become the learning log
  • More and more visitors from other departments wanted to learn from us
  • And the best of all, the cohesion and collaboration among team members (as well as with the management team) improved

Taking a bold step, and then taking another courageous step on top of that, taught us many lessons and made us a great team. We delivered value to customers, and we were more open about our outcomes. Best of all, the tea cohesion improved.

I can’t ignore the fact that the senior folks I worked with made it easier for me to take bolder steps. If executives aren’t supportive, then forget about experimenting with new ideas.

The failure log was an experiment that could have gone in any direction. It could have become a political mess, or quietly died from lack of interest.

Users don’t know what they want, and we don’t know our users!

Users don’t know what they want, and we don’t know our users!

I was speaking with a friend yesterday who happens to be a senior leader in a big 4 bank in Australia. He told me that he recently rubbished a new feature that a group of tech and prod people brought to him for improving frontline staff’s work.

He wasn’t pleased that the group didn’t know what the staff on the frontline did. So, he asked them to spend a day in the bank’s branch and observe what the staff did.

The group returned with their observations and admitted that their idea was faulty.

It seems that product and tech teams don’t invest enough time and effort in learning what their users do, or how they perform their jobs.

Asking users what they want isn’t a good approach:

Don’t ask users what they want. Users don’t know what they want, so they ‘dictate’ what they desire.

You should have heard the quote attributed to Henry Ford where he says, “If I had asked them what they want, they would have said a faster horse!”

Horse cart users would have desired for faster and healthier horses, and more comfortable carts. 

So, Instead of asking users what they want and then jumping right on doing that, we should:

– ask them for their pain points
– get their insights and learn from those
– ‘explore’ rather than ‘gather’ requirements

So what do we do if not ask users?

It is true that often users are served features or products that aren’t useful for them. Possibly because people who build those products never find out how users do what they do. That’s another problem because of which we see so may rubbish products in the market.

A while ago, my doctor (GP) explained a similar situation to me. She was struggling to use the software that the health practice had recently bought from a software firm.

Her comment was, ”They built this software for doctors without understanding what doctors do and how they might use this software.” Fair enough!

Not engaging with potential customers or users is one of the biggest shortcomings of product development. An even bigger problem is not knowing what the users actually do.

Knowing what a user does provides deeper insights into their work. Those insights can significantly inform and influence the development work that the product teams undertake.

The Problem of Overthinking Problems

The Problem of Overthinking Problems

People inadvertently overthink problems.

I lead some large (MM$) initiatives with sizable teams. One thing that I’ve observed, and have been observing for a while which has been consistent is that people spend way too much time over-thinking problems and solutions. Why do they do that? You might have read about Occam’s (or Ockham’s) razor. This principle explains that there should not be more options than necessary. In simpler terms, things should not be blown out of proportion. Occam’s razor – Wikipedia

So why do people (and teams in organisations) overthink problems? Here are few things that I’ve noticed.
 
Ownership and Accountability: Sometimes teams don’t take ownership to avoid accountability. That is, they respond slow and hope someone else will take ownership. Sounds like culture issues, right?
 
Empowerment (or the lack of): Sometimes teams do not feel empowered and confident of the solutions they work on. Again, these are often culture issues. “Even if we find a solution, boss will do what they want. Let’s spend more time and provide multiple options.”
 
Deliberate delays on finding solutions: The thinking that goes on here is, ‘if we sit on a problem, it may go away’. We even observe this phenomena in our personal lives sometimes. Do you remember ignoring that annoying headache for days, which turned out to be the…?
 
Anxiety of the outcome: “Stakes are high and our reputation matters. Let’s think it through.” Anxiety can be a challenge, specifically in toxic environments. It certainly affects teams when stakes are high.
 
Psychological safety: “if we make a mistake, there can be consequences. So, let’s think carefully, and in detail so that we don’t get punished.” It’s indeed very important aspect of small problems taking longer to solve.
 
Culture matters: Good culture matters more. Leaders must strive to improve culture. Once people see that they enjoy personal freedom, they start taking responsibility of their own actions, and over-thinking of small problems drops.

What’s the solution for not overthinking problems?

Change your perception. Perception changes everything. A problem could be an opportunity.

 

The Incongruence of Organisational Hierarchy

The Incongruence of Organisational Hierarchy

The incongruence between facts and claims in many organisations often bothers me. One of the biggest bogus claims that I have seen is the lack of hierarchy or the flatness of an organisation. What that means is that organisations claim to have very little or no hierarchy in their organisational structure. Such claims make an organisation look modern, open and cool. The flatness of hierarchy (do you see the contradiction here?) is used as a marketing tool to attract talent. After all, who wouldn’t want to work for a company where management teams are approachable and where one doesn’t have to worry much about too many titles.

Sadly, more often than not, organisations that claim to not have hierarchical structures, have unwritten ones. Worse, some of these places have a command and control culturer where the top boss or someone else in the upper echelons control everything.

Few years ago I worked for a financial organisation that did not have many levels in their organisational structure. I was leading a digital project with a budget of few millions. What I found surprising was that the senior management team asked for so many details from projects that the monthly report was over 200 pages long. Did they read the report? I doubt that. Soon I figured out that the structure was less hierarchical because the bosses wanted to keep all the control and didn’t trust others enough to delegate. Unfortunately, that culture flowed down and made that organisation a typical command and control driven culture despite trying to be Agile in vain.

Are their any positives of a hierarchical structure?

One vendor that I can think of is that a hierarchy gives you a possibility of climbing the organisational ladder. It is easier for a company to move people one level up but adding a ‘Sr.’ to their titles. It doesn’t cost much and employees stay happy with yearly promotions. Result is that everyone stays happier.

What to do if you end up in such an organisation?

Well, it truly depends on your own circumstances. If you enjoy your work and the hierarchy does not impact you and your attitude, then you have no problem. What matters is whether you continue enjoying your work or not, and whether you have the right opportunities available for you.

However, if you feel claustrophobic in there, or if you want to climb the organisational ladder fast, then may be you need to consider other options. Again, that’s all circumstantial.