As a developer, I have a confession to make: I used to think project managers were overhead.
You know the type of thinking. "Why do we need someone to organise meetings about the work when we could just... do the work?" It's a common sentiment in development circles, whispered in Slack DMs and muttered over mass-produced coffee.
Then I worked on a project without one.
What followed was a masterclass in chaos, contradiction and the slow erosion of my sanity. It also taught me something important about a concept we throw around a lot but rarely appreciate until it's gone: the single source of truth.
What Is a Single Source of Truth, Anyway?
In its simplest form, a single source of truth (SSoT) is one authoritative place where the current, correct information lives. For a development project, this could be a project board, a requirements document, a wiki or even a well-maintained README.
The key word is "one".
Not the Slack thread from Tuesday. Not the email chain with the client. Not the verbal instruction someone gave you while you were trying to fix a production bug. One place. One truth.
When this exists and is maintained, development becomes significantly smoother. You know where to look. You know what's expected. You can get on with the actual work.
When it doesn't exist, you get what I like to call "instruction roulette".
The Chaos of Conflicting Instructions
Let me paint you a picture.
You're a developer on a project to build an e-commerce checkout flow. On Monday, your team lead tells you that the checkout should support guest users only, no account creation. Simple enough. You build it.
On Wednesday, a message appears in the project Slack channel. The client has mentioned to the sales team that they'd really like account creation to be part of the flow. The sales team has passed this on to your team lead's manager, who has pinged the channel asking if this is "in scope".
Nobody replies with a definitive answer.
On Thursday, you're in a call and the client casually asks how the account creation feature is coming along. Your team lead, caught off guard, says it's "in progress".
You now have two conflicting instructions. Guest only. Account creation. Both apparently valid. Both from people with authority. Which one do you build?
If you're lucky, you ask and get a clear answer. If you're unlucky, you pick one, build it, and discover in the review that you picked wrong. Now you're rebuilding, the timeline has slipped, and everyone is frustrated.
This scenario is not rare. It is, in fact, the default state of projects without deliberate information management.
What a Project Manager Actually Does
Here's the thing I didn't fully appreciate until I lived without it: a good PM spends a significant amount of their time preventing the scenario above from ever reaching you.
They are in the calls, the email threads, the Slack channels and the awkward conversations with stakeholders. They hear the client say "it would be nice to have account creation" and they do something crucial: they clarify, document and communicate.
They ask: "Is this a requirement or a nice-to-have?"
They update the spec or the board or the requirements doc.
They tell you: "Heads up, client mentioned account creation. I've confirmed it's out of scope for this phase. Continue with guest checkout."
But it doesn't stop there.
A good PM also considers the ripple effects. When a new feature or change request comes in, they don't just document it and move on. They actively think through what this means for everything already planned.
"If we're adding account creation, what happens to the guest checkout work that's already scoped? Does the payment flow need to change? What about the tickets we've already estimated for next sprint?"
This is impact analysis, and it happens quietly in the background.
Without it, you end up with a backlog full of orphaned tickets. Work that was planned, estimated, maybe even partially built, but is now irrelevant because a later decision invalidated it. That's time wasted on planning, time wasted in refinement sessions, and potentially time wasted in development, all because nobody asked "what does this change affect?".
A PM catches this. They flag that the new requirement conflicts with or supersedes existing plans. They update or remove the now-redundant tickets. They adjust timelines before anyone starts building something that will never ship.
It's also, frankly, a thankless task.
When a PM does this well, nothing bad happens. The project runs smoothly. Developers build the right thing. Deadlines are met. And because nothing went wrong, it's easy to assume nothing was being prevented in the first place.
The PM's success is invisible. Their failure is extremely visible.
The Question You Need to Ask Yourself
So what happens when you don't have a dedicated PM? Perhaps you're on a small team, or working as a freelancer, or in a startup where everyone wears multiple hats.
The work of maintaining a single source of truth doesn't disappear. It just falls to everyone else.
This means you, the developer, need to adopt a PM mindset in one specific way. Every time you receive an instruction, a request or a piece of feedback, you need to ask yourself one question:
"Have I already been given a different instruction for the same thing?"
This sounds obvious. It is not.
When you're deep in code, when you're juggling multiple tasks, when instructions come from Slack, email, calls, comments on tickets and passing conversations, it is remarkably easy to simply act on the latest input without checking whether it contradicts something earlier.
The PM does this reconciliation automatically. Without a PM, you must do it consciously.
Practical Ways to Maintain Your Own Source of Truth
If you find yourself in a PM-less environment (or simply want to be more resilient regardless), here are some habits that help.
Pick one place and defend it ruthlessly. Whether it's Jira, Notion, a GitHub project board or a shared document, decide where the truth lives. When someone gives you an instruction elsewhere, your first action should be to add it to that place. If it conflicts with something already there, raise it immediately.
Repeat instructions back in writing. When you receive a verbal instruction or a vague message, respond with a summary. "Just to confirm, we're going with guest checkout only, no account creation for this phase. I'll update the ticket." This creates a paper trail and gives the other person a chance to correct you before you've built the wrong thing.
Timestamp your understanding. Requirements change. That's fine. What causes problems is when you're working from an outdated understanding. When you document something, note when it was confirmed and by whom. "Guest checkout only (confirmed by Sarah, 12th Jan)" makes it much easier to spot when newer information supersedes it.
Ask the awkward question early. If you spot a potential conflict, raise it before you start building. Yes, it might feel like you're being difficult. Yes, it might slow things down in the short term. But it is always faster than rebuilding.
Create a "decisions log". For projects with lots of moving parts, a simple running list of key decisions can be invaluable. Date, decision, who made it. When someone asks "why did we do it this way?", you have the answer. When someone tries to change direction without realising it contradicts an earlier decision, you can surface that.
A Note of Appreciation
I started this post with a confession, so let me end with an appreciation.
To the project managers who sit in the meetings, who send the follow-up emails, who update the tickets, who ask the clarifying questions, who absorb the chaos so the rest of us can focus: thank you.
Your work is often invisible precisely because you're doing it well.
And to my fellow developers: the next time you're tempted to see the PM as overhead, consider what your day would look like if every piece of information came to you unfiltered, unreconciled and potentially contradictory.
The single source of truth doesn't maintain itself. Someone has to do that work. If you're lucky, you have a PM who handles it. If you don't, that someone is you.
Either way, the question remains the same: "Have I already been given a different instruction for the same thing?"
Ask it often. Your future self will thank you.