Have you ever agreed on a time to hang out with your friend only to find yourself waiting, and then you get this text:
“Sorry omw”, “I’ll be there soon”, “Almost there!”
I've been in this situation and each time I’m left thinking:
- Are they okay?
- When will they actually be here?
This is an effect of blurry language; 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.”
Much better!
In reality, having to wait for a friend is whatever, who cares?
However, 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 deblur as a core tenant of our culture.
1. Identifying blurry language
Blurry language has common traits that you can learn to spot over time:
- 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)
Here are some examples of phrases that we've used commonly at Distru that are blurry. 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 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.
2. Deblurring
Lets deblur our examples from above:
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 follow-through 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.
3. Calling out blurry language (safely)
Blurry language is easy to notice on others, hard to notice on yourself. Therefore, we are responsible for each other by calling out of blurry language. Here how you can do so, and not feel like a nuisance:
- “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, 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.