By Qu Kuilin, nicknamed Disu at Alibaba.
Naturally, after any team of engineers are faced with a series of challenges, they will have questions. Straight away, team members will raise questions like these:
When we hear people say that "thinking is not enough" or "think more," what they're really talking about are these sorts of questions.
So, what's the solution? How do you effectively answer these questions? Well, in this article, Kuilin Qu, as a senior frontend expert at Alibaba, will share his experience on how he solved these three major problems to become a better engineer.
Although a scientist may dedicate a lifetime career to research, the reality is that his or her time is extremely limited when it comes to actually doing research. However, the big dilemma is that there exist countless topics worthy and in need of further research in the world. And so, if you select research topics just because they are a little interesting, then your life will be over before you can do something really important, said one very wise Nobel-winning scientist, Susumu Tonegawa.
This is true for software engineers as well. The fact is before answering this question, we need first to understand one important concept: What is a valuable issue?
My understanding is any issue that concerns an important, pressing topic and leads to a critically important and quality answer is valuable. But what does that mean? Still not getting it? Well, think about the issue this way then: consider whether this issue actually exists, consider whether it is necessary enough to solve this issue in the immediate future, and consider whether the solution to this issue is feasible.
Then, if you're thinking about things this way, then you'll also know that: if you want to find such issues in your business, you'll need to first understand your business strategy, as well as the method and positioning behind your business. Preparing this prerequisite information is a big challenge for engineers, which is probably why we tend to ask this question.
Most software engineers are engaged in front-line development. Therefore, their understanding of business may be limited to what is immediately below their eyes and what they are doing right in the moment. But, a lot of information out there is the information that has been filtered several times by someone else. What you get may be a task and the reason you are doing this task. But, the reality is that, at its core, this understanding is not as good as the understanding that the original strategy maker him or herself had proposed.
So, what we can draw from this is that not all information is also equal. Some bits of information are better than others. Therefore, when we get a new task, a new message, we need to collect information, sort out and summarize the information, and analyze the issues. Only when we do this can we get at the core of the issue and know what's valuable.
So, now in this section, I want to talk about the process of collecting information. Actually, this process is sort of like information science, if you will. The best way to collect information is to attend the kickoff meetings hold by the leaders of your business units. Each type of kickoff meeting will break down the corresponding strategy and thinking behind the general business plan and the corresponding tasks to follow. These meetings are presented to members of the business unit or the concerned department. Although we may not personally participate in the brainstorming process, we will understand the thinking behind it if we attend the meeting. So, as a general rule of thumb, you should always remember to take notes.
After obtaining this first-hand information, we'll need to start collecting external information and organizing everything together. Here, I often use Ali-learning for this.
Alibaba's got two in-house learning platforms, which are the Ali-learning business repository and the ATA technology repository. Of course, you can also collect such information from many other external channels. There are loads of different sources out there. In short, we need to collect this information just like how a product manager would do. At Alibaba, we also encourage students of different business units in different fields to communicate with each other, not just by chatting offline but also by asking questions online. In fact, at this point of the process, it can be a smart idea to use websites like Wikipedia or Yahoo Answers to give you a bit more background information and a better understanding of what's going on. In China, two popular websites of this kind are Zhihu and Baidu Baike.
The information that we obtain from different sources can be scattered and therefore piecing it all together can also be intimidating. You may think to yourself: how can we process and integrate it into our own thinking process? Well, first, to answer this, information cannot be simply piled up. We need to figure out the main threads before doing anything else. A principle called the MECE principle can be helpful for this. It can be used for breaking down the information. In short, this principle encapsulates the idea that the entire body of information can be grasped through classification that is both mutually exclusive and collectively exhaustive. The information of the logic tree you will create will be matched with the requirement-based scenario you're aiming to figure out. You can try to use different entries on the C-end and the B-end to reconstruct the requirement-based scenario. In this process, you can combine certain methodologies, such as deductive reasoning and inductive reasoning to refine the problems and challenges involved, which will ultimately help you understand the business unit's strategy.
Meanwhile, you can also break down your strategies into the corresponding projects from your own perspective. For example, last year at Alibaba I personally analyzed that two unitary traffic patterns served as one of the main problems facing Fliggy in the C-end. Adding to this, Fliggy's B-end supply chain was not mature enough, making it impossible to provide vendors with a more substantial service experience. The reason behind the limited category intersection of Fliggy was that its vertical services were isolated from each other.
When we figured out these three issues, we couldn't start working straight away. We still had to refine what exactly was the core value involved these issues. Otherwise, we could not link up the final technical output to the business results after doing all of the necessary work. Thinking isn't a matter of brute force. Your work does not rely on physical strength alone.
So, where exactly is the work related to your role then? Being on the frontend, one the edge has one big advantage, and that is that you are close to the product and to the end user. Therefore, you can understand the basic presentation modes in a more abstracted and systematic way through the product prototype.
Considering the construction of a traffic system as an example, we need to segment users. Reasonable methods can use and rely several different traditional models like RFM or AARRR, and their variants to settle on the technical platforms or products we'll have to undertake. For example, in traffic system construction, after we think about segmentation, we divide users by their willingness to purchase, and also divide them into users that are either outside or within the Alibaba ecosystem. Then, we design two platform products accordingly.
As the project initiator, we need to pay attention to every piece of the puzzle. Therefore, we need to first find the corresponding business party to "sell" our thinking to others. To find people with the same goals, you need to know who your business party is and what are they responsible for.
When it comes to this sort of thing, my method is relatively simple. I look directly at the functional division in terms of operations. I want to be clear on what the person is responsible for and the KPI that the person is responsible for achieving. In addition, you want to be looking for people with your corresponding project director. Generally, the most direct partner is the person who can help you deal with the problem of business and technology convergence.
After finding all the right people you'll need, you want to prepare a kickoff meeting to determine the priorities involved with all the requirements of the job. And then, when resources are limited, what should we do first? The answer is simple: Unimportant parts can be left until later, prioritize the core features of your product.
Generally, the highest priority item of platform products is the general functions needed for the operation of that product. Therefore, you'll need to confirm with your partners what functions they think are the most important, and then start there.
Alibaba Group is already a very big institution. Basically every thought that you are thinking has probably already been thought about before, so it's not your time to try to reinvent the wheel. Actually, the same thing goes for small companies as well. Many small companies will use open-source technologies, rather than creating their own proprietary solutions because there's no need to reinvent the wheel if it can work just fine for your business.
When starting work on the project, if it is a platform, we need to first separate the core functions. These core functions depend on whether someone in the group is already doing it or whether there is a mature solution. Looking into these problems helps to avoid repetitive development, so that you can solve your most urgent core problems as soon as and as directly as possible.
At Alibaba Cloud, the simplest and most direct method is to search some of our internal technical repositories and knowledge bases, which for us is ATA and Yuque, to extract keywords and find the key person who is doing things. That is, involved in this process is the fact that you've just got to believe and know that you are not the first person to think of this issue. Some general issues definitely already have general services provided within the group. If they are not provided, a more mature solution probably will apply already.
Even if no solution has been established within your company, this direction is also cutting edge in the industry. If you encounter such an issue, you can first see whether it is possible to bypass this issue. If it is impossible to bypass this issue, you can try to find a basic team that is suitable to work and build on this issue together. And, of course, there may also be external paid solutions for purchase and use.
Regardless of the solution, you still need to ensure that the business wins in the end. Business engineers need to think about what value you can bring to the business. Therefore, your core value is not to handle and resolve very complex technical issues, but rather to use your technologies to increase the value of your business.
Therefore, one big message I want to share here is that the value that business engineers bring to a business is leveraging a technology or model to solve very complex business problems, and this is a technology of universal value.
One of the most important things you need to develop is foresight, which I like to call the ability to look into the future while standing in the present.
You need to focus on the present and even more so on the future. Not only does technology need to be oriented to the future, but the industry as well. Stand in the present, and think about how to solve the biggest problems encountered by the business at present and in the past. And think about the opportunities for overtaking competitors in the future.
For example, if Alibaba's Fliggy wants to catch up with a competing product in the same industry but cannot compete with this competitor in terms of the amount of resources invested in it. Ultimately, the best result may be to reach a tie with its competitor. Therefore, we need to find the fulcrum for winning in the future industry, the time to focus and the energy for pushing forward these key nodes, and use a global strategy to break through. And, Fliggy also needs to be prepared for internationalization. In this part of the puzzle, we can also draw on the technical experience that we have found from others. To help us focus more on our business, we could say that last year's platformization paved way for our business.
This last question is a bit of a trick question. If we clearly understand the business from the beginning, and if our execution has not deviated and has stayed focused on our original goals, it is unlikely that our final business results cannot be obtained.
So, ultimately, there is only one question: How is technical value embodied when we obtain the business results?
Starting things off from my own experience, my colleagues have often ask me if there's no need to reinvent the wheel but at the same time everything's already been done, so then what is our value in the end. And my answer to this sort of question has always been that a team that works on basic technology will continuously dig into the basic engineering and technical fields. But, they also need to focus on the transition from discovering the technological value of their creation to finding its business value.
Effectively, the main issue almost invariably is that the business scenarios, which should have been consider long ago are lacking. So, collaborating with the business team is important and is complementary to the technical stuff we do. Doing so enables us to get business results and also experience the growth of our own technology.
But then again when I think back to these conversations, it is clear that there are also many internalized, unspoken questions. For business engineers, the core of our focus is to ensure that the business wins, of course. So, if that goal is not met, the engineers can end up being a bit too "self-indulgent" in problem solving. Therefore, what we need on the business side is to have a technical perspective to see what other teams or external teams of the company are doing, and actively communicate to make this situation a win-win.
If no one else is doing it, let's go and ask someone to stand up and see whether this input-output ratio is reasonable. This is also the value question of the topic and the solution that we mentioned at the beginning of this article. Are these problems common to other teams in the company and can we bring them value by solving them? Of course, given the question of finding technical value in the business, in fact, there is a relatively clear answer here.
The most important thing is to think clearly about the "why" so that we can do the most correct thing. Only by doing things this way can the business value created by resolving this issue be clearly located.
That is to say, the best engineers must understand the product and how it is a piece of the business puzzle.
To depart from this theme for a bit, a colleague at Alibaba asked me whether the business frontend would be eliminated in the future. This colleague asked this question because the lowcode/nocode we are doing may put us out of a job. Although an interesting question, it is not productive. It simply a pessimistic thought that forgets the how and why behind why the frontend developed in the first place.
For the current direction, we still need to think about how to solve low-quality code construction and inefficient repetitive work that occupies most of an engineer's energy, and free up an engineer's time to be able to improve the overall development efficiency of the company. In the past, the frontend belonged to the application layer, or specifically, the appearance, presentation, and rendering side of the top layer.
The application layer has been constantly changing and evolving over the past few decades, and so the profession has also evolved with it. This evolution has gone from the earliest GUI engineers to the frontend and client-side web development engineers of today and recent past. During this transformation, the application layer and presentation layer have been constantly changing, and therefore frontend professionals feel that they are always acquiring new knowledge.
However, this development process actually follows a pattern. Although the application layer is constantly changing, it is essentially developing in two major directions. One is the improvement of engineering efficiency from the engineering perspective, and the other is graphing and image research from the user perspective. At present, the two directions also have a very complex and large tree of knowledge systems, which are still being extended.
Meanwhile, with the rise of machine learning, the improvement of hardware performance and network bandwidth, and the upgrade of visual presentation devices, a new round of technological disruption is possible. Therefore, from this perspective, the frontend will not disappear in the future, but instead will only exist in another form. However, engineers who do not learn will disappear.
In conclusion, I want to say that when you come to a new business, do not rush to get these two results on the business and technology side of things, but rather take your time to get the flow of things.
Before anything else, we need to see where the business is in the large picture of things and understand how it is associated with other businesses. We need to collect information and issues, look at these issues in depth, and find business pain points by communicating with others in the company.
In this process, we need to collect the issues first, think about them, and then work on business projects. We need to have targeted thinking. Lock in on and track our goal, and modify our path according to the actual conditions we find and keep doing so until we hit our eventual end goal and the results of it.
Actually, I have written a lot, and also sorted out and summarized the methodology of how I do things. In all of this, I also said that it is best not to let the business push you along, but that it is most important that you bring the business along with you on your journey.
Initially, "bring" may mean that the business moves in the direction you understand after you learn about how the business works. However, through a long stretch of training and self-learning, you may find that this part actually also involves a bit of implementation. Finally, you need to realize that it is really you who is leading the industry and driving the direction of the business forward through technological innovation, rather than the technology itself.
This is my third year at Alibaba. Although I had been working for almost eight years before I came here, I grew far faster during my time at Alibaba than I had before grow at my previous positions.
I have become a new person these three short years, so I would like to give myself a message now: I hope that in the next five to ten years, my thinking will have risen to a whole new level. I also welcome everyone's comments and feedback. All criticisms are welcome because encouragement does not help reveal the issues.
Finally, I also have some related books to recommend to you, which offer more details about some of the preceding parts. I hope they will be helpful: The Pyramid Principle, Thinking, Fast and Slow, Influence, The Willpower Instinct, and Agile Development.
PS: DingTalk is recruiting P7-P8 frontend, client-side, and Java wireless server-side engineers who are based in Hangzhou or Beijing. You are welcome to apply! If interested, contact kuilin.qkl@alibaba-inc.com
yichao - March 31, 2020
Apache Flink Community - June 6, 2024
Alibaba Cloud Community - September 13, 2021
Redspan - September 30, 2022
Alibaba Clouder - February 14, 2020
Alibaba Clouder - September 28, 2018
Content Delivery Solution
Save egress traffic cost. Eliminate all complexity in managing storage cost.
Learn More
MaxCompute
Conduct large-scale data warehousing with MaxCompute
Learn More
Architecture and Structure Design
Customized infrastructure to ensure high availability, scalability and high-performance
Learn More
Global Traffic Manager
Allows you to access the nearest node based on the Domain Name System (DNS) architecture.
Learn More
