(This post started off as an email to a colleague. They asked me for feedback on how to speed up an agreement on technical issues. Halfway through my response, I realized the advice I was giving was broadly useful and I wanted to write it up more thoroughly.)

So you want to write some code or do something that affects more than just you. Great! Whenever this happens, you will face three basic challenges:

1. Find the stakeholders.
2. Explain the problem to the stakeholders.
3. Listen to and address concerns that the stakeholders have.

Once you’ve done all three, you’re done! The actual work is usually straightforward once your team is supporting you.

Many Meetings

While challenges 1 and 2 can take time, challenge 3 is the one that requires the most dialogue. While technology has given us many tools for communicating, I still find that the quickest way to reach a resolution is face-to-face. There’s a lot of nuance that people provide in-person that gets lost in written communication. Confusion, concern, and excitement are easy to see on someone’s face. Emojis don’t cut it. Videoconferencing has gotten good enough that it is an acceptable substitute, but if you can, gather in the same physical room. The last step in reaching consensus should be a meeting.

But I know what you’re thinking: more meetings? Nobody likes those! In my experience, meetings become distasteful to a person when they suffer through too many where they silently ask “why am I here?”. If you’re spending time in a meeting explaining what the stakeholders should be deciding on, you are wasting everyone’s time. Every attendee should know what is to be discussed before they walk into the (virtual) room. Every attendee should have a stake in the outcome. And especially if you are in a large company or an open source project with multiple time zones and different offices, wasting carefully coordinated time is frustrating for everyone. The key to an effective meeting is preparation.

Explaining the Problem

While preparing for the meeting, you will probably develop an idea for a solution. Good! However, if you can’t articulate the problem you have, people will nitpick on insignificant details of your solution, or worse: you will solve the wrong problem. Whenever you start to see a problem that needs fixing, write up a Google Doc describing the problem. It doesn’t have to be a long description — in fact, it probably shouldn’t— but it must be able to summarize the problem to someone with only passing familiarity with your area of expertise. Using a Google Doc will enable your audience to contribute to the problem description.

Now you may be thinking that writing every problem down is arduous. “I don’t need to write it down. The problem is simple! All that is wrong is…” Think of writing a problem description as an investment. True, it may take you longer to write the problem down than verbally explaining the problem. However: you are now a single point of failure. If you need to give the explanation to someone new, you must recite your prior explanation, taking away from valuable problem-solving time. It’s an issue of scale. If explaining a problem with the written word takes X time, then the amount of your time that it takes to explain it to Y people is still X, not X times Y, like it would be verbally. The written word has a high return on investment of your time.

Finding Stakeholders

Writing down your problem in an easily shareable format gives you another advantage: you no longer have to be physically present for someone else to receive the knowledge. If you share your document with a few folks that you know are stakeholders, they can recommend who else may care about the problem (or they can just share the document to other stakeholders directly!). The challenge of finding stakeholders is a breeze once you solve the challenge of explaining your problem.

Build Consensus on the Foundation

This brings us back to the meeting. All the people you need are in a room. They understand the problem, and now they can tell you what they need. I could list some tips on how to have this conversation, but any advice I could give has already been written in much greater depth in Crucial Conversations by Kerry Patterson et al. If you haven’t read this book, it’s a light read with great insights — I can’t recommend it enough. But even if you skip the book, overcoming the first two challenges (finding stakeholders and explaining the problem) will help the stakeholders express their concerns to you in a meaningful way. Your meeting will not waste time. Your attendees have personal involvement and understand the significance of what you’re trying to solve.

While most of my experience is in software development, I believe that these three challenges are applicable to all disciplines. The particulars of how you overcome them may differ in your environment, but they’re always there. I hope that by looking at your problem through this lens, you are able to reach consensus efficiently. Go forth and influence the world!