Separate your concerns
Rather than tackle multiple concerns at once
Welcome to The Overlap, a biweekly newsletter somewhere between product development and organizational development.
Before the essay, an announcement: I’m facilitating another workshop with Index on facilitation. It’s on July 29th, 4-6pm ET. If you missed the one we hosted in June, come to this one!
Today, we’ll talk about a small hack that can help you design more adaptive organizations: separate your concerns.
Consider this scenario.
The design team is overworked. They’re constantly getting requests from marketing to make changes to the design. Marketing has no idea how much is on the design team’s plate, and the design team hasn’t visualized their work for the rest of the org.
The design director asks both teams to use Trello to visualize their current goals and work in progress. Both teams agree this is a good idea. Nice! The design director is feeling good about themselves — problem solved!
Weeks later, the design director hears that their team has no idea where the most recent copy lives. The design team constantly bugs the marketing team lead for copy.
So, the design director asks the marketing team lead to link the docs of the most recent copy on their shared Trello board. The marketing lead agrees.
But now, the Trello board is being used for both a) file sharing and b) tracking work-in-progress. A design team member on the Type A side hates how the Trello board is getting cluttered and creates a separate board for receiving copywriting for their design work.
The marketing team sees their docs in two different boards, confused about which board to use for what. Both teams finally meet and decide to use one board for updated copy and another board for tracking the design team’s work-in-progress.
Madness. Both a) sharing updated copy and b) tracking design’s work-in-progress are separate problems. Each problem should have been solved separately, with both teams involved in solving it.
Separation of concerns
If you’re in a leadership role, you like to solve problems. You also like to solve problems efficiently.
This can lead to solving multiple problems at once. Watch out for this. It’s an anti-pattern!
Instead, separate your concerns. This helps you solve each concern independently, and reduces the dependency on having to make changes elsewhere.
Separation of concerns is a programming principle. Separate your program into different sections that each address a single concern.
If your app needs to display certain items to your user, and if your app needs to format these items in a certain way to make them more noticeable, you don’t want to write logic in the same place for these two distinct concerns.
Separation of concerns makes it easy for programmers to design a modular, flexible system. The system is loosely coupled, meaning that when we have to make changes in the future, we won’t need to make changes in more than one section. Each section is independently changeable.
Separation of concerns applies to designing organizations, too. In the same way that separating concerns help programmers design a modular system, separating concerns help product managers design a modular organization. You can easily construct and reconstruct, making it easy for you to adapt your organization when it encounters new information.
If you read prioritize cohesion, then uncouple, you’ll remember that the roles, processes, and policies of adaptive organizations are loosely coupled. Making changes to one role, process, or policy won’t affect other roles, processes, or policies.
Separating concerns fosters more adaptive organizations.
I’ll give you an example of how we try to separate concerns at Manhattan Hydraulics.
Separating concerns at Hydraulics
Like many design teams, we do a Design Review every Wednesday. Design Review is our space to give and receive feedback on design work, ultimately making our work better. Devin Halladay introduced Design Review in September 2019 when we first formed our team.
To get feedback in Design Review, we signed up ahead of time. We linked files to our work and specified the feedback we needed. Signing up ahead of time gave us visibility on who’s presenting, what they’re presenting, and what feedback they need most.
When we actually did Design Reviews, it was awesome. Our team got useful feedback that made their work better.
But over time, we stopped signing up for Design Reviews.
We got busy.
Because we stopped signing up for Design Reviews, we didn’t have work to give feedback on. This meant that we had a weekly meeting on the calendar with no agenda, and like any team, we started using this weekly meeting for non-Design-Review-related discussions around hiring, staffing, and strategy.
Design Review lost its original intent: helping designers receive useful feedback on their work. As someone that often brings staffing-related problems to the meeting, I totally contributed to Design Review losing its original intent. We muddled it up with other studio needs because we didn’t create a separate way for us to address these needs.
Recently, Devin expressed to the team that he feels like we have an opportunity to repurpose Design Review back to its original concern: giving and receiving useful feedback on design work. We agreed with his concern. He’s now writing a proposal for how we can repurpose Design Review.
Of course, repurposing this meeting presents an interesting org design challenge: if we repurposed Design Reviews to its original intent, how will we address hiring, staffing, and strategic needs?
Simple. Separate each concern, and design a way to address each concern:
Hiring: What practices, rhythms, or workflows do we need to make progress with our hiring efforts?
Staffing: What practices, rhythms, or workflows do we need to make good staffing decisions? Do we need a recurring meeting? Or can this happen asynchronously, through a process?
Strategy: How are we doing against our current goals? How often do we want to reflect on and refresh our higher-level ambitions as a studio?
Separating concerns fosters organizational adaptivity
When you see different concerns in your organization, try not to address multiple concerns at once. Instead, separate those concerns, then design separate solutions for each concern.
By separating your concerns, you will continue to design an adaptive organization. You want your organization to be ready for the future. You don’t want past solutions preventing your organization from learning.
What I’m Reading
When I used to work in a Holacratic org, I used to frame concerns as tensions. Here’s a bit more about what tensions are.
Mandate Levels are a great way to specify levels of autonomy. “Build exactly this spec” is a much different mandate than “Directly generate [short-term business outcome].”
A great read on how Slack builds products.
Positive Sum Worlds invites us to redefine what “public goods” means, in the age of cryptocurrency. It got me thinking about how decentralized communities require different, non-traditional ways of making decisions so that the community is truly making decisions for the community.
See you in two weeks,
–tim