Week 21 Day 3: Horizon 2 -- What We Are Building Next

Horizon 2 contains the work that will enter Horizon 1 in the next one to three months. It is actively being planned, designed, and scoped -- but not executed. The team knows it is coming. Key decisions are being made. Dependencies are being identified. But nobody is writing code or building deliverables for Horizon 2 work yet. The discipline is keeping Horizon 2 in design mode, not execution mode.

Horizon 2 is where most leaders fail. The temptation is to start execution on Horizon 2 work before Horizon 1 is complete -- 'just getting a head start.' This head start is a trap. It splits the team's attention, increases context-switching, and creates two half-finished workstreams instead of one finished one. The right activities for Horizon 2 are: architectural design discussions, requirements gathering, dependency identification, stakeholder alignment, and prototype exploration. These activities require a fraction of the team's bandwidth and can run in parallel with Horizon 1 execution without significant context-switching cost. The wrong activities for Horizon 2 are: building features, writing production code, creating infrastructure, or deploying anything to a real environment. The moment Horizon 2 work starts consuming the same people who are doing Horizon 1 work, the model is broken. In my experience, the most effective teams dedicate one person -- a tech lead or senior architect -- to Horizon 2 preparation while the rest of the team focuses entirely on Horizon 1. When Horizon 1 completes, the prepared Horizon 2 work slides into Horizon 1 cleanly because someone was already thinking about it. The key phrase is 'thinking about' -- not 'building.'

The Horizon 2 concept draws from the McKinsey Three Horizons of Growth model (Baghai, Coley, and White, 1999), which originally applied to business strategy: Horizon 1 is the current core business, Horizon 2 is emerging opportunities, and Horizon 3 is long-term bets. Adapting this to team-level cognitive management preserves the temporal structure while shifting the unit of analysis from business value to attention allocation. The prohibition against premature execution in Horizon 2 reflects what Reinertsen (2009) calls the 'cost of delay' framework -- starting work before it is fully scoped increases variability, which in turn increases queue time for all work in the system. His research on product development flow demonstrates that the economic cost of high variability (partially scoped, prematurely started work) exceeds the economic cost of delay (waiting until scoping is complete). The dedicated preparation person model aligns with what Hackman (2002) calls 'team coaching' -- having a team member whose role is to scan ahead and prepare the conditions for future work, rather than contributing to current execution. Research by Sterman (2000) on system dynamics demonstrates that 'pipeline delays' -- the time between starting and completing work -- are the primary source of oscillation in organizational performance, and that reducing pipeline delays through better preparation produces smoother, more predictable output.