How to Teach Employees Independence. Part 2

At any level you have to synchronize goals

The goals of the company, of the clients and of the specialists need to be synchronized. Let’s take an example:

A certain studio builds corporate websites on WordPress. Its goal is long-term relationships with clients. The clients’ goal is for the site to look good, to solve marketing tasks and to come cheap. And the developer wants to work on interesting problems, learn from the best, try out new technologies and, say, build the site not on WordPress but in some modern framework with fashionable programming methods, so there’s something to talk about at a tech conference.

There’s a conflict of goals here, at the very least between the developer and the client. Because if you take a different framework instead of WordPress, spin up Docker containers, write everything as a set of microservices, then in the near term the client gets a site that costs more and may well work worse than the WordPress one. For instance, it may turn out that the WordPress site handled the job perfectly and came with a pile of handy little things written earlier, which nobody got around to writing for the site in the fashionable framework, because there were more pressing things to do.

The company’s goal: Long-term relationships with clients.

The specialist’s goal: To work on interesting problems.

The client’s goal: A good-looking site, cheap and fast (this is an example of a bad goal, one that will lead to desynchronization later).

If the goals are different, there will be problems. Suppose the company hands the task to a manager who gets a bonus off the profit. The manager will pick the solution that leaves the client happy, but then a staffing risk appears — the developer will be thinking: “Why am I even sitting here, where’s the growth? What is going on? Goodbye.” If you hand the task to the developer, he’ll be guided by his own goal — to work on interesting problems. He’ll build it, put it on GitHub, speak at a conference, but the company will lose the client and won’t make any profit.

“Why am I even sitting here, where’s the growth? What is going on? Goodbye”

In a world of pink unicorns the company would have done everything right from the very start — for example:

• It would have told the developer: look, right now you’re building a site on WordPress, and at the next stage you’ll be working on such-and-such interesting problems — and shown how those stages connect;
• Or it would have hired a developer who finds WordPress interesting to work with in the first place;
• Or it would have analyzed the client’s goals more deeply and understood, for example, that the client’s real goal is to increase sales in a specific segment, and the competition isn’t happening at the level of good looks but at the level of how effective the service is. That would have made the task interesting for the developer.

But if the company lives in a less beautiful reality, the manager has to choose whose interests will have to be sacrificed, and to do it consciously. Let’s say the developer wants to build interesting sites, but what’s needed is a site on WordPress — that’s a conflict of goals. The manager doesn’t offer the choice to the developer, he makes the choice himself, and he picks one of two options:

• Let the developer get some practice and risk the relationship with the client;
• Keep the client, but create a staffing risk.

In the second option the task will have to be set for the developer at a lower level of abstraction.

A task at a higher level of abstraction: Seryoga, go and sort things out with the client, do the whole thing properly.

A task at a lower level: Seryoga, we’re building a site on WordPress, plug in these two modules and stretch this template over it.

That way the manager does the thinking part of the task himself, and delegates a much smaller chunk of responsibility to the developer. He treats him as a less independent specialist and thereby lowers the probability of short-term risks — a damaged client relationship, for instance — but makes the developer’s life less interesting and less independent.

To grow independent people, you have to create broad areas in which the goals coincide. When goals coincide, trust appears and you can delegate tasks with a higher level of responsibility.

Good feedback helps people reach their goals

Back to the topic of feedback — that is, the response you get back. In our system there is a criterion for good feedback, and it’s a simple one: the person receiving the feedback believes it moved him closer to reaching his goal.

Every system, a human being included, is shaped by whatever determines its development — and that is feedback: where we get it, whether we’re able to digest it, which parts of the feedback we react to. If the company becomes the source of the most valuable feedback for its specialists, that lets it shape them to the tasks of the system.

But if a specialist gets his most valuable feedback not from the company but, say, at industry conferences, on a forum or in some chat with other specialists, then congratulations to the company: it has released him onto the open job market.

This doesn’t mean people should be kept in a bunker and not let out into the outside world — no, that’s impossible. The task is to give the highest-quality, most valuable feedback.

Suppose a manager and a developer named Seryoga have a startup, and they share a goal — to build a neural network that will recommend products. The manager sets the task, Seryoga does something, and gets feedback.

The task: Seryoga, we’ve got an online store, it sells diapers, please bolt on a neural network so it recommends products and raises the average order value.

The feedback: Seryoga, you did this work like an idiot! What even is this? I told you the main thing is to show the expensive items at the top (he didn’t tell him, and it’s a dumb idea anyway). And you didn’t do it! Why did you spend so much time on it at all?

That’s an example of bad feedback. To make it even worse, the manager doesn’t just say this to Seryoga, he stages a public dressing-down in front of colleagues. Even if we imagine the developer is a thick-skinned person and thinks: “God, what a moron, he’s always coming out with something like that. Fine — the dog barks, the caravan moves on” — and doesn’t quit, the problem with the feedback doesn’t go away: the feedback in that example does nothing to help Seryoga reach his goal. From that feedback it isn’t even clear what he’s supposed to do now.

If the manager wants the feedback to be good, he has to deliver it in a way that helps the person reach the goal. For that, the manager has to take care of the handover of responsibility in advance: both the manager and the specialist have to understand what they’re doing and why, and formulate a hypothesis together, as grown-up equals.

For example, the manager and Seryoga formulated a hypothesis, launched the neural network, but the average order value didn’t go up — and sales actually dropped.

The task: Seryoga, please propose a solution that will raise our LTV. Let’s agree on how we’re going to test it — say, we’ll run an A/B test, we have enough traffic. We may well miss on the first try.

The feedback: Seryoga, we have a problem. Meaning you and I (the manager doesn’t shift the responsibility, he shows that the decision was made together and the responsibility is shared). We’ve dropped sales. Now, first, let’s roll back as fast as we can. And second, let’s analyze it and work out what we did wrong and how we ended up here. Where did we make the mistake? And what useful thing do we take away from it?

In this case Seryoga will have to work considerably harder than in the one where the manager simply yelled at him. Because he’s ended up in a situation where he carries responsibility for what happened — he took that responsibility on himself.

But the manager shows that he respects his position and doesn’t walk away from the part of the responsibility for the task that lies with him. All that’s left for Seryoga is to agree and go solve the problem — for example, he can say: “Got it, let’s solve this task some other way, not with a neural network.” And find some zone of his own interest in that.

And what if he says: “Boss, but I don’t know what to do!”

Suppose Seryoga says: “I haven’t the faintest idea what to do” — that’s a refusal of responsibility and a request to be given simpler tasks. If this happens for the first time, it’s fine. In that case the manager measures his level of responsibility: “Okay, got it. I gave you a task for level one hundred, and you’re at level ten for now, no big deal, we’ll recalibrate.”

Okay, got it. I gave you a task for level one hundred, and you’re at level ten for now, no big deal, we’ll recalibrate.

But if the specialist shows a negative trend — doesn’t take on complex tasks, refuses responsibility and copes with less and less complex tasks carrying a low degree of responsibility, even though he used to be able to solve anything — then something is going wrong in the relationship with this person. It may not be about personal qualities but about a breakdown in the “company — person” system; but if nothing is done, the situation will keep getting worse and worse until the company and the person part ways.

For a situation to require firing, several factors have to line up:

• The person is refusing responsibility not for the first time;
• He used to take on more complex tasks and solve them, and now he backs off;
• He not only doesn’t know what to do, but doesn’t want to look for a solution;
• He takes the position of “sort out your problems yourselves”;
• He refuses to work on himself.

If all of that lines up, the manager has to say:

“Seryoga, you work here to reach your goals, and we’re here to reach ours. We want both sides to be glad, and we’re always ready to talk about what interests you. What interests us is that you solve the company’s tasks more and more effectively, while we spend less effort on it. We call that professional growth and an increase in the level of responsibility. And the most frightening symptom is when we have to lower your level of responsibility.

Before, we could trust you with more responsible tasks — we’d simply ask you to sort out a problem, and you sorted it out. And now you’re not coping, and we have to come down a level and make decisions for you. We decide ourselves in what timeframe and by what methods you’re going to solve the task. And that’s an alarming signal, Seryoga.”

To keep things from getting to the point of firing, you need to talk through at hiring time what the company expects from the person and what the person expects from the company. The manager has to state clearly under what conditions the company parts ways with people. For example, explain how the company assesses a specialist’s growth and what happens if after three years the growth hasn’t occurred.

Normally, a good specialist always strives to expand his zone of responsibility. It doesn’t necessarily have to be career growth — it could be, for instance, going deeper into more complex technical problems. But in a healthy situation a person wants development — and in business that means he solves more and more complex and responsible tasks.

You can’t say that development is a universal human value; not everyone needs it. But for companies that want to grow — yes, it’s a universal value.