

Discover more from The Overlap
The Overlap is back! Sorry this one came out a week late.
Manhattan Hydraulics and XXIX, our two studios at garden3D, are learning to work as one design team. We’ve been doing the work of deciding how we decide. Who should have the final say in X decision? Who should be solicited for feedback when work gets shared to clients? How do we create feedback loops that improves our design work without creating bottlenecks? I’m reminded of how important it is to create space for these conversations.
Whenever humans get together to get stuff done, power emerges. Even in flat organizations. Even in self-managing organizations.
Abolishing a traditional hierarchy doesn’t mean we get rid of power entirely, it just means we get rid of positional power (that’s often arbitrary) in service of a power that’s based on expertise, influence, and reputation.
Most flat companies try to move quickly. And because of wanting to move quickly, they don’t articulate how they ideally want power to work in the organization. Power becomes soft, inexplicit, intangible. It’s not clear who you should go to for, say, accessibility best practices. Or article ideas you have for the company’s Medium publication.
I’d be the first to say that traditional hierarchy is broken. It creates more decisions than it makes. It separates the doers from the decision-makers, leading to more decisions being uninformed by actual customer feedback/context.
But there’s an upside to a traditional hierarchy. It’s easy. We all know how to operate within it. When we were kids, we asked for permission from our parents to play video games on a weeknight. When we were in grade school, we asked for permission from the teacher when we had to use the bathroom during class. When we worked our first retail job, we asked our manager how to close up shop. Hierarchy has been ingrained in us since we were young.
That’s why self-management is hard. You have to decide how we decide. Without deciding how we decide, everything feels unclear.
Fortunately, some tools can help us decide how we decide. Here’s two that can.
Autonomous, advice, and consent-based decisions
One helpful question: of all the decisions your organization makes, which decisions should be…
Made autonomously. These decisions don’t need input and should be made without permission. If you’re unsure, go with your best judgment. If it’s wrong, it’s okay, and we’ll learn!
Made with advice from others. These decisions should be made with advice from folks who have the most expertise related to that decision. Advice = feedback that acknowledges you own the final call at the end of the day. Advice ≠ asking for permission / seeking approval.
Made through consent from relevant stakeholders. These should be the murkiest, most complex, and most consequential decisions. If you can’t reverse the decision, it should have the consent from the most relevant stakeholders. Consent ≠ consensus, here. Consent is “This is safe to try. Even if I disagree with it, I consent to it moving forward, knowing that we can always reverse this decision.” Learn more about this here.
For example,
80% of decisions should be made autonomously
15% of decisions should be made through an advice process
5% of decisions should be made through consent from relevant stakeholders (using Integrative Decision-Making).
I’m not saying 80%, 15%, 5% is the right ratio for your org. Every org is different. I’d discuss it with your org, and come to an alignment there. But if you’re unsure, err on the side of most decisions being made autonomously, so that you can move quickly.
Clarify decision rights between leaders and teams
Another practice: clarify decision rights between leaders and teams. Because oftentimes who owns what decision is murky between a leader and a team.
Say a leader tasks your team to work on a specific initiative. Your team is excited to go off and move it forward.
But as your team makes progress, you encounter some questions that require the leader’s input. Can we hire another teammate to help us with this work? It feels like a lot. What if we need additional budget to do this successfully? Can we try using a different framework than what our engineering team usually uses for this one initiative? Oooh… what about this direction, has leadership considered this?
Now imagine you’re the leader. The team is pinging you with *tons* of questions. You need to sit and think them through. But you don’t have time to answer them because… look at the time! You’re late to your fifth meeting today!
You all need to gather. And ask two questions:
What can we do autonomously?
What must we get the external approval for?
Then collectively make a list of decisions that go under each category.
Make sure you don’t leave that meeting without discussing the murkiest decisions. What decisions from past initiatives have felt murky? What decisions were back-channeled and not addressed as a group? Discuss those, and decide which category that decision belongs in.
Four areas that could get the conversation going:
Staffing — if the team wants other teammates to join them and help, can they make this decision without external approval?
Example: pulling other team members into this initiative can be done autonomously. So long that the other team member is fine with their level of commitment. This doesn’t require external approval.
Hiring — can the team hire an additional teammate without the leader’s approval? Or does the leader need to be involved, and if so, when do they need to be involved?
Example: hiring new team members for this project is the team’s call, so long that they don’t exceed the budget for this initiative.
Tools — can the team decide on which tools they use for this initiative? Do some tools require external approval? Are some tools a hard requirement for this project?
Example: the frameworks we’ll be using for this project are React + NextJS. Our existing design system is built atop React, so choosing a different framework will be more trouble than it’s worth.
$$$ — if the project requires more budget than initially allocated for, should we seek the leader’s input? What would be good reasons to increase the budget on this project?
Example: asking for more budget needs external approval. To make this approval as seamless as possible, the team should propose a specific amount of budget they’ll need and make the case for how this makes the project more successful. The leader has to ask the finance team for additional budget.
Get so explicit it feels uncomfortable. That’s how you know you’re doing decision rights right.
Mature organizations acknowledge power dynamics
Make it okay to talk about the power dynamics that are present in your organization. Accept some as reality. But question those that are in the organization’s way.


The org I work at, garden3D, is trying to get better at talking about power dynamics. We had Gabe Wilson run a workshop with us on this. We know it’s uncomfortable, but we know it’ll help us mature as an org. I’ve been super proud of how everyone is showing up in this conversation, and how we’re all okay with talking about dynamics that are in the way of garden3D realizing its vision.
Podcasts I’ve Listened To Recently
Melissa Perri’s product thinking podcast has quickly become one of my faves. And it’s cool to see self-management principles applied to DAOs.
What I’m Reading
Long Pressed’s website — org design x non-linear notetaking. Shoutouts to Devin Halladay for the send.
John Cutler’s Product Org Expertise — cool to see someone understand how to clarify tacit knowledge of an org designer.
WTF is strategy? — good reminders on how to craft a strategy.