Thoughts on Management Style

Summary

My general approach to managing volunteers and employees is to be mostly hands-off, in the sense of letting people do what they want to do within limits. It then becomes more important to hire the right people rather than manage in the right way. I discuss a few motivations for this stance, partly drawn from past experience. However, given that I'm young and have little management experience so far, I expect my views on this topic will change with time.

Introduction

Around 2010, while I was working at Microsoft, a colleague and I had a conversation that went something like this:

colleague: This person is going to try an experiment to test this new idea in this way.

me: But you think it should be done in a somewhat different way. Are you going to encourage the person to do it your way instead?

colleague: No, I'll let the person try it his way and see how it goes. I think people are most motivated when they can own their own projects rather than being told what to do.

This exchange has stuck with me.

A general philosophy of hands-off management

If I care about a project intrinsically, I dislike being told what to do or that I need to change it. This is one reason I publish so much on my own websites rather than submitting to external venues: I find it unpleasant to cut or rewrite my work to suit the constraints of an external publication or the whims of an editor. I love the freedom that comes from being able to say whatever I want in whatever way I want, without worrying about holding unpopular ideas or seeming weird. I would find it demotivating to work for an organization where I was told what to write about at any given time, since that would suck away the enthusiasm that comes from spontaneity and controlling one's own path. Writing is art, and it takes the fun out of art if you're given a long list of constraints that your end product has to meet.

Given that I dislike micromanagement, I tend to assume that other people feel similarly. My management style tends to be telling people: "Here are things I think are most important to work on. I encourage you to work on something in this neighborhood, choosing the specific topic based on what you're most passionate about. It's ok to work on other things that are less important as well if you need to, as long as the total value of what you're doing is high enough."

This doesn't mean that anything goes or that people's work can't be evaluated. Both managers and other colleagues should give regular performance feedback and should clarify when someone's work is drifting too far from expectations. But I think it's also important, especially in a research organization, to maintain epistemic modesty, so that the manager doesn't only reward employees for taking the views or approaches that the manager already favors. Even if the manager thinks an employee's approach is misguided, it might be good to give the employee a bit of time to test things out and possibly prove the manager wrong.

Benefits of hands-off management

Lots has been written on tradeoffs between hands-on and hands-off management styles. Following are a few main reasons I incline toward the hands-off approach.

Saving time

Micromanagement is a time sink. There have been occasions when I've tried to give specific instructions to someone else to do some task. Doing this takes nontrivial time. Yet, it's not uncommon that the other person doesn't do the task the way I intended, so I either need to take more time explaining or go back and do the task myself. Also, other people (especially volunteers) are often less reliable, so I would sometimes find myself in the position of setting up a note for myself to remember to remind the other person to do something. As they say: "If you want something done right, do it yourself."

Other people may sometimes not be as careful as I am, which is one reason I don't hire other people to do small tasks for me. Often it takes more time to try to outsource a task than to just do it yourself.

Of course, I don't intend offense to volunteers. It's natural that people will be sidetracked by other things that may often be more important than whatever task they signed up for in their free time.

People are hard to control

Sometimes when I hire or collaborate with another person, the other person tends to do what s/he wants to do most of the time. Occasionally I can convince the person to do things my way for a while, but in the long run, the person's focus inevitably shifts back to what s/he is most passionate about. This poses the dilemma of either micromanaging (which takes too much time) or letting the person roam free. Letting people roam free seems to be the only scalable option.

Thus, it's very important to hire the right people from the outset—those who share your values and approach.

Happier employees

As noted earlier, people are probably more passionate about a project they can control, and giving employees more control probably increases employee satisfaction.

Some occupations, like entry-level investment banking, are famous for their rigid requirements on employees, but these industries make up for unpleasantness with the promise of high compensation. Nonprofits typically can't do that.

Less distraction

When I do research and writing for a substantive essay, I prefer to avoid distractions, including communication with other people, for long periods of time. Otherwise I find it hard to keep lots of information in my head at once, and my enthusiasm for research can be interrupted and then hard to restore.

A more relaxed approach to management means fewer distracting messages to employees.

More creativity

Some of my past managers have been pretty hands-off, while others have been more involved with details. While I found that hands-on management could have upsides in certain cases (discussed below), I also noticed that if I was micromanaged, I took less initiative. Rather than coming up with new ideas on my own, I waited for my manager to tell me what to do.

This was especially true if my manager was the kind of person who didn't like ideas that weren't his/her own, since in those cases, if I suggested something, my proposal was usually not heeded. It wasn't obvious if making alternate suggestions was even a positive thing for my performance evaluation. Of course, it's unfair to paint all hands-on managers with this same brush.

Less communication overhead

Too many cooks spoil the broth, and too many people working on a single project make the project slow. As Brooks’ law explains, the overhead of inter-person communication can be huge.

I think a good model for scaling employees in a research organization is an Internet forum. People produce results on their own, perhaps with some assistance as desired. They post drafts for others to see. Whoever has time can give comments. People can choose which projects they want to review and collaborate on. This allows for automatic load balancing rather than putting too much burden on any given person who's supposed to review material.

Benefits of hands-on management

A more hierarchical and closely coordinated organization

• might spend a bit less time on suboptimal projects because there's more discussion about what to work on ahead of time
• will have a more uniform public-facing image (although this could be bad if one values diversity of viewpoints)
• might better fit those employees who are more motivated by external pressure than by internal passion
• offers more training wheels for new employees.

In some cases training wheels might be welcome. For instance, I've had jobs where I wished I had been given more instruction from my manager so that I could learn faster how to perform my role better. My intuition is that training wheels are less useful in a research institute where there are fewer concrete tasks that need to be done exactly the right way, but perhaps some employees would find more guidance helpful.

Of course, one needn't create a false dilemma between hands-off vs. hands-on management. A hands-off style can still allow employees to ask for hands-on guidance when desired.

Decision-making: distributed or hierarchical?

A related question is how an organization should make decisions about high-level issues, like goals, future plans, and hiring.

It seems people generally favor distributed, democratic decision-making for governmental policy but hierarchical, authority-based decision-making in private companies. The main tradeoff is that distributed decisions are often wiser (assuming the participants are sufficiently informed and engaged), while top-down decisions can be made faster and with an overall vision in mind. There were many cases at Microsoft where I felt that top-down decision-making was suboptimal, because managers didn't always know much about the on-the-ground affairs that they were making pronouncements about. On the other hand, I wasn't able to see a more democratic style of decision-making, so I can't say it would have been better on balance.

One of my high-school teachers said: "If you want to kill something, send it to a committee." Requiring approval from everyone slows down action. Getting approval from lots of people can also waste time, since many eyes need to examine the same proposal.

On the other hand, consensus decision-making has the virtue that it can unearth disagreements that otherwise would have been ignored. If two people with the same values disagree about a decision, they might benefit from presenting their disagreements in order to update in each other's directions, thereby potentially improving the final choice and the general epistemological accuracy of the decision-makers going forward.

One compromise position between these extremes is to make decisions in small groups but also let others know about those decisions and be open to comments and objections that others may have. Others can comment only if they have time and if they feel passionate enough to do so.

Keeping conventional wisdom in mind

Unless your organization is very different from other companies or nonprofits, it seems risky to deviate too far from standard practices, since those practices have been honed through enormous amounts of experimentation.

The ideas in this piece should be interpreted more as principles to keep in mind rather than a specific blueprint for a non-standard approach to running an organization.

An overarching theme of my recommendations is epistemic modesty: letting other people's views influence how the organization runs rather than exerting lots of top-down control.

Avoid hiring careerists

A careerist is "A person who pursues the advancement of his career at the expense of other values." While hiring careerists is probably undesirable in most professions, it's especially bad in fields like research where a person's output isn't easily externally verified. A careerist trader on Wall Street might be ok as long as she demonstrably makes a lot of money (and as long as she doesn't do so in ways that, unbeknownst to the rest of the team, set the company up for long-term trouble). Meanwhile, with research, it's more time-consuming to verify the quality of someone's output.

A researcher who really cares about the topic she's writing about will be highly motivated to explore it and will be more likely to fret over things that don't make sense or over lingering doubts that some consideration has been missed. Meanwhile, a careerist will tend to be less intrinsically motivated by the topic and will tend to ignore messy details in favor of cleanly argued papers that superficially appear more impressive and convincing.

If experimental results don't verify a hypothesis, a sincere researcher will report this and revise her beliefs. Meanwhile, a careerist researcher is more likely to massage the results until they support the desired conclusion.

People who work primarily to earn money are more likely to be careerists. This suggests that paying higher salaries to researchers isn't obviously a good idea, although this is only one small consideration in the overall decision about how much to pay employees.

Careerism is one reason it's good to be skeptical of published studies. I would guess that a decent fraction of academic researchers massage their results and omit unflattering complications from published research in order to make it look more impressive. If a study has messy results that don't necessarily support the authors' hypothesis, I'm more likely to believe it than if the results all line up exactly how the authors predicted.

Quantitative metrics should rarely be optimization targets

Some companies use relatively objective metrics to evaluate employee performance. This might sometimes work well if the metric accurately captures most of what you care about, such as the total value of sales that a salesperson has made during a year. However, my sense is that in many cases, quantitative metrics don't work well as goals, for a few reasons:

1. Noise: Many metrics may fluctuate significantly based on factors unrelated to employee performance. If you reward employees for good performance on metrics, you may be rewarding mostly random luck.
2. Granularity: Many possible metrics are too broad and are only modestly affected by employee actions. This means that most of the metric will be noise relative to the employee's performance. For example, most of how the US economy fares is not controlled by the US president's personal choices, so evaluating a US president based on the economy isn't that useful. (Yet many voters seem to do this.) I would instead evaluate presidents based on more specific assessments of the policies they actually implement.
3. Campbell's law: When a metric is optimized for, people tend to search for ways to game the system. For example, if "number of Facebook Likes" is a metric, you may make a lot of low-quality Facebook posts containing pictures of kittens. If "number of papers published in journals" is a metric, you may optimize for publishing on topics that peer reviewers are least likely to find objectionable, even if those topics aren't very important, and you may neglect publicizing the results of your papers to the wider public. And so on.

In my opinion, there's no simple substitute for qualitative, contextual, and holistic evaluations of employee and organizational performance. Numbers are fine to look at, but they should generally not become optimization targets.

Maybe some companies use quantitative targets because qualitative evaluations are subjective and can't be trusted. For example, a selfish manager (call her Alice) might tell her own manager (call him Bob) that all Alice's employees are doing great, so that Bob will look more favorably on Alice's performance; however, this would inflate the performance reviews of Alice's employees. This problem seems less acute in an organization of people who actually care about altruism rather than just making themselves look good.

External review, such as that done by GiveWell or Animal Charity Evaluators, can help provide evaluation that's impartial but still qualitative and holistic.

High-impact vs. low-impact feedback

Do you have more impact by being a manager and advising other people on the direction of their research? Or do you have more impact by being one of those researchers making novel contributions?

In the past I tended to assume that managing generally had higher leverage because you could affect the research direction for many people, which is more valuable per unit time than getting into the weeds of detailed technical material on a specific topic. I still think that shaping the general thrust of people's research can be very important for this reason.

However, in other cases, giving feedback on others' work may be much less useful. This is true in at least two broad cases:

1. The other person doesn't incorporate your feedback much. In this case, you might write many paragraphs of insightful comments that will be read by one recipient, mostly ignored, and then lost to posterity. It would have been better if you had instead made those points in a public blog post replying to the main article so that others could have seen them.
2. You end up doing a lot of "janitorial" work, such as fact-checking, suggesting writing-clarity improvements, fixing grammar, and so on. If you need to make a lot of such low-level corrections, this can consume a lot of time and is arguably less valuable than writing your own high-quality paper directly. (Pointing out hard-to-notice typos or grammar mistakes within a mostly error-free paper can, I think, be very useful, because you might spot a needle in the author's haystack that the author himself would have required great effort to find.)

Acknowledgements

Simon Knutsson helped inspire this piece and provided valuable criticism.