Senior Technology Project ManagerLondon, UK
I run technology delivery for global brands, public sector organisations and government clients — web platforms, mobile and desktop applications, and large-scale digital systems, much of it under regulated compliance frameworks.
The work spans the full lifecycle: discovery, scoping, delivery, release and handover, then staying close enough afterwards to know whether it worked.
Alongside that, I build. The AI tools I make are the ones I use to run my own projects, and building them is how I judge what these systems can and can't currently be trusted with.
Most of what a project manager does in a week can now be automated with AI. Status collation, documentation upkeep, reporting, chasing people for updates — none of it is why anyone took the job, and most of it is now within reach of tools you can build yourself.
What's left is what the job always was. Reading a room. Managing expectations that genuinely conflict. Spotting the risk nobody flagged and the dependency nobody owns. Making the organisation see clearly what's actually happening on a project rather than what the status report says. Deciding under uncertainty, and putting your name to the decision.
But getting there is harder than it sounds, and the reason has almost nothing to do with the models.
The capability curve is moving faster than almost anyone predicted. The absorption curve — what organisations can actually take on — moves at the speed organisations have always moved.
That second speed gets treated as timidity. It usually isn't. Sign-off chains, audit trails, procurement review, training programmes: each exists because something went wrong once and someone decided it shouldn't again. It's accumulated caution, and most of it is load-bearing. The gap between the two curves is where my work happens.
The pattern is familiar by now. Someone builds a prototype, it does something genuinely useful, everyone in the room agrees it's impressive. Then it stops — not because the model failed, but because nobody can answer what comes next. Who approves this. What happens when it's wrong. Which data it's allowed to touch. Who's accountable when it makes a call nobody reviewed. And what happens to the people whose roles were built around the process you've just automated.
Those aren't AI problems. They're delivery problems — the same governance, integration and change questions that have always decided whether technology gets adopted or quietly abandoned. AI makes them harder because the output isn't deterministic. Same question, different answer, no spec to point at. In an environment where every change is signed off and audited, a system that can't reproduce its own reasoning is a governance problem before it's a technical one.
The answer isn't to ask an organisation to trust the output. You can't, and you shouldn't. The answer is to design where the human sits. A lot can be delegated. Anything with real consequences needs someone who reviewed it and owns it. Getting that boundary right — what runs unattended, what gets proposed for review, what never leaves a person's hands — is the actual design work, and it's what separates a tool people depend on from a demo that impressed everyone once.
The other shift is closer to home. I'm not an engineer. Two years ago, if I wanted a tool, I wrote a requirement and waited. Now I build it. PM Hub exists because the distance between describing software and having it collapsed.
That's happening across every function. The roles are blending — one person can be a passable developer, designer and analyst at once. Not expertly, but well enough to ship something real. Which means the scarce skill stops being the ability to produce the artefact and becomes the judgment about which artefact is worth producing at all.
So I'd expect a new kind of role to come out of this, and I think it's already forming: people who understand business processes well enough to know what they're actually for, who can think critically about where they break, and who can now build improvements rather than specify them for someone else and wait. That's the job I've effectively been doing for the past couple of years. There's going to be a lot more of it.
PM Hub is what that looks like in practiceAn AI tool for project delivery. It reads across the systems I use to run projects and turns what's scattered between them into one coherent picture — briefings, status, risk, priorities.
I'm building it because the problem is mine. I run three to five projects at once and the coordination overhead was eating the part of the job that actually requires judgment.
It's in development and in daily use. The parts that are live save me around ten hours a week.
An automated system that monitors financial news and regulatory filings, uses LLMs to assess whether an event is likely to move a price, and executes trades through a brokerage API.
It works. It does what I built it to do, reliably. It also doesn't beat the market, which is why I no longer run it with real money.
I've kept it here because the failure is the useful part. The system was sound; the assumption underneath it wasn't. Building it taught me a great deal about working with messy financial data, about how markets actually behave versus how you'd model them, and about where an LLM's judgment is genuinely useful versus where it just sounds confident.
Senior Technology Project Manager
2022–present
I own delivery across multiple concurrent client accounts, from initial discovery through release and handover. I run discovery with senior client stakeholders — establishing what a business actually needs behind what it asks for — then turn that into specifications the team builds against.
I work with in-house design, engineering and QA alongside external contractors, and manage the vendors and commercial terms that sit around delivery. I own testing and user acceptance through to release, and stay close after launch to see whether the thing worked.
Digital Project Manager
2016–2022
End-to-end delivery of web and platform products for international clients across Western Europe and the US, working with distributed engineering, product and design teams. I was the primary interface between client stakeholders and the people building for them.