To my colleagues in coding technology: Only when you are trusted by others can you have a bright future

[[135857]]

I have worked in Autohome for 10 years and now I have started my own business for 6 months. I have hundreds of technical friends around me. I have fought with them, started businesses with them, watched them leave, and seen them unhappy.

What is the reason?

The most primitive state is: not being trusted.

The technology of writing code is a very unique job. It is not like other jobs where you can understand the logic of the employer. For example, I am a marketing person. If my colleagues from other departments are willing, they can try to figure out the working logic and efficiency of this job. I met 3 clients today. I told them where each client is in Beijing, how much time each client spent, and what we talked about. I can tell these things to my grandparents, and everyone can understand them. As long as they can understand, they can understand and recognize each other. This is the most basic source of trust.

But technical jobs are different. Except for the technical colleagues themselves, colleagues from other departments have no chance to understand the details of your work and understand your efficiency. If they don't understand, people will often be skeptical at first. Because this kind of black box job does/often/really/certainly there are some not-so-good technical colleagues who use the black box work status to delay time, slack off to earn work points, and ruin the technical reputation. The most basic trust between other departments and technical colleagues has a layer of barrier before it is established. This barrier is inevitable, not because of anyone being evil, but is determined by the unique job.

I don’t think that a long Weibo post can change the lazy and bad technical colleagues mentioned above. Those people are just garbage and scum, and are not within the scope of this article. What I want to change are the positive technical colleagues who want to continue to do well but just don’t know how to do it.

At the same time, because colleagues from other departments don’t understand, they can only ask some general questions, such as the overall progress, what do you think of the progress speed, etc., but technical colleagues often don’t answer this question directly. They have thousands of premises and reasons in their minds that lead to not telling you the overall progress (or they are unable to evaluate it correctly), so they start talking about details. Often when they talk about details, colleagues from other departments don’t understand. Generally, the atmosphere in some not-so-good companies is that people don’t like to ask each other questions, so other departments think that this technical colleague is not very good.

At the same time, other departments don’t understand the progress and can only make agreements with you based on time. As a result, often when the deadline comes, nothing is produced. The technical staff also don’t tell you in advance, or don’t know to raise your hand to ask for resources when there are difficulties in the process. In short, you are very angry. This is the source of distrust.

Therefore, if you want to change the status quo, first of all, any colleague in the technical department must keep in mind an idea: I want every colleague and partner who comes into contact with me to understand what I am doing and what methodology and logic chain I use to achieve it. I will first inform you of the overall progress and situation in the most colloquial language. If you are interested, I will then use the simplest metaphors and other methods to let you know the technical logic of the work I am doing this time. People all believe in logic. Only when others understand your logic can they trust you.

Of course, as colleagues from other operations departments, you should also take the initiative to learn some technical logic that you can understand. For example, I once spent 30 minutes to understand the logical relationship of Autohome's 5-level cache. In the following years, when I talked with technical colleagues about some cache-based issues and bugs, both sides had a lot more common language.

However, technical colleagues, don’t expect others to take the initiative to understand your logic. This matter still needs to be figured out by your technical colleagues, because colleagues from other departments really have questions and want to ask but don’t know how to ask or what to ask.

In short, if we work hard to break the black box state that is easily created in technical jobs, we can gain mutual trust.

Continue to chat, after trust is established, there are many details that technical colleagues often don't care about. For example, in a company, especially a small new company, if a technical colleague talks to other colleagues, he always uses "you" and "we". This is a huge problem in itself. The original division and person are so clearly separated. It should be: we, we do this and that together, and it feels very intimate instantly, like a company. The power of this subtext is very scary. Many newcomers just look at the words and deeds of the old people. Today they call each other "you" and "we". After 2 weeks, these newcomers always feel that the company is full of antagonism between departments.

I also understand the origin of always saying "you" and "we". Many times, the requirements given by operations and product colleagues are not clear, and the logic may be problematic. However, if the technical staff just complain and do it by themselves, it is often better to communicate clearly with the operations product staff at the time. It is better to regard yourself as the owner of the project than to be a passive coder. Many times, in order to be valued, you must first express your own ideas. If you only express your ideas by mumbling without talking to people who can make decisions, then it is all useless nonsense. You often feel that you are not appreciated. In fact, you have never expressed your ideas to effective people. Who can take the initiative to get into your mind and see what you think?

Generally speaking, technical colleagues, due to the closed nature of their jobs, have fewer opportunities to physically look up and come into contact with a wide range of things/business. As a result, their IQ is not low, but their EQ is not easy to be high. However, being a supervisor/executive requires high EQ. One must be able to use the knowledge in his or her brain with ease, be able to ask many questions keenly, and be able to pay attention to details. These are what the technical job lacks. This is why it is difficult for a company's middle and senior management to have a large number of people with a technical background. This is also why technical supervisors, directors, and CTOs are so expensive, because these people can look up, which is not easy in the field of technology, so these people are rare and precious.

***, if you want to have a bright future and not be the most miserable grass-roots programmer, you must first let everyone trust you and be a technician with no black boxes in behavior and language. This is the minimum of 50 points. Then do what you say, raise your hand to communicate when you have difficulties and problems that you cannot solve, and this is 60 points. If you want to run the management line, you must try to look up more when you are not writing code, understand more about people's hearts, human nature, management and social interaction, and figure out the human affairs clearly, so that you can use the docking resources with ease and get promoted. Otherwise, no matter how much resources fall on a person who opens his mouth and others cannot understand what he says.