I learned how fundamental this book was to tech. Its basic premise: make it as easy as possible for users to complete a flow. They shouldn’t have to think. This thinking is baked into the apps you and I use today. Amazon Prime’s one tap purchase. TikTok’s feed. We barely think when we use our phone.

I see this same principle baked into the way AI tools are designed. Everything is a chatbot. Everything. That’s because we all know how to interact in chat.

Claude Code is great. I use it every single workday. It feels like play to me.

I’ve used GenAI to diagnose car troubles, dog sicknesses, strategize my savings goals. You name it.

Where I struggle is when I’ve used it to skip the part where I think.

Not only is the work not getting the best part of me. But I feel disconnected from the output itself. I just write some words, receive a result, put that in a doc somewhere, and then it’s... done? That’s it!

Behzod wrote recently: Be romantic. AI isn’t that romantic. It wants us to go straight to the chapel before even having a first date. Where’s the romance in that?

Conversations with coworkers and friends revolve around a similar theme. It speeds up work tremendously, and can even do some complex things. But when we use it to do the thinking, we’re less convicted in the result.

I’m not criticizing the immense progress in generative AI. The tools are amazing. I just think we should be using them to help us think better, rather than think less.

John Cutler had a really great quote: Diagnose, before automate. That’s sort of my new mantra. I feel like everyone is using it to automate automate automate. We gotta save time. For what? What do we do with our newfound time?

Everything above can be sharpened by asking three questions about any behavior you’re considering handing to AI. Is it a capability problem? Is it an opportunity problem? Or is it a motivation problem?

Using AI to make a dashboard won’t work when the humans have to change their behavior to keep their dashboard up to date. Behavior change still requires… humans.

Diagnose, before automate. Why are we using this tool? What do we hope to achieve as a result?

That’s the exact part that requires your brain and my brain. You can use the LLM as a thought partner here, but I wouldn’t offload this part to the robot. The thinking needs you.

There is good, difficult, strategic work to do that requires your brain and intuition. Building trust, navigating a tricky power dynamic, fostering psychological safety, encouraging and trialing a new way of working, working towards the same thing, navigating failure and learning together. I’m certainly biased, but those things are really hard to accomplish with a Claude Skill. They help, but ultimately we’re doing this work.

Taste is the new buzzword. OpenAI hires for it. Paul Graham says it’s your main differentiator. But a 2024 study showed that Generative AI enhances our individual creativity, yet reduces the collective diversity of novel content. (Thank you to my coworker Cara Moyer for sharing this study.)

I suspect everyone will develop their individual taste, but collectively… everything will continue to look the same. In a similar way tech bros wear black tshirts, corporate memphis became the norm, and every app became a chatbot.

Your taste, judgment, and creativity comes from you being a human. Trying something that didn’t exactly succeed, being inspired outside or in a museum or on top of a mountain or in a conversation with a friend. Living your best life boo boo.

As generative AI continues to blow our minds, the future becomes more uncertain. Friends of mine looking for a tech job feel hopeless about finding their next. Friends of mine in tech question their job security. There is this lightweight stress going around that no amount of taste or prompting can solve.

I’m not really sure where this will lead to, but I’m going to continue thinking. Please make me think.

Org design is one of those jobs people pretend to understand.

• “So… HR consulting?”

• “Change management?”

• “Reorgs?”

Close. But not quite.

I’ve used many definitions, depending on who I’m talking to:

• “I help teams work better cross-functionally.”

• “I help organizations strategize better and work well.”

• “We make the right things easier to do and the wrong things harder to do.”

At some point, I stopped trying to perfectly define it. People don’t really understand org design until they experience it. Honestly, I didn’t either when I first started at The Ready ten years ago. I only understood it by doing it.

The Default Path vs The Pathless Path

I just wrapped up a team engagement in Korea. Over shabu shabu, my fiancé and I were reflecting on how people who do things like us don’t really have legible job titles. Kayla has had many job titles throughout her career: art gallery manager, educator assistant, philanthrophy event strategist, and now is an end-of-life practitioner. (My mom often says “Kayla’s strength is connecting the dots.”)

Our conversation got me to reflect on my weird path:

• I started as an org designer at a small firm,

• then moved into product management,

• then did my own consulting with nonprofits

• while pursuing my life as a climber

• and now am a full-time org designer at Airbnb.

We’re big proponents of the pathless path, a term that writer Paul Millerd coined.

The pathless path ≠ the default path. The default path is what we’re taught in schools (and taught by immigrant parents if you’re a child of immigrants). Get good grades. Go to a good school. Find a decent job. Climb the corporate ladder. Eventually one day you will have enough to be happy.

The pathless path is about actively experimenting with different kinds of work. And trying on new identities. From Paul’s book:

“On the pathless path, the goal is not to find a job, make money, build a business, or achieve any other metric. It’s to actively and consciously search for the work that you want to keep doing. This is one of the most important secrets of the pathless path. With this approach, it doesn’t make sense to chase any financial opportunity if you can’t be sure that you will like the work. What does make sense is experimenting with different kinds of work, and once you find something worth doing, working backward to build a life around being able to keep doing it.”

The pathless path resonates with me on a personal level.

But now I’m starting to think… to be an org designer is to embrace the pathless path. We’re constantly experimenting with new frames, new ways of seeing, new ways of intervening. The path of an org designer isn’t linear… it’s constantly solving ambiguous problems. And learning from past problems as you move to the next.

Well-defined work is going away, ambiguous work is here to stay

I used to get impatient when people didn’t understand what I did. I’d overexplain. Send blog posts. This was all to my own detriment. “Why don’t they get it?!”

The ambiguity isn’t our deficit. It’s our strength.

The real skill of an org designer isn’t having the answer—it’s helping people see the problem clearly enough to act. More often than not, the problem isn’t well-defined.

Tom Critchlow has a framing I keep coming back to:

AI is taking on more well-defined work. Which means… more of us are doing ambiguous work.

That kind of work doesn’t neatly fit in a JD. Maybe we’re all org designers?

The career ladder is now a climbing wall

What’s fascinating is that now leaders are talking about this shift.

At Airbnb, our CHRO Iain Roberts was a designer before moving into HR. And Aneesh Raman in his conversation with Iain put it well:

“The ladder’s done,” said Raman. “Think about this more like a climbing wall. ... Worry about what you’re doing today to get better at the tools that you’re using and get better at defining your unique curiosity and capability.”

As a climber, I love this analogy.

You don’t just go up. You move laterally. You try new problems. You experiment. You fall. You try again.

You stop caring about your job title and care more about the work.

We understand complex systems and intervene

After we paid the shabu shabu bill, I found this old note I saved from a 2016 Fast Company 2016 article:

Interventionist

Nominated by Ashlea Powell, location director, IDEO New York

Interventionists are already in our midsts, we just haven’t named the role or cultivated it. As organizations and their challenges become more networked and complex, it will be harder work to help them digest new ideas and build towards a better future. This is the work of an Interventionist, and it’s time that the craft of intervention design takes shape, whether it’s designing an experience that creates transformational empathy or hosting a conversation that puts an end to polemics. These designers will come from backgrounds in organizational psychology or behavior change and be experts in facilitating creative conversations, framing unexpected questions, and navigating the uncomfortable.

I remember feeling that this decsribes what I do better than I ever could.

We’re not just designing org charts and running workshops.

We understand complex challenges and intervene.

Org design doesn’t fit neatly in a job description. That’s the point.

🚝🚝🚝

What I’m Reading

1. Jeanne Bell on how nonprofits can be more cross-functionally structured. And aligned towards a clear strategy. Psyched to see OD thinking in the social justice world. Great essay Jeanne.

2. My colleague Cara Moyer on what athletic/dance training can teach us about performance. “Professional athletes spend most of their time training so that performance, when it comes, is almost effortless, or at least legible as effort. Corporate reverses the ratio and then labels the exception as a basic participation trophy.”

3. Related to my own climbing training: Intentional improvement > chasing fatigue. A quote I’ve always applied to my climbing training, but also see in organizations too. How can we intentionally improve, rather than chase busyness?

4. Permission to Move by Clay → them slides tho. Also, his new book is a delight.

5. The Resilience Paradox. As a self-identified resilient person, I’ve always reflected on when my own resilience wasn’t serving me. Anne-Laure Le Cunff has research to back this up.

6. John Cutler and Sam Spurlin chatted about the beautiful mess of product and organizations. Worth a listen.

I first heard “slow is smooth, smooth is fast” from an old coworker, Spencer Pitman. Spencer had a fascinating background: head of product, strategy consulting, engineering, and… climbing guiding.

“Guiding in the mountains taught me everything about guiding organizational change,” he told me. Preparedness. Assessing risk. Having a plan but adapting when circumstances change. All of it applied directly to the org design consulting work we did together.

On every engagement, he’d say to our clients:

Slow is smooth, smooth is fast.

Eight years later, I’m (coincidentally) training to become a climbing guide myself. In my guiding courses, my instructors say that phrase.

Slow is smooth, smooth is fast.

I’ve grown to appreciate the phrase more with experience.

I mean… I learned it the hard way.

One time, Ivan and I got benighted. We unexpectedly had to spend the night on the wall. We took much longer than we thought to complete the climb and couldn’t find the rappel rings once it got dark.

We were climbing in Yosemite(East Buttress of Middle Cathedral if you’re curious). We started at 10am, fully convinced we’d be up and down before sunset. I left my daypack at the base because there were chimneys (yes, like Santa climbing up a chimney). Before starting the climb, I thought that I’d move faster through the chimneys without a pack. So I left my pack at the base.

That pack had my headlamp.

That mistake meant I climbed chimneys in the dark. We moved slower than planned, lost daylight, and ended up sleeping on a ledge. With ants. Thankfully, it didn’t drop below 37°F that night.

Basically our desire to climb this fast delayed our completion by an extra day. We wanted to go fast, which led to us going slow. Thankfully our friends had prepared us ramen that morning.

It’s the same with organizational change

Our desire to go fast can lead us to go slower than we’d like.

I’ve seen teams move quickly into new operating models before decision rights were clear, shared context existed, or team membership had stabilized. Not getting the results we want? Reorg. Six months later, leaders were frustrated that nothing had sped up.

In reality, they’d optimized for motion. Not smoothness.

You’ve probably experienced:

• A reorg that shipped before decision rights were clear

• A strategy announced before teams had the context, resources, or capacity to execute

• A leadership team that canceled retros last-minute to “give time back”

My job has often been to help organizations slow down and practice on purpose.

Ambitious goals or new directions require unlearning old habits and practicing new ways of working. That practice will feel… slow. At first. That’s not a bug. It’s a feature.

Because when we do it right, we become smooth. And smoothness is what affords speed.

The Curse of Knowledge

According to the Accidents in North American Climbing reports published by the American Alpine Club, the majority of reported climbing accidents involve experienced climbers. Not beginners. And most are caused by human error rather than gear failure. Belay mistakes, rushed rappels, and skipped safety checks dominate the reports.

From a 2000 paper, Staying Alive, written by a former National Park Service Search and Rescue member:

Most Yosemite victims are experienced climbers: 60% have been climbing for 3+ years, lead at least 5.10, are in good condition, and climb frequently. Short climbs and big walls, easy routes and desperate ones—all get their share of the accidents.

The common thread isn’t lack of skill. It’s familiarity. Routine. Speed.

Experienced climbers want to move fast. I mean duh, we know how to do this. But I’ve known friends of friends who literally lost close ones because they didn’t finish tying their figure-eight knot and skipped safety checks before leaving the ground: things we learn on day one.

I know this is bleak, and organizations aren’t exactly in these high stakes scenarios. But it’s the Curse of Knowledge: the longer we do something, the more susceptible we are to assuming we already know how it works.

I’m not immune to this. If anything, being both an experienced climber and an experienced org designer probably makes me more vulnerable. I also am naturally a fast person. But familiarity breeds confidence, and confidence is often when we stop checking our knots.

Slow is smooth, smooth is fast in practice

The real challenge is this: how do we slow down when there’s enormous pressure to go fast?

A few places to start. (And I’m curious what’s worked for you, too.)

1. Name experiments explicitly.
   “In this meeting, we’re trying a new structure. The goal is to improve visibility into our work. It’ll feel clunky at first, and we’ll use the last five minutes to reflect on what worked and what didn’t.”

2. Limit experiments in progress.
   Do less at a time.

3. Never skip retros.
   Skipping retros is a sign you’re choosing speed over smoothness.

4. See the problem before solving it.
   Resist the urge to fix immediately. Get on a call. Hear how others understand the problem first.

5. Refresh strategy on a regular cadence.
   If you’ve never done this, quarterly is a good place to start. Here’s a template you can use.

6. Build reflection into weekly meetings.
   End with a moment for observations. Over time, reflection becomes a muscle.

Slow is smooth, smooth is fast isn’t about being overly cautious. It’s a reminder that speed is an outcome. Not an input.

In climbing and in organizations, the fastest teams I know are the ones that rehearse deliberately, reflect relentlessly, and treat fundamentals as sacred—especially when they’re under pressure (or put pressure on themselves) to perform.

Things I’m Reading

1. “What is it that streams can teach me about organizations? I am attracted to the diversity I see, to these swirling combinations of mud, silt, grass, rocks. The stream has an impressive ability to adapt, to shift the configurations, to let the power balance move, to create new structures.” —Margaret Wheatley. Leadership and the New Science is written for the environmentalist org designer.

2. Finally took the time to learn about Wardley Mapping.

3. Daily org design donuts from Clay’s OD Radar. Sharp as always.

4. Sam’s “The Case For Building an Internal Org Design Capacity” mirrors a lot of my experience being internal now.

Disclaimer: my views on this newsletter continue to be my own and not Airbnb’s views as a whole.

It’s week 6. My coworkers say that Airbnb years are like dog years. 1 year feels like 7. I feel seen—these six weeks have felt like 42!

I’m learning a lot. And I’m relearning.

Which is getting me to reread.

Rereading old essays my younger self wrote.

And wow! Why did I write it that way?! But damn. That still hits.

I’m starting to think about the overlap between service design and org design. From Mind the backstage and frontstage in 2022:

I used to facilitate a lot of journey mapping workshops. My first two journey mapping workshops generated lots of great ideas! But I still felt like it wasn’t clear how we would deliver those ideas.

[…]

I realized that I over-indexed the workshop on the user experience and under-indexed on the organizational experience. Lots of amazing ideas. But which ones can we feasibly pursue given our current resources? So in my next few journey mapping workshops, I started to hold more space for how we as an org can deliver on those ideas.

“You should talk to so-and-so from the service design team. They see things the way we do.” Part of my onboarding is to meet the service design team. Our teams have worked together on some important work. Re-reading this old post, it makes sense: Service design and org design go hand-in-hand. 🤝

Which brings me to minimum viable process:

Many times, process is useful! Think about when you need to make a presentation. You just want to know what typeface, font size, and colors to use. You (most likely) don’t want to have to design the deck’s template as you’re designing the deck.

But other times, process creates more work than it accomplishes. Maybe we’re overreacting to a circumstance that may not happen in the future. Or maybe we’re creating a bandaid solution to solve multiple problems. When we instead need to clarify our defaults or separate our concerns.

Earlier in my career, I used to quick attack process like a level 16 pikachu. This wasn’t always helpful.

But process does protect confusion! It gives teams clarity on how things get done. So I no longer quick attack process. Instead I try to communicate our goals, offer support, and trust that that’s enough. At the end of the day, teams will figure out what works for them.

And speaking of goals… I’m reminded that strategy starts from a set of constraints.

When the constraints are clear, teams feel free to decide how to pursue their goal. Constraining a problem enables (rather than inhibits) autonomy. 

It’s easier to form a strategy when the constraints are clear. And not every constraint can be clear, that’s ok. We can name constraints that aren’t clear—strategy is also about owning what we don’t know.

A capable, willing team

Lastly, it feels great to be a part of such a capable, willing, and caring team. Everyone is bringing their a-game. I learn something new every time we make sense of something together. As org designers & developers, we instinctively see the problem before we solve it.

Being back at work full-time has activated my writing brain again. Which brings me to my last thought that’s been staying in my brain rent free the past six weeks.

Why do I write?

Am I writing solely for me? For me and the people around me?

Do I feel the need to because Everyone Else On LinkedIn is Writing?

Is there a part of me that doesn’t want to admit that I appreciate the affirmation?

Is it because I’ve always told myself “I’m a writer”?

Dani Offline’s essay on DJ’ing got me thinking about writing:

Another definite reason so many people seek the troubled social status of “creative” these days is because it’s easier than ever to become one. The democratization of this pursuit is, on one hand, a beautiful thing. But it’s also incredibly lucrative to those who supply the means of production. As creation gets conflated with entrepreneurship, making art becomes an experience, a *lifestyle*, to be bought and sold. The subtle injunction to network, curate, and fetishize ourselves (and spend as much money as we can afford along the way) can’t be good for us.

The problem is not that everyone wants to be an artist, it’s that enjoying art with other people for the simple, loving pleasure of it all has become devalued. If that’s the case, what are we even doing all this for? Why be an artist at all if we can’t enjoy the things we create?

This author is talking about DJ’ing, people who self-identify as “creatives,” and how brands have responded to creators on the internet. I think the same is true with writing on the internet: everyone’s writing but few people enjoy the reading? My friend Maceo said once that we live in an intellectual drop culture where we value the quick take rather than the long conversation that actually might not result in a 280-character post. Lightweight depressed, he said. Due to intellectual drop culture.

I started writing online in 2015 because I really enjoyed what I read at the time. The writing moved me in ways day-to-day life couldn’t. It shaped the direction of my life. I started writing, which led to an org design job in New York City, which led me to relationships that brought me to where I am today.

Can I have that same impact on others that writers have had on me?

I want to keep writing because I’m still moved. The dancefloor may be empty, but it doesn’t have to be here. There are other writers out there who write because they enjoy it. It’s just how we think.

It’s hard to say that writing is entirely an intrinsic pursuit… but today, LinkedIn takes and even Substack posts feel like it comes from a place of should rather than a place of pleasure. I want to be happy with what I put out there, I want to enjoy the process, and I want that for others too. Otherwise, as Dani wrote, “Why be an artist at all if we can’t enjoy the things we create?”

I’m really impressed with Vaughn Tan’s writing on uncertainty. He points out that most organizations confuse unknowns with “risks”, which blinds us to the real nature of uncertainty.

Risks mean we know possible worst-case scenarios and how to plan for each. Everything is measurable. But treating uncertainty like risk stops us from seeing the problem clearly before solving it. If uncertainty was truly a risk, we’d be able to predict the LA fires that happened in January 2025. Truth is, we didn’t know that would’ve happened.

Vaughn defines four types of unknowns, or as he calls them, four types of non-risk non-knowings:

1. Not-knowing about actions: This arises from uncertainty about what actions or possibilities new and existing technologies offer. For example, when a company faces a new technology, it may be unclear what can actually be done with it or how to deploy it effectively. The broad approach here is to run many small, intentionally diverse experiments as a portfolio to explore the space of possible actions and discover new affordances.

2. Not-knowing about outcomes: This involves uncertainty about what outcomes can be achieved or are even imaginable. Outcomes may be feasible but not yet imagined, or imaginable but not yet feasible. For known outcomes, experimentation through portfolios works well. For novel or unprecedented outcomes, structured imaginative techniques such as speculative fiction or scenario planning help expand what’s considered possible.

3. Causal not-knowing: This concerns uncertainty about how actions lead to outcomes, including when multiple causes exist or causality is inconsistent. When causal relationships are resolvable, traditional hypothesis testing and structured experiments apply. When not resolvable, it may be more effective to try many varied small interventions and optimise for directional movement rather than precise control (“stacking the deck”).

4. Not-knowing about values: This type deals with uncertainty about how much an outcome is worth—subjective and often contested judgments that can change over time or differ across stakeholders. Approaches include reasoning, argumentation, negotiation, and setting broad, flexible goals that can accommodate diverse values and changing norms.

Why does this matter?

These four types help us recognize which unknown we’re dealing with, so we can design smarter experiments.

I’ve always approached org design and strategy as experiments: What level of risk will we take to learn X?

Vaughn’s thinking refines that to:

What risk will we take to learn about a specific action, outcome, causation, or value?

Experiments aren’t just throwing spaghetti at the wall. They’re about clarifying what we don’t know, what we want, and how to move toward it.

I’ve used this statement with teams, which I got from Lean Change Management:

By [implementing this change]

We will see [this result/outcome]

As [measured by these metrics]

With Vaughn’s four types of unknowns, we can go deeper. Not just “will we see this result?” but “what specific unknown will we learn more about?”

Here’s a new hypothesis sketch:

By [implementing this change]

We expect to learn more about:

• Action – what is actually possible here?

• Outcome – what might be achievable or imaginable?

• Causation – how (or if) this action will lead to that result?

• Value – what is this result worth to us/others?

As measured by [these signals or indicators]

And we’ll know we’ve learned something when [this happens].

Tagging experiments by their type of unknown keeps us honest about what we don’t know—and stops us from treating a foggy unknown like a clear risk.

It also lets us layer learning: an experiment about action might reveal unexpected outcomes or shift our sense of value. Naming the type upfront sets us up to see pivots as part of the journey, not surprises to fix.

Maybe this helps teams focus on what’s really going on rather than what we think is going on.

Example Experiments

Just to pressure test this updated hypothesis statement, let’s ask GPT-5! Hey chat, give me four example experiments for each unknowing type using this new hypothesis statement.

1. 4-day workweek pilot
By launching a 4-day workweek trial for one team over six weeks

We expect to learn about: Action — what operational changes and workflows actually work in a compressed schedule without sacrificing output.

Measured by: project delivery rates, employee feedback, and customer satisfaction.

We’ll know we’ve learned something when: we have a clear sense of which tasks and processes adapt well, what blockers arise, and where support or redesign is needed.

2. Cross-functional product team
By restructuring two teams into one team for a quarter

We expect to learn about: Causation — does tighter integration speed releases?

Measured by: time to launch, handoffs, clarity of roles in retrospectives.

We’ll know we’ve learned when: a clear pattern links structure to speed or quality emerges.

3. Onboarding completion through progress bar tracking
By adding progress tracking bar to onboarding for three months

We expect to learn about: Outcome — whether more users will complete onboarding and thus, we see increased retention.

Measured by: completion rate, session length, churn rate.

We’ll know we’ve learned something when: completion rate increases/decreases, churn rate decreases/increases

4. Pay-what-you-want workshop pricing
By running a pay-what-you-want experiment

We expect to learn about: Value — what participants are willing to pay when given choice.

Measured by: payment distribution, sign-ups, feedback.

We’ll know we’ve learned when: the data shifts our pricing conversation—validating, challenging, or revealing new tiers.

Not bad, robot.

This is still early thinking!

Of course, the true test of this lies in the work. I’m excited to try this in my own work with clients.

In a world where “being able to navigate ambiguity” is seen as a core competency, being clear on what we don’t know and designing how to learn is a core practice.

Have you approached experiments in this way? How have you helped your teams navigate the unknown?

What else I’m reading

1. I’ve always thought about the role of luck in climbing, careers, and even organizations. Luck plays a huge role in the outcomes we want. Cate Hall says we should increase our surface area for luck.

2. Navigating by aliveness — “will this job, project, trip, or opportunity take me in the direction of aliveness or away from it?” A beautiful question.

3. Clay’s Five OD Things is so well-synthesized. You should subscribe.

4. The product design talent crisis. It’s a tough time to be a newer product designer right now. On why companies should invest in different ways to grow their junior designers.

5. And relatedly… Designers! Designers! Designers! “What companies want isn’t just a designer, but someone who can own outcomes end-to-end: set direction, make decisions without committee drag, and ship.” A good explainer by Carly on why the talent marketplace is flooded and yet there is still demand for senior design talent.

At least, I used to think that. Now, after Trump signed Executive Order 14151 to “end radical and wasteful government DEI programs and preferencing,” companies are pulling back DEI efforts.

2020-2024, companies were all about diversity (or at least more concerned with being perceived as diverse). But now, I’ve seen a lot of major companies pull back on DEI efforts.

Many are scrapping their goals entirely. But thankfully, some organizations are remaining committed, even if DEI is no longer the label.

Diversity, equity, and inclusion is not optional

In 2021, we published everyone’s salary data internally after everyone consenting. Hugh, LJ, and I initiated this change at garden3D — my last company.

We opened the opportunity for anyone to object to this change, and while some felt uncomfortable with exposing their salary, no one objected. We valued transparency and fairness, and knew that making salaries transparent would reduce bias in compensation. Unfair pay is rampant in the tech industry — women in tech earn just 83% of what men earn, and racial pay gaps persist even when controlling for education and experience1. We wanted to do something about it within our locus of control.

What we found was an uncomfortable truth.

While we were more diverse in race, ethnicity, and gender identities compared to the tech industry, most folks who held senior or lead roles were white males. People of color weren’t in senior roles or higher—we were either experienced mid-level, mid-level, or junior. Why was this? Our company hired more inclusively relative to the tech industry, but our early employees and senior hires were mostly white males. As Mekka put it, we were paying down our inclusion debt.

So we began with one experiment: provide support for newer designers and developers to become project leads. We also decided to publish our DEI data publicly, sharing what we’ve learned and what we’re trying next, to both hold ourselves to a standard and be open about what we’re doing.

This took a ton of commitment, a willingness to get out of business-as-usual, and a lot of uncomfortable conversations. We even hired a DEI consultant and worked with a facilitator to help us understand how soft power influences who gets chosen for opportunities and included in decisions.

We started writing about our DEI journey in 2022. To this day, garden3D continues to share lessons from their journey.

garden3d.net

garden3d DEI Report 2024

What is garden3d…

Read more

2 years ago · 12 likes · Kelly Rogers

Over the last year, DEI efforts have been drastically de-prioritized in the tech sphere. Many major companies cut DEI programs created to support underrepresented groups as a result of tightened budgets. Reports continue to be published while the actual efforts are unclear, and the data collected still limits representation. For example, only one out of the ten biggest tech companies mentioned including any gender nonbinary statistics.

At garden3d however, we feel this work is as urgent as ever. Our three years of focused efforts shaping conditions for all people at our company to thrive has taken root, and we’re now seeing the fruits of this labor.

DEI work is org design work

Companies are going to want to pull back.

If you’re in a leadership role, don’t pull back. If you’re an organization designer, you share the same goal as DEI advocates.

DEI (or JEDI, belonging, inclusion, talent, development—however your company frames it) is more important than ever.

Lily Zheng reminds us that DEI work is 99.9% operational:

There is only one "ideology" present in DEI work done right, and it's shared by pretty much every pluralistic democratic society in our world: that everyone deserves dignity, respect, and opportunity regardless of the beliefs, values, needs, circumstances, experiences and perspectives we hold. That's it. The remaining 99.9% of the work is operational. How do we remove barriers to opportunity and fairness in the workplace? How do we meet people's many needs so we can bring out their potential? How do we create an environment where different people can come together and build something bigger than themselves?

Surprise! This is org design work.

Building more equitable processes and practices is org design work. Removing systemic barriers to opportunity and fairness is org design work. This is DEI work. This is the work.

Not only are systemic and operational efforts less legally risky in this specific moment, they're way more effective than programs focused on specific groups. If you don't believe me, believe Alexis Robertson:

Instead of viewing DEI as a set of programs focused on certain groups, view it as an effort to transform the organization through positive changes that impact everyone, while closing gaps for the most marginalized. Integrate your DEI work into all talent development work and anywhere.

Moving from the programmatic to systemic is not only the best way to minimize legal risk, but also more effective. (There’s still a place for some programmatic efforts. To the extent you have them make these targeted to specific organizational concerns and endeavor to have them open to all. If they're not open to all, work with your in-house counsel to weigh to risks presented.)

Where to start

Don’t know where to start? That’s ok. Others are wondering too. Here are some resources to get started:

1. Project Include: DEI now

2. A Resource Guide for Belonging Builders

3. Racial Justice at Work

4. Pay fair

5. How diversity branding hurts diversity

6. How to advance DEI under any label

If you have any stories about how your company is navigating this moment, I’d love to hear. Send me a reply to this newsletter.

Also — I’m taking on 1-2 new clients this summer! See my consulting work here. If you know anyone who’s building a growing team or navigating structural change, send them my way: timcasasola@gmail.com.

I recently picked up Levers of Organization Design. The first chapter introduces “Evolution and Revolution as Organizations Grow,” a model developed in 1972 by Larry Greiner, a professor at USC.

I was intrigued! As organizations grow, they encounter crises, solve for those crises, and introduce new crises from the solutions that were implemented before. It’s a good tool to help organizations get more prepared for the inevitable problems that occur as they grow.

Evolution and Revolution, Summarized

All organizations start small and young. Creativity is what drives growth. Everyone is a jack-of-all-trades, the entrepreneurial spirit is high, they’re excited to get a product/service in the market.

The growth makes things feel chaotic. Roles become more and more unclear. They miss a lot of potential opportunities.

They experience a crisis in leadership. So they instill more direction.

A structured hierarchy is introduced. Perhaps a new leader from a more established company is brought in to bring in systems and structures. Distinct functions are created: brand marketing, product operations, engineering, design, finance, HR. The company resumes its growth.

But then these functions become insulated from the marketplace. The business that once had a direct relationship with their customers now lose touch with them. Employees start to check out. It’s not fun to work there.

They experience a crisis in autonomy. So they embrace delegation.

“We need to push decision-making authority to the teams closest to the problem.” They bring in org design consultants (👋🏽) to decentralize their structure and form cross-functional teams. Standalone business teams are formed. Innovation is reignited, teams are encouraged to test and learn, and teams improve their ways of working to respond to customer needs. Growth resumes.

But then… the decentralized structure creates independent fiefdoms. Business leads have conflicting priorities, tradeoffs aren’t being made, and none of it adds up to a cohesive strategy. Coordination gets harder, budget is wasted, and profitability declines.

It’s a crisis of control. So then they grow through coordination.

Centralized coordination systems are brought back in. Head office/corporate/the C-suite reigns control. Program managers are hired. New centralized staff groups assume responsibility for planning, coordination, and resource allocation. Business leads now have to get approval from headquarters before pursuing a new strategic commitment. Things feel bureaucratic—again.

It becomes a crisis of red tape. So then they grow through collaboration.

Consultants are brought in again to reduce friction in the way they work (👋🏽). It’s all about teamwork. Let’s cut through the bureaucracy. Investments towards noncore business offerings are cut and the business refocuses on its core offering. Centralized staff groups are dismantled. They emphasize that business teams have direct accountability for results.

But then… coordination suffers again! The collaborative culture that once fueled momentum now slows everything down. Decisions drag. Ownership blurs. Meetings multiply, but outcomes don’t. Cross-team initiatives stall without clear accountability. As the organization grows—even globally—its internal complexity starts to outpace its ability to execute. Growth plateaus. Teams duplicate efforts or move in conflicting directions. People feel stuck.

It’s a crisis of growth. So they embrace alliances.

They acquire new capabilities, invest in AI, build strategic partnerships, and/or expand through joint ventures. It works—until it doesn’t. The business now spans industries, geographies, and business models. And with that comes a new kind of crisis: a crisis of identity.

They go back to the basics. Who are we? What’s our vision? Mission? What impact do we want to make? How will we win as a business? What obstacles stand in our way—and what will it take to overcome them?

Aren’t they just flip flopping?

Instead of growth being a linear journey, I wonder if growth just forces organizations to flip flop between two states: Centralized and Decentralized. Are organizations vacillating between a centralized structure with specialized functions and a decentralized structure with cross-functional team?

Both structures have their pros and cons.

It’s easier to get things done in a centralized structure, but harder to respond to the market, try new bets, and pursue new opportunities.

It’s easier to respond to market and place new bets in a decentralized structure, but harder to coordinate across business teams.

Maybe it’s just another way to look at it.

Making it useful and thinking about now

However you look at it, I think you can make this model useful for your organizational context. If you’re part of a leadership team, ask your team:

1. If we were in a stage in this model, what stage are we in? What have we seen that tells us we’re in this stage?

2. Given that we’re in this stage, what crisis might we encounter? What tensions are signs that this crises is bound to happen (or is happening right now)?

3. What might we need to change to prepare for the challenges ahead?

I’m curious what now might tell us about this model. With rapid advancements in AI, what new crises are on the horizon for companies that heavily investing in AI? Will we these companies experience any of these crises? Or will new crises occur?

From 2016-2019, I worked for a company that transformed other company’s operating systems. Every company has an “OS” — the fundamental beliefs, behaviors, and patterns that the organization runs on.

It was a dope job. I mean, your sole job being changing other company’s operating systems? That’s rad.

Fast forward to today — 2025 — I attended a conversation hosted by John Cutler on how operating systems are a design challenge.

>60 people attended! Which tells me… lots of people take interest in this stuff. Seeing an organization as a system, an environment that can be changed to better foster the behaviors that will help the organization succeed.

And I think seeing organizations as an OS has really benefitted my own career. It’s allowed me to have an impact in companies I’ve worked for and clients I’ve worked with. Whenever I talk to founders and leaders, they resonate with this thinking.

So… why does operating system design still feel like a “niche” thing? Lots of people think about organizations in this way. But maybe not as many as I might think? I dunno. Last I checked, there aren’t jobs out there called “operating system designers.” (If you search it, you’ll just see a bunch of software engineering jobs.)

I suppose people like us have been doing operating system design in our day jobs. Under our titles as leaders, founders, service designers, managers, consultants, practitioners, product managers, org designers.

It’s just what we do.

But what if there were more jobs where operating system design was the sole thing you focused on? Airbnb are hiring Organization Designers… what if more companies followed suit?

Will there be more jobs titled “org designers” and “operating system designers” in 2030? What do you think?

In 2021, my last employer (garden3D) piloted a four-day workweek: opt into a 20% pay cut, and you got Fridays off. I was like, yo, sign me up. I joined the first cohort and stayed on a four-day schedule until 2023.

It changed my relationship with work.

I had time to grow as a rock climber, deepen my relationships, and actually rest — all while continuing to deliver my best work.

I felt lucky. My employer recognized burnout as a problem and did something about it.

And they weren’t alone. The research is clear: four-day workweeks are good for people and good for business.

What the Research Says

Between June and December 2022, 61 companies in the UK piloted some version of a four-day workweek. The results were encouraging:

• 56 of the 61 companies continued the program.

• 18 made it permanent.

• 71% of employees reported reduced burnout.

• 39% felt less stressed.

• 54% found it easier to balance work and home life.

• Company revenue stayed steady — and even grew compared to previous years.

• Employee attrition dropped by 57%.

• And this one really stuck with me: 15% of employees said no amount of money would make them return to a five-day schedule.

Like I said, I’ve never looked back. Even now as an independent consultant, I still take Fridays off.

If the Benefits Are So Clear, Why Aren’t More Companies Doing It?

A lot of my peers already kinda have lighter Fridays:

• There are no meetings.

• It’s remote-only.

• Fridays are off in the summer.

• Or it’s just “a chill day” — respond to a few Slacks and keep the green dot on.

So if we’re already halfway there, why don’t companies go all in?

Common Fears About the Four-Day Workweek

Here are the objections I’ve heard — and how we might reframe them:

😱 “We’ll lose money!”
→ What would it take to adapt your business model for a 4-day week? You might shift from billing hours to billing by deliverable or week. You might run Monday–Thursday sprints instead of Monday–Friday ones.

😱 “People won’t be as productive.”
→ The opposite tends to be true. Constraints force focus. And remember Parkinson’s Law: work expands to fill the time allotted.

😱 “We’re already overloaded. How will we get everything done?”
→ Maybe the problem isn’t time. Maybe it’s prioritization. Reduce your WIP (work in progress) and prioritize what truly matters.

😱 “What if a client emails us on Friday?”
→ Set expectations. Let them know your company invests in well-being. You might be surprised — they’ll often appreciate (or even emulate) the boundary.

Knowing ≠ Doing

We know the five-day workweek is an outdated legacy from factory floors.
We know people burn out fast.
We know most of our jobs don’t require 40+ hours of screen time.
We know humans aren’t meant to stare at computer screens 40+ hours/week.
We know shorter workweeks improve retention and attract talent.

But knowing ≠ doing.

Change is hard — but that doesn’t mean it’s impossible.

Think about the cost of not changing? Burnout, turnover, disengagement.

At my last employer, the 20% pay cut was a way to test the model with minimal impact on the business, while giving people a real choice.

The important part was this: they made it safe to try.

We Need More 4-Day Workweek Stories

I’d love to hear from you:

Have you worked four days a week — as a freelancer or at a company?
Have you been part of a team or org that transitioned to a four-day workweek?

How did it go?

Other relevant links:

• New research on the 4 day workweek — from Juliet B Schor, an economist and sociologist at Boston College.

• The Sabbatical Project helps people (and companies) take sabbaticals.

• Why companies are still reluctant to introduce the four day workweek

"Fail forward."

How many times have you rolled your eyes at this in your company all-hands meeting?

"Yeah, but if I fail, that'll mean I won't get my promotion."

“What if layoffs are around the corner? If I hit my targets I won’t be laid off…”

Many organizations preach failure but don’t practice it. The incentives, climate, and implicit vibes are all telling employees to play it safe. They need their paycheck!

But think about this.

What is the cost of not failing?

Businesses that don't fail, don't learn. And if they don't learn, they don't adapt to the market, which is a surefire path to obsolescence.

Failing is inherent in climbing

I just did one of the hardest rock climbs of my life after failing on it 19 times. 19 times. This is 19 days of driving to the crag, hiking, trying the route three times, failling, leaving, and driving back. That’s a lot of effort!

Many people will look at this and ask: so you’re just trying one route and failing at it every time? Yes! Us climbers find joy in this process. We are learning and getting better every single time.

For professional climbers, they’ll attempt their route 20-40 times, year-after-year, season after season until they finally finish their route. Failure is the path toward success in climbing. And the rate of failure for pro climbers is higher than in other sports:

• A pro 3-point shooter in basketball makes 40 of their 100 3-point shots.

• A pro hitter in baseball can hit 29 out of 100 bats.

• A pro tennis player can win 70 of their 100 first-serve points.

• A pro climber can fail on their project 100 times, as long as they send once.

Dave Macleod talks about how many adult climbers don’t fail because society teaches them not to:

In my opinion there is much confusion about the place and role of failure in western society that has spilled over into sport with poor consequences for its participants. It has become an increasing norm that failure generally is bad, unacceptable and even punishable. If governments fail to meet targets, they are booted out. If football managers fail to win the league, they are sacked. Make a professional error, and your ass is getting sued etc. Watch a TV show like 'The Apprentice' and you see reams of smart folk keeping a straight face while they announce that they simply don't accept personal failure. But there is a fairly simple detail missed out here. It's fine to settle for nothing less than personal success in the long run. But temporary failure is the essential part of long term success. That bit gets dropped off in the edit. It wouldn’t make good TV or a good headline sound-bite.

Like many adult climbers, we also don’t fail at work…

Aversion to Failure in Business

Companies are averse to failure, too. Reputations are at risk. Job security is on the line. “The market isn’t looking good.”

While many companies need to prioritize keeping their business, playing it safe is also a risk. The cost of not failing? Your business not achieving their long-term goals. The best organizations fail, learn, and adapt; the ones that don’t go out of business.

Just like in climbing, organizations need to fail (and learn from it) to achieve long-term success. And if organizations fail safely — if they make it “inexensive to learn” — they learn more quickly. So how do organizations fail in a way that minimizes cost and maximizes learning?

Fostering ways to fail

1. Frame your projects as bets. More on this here: TBM 19/52: A Portfolio of Bets

2. Use decision-making frameworks — like Integrative Decision Making — that push teams to make decisions that are safe-to-fail. (You'll learn from it anyway.)

3. Disagree and commit. Encourage dissenting opinions, but once the decision has been made, implement the decision. Do not reopen the decision.

4. Celebrate teams that try something new that didn't work. This will make it safe for more teams to innovate.

5. Share failures publicly. Companies are often afraid of doing this because it’ll hurt their brand perception. But what hurts your brand perception even more is when people find out about failures not through your company, but through industry gossip/heresay/exposition articles. Own your failures! People will appreciate your honesty, and be bought into your brand even more.

These five things are much more impactful than just saying "move fast and break things."

What ways do you build failure (and learning) into your organizational culture?

This week, I’m sharing seven lessons I’ve learned in climbing that also apply to cross-functional teaming. I typically don’t like to use sports metaphors. But as I keep coming back to my work desk from the mountains, I keep coming back to these lessons. This newsletter has always been about overlaps between disciplines… so here goes!

The more I multi pitch climb, the more I relearn the same lessons I’ve coached product teams and cross-functional teams on.

Multipitch climbing is when you climb something tall with at least another climber. So you’re working in a team (as opposed to alone).

Seven lessons from multi pitch climbing that also apply to cross-functional teaming

1️⃣ Have a shared goal that's clear, ambitious, yet achievable.

“We’re going to get to Pitch 9 on Levitation 29 by 2pm and rappel down then. That way we’re hiking back as sunset hits.”

2️⃣ Create a strategy.

“To do this, I’ll lead this pitch while you lead this pitch. Here’s the gear we need. Some watch outs on Pitch 5: it’s a hard pitch that requires two fists.”

3️⃣ Name the risks upfront.

What can go wrong? Any no-fall zones? How can we mitigate these risks? Can we bring 3 black totems to ensure that we’re well-protected throughout the thin finger crack?

4️⃣ Your team needs both technical skills *and* communication skills.

In multi-pitch climbing, we have very specific commands to each other. “You’re on belay!” “Off belay!” “Climbing!” “Climb on!” These commands are almost standard. No matter how good you are individually, communication matters a lot.

5️⃣ Have a broad toolbox.

Yes, best practices are great. And, you'll want to be ready to use other tools/techniques when the situation demands it.

6️⃣ Slow is smooth, smooth is fast.

My former coworker, Spencer Pitman, who’s also a climber, used to say this a lot. As a climber, I get this now. Do not rush. Most accidents happen when you rush. Efficiency comes from being smooth, first.

7️⃣ Reflect, learn, and improve.

Did we achieve our goal? How’d we do today compared to how we expected we’d do? What could we do better if we were to do this route in the future?

🎱 Don’t be afraid to bail.

This one’s added by my friend Katie Mayo from Root to Earth. From her LinkedIn response: “In tech, bailing might be for the sake of opportunity cost, delighting the users, or implementing the Pareto principle. Sunsetting products avoids wasted time and keeps the user experience clean & focused.”

Product heads & consultants — don’t these seven lessons sound familiar?

I used to roll my eyes at using sports analogies in a business setting (because they can be hard to relate to if you’re not into sports). But since getting into multi pitch climbing, I see all the overlaps. I guess I’m getting my MBA on Yosemite’s walls.

Project Updates

• I discontinued Unsend It, a newsletter that I started awhile ago.

• Last year, I started a podcast called Rock and Rice. It’s more of a passion project than it is business-related, but I’m pretty damn proud of it since it’s spread in the Filipino climbing community.

The org design neurons in my brain are firing off. Again. I started a full-time org design consulting project a month ago and it’s brought me back to some many things I’ve written about in this newsletter.

I recently wrote a post on LinkedIn that I wanted to elaborate into a newsletter here. So… here goes!

I’m also… ambivalent about just writing on LinkedIn. It feels performative? But necessary? Do others feel the same way?

Tim, are you going to be writing this newsletter again?!

I’m not committing to a regular writing cadence (yet?!). Right now, I just wanna write when inspiration strikes. So you may be receiving random emails from me when I strike while the iron is hot.

I know writing on a regular cadence is newsletter best practice. Which… ironically this post is going to be about why best practices are great. But for now, I’ll posting here randomly when inspired. Who knows. Maybe I’ll go back to writing regularly.

Back in 2018, I wrote this article titled Best Practices are Killing Your Company. But now, I think best practices are saving your company.

More pointedly, best practices ultimately help companies that have teams new to working cross-functionally, reflectively, and collaboratively. Say, a 5-person startup who’s just getting off the ground. Or a 1000-person organization that’s re-organized from functional siloes to cross-functional teals.

Last year, I coached high schoolers who were new to rope climbing. (I promise there’s a consulting/product lesson in here.) They wanted to learn how to belay another climber.

In climbing, belaying is the technique used to control your climbing partner’s fall when climbing on a rope. Not required, but if you’re interested:

There are plenty of ways to belay, each with their pros and cons. But with these kids, I didn't go into each of the different methods. That's overwhelming.

I taught them one method that is best practice. This one. Had them learn why it was a best practice. Then, I asked them to practice it!

After tons of practice, these kids are safely belaying each other and having fun.

As a consultant, I see a parallel to coaching newer teams. Give them one best practice to practice.

Early in my consulting career, I’d hesitate recommending one true way to run meetings with teams I'd coach. "There's no best way to run this meeting. Here are some principles for running a good meeting, but the structure of the meeting will depend on your current strategy, context, and environment."

Now, I have zero hesitation recommending to a new cross-functional team:

• weekly action meetings

• monthly retrospectives, and

• quarterly strategy meetings

Are these the absolute best meetings? Maybe not. You, reader, might have better meetings to recommend than I do.

But will these get the team to start practicing? Absolutely.

I even wrote an article titled "best practices are killing your company" back in 2018.

The lesson here is that the most successful leaders and organizations deeply understand the most successful practices’ core principles, even over implementing the practice itself.

Instead of falling for another business fad, seek to understand the principles behind the practice (the why) even over figuring out how to implement the practice (the how). You can do this by asking questions like:

1. Why does this best practice exist? What makes it so popular?

2. What does this practice look like in similar companies facing similar challenges? What does this practice look like in different companies?

3. How else can the purpose of this practice be achieved in our company?

Yes, I still think it’s good to extrapolate why the best practice is good.

But with teams who are brand new to working in a different way, it’s best for them to start practicing a practice that’s… good enough. Call it a best practice for the packaging.

Examining why it’s a best practice is good work too. We’ll just do that… later when your team is humming. Right now I just need newer teams to start practicing.

As a more experienced climber, I know 3 different ways how to belay. And I can tell you the pros and cons of each way. But I really default to one best practice. And I really teach one practice. I trust that the climber who’s learning will discover other methods 1-2-3 years down the road. Today, we just need you to belay someone safely.

Of course, I’ll share the core principles behind the practice. The from → to. The mindset we’re trying to demonstrate, and the mindset we’re letting go.

But like the kids who learned how to belay, newer teams benefit from learning a best practice.

They get to practice! They’ll learn why it’s a best practice once they practice it.

What do you think? How do you think of the role of best practices in your work as a product person or consultant?

Let me let you in on a secret. I haven't had many great experiences with resource allocations.

(I've had a few good experiences that I'll share too.)

Resource allocations is matching people to projects. “Jane is on this project at 50%. Charles is on this project at 30%.” Some firms call it staffing.

You are a pie that can be cut and split into different pieces, each piece being fed to a hungry project that always wants more pie. Bleh.

All organizations allocate resources (which really means you work on X for Y hours/week). This makes things predictable. We know who’s doing what. We know when so-and-so is available.

I haven’t had the best experiences with resource allocation. You might relate. Here are six resource allocation pains I’ve experienced.

🤷🏽♂️ Junior employees are promised support and training, but get put on difficult projects with no support.

When the business has more work than people available to do the work, we staff the folks who are available, rather than the folks best for the project. “Figure it out!” the manager says. “We don’t have time for learning and development.”

If the project fails, it’s seen as the junior’s fault (rather than the manager’s). “They’re just not a good fit.”

Consider that it might be the organization’s fault.

😰 Always being anxious about missing utilization targets

“Utilization” is a metric that both tech companies and client service businesses use. Firms and agencies make money from people on projects, especially if they bill hourly, so they need employees’ hours always on client work. Tech companies use utilization targets to keep their developers busy, because if their devs aren’t on work, “we’re bleeding money.” (Yes, I’ve heard a leader literally say that before.)

This leads to anxiety. Developers are anxious when they aren’t put on a project, because if they aren’t utilized, they may get laid off.  (Although some of your devs want to get laid off. Potential severance is the new golden handcuff.)

Utilization is a means to help make good decisions on how to remain profitable. But when it becomes the metric to control for, it’s just another case study of Goodhart’s Law: “When a measure becomes a target, it ceases to be a good measure.”

😮💨 No breaks

“Done with your project? Great. I have a new one for you. Oh, you had a vacation planned after your project wrapped? Well, we just sold to a large client. I need you to fit in time for this enterprise feature, even though you’re maxed out.”

Justin Jackson writes that good businesses have margin. Good resource allocations also have margin.

🏋🏼 Constantly tinkering with allocations because of new work

I’ve been a part of conversations where allocations needed to be updated daily. If we need to readjust daily, can we address the root cause here? Instead of incessantly keeping our table updated?

I’ve also seen allocations get thrown out the window because of a big sale. “We need bodies on this project ASAP!” Abandon ship on current work. We got a Big One. (But… did you ask for a later start date?)

🫨 Too much context switching

“Angeli shouldn’t be working more than 40 hours a week! She’s 10% on Feature A, 15% on Launch Project B, 30% on the CEO’s project, 25% on Feature D, and 20% on mentoring other developers. How could she possibly be overworked?”

The more projects you’re on, the more time you spend context switching. This is why people hate having tons of meetings on their calendars.

Good video by John Cutler on this here.

🪤 Time allocated ≠ time actually spent

Have you ever been staffed 100% on a project that only required 30% of your time? I have. It’s great.

Have you ever been staffed 30% on a project that actually needed 100% of your time? I have. It sucks. Now you have to ask for more allocation on a project while being worried about being seen as incompetent.

🌱 Better ways to allocate

I don’t believe in there being the best way to do anything. But I do believe there are better ways to go about resource allocation. Here are thirteen options.

To folks who allocate people to projects (product managers, design operations, leaders):

🌳 Root your allocations in strategy

At garden3D, I and a few coworkers advocated for engineers to be allocated to the discovery phase of a project. Engineers usually weren’t a part of discovery, so that they could be 100% allocated toward engineering work. But we found that our projects could’ve been better scoped. Engineers faced tight timelines. And some of the features agreed on with strategy, design, and the client just weren’t feasible. Our engineers had to constantly advocate for more time to launch sometimes but had very little negotiating power since the launch date was the launch date, which was decided without them in the discovery phase.

So moving forward, we started allocating a tech lead in our discovery work. That way an engineer would help shape the feature requirements and timelines alongside the PM. PMs were able to learn whether a certain feature a client liked wasn’t exactly feasible, and both the tech lead and PM would collaborate to think of alternative ideas that would be more feasible yet still satisfy the client’s goals behind the desired feature.

This ended up being so great. Tech leads allocated in discovery allowed for career growth. Many engineers wanted to grow into being a tech lead. Our projects were a lot more realistic; fewer developers had to resent a tight timeline, more starting together, and more of a spirit of cross-functional collaboration. We always felt tempted to revert to no developers on a discovery project. But because this was a strategic goal — every discovery project having 20-40% of a tech lead’stime — we never lost sight of it. Root your allocation in strategy.

☁️ Limit work in progress

The more work in progress, the more time people need to context shift. The less work in progress, the more time people have to focus and go deep on the challenge. And guess what? Less WIP ≠ less work getting done. It means more work getting done at a faster rate.

For every individual, limit the work in progress. I suggest starting with no more than two projects or features at a time. Yes, two. Don’t negotiate. Use two as your constraint and witness your teams getting more done. More on WIP limits here.

🎲 Double your estimates

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

Everything takes longer than you think. Your initial estimate isn’t enough time. Double your initial estimates. Give your team time to do a good job. Again, good teams build margin.

🧘🏽 Add context switching time

Say there are four projects: projects A, B, C, and D. Angelo is an engineer who can be allocated to any of them.

If Angelo's just on project A, their allocation is 100%.

If Angelo is on projects A and B, give them 10% of their allocation for context switching. So that

• 45% of their allocation is on A

• 45% of their allocation is on B

• 10% is a buffer for switching between A and B

If Angelo is on projects A, B, and C, give them 25% of their allocation for context switching. So that:

• 25% of their time is on A

• 25% of their time is on B

• 25% of their time is on C

If Angelo is on projects A, B, C, and D, run it back. Don’t staff someone on four projects. Again, we limit WIP.

📆 Build utilization rates based on a 4-day workweek

I’m lucky that my last company offered 4 days/week. I was able to prioritize the most important things, get the same amount of work done, plan my weeks more efficiently, and ultimately make space for things important to me outside of work.

I’m not alone. Hundreds of other companies have adopted the four-day workweek.

As a leader, you probably want your company to offer a four-day workweek. But you’re concerned about the company making less money, not hitting deadlines, not meeting velocity goals, etc. If that’s you, test out a 4-day workweek on oneteam or one project. Treat it as an experiment. Will this team ship at the same rate with one less day/week? Treat this team as a model for whether this could work or not at your company. Make space for this to be messy.

🫱🏽🫲🏾 Consider a two-way process

I used to be a part of a two-sided marketplace at The Ready. Tabea Soriano speaks to this:

Instead of assigning projects in a sequential, first-come-first-serve basis, we employ a marketplace model. This model empowers individuals to select projects they prefer, effectively decentralizing the staffing process. —Tabea Soriano, Head of Transformation at The Ready

When a project was just about to start, consultants would 🙋🏽 raise their hands 🙋🏽 if they were interested. Usually, projects were staffed by two consultants. I handraised on projects I wanted to be staffed on. I also knew who else was available and interested. If the main salesperson closing the project thought I’d be a good fit, they’d choose me.

💪🏽 Build in support systems for junior employees

Back in 2018, I was able to be a third consultant on a client, when our default model was two consultants per client. The Ready understood that this would help develop me as a consultant earlier in their career. And! The project got a third person, meaning we could divvy the work more and have a larger impact on our client. Everyone benefitted from a three-person team: I got to grow, my colleagues had an extra teammate who could help, and our client got more support.

When I became a studio lead at garden3D in 2021, I’d assign our junior product designers to existing projects that already had designers on the project. The point wasn’t to “make more money” on these projects by adding another designer. It was so that designers could learn alongside more experienced designers. Those experienced designers knew that a part of their job was to mentor, so they had a new avenue to grow too.

🧑🏽🍳 Create a skills database

Have your team list out the a) skills they bring and b) the skills they want to grow. Then ask your team to list out skills their teammates bring (oftentimes people are too humble about listing their own awesome skills!). Keep this skills database in your allocations database, whether that’s on Notion or some allocation software.

🗳️ Staff projects democratically

When I was a studio lead and had a bunch of new projects starting soon, I facilitated a voting process. Everyone gets to vote on who gets staffed on what. How we did it:

1. Project context. We shared context on each project and held space for clarifying questions. Sometimes sales would be on the call to share context, too.

2. Review skills database. We’d review the skills folks have and the skills they want to grow.

3. Silent voting. Everyone wrote down the team member who they believed should staff the project. For every project. People could vote for themselves (we encouraged it).

4. Share votes. We all shared our votes in a round and explained our rationale. Some people would vote on a certainperson based on their experiences, others would vote based on their interest in the client’s industry, and others would vote because they think it’d be a great way for that person to grow the skill they want to grow.

5. Consent. People who were most voted for a project were asked: do you consent? Or not?  If they didn’t consent to the project, the second-highest-voted person had a chance to consent.

6. Final round. We’d do a final round to look at who consented to what. We held space for anyone to make any final suggestions. If there was someone who wanted to be considered for a specific project so that they could get experience in that type of work, we heard them out.

It does require a high level of psychological safety and knowledge of each other’s skills. This process always led to some great conversations. We adapted this process from Samantha Slade's article here.

🙅🏽♂️ Try no allocations for a month

What if you didn’t set any allocations a month?! Omg!!! Anarchy!

Consider this question: what can we learn if we pause our allocation practice for a month? How would we spend our time? What will we do with the time we get back when we don’t allocate? You’d have to pick the right month to do this and properly learn from it, maybe don’t choose the month before an important launch. But give it a go.

👂🏽 Ask your team members to challenge your allocations

Invite disagreement. “This is my best guess, but it isn’t absolute truth. I’d love it if you could tell me how this could be better as you progress your work.”

Make it clear to them that they’re always welcome to ask for more (or less) team members on the project. And always follow up. Were the initial allocations on point? Or do we need to adjust them?

🌱🌱🌱

To folks who get allocated (engineers, designers, ICs, staff):

🗣️ Be transparent when you need more allocation time

You intend to do your best job. But it turns out 30% on this project isn’t allowing you to do your best job. That’s all good. Communicate that to your PM/design lead/tech lead/direct manager.

What you want to hear:

• “Thank you for sharing. What can I do to support you? What do you need?”

• “Let’s extend our deadline.”

• “If you were me, how much allocation would you give yourself?

If your manager responds with:

• “You’re too slow”

• “I should’ve staffed someone more senior”

• “You need to work longer to get this done faster”

Find someone else who would better understand your perspective. (And maybe eventually, find a different manager.)

💆🏽 Build margin in your day

No one works eight straight hours a day, five days a week. People aren’t meant to sit in front of their computers eight hours a day. We take walks. We make lunch. We walk our dog. We go to the gym. We pee. Build margin in your day.

Also, if you get the job done say two hours faster than allocated, don’t spend an extra two hours doing busy work. Take a break. No one will mind. (And if you have great managers, they’ll encourage breaks.)

🌱🌱🌱

🤖 Traditional resource allocation is based on the premise that humans are machines

Your time is the resource the company uses. When time isn’t your only resource at their disposal.

But the problem is in the name itself. “Resource” allocation. We are resources to a company, not humans.

Much of resource allocation is based on the fact that humans are resources to a company. Which, of course, Tim, that’snot news. But instead of companies saying they want to create more humane workplaces and help people feel more authentic at work, we still plan in an inhumane, robotic, assembly-line-til-AI-takes-our-job type of way.

What would a humane way of channeling our time, headspace, and energy toward organizational goals look like?

What other resources do we have at our disposal besides people?

What aspects of resource allocation must we accept? And where could we be more humane?

🌱🌱🌱

Consider the above as a menu of options to resource allocate in a better way.

For managers, PMs, tech leads, and directors:

• 🌳 Root your allocations in strategy

• ☁️ Limit work in progress

• 🎲 Double your estimates

• 🧘🏽 Add context switching time

• 📆 Build utilization rates around a 4-day workweek (not a 5-day workweek)

• ↔️ Consider a two-sided marketplace

• 💪🏽 Build in support systems for junior employees

• 🧑🏽🍳 Create a skills database

• 🗳️ Staff projects democratically

• 🙅🏽♂️ Try no allocations for two weeks

• 👂🏽 Ask your team members to challenge your allocations

For folks who receive assignments:

• 🗣️ Be transparent when you need more allocation time

• 💆🏽 Build margin in your day

What have you tried that’s worked for you? Leave it as a comment.

If you’d like help trying any of these out, send me an email. I’d be happy to help.

It’s been a while.

I wrote a thing that might be of interest.

I share some client work I’ve done since taking on my own clients as an independent consultant. It’s been fun.

While these days I don’t write as much about product and org design, I still enjoy making these concepts useful for others.

Curious if you or anyone you know are consulting on their own, too. I’d love to learn about how it’s going for you.

Be well!
–tim

Stuff I’ve Read Recently

• Me-as-a-Service by Behzod

• The evolution of Ashima Shiraishi

• Three Organizational Design Principles

• Book: Slow Productivity

Hello Overlap readers! It’s been a while.

I wanted to share three personal updates:

1. I’m no longer at garden3D. I’m thankful for my last four years there. I’ve learned a lot. My experience working there fueled much of my writing for The Overlap.

2. I’m currently taking consulting clients. Currently offering two services: organizational development and DEI support. Know anyone who needs support in either area? Reply to this email!

3. I’m thinking about turning all past The Overlap content into an eBook. I’m curious if past subscribers would buy it.

   1. The book would be a collection of all past Overlap essays: a single package of all the content you’ve read here. There wouldn’t be new material — I’ve sunsetted this newsletter and have writing ideas on other topics (more on that in a future email!). I’d love to gauge interest on this eBook idea, though, before deciding to pursue. So! Poll time. If I were to sell an Overlap eBook for $10, would you buy it?

I’ve decided to sunset The Overlap. Sudden decision, I know.

I no longer have the stoke and passion to write this newsletter that I used to have.

I used to be really into org design in 2016-2019. And then product management in 2019-2020. I started this newsletter to examine the similarities between both.

I wanted to look at the entirety of what it takes for teams to do their best work. A product team’s product is only as good as how they organize, strategize, communicate, decide, and act. How organizations work determines whether they achieve the outcomes they want. But organizations rarely practice reflecting on their how. We move on to the next project, we don’t address deeper issues, and we turn a blind eye from addressing dysfunction when everyone literally feels it. And, it’s a shitty experience for everyone. Who wouldn’t want to feel effective, engaged, and fulfilled at work?

Improving the way product organizations work is still meaningful work to me. But lately, I struggle feeling excited to write about it every week.

Product and org design feel like remnants of an old me. An old me who lived in New York City and was excited to integrate what I was reading and learning into my work. I feel like it’s hard for me to unsee possibilities for how organizations can work better — my brain is literally wired this way because it was my first job out of college. But I don’t think about the way we work as much as I used to. Post-pandemic, I’ve started to value things outside of work.

I’ve been struggling to accept that I’m not as passionate about product and org design. This has been strange to come to terms with. I’ve always seen myself as the org design guy at work. And a product and org design writer. It’s a part of myself that’s shedded — I’m slowly accepting this.

I do enjoy writing. (Perhaps more specifically, I enjoy having written more than I do writing.) Writing is my way of making sense of reality, messiness, life. Writing reminds me of what’s most important to me. Writing helps me help others see things in a different light. I just don’t want writing to feel like work. I want to write only what I’m excited by.

I don’t want The Overlap to become dull and dreary

From visakan veerasamy’s I Don’t Wanna:

I don’t want to repeat myself in a dull, dreary way.

[…]

There’s repetition that’s interesting — coming from a new angle that feels fresh, significant, meaningful — and there’s repetition that’s dull and dreary, recycled pablum.

I worry that The Overlap will become recycled pablum. I want to create what I want to create. And always bring something fresh to the table.

Now, I force myself to write it every week. That’s not a great sign.

I wrote Define your leading and lagging indicators because I knew it wouldn’t take me long. It took me 1 hour to write and edit. But I don’t ever want to think, “What’s a topic I can quickly publish?” I want to think, “What’s a topic that I’m genuinely stoked to write about?”

More from visakan veerasamy’s I Don’t Wanna:

I don’t want to… do homework. And that’s what a lot of my essay plans feel like right now. Homework. My last day of school was in 2009, and it’s been 13 years since and here I am sitting around feeling frustrated with a bunch of homework that I’ve assigned myself. Gosh.

Wait, didn’t you just start a paid newsletter?

Yep! I did.

And a few of you have graciously paid the annual subscription. If that’s you, I’m going to email you directly and ask if you’d like a prorated refund for the newsletters you haven’t paid for. (I’ll refund $70 minus $7/month for the amount of months you’ve subscribed.) It’s up to you if you want that prorated refund. You can choose to support me by keeping the $70 payment. Or you can choose to receive the refund. Completely up to you.

I’m afraid I’ve disappointed many of you by quitting this newsletter. But I only want to give The Overlap readers writing that I’m genuinely stoked about.

So, what do you want to write about now?

I’m not sure. I reckon I’ll be able to answer this question by living it out (rather than theorizing).

Some questions I’ve thought about:

• What have I learned about love thus far?

• Why do I love climbing outside so much?

• Why should climbers choose just to boulder or just to sport climb? Why not excel in both?

• How do I foster community while always being on the road?

• Why does seemingly every solution to interpersonal conflict always point back to self-awareness and communication?

• How can different generations in the Filipino community better understand each other? And how might this improve our collective mental health?

I’m proud of these three essays I wrote last year:

• I live with my parents and I’m okay with that

• on practice

• My 2022 year in review

I don’t read as much about business and organizations these days. The only business-y thing I read is John’s The Beautiful Mess. No surprise to you as a reader of this newsletter. His newsletter inspired me to write mine.

If what I’m reading is any indication for what I’ll eventually write about, I’ve been enjoying:

• bookbear express

• visa’s voltaic verses

• The Pathless Path

• Michelle Varghoose’s Newsletter

• The Paradox of Goals

• Over-indexing on freedom

Thank you! It’s been a good run.

You are the reason this newsletter is successful. Thank you. For reading and giving these words an audience.

1221 subscribers. 14 paid subscribers after five paid editions. 61 editions. Many great comments. I’m happy with how The Overlap ended up.

Who knows, maybe I’ll be writing about this stuff again.

For now, The Overlap will sunset. And my interests will continue to wander.

–tim

Just as a reminder:

• 2/9: Free edition out ✅

• 2/10-2/25: No Overlap (I’m in Thailand & the Philippines)

• 3/2: 🔒Subscriber-only edition out

• 3/9: Free edition out

This one’s on how to define leading and lagging indicators. I think every product manager and org designer should have this tool in their toolbelt.

Why are leading and lagging indicators important?

So that you don’t waste time, resources, and energy on things that won’t produce the results you want. You want to make sure that you’re focusing the organization’s time, resources, and energy on things that actually give the organization what they want.

What are leading indicators?

Leading indicators lead you to the result you want.

Examples:

• # of times in the water >15 mins; # of falls taken per week (surfing)

• % of users who track 3 rides within their first week (Strava)

• % of new users who invite 2+ team members within the first 7 days; # of docs created within the first 7 days (Notion, Coda)

• # of Mailchimp actions triggered from the Stripe dashboard in the first month within download (if you’re a merchant who uses Mailchimp and Stripe)

• % of billable hours utilized on client work (indie consultants, agencies, consultancies)

What are lagging indicators?

Lagging indicators are the results you care about. They tell you whether you’re getting the result you want or not. They lag, meaning they take a while to tell you whether your efforts are paying off.

Examples:

• ⬆️ # of times in the water >15 mins; ⬆️ # of falls taken per week → ⬆️ % of waves < 6 feet surfed

• ⬆️ % of users who track 3 rides within their first week → ⬆️ % of users who use Strava at least once-a-week

• ⬆️ % of new users who invite 2+ team members within the first 7 days; # of docs created within the first 7 days → ⬆️ enterprise subscriptions

• ⬆️ # of Mailchimp actions triggered from the Stripe dashboard in the first month within download → ⬆️ subscriptions on the Mailchimp app on Stripe

• ⬆️ % of billable hours utilized on client work → ⬆️ quarterly profit margin

What should I not do?

Don’t focus too much on the lagging indicator. Or else you’ll fall into the Goodheart’s Law trap: when a measure becomes a target, it ceases to be a good measure.

Lagging indicators, by definition, aren’t controllable. Leading indicators are.

How do I figure out my leading indicators?

Make an educated guess. Then, try to influence (increase/decrease) that leading indicator, and see if that influences the lagging indicator. If it doesn’t, it’s probably not the right leading indicator.

If that’s the case, take a different guess. Repeat until you’ve found the leading indicator that impacts the lagging indicator.

Most businesses don’t know the inputs to their desired output. They just make sure “developers are typing” and “designers are clicking” because it *looks* productive. But looking productive ≠ producing results.

Define your desired outputs (lagging indicators). Clarify the inputs to those outputs (leading indicators). Then focus on those.

Further Reading

1. Goodheart’s Law Isn’t as Useful as You Might Think

2. Strategy, systems thinking, and being wrong

3. Good North Star, Bad North Star

4. The Paradox of Goals

5. Uncommon metrics that say a lot about your company

See you on 3/2 (if you’re a paid subscriber) or 3/9 (if you’re a free subscriber),
–tim

I’ve been working through some unexpected insomnia (ugh!) and need the week to recuperate.

I also have some travel plans coming up that will impact our cadence. I’m on vacation 2/10-2/25 (climbing in Thailand and family time in the Philippines!). And off March 16-21.

So! The Overlap’s schedule is:

• 2/9: Free edition out

• 2/10-2/25: No Overlap

• 3/2: 🔒Subscriber-only edition out

• 3/9: Free edition out

• 3/16: 🔒Subscriber-only edition out

• 3/23: No Overlap

• 3/30: Free edition out

Taking breaks help me get my head straight, which makes for a better newsletter. Thank you for supporting this newsletter!

What I’ve been reading

1. Coordination Headwind - How organizations are like slime molds (amazing)

2. Netflix, Democracy, and ~Operational Excellence

3. The Paradox of Goals

4. Are you serious?

What I’m sending

This thing and this thing.

See you next week,
–tim

The design systems team! The user research team! ProductOps! The infrastructure team!

These teams are platform teams. Their tools and output are usable by other teams so that those teams can do a certain thing well.

CPJ recently wrote How Capabilities Evolve. It’s great!

He talks about how it’s healthy to think of a matrixed capability team (R&D, Customer Strategy) as on its way to becoming a “platform team.” These platform teams provide an API that other teams use to be more capable at a certain thing.

Platform teams provide other teams the tools to better do X [design/infrastructure/understand their customer]. A platform team’s “customer” is internal.

I think of these as “Platform Teams” – teams that build things that improve business performance. Things that raise the bar. Things that allow businesses to do things they weren’t able to do before.

I think his insights on platform teams in large orgs apply to smaller orgs too. At least in my experience.

Creating a strategy “platform team” in a 30-person org

garden3D is a 30-person design & dev client services business. We don’t advertise it much, but we have a strategy team.

Why? To us, a good strategy helps our design and development organizations deliver more complex projects on time, within budget, and aligned with our client's goals. Now, we’re starting to think about what a standalone strategy offering would look like. (How can we actually help our clients better achieve their business goals?)

Before our strategy capability, garden3D was Sanctuary Computer, focused on just engineering. We created a strategic capability to help us be better at, well, strategy! And I was brought on as the first full-time member of that team.

We never intended our strategy service to be as profitable as our design and dev services. Our strategy service often operates as a loss, if we’re looking purely at the cost of having two full-time strategists and the profit we make from them doing shaping work. But we were okay with that loss. Having strategy in-house helped us win and deliver more complex design and development work, which ultimately would makes us more profitable.

But! To a designer or dev, Shaping (our strategy phase) feels like a mystic art. With no spell book. People figure out how to Shape out as they go.

This was a sign that my team, the strategy team, can do a better job of making our tools usable so that the business is more capable at Shaping. So we’re currently focused on making sure anyone can run a Shaping phase. Which means: making usable strategy tools!

More from Clay in How Capabilities Evolve:

…there’s a mindset shift from “we control what the businesses do,” to “we are out of a job if the businesses don’t want to use what we made.”

100%. Take a design systems team at a large company. The point of a design systems team isn’t to control the design output for every product team. The point of a design systems team is to give other designers the tools to quickly produce consistent, quality designs for their specific project.

I don’t see my role as “controlling the Shaping phase on every project.” I see my role as “creating the tools for teams to capably run a Shaping phase.” If these tools aren’t being used, I’ll learn why they aren’t being used, so that they can become more useful.

…So the skills need to change, too: the folks in those “Shared Services” probably need more of the core capability skills than they need General Management skills.

This also means that I need to improve my own strategy skills! I was a studio lead for the past 1.5 years, so my “general management skills” have grown much more than my strategy skills. Now that I’ve stepped down from a studio lead role and am back to focusing on strategy, it’s time I up my strategic chops.

They probably need to have the ability to make software-ish versions of their outputs without asking for help.

We’ve been working on a toolkit for running a Shaping phase:

…They probably need to be able to sell. They probably need to be able to consult.

Absolutely. I’ve long believed that some of the skills from my consulting life are the same skills a product strategist needs. And now that I’m more focused on creating a strategy toolkit, my “clients” are now my colleagues!

🛠🪛🔩

Platform teams aren’t meant to control output. They’re meant to help their organization be more capable at a certain thing. So that the business improves in the long run.

Have you worked on a platform team? Or consulted for one? What have you seen work well?

Relevant Reading

1. What is a platform engineering team, and why do we need them?

2. What is ProductOps?

3. Stream-aligned teams, enabling teams, complicated subsystem teams, and platform teams

4. Gardening platforms

See you next week,
–tim

Davide left a really good question that I’m sure others experience:

I'm not sure how a request for a sabbatical might be perceived by a company and the managers: in my experience there's a high risk of compromising yourself, the request being seen just as a paid vacation before checking out mentally or quitting right after the sabbatical.

You focused a lot on the nuts and bolts of building a proposal — which is great and helpful — but I'm curious about how you navigated the touchy-feely side of it, and how others might prepare themselves better for the inevitable clash of different expectations and suspicions that might arise from a request for a sabbatical.

He graciously permitted me to respond to his question in the next newsletter. So, here goes!

I know that for most people, asking their boss for a sabbatical can come off negatively. Of the two places I worked at as a full-time employee, I’ve never felt like I’d be judged for asking for a sabbatical. So I’ll own that I don’t have direct experience here. If you have experience proposing a sabbatical policy and not everyone took it positively, please share your experience in the comments!

My first employer valued work-life balance. And always used integrative decision-making (IDM) to make changes to any policy. One of my colleagues proposed a “honeybattical” to take extended time off for her honeymoon. We passed this using IDM. After I left The Ready, I noticed that my friend Sam proposed a sabbatical policy that passed too.

And before I joined garden3D, I learned that we had a 6-tweek sabbatical in place for employees of three years. In 2020, we started using IDM to make changes to any policy. One policy that came out of IDM was our 16-week paid parental leave (shoutouts Isabel).

This brings me to my first idea. First, introduce a way people can make changes to policy. Then, propose a sabbatical policy. 

When I used to introduce IDM to leaders, I’d help them understand that IDM was a tool to help them quickly make informed, safe decisions. Their organization usually struggled with one of two things:

1. Making decisions too slowly. Which happens in more consensus-oriented organizations.

2. Making decisions without input from teams that the decision most impacts. Like the CEO deciding on what the prices of a local franchise’s avocado toast should be. 

The leaders who liked IDM loved that they didn’t have to have every decision escalated to them. And, they had a tool to make quick decisions, with the right input.

Anyway. Derrick Bradley has a solid essay on how IDM works.

Let’s counter my suggestion above, though. Most people who want a sabbatical aren’t willing to introduce a new decision-making framework to their leaders. And ensure its adoption. 

You just want a sabbatical without having to change the way your company makes decisions. 

So, my second idea is to find the others who also want a sabbatical.

Specifically, find a sponsor who

1. also wants a sabbatical, and

2. has the authority or influence to make this decision. 

Squad up! Your sponsor (or team, if you work with multiple people on this) will be your refuge. In this refuge, psychological safety is high. You can’t change the psych safety of your entire org, but you can create a psychologically safe team. 

Having a sponsor with influence or team might alleviate some anxiety around coming across negatively to others. If Jasper, the Head of HR, also wants a sabbatical and has sound reasons for why a sabbatical is good for the business (reduces burnout, which increases retention and saves the business $ in the long run), then maybe others won’t be as judgmental towards you.

Okay, so we’ve gone over two ideas: introduce a decision-making framework or find the others.

My last idea is more about inner work.

Reflect on these three questions:

• Are others actually going to be suspicious if you request a sabbatical?

  • This might depend on things like how long you’ve been at the company, whether people truly take time off, and how much trust you’ve built with your coworkers

• If yes, why will people be suspicious? Is there a general vibe of low trust? Or is this suspicious specific to you?

• Are you okay with going for it, knowing that others will be suspicious/judgmental? 

• If no, what can you personally do to be okay with others feeling suspicious of you? Who can you seek support from here?

In certain cases, there are real social/political consequences for asking for a sabbatical. Like you work at Twitter 80 hours a week because that’s what Elon wants. Or you work at a startup where everyone’s been grinding hard before the big launch. A sabbatical before the launch probably isn’t the right time. 

Get clear on those consequences. Then ask yourself if you want to make that tradeoff. If yes, go for it (strategically!). If not, then figure out how to de-risk those consequences. Or consider if where you work is the right workplace for you.

In other cases, people will judge, but there’s little to no consequence in asking. In these cases, don’t worry too much about judgy people. You can’t control them. You are unfazed. 

In other cases, people won’t be suspicious of you. Be objective — this may be the case! Have other coworkers taken parental leave? (If yes, that’s a good sign!) Have you made an impact? (Most likely!) Do any of your other close colleagues want a sabbatical too? (If you don’t know, find out!)

Suspicion. Distrust. Judgment. Potential clashing. To what extent is this caused by your organization’s dynamics? To what extent is this coming from you? Sometimes it’s more one than the other. Or both. Get clear on what’s mostly driving this — this will prepare you to take the best path forward.

I hope this helps, Davide!

If others have any experience with this, I’d love to hear it in the comments.

What I’m Reading

1. Official myths by Mandy Brown. “Ultimately the real problem with the argument that we need offices to support junior staff isn’t about those junior staff at all—most of whom, I think, can see right through those claims. It’s that by constantly comparing remote work to an office straw man, we’re not engaging seriously with the challenges of remote work.”

2. “High Standards” by John Cutler. High standards are good, as long as it leaves room for different ways to achieve those standards. 

3. Five Org Design Things by CPJ is good! He’s been consistent with writing lately. Awesome to see.

See you in two weeks (or next week if you’re a subscriber), 
–tim