Perspective of the Other Side

Table of Contents

Common Leadership Challenges

While working with leaders, I often encounter a recurring issue—they want someone else to change their behavior. For example:

  • How to deal with people who criticize my ideas?
  • How to stop a boss from micromanaging the team’s work?

We desire others to change because we believe we are right, have good intentions, and aim to improve the work environment, while the other side seems to hinder us. We are convinced that Agile/microservices/Product focus (not project)/whatever is the only idea that can help, and anyone who disagrees is an enemy to be subdued.

If someone criticizes my ideas, they must be wrong. If my boss tries to micromanage, he is an ignoramus, because every management book describes it as an antipattern.

The Subjectivity of Beliefs

But let’s be honest—all ideas like:

  • (the power of) teamwork
  • limiting work in progress
  • autonomy (instead of micromanagement)
  • timeboxing
  • agile/kanban/lean
  • TDD/BDD/ATDD/Spec by example
  • (…place your favorite idea here…)

are just ideas. They are supported by a set of beliefs, but mostly subjective beliefs. You believe in them or not, but you can’t prove they are right. They are just models, theories, hypotheses, patterns, heuristics, strategies. Because they are applied in complex environments, there are contexts where they will be beneficial, and contexts where they will not, and sometimes it will be very difficult to evaluate their real value. So every time you meet someone who doesn’t agree, be aware that they might be right. This is the first necessary step to deal with the issue. It is secondary what you believe in; much more important is how you react when someone doesn’t agree or follow.

The Importance of Perspective-Taking

The most significant obstacle to tackling the challenge is our tendency to view the situation only from one perspective—the “I” perspective. This perspective is subjective because it is based on our current beliefs, expectations, state, knowledge, and biases. This is why it is so difficult to solve problems between people. If we genuinely want to find a win-win solution, we need to try to see the situation from the other side’s perspective—the “you” perspective.

Understanding Underlying Intentions

If a person criticizes your idea, just try to find an answer to “why?” But beware, because we like to see negative intentions in other people’s behavior. “He criticizes me because he wants to diminish me.” In some rare cases, it may be true, but it is not the root intention. The root intention is, in most cases, positive, at least from the other side’s perspective. They may criticize your idea because they want to ensure that the best possible solution will be applied or want to warn about potential problems that may arise.

In the second example, if a boss wants to micromanage, just ask, “why is it important?” He may want to ensure that work will be done correctly or in a standardized way. When you know the intention, it is easier to find a solution—a different way for the boss to ensure it without micromanaging. If you just say, “Micromanagement is evil,” you will try to take something away from him that is important and give nothing instead.

Applying Empathy in Leadership

So the next time you don’t like someone’s behavior or attitude, try to look at the situation from their perspective by asking, “why is it important for him/her? What is the positive intention?” Then it will be much easier to tackle the situation. And remember, most of the stuff you think is the right way of doing things is just a set of beliefs—subjective beliefs—so don’t be too attached to them.

(Of course, this subject is not specific only to technical leaders but can be attributed to the entire human race.)

Related Posts

Code Cleanliness: More Than Just Refactoring Part 1

Initially, my intention was to create an article about refactoring. However, the more I pondered the subject, the clearer it became that I would not be writing solely about refactoring. It’s about something much more significant—conveying a vast amount of knowledge, essentially experience, related to code creation. Code that not only works or is well-designed but is most importantly easy to read. When we achieve this skill, we stand on the threshold of professionalism. Programming professionalism.

Read More

A Manifesto Against Developers

A Manifesto Against Developers

I hate you because:

  • You focus on the features of your IDE instead of the features your client/user needs.
  • You consider typing at the keyboard as thinking.
  • You waste countless hours manually testing your code.
  • You spend more time struggling with frameworks than delivering value to end users.
  • You code for hours without asking yourself, “What am I really doing?”
  • You naively believe that technologies and tools will solve your problems.
  • You naively believe that a good algorithm is more important than a good understanding of requirements.
  • You naively believe that your intuition is enough for writing good code.
  • You naively believe that you can manage the complexity of the system piece you’re working on.
  • You agree to unrealistic deadlines.
  • You write poor code and rationalize it with various excuses (because there is no time).
  • In your head, you create code snippets without really knowing what needs to be done.
  • You guess what needs to be done rather than clarifying.
  • You mindlessly follow the technology you use.
  • You don’t understand the tools and technologies you use.
  • You isolate yourself in your piece of code, breaking contact with the world.
  • You think it’s all the fault of managers or clients and believe you can’t do anything about it.

… even though I love you because I am a programmer myself.

Read More
Hurry, or Something Smells Here [Archive]

Hurry, or Something Smells Here [Archive]

Hurry, or Something Smells Here

When I think about various problems organizations face, especially recurring ones, the most characteristic symptom that something is wrong is hurry.

Read More