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.
A little while ago, the team coach at one of my clients suggested that we collect feedback from the team anonymously to understand the ‘team health’. My opinion has been that you can explore and understand a team’s health by frequently talking and working with them. So, I wasn’t really in favour of gathering data anonymously, but since I had started working at that place only a few days ago, I asked for more information.
Turned out, the team coach, who was a nice person and was quite experienced, was actually not in favour of collecting anonymous feedback either. However, the inexperienced manager of that group truly believed that feedback should be collected that way and therefore commanded the coach to follow the process.
I believe that most of us don’t like receiving anonymous feedback. To validate my assumption, I spoke to a number of people. However, I wasn’t entirely surprised when many of them told me that they didn’t mind providing it when asked. Some even admitted that they have exaggerated while giving feedback anonymously. Giving and receiving feedback can be daunting, however, it can be worse coming from an unknown source.
My experience is that managers who have a command and control mindset do not like transparency, conflict or challenge. They see that as confrontation and try to avoid that.
How people engage with each other, and how managers and team members give or receive feedback often tells a lot about an organisation’s culture. Correct?
I can see that you are nodding your head, most likely in agreement. Well, if you trust me enough then tell me about it.
Let’s try to analyse the feedback given in an unidentified and unspecified manner. An easier way to analyse that is break it down.
- Is anonymous feedback good or bad
- What happens when people are allowed to give feedback anonymously
- How do we feel when we receive anonymous feedback
- Criticism or critique
- What does good look like
Is anonymous feedback good or bad
The debate about anonymous versus face to face feedback isn’t new. In my work as a coach, consultant and sometimes as a manager, I have come across scenarios where leaders were looking for, and at times, encouraging, anonymous feedback. Their logic or assumptions often were similar. “People feel confident providing anonymous feedback and we learn what our teams actually think about the organisation or the processes or the management or all of these.”
Nonsense!! If the culture of a place isn’t conducive to openness, people will not tell the truth even in an anonymous survey.
If people in a team find it hard to offer direct honest feedback, then it is clear that the group has trust issues. Because if I trust you enough, then I’d feel confident that you would listen, pay heed and won’t mind about my feedback.
So, in general, it seems that anonymous feedback isn’t a good thing.
What happens when you are allowed to give anonymous feedback?
How people respond to a request for feedback largely depends on how they feel in the setting in which they are. We respond and react passively or negatively in an environment that makes us feel unsafe. That’s why the ‘feeling of safety’ matters a lot. When employees feel safe to challenge the management, they inadvertently also save their employers from a lot of trouble. When they don’t feel safe, they won’t bother telling the management that the organisation was on fire, and in some cases, literally.
In a blame culture, while some people give up hope that the management would take any actions on their suggestions; few others find the request for anonymous feedback a great opportunity to vent their frustrations. They may exaggerate situations, they may skew data by giving the lowest score for everything and they may even lie if they feel vengeful. And why wouldn’t they? Anonymity provides them the veil to do things that they wouldn’t otherwise do.
Receiving anonymous feedback:
Here is a scenario that you will possibly recognize.
“Hi, we need to talk”:
Your manager comes to you and says,”I have received some feedback about you from some of the team members. They think that your quality of work is poor, you delay their work by not responding on time and you arrive to work late. I’ll have to take some action if you don’t improve.”
Naturally, you are taken aback because you thought you had cordial and honest relationships with your colleagues. You considered them your friends and you always assumed that they would approach you for any concern they had about your work. Anyways, you always believed that you produced high quality work. You have been praised for your work by the clients and this feedback did not seem to make any sense.
So, you ask,”who has given that feedback?”
Manager says, “All feedback that we receive is anonymous. We don’t want people to feel exposed or unsafe for providing information or feedback. And we also don’t want people who receive feedback to be vengeful.”
“That’s a load of bollocks!”, You feel like saying to your boss, but decide to keep this thought in the mind and don’t actually utter it. Times are tough and saying that could be a career limiting move.
Instead you mutter, “I understand that, but without knowing exactly what the issue is, I can’t accept or even take action on this feedback. Actually, I think all of that feedback is incorrect. If you tell me who’s provided this feedback then I will work with them to fix things.”
Of course you never get that information.
The problem in the above scenario is that you don’t have any specific information. The feedback was vague, you didn’t know who provided that. You also don’t know whether your boss misunderstood what your colleagues said about you or whether they all were truly two-faced people. If you have a weak manager, then the first thing that comes to your mind is whether your boss was making up all that feedback.
Whatever the case maybe, now you have a dislike and distrust of almost all your team members and also your boss. The damage has been done.
Criticism vs critique:
Criticism is always an attack on someone’s person. When you give critical feedback, you’re talking about that person and how bad they are. However, when you critique, you talk about an attribute of a person, and not the person.
Brene Brown says this about anonymous feedback:
“If you’re not in the arena also getting your ass kicked, I’m not interested in your feedback.”
What does good look like?
The good looks like working in a culture where people feel safe speaking out, respect is a common behaviour, the management folks are open and honest in accepting mistakes and failures and actively ensure that their teams do the same by encouraging them.
I worked with few such teams (I have yet to see an ideal organisation) where people openly expressed their opinions and views. The leaders there created a culture where we felt safe to debate and challenge in an honest, healthy and respectful way.
In an environment like this, team members as well as managers can offer genuine and meaningful feedback in a supportive way. There you talk like mature people. And that not only helps the individuals to grow, but also helps their teams and organisations to stay on course. These cultures also encourage frequent and just in time feedback instead of waiting for a quarter of a year to deliver bad news.
Building trust, enhancing collaboration and establishing relationships is hard enough when teams work together in a physical office. Things become more challenging when teams are distributed. This issue doesn’t sound too challenging when one team is co-located and works with other teams that are at different locations or different time zones. Actually, ever since offshoring and outsourcing became mainstream, we have learned to live with the distributed nature of work.
When do we collaborate?
We collaborate with others to achieve something of common interest. For example, entrepreneurs may collaborate to build and launch a new product. In corporate settings, different teams collaborate to build products and to deliver valuable outcomes for their customers.
Collaboration is successful when the level of trust is high among the people who work together.
However, the question remains.
How do we build and enhance collaboration and trusted relationships among team members?
There are hundreds of methods that help us do so. But we’re not going to list all of them here. Google is good for that sort of stuff. In this post, I’ll tell you what has worked for me and then you can tell me what has worked for you. Hence, don’t forget to add comments below.
When it comes to collaboration, the current pandemic has made the situation even more challenging. How? Now not just the teams, but every single person of a team is located remotely. That brings a different dynamic to the equation when we talk about collaboration and teamwork.
I’m going to share two techniques that I’ve found useful.
The first one is personal mapping.
Enhancing collaboration using personal mapping:
When team members know more about each other than just the work stuff, the bonding improves. It mostly happens that when we sit in the vicinity of others, communication begins. The generic, “hey, how was your weekend?” often becomes the icebreaker and increases the flow of communication. And it appears to me that this improved relationship also helps us deliver better outcomes. This might just be human nature. When our ancestors worked together, they survived and grew.
Personal mapping technique is a simple mind mapping exercise where you tell your story through visualisation. Here’s my personal map.
How to get your team’s started with personal mapping:
A good place to start is to use the technique as an icebreaker before workshops. Or, do it when New team members join.
I often start with asking team members what they knew about me. One they respond, I share my personal map with them. I normally include details of education, work, hobbies, family, goals and values etc. The idea is to keep the session interesting. This often helps in making team members feel safe, relaxed and engaged.
After sharing my personal map, I encourage team members to pair with someone who they don’t know much about.
Team members talking of their colleague’s personal map:
When team members know that they will be introducing their colleague to others, they listen intently and they try to understand them better.
How to do it remotely
Easy. If you’ve created your map on your computer and if you’re using a solution liked Google Meet, Microsoft teams or Zoom, you can share your screen. If you’ve created your map on paper, you can show it on camera.
Drawbacks of personal mapping:
My observation is that introverts can find this exercise a bit awkward. Some team members also do not want to share information about themselves for personal reasons. Each person is different and it’s better to familiarise the team with this exercise beforehand and find out whether it might make someone feel uncomfortable. You can work with them to adjust the exercise for them and make them feel safe for participation.
Using collaboration game Quinks for team bonding
I came across this interactive game when one of my friends invited me to join a free session with the game’s inventor, Viren.
The game is available online as well as a physical set and that makes it easier to either do it remotely or in person.
How to play:
Quinks is based on experiential learning techniques in which two players ask each other questions related to specific contexts by drawing cards. One person is assigned the role of Questioner, and the other the role of Answerer. The Questioner draws a Quinks card (a question card) and combines it with a Context card to create and ask a powerful question. These cards consist of powerful questions that Viren collected through his research and experience.
Since the game limits conversations (responses of the contextual questions) to just 3 minutes, it compels team members to pay attention, learn to express themselves in a concise way, ask good questions, empathize and engage in deeper conversations.
I had fun playing the game even with total strangers in public sessions. It was interesting and surprising to realise that given a context and a relevant question, how you can bond with those who you’ve never met before. This was a great way to introduce people and build relationships.
Value map for further discussions:
The game also lets players map various values of their partners based on their conversations. Once everyone completes the game, you see the value map that represents how others have perceived you through your responses. Through this process you learn about your blind spots and improve self awareness.
A good reference regarding self awareness here is Johari Window. Have a look.
Personal mapping and Quinks can possibly be combined as one big workshop. I haven’t tried that yet. You may want to do that.
If you have used other collaboration techniques that gave you good results, let me know. Actually, even if your efforts didn’t succeed, we can learn from them. Why not share them here.
Agile has been touted by people (who understand it) as an approach, a value centre, a mindset and philosophy. Those who understand, have been observing some interesting posts and discussions going on social media that claim that Agile has failed in their organisation.
If we regard Agile as a tool that a team or organisation might choose to use, then perhaps we can understand the failure of Agile for that organisation. That’s be similar to any other tool that an organisation might use. Sometimes tools work, sometimes they don’t! Understood! A hammer can certainly fail a carpenter if it breaks during carpentry work. But, if the carpenter does not know how to use a hammer, it is not the hammer’s fault, or is it? (Just too be clear, this analogy does not represent Agile as a tool).
Let’s not jump too prematurely to any conclusions. Instead, let’s try to cognitively analyse if there is a problem here. Jerry Weinberg’s Rule of Three* states that if you can’t think of at least three different interpretations of what you have received, you haven’t really thought enough about what it might mean. Another version of this rule that my friend Jari Laakso suggested was, “If you can’t think of three things that might go wrong with your plans, then there’s something wrong with your thinking.”
When someone says that Agile has failed them (in other words, their Agile way of working was not successful), the actual problem might have been:
They don’t know enough about Agile and they tried to “do Agile” rather than “be Agile”.
They thought that they knew about Agile and implemented it the way we knew it. What they did didn’t work. (Rajesh’s note: you don’t implement Agile in the same way you don’t implement truth.
They thought Agile was predominantly about specific practices and conventions: using post-it notes, having daily standups, having sprints and not much else. Despite those they couldn’t deliver anything.In some contexts, any (or all) of these cases may have been a key contributor to the failure of Agile.
What troubles me is that many people who blame an approach or a methodology, do not in fact try to first understand that approach or methodology.** There was a mention of waterfall methodology somewhere and most people in the discussion did not know about waterfall’s origin. Someone mentioned Winston Royce and disappointingly it turned out that even that person had selective take of the paper and decided to conveniently forget about the last few sections of Royce’s paper which are very important.
More often than not, Agile methodologies are implemented incorrectly. Some implementers don’t realize that there are Agile values and principles (Jari reminded me about ScrumButs). Some have not taken time to look at and understand the Agile manifesto. Many Scrum Masters never looked at The Scrum Guide. Some didn’t even know it even existed. I have done this experiment of asking anyone who mentions Agile whether they have actually read the manifesto. A large number of those had not. Many of those who had read the manifesto, did not try to understand it well. Sadly those who understood it, could not implement what an approach as outlined by the Manifesto, because their organisations weren’t ready.
It is indeed often easier to blame a methodology or an approach. Agile adoption and implementations of related frameworks can fail for many reasons. What is important is to investigate what went wrong and whether that could be avoided. Even more important is to understand an organisation’s culture and whether the organisation and the approach are good fit for each other. Jerry says in his second rule of consulting, “No Matter how it looks at first, it’s always a people problem.” A good Agile coach might be able to help bring a mindset change if not the culture change.
So, as often the case may be, Agile hasn’t failed you, you may have failed Agile.