Help and Clarification: How to Manage Your Superiors? #
Hello, I am Zheng Ye.
In this module, I have provided a detailed explanation around the principle of “begin with the end in mind” and introduced some industry best practices for applying this principle.
Many students have been actively engaged in leaving comments and have expressed that they have gained valuable insights. Additionally, they have raised numerous questions. Everyone is particularly interested in how to implement these practices in their own work. I have already responded to some of the questions in the comments. In today’s Q&A session, I have selected some typical questions to provide more detailed answers.
Question 1: What should I do if I can’t refute the requirements of my leader? #
a student named achenbj mentioned:
You explained it well, but I feel that there is still much effort needed for implementation. Our leaders give us tasks and tell us what to do, and that’s all there is to it. That’s it. - —— 04 | 接到需求任务，你要先做哪件事？
A student named Alexdown mentioned:
Considering the unequal status and my established “persona,” it is a bit difficult to implement. - —— 02 | 以终为始：如何让你的努力不白费？
This is a very classic problem, and many students have mentioned it in their comments, so I won’t list them one by one.
In my professional career, I have heard countless people complain about the same thing. Initially, I felt that this was an unsolvable problem until I read a book.
Management master Peter Drucker has a classic work called “The Effective Executive,” although the title has the word “executive” in it, but in my opinion, this is a book that tells us how to work, and everyone can read it.
When I read this book years ago, one of the points shocked me: how to manage superiors.
What? You can also manage superiors? For those of us who are used to following orders from superiors, this conceptual shift is almost earth-shattering.
In the eyes of many people, they work hard because of their idiotic superiors who have not handled their duties well and blame them for everything.
However, in Drucker’s view, superiors are also human beings, with strengths and weaknesses. We should make use of their strengths and minimize the adverse effects of their weaknesses. Managing superiors means utilizing their strengths, not simply obeying orders, but rather proposing suggestions in a way that superiors can accept.
So how can we manage superiors in our daily work? Here are some suggestions.
We must dare to manage superiors, saying “no” to unreasonable demands from superiors is a mindset shift. Many people are influenced by traditional hierarchical thinking and have reached an unhealthy level of obedience to superiors. The precondition for effective management of superiors is to have the courage to make changes. If you don’t make a mindset shift, my following suggestions will be of no value.
So specifically, where do we start?
First, manage the expectations of superiors.
If the superior asks you, “How long will it take to complete a product feature? Two days? Can you do it in one day?” You think about it, and if you don’t write tests, it would indeed save a lot of time, so you decide to agree to the superior’s request. Yes, most people compromise like this.
Compromising is easy, but it’s not easy to go back. Next time, he will compress it further: “Can you do it in half a day? Can you do it in two hours?” Human desires are infinite, so don’t let the superior have incorrect expectations.
If it were me, I would tell the superior what this compression will affect. For example, if you want to make this adjustment, what you need to give up; or, I can provide a temporary solution for quick deployment, but in the next few days, I need to make adjustments to bring the code back to a normal state. So, don’t assign me new tasks.
This process is equivalent to exposing the problems you see to your superior and letting him choose. He has more context, and he will balance what needs to be done.
Second, help superiors gain more knowledge.
Not every superior is experienced and knows everything. For example, some fast-growing managers may not have had time to fully understand the complete software development life cycle. This is very likely in the rapidly developing IT industry. Therefore, it is very likely that you know more than him in some specific areas.
In areas where he is not doing well, he must have many concerns. For example, a product manager who blindly asks for requirements may also affect his judgment of requirements.
At this time, you may find an opportunity to share with him what you know. A simple way is to send him the content of my column and discuss with him what is a reasonable approach. Then, everyone can work together to improve the way we work. Because you are helping him solve problems, he will be more willing to accept it.
Third, express your thoughts.
If you don’t do anything, the superior will arrange work according to his own understanding. For example, if Xiao Li is good at handling message queues, all the message queue tasks will be assigned to him.
If you have your own thoughts and plans, why not speak up and take the initiative to assume some responsibilities? For example, if you plan to learn more about message queues, just tell the superior openly. When the next relevant task comes up, consider yourself. When the superior arranges work, he will think about you more. This is actually the simplest principle we are familiar with: the squeaky wheel gets the grease.
If after all your efforts, you find that you really can’t influence your superior and he can only act in a frustrating manner, then you need to carefully consider the prospects of working with him.
However, a more likely scenario is that you give up before trying to change and attribute all the responsibility to your superior. If this is your logic in problem-solving, no matter which company you go to, the result will not be better than it is now.
Question 2: What should I do if the product manager always cites the boss as the reason? #
Francis mentioned,
Many times, the only reason given by the product manager for doing a requirement is “because the boss wants it!” - ——01 | How do 10x programmers think?
Xixi Fu and Kafka mentioned,
Some product managers will use a killer move - claiming that it’s the boss’s requirement - ——06 | Lean entrepreneurship: What should you do if the product manager is unreliable?
Using the boss to pass the buck is particularly common in the software industry.
In reality, the boss is giving the direction, not the specific product features. The boss doesn’t get into the nitty-gritty details. Therefore, what a product manager should do is turn the direction given by the boss into implementable product features. They should analyze what is reasonable and what is not.
The unreasonable parts should be discussed with the boss, not pushed onto the development team to implement.
In the real world, what is more likely is that the product manager “takes a tiny suggestion as gospel,” when the boss says “give it a try,” it becomes “must be done” from the product manager’s perspective. They don’t dare to question the boss, so they just push the pressure downstream.
In this situation, you might as well go see the boss together with the product manager. As we mentioned in the article “Solving many technical problems, why are you still stuck in the “pit”?,” you should expand the context of your work. This approach can also help you solve problems that cannot be solved within your own context. Place those problems in a larger context to solve them.
Question 3: We Should Do What Others Can Do #
Xunqf mentioned:
When you argue with a product manager, they often show you an existing product and say, “If others can do it, it means it’s technically feasible and we can do it too.” Over time, you will find that their requirements are all copied from other apps, and then you will think that if others can do it, we can definitely do it too. - —— “Lesson 06: Lean Startup: What to Do When Product Managers Are Unreliable?”
In this question, two typical issues that may arise in communication with product managers are mentioned: one is wanting to have a product that our competitors have, and the other is if others can do it, then it is technically feasible and we can develop it too.
Let’s take a look at how you should deal with these two claims separately.
First, wanting to have a product that our competitors have.
No company succeeds purely by copying others. I know you want to bring up Tencent as an example. Tencent did QQ, which, at first glance, looked very similar to ICQ, to the point that even the names were very similar: OICQ. However, Tencent made its own slight innovation by saving messages on the server side, while ICQ saved them on the client side.
It was this seemingly small innovation that allowed ordinary users, who did not have a computer at home at the time, to continue their online social interactions on different computers in internet cafes, adapting to the needs of the times. Tencent “copied” things well because they had their own innovations, including WeChat today.
The problem is not “copying”, the problem is mindlessly copying.
So, if your product manager only wants to mindlessly copy, essentially, they’re being lazy and not doing their job well. Why did competitors do this particular feature? How does this feature complement its other features? If we do this feature, how can we bring value in our product? As a product manager, you must clearly explain all of this to me.
Even if our final result is identical to our competitors’, “copying” after thoughtful consideration is a greater value in itself.
Second: If others can do it, it means it’s technically feasible.
Regarding this point, I have to say, the product manager is right. If others can do it, it means it’s definitely technically feasible.
However, we must distinguish between two things: requirements and technology.
What to do is the requirement, and how to do it is the technology. With the product manager, we need to confirm if the requirement is reasonable and whether we should do it. Whether it can be implemented technically is something the development team needs to consider, and it is not a reason for the product manager to decide.
There is also a situation where the requirement is indeed reasonable, but the technical implementation cost is very high and it takes a long time. In this case, it is difficult for you and the product manager to convince each other.
The solution is to escalate the issue and put it in a larger context, so that the upper-level leadership can decide whether to do it this way at this moment, given the existing resource constraints. At the same time, it is best for you to provide an alternative solution, so that the leadership can make a better choice.
Some classmates have asked very good questions. For example, programmers take on too many roles and are confused. I have answered this question in the column. In Lesson 《What Should You Do First When Receiving a Requirement Task?》, we discussed how to play one role well at a time. In Lesson 《Why Are You Still Stuck in the “Pit” Despite Solving Many Technical Problems?》, we mentioned that programmers should have a better understanding of different roles.
Someone asked, what should we do if our plans cannot keep up with changes? The simple answer is to rely on task decomposition, because this topic involves the content of the “Task Decomposition” module. Once that topic is completed, if you still have any doubts, we can discuss it in detail.
Alright, that’s it for today’s Q&A. Please think back, have you encountered similar problems in your work? How did you solve them? Feel free to share your thoughts in the comments. I will select typical questions and interact with everyone.
Thank you for reading. If you found this article helpful, please feel free to share it with your friends.