As a video game engineer working on a large team, I once overheard a hallway conversation between Paul and Melanie about whether the team should use networked properties or RPCs to send data from game servers to clients.
As a game programmer, I have a multitude of opinions on this topic. So I swerved into the conversation and listened. Melanie was arguing we should use networked properties because they’re more performant and easier to write, and Paul believed RPCs allowed more control. Personally, I was on Melanie’s side, and I launched into a rebuttal.
Minutes later another engineer appeared, and then another. This was a hot-button issue in our studio. The five of us had a pleasant conversation for the better part of an hour. At its end, we returned to our desks and resumed our work. Was this an effective conversation? The answer is no.
We felt like we had accomplished something by communicating with our colleagues. The conversation felt productive, and it felt like work because it was work-related. But in the end, the team was in the exact same position as when we started. Five engineers wasted an hour each of our time.
Why was the conversation ineffective?
Because no decision was made, no action was taken, and nothing was learned as a result. We five engineers did nothing more than spend an hour being social while pretending that we were working.
Why was no decision made, and no action taken? There were two reasons:
- The owner of the decision wasn’t in the conversation. Of the five engineers in the discussion, none owned the decision of whether to use networked properties or RPCs. If nobody present is responsible for owning and enforcing that decision, how can the conversation be productive?
- The decision didn’t need to be made at that moment. If the decision doesn’t need to be made right now, what’s the point in having the discussion?
Between now and when the decision must be made, many things can and will change. The team will learn new information that may change their judgment, or the decision may become obsolete. And any discussion is stealing time from working on the tasks you must deliver right now. So the most productive thing to do is to defer the discussion until the last possible minute.
Some decisions will incur penalties if the decision is delayed since the code will need to be rewritten to the guidelines of the decision. (Programmers call thisĀ technical debt.)
This doesn’t mean the decision needs to be made right now. Paying a cost for delaying a decision can be an acceptable tradeoff if the extra time guarantees that you make the correct decision that the entire team is comfortable with.
Suppose Melanie had owned the decision, and it’s a decision that had to be made imminently. Then does it make sense for these five engineers to discuss the issue?
Still, the answer is no, unless the decision significantly and negatively affects someone’s productivity.
The only reason I had for being in the conversation was to express my multitude of opinions. This doesn’t require an hour-long conversation involving five engineers. Each of the five engineers could easily have dropped by Melanie’s desk separately and shared their concerns in less than five minutes.
After those short conversations, Melanie would then have been empowered with the information to make the correct decision, and everybody would remain productive. By holding Melanie in a conversation for an hour, I monopolized her time and showed a lack of trust and respect for the boundaries of her role.
Suppose that there is no owner for this decision. No individual on the team owns the decision for whether the team should prefer networked properties or RPCs and in what circumstances. Then is a conversation warranted? Still, the answer is no, the conversation will still be unproductive and should be avoided.
Somewhere on your team, there’s a person who can assign out responsibility for making that decision, for example, a team lead or technical director. Your only responsibility is to report the situation to that person so that they can assign a proper owner.
Once responsibility has been assigned, that person can carry out your team’s process for making decisions. That process should involve the decision maker soliciting everyone’s opinions and driving the decision towards a resolution that has the consensus of the team. (For example, this process could be that the decision-maker must create a document describing the decision and its tradeoffs, solicit team feedback for a period of time, revise the document, and then obtain approval from the relevant leads.)
When the decision is made as part of a healthy process, everyone’s voice will be heard, and nobody’s time will be wasted with social hallway conversations. If your team has no such process, then your responsibility is to give constructive feedback to the lead or director on your team empowered to create such a process.
Spontaneous conversations are a sign of poor workplace processes. They’re nothing more than spontaneous, unstructured, leaderless meetings, and as such are doomed to fail. The most effective resolution is not to talk about it, but rather to find and assign an owner whose responsibility it is to resolve it.
The Only Exception
There is a case where I should have remained in the conversation even though I wasn’t the decision owner or assigner and I wasn’t seriously negatively affected by the lack of a decision, and that is if I stood to learn something from the conversation. In this case, my involvement would be mostly in the form of asking questions, like:
- “What are the tradeoffs between using RPCs and networked properties?”
- “Do we plan to improve our support for networked properties in the near future to resolve their performance problems?”
- “Can we for the time being work in a way that’s agnostic to this decision so that we can delay having to make it?”
By asking these questions, I learn more about video game networking in general, and in particular, the constraints that my team members face, and my time in that conversation remains productive.
The Pros and Cons of Hallway Conversations
Let’s examine the pros and cons had I skipped that conversation.
Pro: I would have gained an hour more of work time on that workday.
Con: I would have had a bit less socialization with my teammates.
The pro is significant. I can get a lot of work done in an hour. In comparison, the con is relatively minor. I can talk with my co-workers at any time about any topic.Ā
If I’m going to be social, I personally prefer it to be about something not work-related, so I can get to know my coworker on a personal level. It’s better to have that social time explicitly than to do it while pretending to get work done.
There’s nothing wrong with socializing with your teammates. It’s great to spend time talking even about technical subjects if you enjoy doing so. But do it during your lunch break, or after 5:00, rather than during company time.
How To Avoid Unproductive Conversations
If you find yourself in a hallway conversation and you’re wondering whether you can reclaim your time by excusing yourself and seeking productive work at your desk, follow these guidelines. If any of the below are true, feel free to hold the conversation:
- Is there a decision to be made on this issue right now, and are you the person who must make that decision?
- Are you significantly negatively affected by this issue, and are you talking to a person who has the authority to fix the problem?
- Is there no owner for this decision, and are you the person who must find and assign an owner?
- Do you stand to learn something from the conversation?
If none of the above is true, you can leave the conversation confident in the knowledge that no decision will be made without your input and you are about to reclaim productive time.
At your workplace, there are people who talk and people who do. The difference between them is that the doers know when not to do the talking.