The Six-Week Review Operating Cadence
Short, frequent check-ins where leaders pair on problems, not catch you slacking, create velocity.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 85%
An operating rhythm combining weekly written updates (GSD), tiered alignment reviews, and a company-wide six-week deep review with the CEO. The counterintuitive claim: more frequent check-ins increase speed because each one is an opportunity to pair on the problem and unblock, and the recurring deadline harnesses Parkinson's Law to force visible progress.
Origin
Shopify's system as run by Thawar. 'GSD' (Get Shit Done) is weekly whole-company updates; six-week reviews replaced a twice-a-year cadence. Framing draws on Parkinson's Law and Elon Musk's 'what did you get done this week' text, but reframed as pairing rather than surveillance.
Core principles
- 01A check-in is 'trust but verify' and an invitation to pair on the problem, NOT a Dilbert-boss 'gotcha.'
- 02Micromanagement isn't a dirty word when it means 'can I work on this problem with you.'
- 03Six weeks is the sweet spot: short enough to remember context, long enough for a team to ship real progress.
- 04The recurring deadline makes people want to show progress every single week (Parkinson's Law).
- 05Don't wait for the next review to act; iterate the very next day on feedback received.
How to run it
- 1
Run weekly whole-company updates (GSD)
Every week, each project posts an update to the whole company, ideally high-fidelity (writing plus a demo or video, not just screenshots). Because people want to show progress weekly, the cadence itself drives momentum.
Pro tip Prefer demos and beta-flag links over screenshots so reviewers can feel the actual experience (e.g. notice a page takes 20 seconds to load).
- 2
Layer tiered alignment sign-offs (OK1 / OK2)
OK1 is typically a director confirming they're aligned with the direction (or making changes). OK2 is typically an area VP checking fit with the overall architecture and surfacing context the team may have missed.
- 3
Hold a company-wide six-week deep review
Every six weeks, teams walk their roadmap, resourcing, and work through with immediate leadership and with Toby over several days in the office. Every project in the company gets discussed and changed as needed.
Pro tip Six weeks is chosen deliberately: short enough to still hold context in your head, long enough for a dozen-engineer team to accomplish something substantial.
Watch out It's a huge time investment (multiple full days of many people); the payoff is the intensity and alignment it creates, so protect the cadence.
- 4
Act on feedback immediately, treating check-ins as pairing
Don't wait for the next six-week review to respond to feedback; the next day, build, iterate, and tag people. Use the check-in to pair on the actual problem and unblock, not to catch people out.
Pro tip When a team hit an LLM output-context-window limit, Thawar simply asked in the shared OpenAI/Gemini Slack channels and had the limit raised within an hour, unblocking the team without waiting for the next review.
Watch out If check-ins feel like surveillance ('did you do your thing?') they lose their power; the intent must be to pair and unblock, or trust erodes.
In the wild
In a six-week review, a team was blocked because they needed a large output context window that most LLMs didn't offer, and were planning complex chunking and caching workarounds. Thawar messaged the OpenAI and Gemini teams in shared Slack channels asking if a bigger output context was possible.
→ Within an hour, the vendors enabled larger output context for Shopify (an undocumented capability), and the team was unblocked without waiting for the next review, raising the team's intensity.
Early in Thawar's Shopify tenure he told Toby not to waste time on their one-on-ones since he was hired to take problems away. Toby replied 'you misunderstand why you're here, we're here to work on problems together.'
→ Thawar reframed his understanding of the whole check-in system: leaders pair on problems with reports rather than merely receiving status, which is what makes the cadence accelerate work.
Common mistakes
Treating check-ins as gotcha surveillance
If the check-in is a Dilbert-boss 'did you do your work?', it demoralizes and doesn't help. The goal is to pair on the problem, share context, and unblock, so the person gets leadership's broader view and moves faster.
Waiting for the next review to act on feedback
Deferring changes until the next scheduled review wastes the six weeks. High-velocity teams iterate the next day, tag people, and arrive at the following review with a visible trajectory.
Is it for you?
Best for
Fast-moving orgs and engineering leaders who want alignment and momentum without drowning in meetings, where leaders can meaningfully pair on problems.
Not ideal for
Cultures of low trust where check-ins will be experienced as monitoring, or teams whose leaders lack the context to actually help with the work.
From the transcript
“we find six weeks is a very good Cadence because it's short enough that you can remember the context and it's long enough”
“the goal of the check-in is not for you to be like haha I caught you not doing your work”
“it is like even when I look at the Elon text which is like hey what did you get done this week it wasn't to…”
“we're here to work on problems together”
From the episode
How Shopify builds a high-intensity culture
Farhan Thawar (VP and Head of Eng)