The Pulse of Engineering
Most modern technology companies operate on a quarterly cadence — a 12-13 week cycle that provides a natural rhythm for planning, executing, and reflecting. This isn't arbitrary; it's long enough to accomplish meaningful work but short enough to course-correct before a bad bet consumes an entire year.
Annual planning is too slow: the market changes, assumptions expire, and teams spend 11 months executing a plan that was obsolete by February. Monthly planning is too fast: meaningful infrastructure work — a database migration, a new observability platform, a compliance certification — cannot be meaningfully started and finished in four weeks. Twelve weeks is the Goldilocks interval.
The Phases in Detail
Phase 1: Planning (Week -2 to Week 0)
This is the most important phase, and the one most teams underinvest in.
Week -2: Leadership publishes Company-level OKRs. These are typically 3-5 objectives that represent the company's top priorities for the quarter. Example: "Win the enterprise market segment."
Week -1: Engineering teams digest the company OKRs and draft their Team-level OKRs. This is a negotiation, not a dictation. The team proposes how they can best contribute to the company's goals given their expertise, current technical debt, and capacity.
Company Signal: "Win Enterprise."
Team Response: "To help win Enterprise, we will:
O: Build enterprise-grade platform foundations
KR1: Implement SAML-based SSO for all services
KR2: Deploy audit logging with <5s event latency
KR3: Achieve 99.95% availability (up from 99.5%)"
Week 0: OKRs are finalized, published, and shared across the organization. Every team can see every other team's OKRs. This transparency is critical — it prevents duplicate work and surfaces dependencies early. If the security team and the platform team are both planning to build audit logging, the overlap is visible before either team writes a line of code.
Phase 2: Execution (Weeks 1-10)
This is where the actual work happens, typically organized into 2-week sprints:
- Weekly OKR check-ins: Each Monday, the team spends 15 minutes reviewing Key Result progress. Are we on track? What's blocking us? Do we need to adjust?
- Mid-quarter review (Week 5-6): A more formal checkpoint. If a Key Result is clearly going to miss, this is the time to either re-scope or reallocate resources. Waiting until Week 11 to discover you're off track is a planning failure.
- Dependency management: If your KR depends on another team's work, this is when you escalate blockers. Don't be polite about it — a blocked KR is a strategic risk.
Phase 3: Landing and Grading (Weeks 11-12)
Week 11: Stop starting new work. Focus on landing what's in flight. "Landing" means getting work to a shippable, measurable state — not "80% done," which in engineering means "not done."
Week 12: Grade each Key Result on a 0.0 to 1.0 scale:
Grading Scale:
0.0 - 0.3 → Failed to make meaningful progress
0.4 - 0.6 → Made progress but fell short
0.7 - 0.8 → Delivered (the sweet spot for stretch goals)
0.9 - 1.0 → Nailed it (or the goal wasn't ambitious enough)
If you consistently score 1.0 on all OKRs, your goals are too easy. Google's philosophy is that 0.6-0.7 is the ideal average — it means you're setting ambitious targets and achieving most of them.
Common Traps
Trap 1: Planning too late. If your team doesn't know what it's doing on Day 1 of the quarter, you've already lost 8-15% of your execution time. Planning should be complete before the quarter starts, not beginning.
Trap 2: The "Carry-Over" OKR. An OKR that rolls from Q1 to Q2 to Q3 unchanged is a zombie. Either the goal isn't important enough to finish (kill it), or the team is consistently underestimating the work (re-scope it).
Trap 3: Confusing confidence with commitment. At the start of the quarter, you should be about 50% confident you can hit your OKRs. If you're 90% confident, you're sandbagging. If you're 10% confident, you're setting yourself up for failure and demoralization.
Trap 4: No mid-quarter correction. The plan is not sacred. If market conditions change, a key dependency falls through, or you discover a critical assumption was wrong, adjust the OKRs mid-quarter. Document the change and the reason. Rigidly following an outdated plan is not discipline — it's stubbornness.
Key Point: The quarterly cycle is a feedback loop, not a waterfall. Each quarter's retrospective should directly inform the next quarter's planning. If you shipped audit logging in Q1 but discovered it doesn't meet the enterprise customer's actual requirements, Q2's OKR should address the gap — not repeat the same goal with the same approach. The retrospective is where organizational learning happens; skipping it means repeating the same mistakes at the same cost every quarter.