18 Demand Management: What to Do When Too Many People Assign Tasks to You? #

Hello, I am Zheng Ye.

In the previous lecture, we talked about demand decomposition. I used user stories as an example to explain how we should break down large demands into smaller ones. But is everything fine once the demands are broken down? Obviously not. Today, let’s discuss another topic closely related to demands: demand management.

Demand management? The initial reaction of many programmers is usually that this is either the responsibility of the product manager or the project manager, and has nothing to do with them. I know many people think this way, but what I want to say is that, even if you don’t understand how demands are managed, even if you have conducted demand decomposition, the end result may still be that you are deeply stuck in a quagmire without knowing it.

Why do I say this? Let me tell you a story that happened around me.

The Most Brain-dead Approach to Requirements Management: “Because the Boss Said So” #

Once, we organized a “complaint session” for the heads of various teams to openly discuss the problems they encountered. The leader of a development team said, “The work backlog on my end is too heavy. Every product manager tells me that the release dates are already fixed, but I have limited resources and just can’t handle it.”

Out of curiosity, someone asked, “Are all these tasks equally important?”

The team leader shook his head helplessly, saying, “They all say their own tasks are important.”

“Why do they think their own tasks are important?” I also asked a question.

The team leader said, “They told me it’s because the boss said so.”

Doesn’t this sound like a familiar situation? A bunch of tasks coming your way, simply because it’s a word from the boss. Are all our bosses so unreasonable? In fact, this is probably not the case.

Based on the phrase “because the boss said so,” we can conclude that product managers lack the necessary understanding of requirements management. As a result, the development team mindlessly accepts the requirements and is almost crushed by them.

At this point, the CTO spoke up: “Verbal agreements don’t count. If they say it’s because the boss said so, then let the boss send an email to confirm it.”

I agreed with the CTO’s approach, but I wasn’t sure about the team leader, so I asked him, “Would you have the product managers do this?” Sure enough, he hesitated.

“Product managers might not say it like that to the boss. Then you go and do it,” we made a suggestion to him. Obviously, he hesitated even more, as he would have to face the big boss.

In response to this situation, we came up with a solution: “If you’re worried that the product managers won’t do it, you can directly send an email to the boss, with the CTO copied.”

“Yes, that’s a good idea,” the CTO took on the responsibility. The team leader immediately felt reassured.

Doesn’t this feel familiar? In fact, if we extend this story a little further, it applies to us programmers as well.

As programmers, we often encounter a scenario where a requirement comes in without clear specifications, and your weekend plans get ruined because your team leader will tell you, “Because the boss said so.”

There’s a joke in the software industry: When is the ideal delivery date for building software? The answer is yesterday, followed by as soon as possible. Everyone who submits business requirements wishes that the requirements were already completed. But reality is often disappointing, so they can only hope that the requirements will be implemented as soon as possible.

What if we waited until all the requirements are fully developed before going live? That’s what the so-called waterfall model did in the past. Twenty years ago, this approach still had its place, but today it’s clearly outdated.

We’ve discussed how to build software many times, and the key point is that there is too much uncertainty in the world. We can only develop a “portion” of the product and release it.

This raises a question: which “portion” should be prioritized for the release? We must make trade-offs between grand ideals and harsh realities. This involves the essence of requirements management, which is essentially a matter of prioritization.

Prioritization of Needs #

“From the boss” is the simplest answer to determine priority and also a way to shift responsibility. The implicit meaning is that if the pressure is high, it’s not my fault, blame the boss. “From the boss” should not be the indicator of priority.

First of all, we need to understand that priority can be discussed. Most people who can be bosses are reasonable. But in order to have a discussion with the boss, we need to know how to reason. We need to prepare some basic knowledge in order to discuss how to prioritize work with different levels of bosses.

Why do we need to differentiate priority? Because time is limited, there is a ceiling to how much work you can complete within a limited amount of time.

How to make the most of limited time is actually a problem of time management. Therefore, we can fully utilize some excellent practices in the field of time management to help us discern priority more effectively.

When it comes to time management, an effective time management strategy is the Eisenhower Matrix, which was developed by former US President Dwight D. Eisenhower.

This tool was further popularized by Stephen R. Covey in his famous book “The 7 Habits of Highly Effective People”. You may not be familiar with this name, but you will understand when you look at the image below.

- It divides tasks into four parts based on the dimensions of importance and urgency: important and urgent, important but not urgent, not important but urgent, not important and not urgent.

Let me explain using some examples from a programmer’s life. Online system failures that prevent normal operation belong to the category of important and urgent tasks. If they are not resolved immediately, they will affect the company’s normal operation. Upgrading and transforming the system is important but not urgent: if it is upgraded, the performance and maintainability will be improved, but if not, it can still be used for a while. Some temporary tasks fall into the category of urgent but not important, while browsing social media falls into the category of neither urgent nor important.

According to the concept of time management, important and urgent tasks should be done immediately. Important but not urgent tasks should be the focus of our energy. Urgent but not important tasks can be delegated to others. Not important and not urgent tasks should be minimized.

The biggest change in thinking that this matrix brings us is the realization that not all tasks are equal. If we don’t focus on important tasks, they may become urgent tasks in the end.

For example, if we neglect the upgrading and transformation of the system, the increasing technical debt will lead to more and more problems, and the speed of implementing new requirements will become slower. Finally, a few seemingly insignificant requirements are enough to make the team work overtime and face complaints.

Applying this mindset to our practical demand management, you will find that the priority order of various demands faced by the team is basically arranged according to the degree of urgency, but are they really important?

If you throw this question back to the demand proposer, I can almost guarantee that their answer will be that the demands they propose are important. One possibility is that they also can’t differentiate between important and urgent, just like how we are sometimes confused.

In such a scenario, what we need to do is ask more questions. In my article “Lean Startup: What to Do When Product Managers Are Unreliable”, I mentioned that by default, all demands should not be done until we figure out why we need to do them.

Similarly, demands are not so important until the product manager can explain why they are important, especially why they are more important than other demands. If a product manager cannot prioritize several demands, you can explain the content you have learned to them.

There is another possibility that the demand they give you is indeed the most important content in the context of their work. However, when there are multiple sources of demands, how do we determine which demand is the most important? Then, it is time for the boss to step in.

Standing in Front of the Boss #

In the article “Why Are You Still Stuck in a ‘Pit’ Despite Solving Many Problems?”, I have mentioned that we should not limit ourselves to the role of a programmer. The true difference lies in the different work contexts of different roles. Everyone works within their own context, which also limits their perspective.

Imagine two product managers appearing before you: one tells you that the company wants to expand in a new direction and this feature needs to be done, while the other says that the company needs to further profit and that feature must be done.

From your perspective, they both seem right and both sound important. But the harsh reality is that if you take on both tasks, you will be overwhelmed and unable to complete them.

So what can we do in this situation? Step out of this context and into a larger one. If you can’t judge which requirement is more important, ask a higher-level boss to decide.

With the knowledge you have built up as a foundation, you can finally stand in front of the boss. You can tell the boss: my resources are limited, so I need to prioritize these two requirements and see which one is more important. My context is limited, so I need your help in making a judgement.

The boss will tell you the origins of these two requirements. The need to expand profits is because competitors already have it, and customers are asking for it. Not doing it will affect customer relationships, especially as the new fiscal year is approaching and the next stage of contracts will be affected. On the other hand, the idea for the new business arose from an inspiration at an upscale gathering one day. The boss is unsure how much revenue this idea can bring, so he wants the product department to give it a try.

After hearing the boss’s information, you immediately understand the importance of these two things, and you also know how to deal with the two product managers.

The boss’s context is larger than yours because they have more dimensions to consider when looking at this problem. So, what seems like an extremely difficult decision to you is easily resolved with just a few words from the boss. To them, it is not a big deal at all.

If you have read Liu Cixin’s “The Three-Body Problem”, you will know that this is actually a “dimension reduction attack”. Another term you may be familiar with is “big picture thinking”. I often tell people that when you can’t understand something as an employee, try looking at it from the boss’s perspective and everything will become clear.

I encourage every programmer to work in a larger context, which means gaining more dimensions of thought. And today’s main point is to tell you that when you have limited context, you can introduce new elements, such as seeking the boss’s opinion, to expand your own context.

Going further, we must also constantly expand our own context when doing things for others. This is what we often refer to as broadening our horizons.

Many so-called life dilemmas are simply caused by limited perspectives. For example, if you feel that there are always people in the company who are better than you in terms of technology, it is better to broaden your perspective and compare yourself to the industry as a whole. Because you are working for your own career, not just for a company.

Summary #

After decomposing the requirements, the most important step is to prioritize them. There are many ways to prioritize, and we can borrow from time management methods by categorizing tasks based on importance and urgency into four quadrants. We should focus our energy on important tasks rather than using urgency as the sole criterion for prioritization.

When we decompose requirements into smaller chunks, we also break down the original context. To effectively manage requirements and determine their importance, one way is to regain the lost context. If we cannot judge the context ourselves, a good approach is to introduce a larger external context.

If you can only remember one thing from today’s content, please remember: do the most important things as much as possible.

Lastly, I would like to ask you to share any problems your team has encountered in daily requirement management. Please feel free to write down your thoughts in the comments section.

Thank you for reading, and if you found this article helpful, please consider sharing it with your friends.