Product managers and development engineers

See Andy's "PM How to break through the engineer's heart defense?" and "How the engineers do not be PM bullying" touch, welcome to the brick, discussion.

From a team perspective, product managers and development engineers should be brothers on the front because the goals are consistent. Both product managers and development engineers want to do the products and projects, here we can say: "Zhi Tong."

But product managers and development engineers, because of the role and work content of the product development process, and may not understand each other's work content, there will be a lot of communication costs, communication is not talking, but change action. Real communicators focus on the effects of communication. In communication, it's not what you say, it's what the other person understands, so the feedback is important. Often a lot of product managers and development engineers communication will appear "donkey head to Horse mouth" we do not understand each other situation, and even lead to small friction, when we said: "The road is not appropriate."

"Tao is different from the other", will inevitably lead to disagreement, and even bring about the effect of unpleasant mood in work. Whether the product manager and development engineer which side is strong, or in the "war" process which side "win", will cause the other side of the negative impact, or even decadent. The result will always be a product or performance, or something else that is often unsatisfactory. The end of the project, the assessment of performance or project summary of the time will be the responsibility to the other party, followed by everyone complained, blame. Then product improvement is the next round of "war"; over time, the impact is not a product to do bad, not the main consequences, this product does not do well, we can improve, can do the next product. The most serious consequence is that the team falls apart, disunity, without cohesion. There is no cohesive team is absolutely no combat effectiveness, is absolutely no good products. This is fatal to the team and the company.

Although many people understand this, however, such "combat" or product manager and development Engineer's contradictions are always happening! We can look at the two questions and answers:

1. What do product managers hate about developers? http://www.zhihu.com/question/19629183

2. What are the bugs that developers hate about product managers? http://www.zhihu.com/question/19628273

How to solve these problems, please see Andy's "How to break the engineer PM" and "How the engineers do not be PM bullying", although in the actual process you may not be able to do, but at least we can get some inspiration from it.

=================================================

PM How to break through the engineer's heart?

From: http://www.kuobrothers.com/article-125.htm

PM often encounter a problem, that is, there are a lot of things want to do, to helpless everything through the engineer, no way to do their own, so because and the engineer is not very good relationship, the final actual products are not designed to look good. I'm talking about the status of "Internet company", which is about people who plan their products. Other industries may have a similar situation, and the following "teaching hands" provide some reference to the PM who is groping for his own survival.

First figure out what to do and what not to do:

Often, PM will put forward some of the idea of unrestrained, so that sometimes the engineers feel very difficult to cooperate. It's because you don't know what to do or can't do. To the website, this is actually very easy to know, do not need too much study and knowledge. If there is a feature that you can see on the three site, 99% it can be done. For example, you want to have a page, fill out the address of the "County city", the next menu will be loaded in the county you choose the canton. If you do some homework, you can see that the form appears on many websites. That's 99%. If you come up with a way of showing up and never looked at anything, it's more likely that you won't be able to do it. When communicating with an engineer, if you want to make a drop-down menu like this "County city," You'd better ask the engineer to look at someone else's page instead of describing it in your own way. The engineer usually has the character which does not want to lose, if other website can make out, he does not want to be able to do not come out.

Never debate anything about technology with a mechanic:

While PM can learn a little bit about the concept of Web pages is good, but with the engineers, you may often hear "this difficult to do" feedback. It can represent several different meanings. It may mean that it's really hard to do, or that he doesn't want to help you. If it's the second, there are a number of ways to compromise. But it is absolutely the worst way to prick him and get him to argue. When he says it's technically difficult, never tell him, "This is just ... It's OK! It may make you look smarter, but your relationship is dead. And the engineer's character is easy to have a very strong self-esteem, so don't do it. And, Technical's field, you may never argue against winning him. A lot of "This can not do" problem, not from the reason, but from do not want, unwilling, feel this meaningless, or really spend time. If you really want to do it, 99% of things can probably be done. So when this seems to be a technical angle to reject your situation, if you really want to stick to your idea, try to get out of technical's discussion, you should understand his technical obstacles, but never argue with him in this field. Because you win or lose is no good.

Engineers like you to ask him:

It is easy for an engineer to have a certain character, to sit there and hope everyone will come to him. So it's not hard to imagine that the way people do things for you is to lower your posture. You have to make him feel that you need him, not that he must help you. Even though you've always thought, "the company pays you to come to work. Perhaps as PM you, when every project has progressed and stuck in a time of no progress, take the drink point menu to ask the engineer what to drink is a good way.

Give all credit to the engineer:

In the company, because a lot of products are planned by PM. So the success of project, it is easy to feel that the PM credit. Please try to send these credit to the engineers who are working with you on any public occasion or email. The same spec, a good mood engineer, can make it 100 points. A bad-mood engineer can make it 60 points. Two can 100% match your spec, but one can be rotten to a myriad of problems. Because software is not beforehand can think clearly. So an unhappy engineer, can see many problems but "ignore", also do not take the initiative to tell you, then you are finished. So be sure to let the whole company feel that these achievements belong to engineers. You take credit away once, and the next time you're done, because no one wants to work for you.

Don't despise "the engineer's project".

The engineer you work with may say that he is busy because he is "rewriting some function" or "making the database a little faster. Many PM do not know what they are doing when they hear this, so they will show that they don't care about or don't think they are important. Usually engineers prefer to do this kind of implicit project. Because they don't have to listen to PM's command. For a healthy company, there will be a certain percentage of resources invested in these project. To do so is usually decided by the boss, or by someone who knows more about it. But you have to be in front of the engineers to make people think that you seem to agree.

The posture is soft, but cannot lose the dominant power

Although the front says you are soft, but you must not give your project to the engineer, you lose the lead. Because it makes you look less valuable to your boss. You should at least continue to master the "time" and "content" of your project. That is, you must maintain your "dominance", stick to what you insist on, and compromise on something, but not all the engineers.

Do not finalize all designs and give them to the engineer.

Most of the engineers are disgusted with this process, so please find a way in the design phase, to consult the engineer's opinion. He may say that he is busy, you want to be good. Even if you just get this sentence, it has great value. This means he gave up his future because you didn't find him first in project early, so he blamed your rights.

In short, the engineer's mood is elusive. So the problem of "emotion" may be more important than the discussion of "technology" or "function". If you like this article, perhaps you can read the "reverse version" of this article again: How does the engineer not be bullied by PM?

=================================================

Engineers how not to be bullied by PM

From: http://www.kuobrothers.com/article-127.htm

The teacher taught us how to write programs, but never told us that in the company, there will be a person called PM assigned to us every day, but also forced us to hurry to finish. This is the first surprise that many software engineers have entered the workplace. After a while, you'll find that most of the PM that can crush you is not written in a single line of code. So we will face a very contradictory mood, sometimes it is a bit of being bullied psychology. This article is the previous article pm how to break through the engineer's heart defense extension, we discuss is the engineer in this situation survival.

(1) Improve their visibility

In a very large number of companies, top bosses or company bosses only see a project PM and don't see the hard work behind the engineers. In other words, your efforts and achievements have been obscured. I have always believed that it is important to have "visibility" in front of the boss or other colleagues in the workplace. Visibility except in a number of situations (meeting speeches, discussion ...) can appear outside. To provide a good friend I have a very powerful move for you to refer to. As an engineer, he would "inadvertently" send out a "Thank you letter" to everyone involved in this project after each big project, by the way CC gave the big boss who didn't know what he was doing. There are one by one points in the letter thanking everyone for his guidance and project assistance. This kind of letter everyone looked very happy, the most important is the last big boss also had a deep impression on him.

(2) Don't immerse yourself in writing programs every day:

Most engineers like to immerse themselves in writing programs because it's the best and the least energy thing. But if you write the program 100% times a day, I'm sure you'll feel good about yourself, but everyone doesn't know what you're doing. So maybe it's time to change the strategy and let yourself have a little bit more to "express yourself". "Show yourself" does not mean to do some superficial kung fu waste of time. Instead, take part in the discussion and give meaningful advice. Engineers like to use computers only to communicate with other people, want to use a system to track progress, ideas are discussed with email. In the workplace, it is important that you learn less email, and go over and talk to that person. It may take 1 minutes to walk, but you interact well with other people, and you'll get on well in the workplace.

(3) to stand on the boss's point of view things:

Engineers because of the role of the relationship, it is very easy to stand in the "technology" point of view of things, but often in charge of the veto and feel discouraged. The company's ideas are usually similar to the PM's idea, are standing in the interests of the company to think things, rarely use the "technology" angle to think things. Try to think like them, and your days will be happy. For example: If our company is now going to enter 10000 information. There are two scenarios, scenario A is "manual input" and scenario B is "automatically imported by program." Programme a asked for 10 work-study, and almost none of the inputs were much worse. Program B is a powerful program, you develop a day, the program runs 3 seconds to complete. However, the overall cost of programme A is assessed to be lower than programme B. I believe that most of the company's operators will be willing to find 10 people, do a duplication of things, a sum of key in data. If you think in terms of an engineer, you might think, "This is so simple, a program is good", and then start to think that the boss chooses Plan B is really pedantic. You should try to sync your brain with the interests of the company, which will make you a lot better. Because most of the PM knows how their brains are going to sync with the boss. There is only one way to make yourself look smarter than PM in front of your boss, and that is that the brain and corporate interests are doing more than PM.

(4) With PM fear of weakness effectively to get more development time

PM very like everything is on schedule, if the early online is better. It is unwise for many people to turn their face to PM because of deadline. Back to the example of my engineer friend, he will be very pleasant to PM said "I can stay up late every day to finish it, may be on line, but I know it will appear a lot of" we "have not thought of the problem, it may make the boss (or customers) think we are very not careful. But if you can help me to buy a little more time, I can make it better quality. "For PM, in addition to" fast ", if the things come out very bad, also hit his pain point. My engineer Friends Use this method to help themselves to get a longer development time, and better sleep.

(5) Communicate with him in PM language

Many engineers get used to communicating with their own language and PM, resulting in poor communication. We have to try to make ourselves talk to them, a language that anyone in the world understands. As little as possible to mention technical terminology, as little as possible to let pm feel you use your technical advantage in suppressing him. Because PM is not likely to learn the language of engineers, the only way you can communicate is if you learn to use PM language.

(6) become the most popular PM people in the engineering team

You will find that if you call PM to vote, from the most like the cooperation of the engineers, ranked the most do not like the cooperation of engineers. The list is often very consistent. And you'll find that people who are in the top of the list are usually more likely to rise up in the workplace. So, find a way to become that person! Because the PM's evaluation of you, often in the company, and your engineer in charge of your evaluation is equally important.

(7) Three months before work, don't try to change anything in the company.

The company's systems, company's project, processes, everything. It will be the way it is, and there must be a reason for it. There are reasons for reason, irrational reasons, and perhaps the reason why. But the vast majority of companies looking for you, want you to put a thing in his "current structure" under the development. In the first three months, if you think the development environment that everyone uses sucks, the test process sucks, any platform sucks. Please bear with me, because except for the very very open minded supervisors and colleagues, most people will not be too welcome to the idea that you just came in and wanted to change everything.

(8) attributed to PM:

The EQ good PM will give project credit to the engineer. But as an engineer, if the EQ is good enough, it should be attributed to PM. Don't think you made it yourself because it's the code you wrote. It's not helping to survive in the workplace, except to feel good about it. Find a way to speak pm". Think of yourself and PM as a team, and this project is made by us. Although many pm will joke that they are in the side to help the handyman, but he will be very grateful to you very thoughtful to give some credit to him.

(9) Don't waste the company's resources to enjoy your sense of achievement

Many engineers like to take the company as lab and experiment with new technologies. If it's "really helpful" to the company, of course it's good. Before you do these things or proposals, try to use your employer's perspective to maximize your company's interests (rather than personal learning or fulfillment) and whether he will support you in this experiment. If not, don't do it. Because while you're having fun, people may think it's just a waste of company resources.

(10) Become a more PM-like person

Technically you should be on the same team as your other engineers, but in "character" or "behavior," you usually have to imitate the PM. Please believe me, in most companies, "character" and "behavior" similar to the PM engineers, in the company is the most popular.

Write this article and perhaps get some more criticism. But I was just kind and wanted to tell the engineers. We should improve our visibility and let others see our performance in moderation. And to become an engineer who looks like a PM, usually in the company. Many engineers feel they are being bullied by PM, but pm usually doesn't bully people who look like them. If you like this article, perhaps you can take a look at this article: PM How to break through the engineer's heart defense?