Good Busy Bad Busy
Everyone is busy, that isn’t the interesting part
I have been thinking quite a bit about engineering work, organizational structure, information flow. When I was young and absolutely clueless, during my undergraduate, I started reading a lot of random blogs to just try and get an 'in the trenches' feel for what it might feel like to work in some industry. I came across randsinrepose, and ate it up. I even sent him a half panicked half coherent email when I was deciding about putting myself onto a track that would lead to getting my PhD, and he was very kind. Sold.
If I had known what sampling bias was at the time I would have realized I was also selecting on what industries produced really good communicators, but that all worked out for me. Unsurprisingly I also find myself thinking hard about the unquantifiable parts of human interaction. The small stuff. I keep being surprised at how much of the difference between a good team and a bad one comes down to accumulated tiny acts of giving a shit publicly when team trust is on the line. These moments compound, and I am becoming convinced that these are the difference makers on whether the hard moments will be remembered as a joy or as a slog. In his writing, Rands often talked about 1:1s, and I paid attention closely. Now, some years later here I am running 1:1s, thinking hard about them, and now here I am writing about 1:1s. They are the atomic unit of organizational information transfer, a delightfully messy playground. We have all had bosses that have run terrible 1:1s, some of which were run by yours truly, and I hope everyone has had a boss that ran a 1:1 that left you feeling like you could slay dragons, or at least a menacing lizard. This can come from unflinching honesty, clear praise, hard feedback. What I want to talk about is a quieter move: asking a question juuuuuust weird enough that 'good….' isn't a valid answer.
What I want to share now is a question I am finding so goddamn effective it feels like a manager cheat code.
"Busy" is a word with probability near 1 of appearing in the first five minutes of a 1:1. This is an overused shorthand, and I've been getting mileage out of a simple follow-up: "Are you good busy or bad busy?"
Importantly, we have not defined our terms. Learning how the recipient interprets the question is half the exercise.
I like this question for a few reasons. It makes them pause and think. They need to compile a good v. bad criterion and apply it, which usually leads to something interesting. It openly acknowledges not all tasks are the same. Asking someone "please put your last ten tasks into two buckets and label them" might yield interesting results, but likely it will lead to them asking to move teams. The dialogue that comes out of this is nearly always unexpected, and useful. It allows you to be honest, and in the right circumstances question the label attached to work, helping you pin down what it is about it they really like or don't like.
Most importantly, it is a fantastic barometer for exactly how they are feeling right now. The good v. bad answer is such a great window into how they are feeling at that exact moment, and taking your team's temperature is basically your whole job some days.
Some recent replies:
"Good busy, once I nail this fucker down thread management is going to be so much more straightforward." They see the force-multiplying properties of what they're building and are motivated. Mind you, if this had fallen somehow in bad busy in their minds, it is an open invitation to step back and make sure they understand the impact on the broader ecosystem this code will have. Good busy is what you want to hear every time. It implies motivation, clarity of purpose and impact, and that hard-to-distill feeling "this code I am writing will survive for a long while." More deeply, it gives you a window into what makes this person off the cuff classify work as good. Is it building durable systems? Wicked problems that require some really out there testing? This is such a rich question because you are real time getting a picture of their value system bumping into their work.
"Good busy, set up a suite of runs and it turns out our poor out-of-sample performance was fixed with smarter normalization, check this out." Not only do you now know that this researcher is best when their teeth are deep in a problem, but you also get a sense that they dig into fundamentals rather than just reaching for bigger and bigger hammers. The task now is to probe the why. Everything. Have them take you through the process as if you haven't talked about this for the last three weeks, and I mean explicitly say that. You are seeing if this is something worth showcasing at a team meeting or lunch and learn or whatever, as well as forcing them to give a recap of their research. Now dive into what else they tried, ask for gut instincts on why things worked or did not work. The point of this moment is to keep asking questions until you increase your odds of guessing: if I give them task X, will they file it under good busy?
"Bad busy, chasing my tail on this bug we were told our code caused when really it was the service passing into ours crashing after it logged success so it just looked like us." This is exactly the kind of managerial moment this question is designed to set up. Solving things is generally good. Doing work that improves the overall health of a system, also good. What makes them put this in the bad bucket? Ask very simple questions and listen closely. In this instance, it was because when it looked like their fault the other team had their hair on fire and made it a generally stressful experience to debug, and when they worked late into the night to understand wtf is going on, they cracked it to a much more muted and unapologetic "oh thanks we will get this into the next hotfix." Okay, shitty situation, finger pointing, and a clever bit of debugging combined with hard work going uncelebrated. We know how to handle this. Congratulate the hard work during a team meeting, ask to be included in future discussions with this team so the next time their hair is on fire you can force everyone to take a beat, breathe deep, and only if absolutely necessary gently remind them of this situation to try and keep the temperature low.
The core loop is as follows:
Good busy or bad busy?
Shut up and listen closely.
If good, probe the why.
If bad, also probe the why. Actually just make step 3 "probe the why."
Develop an understanding of your team member and their motivations, frustrations, and needs.
A 1:1 is never just talking at each other. You (the manager) are demonstrating consistency and empathy in understanding them. I doubt it is a controversial stance to say this is fundamental for trust, which is the only option if you want a successful relationship with your reports.