Your Project Manager Is a Paperclip Maximizer

A project manager’s job is to turn available resources into a completed project. Give a determined PM another developer, another week, or another slice of someone’s attention, and they can usually find a way to put it to work.

That is what makes the paperclip scenario such an unexpectedly good description of project management. Both the fictional AI and the PM have been given an objective. Both can become remarkably effective at organizing everything within reach around it.

The uncomfortable question is how much of the surrounding world that objective is allowed to consume.

First, the paperclips

In his 2003 paper on advanced artificial intelligence, philosopher Nick Bostrom described a hypothetical superintelligence devoted to making paperclips. Pursued without the right constraints, that goal could lead it to transform Earth and more of space into paperclip-manufacturing facilities.

The machine does not need to hate humanity. It needs an objective that leaves out the things humanity wanted preserved. More materials, more energy, and more production capacity all become useful because they help it make more paperclips.

This is a thought experiment about possible superintelligence, not a prediction about your chatbot. But its underlying logic has a familiar business shape: give a capable operator a goal, access to resources, and a strong reason to finish, and those resources start acquiring a very specific purpose.

Your project manager would like to know whether that purpose can include the developer you just hired.

The locusts have a deadline

A colleague once put the comparison more bluntly: “PMs are like locusts.”

The image is memorable because you can practically see the calendar being eaten. A free afternoon becomes a working session. An available engineer becomes help with a dependency. A little remaining budget becomes another way to reduce delivery risk.

Read that as affectionate professional shorthand. A capable PM is expected to find the people, time, information, and decisions needed to get a project over the line. Letting an important project stall while useful capacity sits available would hardly be a triumph of restraint.

The Project Management Institute identifies scope, deliverables, risk, and communication as key aspects of the discipline. Within that work, resourcefulness is a strength. A PM who finds a legitimate way around a blocker is doing something valuable.

The paperclip comparison is about the direction of that effort. The PM has been charged with getting this project delivered. Another person’s spare hour can look like progress waiting to happen.

The locust does not see a field. It sees lunch. The project sees your apparently empty Thursday.

Every request can make sense on its own

Consider an illustrative software project approaching launch. Testing has found a difficult defect. The PM asks for another engineer. Sensible. That engineer needs help from the architect. Also sensible. The architect needs a decision from the operations team, which needs a meeting with the vendor.

Nobody has proposed anything ridiculous. Each request has a credible relationship to the launch. Each additional resource might improve the chance of delivering it.

Meanwhile, the engineer was meant to help another team, the architect was investigating a recurring production problem, and operations had planned maintenance work. The launch gains momentum by drawing on capacity that already had other possible uses.

The PM can be acting responsibly within the project while the organization still faces a difficult allocation decision. The project’s need is real. So are the needs outside it.

That is the useful twist in the analogy: you do not need a foolish objective to consume too much. A worthwhile objective can do it, too, when every additional resource makes achieving it a little easier.

The project is one objective among many

A PM should understand cost, negotiate tradeoffs, and respect agreed limits. The comparison does not imply that PMs are mindless, wasteful, or incapable of judgment. It describes the pressure built into a role whose attention is concentrated on a particular delivery.

Leadership has a wider problem. It must decide how much capacity that delivery deserves relative to customer support, maintenance, other projects, and the health of the people doing the work.

If five PMs each make a convincing case for the same engineer, the engineer does not become five engineers. A sufficiently colorful spreadsheet will not change this.

Someone with authority across those commitments has to choose. Asking each PM to advocate for their project and then treating the resulting demand as a character flaw would be a strange management strategy.

The practical question is whether resource allocation reflects deliberate priorities or simply which project keeps asking most persistently.

AI makes the same dynamic easier to see

Now give an AI assistant a useful but expansive instruction: improve customer onboarding. In a hypothetical workflow, it could identify changes to the signup form, email sequence, reporting, integrations, and internal support process.

Each suggestion could help. Each also creates a reason to use another tool, request more access, or keep working. As with the PM’s resource requests, the individual steps can sound completely reasonable.

The resemblance is behavioral, not a claim that a human professional and an AI have the same motives or understanding. Both can organize their work around the assigned objective so effectively that the cost to everything outside it becomes easy to overlook.

Better execution can increase that pressure. When you can complete more work, more work starts looking achievable. Opportunity expands to meet capability, and suddenly a request to improve a form has acquired an architecture diagram.

The paperclips have discovered a roadmap.

Give the objective a resource boundary

The answer is to make the allocation explicit. For a project, specify the outcome, the capacity committed to it, and the decisions that require somebody with a wider view. Name what must remain available for other work. Define what counts as finished.

Those boundaries can change. A critical defect may justify moving an engineer from another project. The important part is making that choice knowingly, with the displaced work and its consequences visible.

For AI, the same discipline needs technical enforcement. Limit access to the tools and data the task requires. Set spending and execution limits. Require appropriate review before consequential actions. Verify the result and return control when the agreed job is complete.

A prompt asking the system to be sensible is a weak substitute for those controls. These are practical safeguards for bounded automation, not a claim to have solved the broader problem of aligning superintelligence.

The principle applies whether you are commissioning custom software or assessing the economics of automation: the value of an outcome has to be considered alongside the resources required to produce it.

A determined PM is supposed to pursue delivery. A useful AI assistant is supposed to pursue its assignment. Giving either one a clear mandate means being equally clear about what has actually been committed to that mandate.

The next time a PM spots unused capacity and asks for it, appreciate the instinct. They have found another way to move the work forward. Then make the allocation decision at the level where the competing needs can be judged.

The locusts have a deadline. Someone still has to decide how much of the field belongs to lunch.