Why project management roles are “bullshit jobs” and startups are better off with self-organizing teams.

David Graeber, the famed anthropologist who sadly passed away unexpectedly in September last year, was well known for his anarchist positions which he shared at such different events as an Extinction Rebellion protest in Trafalgar Square as well as a panel discussion with Peter Thiel. Besides his probably most popular book Debt: the First 5000 Years and many others, he also wrote Bullshit Jobs: A Theory in 2018 about meaningless jobs that don’t generate any real value or even do harm. The examples he mentions include roles such as people that write reports which then nobody reads or receptionists at companies that have no visitors.

One of the five main types of bullshit jobs he presents is the taskmaster who manages, or creates extra work for, those who do not need it. In my experience, that pretty precisely describes many project management roles in digital product development teams and those in startups in particular. Startups, more than most other companies, operate in challenging environments and face a lot of pressure from many sides. They need to satisfy their users’ expectations and constantly improve their products and services but also need to satisfy their shareholder’s expectations, reach particular KPIs like active users or market share, often while competitors are fighting hard to conquer that same share of the same market.

Responding to those challenges, what many companies do is establish roles and hierarchies that make sure teams “deliver”. Project management roles would prepare plans and set deadlines and then check in with product teams regularly to make sure they are on track. There are many different names for these roles from the classic “Project Manager” to the “PM” (where it’s often unclear whether the “P” stands for “Project” or “Product” and the answer to that question doesn’t really make a difference in many cases anyway) or the “Product Owner” as it is defined in Scrum.

The problems that all of these roles have in common are twofold. For one, the manager roles are not themselves experts in any of the involved professions like engineering or design. At the same time, the engineers and designers that need to deliver on the project manager’s plan often don’t have much involvement or influence in the planning and prioritization process and do not get to contribute to it early on, resulting in plans that are flawed from the beginning. Countless times have I witnessed designers and engineers executing on tasks that were prepared by their project managers in an effort to “make it easier for the development team” while in reality, those good intentions resulted in decisions that actually made things harder. Bringing in the experts for the respective fields to the planning process early on often would have resulted in easier, faster, and more sustainable ways to reach the same goals.

But the project management roles’ responsibilities and goals focus on timelines and delivery dates, not necessarily on the substance and quality of those deliverables. They often make plans that do not sufficiently consider the perspectives or priorities of all involved specialities. The result of that is a sometimes severe negative effect not only on the quality of the developed products but also on the team’s ability to sustain a reasonably high pace when maintaining and evolving those products. Not letting experts contribute their perspectives early on usually leads to debt in their respective areas of expertise. Probably the most well known kind of such debt is the dreaded “technical debt” which refers to the implied cost of future, additional rework necessary when choosing seemingly easy solutions to move faster instead of better solutions that might take a bit longer to build initially. Technical debt not only makes it harder and harder to evolve a product over time and can in the worst case bring all development to a halt. It also leads to frustration among teams, even causing team members to quit their jobs, as a recent survey shows. That results in fluctuation among the team and a further decline of velocity. And that’s just one kind of debt – other kinds like UX debt or product debt as a lack of features exist as well and are equally problematic.

The second problem project management roles often lead to originates in the fact that they would assume an intermediary role between the various involved groups in a project team such as product experts, engineers and designers. Channeling communication and collaboration between these groups through a project management role is often done in an effort to let these groups focus on their own tasks and making things more efficient. While that point alone is questionable as important information and nuances will get lost in translation as it passes through the project management role, there’s another, even more severe negative effect. An understanding and appreciation of each other’s perspectives and priorities can only develop through direct communication between people. Such communication not happening leads to each group focussing on their area of expertise only and perceiving the needs of other groups, presented to them only indirectly, as disturbances that threaten to take focus away from their own tasks. The different groups in a project team will then try and fight off these external inputs in an effort to maximize their ability to execute on their own agenda.

Many companies are suffering from teams working against each other rather than with each other and statements like “Product Management is pushing too hard for features, we cannot keep up”, “Engineering is blocking everything, they just want to make things nicer for themselves” and similar sentiments are often to be heard in the industry. In many cases, companies would try and resolve these situations by introducing more and stronger project management in an effort to mediate between the involved groups in order to increase velocity. In my experience that almost always is like pouring oil into the fire though and makes things worse rather than better – teams end up in the midst of a vicious cycle before they even realize it.

The effect of the project management role, which originally was supposed to be ensuring deadlines are met and development teams move at a high pace, turns into the opposite, making teams deliver slower rather than faster, at lower quality and with more frustration on all sides. Thus, the roles are “bullshit jobs” in the sense of Graeber’s book as they do not add value but in fact do harm – and eliminating the role altogether would be more beneficial than keeping it.

The alternative to these roles is simply letting development teams truly self-organize. Self-organized teams, when presented with a goal rather than a predefined plan and respective set of tasks, can contribute their expertise and perspective from the beginning and collaboratively come up with the best way to reach the goal. That not only prevents important aspects of the product that are not well understood by the project managers from being neglected and thus negative consequences from accumulating. It also increases every member of the project team’s feeling of ownership for the product which results in a boost of motivation and thus productivity.

Companies understand they need to hire the best minds for the best output. What many do not understand in my experience is they then also need to give the people the freedom to put their minds to work and bring in their experience and expertise to deliver the best product value in the most efficient way rather than just executing someone else’s – often flawed – plan.

If you’re interested to learn more about sustainable product development with self-organized teams, have a look at our playbook.