Systems Thinking
Seeing how parts connect and designing for the whole
Week 10 Day 1: You Are a Liability -- And That Is Okay
Every leader is a single point of failure for something. The ones who build great teams are not the ones who eliminate their flaws -- they are the ones who build systems around them....
Week 10 Day 2: The System Is the Safety Net, Not Your Willpower
Willpower is a depletable resource. Systems run whether you have energy or not. The best leaders design their teams so that the right things happen automatically....
Week 10 Day 3: How to Automate Accountability
The best accountability systems do not depend on someone reminding you. They make the status of every commitment visible to everyone, all the time....
Week 10 Day 4: Creating Guardrails for Your Worst Patterns
You know your patterns by now. The question is not whether they will show up again -- it is whether you have built guardrails that catch you when they do....
Week 10 Day 5: What a 'Leader-Proof' Process Looks Like
A leader-proof process is one that produces good outcomes regardless of the leader's mood, energy, or attention on any given day. It is not an insult to your leadership -- it is a testament to your de...
Week 10 Day 6: Your Team Should Be Able to Succeed Even on Your Bad Days
Your worst day should not be your team's worst day. If your bad mood, low energy, or distracted attention derails the team's work, the system is designed around your presence, not around their success...
Week 10 Day 7: Assignment: Design One System That Compensates for Your Biggest Gap
This week's assignment: pick your single biggest leadership gap -- the pattern that costs your team the most -- and design a system that compensates for it. Not a habit. Not a reminder. A system that ...
Week 13 Day 1: The 'Why Does This Matter?' Question
Every task on your backlog should be able to answer one question in a single sentence: 'Why does this matter to the business?' If it cannot, it should not be there....
Week 13 Day 2: Every Task Either Creates Value or Protects Value
There are only two valid reasons for any task to exist: it creates new value for customers, or it protects existing value from degradation. Everything else is waste....
Week 13 Day 3: How to Map a Sprint to Business Outcomes
A sprint that cannot be described in business outcome terms is a sprint the business cannot evaluate. And a sprint the business cannot evaluate is a sprint that will eventually be questioned....
Week 13 Day 4: When Your Team's Work Is Three Steps Removed From Revenue
Not every team builds customer-facing features. Some teams are three steps removed from revenue -- and they need a different value narrative....
Week 13 Day 5: Making the Connection Visible Without Oversimplifying
The gap between 'everything connects to value' and 'here is exactly how' is where most leaders fail. Precision matters more than enthusiasm....
Week 13 Day 6: The Danger of Only Valuing What You Can Measure
Not everything that counts can be counted. If you only value measurable work, you will systematically underinvest in the work that matters most long-term....
Week 13 Day 7: Assignment: Build Your Leadership Operating Manual (Draft 1)
This is the assignment that Week 1 promised -- your first draft of a Leadership Operating Manual. A written document that tells your team how you work, what you value, and what to expect from you....
Week 26 Day 1: More Work Fails in the Handoff Than in the Execution
The most dangerous moment in any project is not the hardest technical challenge -- it is the moment responsibility transfers from one person to another....
Week 26 Day 2: Why 'All You Gotta Do Is...' Breaks Teams
The five most destructive words in leadership are 'all you gotta do is.' They minimize the work, insult the person, and guarantee a broken handoff....
Week 26 Day 3: The Gap Between What You Said and What They Heard
Every handoff contains two messages: the one you sent and the one they received. They are never the same message, and the gap between them is where failures live....
Week 26 Day 4: Hand-Offs Fail When Context Is Assumed
The most common handoff failure is not missing information -- it is assumed context. The sender knows why the work matters, what has been tried before, and what constraints exist. The receiver knows n...
Week 26 Day 5: The Five Things Every Handoff Needs
Every clean handoff transfers five things: what needs to happen, why it matters, what has been tried, what constraints exist, and how the receiver should signal if they are stuck....
Week 26 Day 6: What a Clean Handoff Looks Like in Practice
A clean handoff feels unremarkable. Nobody notices it because nothing went wrong. That invisibility is what makes it hard to prioritize -- and what makes it one of the highest-leverage leadership skil...
Week 26 Day 7: Assignment: Audit One Recent Handoff That Went Wrong
This week's assignment turns your most recent handoff failure into a diagnostic tool -- trace the failure backward to the specific information gap and design the fix....
Week 33 Day 1: If You Are Always Putting Out Fires, You Built a Flammable Organization
Firefighting is not leadership. It is the evidence that leadership failed to build systems that prevent fires in the first place....
Week 33 Day 2: Why Firefighting Feels Heroic but Is Actually a Failure
The leader who swoops in to save the day feels like a hero. The team cheers, the crisis is averted, and the adrenaline is addictive. But every heroic save is evidence that the system failed -- and the...
Week 33 Day 3: The Leader as Arsonist -- When Your Chaos Creates the Emergencies
Some leaders do not just fail to prevent fires. They start them. Last-minute direction changes, unclear priorities, unrealistic deadlines, and constant re-prioritization -- these are not leadership. T...
Week 33 Day 4: How to Diagnose Recurring Fires
The first step in building systems is diagnosing which fires are recurring. Not all problems need systems. Only the ones that keep coming back....
Week 33 Day 5: Building a System Is Slower Than Fixing the Problem (and That Is the Point)
The reason leaders default to firefighting instead of system-building is that fixing the immediate problem takes an hour and building a system takes a week. But the leader who invests the week saves m...
Week 33 Day 6: What a Team Looks Like When Systems Actually Work
A team with good systems looks boring from the outside. No drama, no heroics, no all-nighters. Just consistent, predictable delivery. That boring consistency is the result of excellent leadership....
Week 33 Day 7: Assignment: List Your Team's Top Three Recurring Fires
This week's assignment starts the diagnostic process: identify the three recurring problems that consume the most of your team's unplanned time, and calculate the cost of each....
Week 34 Day 1: Chaos Is Not a Market Condition -- It Is an Internal Design Choice
Leaders blame chaos on market conditions, competitive pressure, and organizational complexity. In reality, internal chaos is almost always a design choice -- the result of decisions the leader made or...
Week 34 Day 2: The Hidden Cost of Constant Re-Prioritization
Every time you change the team's priorities, you pay a cost. The visible cost is the rework. The hidden costs are the context-switching overhead, the trust erosion, and the learned helplessness that a...
Week 34 Day 3: The Urgent-Important Matrix Is Not Just a Framework -- It Is a Survival Tool
Eisenhower's urgent-important matrix is the most cited and least applied framework in leadership. If your team spends most of its time in the urgent quadrants, the organization is dying slowly under t...
Week 34 Day 4: How Lack of Process Creates the Appearance of Speed
Leaders who resist process believe that process slows teams down. They are half right -- bad process slows teams down. The absence of process creates the illusion of speed while producing less than a ...
Week 34 Day 5: The Organization's Tolerance for Chaos Reveals Its Leader's Tolerance for Chaos
Organizations reflect their leaders. If the leader tolerates chaos -- or worse, thrives in it -- the organization will be chaotic. The fish rots from the head....
Week 34 Day 6: How to Introduce Calm Into a Chaotic Organization Without Slowing Down
The fear behind resisting process is that calm equals slow. In reality, calm equals focused. A focused team produces more than a frenzied team, faster and with fewer errors....
Week 34 Day 7: Assignment: Audit Your Team's Chaos Sources
This week's assignment: catalog every source of unplanned work and disruption on your team for the past month, and classify each as externally caused or internally caused....
Week 35 Day 1: A Process Is a Promise -- It Tells the Team What to Expect
Every process is an implicit promise: 'This is how things work here. You can depend on it.' When the process is reliable, trust grows. When the process is inconsistent or ignored, trust erodes....
Week 35 Day 2: Good Process Liberates; Bad Process Imprisons
The reason people hate process is not that process is inherently bad -- it is that they have experienced bad process. Good process removes friction and frees people to focus on their work. Bad process...
Week 35 Day 3: The Minimum Viable Process -- Start Light and Add Weight Only When Needed
The biggest mistake in process design is starting too heavy. Begin with the lightest process that prevents the most common failure mode. Add complexity only when the light version fails in a specific,...
Week 35 Day 4: How Repeatable Processes Scale Trust Across the Organization
Trust does not scale through relationships alone. At some point, the organization grows beyond the number of people any individual can know personally. At that point, trust must be embedded in process...
Week 35 Day 5: The Playbook Model -- Documenting How Your Team Works
A team playbook is a living document that captures how the team operates: how decisions are made, how work is prioritized, how communication flows, and how problems are handled. It is the codification...
Week 35 Day 6: When to Break Your Own Process
Good process includes a defined mechanism for overriding the process when circumstances demand it. A process without an override mechanism becomes a cage; a process with an override mechanism becomes ...
Week 35 Day 7: Assignment: Design One Repeatable Process for Your Team's Most Common Handoff
This week's assignment: identify your team's most common handoff (the point where work passes from one person or team to another) and design a repeatable process for it....
Week 36 Day 1: Stop Operating and Start Designing
The most important transition in a leader's career is the shift from operating -- doing the work and managing the work -- to designing -- building the systems that enable others to do and manage the w...
Week 36 Day 2: The Architect Thinks About the System; The Operator Thinks About the Task
When a problem occurs, the operator asks 'How do I fix this?' The architect asks 'Why did the system produce this problem, and how do I change the system so it does not produce this problem again?'...
Week 36 Day 3: What It Means to Design Your Organization Instead of Running It
Designing your organization means making deliberate decisions about structure, process, communication, and decision-making authority -- rather than letting these evolve by accident....
Week 36 Day 4: When to Step Out of Operations -- The 80/20 Rule for Leaders
You cannot design the organization while you are buried in its daily operations. The 80/20 rule for leaders: 80% of the long-term value you create comes from the 20% of your time spent on design, not ...
Week 36 Day 5: How Architects Think: Inputs, Outputs, Constraints, and Feedback Loops
The architectural mindset uses four lenses to analyze any organizational system: what goes in (inputs), what comes out (outputs), what limits the system (constraints), and what information flows back ...
Week 36 Day 6: The Hardest Part of Being an Architect Is Watching Others Operate Imperfectly
When you shift from operator to architect, you must accept that others will operate the systems you designed differently than you would -- and often less efficiently. This is not a failure. It is the ...
Week 36 Day 7: Assignment: Spend One Hour This Week Designing Instead of Doing
This week's assignment: block one hour on your calendar for organizational design work. During that hour, pick one systemic issue your team faces and design a solution -- do not fix the issue manually...
Week 39 Day 1: Context-Switching Is the Silent Killer of Team Performance
Every time a team member switches between unrelated tasks, they lose 15-25 minutes of productive focus. A team that juggles five concurrent priorities does not move five things forward -- it moves not...
Week 39 Day 2: Priority Debt Is More Dangerous Than Technical Debt
Technical debt accumulates when you take shortcuts in code. Priority debt accumulates when you take shortcuts in decision-making -- when you say yes to everything rather than making the hard choice ab...
Week 39 Day 3: Stack Ranking Your Priorities Forces Honest Decisions
Most leaders list their priorities as a set of equally important items. Stack ranking forces you to decide which priority is first, which is second, and which is last. The discipline of ordering -- no...
Week 39 Day 4: Saying No Is the Most Important Leadership Skill Nobody Teaches
Every yes is a no to something else. When you say yes to a stakeholder's new request, you are saying no to the time your team would have spent on something already committed. The only question is whet...
Week 39 Day 5: The Urgent-Important Matrix Is Not Enough -- You Need an Attention Budget
The Eisenhower Matrix categorizes work into four quadrants: urgent-important, urgent-not-important, not-urgent-important, and not-urgent-not-important. This categorization is useful but insufficient b...
Week 39 Day 6: What Your Team Accomplishes When They Stop Trying to Do Everything
The paradox of prioritization: teams that work on fewer things accomplish more. Not just more per project -- more total output. Reducing the number of active priorities increases throughput because it...
Week 39 Day 7: Assignment: Cut Your Active Priorities by Half
This week's assignment: count the number of active workstreams your team is pursuing. Then cut that number by half. Decide which half stays and which half is explicitly paused....