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.
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.
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.
Beyond overpromising, the PM software model also requires programs to do what Taylor did, but with ongoing returns. The modern tech business model is built around expected recurring revenue, so these programs must use tech sales teams and software-as-a-service models to lock in ongoing customers and keep predictable money coming in. The companies may promise an answer to workflow problems, but they’re selling a service.
Wrike was founded in 2006, Asana in 2008, Trello in 2011, and Monday.com and Airtable in 2012. In the marketing arms race, each has filled the web with its own content sites (Asana has its own fake newspaper), paid fake reviews, promoted Quora answers, and claims that only they have the right software to organize your entire workforce. To even remotely fulfill this promise, software must be useful to many sizes and styles and types of workforces.
Wrike can do Gantt charts or a little spreadsheet thing. Asana can do road maps, waterfall charts, and kanban boards. But under the hood, what are these programs actually doing? In a video game engine, a world is modeled—gravity pulls stuff to the ground, projectiles behave a certain way, your character can hold so many items before they have to drop one. PM software promises robust systems for solving complex problems, but its solutions are usually a superficial UI dropped atop relational (linked) databases. These programs often don’t “work” for teams because they are either too complicated for simple tasks or not robust enough for complex ones, and because relational databases are not a silver bullet for the werewolf of workplace frustrations.
Because the goal of software-as-a-service providers is to sell and retain subscriptions, these companies have to continually add individual features to address any use case that pops up. But when your software is built atop database thinking, new features often just add layers of complication. Adding relational database thinking to a task like “I need to retouch a photo of a dog toy” creates unnecessary complications unless the software is truly user-friendly and mimics software users are familiar with.
For a long time, many of these programs (Asana, as an example) didn’t have an undo button. A competent—but not super tech-savvy—retoucher could go to the “card” in Asana and accidentally delete the task or its history, unwittingly screwing everything up.
It’s a problem when a general user has the universal ability to add, delete, and remove tasks, and it’s a choice someone at Asana made (or didn’t make). Of course you shouldn’t delete files at your job, but the software built on database entries makes it difficult for someone whose brain is trained on modern user experiences (UX) to adjust.
Programs like PM software built around programmer thinking reveal the massive gap between how computers function and a layperson’s understanding of how they work. In the mid-90s, you might reasonably expect someone with a PC to understand file trees or databases because the UX hadn’t advanced to the seamless level seen in today’s phones and apps. Gmail is so good now that a Zoomer entering the workforce might not even be able to think in terms of file trees or relational databases, and they probably can’t troubleshoot that weird little hitch in their PM software. If we look at adding a recycle bin or undo button to what is still, at its core, a database, we see how the gap between user expertise and developer expertise is growing as, say, Gmail UX continues to expertly obscure the actual computer stuff happening on a computer.
The undo button eventually arrived, but it came with a 20-second window, à la Gmail. Not fast enough? Too bad. It’s likely that this feature is simply storing your actions in local memory, laying this atop the interface such that the time between your actions and the program’s server receiving them is the time you have to undo. From the server’s perspective, you aren’t undoing, but merely not-doing.
The reason there are so many of these companies and yet no single killer app is that it has not been difficult to raise capital and build new software on top of a database. Jira puts a Java-based web app between you, the user, and a database. And the way you access and manipulate the database is laid out like an actual, reliable system of workflow management, the aforementioned flow charts and kanban boards. But most of us don’t know how to navigate databases. If something goes wrong, we don’t suddenly start thinking like programmers.
We also aren’t all managers and don’t all think in decision trees. The MBA-brained idea that management is a skill that transcends individual disciplines is part of PM software’s pitch—the people selling these services contend that if their software works for their developers, it must be good for everyone. Consistently using the product they build—also called dogfooding—is a point of pride for companies like Asana, but to this reviewer, it is a less ringing endorsement than they might imagine.
Information work increasingly asks employees to handle more complexity—but we should not have to self-manage our own productivity in imperfect systems laid atop programmer thinking to simply do our work.
Because there is no one way to organize projects and workloads, no software can be everything for modern workers. You may find yourself really loving one of these programs—and that’s great! But the utility of software like Jira lies with actual programmers. Smaller, more job-specific software, like Clio for lawyers, is more likely to address the problems of a specific type of work than one that forces workers to claw through SEO-optimized listicles to find a set of features that can be bent to work for their team.
A huge part of your job today may be simply resolving and reconfiguring the natural entropy in your office, but poorly communicated deadlines will remain so whether they’re written on an index card, sent in an email, or appended to a “task” in Asana. If you put something on a digital kanban board without enough information, it is no more useful than it was before you created the task. Workforce software is offloading the job of managing projects to countless mini-projects, each only as useful as the skill and utility of the individual user. And we can’t expect each user to be both a maker and a self-manager, especially with the imperfect tools on the market. When we line up the Trellos, Asanas, Wrikes, Airtables, and endless clones of the same inherent project-management misses, their differences matter less than their end results—to paraphrase Anna Karenina’s line about families, each project-management app promises the same happiness, but each creates unhappy users in its own way.