When I worked as a copywriter at a dog-toy-slash-tech company, we used Airtable and Basecamp to organize our workflows. At my next job, the marketers made us learn Asana (“same as Airtable but much better”), but the product team pushed their work and sprints through Jira. I was laid off before I had to learn Jira, and at my next gig they swore by Airtable, which, phew, I already knew. But efficiencies were still being lost, apparently, and Airtable took the blame. As I was leaving that job, I heard someone mention that a new program, Trello, was going to replace Airtable and “change everything” for us. I came back as a contractor a few years later, and everything had not changed. The company had moved on from Trello and was now in the thrall of something called Monday.com. It, too, promised big changes.
If you work as an “individual contributor”—engineer, copywriter, designer, data analyst, marketer—in the modern white-collar workforce, you’ve probably encountered one of these project-management software (PM software) enterprises. Your onboarding will include an invitation to collaborate from the likes of Smartsheet, Notion, Udemy, ClickUp, Projectworks, Wrike, and Height. The list seems endless and yet is somehow still growing. More than a hundred proprietary apps and planners are currently vying for companies’ business, all promising increased productivity, seamless workflow, and unmatched agility. And if, like me, you’ve ping-ponged between a couple of jobs and project teams over a few years, you’ve had to come to terms with the fact that misunderstandings and confusion are natural in any large workforce. But in an increasingly digital, increasingly remote age of work, you might still imagine that a “killer app” really would win. And yet none of these PM software services make work work. The key to these deficiencies lies in the history of workplace efficiency itself—starting with the original business consultants.
Solving for Efficiency
Before the second Industrial Revolution, there was practically no such thing as productivity. (The word itself basically didn’t exist before 1900.) As factories became more complex and wage-laborers proliferated, the goal of capital became ensuring the efficiency of its labor. If connecting your workplace annoyance with too many Trello notifications to the plight of a machinist building lathes in the 1900s gives you vertigo, you aren’t alone. But the idea of making sure you’re working efficiently is as old as the idea of being employed.
And so the 1900s ushered in what we know as project management. According to Frederic Taylor’s The Principles of Scientific Management, the goal of managing workers “should be to secure the maximum prosperity for the employer, coupled with the maximum prosperity for each employee.” At the same time that Taylor, a mechanical engineer, rose from the factory floor to become one of America’s first workplace narcs (or consultants), another engineer, Henry Gantt, popularized and codified the basics of the Gantt chart, a simple bar chart that turns a project’s schedule into a set of lines on an x- and y-axis, with time moving from left to right. Also called the “waterfall” method, Gantt charts create a visual metaphor of tasks and their dependencies and contingencies so you can see each individual task in terms of when it should start and when it must be completed, relative to the overall project and the tasks coming before it.
Are you a graphic designer waiting for photos and copy to come in before you can design a banner ad? In many of our modern PM software apps, you can see those prerequisites, as on modern Gantt charts offered by Monday.com, Wrike, Microsoft Project, and Click Up. Asana also has Gantt templates.
Taylor and Gantt were figuring out how to manage the work of a factory machinist, whose job, like Lucy’s in the chocolate factory, typically involved one repeatable task. But the growth of the information worker means more generalists, consultants, analysts, and managers—and more hierarchy. On a construction project, for example, as long as the rebar is installed, the concrete team can pour a foundation. Similarly, the factory worker does not have to see the Gantt chart to fabricate their part of the widget, they only need to know what to do. They don’t have to participate in the creation of the chart. They don’t have to interact with the chart. In the formidable Hoover Dam project (its construction was organized via Gantt chart), the workers pouring concrete did not have to self-manage that task while also checking in with their Gantt charts. In the time before information work, task workers (individual contributors) did not have to self-govern; they were the governed.
Information work, on the other hand, is more easily managed using the methods Gantt developed. In an information workforce, there are infinite vectors of feedback, debate, stakeholder approval, and revision, not to mention endless points of contact. (If you feel your place of business is swollen with managers, you’re not alone.) Software that mimics a bygone way of setting up project dominoes is the source of our workplace frustration and the beginning of do-it-all solutions that end up simply making more work.
Critical Paths to Road Maps to Endless Options
Did you know that the Manhattan Project is also part of the glorious history of project management? Increasingly complex problems need increasingly elegant solutions, and you can’t go from an idea to an atomic bomb in a few years without efficiently organized parallel paths of work. The observations established by some engineers on the Manhattan Project led to the creation, in the late 1950s, of critical path method, an algorithmic model that creates a mini-map (a bit like a decision tree) of all pieces of a development process or project. Each node and path is given time values, and a computer solves for the fastest (or cheapest) way to get to the end with all necessary tasks accomplished. Combine critical path with the US Navy’s PERT method, a similar system developed simultaneously, and project management has moved into the computer age. Around the same time, the kanban (Japanese for signboard) system was developed at Toyota to wring more efficiency out of lean manufacturing. A manual system of cards and signs, kanban also gained popularity.
By the time software development becomes a more legitimate field to be managed (in the 1980s), we also have Fred Brooks’ “law,” which states that adding manpower to delayed programming projects only further slows them down. The truth behind this idea—that “onboarding” complex tasks is more time-consuming than time-saving—is one of several factors that lead software developers to work in and develop scrums, a more flexible way of communicating during open-ended work projects, like programming. Scrums are possibly more revolutionary than critical path, kanban, or any of their precedents because they present a format that fits the functionality of small teams with shorter-term goals. Scrums help programmers accomplish work quickly and then do the same on the next project.
You may look at a critical path chart and think: Hey, that sounds a lot like a product road map (a somewhat useful-looking combination of the waterfall part of a Gantt chart and the dependent-path layout of a critical path). Or you might consider a kanban board and think: OK, I can get used to this. But notice that Asana is advertising its fluency in kanban, critical path, and scrums, as well as with a newer term: agile. PM software represents itself like Frederic Taylor in the late 1800s, traveling from place to place and assuring factory owners that his system can be applied equally to joinery and industrial laundry. The difference is that Taylor had a one-system-fits-all solution; PM software sells itself a jack of all systems and master of all too.
