Accountability is one of those words organizations use constantly without ever defining it.
Someone owns a project. Someone owns a deadline. Someone is responsible for a result. When the result doesn't happen, the conversation turns to accountability.
Before asking whether someone was accountable, I think there's a more basic question: could they actually influence the outcome?
I've seen people held responsible for work that depended on a decision they couldn't make, information they didn't have, another team they couldn't direct, or a system that wasn't working properly. The responsibility was assigned to them. The conditions required to fulfill it weren't.
That's where accountability starts to break down.
There's responsibility on the employee's side, too. If you agree to own something, you own the commitment. You need to understand what you're agreeing to, and when you see that something necessary to deliver it isn't there, you need to say so.
I've learned that one myself. I have a tendency to see something new, decide I can figure it out, and say yes before I've fully understood what that yes requires. Sometimes the instinct is useful. Sometimes it means I've agreed to something without understanding all the variables attached to it.
The organization has a responsibility too: make sure the person accepting the work understands what they're responsible for, and has a reasonable ability to influence the result.
That distinction has mattered throughout my career, because I've seen how differently work moves depending on whether the operating structure is clear.
Early on, I worked with a project manager who'd built an extremely detailed operating spreadsheet. It was Excel. Nothing sophisticated about the technology. What made it work was how the work had been organized. The deliverables were clear. Dependencies were visible. Responsibilities were understood. There were defined points for escalation, and the project manager had the authority to move the work forward.
It worked because the people using it understood how the work was supposed to move.
I've seen the same principle hold with modern work-management platforms. I've also seen those same platforms become elaborate places to store information nobody actually uses.
When I look at an operating system, I ask how much I can learn from it without needing a person to interpret it for me. If I have to ask someone where a project stands, piece together updates from conversations, or wait for a presentation to tell me what's happening, the system isn't doing its job. Not everything can or should be automated. There will always be context that requires judgment. But the basic state of the work shouldn't depend on someone's memory, and I've seen what happens when it does: the operations person becomes the connective tissue. They chase updates, remember conversations, reconcile conflicting information, track dependencies, and explain status to leadership. Over time, that person becomes the place where the organization stores knowledge that should have lived in the system itself. You shouldn't have to find the person who remembers the story to understand what happened.
When that person leaves, the organization loses more than a resource. It loses part of its institutional memory.
That's the beginning of what I think of as a corporate lobotomy: when too much of an organization's knowledge, context, and history lives inside individual people instead of inside the organization itself.
This isn't just an information problem. It affects how work actually gets delivered.
Projects are rarely linear. One team finishes something so another can start. A decision unlocks the next step. A delay in one place creates a problem somewhere else. If a project is going to miss a deadline, the system should surface that before the deadline arrives. That means visibility into dependencies, capacity, and progress, so problems can be seen while there's still time to act. And the person responsible for the work has a responsibility to raise the flag when they know a commitment is at risk.
The system gives you the quantitative picture. The person gives you the context. You need both.
When a project misses, I look at both. The system shows what happened in the work: when something moved, what depended on it, where the schedule changed, what decisions were made. The person explains what the system can't: what they knew, what they were waiting for, what changed, what they understood their responsibility to be.
I've seen people blamed for outcomes they didn't control. I've also seen people fail to deliver work they absolutely owned. Those are different conversations.
If someone has clear direction, understands what they own, has the authority to act, has access to the information and resources they need, and agrees to the commitment, then they're accountable for delivering it. If something changes, they have to raise it. If they repeatedly fail to deliver what they agreed to under reasonable conditions, that becomes a performance issue.
The first two instances should be coaching conversations, documented as opportunities to address the behavior and clarify the expectation. If the same failure happens a third time, there should be a consequence.
The organization doesn't need to teach someone how to be accountable. That belongs to the individual. What the organization needs to do is make sure accountability is attached to something the person can reasonably influence.
Good operating systems make that easier to see, and that's the whole point. You don't manufacture accountability through more meetings, more reporting, more oversight. You build a system that shows the work, shows where it stands, and shows the moment it stops moving. Then accountability isn't something you have to go looking for. It's just visible.
That's controlling the controllables: not pretending everyone can control everything, but making sure the things people can actually influence are never hidden from view, theirs or anyone else's.