Have you ever agreed on a time to hang out with your friend only to find yourself standing at the meeting place wondering “Where in the world are they? They should have been here by now.”. You then proceed to send them a text and you get one of the following responses:
“Sorry omw”, “I’ll be there soon”, “Almost there!”
I’ve been in this situation quite a ton in my life, and each time I’m left thinking what had happened and when will they actually be here? This is an effect of blurry language in its essence; on the surface, it seems to provide helpful information, however, it does the opposite by creating more questions and uncertainty. Now imagine a world where your friend says:
“Sorry, I had to find a babysitter for my kids, it took longer than expected, I’ll be there in under 10 minutes, but good news, I’ll be able to stay 2 hours longer!”
Anxiety and uncertainty go out the window!
In reality, having to wait for a friend who is late is relatively harmless. Conversely, when building a fast-moving startup, using blurry language could mean the difference between hitting a critical deadline or not, closing a life-changing investment or not, etc. At Distru, we’ve been first-hand bitten by blurry language too many times over the years, and I’d like to share our findings and tactics with you!
Step 1: Identifying Blurry Language
Blurry language has common traits that you can learn to spot over time. The main ones we’ve disseminated at Distru are:
- Vaguely measuring time (pretty much, almost, close)
- Emanating resolve, but without next steps (I got it, it’s all good)
- Using words that convey different meanings to different people (finished, fixed, done)
Are there any you can think of that I’ve missed here? Please let me know -> johnny@distru.com
Here are some examples of phrases that we’ve used commonly at Distru that inhibit some of the blurry language traits described above. To help illustrate, I have underlined the parts of the language to focus on:
Providing Estimates: “The unit types feature is pretty much ready.”
- unit types feature could be big in scope, and might be interpreted differently by different people.
- pretty much is relative to the person giving the estimate. This phrase could mean 1 hour or 1 week of work.
- ready is contextual to how someone perceives ready. For example, is this work ready to be reviewed by other engineers, ready to be QA’d, or ready to be used by customers?
Giving Feedback: “You did a great job closing Client X!”
- great job does not specify what the person did great, thus making it harder for them to repeat that behavior in the future.
- closing is contextual to how someone perceives a closed deal. Is this a verbal agreement, signed contract, or money in the bank?
Taking Ownership: “I’ll take care of it.”
- take care without further follow-up does not specify the exact next steps the person will take and when.
- it can at times be blurry if more than one thing is being discussed.
Reporting Updates: “I fixed the bug!”
- bug does not specify what the fixed is.
- fixed is subjective to how someone perceives fixed. An engineer may consider something fixed when their code is approved during peer review, while a customer does not consider something fixed until they can use it again.
Blurry language often gives and withholds essential details at the same time. So, if you find yourself vaguely understanding something that’s been communicated and not feeling completely satisfied with it, you likely need to ask the other person to deblur their language.
Step 2: Deblurring Your Language
Chances are, you’ve used many similar variations of the blurry language seen above (as we all have). So now let’s explore some ways we can deblur using real-life examples we’ve experienced at Distru!
Providing Estimates: “The unit types feature is pretty much ready.”
To engineers: “I’m currently working on allowing users to mix and match compatible unit types on Sales Order line items; I’m 90% confident that this will be ready for an initial code review by EOD tomorrow.”
To non-engineers: “The portion of the unit types feature that allows mixing and matching of compatible unit types is 80% code-complete. I have ~5 hours of work still left, which I’ll get to today. It will likely take a couple more days to fix any review comments and a couple more days for additional QA. You can expect this to be released by EOW this week; if anything changes, I’ll update you ASAP.”
Here we are deblurring the timeline, confidence interval, and giving definition to what “ready” means depending on our audience.
Giving Feedback: “Great job closing Client X!”
“The way you clarified the client’s biggest concern around unit types and communicated potential workarounds via a follow-up email helped them realize that they can count on you and was a big factor in getting them to sign with us! Great work, and keep that up!”
Here we see that we are explicit on what they did well, and what specific positive impacts it had. Again, this deblurs the great work and gives the other person a way to repeat their success.
Taking Ownership: “I’ll take care of it.”
“I’ll look into the brand color discrepancy issue on Safari later today. I’m 80% sure that it’s a simple fix I can patch and release tonight; I’ll update you as soon as I do. If it’s not a simple fix, I’ll recommend the next steps tomorrow morning.”
Here we are deblurring what we’re owning, by when we plan to execute, and a followthrough plan.
Reporting Updates: “The bug is fixed!”
To engineers: “The bug where users were sometimes unable to see their profile image in the header bar is now up for review. I’ve tagged some of you; please take a look sometime before the end of the week.”
To non-engineers: “The bug where users were sometimes unable to see their profile images in the header bar has been shipped to production just now.”
Here we see that we’re deblurring what we’re updating on and giving context to the progress based on our audience.
Step 3: Practice Calling Out Blurry Language
Like someone who just ate a hearty leafy salad, others are likely to notice the specs of bruised leaves clung to the crevices of your teeth much better than yourself. Wouldn’t you be eternally grateful for them to point that out before you go about the rest of your day?
Much like the specs of salad leaves, blurry language is often impervious to the ones delivering it. I know very well what I mean when I say “The feature is pretty much ready”, or “I’ll take care of it”, but others most likely don’t.
Therefore, we are all responsible for our fellow teammates by practicing the calling out of blurry language. Here are some low effort ways to get started:
- “Could you deblur what you just said for me?”
- “When you say ____, what does that mean to you?”
- “Could you clarify for me what ____ means?”
In doing so together and often, we constantly refine a culture of deblurring your language and providing more transparent communication. In doing so, the next time you need to convey anything to your team, your customers, or your friends, you’ll be thankful as to how few follow-up questions there are, and they’ll be grateful for just how clear you are.
—
I hope this concept has been “deblurred” enough for you to practice! If you have more to add to this topic, please reach out to me via johnny@distru.com. We’re always trying to learn and improve as a company, and any thought exchange in that effort is greatly appreciated!
Lastly, Distru is currently hiring product-minded engineers, product designers, product managers, and engineering managers that want to build software powering the future of the Cannabis supply chain. If you’re interested in learning more, please check out our Glassdoor and reach out via our careers page and I’d be happy to jump on a call with you!
