By Guo Yanming, nicknamed Wuxun at Alibaba.
When doing business, you need to work in a team, and in your team you need to work closely with other team members to define problems, achieve business goals and success, and increase your technical skills. At the same time, given that increasing numbers of frontend engineers are engaged in business R&D, team work and understanding business are two skills that are necessary for engineers to have in the new and evolving tech space. If you are pursuing a career that involves business development, then it is crucial for you to understand business and have these skills.
Today, as one of the leading technical experts at Alibaba, I will share thoughts about my experiences while working at Alibaba and discuss how I went from "just surviving" at work to becoming a full-blown technical expert. I hope that my story can inspire others who are still only just "surviving" at their positions, seeding the hope that they can seize the challenge to grow in their career.
In this post, I am going to summarize my past experiences and current situation by looking at three distinct stages of my past development, which I call the "survival", "development", and "refinement" stages. These stages are detailed in the infographic above.
As one of the frontend engineers serving the front-line business operations at Alibaba, I quickly learned first hand that business support work accounts for about 50% to 60% of our KPIs. In the industry generally, the frontend often becomes a resource bottleneck for the entire business. If you are a frontend engineer, I am sure that you must have had experienced the exhaustion of often handling emergency-like scenarios online.
In my first year after joining the company, I mainly worked with Tmall Global, which happens to involve both platforms and self-operated business units. At that time, the import business of Tmall was still very much in its early stages of growth, and so competition was fierce. We often had to cope with two major changes each year, while still somehow taking care of our routine work. At the same time, we had to support five major promotions and some smaller promotions each year.
I remember that, for me, one of the busiest times was Double 11 in 2017. Faced with the major upgrades of the self-operated and platform businesses as well as the various needs of Double 11, we did not have any time to stop and think. But, after that time, I gained a deep appreciation of the importance of requirement management, time management, and how to avoid online problems. Here, I want to talk about how to break out of this state based on my own experience and the experience of my team.
First, requirements can never be fully met, so there are always inevitable trade-offs. Therefore, we should always concentrate our manpower and energy on our core business requirements in order to maximize the value of our work. So, if your team is overwhelmed by a wide variety of dispersed requirements, you'll need to take appropriate measures to manage those requirements:
For example, you can convene a meeting involving your boss, PD, business colleagues, and development personnel every two weeks or so to review the progress of the project over the past two weeks and clarify any requirements that need to be dealt with next.
This will allow you to determine the priority of different requirements, decide which resources should be allocated for development, and what trade-offs should be made so that more energy and manpower can be focused on the most important business matters.
For example, if the business team is reliable or has major plans, they will generally break down their objective for the fiscal year into phased ones and determine the most important business efforts in the current year. Then, the technical personnel will make their arrangements based on this overall campaign strategy. As such, the business and technical teams will have clear and unified plans and objectives. For example, at Alibaba it's a pretty typical situation for us to focus on various important efforts while also coping with routine requirements.
In essence, 80% of core requirements and priorities can be determined during the biweekly requirement scheduling meetings. However, business personnel and PDs will often ask you to take care of something that was not considered during the meetings. Such requirements are often stated in one or two vague sentences. For example, they may say something along the lines of "This product is terrible. I want to change the format from one-by-one to one-by-two", or something like "I don't like this icon or marketing slogan font. You should change it."
The geek column written by Coolshell and Barret Lee's blog have both talked about ways to reject these "one-sentence requirements." Looking at their approaches and incorporating my own experience, I want to talk about three methods you can use to reject such requirements.
When you receive a one-sentence requirement, ask about the purpose and value of the requirement. Ask about the expected benefits and ask why this must be done to obtain these benefits. You don't even need to ask these questions to the business team directly. In fact, you need to ask these questions to yourself. You need to ask if the business team's objectives line up with the approach to solving this requirement. If the implementation approach is irrational or not the best plan, then you can know then that the requirement can be filtered out.
After asking "why", you can filter out unnecessary one-sentence requirements. Still, some of these requirements may have some value. However, the idea mentioned by the business team may not be an effective solution or involve high costs. In this case, you need to think about an alternative solution and try to meet the needs of the business team by using an existing solution or a more cost-effective solution. As such, you can provide a solution that satisfies that original requirement, while still having a means to reject impractical requirements indirectly.
When you can't say no, you can admit that the requirement is valid, but that you do not have the necessary time to address it at the moment. The key thing is that you cannot directly refuse the business team as this will make it harder to work with them in the future. You can say that you accept the requirement, but you will need more time or can only meet them halfway. Or, you can say that, if you have to address this requirement on their schedule, you cannot ensure the performance or quality of the project after it is launched. This will force the business team to consider the necessary trade-offs.
Of course, requirement management is only one part of a technician's job. It is also necessary to improve your development efficiency and quality. I think everyone has a deep understanding that we should try to minimize the amount of low-quality repetitive work we need to do. For example, you can improve your productivity and that of your team by developing unified technical systems and encapsulating reusable components and productivity tools. Even if you are busy, you must consider and perform these tasks. If you neglect them, this will only increase your workload down the road.
I want to avoid a misunderstanding here. I'm not encouraging everyone to reinvent the wheel. As a member serving the business team, I recommend that you focus on the rapid customization of existing technical solutions in your industry or group to meet your business needs. For example, we customized our own Magic Stone module for international projects with the help of Shuwen team's Magic products to meet the needs of international marketing scenarios. At present, we have provided good solutions to similar module requirements in major promotions.
What's more then? We must also focus on quality. It is necessary to take the time to identify the products and code that often cause online problems and redesign their solutions. During international work, I usually do this on the weekends. This restructuring allows us to completely solve problems so that we will not be overwhelmed with calls in the middle of the night for fixing these problems. The remaining methods and techniques are to increase quality assurance and the necessary online monitoring during the development process.
Often, we tend to think that our job ends after the project is put online for testing, but this is a bad habit. Over time, we will be reduced to a project resource role in the eyes of our partners and become passive in solving problems. In fact, we should carefully analyze the business data and results after the launch and summarize our findings. In fact, doing exactly this provides the following benefits:
While paying attention to the business data, you will be able to adopt the critical business perspective and judge whether the value of a certain feature meets expectations. When a feature does not meet expectations, you can work with the business team to analyze the data funnel and find the problem. As such, the result of all our work does not become a one-off task, but rather something much more than that.
Summarizing the results can help you to identify your shortcomings in the project, discover problems that hinder the progress of the project, and learn how to do better in the future. This also improves the upgrade efficiency and quality of subsequent projects. For example, was rework required due to a failure to understand requirements? Or, did the project suffer from poor communication between team members or poor collaboration? And, last, was the solution you designed a rational, well thought out one? Asking yourself these questions will allow you to provide better solutions next time.
By looking at the data and summarizing the results, you can determine what types of requirements are reliable and what sort of business personnel are reliable. You can also identify the business personnel who always demand resources but do not produce good results after launch, so the next time they ask for something, we can be a bit more skeptical.
These are only some of my experiences for handling a spurt growth of business requirements. Generally speaking, although business support work accounts for most of our KPIs, we cannot lose ourselves in meeting such business requirements. We must set aside time to reflect on our experiences and proactively provide more suitable support for our business operations.
Of course, it is not enough to proactively support the business team. At the same time, you need to find ways to develop and grow personally. Let's talk about this second stage, which I call "searching for ways to develop."
In this stage, you will find that, although you can provide better support for business and take time to reflect on your work, it is difficult for you to identify the proper paths for personal improvement. In particular, every time you formulate and set out KPIs, you will find that, other than business support objectives, you do not know what to do. In my opinion, at the frontend of the business team, we should really try to consider things from two perspectives.
Business empowerment requires us to formulate technical plans and solutions that suit the business plans. Therefore, I suggest that, starting from the beginning of the fiscal year, you should talk with your boss, your business PD, and the business team in order to learn about the key focuses in the year's business KPIs and the expected planning and implementation approaches. Moreover, consider what you can do to help the business team achieve its KPIs based on your own situation and the team situation. In fact, this is not a simple task. I am still trying to get better at it. I have two points I would like to share.
Many times, in fact most of the time, you may be presented with individual difficulties and business requirements. However, you should not focus on each issue in isolation, but you should consider them in an overall way. For example, SEO pages are very sensitive to performance. Business personnel often tell us that our SEO has problems that need to be fixed. However, solving these problems one by one may not benefit the business by that much of a margin whatsoever, nor will it help us improve our own skills. Instead, if you were to consider the full situation, the entire picture, you would be able to discover that the purpose of SEO page optimization is to improve the indexing and ranking of SEO pages.
To improve the indexing and ranking of SEO pages, we can do more than frontend performance optimization, for example, you could optimize the keywords and long-tail words, use Google's AMP technology to improve SEO pages, reduce page crawling time, and improve the crawling rate. As such, you can extend from a specific point to a more high-level solution. This in turn can allow you to formulate more effective and comprehensive solutions to empower the business.
Most of the time, it is not enough to meet the KPIs placed in front of us. We also need to understand the long-term thinking and likely plans of the business team. For example, we are currently working on a very important project for Alibaba. The project deadline is very tight. The frontend needs to complete 300 man-days of work in only 48 business days, which is a risk in the project. The top priority of business and technology personnel is to ensure the project is launched on time. Common sense tells us that the objective of planning must be about how we can launch it on time. In the future, this project may also need to be implemented for other sites following this model. This means we also need to ensure that the technical solution can be replicated. A replicable solution will reduce the frontend work for new sites and help us quickly launch the project on international sites in a modular manner. This is a second dimension we need to consider. By looking at all the possible near- and long-term problems, we will see that what we actually have to do is to create a complete frontend solution for international sites. This shows that we must constantly explore and define problems and find appropriate solutions. In this way, we can find better ways to empower our business.
The technical experience perspective is a familiar perspective for frontend personnel. In the business team, the frontend personnel can do more things, such as improving R&D efficiency, optimizing the performance experience, testing and implementing new technologies, and integrating technologies with terminals. If you want to pursue this direction, there are several things I think you should focus on.
When you need to develop a product-based solution, a tool, or a framework, it is best to first conduct research within our own company and in the industry to see how your colleagues and peers have solved similar problems. Try to innovate or participate in co-construction by taking advantage of the work that has already been done by others so you don't have to reinvent the wheel. I recommend that you pay more attention to the plans and dynamics of the company's frontend committee and pay more attention to the information shared within and outside the company. Then, participate in co-construction and sharing when you find projects you are interested in or when you address similar problems and scenarios.
In frontend performance optimization, we don't talk much about common operations such as resource compression and combo requests. Instead, we look at deep optimizations highly integrated with the client, such as Tmall's previous Webbased solution. This is an example of a deep solution. In the past, when I was working on Global Lite solutions for international performance optimization, I adopted a comprehensive perspective in my planning and thinking. This is an example of a broad solution. Therefore, the depth and breadth of a planned solution determine its potential benefits. I have a few ideas about how you can improve the depth and breadth of your solutions. First, go one step further. Think from the perspective of upstream and downstream teams and partners and work with other teams and roles to explore possible solutions. Second, think about the desired final result, that is, what the solution ultimately seeks to accomplish. Then, think about how to implement the solution given current conditions.
Consider the full costs and benefits of your solution. This gives you a way to assess its value. When assessing costs and benefits, you can look at costs in two ways. The first is our normal understanding of costs, which include the number of days of work and the funds expended. Another way to look at costs considers economic opportunity costs, which are the value given up by doing one thing as opposed to another. The benefits of a solution include how much it increases productivity, how much it improves business data, and how much it improves performance. I recommend using a comparative method to highlight the benefits.
If you want to incorporate existing solutions and capabilities in order to drive further innovation and customization, then you should provide the results and solutions of your project so that others can build on them. For example, you can expand the solution to cover other industries and business units in the company, allowing them to solve similar problems. To do this, you can make your work open-source, apply for a patent, or participate more in information sharing within and outside the company.
Business empowerment and technical planning deserves ongoing exploration and practice. I recommend that you communicate more with your boss and experienced colleagues in your team. Generally, they have a lot of experience and can give advice to help you better think things through. And, in fact, sometimes these exchanges can be quite eye opening.
Sometimes, when we find a new direction or opportunity, we may already have a general idea and plan in mind. At such a time, we may want to start going down this new path right away. The risk in doing this is that we may stray off course, resulting in a final outcome that is not satisfactory. Here, we need a set of theories and methods to ensure the accurate, complete, and high-level understanding of the problem. Are there any methods and procedures we can use? The answer is yes. The answer lies in developing a structured way of thinking and acting.
The first aspect of structured thinking is that you'll need to establish core objectives. When facing a problem or a challenge, we need to establish core objectives. To give a simple example, if we have a slow project compilation speed during development, our objective can be defined as solving the project compilation problem. Of course, though, we can also go up a level and consider how to improve the efficiency of the entire development process. Now, our core objective is to improve the efficiency of the entire development process. In a word, we go up one more level so that we can increase the value of our work and expand the coverage of the problems to be solved.
Another thing you need to do is to break down broad objectives. Here, you can break down large and complex objectives into smaller objectives based on different scenarios and logical sequences such as time, structure, or degree. For example, if your objective is to improve development efficiency, you can break down this objective according to the development time sequence: local development and debugging > Joint debugging > Pre-release verification > Release and launch. Note that, for this sequence, the new sub-objectives after the breakdown should be mutually independent and complete.
Now, you'll need to sort out the sub-objectives. You will never have enough manpower or capabilities to do everything you want to. Therefore, not all sub-objectives are worth pursuing at the current stage or if they involve high costs. We need to determine the most important sub-objectives.
I suggest that you read the book The Pyramid Principle, which I am currently studying myself, and other books about career development. In addition to technical knowledge, this will allow you to better understand thinking methods, project management, and interpersonal communication. Of course, books and articles only provide theoretical knowledge. You still need to put these ideas into practice at work to test their real value, which I am also working on now. I hope to share more experience with you in the future.
2,599 posts | 765 followers
FollowAlibaba Clouder - May 14, 2018
Alibaba Clouder - April 3, 2020
Alibaba Clouder - March 31, 2020
AsiaStar Focus - June 30, 2022
ApsaraDB - November 28, 2019
Alibaba Clouder - January 22, 2020
2,599 posts | 765 followers
Follow
Container Service for Kubernetes
Alibaba Cloud Container Service for Kubernetes is a fully managed cloud container management service that supports native Kubernetes and integrates with other Alibaba Cloud products.
Learn More
ECS(Elastic Compute Service)
Elastic and secure virtual cloud servers to cater all your cloud hosting needs.
Learn More
MaxCompute
Conduct large-scale data warehousing with MaxCompute
Learn More
OSS(Object Storage Service)
An encrypted and secure cloud storage service which stores, processes and accesses massive amounts of data from anywhere in the world
Learn MoreMore Posts by Alibaba Clouder
