The owners’ list for their new tower on Fifth Avenue was short. A fixed budget. No office more than 28 feet from window to corridor. As many floors of that space as possible. Limestone outside. And completion by May 1, 1931, which, as the chief designer William Lamb put it, “meant a year and six months from the beginning of sketches.”
May 1 was the day New York traditionally signed its new office leases. That made the date, as the city’s Landmarks Preservation Commission later put it, “of crucial importance in the economic planning of a speculative office building.”
By Lamb’s account, the basic scheme for the Empire State Building came together in two hours, the evening before a meeting of the owners’ corporation. By the next day, an all-night session had produced five or six of the essential plans, an elevation, a perspective and a count of rentable space.
The plans took one night. The last day had been fixed before the first of them.
Designed backward
The date reached into details you’d never connect with a calendar. Lamb’s partner R. H. Shreve explained that setting the windows slightly forward of the stone, with metal panels between them, turned most of the stonework into simple, repeated pieces that were quick to cut. The masons could keep climbing without waiting for the windows. That choice, Shreve wrote, was “of the utmost importance” in shortening the time from sketches to construction.
Construction took 410 days. The building opened on May 1, 1931.
Before you start, decide what finished looks like, then plan back from it.
Stephen Covey made this the second of the habits in The 7 Habits of Highly Effective People, published in 1989. His version rests on the idea that all things are created twice, first in the mind, then in the world, the way a house exists as a blueprint before anyone lays a brick. Covey pushed it far past buildings. He asked readers to imagine their own funeral and what they’d hope people say about them; as the FranklinPlanner blog retells the exercise, you then work backward to goals for right now.
What the end can’t tell you
The Empire State’s end was a date, and it hit the date. The building’s purpose was rent, and in its first Depression years it stood half-tenanted, nicknamed the “Empty State Building.” The prime corporate tenants its backers hoped for went to towers farther north. A clear end gets you to the place you named. It can’t check whether that place is still the right one when you arrive.
Covey’s funeral exercise is his own device, offered as advice rather than as a research finding. The narrower idea, planning backward from the goal, has a few studies behind it. In 2017, Jooyoung Park, Fang-Chi Lu and William Hedgcock reported that people who planned backward felt more motivated, expected more success, felt less time pressure and did better on the goal. In one study, students who planned for a final exam starting from the exam day scored higher than students who planned forward. The benefit was largest when the goal was complex to plan. The participants were students, planning for schoolwork, exams and job interviews, and it is one paper’s set of studies.
An earlier set of studies adds a caution. Jessica Wiese, Roger Buehler and Dale Griffin found in 2016 that backward planners predicted later finish times, and in one study that made their forecasts less over-optimistic. But the gain came because the predictions moved: the study found no significant change in when people actually finished. Working back from the end made people see the work more honestly. There was no evidence it made them faster.
The onboarding that had no finish
Imagine you’re asked to “improve onboarding” for new engineers. You could start at the front: update the welcome doc, add a buddy, tidy the wiki.
Or you could write the end first: a new engineer ships a small change to production in their first week. Then work back. Shipping needs a reviewed change. A change needs a working dev environment. The environment needs a laptop with access. And laptop access, you discover, takes eight working days to approve.
The welcome doc would have been lovely. The engineers would still have waited for their laptops.
A task whose end lived in a test
AI coding agents face this problem in its purest form. They get a description of a problem, and somewhere else, a check of whether it’s solved.
SWE-bench, a benchmark for coding agents, built its tasks from real GitHub issues and graded them with tests taken from the fixes. In 2024, OpenAI had 93 experienced Python developers screen 1,699 of the tasks. They flagged 38.3 percent for underspecified problem statements, unclear about what the problem was or how it should be solved, and 61.1 percent for tests that might unfairly mark valid solutions wrong. OpenAI filtered out 68.3 percent in all, calling its own screening likely overzealous.
One example: an issue asked why a parameter named copy in a scikit-learn function was being ignored. The grading test checked for a specific deprecation warning with specific wording. The issue never mentioned it. The end existed only in the test.
You hand agents tasks like that every time “fix the export bug” lives in your head and nowhere else. Before an agent starts, write down the check you’ll use to call it done, and put it in the instructions. Then give only the task text to a colleague, or to a fresh model session, and ask what done means. Try it a few times. If the answers keep differing from yours, treat that as a sign the task is underspecified and tighten it. Otherwise the agent may end up guessing at a deprecation message nobody wrote down.