Not everyone cares about org design
The Overlap #45
The Overlap is a newsletter somewhere between product development and organizational development. It comes out every other Wednesday. Although today’s was released Thursday. Busy week!
As a reader of this newsletter, you probably think about org design all the time.
You see every meeting is an opportunity to assess how the team communicates and makes decisions.
You see every budget decision as an opportunity to talk about how traditional budgets are harmful, and that there are better ways to do it.
You see every conversation about compensation as a way to “nudge the system” towards fairness and transparency.
But not everyone cares as much about org design as you do.
Some people see org design as management. They’re not interested in management. They just want to make. Or stay an IC.
I sometimes talk about org design with close friends who’ve worked in large tech companies. These friends have stayed an IC for as long as possible, avoiding any opportunity to become a manager. Org design doesn’t interest them!
Maybe your coworkers are enthusiastic about your ideas. But when you ask them to lead a change or an initiative, they’re hesitant to take it on. “Sounds interesting. It’s just that I have three other tickets to close, new feature requests from the PM, a Figma file to weigh in on, a technical spec to write, and holy shit this bug I’ve been working on for hours still isn’t fixed.”
I don’t mean to “other” developers. Or designers. Or content writers. I know developers, designers, and content writers who think the how of work is fascinating.
I’ve just learned that it doesn’t fascinate everyone. And that’s okay. Sometimes marketers love marketing, data scientists love data, developers love developing, and designers love designing. They all philosophically agree with you. But at the end of the day, they focus on their craft.
“What have they experienced that makes [this idea] intuitive to them?”
Org designers get frustrated when others don’t “get it.” Why don’t you get that this is a better way!?
Here’s what we forget. We’ve gone through experiences that make it intuitive for us to believe in outcomes over outputs. Or starting with a product strategy. Or sharing work before it’s finished. Or PMs-designers-developers starting and finishing as one team. Or getting rid of traditional fixed budgets. We can be so gung-ho and hyperlinky about our beliefs.
Here’s what we also forget. Others have beliefs that aren’t intuitive to us because we haven’t gone through their experiences.
To others, outputs prove to their leaders that their team is doing good work, which rewards them with more budget. Outputs help developers get promoted, even when those outputs have little business impact. Design and developer collaboration sounds great in theory, but their org siloes designers and developers into their own orgs, disincentivizing collaboration. And that they tried including developers in discovery before, only to find that developers were insecure about their contributions in discovery, so now they don’t include developers in discovery anymore.
Better understand the perspective of others who don’t share the same beliefs as you. Flip John’s framing into “What have they experienced that makes [this idea] intuitive to them?”
Adam Grant wrote about how when you disagree with someone, question the how, rather than the why. When you ask someone why they believe what they believe, they intensify. They get defensive. When you ask them how they formed that opinion, they’re more willing to temper their own opinion. “How did you arrive at that perspective? What was the experience you had that led to your belief?”
I don’t want beliefs to be shoved down my throat. So how could I expect others to be open to ideas that are intuitive to me but not to them?
Find out about what others care about
What I’m not trying to say is to stop being a change agent. I want you to be an agitator of change.
What I'm saying is: find out what people care about most. Learn about the experiences they’ve gone through. Listen.
If you do this, you can help them see the way you view work. But you’ll help them see what you see through the lens of helping them do the thing they care about more — having more time to code, more time to write, or more time to focus on the business. People find it hard to follow decentralization or consent-based decision-making or outcomes over outputs. But when you start with learning about what they care about and then suggest a practice or experiment to help them do that thing they care about more, you’ll learn that they do care about org design. Just not in the way you would expect.
What I’m Reading
My team, Manhattan Hydraulics, just published our first year in review.
“If someone cannot shield their direct reports from BS above them, or they cannot manage up for the wellbeing of their team they shouldn’t be a manager.” And it hit me. Really? Why is BS the norm?
Why Sh*t is Hitting the Fan. Helped me better understand why tech is taking a hard hit now. Paid post, but well worth it.
See you in two weeks,
–tim
After months of struggling to make people understand even the simplest org design concept — they didn't understand for months my objection about their teams not being real teams — I showed them how we could do a simple knowledge matrix of their "teams".
It was a game changer, it immediately became their favorite thing and now they want to use this practice even before they form teams (a kind of use that I didn't think about) in order to, well, take better org design decision.
Granted, like many companies, they have an ongoing organizational transformation based on the usual mishmash of organizational models, but right now they are focusing on how knowledge is spread throughout their company, because that's what they care about the most.