About a year ago at Gatewise we were thinking through the R&D structure, and one of the open questions was whether we needed a separate project manager role at all, or whether a product manager would cover what we actually needed, and after some back and forth we decided not to install the PM role. A few months later Harvard Business School published a study of more than 50,000 developers using GitHub Copilot which found that the share of project management work in those engineers' days had dropped by 10 percent while their coding share had grown by 5 percent. The number was small and the framing was different from ours, but the direction was the same direction we had already chosen, and seeing it in a Harvard study made me want to write down what we learned from skipping the role.

What the role actually was

A classical project manager at a small tech company, doing the job on a normal Tuesday afternoon, is actually doing two different jobs at once that happen to share a single title. The first job is keeping the team's internal rhythm, running the sprint, chasing tickets, refining the backlog, writing status notes for stakeholders who would not read them, organizing retros, and making sure the team finishes what it said it would finish, while the second job is something quite different and much harder, which is making sure the right thing gets shipped at the right moment for a market that does not always behave, coordinating with sales people who want a feature yesterday, with field technicians who need a firmware version six weeks before the SaaS rollout, with procurement at a parent company like Allegion that has its own timelines, and with engineering decisions that ripple through all of the above. One requires operational discipline, the kind of grinding consistency that good ops people have, and the other requires product judgment shaped by years of watching real customers do things you did not expect. In many tech companies these two get glued together because there is one head count called PM, and one career ladder, and one Jira board, and a single person is expected to switch between operational mode and judgment mode ten times a day, which they do badly because nobody can do both well at the same time.

What the agents took

The first job, the internal rhythm one, turned out to be the part that AI agents could absorb almost completely once we built the right scaffolding around it. We use a method we call AI spec-driven development, which sits on top of a skill I wrote for our team and which Claude Code understands directly. The agent receives a high-level intent from the product side, breaks it into epics and tickets and acceptance criteria, writes the implementation plan, generates the code, runs the tests, and updates the documentation along the way. The documentation is not written by a human later as a clean-up step, the documentation is written by the agent as the source of truth that the next iteration of the agent will work from. We have been running this way for about a year now and the part that surprised me the most is how stable the loop is, the same agent authors the spec and the implementation plan, then orchestrates the execution itself, sometimes by spawning sub-agents for parts of the work and sometimes by calling its own tools directly, and pulling in a human only when the task needs real judgment, while our team reviews at the joints rather than inside every task.

Operational work that remains for humans includes sprint formation, dependency calls between teams, and scope cuts when something turns out to be harder than the agent estimated. I am Head of Software Engineering at Gatewise, and most weeks I spend my Monday morning with the team walking through what is in flight, where the agents got stuck, and what we should re-prompt or re-scope. We removed the layer that used to do translation between me, the engineers, and the codebase, because once the agents handle the paperwork and the engineers handle the judgment, there is nothing left in the middle to translate.

The PO we kept does a different job

The second job, the cross-domain orchestration one, we kept. We just stopped calling that person a project manager and stopped describing the role as managing the engineering team. The role we kept is Product Owner, and the shape of our Product Owner is different from what we started with. Our PO does not sit above the engineering team telling people what to build, our PO sits in the field, in the space between engineering and sales and field technicians and our parent company Allegion and the customers themselves. They are what we have started calling a quarterback inside the company, the person who knows where the project is in the broader system at any given moment, who coordinates the launch timeline with the sales team, who makes sure the technicians at the residential complexes have the right firmware and training before the SaaS update lands, and who owns the go-to-market roadmap end to end. They are not managing the team, they are routing the project through the world, and that is the shape we needed our PO to take from the start.

Earlier this year I read a Harvard Business Review piece by Suraj Srinivasan from HBS and Vivienne Wei from Salesforce called "To Thrive in the AI Era, Companies Need Agent Managers", and it introduced a role they call the agent manager, a person responsible for orchestrating how AI agents and human teams operate alongside each other. Reading it I had the same feeling I sometimes get when academic research catches up to something my team has already been doing for a while. They had named the role from the top down, from interviews with Salesforce and other large organizations, and we had drifted into a near-identical shape from the bottom up because the alternative was hiring someone for a job that was already gone.

What this means if you are running R&D

The lesson I would draw is not that AI removes roles, although that headline travels well. AI actually removes the cheap glue that held together roles which were always two roles wearing one badge. Historically the classical PM was an administrator and a quarterback at the same time, and as long as both jobs were small and the company was small, one human could do both at once. Once the administrative job becomes near-free because agents handle it, the math of bundling the two jobs falls apart, and you end up with a smaller number of humans doing the more valuable half of the original work more often, and each of them covers more ground than the bundled PM ever could. We did not save head count by skipping the PM role, we just redirected the head count to a place that mattered more for the business. Instead of one PM splitting attention between operations and judgment, we have a PO who can spend a full week with the partner company on a launch, while the agents and the engineers handle everything inside the team without anyone in the middle.

For anyone running an R&D team right now and considering whether to install a PM role, the more useful question is which of the two jobs you are actually trying to buy. Administrative work is mostly absorbed by agents and engineers already, both in our experience and in the Harvard data, and you can probably skip hiring for it. Quarterback work matters more than it ever did, and framing that person as a project manager will under-describe everything you actually want from them. The hard part of this setup, a year in, is not whether the math works, the hard part is finding the right person to play the quarterback role.