by Brian Tomasik
First written: 5 Dec. 2015; last update: 8 Dec. 2015


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.


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 makes 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

Many corporate and nonprofit organizations have similar structural features. Unless your organization is unique, 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.


Simon Knutsson helped inspire this piece and provided valuable criticism.