preface

Most software developers want nothing more than to sit in a corner and quietly write code. But the harsh reality is that communicating and communicating with others is a must for software developers these days. It’s not uncommon to see a technician arguing with a product manager, PM: How did you develop this feature? DEV: It’s what you asked for. It’s what you asked for. OK, as long as to this step, the basic will evolve into mutual questioning ability, unhappy parting, and even may become a real PK. This article will talk about common problems in communication with the combination of a simulated failure of communication.

background

Many people read a lot of books and know the theories, but when it comes to real experience, they tend to forget and become the puppets of their genes.

The simulated failed communication took place in a small meeting with a small number of participants, about five or six, one of whom was a senior manager, and the rest were software technical backbone and middle-level staff of the department. Everything was nothing special, the main topic of the meeting is the next step of the system modularization. First, high-level C and business department B express the market demand for modular talk, and then A, as the software technology department, introduces the current situation, the actual architecture and original planning of the current system.

A: The system itself is modular. B: Modular? Can you sell it directly? A: A look of frustration, and then try to explain how the current architecture implements modularity, microservices, middleware, componentization, blah, blah, blah, blah. B: What did you say? Can you sell it separately? A: Yes, but need the current system business support, need XX business, need XX basic information support… Another pile. A: Our system positioning is to have A certain degree of coupling with the business ah, completely decoupled from the business, also does not lead to the expansion of the field, competitors substantially increase… B: You just need to concentrate on the technology, and we’ll take care of the business problems.A: Business and technology have to work together. B:… In A word, you are wrong. You’re wrong anyway

Then the topic was completely confused, and there was no direct conclusion after half an hour of discussion. In retrospect, it’s funny that the two were not on the same channel all the time and did not try to understand each other, but under special circumstances, their perspectives were limited and they went into a state of proving each other wrong.

The main problems in this communication

Definition problem: The two sides do not have a common understanding and definition of what is being discussed (modularity). PS: In 10 minutes, ask 1000 software technicians what modularity is twice and you’ll get 1500 answers. Perspective problem: Communication only starts from oneself, with insufficient cognition of the other party’s role and perspective. Posture problem: Always on the defensive, ready to fight. Problem of way: label people first, not things. Occasion problem: Pay attention to the different communication environment and communication objects. This communication is in a meeting, especially the presence of senior leaders, who do not want to admit their mistakes and try to understand themselves

What do I do

Be alert to distinguish between X/Y problems and common definition problems

There is a question on Stack Overflow asking “How do I cut the last three digits of a string?” People gave a bunch of answers. Suddenly someone asks, “Why did you intercept the last three digits of a string?” He said, “I’m looking for the extension of the file.” In fact, file extensions don’t have to be three characters, and there are special functions that do that, so you don’t have to write them yourself. In this case, take the extension of the file, which is called X, and take the last three characters of the file name, which is called Y. He wanted to know X, but didn’t know how to say it, so he said Y instead, causing everyone else to solve a problem that didn’t exist. This is called an X/Y Problem.

Stop and jump out of the proof state

The only thing that can save a conversation when you get into a mutual proof state is to stop, cool off, drink a glass of water or wash your face, reassess your purpose, and adjust to the situation and the person.

Trying to empathize, to share, to benefit, to agree

The first is empathy, sharing their feelings with each other, which is the most effective way to close the distance, and then it is to share their own views with each other, seeking common interests in their views, and then the cycle continues, reaching consensus bit by bit.

Personal reflection

It’s not just one reflection, but a few more whys and whys, and once you’re uncomfortable, you know you’re in the right place.

For example, the reflection process of this time: why did the communication fail and the topic deviate? Level 0 reflection: Attention should be paid to the synchronization of information in the unified communication. This time, we did not timely find that the definition of modularity was inconsistent in the communication. Why did we enter into the state of proving each other wrong? Level 1 reflection: Prior to labeling the other party does not understand the technical/business label, has been didactic posture and is aimed at persuasion. Why do you think the other person is wrong and you are right? Level 2 Reflection: Once again to verify the view of Carnegie’s “How to Win And Lose Human Nature” : people care most about themselves, once their ideas are not accepted by others, the instinctive reaction is to prove them wrong. Why didn’t it stop in time? Level 3 reflection: Wanting others to identify with you too much and lacking confidence. Anxiety and low self-esteem are present.

To improve the

  • Acknowledge your limitations and constantly improve yourself
  • Every time you speak, try to see yourself from the other person’s point of view
  • Be proactive and acknowledge others. Recognition is a good start

reference

Much of this is from the following column and will not be listed.

  1. Lecture 34 of Lecture 36 of Technology Management
  2. Lecture 103 of Wind in the Left Ear
  3. “Zhu Yun’s technical Management class” 08 talk