World After Midnight

The Annual Planning Meeting That Runs Every Year Like It Hasn’t Noticed the Year

Picture this: a room full of smart, experienced people. Whiteboards covered in three-year roadmaps. Gannt charts with phase gates mapped to the quarter. A VP of Product presenting a detailed plan that accounts for every dependency, every integration, every resource. The planning took six weeks to produce. It is thorough. It is confident. And it is, in a very real sense, a work of fiction.

Not because the people are careless. They’re anything but. Not because the data is wrong. It’s the best data available. The plan is fiction because it was constructed on assumptions that stopped being true sometime in the late 1990s — assumptions about how stable markets are, how predictable competitors are, how much certainty you can actually bank on when the world now changes faster than most organizations can plan.

Eddie Obeng, a British management educator and founder of Pentacle virtual business school, made this observation the centerpiece of his career. The insight — which he articulated in a 2012 TED Talk that became the primary entry point for most people into his thinking — is disarmingly simple: there was a “midnight” moment, somewhere around the late 1990s and early 2000s, when the pace of global change crossed a threshold. After that crossing, the world began changing faster than organizations could adapt. Old assumptions about markets, competition, information, and work became unreliable. But most organizations — and most of the management tools, methods, and mental models they depend on — were designed before midnight. And they never got the memo.

The result is what Obeng calls the World After Midnight: a world where organizations keep applying pre-midnight thinking to post-midnight problems, and then are genuinely baffled by the results. Where planning cycles take six months to produce roadmaps for markets that will change in three. Where management philosophies built for industrial stability are applied to digital volatility. Where the organizational immune system identifies agile practices as the threat, rather than the rigidity those practices are trying to treat.

The Clock That Changed Everything — And the Organizations That Didn’t Notice

Obeng’s framework is built on a deceptively simple premise, but the implications keep unfolding the more you sit with it. Let’s walk through what he’s actually saying.

What “Midnight” Means

The “midnight” metaphor describes a qualitative threshold, not a specific date. Obeng points to the confluence of events in the late 1990s: the internet reaching mass adoption, globalization accelerating supply chain complexity, information becoming cheap and abundant, and the emergence of genuinely networked markets. These weren’t just new technologies layered on top of existing business conditions. They changed the fundamental dynamics of how competition works, how fast information moves, and how quickly advantage can be created — or destroyed.

Before midnight, the world changed slowly enough that organizations could afford to study it carefully, plan deliberately, and execute those plans at reasonable confidence. A three-year strategic plan wasn’t naive — it was responsible. Market conditions were relatively stable. Technology evolved on multi-year cycles. Customers were slower to shift loyalty. Competitors operated with similar information delays. In that world, “plan your work and work your plan” was genuinely good advice.

After midnight, the dynamics inverted. Markets now move faster than planning cycles. Technology produces entirely new categories in months, not years. Information asymmetry collapsed — your competitors know roughly what you know, roughly when you know it. Customers expect iteration and responsiveness, not three-year feature roadmaps. In this world, planning your work and working your plan is still respectable-sounding advice. It’s just often wrong.

The problem Obeng identifies is that most organizations’ tools, methods, and management philosophies were designed for a pre-midnight world. And since those tools are encoded in culture, training, incentive structures, and organizational habit — they don’t update automatically just because the external world changed. They keep running on their original assumptions, like an old operating system that doesn’t know its drivers are out of date.

The Four Types of Work

The most practically useful part of Obeng’s framework is a simple 2x2 matrix that categorizes work by two variables: clarity of goal (do you know what you’re trying to achieve?) and clarity of method (do you know how to get there?). The resulting four types aren’t just categories — they’re a diagnostic tool.

Here’s what makes this framework useful for agile coaches: traditional project management — the waterfall lifecycle, the detailed upfront plan, the phase-gate approval process — is fundamentally designed for Painting by Numbers. It assumes you know what you’re building and how to build it. When you apply those tools to a Quest or a Walking in Fog problem, you get expensive theater: detailed plans for things you don’t yet understand, phase-gate approvals of decisions that haven’t been made yet, and velocity metrics on work whose definition keeps shifting. The process produces documentation. What it doesn’t produce is progress.

Why Agile Emerged — and Why It Was Inevitable

This is the part that should make every agile coach feel a quiet sense of vindication.

Obeng’s framework is essentially a historical explanation for why agile had to happen. Software development — even before the internet era — almost never Painting by Numbers. Writing software for a new business domain, for new users, with new technology, is almost always Walking in Fog or Quest territory. You don’t know exactly what you’re building until you’ve built some of it and shown it to someone. The requirements that look clear in a spec document turn out to be assumptions about user behavior that may or may not be accurate. The architecture that looked solid in a diagram turns out to have failure modes you didn’t anticipate until you tried to build it.

The traditional software development lifecycle — requirements gathering, design, build, test, deploy — was imported from engineering disciplines where the Painting by Numbers assumption held. Civil engineering. Manufacturing. Infrastructure projects where the laws of physics are stable and the tolerances are known. These are domains where careful upfront analysis pays off, because you’re working with materials and forces that behave predictably.

Software doesn’t. Neither does product design. Neither does organizational change. And the Agile Manifesto, whatever else it is, represents a practitioner community saying collectively: “The tools we’re using were designed for the wrong quadrant.”

Iterative development is how you do work when goals and methods are unclear. Short feedback cycles are how you replace the false precision of upfront planning with genuine learning. Working software over comprehensive documentation is a prioritization choice that makes sense specifically when you’re Walking in Fog — the fog only clears when you build something and show it to someone. None of this is arbitrary. All of it follows logically from an honest assessment of what quadrant most software development actually occupies.

The “Outrun by Opportunities” Dynamic

There’s one more piece of Obeng’s thinking worth naming explicitly: the accelerating rate of change doesn’t just mean that plans go stale faster. It means that the gap between what your organization knows and what’s happening in the world grows continuously — and so does the number of opportunities and threats that fall outside your current awareness.

Obeng’s phrase for this is being “outrun by opportunities.” The options are proliferating faster than your decision-making process can evaluate them. By the time a traditional strategic planning cycle has analyzed an opportunity, produced a business case, secured approval, and mobilized resources — the opportunity has often passed. Or it’s changed. Or a competitor who moves faster has already taken it.

This is not a failure of ambition or intelligence. It’s a systems-level mismatch between the decision velocity your organization is built for and the decision velocity the post-midnight world requires. Agile’s short cycles, empowered teams, and emphasis on just-in-time decision-making aren’t just development practices — they’re a structural response to being outrun.

What This Changes About Your Coaching

Helping Organizations Make the Case for Agile — Without Saying “Trust Us”

Most coaches who’ve tried to explain agile to skeptical executives have experienced a version of this: you make a solid case for iterative development, and the response is some variation of “that sounds fine for experiments, but we still need to know what we’re delivering and when.” The conversation stalls because both sides are implicitly reasoning from different quadrant assumptions. You’re describing Walking in Fog work. They’re evaluating your proposal against Painting by Numbers expectations.

Obeng’s framework gives you a concrete diagnostic to make the mismatch explicit. Before the methodology conversation, run the quadrant exercise with the leadership team. Ask them to categorize their current major initiatives by goal clarity and method clarity. Most teams find, when they’re honest, that a significant portion of their “defined projects” have significant fog on one or both dimensions. The roadmap is detailed. The confidence is lower than the detail implies.

Once you’ve done that diagnostic together, the agile case changes shape. You’re no longer arguing that iteration is generally better than planning. You’re pointing to specific initiatives and saying: “Given that we’ve assessed this as a Quest — we know what we’re trying to achieve but not how — what management approach do you think fits that better: a plan with defined deliverables six months out, or short cycles with frequent review?” That’s a much more productive conversation, because both sides are looking at the same map.

Reframing the Conversation About Estimation and Predictability

One of the most persistent tensions in agile coaching is the demand for predictability. Stakeholders want dates. Finance needs budget commitments. The PMO needs a delivery plan. And there’s a version of this that’s entirely reasonable — organizations need to coordinate, and coordination requires some shared sense of timing.

But there’s a layer underneath the predictability demand that Obeng’s framework helps surface: the assumption that the work is predictable in principle, and that agile teams are just being evasive when they hedge on timelines. That assumption holds in the Painting by Numbers quadrant. It doesn’t hold in the other three.

When you’re coaching a team that’s navigating a Walking in Fog initiative and facing pressure to produce hard delivery commitments, Obeng gives you a frame that’s easier for non-technical stakeholders to grasp than “the complexity is too high to estimate accurately.” Ask the leadership team whether they’d want a meteorologist to give them a precise temperature forecast for six months from today. The question lands because everyone understands that long-range weather prediction is inherently limited by the nature of the system being predicted — not by the meteorologist’s skill. The same logic applies to novel, complex product development.

What you can offer instead is: honest progress transparency, frequent re-forecasting based on real data, and an explicit acknowledgment of which parts of the plan are known and which are still fog. That’s not less rigor. It’s better rigor — the kind that accounts for the actual nature of the work.

Coaching Leaders on Strategy in a Post-Midnight World

The deepest application of this framework is in helping senior leaders develop genuinely post-midnight strategic instincts. Not just adopting agile practices at the team level, but reconsidering how they think about uncertainty, planning, and competitive advantage.

Pre-midnight strategy looked like: gather information, perform analysis, choose a direction, commit resources, execute. The quality of the strategy was primarily a function of the quality of the analysis. This logic works when the environment is stable enough that the analysis stays valid through execution.

Post-midnight strategy looks more like: develop hypotheses about where value might emerge, place multiple small bets, learn from the results, and reallocate quickly toward what’s working. The quality of the strategy is primarily a function of the learning velocity and resource flexibility. Commitment is good — but commitment to learning cycles, not to predetermined outcomes.

Most leadership teams haven’t explicitly made this transition. They’re running post-midnight organizations with pre-midnight strategic instincts — investing heavily in annual planning processes, requiring detailed business cases for any meaningful resource commitment, and treating course corrections as strategic failures rather than learning signals. Coaching these leaders isn’t about telling them their planning is wrong. It’s about helping them see the quadrant mismatch, and then building the practices — small bets, frequent reviews, explicit learning objectives — that fit the territory they’re actually navigating.

What It Looks Like in the Room

Priya had been an agile coach for seven years, mostly in financial services, when she took on an engagement with a mid-size insurance company trying to modernize their claims processing platform. The company had been doing “agile at the team level” for about two years — sprints, standups, the basic ceremonies — but the program leadership was still running quarterly planning cycles with detailed delivery commitments to the board.

She was brought in to help the program director, Marcus, understand why the delivery dates kept slipping. The teams were working hard. The velocity metrics looked reasonable. And yet every quarterly board presentation required an explanation of why last quarter’s commitments hadn’t fully materialized.

Marcus had a theory: the teams weren’t estimating carefully enough. His proposed solution was a more rigorous estimation process — better backlog refinement, T-shirt sizing followed by planning poker, tighter sprint goals. He’d even drafted a new estimation policy.

Priya sat down with him in his office and asked a different question. “Before we talk about estimation,” she said, “can you walk me through the last three initiatives that missed their original dates? Not why they slipped — just describe what the work actually was.”

Marcus pulled up his notes. The first was a new mobile claims submission feature. The second was an integration with a third-party fraud detection vendor. The third was a customer communications overhaul aimed at reducing inbound call volume.

She asked him to describe, for each one, whether the team knew exactly what they were building when the commitment was made, and whether they knew exactly how they were going to build it.

He worked through the answers slowly. The mobile claims feature had started with a clear brief, but user research in sprint three had revealed that customers wanted something quite different from the original design — the scope had changed significantly. The fraud detection integration had run into API documentation that didn’t match the vendor’s actual behavior — the method was messier than anticipated. The customer communications overhaul… Marcus paused. “Honestly, we never quite agreed on what success looked like for that one. We had metrics, but nobody felt certain they were the right metrics.”

Priya drew a 2x2 on a notepad. Labeled the axes. Named the four quadrants.

“Where would you put each of those projects when the commitment was made?”

Marcus placed the mobile feature in Painting by Numbers — clear goal, clear method, he said. But as he thought about it, he moved it. “The goal was clear, I suppose. But we didn’t really know how users would respond to our design. So… Quest?” He drew a circle in the Quest quadrant.

The fraud integration he put directly in Quest — the goal was clear (get the vendor integrated), but the method had turned out to be murky. He looked up from the notepad. “We committed to dates as if this was Painting by Numbers.”

The customer comms overhaul he put in Walking in Fog without hesitation. “We didn’t really know what we were trying to achieve, and we definitely didn’t know how to achieve it.” He set the pen down. “And we made a board commitment in month one.”

There was a long pause.

“The estimation isn’t the problem,” he said. It wasn’t quite a question.

“Your teams are estimating their sprints reasonably well,” Priya said. “The problem is that the program-level commitments are being made as if the work is in this quadrant” — she tapped Painting by Numbers — “when the actual work is in these.” She tapped Quest and Walking in Fog.

What followed was a conversation about what a different board reporting structure might look like. Not “we committed to delivering X by Q3” but “here’s what we’ve learned in Q2, here are our current hypotheses for Q3, and here’s the decision we’ll make at the midpoint based on what we observe.” Marcus was quiet for a moment. “That sounds like telling the board we don’t know what we’re doing.”

“Or,” Priya said, “it sounds like telling the board you’re managing complex work honestly, rather than pretending it’s simple and then explaining every quarter why the prediction didn’t hold.”

It took three more sessions before Marcus was ready to take the new framing to the board. The first time he presented it, one of the board members actually thanked him for the clarity. “This makes more sense than a slide full of RAG statuses,” she said.

The quarterly planning cycle didn’t disappear. But it changed shape — from “here are our commitments” to “here are our bets and our learning objectives.” The teams didn’t suddenly start hitting targets perfectly. But the conversation when things changed shifted from “who missed what” to “what did we learn and what do we do next.”

That’s what Obeng’s framework actually does in a coaching context. It doesn’t make uncertainty go away. It makes it visible — and it gives organizations permission to manage it honestly, instead of pretending it’s not there.

Go Deeper

• Obeng, E. (2012). “Smart failure for a fast-changing world.” TED Global, 2012. The twelve-minute entry point for most people into this framework. Worth watching even if you’re already familiar with the ideas — Obeng is a compelling, funny presenter and the four-quadrant framework lands cleanly in the talk.

• Obeng, E. (1994). All Change! The Project Leader’s Secret Handbook. London: Financial Times / Pitman Publishing. The book where the four project types (Painting by Numbers, Quest, Movie, Walking in Fog) appear in their most developed form. Reads as practical project management advice; the quadrant framework is the intellectual core.

• Obeng, E. (1994). Making Re:Engineering Happen. London: Financial Times / Pitman Publishing. Focuses on organizational change and the challenges of transformation — the World After Midnight context applied specifically to large-scale change initiatives. Out of print but findable.

• Snowden, D.J. & Boone, M.E. (2007). “A Leader’s Framework for Decision Making.” Harvard Business Review, November 2007. The Cynefin framework, which covers related territory from a different angle. Obeng and Snowden are usefully read together — Obeng’s four types and Cynefin’s domains aren’t the same thing, but they both address the core problem of applying the wrong management approach to the wrong kind of work. Worth using whichever resonates more with a given audience.

• Beck, K. et al. (2001). Manifesto for Agile Software Development. You know what this is. Worth re-reading with Obeng’s lens active. The four values and twelve principles look different — more like a specific, considered response to a specific, diagnosed problem — once you understand the post-midnight context they emerged from.