The best way to cut down on communication (remember, not collaboration) is to communicate as much as possible up front.
The best way to communicate is to use ‘if then’ rules. Tech types know this as conditional programming. i.e.
If a condition is met, an action is taken.
If the condition isn’t met, something else happens.
For example, let’s imagine you’re recruiting a designer. You’ve spoken to a few and found some you like. You might ask a colleague “can you talk to [prospective designer], see if he will take on the outlined project for $12k or less?”.
This kind of question is going to ensure a dozen or more exchanges of emails. What rate should you open negotiations with? What is the lowest you will accept? What to do if he does/doesn’t accept? etc…
This is frustrating to both of you, slows collaboration down to a grind, and destroys the purpose of collaboration.
We can do much better here by communicating more up front. This means applying ‘if then’ rules to our efforts.
A good ‘if then’ rule might be:
“See if this designer can take on this project for $13k. If not, drop down to $11k but don’t go any lower than that. If he’s ok with that hire him, setup the contract (use our contractors template) and get him started on our onboarding process.
If he won’t do it, go through the portfolios of the next three designers I’ve highlighted here [link], get quotes from each, and send me a list ranked by which you like the most. Make sure they have 3 weeks available and a clear skillset and track record of doing similar work. Check their references and let me know if they check out”
This gets you the outcome you want without endless back and forth to determine exactly what price you will accept, what to do if he accepts or if he doesn’t accept etc…etc…
The goal is to communicate as much as possible up front to avoid having repeated discussions later on. This also forces you to think clearly about the kind of outcome you want from every interaction. That’s a good thing. It helps everyone communicate clearly.
Another example, you might ask a colleague:
“Can you let me know what you think about this proposal we’re about to send out to {prospective client}?”
This is a terrible kind of request to make. How will you let her know? What about the template specifically? The design, the promises, the quotes, the paper it’s being sent out on? What format should the feedback be? When is it needed by (see previous post).
Let’s add some more information and some good ‘if then’ rules.
For example:
“The proposal for [client] is due by this Friday. Given your experience with widgetcorp on installation processes, can you check the time frame, price and methodology we’ve noted here and let me know if:
a) The time frame seems accurate and similar to what we’ve done in the past.
b) The price is similar to what we’ve done before and we can deliver on this.
c) The methodology will insure the best outcome for the client.
Begin at page 11 and work through to page 14 on the proposal document. If everything seems fine, don’t reply to this email. If it’s not, make changes directly in the document and use an in-line comment to quickly explain each by this Friday. If you need to talk it through, schedule 10 minutes in my calendar at this link www.calendarlink.com.”
Now we’ve clearly stated specifically what information we need, when we need it by, and added two ‘if then’ rules to clearly state what needs to be done if the condition is or isn’t met. We’re getting a specific person to share specific expertise in a specific area of a document. And we’ve made it easy for them.
You might think this type of collaboration sounds overly demanding. In practice, we’ve found the opposite is true. This quality of communication removes the ambiguity and improves relationships.
Any time you’re asking a question, be clear about the ‘if then’ rules that will result from the answer. You might be staggered (as I have been) by just how much time and effort you can save here simply by communicating a little more up front.
