Perception and Perspective

Perception and Perspective

“Hey Rajesh, there is a perception that you don’t do <X>!”

The consultant that the company had hired told me.

“Oh! Who in the team think that I don’t do <X>?

“Mate, I can’t tell you that. But perception is reality.”

Only after few years of leaving that place I found out that it was him who created a perception. He wanted more influence (and more business) and I used to question things. Well!

In that case, I did not receive any useful and actionable feedback. This is unfortunate that such scenarios are far too common where people receive vague comments instead of actionable feedback.

At Microsoft, we use the word “Perspective” to get our colleague’s point of view about how one is performing, what they are doing well and where they can improve. This mechanism allows people to receive all-round feedback and not just someone’s perception.

So, what’s the difference between perception and perspective?

Can you define each of those clearly? Most people find it hard to explain what they mean by perception and perspective.

Yet, both of these things are important for us to understand the world around us, assign meaning to what we observe and then decide whether to act or not.

You may hear some people saying that perception is reality, but I find that unintelligent. Saying that is only an excuse for not thinking clearly and critically.

What is perception and perspective?

Perception is the interpretation of things that we see, hear, smell or feel. It is what we ‘believe’ we understand after receiving a sensory input and then define a meaning that we apply to a situation, person or a thing.

For example, look at the cartoon above. Depending on how you look at it, you can easily perceive number six (6) to be number nine (9). You may even fight with someone about being right.

Perspective comes via and after perception. In other words, perception leads to perspective. It is our point of view that we build based on our perception.

If you are thinking that both perception and perspective will together in determining how we interpret things and build a point of view, then you are right.

This cartoon that I found on internet is also a good example of how perception of a given situation creates a point of view (perspective).

The image below is a good and powerful example of how perception and perspective play an important role in building our PoV.

  • What will you perceive if you only look at the first part of the image?
  • What will you think if you only see the last part of the image?
  • What is your point of view about the situation?
  • After seeing the full image, did your perspective change?

Note: The above image was created by Ursula Dahmen. Find the details here: https://www.spiegel.de/fotostrecke/manipulierte-bilder-fotostrecke-107186.html

What was surprising for my own interpretation of the above image was to discover that the soldier on the left wasn’t pointing the gun at the other soldier’s head. It was strapped to the soldier’s back.

Even that interpretation might not be correct until we hear the truth from the horse’s mouth.

Perception and perspective in work scenarios:

Passionately debating is quite common in some cultures.

It is also natural to have debates and discussions at work. A person who is only an observer and noticing the arguments, all the back and forth from both sides and sometimes the treated voices out of passion might perceive the debate as a fight.

This observer might build a point of view that the people debating are causing trouble at the workplace and might decide to complain about them to their seniors.

Based on this observer’s complaint, the senior folks might build a perception too and decide to take punitive action against the people who were merely debating a topic related to their work.

So, while perception is not reality, it may manipulate the reality. Unless one seriously pays attention, find all facts about a situation and critically examine them, perception may turn into a belief.

As managers, leaders, parents or friends, it is our responsibility that we learn about our perceptions and do not let them affect our perspective merely through quick judgement.

That is not easy, but at least we can try.

Are You Making Career Transition Easier or Harder?

Are You Making Career Transition Easier or Harder?

In my 25+ years of career, I have made many transitions to different roles, jobs and industries. Career transition can be nerve wracking, but if done well, it can be very rewarding.

Here are a few tips on how to successfully transition your career.

1. Validate purpose

Check why you want to transition to a different <role, job or industry>

If you have good enough reasons, then move to the next step.

Sometimes the devil you know is better than the devil you don’t.

Also, the grass is always greener on the other side.

2. Plan

A well though-out plan can reduce risks of unknown in a new career.

Add a timeline to your plan. A timeline can make your plan measurable and can give a direction to your goal.

Remember that plans are nothing, planning is everything.

3. Get a mentor

A good mentor can make your career journey smooth by sharing their experience and by exposing your blind spots.

They can drive, guide and inspire you.

A mentor can also help you stay afloat when stress and anxiety try to pull you down.

4. Get skilled

Read, study, learn!

Take classes, attend webinars, watch videos, listen to podcasts, read books,…

Do everything that enhances your skill level in your aspired career.

While you won’t become the best in short term, you’ll become really good.

5. Note your current skills

When changing careers, people worry that they don’t have skills.

We all have transferable skills. You may be great at networking or speaking, or writing or collaborating etc.

Employers need these skills in their staff. Add these to your resume.

6. Get experience (while in transition)

Here are some ideas:

– Do side projects/ freelancing

– Do pro-bono work for a friend

– Find an internship

– Offer free work to a start-up

– Join a crowdsourcing group

Add these to your resume.

All of these show that you’re passionate.

7. Network like hell

They say, “It’s not what you know, it’s who you know”

Ideas for networking:

– Go to local industry events (meetups, conferences, exhibitions..)

– Attend online events

– Join online forums (must add value to those)

– Connect with experienced folks online

8. Be open and ask for help

If you don’t ask, you don’t get.

What’s the worst that can happen? Someone would say no to you. That’s it!

Harry Potter book was rejected numerous times too.

Ask for entry level roles, internships or paid projects (depending on your situation).

9. Last, but not the least, be patient.

Changing career direction can take time. It’s a slow process.

Effort, perseverance and patience with good planning are the right ingredient for success.

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.