In a revelation that should make every Scrum Master question their life choices and every Product Owner reconsider their relationship with reality, the Empire State Building—all 102 floors and 1,454 feet of it—was constructed in a mere 410 days without a single sprint retrospective, daily standup, or color-coded Kanban board. This architectural marvel, completed in 1931, stands as a monument not just to human ambition, but to the profound absurdity of our current technological predicament: we’ve somehow convinced ourselves that building software requires more coordination tools than constructing the world’s tallest building!
The Empire State Building project, managed with nothing more sophisticated than blueprints, telephone calls, and the revolutionary project management methodology known as “talking to people,” employed 3,500 workers who somehow managed to coordinate their efforts without Slack notifications, Zoom fatigue, or a single meeting about meetings. They moved 60,000 tons of steel, laid 10 million bricks, and installed 6,514 windows—all while operating under the apparently antiquated belief that work should produce tangible results rather than perfectly organized digital artifacts of productivity theater.
The Great Jira Paradox: When Tools Become the Work
Modern software development has achieved something the 1930s construction industry could never have imagined: the complete transformation of work into the management of work. Today’s tech teams spend more time updating ticket statuses than the Empire State Building’s workers spent on their entire lunch breaks. A typical software engineer now dedicates approximately 23% of their working hours to what Atlassian euphemistically calls “project coordination activities”—a phrase that would have baffled the construction foreman who built 14 floors in 10 days using nothing more than a clipboard and an alarming disregard for OSHA regulations.
The Empire State Building’s project manager, John J. Raskob, operated under the quaint assumption that if you hired competent people and gave them clear objectives, they would simply accomplish those objectives without requiring a digital ecosystem of interconnected productivity applications. This primitive approach somehow resulted in a building that has stood for nearly a century, while modern software projects routinely collapse under the weight of their own project management infrastructure.
Consider the cognitive dissonance: the Empire State Building team coordinated the delivery of 57,000 tons of structural steel to a construction site in Manhattan without a single Gantt chart, while contemporary software teams require specialized tools to coordinate the delivery of a login button that may or may not work on Internet Explorer. The building’s architects managed to synchronize the work of dozens of specialized trades—electricians, plumbers, steelworkers, and elevator installers—using revolutionary communication technologies like “walking over and asking questions” and “looking at the same piece of paper together.”
The Mythology of Digital Coordination
The tech industry has constructed an elaborate mythology around the necessity of digital project management tools, suggesting that software development represents a uniquely complex form of human endeavor that requires unprecedented levels of coordination and oversight. This mythology conveniently ignores the fact that humans have successfully completed vastly more complex projects—from the construction of cathedrals to the coordination of D-Day—without requiring dedicated Product Owners to translate business requirements into user stories formatted according to specific syntactic conventions.
Jira, the dominant project management platform in software development, has achieved something remarkable: it has convinced an entire industry that tracking work is more important than doing work. The platform’s complexity rivals that of the software being developed, requiring specialized training, dedicated administrators, and regular “optimization” sessions that somehow never result in actual optimization. Teams spend entire meetings discussing whether a task should be classified as a “Story,” “Epic,” “Bug,” or “Task,” as if the semantic precision of these categories will somehow accelerate the delivery of functional software.
The Empire State Building’s construction teams operated under a different paradigm entirely. When a steelworker needed to know what to do next, he looked at the building. When a project manager needed to assess progress, he counted floors. When stakeholders wanted status updates, they could literally see the results rising into the Manhattan skyline. This approach, while primitive by modern standards, had the distinct advantage of producing a building rather than a comprehensive database of building-related metadata.
The Productivity Paradox of Modern Software Development
The proliferation of project management tools in software development has coincided with what researchers are calling the “productivity paradox of modern programming”—the phenomenon whereby teams equipped with increasingly sophisticated coordination tools seem to produce software at an increasingly glacial pace. While the Empire State Building rose at a rate of approximately one floor every three days, modern software projects routinely require months to implement features that would have taken 1990s developers weeks to complete using nothing more than email and the occasional phone call.
This paradox becomes more pronounced when considering the relative complexity of the challenges involved. The Empire State Building required the coordination of multiple engineering disciplines, the management of complex supply chains, and the synchronization of work across dozens of specialized trades. Modern software development, by contrast, typically involves teams of people with similar skill sets working on problems that exist entirely within digital environments designed specifically to facilitate collaboration.
Yet somehow, the Empire State Building’s project team managed to maintain perfect coordination across their massive undertaking without requiring daily ceremonies to ensure “alignment” or weekly retrospectives to identify “process improvements.” They operated under the apparently radical assumption that competent professionals, given clear objectives and adequate resources, would naturally coordinate their efforts to achieve those objectives without requiring a dedicated class of coordination specialists to facilitate their coordination.
The Ceremonial Nature of Modern Project Management
Contemporary software development has evolved into an elaborate ceremonial practice that bears little resemblance to the pragmatic problem-solving that characterized the Empire State Building’s construction. Modern development teams participate in daily standups, sprint planning sessions, backlog grooming meetings, sprint reviews, and retrospectives—a ritual calendar that would make medieval monks envious of its structured regularity and apparent disconnection from tangible outcomes.
The Empire State Building’s construction proceeded without a single “retrospective” session where workers gathered to discuss “what went well, what didn’t go well, and what could be improved.” Instead, they operated under the primitive assumption that if something wasn’t working, they would notice immediately and fix it immediately, rather than waiting for the next scheduled process improvement ceremony to formally acknowledge the problem and develop an action plan for addressing it in future iterations.
This ceremonial approach to software development has created what anthropologists might recognize as a cargo cult mentality—the belief that performing the rituals of successful project management will somehow invoke the spirit of successful project completion. Teams meticulously maintain their Jira boards, conduct their ceremonies, and generate their velocity metrics while the actual software they’re supposedly building remains perpetually “almost ready” for release.
The Tools That Manage the Managers
Perhaps most remarkably, modern project management tools have achieved something the Empire State Building’s construction never required: they have created an entire class of workers whose primary responsibility is managing the tools used to manage the work, rather than doing the work itself. Scrum Masters, Product Owners, and Project Managers spend their days optimizing workflows, facilitating ceremonies, and maintaining digital artifacts that exist primarily to demonstrate that project management is occurring.
The Empire State Building was completed without a single person whose job title included the word “Master” or “Owner” in reference to abstract process concepts. The project succeeded through the revolutionary approach of having people who understood construction manage construction, rather than having process specialists manage the people who understood construction. This approach, while clearly primitive by contemporary standards, had the distinct advantage of maintaining a direct relationship between management activities and construction outcomes.
Modern software teams, by contrast, often include more people managing the work than doing the work. These management specialists possess deep expertise in project management methodologies but may have limited understanding of the actual software being developed. They excel at optimizing processes, facilitating communication, and generating metrics, but their success is measured by the quality of their process optimization rather than the quality of the software being produced.
The Measurement Delusion
The Empire State Building’s project team measured their progress using a remarkably simple metric: floors completed. This crude measurement system somehow enabled them to maintain perfect awareness of their progress, identify problems immediately, and adjust their approach in real-time. Modern software development has evolved far beyond such primitive measurement approaches, employing sophisticated metrics like story points, velocity calculations, and burndown charts that provide unprecedented insight into the development process while somehow failing to predict when the software will actually be finished.
Jira and similar tools excel at generating detailed analytics about development team performance, producing colorful charts and graphs that demonstrate conclusively that work is being tracked with remarkable precision. These metrics provide stakeholders with the comforting illusion of predictability and control, even as the actual software delivery dates remain as mysterious as they were in the pre-tool era.
The Empire State Building’s construction team operated without velocity metrics, burndown charts, or cumulative flow diagrams. They measured progress by looking up and counting floors, a measurement approach so primitive it actually corresponded to the thing being measured. This direct relationship between measurement and reality enabled them to maintain perfect situational awareness throughout the project, while modern software teams can generate detailed reports about their development velocity while remaining fundamentally uncertain about when their software will be ready for users.
The Communication Revolution That Wasn’t
Modern project management tools promise to revolutionize team communication by providing centralized platforms for information sharing, task coordination, and progress tracking. Yet somehow, teams using these sophisticated communication platforms seem to require more meetings, more documentation, and more coordination overhead than the Empire State Building’s construction crews, who relied on the apparently primitive communication technologies of face-to-face conversation and shared physical presence.
The Empire State Building’s workers communicated primarily through direct interaction with the work itself. When a steelworker needed to coordinate with an electrician, they met at the actual location where their work intersected and resolved any conflicts through direct observation and immediate problem-solving. This approach eliminated the need for detailed documentation, status updates, and coordination meetings because the work itself served as the primary communication medium.
Contemporary software development has replaced this direct relationship between workers and work with an elaborate system of digital intermediaries. Developers communicate about code through ticket systems rather than examining the code together. Project managers track progress through dashboard metrics rather than observing the actual work being performed. Stakeholders receive status updates through report generation rather than direct engagement with the software being developed.
The Simplicity Advantage
The Empire State Building’s success stemmed partly from the radical simplicity of its project management approach. The team had a clear objective (build a very tall building), a defined timeline (as quickly as possible), and a straightforward measurement system (count the floors). This simplicity enabled them to focus their cognitive resources on solving construction problems rather than managing the complexity of their project management system.
Modern software development has embraced the opposite philosophy, creating project management systems that rival the complexity of the software being developed. Teams must master multiple tools, participate in numerous ceremonies, and maintain various digital artifacts before they can begin addressing the actual software development challenges. This complexity tax consumes cognitive resources that could otherwise be applied to creative problem-solving and technical innovation.
The Empire State Building’s project team operated under the assumption that project management should be invisible to the people doing the work. Modern software development has inverted this relationship, making project management highly visible and requiring active participation from everyone involved in the development process. The result is a system where managing the work often requires more effort than doing the work.
What’s your experience with project management tools in software development? Do you think we’ve overcomplicated the coordination of creative work, or are modern software projects genuinely more complex than building skyscrapers? Share your thoughts on whether the Empire State Building’s approach could work for contemporary software development, or if we’re doomed to eternal servitude to our digital project management overlords.
Support Analog Productivity Research
If this investigation into the pre-digital productivity miracle that was the Empire State Building made you question whether your daily standup is actually standing in the way of getting things done, consider supporting TechOnion with a donation of any amount. Unlike Jira, we promise your contribution will directly result in more satirical content rather than generating a ticket to create a story about potentially developing content in a future sprint. We're old-fashioned that way—we believe in the radical concept of doing work rather than just tracking it with unprecedented precision.
