Free 30-day program
Couch to 5K:
Org Design
30 days. 10 minutes a day. Learn to see your organization the way a designer does.
No prior experience required. Just bring the organization you already work inside.
Downloads a .ics file with all 30 daily prompts and a Day 30 reminder to share your diagnosis — open it to add to Apple Calendar, Google Calendar, or Outlook.
What you'll build
By day 30, you'll have a one-page diagnosis of a real organizational challenge — written in plain language, grounded in what you actually observed, ready to share with a colleague or manager.
You won't study case studies. You'll study the organization you already sit inside.
Every day builds on the last. The prompts take 10 minutes. The thinking stays with you.
The four phases
Noticing before naming. No frameworks yet — just learning to see.
Your first lenses. One concept every two days, applied immediately.
Observations start connecting. You begin to see the system.
Writing it down. Your one-page diagnosis takes shape.
Your 30 days
Every organization makes decisions differently. Most people have been inside that process hundreds of times without ever really watching it.
Think of one decision that was made in your organization this week — big or small. Write one sentence describing what it was and how it got made. Don't analyze it yet. Just describe it.
Noticing is harder than it sounds. Most of us have learned to look past the machinery and just accept the output. This week we slow that down.
Decisions reveal a lot about how an organization thinks about who matters.
Go back to yesterday's decision. Who was involved? Who made the final call? Who was noticeably absent from the conversation? Write down three names or roles — in the room, not in the room, and who you'd have expected to be there.
The gap between who was there and who you'd expect is often where organizational design problems live.
Every organization has friction points — places where work consistently gets stuck, delayed, or handed off awkwardly.
Think about your last two weeks of work. Where did something slow down that you didn't expect? Describe the moment: what were you waiting for, and who or what were you waiting on?
Friction points are rarely random. They tend to cluster around boundaries — between teams, between roles, between systems. Keep a mental note of where yours appear.
Every organization has things it says it optimizes for. And then there are the things it actually optimizes for. These are rarely identical.
What does your team or organization say it prioritizes? (Speed, quality, customer obsession, innovation — whatever the stated value is.) Now think about the last month. What did your organization actually reward, protect, or make easier? Write one sentence for each. Then look at where resources actually go — budget, headcount, time. Do those investments point toward the same purpose and direction the organization claims to have, or somewhere else?
The gap between stated and real priorities is not usually hypocrisy — it's design. The organization is producing exactly what its structure and incentives are set up to produce. Resources are the most honest signal of all — harder to spin than values, harder to hide than intentions.
The org chart on the intranet shows reporting lines. It rarely shows how work actually moves.
Draw your team's org chart as it officially exists. Then, next to it, draw how work actually flows — who talks to whom, who unblocks whom, where decisions actually land. Think about: who do people actually call when they're stuck? Whose informal sign-off is needed before anything moves? Which relationship holds things together when they're about to fall apart? If you're not sure where to start, try this: identify who your organization ultimately serves — your customer, your end user, your beneficiary — and work backward. What has to happen for that person to receive value? Who touches the work along the way? That question often makes the real flow easier to see than the org chart ever does. They don't have to be neat. Just honest.
The delta between these two pictures is some of the most useful information an org designer can have. Hold onto both. And notice whether your customer appears anywhere in the official chart — because the further they are from the center of how work is organized, the more the design is optimized for something other than serving them.
Most organizations have one or two tensions that never quite get resolved — they surface in different meetings, under different names, but they're the same underlying thing.
What's a tension in your organization that keeps coming up and never quite gets settled? Describe it in two sentences: what it looks like on the surface, and what you think it's really about underneath.
Recurring tensions are usually structural. They're not personality clashes or communication failures — they're what happens when the design produces conflicting pressures on real people.
You've been noticing for six days. Before adding anything new, it's worth pausing to see what's already accumulated.
Look back at what you wrote this week. What surprised you most? What pattern are you starting to notice that you didn't expect? Write three sentences — no more.
The most important OD skill isn't analysis. It's sustained, honest attention. You've been practicing it all week.
One of the most clarifying exercises in org design is trying to describe a familiar organization to someone who has never heard of it.
Write one sentence describing your organization — or your team — as if explaining it to someone completely outside it. Not the official elevator pitch. An honest description of what it actually is, how it actually works, and who it actually serves. All three in one sentence. Not easy — but if you can't say it simply, that's worth sitting with.
If this sentence was hard to write, that's information. Organizations that are hard to describe simply are often hard to navigate for the same reason. And if the customer — the person the organization exists to serve — was hard to name, that's worth noting too.
Structure is how an organization groups its work and its people. It's the first and most visible design choice an org makes. Over the next nine days you'll add three more lenses to this one — authority, coordination, and incentives — and use all four together to build a diagnosis.
How is your organization structured? By function (HR, Finance, Engineering)? By product or business line? By geography? By customer type? Write one sentence naming the primary organizing logic — and one sentence on whether you think it's the right one. If your organization uses more than one logic (functional at the top, product-based underneath, for example), that's common — just name the dominant one and note where it blurs.
There is no perfect structure. Every structure optimizes for something and creates friction somewhere else. The question is always: what are we choosing to make easy, and what are we choosing to make hard?
Now apply yesterday's lens to something specific.
Think about a coordination problem you've experienced — two teams who struggled to work together, a handoff that kept going wrong, a decision that fell into a gap. Does the structure you described yesterday explain why that problem exists? Write two sentences.
Most coordination problems aren't relationship problems. They're structural problems that show up as relationship problems because people are the ones who experience the friction.
Authority is the invisible architecture of an organization — who gets to decide what, and how explicitly that's actually understood. Official ownership, actual decision-making, and blocking power are often three different people — and that gap between them is one of the most common sources of organizational friction.
Pick one type of decision that happens regularly in your organization — a budget call, a hiring decision, a product choice, a process change. Who officially owns it? Who actually makes it? Who can block it? Write one sentence for each. Then consider resources: who controls the budget in your organization, and does that match where decision rights are supposed to sit? Resource authority and decision authority are often out of step — and that gap is where tension lives.
When the three answers are different people, you have an authority problem. It's one of the most common and most costly design gaps in organizations. And when resource control doesn't match decision ownership, the org chart is telling one story while the budget is telling another.
Go back to the slow decision from Day 1.
Map the decision rights for that decision. Who owned it officially? Who actually decided? Who could have said no? Does that explain why it moved the way it did? Now consider one more dimension: does the way your organization distributes decision rights give people room to develop judgment and capability — or does it keep authority concentrated in ways that limit growth?
Decision rights aren't just about authority. They're about clarity. People can navigate almost any structure if they know who owns what. Ambiguity is the real cost. But there's a second cost worth naming: when authority never expands, neither do people.
Coordination is how different parts of an organization talk to each other and align their work. It's expensive, and most organizations have too much of the wrong kind.
How do the different teams or functions in your organization stay aligned? List the main mechanisms: recurring meetings, shared documents, dedicated roles, approval processes. Now mark each one: is it working, neutral, or creating more friction than it solves?
Coordination mechanisms accumulate over time and rarely get retired. Most organizations are carrying coordination debt — the accumulated weight of meetings, approvals, and processes that made sense when they were created but were never retired when they stopped being useful. It's a metaphor, not a formal term, but it describes something very real.
Connect today's lens to what you've already observed.
Go back to your friction point from Day 3 — the moment when work slowed unexpectedly, a handoff broke down, or something got stuck. Is the root cause a coordination problem? If so, what mechanism is missing — or what mechanism exists but isn't working? Write two sentences.
Adding more coordination is almost never the answer. The better question is whether the underlying structure is creating a coordination need that shouldn't exist.
Incentives are what an organization actually rewards — through compensation, recognition, promotion, and the quieter signals of what gets celebrated versus ignored.
What does your organization reward in practice? Think about the last person who got promoted, the last project that got celebrated, the last behavior that got quietly reinforced. Write one sentence on what the pattern tells you.
Incentives are the most honest part of an organization's design. Everything else can be a stated intention. Incentives are revealed preferences.
Now connect incentives to the recurring tension you identified on Day 6.
Who benefits — even unintentionally — from the tension staying unresolved? What does the current incentive structure reward that makes change difficult? Write two sentences.
Most persistent organizational problems have incentive structures that sustain them. This isn't cynicism — it's design literacy. You can't fix what you can't name.
You now have four lenses: structure, authority, coordination, and incentives. That's more than most managers ever use deliberately.
Which of the four lenses felt most clarifying when you applied it to your organization? Which felt least relevant — or hardest to apply? Write three sentences.
Good org design isn't about applying every framework. It's about knowing which lens is right for the problem in front of you. You're already starting to develop that instinct.
You identified a recurring tension on Day 6. This week you're going to follow it deeper.
Return to that tension. Now that you have the four lenses from Phase 2, what's actually producing it? Is it a structure problem, an authority problem, a coordination problem, or an incentives problem — or some combination? Write three sentences naming the root.
Most organizational problems have multiple contributing causes. The skill is identifying which one is load-bearing — the one that, if addressed, would let the others resolve. A useful test: if you fixed this cause alone, would the other problems shrink or disappear? If yes, it's load-bearing. If the others would persist, keep looking.
One of the most important shifts in org design thinking is moving from "people problems" to "conditions problems." If you work in HR or a people function, this reframe may feel personal — because the "people problem" framing is often exactly what gets handed to you.
Think about a behavior in your organization that frustrates people — something teams or individuals do that seems counterproductive. Now reframe it: what conditions would logically produce that behavior? What would the organization have to be rewarding, structuring, or incentivizing for that behavior to make sense?
If a behavior is widespread, it's almost never a character problem. It's a conditions problem. Organizations get the behavior their design produces.
A useful design question is not "how do we fix this?" but "what would have to be true for this to fix itself?"
Take the root cause you identified on Day 18. What would have to change — structurally, in authority, in coordination, in incentives — for the tension to resolve without someone having to force it? Write one sentence for each lever that applies.
This question separates symptomatic fixes from structural ones. Symptomatic fixes treat the output. Structural fixes change what the system produces.
This is the uncomfortable one. Every organizational problem has people who benefit from it staying unresolved — not maliciously, but structurally.
Who in your organization benefits from the current state — even if they'd say they want it to change? What do they gain from the ambiguity, the friction, or the unresolved tension? Write two sentences. Be honest. This one stays in your canvas — it's not meant for your one-pager directly. But it's the private foundation for Day 29, where you'll anticipate who might push back and why.
Change efforts fail most often not because people oppose them openly, but because the design still rewards the old behavior. Knowing who benefits tells you where the resistance will come from.
You've been observing and analyzing for three weeks. Today you make your first design move.
If you could change one thing — one structural element, one decision right, one coordination mechanism, one incentive — what would it be and why? Write three sentences: what you'd change, what you think it would shift, and what you're uncertain about.
Good org designers are comfortable making recommendations with incomplete information. The goal isn't certainty — it's a well-reasoned hypothesis you can test.
The ability to explain an organizational problem clearly and concisely to a skeptical audience is a core practitioner skill.
Imagine you have 90 seconds with a senior leader who is skeptical but open. What would you say? Write it out in full sentences — the problem, why it persists, and what you'd do about it. Read it back. Is it clear to someone who hasn't been thinking about this for three weeks?
If you can't say it in 90 seconds, you don't understand it well enough yet. Clarity of expression is a proxy for clarity of thought.
You're almost ready to write your diagnosis. Today is the last preparation step.
Write exactly three sentences: (1) What is the tension or problem? (2) Why does it persist — what in the design sustains it? (3) What is one lever that would shift the conditions? This is the spine of your one-pager.
These three sentences are the core of every good OD recommendation. Everything else — context, evidence, caveats — is in service of these three.
Your one-page diagnosis starts here. Today is just the first two sentences.
Write one clear sentence that names the organization (or team) and the challenge. Not the symptom — the challenge. Example: "Finch & Co. is a fast-growing 80-person company where decision-making authority has not kept pace with organizational complexity." Your turn. Now write a second sentence: who does this organization exist to serve, and is the challenge you've named getting in the way of serving them well?
The first sentence of a diagnosis is the hardest. It has to be specific enough to be true and general enough to hold everything that follows. The second sentence grounds it — a structural problem that costs nothing for the people you serve is a management puzzle. One that does is an organizational imperative.
Now describe what you found across the lenses.
Write two to three sentences on each lens that's relevant to your diagnosis: structure, authority, coordination, incentives. Not all will apply equally — weight them honestly. If a lens genuinely isn't a driver in your diagnosis, a single sentence saying so is a valid observation — it shows you considered it and ruled it out. Then add one more: growth. Does the design create conditions for people to develop capability, take on more authority, and learn across the organization — or does it keep people in fixed lanes? This is the evidence section of your one-pager.
Conditions descriptions are not complaints. They're observations about what the design is producing. Neutral, specific, and grounded in what you actually observed. Growth is often the quietest condition — no one complains about it directly, but it shows up everywhere in how people talk about their work.
A diagnosis distinguishes between what people experience and what's producing the experience.
List two or three symptoms — what people in this organization complain about or struggle with. Then, for each one, write the underlying cause you've identified. The symptom is what's visible. The cause is what your four-lens analysis revealed.
Treating symptoms without addressing causes is the most common failure mode in organizational change. Your diagnosis is valuable because it goes one level deeper.
One change. Well-reasoned. Honest about uncertainty. Framing a recommendation as a hypothesis isn't hedging — it's the language of someone who understands that organizations are complex systems. Senior leaders who've seen confident-but-wrong recommendations know the difference.
Write your recommendation in three sentences: what you'd change, what you believe it would shift, and what you're still uncertain about. Refer back to Day 22. You've had a week to sit with it — has your thinking changed?
A good recommendation is not a plan. It's a hypothesis. The best org designers hold their recommendations lightly and update them when they learn more.
Every recommendation lands in a political context. Knowing where the resistance will come from is part of the design work.
Who would push back on your recommendation, and why? Not who you'd expect to be difficult — who has a legitimate reason to be cautious or skeptical? Write two sentences for each person or group. Then write one sentence on how you'd address their concern.
Anticipating resistance isn't about winning arguments. It's about designing change that accounts for the real system — including the people in it.
You've done the work. Everything you need is already in your canvas. Today you assemble it.
Write your one-page org diagnosis. Use everything from Days 25–29 as your raw material. It should have: one opening sentence naming the organization and challenge, a conditions section (what the design is producing), a symptoms vs. causes section, a recommendation, and one sentence on what you're watching for. Read it back. Would a thoughtful colleague understand the problem and your reasoning without any additional context?
You just did what org designers get paid to do. You observed an organization, applied a diagnostic framework, identified root causes, and made a recommendation. That's the work. You've been doing it for 30 days.