Healthier Communication Patterns
The Overlap #47
The Overlap is a newsletter somewhere between product development and organizational development. As of now, this will be in your inbox every other Thursday morning (and not Wednesday!).
Ever worked on a project where there were tons of stakeholders? You must have been frustrated by how long things take to get done.
From Metcalife’s law Wikipedia page:
Metcalfe’s law states that the value of a telecommunications network is proportional to the squar of the number of connected users of the system (n^2).
As a team grows linearly, the number of communication lines grows exponentially.
But you and others who work on projects with tons of stakeholders experience this as “the way things usually get done.” It’s the norm. You live with it.
Big organizations (unintentionally) train us to believe that work is often blocked by decisions, approvals, or consensus from leadership. And, that we should always 👏🏽 be 👏🏽 working. So, while we have one project/effort that’s waiting on a decision to be made, we start other work. Which leads to more work-in-progress. Which then turns into more things that need to be approved. Which means more waiting around. Which means more work to fill up time so that people aren’t anxious that “ICs aren’t doing anything.” Yet we wonder why we’re all so busy all the time.
Too many cooks in the kitchen. What do we do about it?
Dysfunctional communication patterns takes many forms. Improving communication patterns depends on the specific dysfunction you’re trying to improve. There is no one-size-fits-all solution for too many cooks; there are only places to intervene.
And, I believe there are specific interventions that produce healthier patterns. Here are a few I’ve observed.
Start projects with a small team
This is something I’ve learned and coached, and yet it’s still a recurring lesson for me. Small teams force definition: you have to make clear who is responsible for what. We’re realizing at garden3D, too. We’ve learned that while our Shaping phase — our introductory strategy phase — needs the right perspectives in the room, not everyone needs to be in it. We can always include more team members later on, depending on the stage of the work and the skills needed.
Spend time upfront on the strategy and goals for the project
With your small team, define the problem you’re trying to solve, articulate your bets, and clarify your metrics for success.
And spend real time on it. To makers and executors, this could feel very slow. But teams move fast when there is a clear strategy that everyone is aligned on. It takes a lot longer to get a project done when the strategy and goals aren’t clear and aligned. Strategize first, move next.
DICE instead of RACI
D = who decides?
I = who’s informed?
C = who’s consulting on this work? (but doesn’t have the final decision)
E = who’s moving this work forward?
Most organizations use RACI, but it doesn’t often get at who is actually making the decisions and who is actually doing the work. Clay Parker Jones explains this well.
Aside: I realize that the above advice might seem contrary to how I’ve written about how strategy and execution aren’t a helpful distinction. The point of that essay was that strategy and execution are part of one feedback loop and that separating who strategizes from who executes makes the feedback loop longer, making it slower for teams to learn.
While I believe this is how organizations should ideally work, many organizations don’t even have alignment on who decides vs who does the work. Replacing RACI with DICE is a great starting point here. That’s why I support it! First, shed light on who decides. Then, help the org see if it’s even worth it to have the decision maker and executer be different people. To get to the latter, you have to do the former.
Start with as few meetings as possible, and then introduce more as needed.
Introducing tons of meetings with tons of stakeholders immediately makes everyone feel obligated to attend. Do I need to be in this? What’s on the agenda?
Avoid pre-empting meetings you think you might need. Instead, start with a weekly cadence, and introduce new meetings with your team as you all sense a need. Minimum viable process, baby.
Work in public
Default to your work and drafts being searchable. Share your work often. Nothing should be gatekept or secret unless there is reasonable justification to do so. Otherwise, default to working and communicating in public. Encourage your leaders to do this too.
Revisit your strategy and assumptions often
This is something we talk about more than we do. Put it on the calendar to revisit your project’s initial assumptions, hypotheses, and strategy. When? Midway through the project, monthly, quarterly, whenever. Just get it going. Retros help!
Better, rather than perfect
Improving communication patterns takes different forms! The practices above are a good place to start.
Your goal is better, rather than perfect. Don’t worry about communication being perfect. Focus on nudging better communication and you’ll see change.
What I’m Reading
Escape from the feature roadmap to outcome-driven development
Operating well – what I learned at Stripe // thank you Alex for the send!
The viable opposite // thank you Conor for the send!
See you in two weeks,
–tim