What AI Taught Me About Management

Towards the end of 2017, at the invitation of someone well known on Zhihu, I shared some thoughts with a group about how a machine-learning way of thinking might help us. If what I said then was a reflection on how the specific habits of thought and behaviour in that field had changed my own thinking, then after a year or so of trying things and gathering practical experience, I have taken rather more from the frameworks of machine learning than from its habits.

What I want to talk about here is how the three elements of a machine-learning project map onto ordinary work and life.

In a normal machine-learning project, before anything begins, we usually have to settle three things:

The objective. What is the loss function — or, what is the function we want to optimise, and to what point do we optimise it?

The model. What kind of model do we choose; which cases do we run experiments on?

The search strategy. By what method do we find the “best” optimisation. “Best” here covers both whether we can find the optimal parameters and the cost or efficiency of the search itself.

Think about the tasks in your own job, and don’t these three words sound extremely familiar?

The objective. Why are we doing this, what result do we want, and can that result be expressed quantitatively? Thinking about the objective matters because desire is unlimited and resources — time, money — are not. When we invest in a stock, prepare for a negotiation, try a new line of research, run a marketing campaign or organise an event, the objective had best be explicit, simple and measurable.

Why think carefully about it? Because it determines whether we can review effectively afterwards — if we do not even know what we were trying to achieve, how do we conduct the review? And more importantly, it determines when we stop. Digging carefully into the objective and finding the most fundamental one keeps us from getting excessively tangled in some intermediate result; and when we do get stuck at an intermediate stage, a clear final objective helps us find a great many alternatives. Say we want to enter an unfamiliar market and hope to reach an agreement with company A quickly in order to gain a competitive position there. Then during the negotiation with A, we probably will not tie ourselves in knots over how the benefits are divided.

The model. To reach the objective, what kind of model do we want to use? For a new line of business, whether the core is R&D, engineering deployment, distribution channels or something else entirely dictates a different style of management. For personal development: a course, self-study, or a study group? If self-study, is it video, books, or scrolling Zhihu? In practice we usually implement the first solution we find. Thinking carefully about your model in advance lets you properly evaluate the options actually available to you, so that when one road turns out to be blocked, you can genuinely plan your way out.

The search method. When we have several models that might reach the objective, how do we find the most suitable one? From the automated machine-learning point of view we can do grid search — trying them one by one down a list; random search — trying them at random; or heuristic search — choosing the next candidate based on feedback from the last attempt. In real matters, which one you choose, and which “model” you try first, is usually shaped by the nature of the problem and the resources at hand.

Take the market-expansion example again. If the objective is to develop new technology on the basis of an existing market so as to raise the company’s influence and competitiveness, we might imagine these options: buy existing technology, develop it ourselves, or develop it jointly. Which one we pick sends us back a step to look at the objective again. Over what period does it need to be achieved? Do we have requirements on ownership of the technology? What quality do we need from the new technology, and can existing tools already reach it? If time is short and independence is not a strong requirement, buying may be a good choice. Conversely, if we want to build a higher technical moat, or if no good existing work on that technology exists, developing it ourselves may be the good option.

So in terms of search method: for the first case we would probably search existing solutions first and put the weight of the work into the partnership or purchase negotiation; for the second we would probably first assemble the research capability and assess the feasibility of doing it ourselves. And of course, if the finances allow, running both in “parallel search” is also an option.

The Pragmatic Programmer has a line I think is quite right: there is no perfect project. So when we consider a project’s objective we must fold the quality requirement into it as well — the completion date, the final quality standard, and so on.

Step back one more time. If the objective is to raise influence and competitiveness, is developing new technology the only “model” that reaches it? Would providing a better service do? Whether we buy or build, we may hit an obstacle we cannot get over. If our list of models has “provide a better service” on it as an option, I am confident we will be far more composed when we run into difficulty.

These three are best written out on a sheet before starting anything, thought through, discussed and listed one by one. Unfortunately, in a great many cases we begin with only a vague idea of why we are doing something and how, and only double back to think it through and fill in the gaps once we hit a problem. I am certainly not suggesting you freeze in place in order to complete a framework. But give yourself a quiet interval and work through what you are about to do along these lines. It may not be comprehensive — that is fine. Having gone through it, not only will the work go more smoothly, you will also spare yourself a lot of unnecessary anxiety. Filling in blanks is always easier than writing the essay.