The unreasonable effectiveness of one-on-ones

When I started dating my partner, I quickly noticed that grad school was making her very sad.

This was shortly after I’d started leading an engineering team at Wave, and so the “obvious” hypothesis to me was that the management (okay, “management”) one gets in graduate school is totally ineffective.

Most graduate students, including Eve, start school right after college, i.e., without much clue about how to effectively do self-directed work. At high-functioning organizations, people try pretty hard to support recent college graduates by teaching them how to prioritize, avoid getting stuck, and generally be effective at things that are more complicated than “do well on the next exam.” In many grad school departments, on the other hand, you’re lucky to meet with your adviser (the only person who nominally cares) more than once a month. Since I also cared, and apparently was more available, I decided to try to help.

Of course, it’s best to have your work support come from someone who also understands your work well enough to provide feedback, and I don’t know anything about aesthetics or philosophy of math. But since nobody who did appeared to be paying enough attention, I offered to have weekly research check-ins with Eve, modeled on Wave’s practice of “one-on-ones.”

One-on-ones are a management tradition at lots of tech companies, perhaps popularized by High Output Management,¹ in which a manager regularly schedules time with a direct report to discuss whatever the report wants.

At Wave, I’ve had one-on-ones with my manager since the time I joined, and I found them incredibly useful for helping me improve at work. Different people would spend their one-on-ones on different topics, but for example, mine often included:

• Personal habits and self-improvements. Among other things, by talking through how to improve my focus, I quickly got 50% more productive time (and that’s just the part that was easy to measure).

• Project management. We’d often post-mortem recent projects. Even though I was building software, the improvement points here were mostly non-technical (e.g.: a different part of this project turned out to be the riskiest part and should have been done first, or we should have checked in more frequently with some stakeholder).

• Communication. Turns out writing a term paper is really different from trying to get four people to agree on how to design a feature. (For instance, bulleted lists signal low effort to professors, but to coworkers, they mean your thoughts are well-organized and skimmable.)

  In addition to improving the form of my communication, I also learned a lot about how to improve my communication habits (e.g. when to communicate how much)—this was extra important since Wave is a distributed company, and has different norms that take some getting used to.

• Alignment—that is, talking through the root causes of any disagreements that have come up. This matters for two reasons. The obvious one is that whoever is wrong about the disagreement will improve their models of the world. The less obvious one is that both participants in the one-on-one get better at imagining what the other person would think about something, which is critical for building a high-trust working relationship.

• Uncertainties. The founders always encouraged me to use 1-on-1s to ask about anything I was uncertain about, even if it didn’t affect my day-to-day work. If anything, I spend more attention worrying about things that don’t affect my day-to-day work (because those are the things I can’t control), so I’d often end up a lot less stressed after these discussions. For the founders, I think these discussions helped them discover problems with internal communication—for instance, occasionally I’d get worried about some strategically important project elsewhere in the company because they’d forgotten to announce progress reports on it.

Those were all things I felt like would be helpful to Eve, so I was pretty confident that one-on-ones would be at least somewhat helpful for her. In the end, they succeeded far beyond my expectations: Eve thinks our one-on-ones sped up her dissertation by about a year.

Obviously, the things Eve and I talked about weren’t exactly the same as my Wave one-on-ones, though they did share some common themes. Here are some of the things we talked about that Eve thinks made the biggest difference:

• Figuring out when she should be outlining new parts of her dissertation vs. fleshing out existing parts

• Realizing that she was spending a lot of time reading crappy papers that she didn’t have to

• Noticing when and why she was least productive (for instance, noticing when her procrastination was a coping strategy to avoid executing a plan that she didn’t really believe would succeed)

• Asking for more frequent feedback from her adviser and dissertation committee

• Being able to talk through anything stressful

• Allowing herself space to “stare into the abyss” and confront uncomfortable possibilities (e.g. is it actually worth finishing her PhD?)

In general, Eve summarized our one-on-ones as being a forcing function for her to fully decide on longer-term goals and then focus her work on the best way to achieve those goals, rather than getting too bogged down in whatever was right in front of her.

I learned a few things from this experience.

One is that grad schools are really dysfunctional. If I, a person whose sole qualification is caring a lot, could help Eve speed up her dissertation by ~25%, then her philosophy department is leaving a lot of productivity on the table. But that was last week’s rant.

On the flip side, I also now think the “caring a lot” qualification is way more important than I used to. Lots of people (including Eve) try having “accountability buddies” that they meet with to discuss progress on their goals, and accountability buddies are rarely this effective. The main difference is that most accountability buddies don’t care about each other in the same way that managers/reports, or significant others, do: for me, Eve’s progress was the top idea in my mind in a way that I doubt it was for anyone else. Because of that, I ended up having more insightful feedback for her than a random “accountability buddy” might.

The last thing this helped me realize is that specialists have a lot of non-specialized problems. In one sense, this is so well known it’s become a cliché—the engineer who just wants to crank out code all day, the philosophy professor with their head in the clouds. But the cliché doesn’t really describe me or most engineers or philosophers I know, who are broad-minded enough to be happy thinking about things outside our assigned specialty. Even for us, though, we can often increase our impact a lot by improving our generalized effectiveness.

Thanks to Eve Bigaj for reading a draft of this post and providing the source material.