For most of fifteen years as a backend developer, it genuinely did not matter whether I spoke.
I don't mean that bitterly. It was the deal, and I liked the deal. Output was code. The code either worked or it didn't, and the feedback came from a test suite rather than a room. On a good week I could go three days barely talking to anyone and be the most productive person on the team.
Last year I built a full project-management platform on my own — about 96,000 lines of Python across 58 modules, 2,900+ tests, three months, under $700 in total spend. I know exactly how that gets done. You hold the whole system in your head, you make a hundred small decisions a day without consulting anyone, and you move.
But as a project manager, almost everything that made me the best at the back office made me bad at the meeting room where people want to listen my thoughts.
The thing nobody tells you
As a developer, the bottleneck is usually how fast can I build this correctly.
As a PM, the bottleneck is how fast can five people agree on what "this" is.
Those are not the same problem, and the second one is not solved by being a faster developer. It's solved by talking — negotiating, running the round-table, chasing the one person who hasn't replied, re-explaining a decision for the fourth time to someone who wasn't in the meeting. I was not good at any of that. I had spent fifteen years optimising for not having to do it.
Here's the version of the problem that finally landed for me:
I can build one system in three months. Can I build five systems, with five teams, at the same time?
That's not five times the same skill. It's a different skill. One is depth. The other is interfaces.
Where it actually broke
Solo, the specification lives in your head. That's not a problem — it's a feature. There's no translation loss, no meeting, no document to keep in sync. You are the single source of truth.
With five teams, the thing that breaks isn't the code. It's the space between the teams. The undefined behaviour is between humans:
- Two people hold different assumptions about scope, and neither knows it until integration
- A decision gets made twice, differently, in two conversations
- Someone waits three weeks for an approval nobody realised they needed
- You find out in month three that "done" meant different things to two stakeholders
Every one of those is the human equivalent of an undocumented API. The call succeeds, the types line up, and the semantics are wrong.
The document I had dismissed
Project management has an artefact for exactly this, and I had spent years assuming it was bureaucracy: the project charter.
Here's the reframe that made it click for me, and it's embarrassingly simple once you see it:
A charter is an interface definition. For humans.
You wouldn't start implementing against a service with no contract. You'd want to know what it's for, what it guarantees, what it refuses, and who owns it. A charter is that, for a project:
| Charter section | What a developer would call it |
|---|---|
| Purpose & justification | What problem this service exists to solve |
| Measurable objectives | Acceptance criteria |
| High-level requirements | The public API surface — and what's explicitly out of scope |
| Milestone schedule | The deadlines that are externally binding, not the internal ones |
| Pre-approved budget | Resource limits |
| PM authority | The permissions model |
| Sponsor authorisation | The owner who accepts breaking changes |
Read it that way and it stops being paperwork. It's the thing you write before implementation because the cost of getting it wrong compounds.
The section that matters most is the one everyone leaves vague
Look at a few real charters and you'll find the authority section says something like:
"The project manager has authority to manage the project and its resources."
Which is the governance equivalent of a permissions doc that says "the user can do user things."
It doesn't say what I can approve. Up to what value. Whether I can commit a contractor, or re-sequence work that moves a milestone, or make the call myself at 9pm when something's blocked. So every decision escalates by default, and five teams sit waiting on me while I sit waiting on a sponsor.
The version that works reads more like a policy file:
"May approve changes up to $X and schedule movement up to N working days where no external milestone is affected; escalates anything above that, or anything touching a regulatory standard, to the sponsor within five working days."
Same section. One is a sentence; the other is executable. If you've ever written an IAM policy, you already know which one survives contact with reality.
And there's a bonus: if the sponsor won't commit to a number, that's information — discovered in week two rather than month three.
What I'd tell myself three years ago
Your instinct to avoid meetings was correct, and useless. The meetings aren't the problem. Meetings that exist because nothing was written down — those are the problem. Writing things down is how you have fewer of them.
Documents aren't bureaucracy; undefined behaviour is. You already believe this about code. The same logic applies to a project. You just can't see it because you've never had the undefined behaviour bite you at human scale.
Depth and breadth are different jobs. Being able to build the thing alone is not evidence you can coordinate five builds. It's barely related. I genuinely thought it would transfer. It did not.
You will talk more than you ever wanted to. No way round this one. But the better the interfaces are defined, the less of the talking is re-explaining decisions nobody recorded.
I'm still much better at the first job than the second. But I stopped treating the second one as a tax on real work, which — looking back — was the actual blocker.
If you want the long version of the charter structure, I wrote it up section by section here: how to write a project charter. It's free and ungated — part of a PM learning centre I maintain alongside the tool.
One question for anyone who made this transition before me: what was the thing you dismissed as bureaucracy and later wished you'd taken seriously?
Top comments (0)