Borrowed, Learned, & Thought (or BL&T) is a weekly newsletter sent on Mondays. In every edition, I share weekly themes and progress in running an agency business/team and doing my best to live a good life. Published posts do not include all details shared via email to subscribers. Subscribe here.
Communication has been a theme on my mind lately as we continue improving how we collaborate as a team. Communication can mean different things to different people. My interest is in how we can make our communication more effective around social contracts, specifically when asking questions and delegating tasks.
While social contracts are critical for any team's collaboration, working as a distributed team underscores their importance.
You can't swing by a co-worker's desk to get what you need.
You can't shout across the room to ask a co-worker to review your email.
I know I'm guilty of both!
While these may seem like a luxury now, this behavior made it easy to operate inefficiently and could create a distracting environment for focused work. However, for better or worse, the benefit was the accessibility to co-workers, whether they replied to you on time or upheld their social contracts, or not.
That said, I believe having these constraints as a distributed team can push us to be more effective and accomplish more together. But, like most things, growth takes time and, in this case, a joint team effort.
A social contract involves two or more team members: someone asking a question or making a request and someone on the other side. Communication breaks down when these parties do not share the same standards.
I'm exploring this topic today to examine both sides of a communication breakdown and what we can do to improve.
When a team member cites issues with a co-worker's communication, there are three common complaints:
Typically, the co-worker's manager or I will have a follow-up conversation with them. I find it helpful to enter these conversations with the mindset that we all want to do our best work together, a.k.a. no one is slacking off. I have learned a lot by leading with this mindset, inspiring me to gain perspective vs. coming in as a feedback messenger and never getting the full context.
Sometimes, the team member is aware of their co-worker's complaint and frustration. They don't feel good about how they've impacted the team. Other times, they have no idea. Either way, they almost always have an excuse for why they think it's happening.
Some common excuses:
All of these excuses are solvable and within their control. We usually spend most of our conversation unpacking the excuse and ways to avoid it in the future.
Here are some common themes:
In the past, I've left these conversations feeling relieved, as if the team member with excuses was a problem I solved. I listened, gave feedback, aligned on ways to improve, and documented everything for future reference. Check, check, check! Unfortunately, it's not that simple. Most of the time, the conversation continues — some become serious performance issues, others fade away as the team member improves.
Either way, I've learned there's an important step I've previously overlooked — taking time to dig into the situation with the team member sharing the feedback from the start.
If you noticed, excuse #1, #2, and #3 above point to a lack of clarity from the person with the request:
Making time to chat with this person about how they communicate and align on ways to be more effective is invaluable. The balance is not making the person feel I am dismissing their concern.
If their co-workers's poor communication continues, and worse yet, other co-workers share similar feedback, they are likely not a good fit. However, raising the bar on our communication can only help. The best case is that #1, #2, and #3 are no longer excuses!
So, what can we do to improve how we create social contracts?
I recently finished reading The Primes: How Any Group Can Solve Any Problem, author Chris McGoff. In the book, McGoff touches on the recklessness by which many of us enter social contracts.
The framework distinguishes between three different concepts:
Statements are "a description of something or the condition of someone." They elicit no response. In an agency setting, a statement might sound like:
I can't count how many times I've heard statements disguised as requests. I'm guilty of the same mistake. We get frustrated when we don't receive the desired response or receive no response at all. While we might hope that our co-worker would pick up on the urgency or tone, we cannot guarantee they will.
Requests are explicit. In McGoff's words, they are an "invitation to give your word. ... Only two responses to a request are allowed in high-performance groups: “no” and “yes.” “Maybe” or “I'll try” are code words for “no,” and their use should be forbidden."
Here are some examples reframing the above statements as requests.
While requests are more effective than statements, I find it is important to include as many details as possible. Details might include when I'm looking for a response from the person or if their response is a blocker.
There is no obligation to say yes to requests; however, "no" should lead to aligning on new terms for fulfilling the request. The key is that people are comfortable saying no! This is especially important for junior team members who feel pressure to say yes.
Commands require "yes" as a response. At first, I questioned their relevancy at Barrel, but after spending more time with the concept, I can see they have their place on occasion.
Commands are a "requirement for someone to make good on [their] word." I find them most applicable to Client Services team members, project leads, managers, and others in a position of delegating tasks, particularly in tense situations.
Imagine that the above requests are non-negotiable because they are critical to the success of a project or trust within a client relationship. Those requests may sound like this when framed as commands:
If a situation warrants a command, McGoff points out leaving room for the person on the receiving end to let you know the impact of them saying yes. In an agency setting where project leads may not be aware of their project team's workload, making this space is critical and may lead to revising the command altogether.
Some example responses:
Although I would bet that most of our team would agree with what good communication looks like, I see an opportunity to solidify and reinforce our standards.
Looking ahead, I'm excited to explore how this might take shape. I'd love to see us move toward a future where statements, requests, and commands are part of our agency vocabulary. Everyone understands their role in good communication, recognizing the weight of their words (or lack thereof), holding each other accountable, and maintaining integrity.
Where am I making statements when I should be making requests?