Someone submitted a question:

Having worked in the internet industry for several years, most of the technical personnel I have encountered have the following problems:

• ①, Reticent and rude;
• ②, When collaborating, they don't like to report progress (for example, while working on something, they suddenly stop and you don't know what they went off to do; if you don't urge them, they won't tell you);
• ③, They don't reply on QQ, and if they do reply, they revert to point 1.

May I ask if this is a common problem? How do you tech folks view this?

The following are excerpts of some excellent replies

1. Li Nan

Poor communication with technical staff is mainly the responsibility of product managers. The reason is simple: they are in technology, and it's not their job to communicate with users and convey requirements to technical staff. If you enter their context and become familiar with their logic, you'll often find you can communicate with them efficiently.

Poor progress control is mainly the responsibility of project managers. The reason is also simple: they are in technology, and it's not their job to manage and control progress. You need to organize meetings, establish systems, collect progress, and evaluate results.

The best programmers are, of course, smooth communicators, good at self-management, and have a big-picture perspective.

But personally, I don't care about programmers who are reticent and don't like to report progress. As long as they follow the rules and deliver usable code. I've also seen many articulate programmers who always give beautiful progress reports. However, the stability of their code might be so bad that I have to reassign someone to rewrite it.

The OP seems to be a product or project manager? My advice is: don't always try to blame others; do your own job well. Just like a reticent technical person fixing a memory leak for you.

2. Fan Kai

I quite agree with @Li Nan's view.

>>1. Reticent and rude.

Working in technology requires down-to-earth focus, and over time you develop a relatively introverted personality. If you meet a technical person who is all sweet talk, you really need to be careful. Such technical people often cause you big trouble, such as lying about work results, stirring up trouble in the team, gossiping, and sowing discord. These are the painful lessons I've learned from hiring.

>>2. When collaborating, they don't like to report progress. For example, while working on your thing, they suddenly stop and you don't know what they went off to do; if you don't urge them, they won't tell you.

If it's a "collaborative" relationship, using the word "report" seems problematic. Since he is a peer collaborator with you, why should he report his work to you? If anyone is obligated to report, it's only to his own leader.

For example, the R&D team, product team, and operations team under me collaborate on a project. R&D engineers have no obligation to report progress to product or operations staff; the R&D team is only obligated to report to me. So how to strengthen communication between teams? The method I use is:

Each team reports progress to me. I have product staff produce a weekly project progress report and email it to everyone so that everyone knows the project's progress. In addition, starting a 30-day countdown before project launch, every day before leaving work, I gather everyone in the project team for a quick daily progress review meeting.

This project management approach has never failed me; the collaboration among product, R&D, and operations teams is very efficient. Therefore, the situation you described is, in my view, the leader's dereliction of duty. Product staff don't have the authority to directly command R&D staff at the same level. It's the superior leader who abandoned his responsibility.

>>3. They don't reply on QQ, and if they do reply, they revert to point 1.

I don't like to open QQ during work; if I do open it, it's in do-not-disturb mode. If you have something, email me. This is the principle I instill in the whole team.

Let me add a few more words. The programmer profession is highly specialized. Not to mention communicating with outsiders, even developers in different fields can hardly communicate. For example, those doing web projects, embedded development, or game engines have knowledge systems that rarely overlap, making it almost impossible to communicate effectively in professional fields, let alone with non-technical people. Barriers are bound to appear.

Let me use an analogy: the medical profession is also highly specialized, so you feel doctors are also hard to communicate with and usually unwilling to have in-depth conversations with patients. It's the same as programmers—the knowledge systems differ too much. Unless one has particularly strong communication skills, effective communication is hard to establish.

One last note: checking programmers' work progress is not difficult for a manager with a technical background. In fact, even if programmers don't report to me, I still know their progress. The reason is simple: I have the highest privileges on the company's internal git source code server. I regularly pull the source code of various projects to see who recently submitted which commits, hehe.

3. Big Tree

I myself have been working in software development for nearly 5 years. The phenomena the OP mentioned do indeed commonly exist among my colleagues.

1. Reticence—I think most of it is unconscious behavior. That is, many developers lack opportunities to communicate with people in their learning and work experiences, let alone communicate well with other colleagues. My own personal experience is that I try hard to communicate and interact with other colleagues and even anyone, but because I lack experience and skills in this area, I make mistakes, and at the same time I'm sensitive to the unpleasant emotions that poor communication causes others. I feel frustrated, and the frustration further damages my confidence in communicating with others. In short, this is a problem I haven't solved well myself.

Also, because they face machines for a long time, they get used to straightforward, blunt interaction. For example, if a machine gives a "hello world", a programmer might only think of a main function and a prinf call, not understanding that the person communicating with them is a living human with other thoughts, forgetting to consider human aspects.

For example, when a PD asks whether a complex feature can be implemented, some programmer colleagues, based on their actual experience, immediately give a blunt, cold "no" that leaves no room for negotiation. Actually, softening it—such as "the time cost is quite high; if the schedule is a bit more flexible, I'd be willing to try"—would make the PD feel more comfortable. This gives both sides an opportunity to continue the topic more deeply and pleasantly.

There is another undesirable phenomenon that is indeed related to the programmer group. Many programmer colleagues are rather arrogant. This arrogance may come from good academic performance, higher income compared to peers, or even just having solved a certain bug. In a self-awareness lacking communication, these factors may not make them realize that this is nothing remarkable.

In order to improve the way I speak and get along with others pleasantly, I even bought a seemingly boring book like "Cai Kangyong's The Art of Talking". It may not have improved my speaking skills much, but it made me realize that speaking is a skill.

2. Not reporting work progress is either due to laziness or lack of planning for one's own work. If you want to become someone others can rely on and want to leave colleagues with an impression of dependability, you must be loyal to the tasks entrusted to you. Due to the particularity of the IT industry, you should increase the frequency of feedback on your work progress. This is an attitude toward work, not limited to the IT industry. If you are unreliable, don't expect to take on important responsibilities.

In order not to forget the things my colleagues entrust to me, I write them down in a memo and keep it nearby. I know which work I am doing and when each task needs feedback.

3. If they don't reply on QQ, use email or call directly. For work communication, try to use QQ as little as possible. You can walk to their desk and chat, or use any method you think can engage them.

Every programmer colleague who cannot get along pleasantly with other colleagues should think about these issues.

From:Zhihu