TL; DR:
A missed date is not a PIP
Ownership means finding the next move
Manager accountability covers people and outcomes
No livestream... I am on vacation!
When A Developer Misses The Deadline, Who Owns It?
A question came up in the comments about what happens when an engineer does not deliver a project on time.
Does the developer get put on a performance improvement plan? If the manager cannot get the developer back on track, does the manager get put on one too?
It is a fair question, but it starts from a framing that I think is too simple. A project slipping does not automatically mean somebody failed at their job. Real projects have dependencies, changing constraints, technical surprises, and decisions that turn out differently than expected.
The more useful question is this: When the plan stops working, who takes ownership of figuring out what happens next?
You can check out my full thoughts on this in the video below:
A Missed Milestone Is Not An Automatic PIP
Let’s start with the most important distinction.
A performance improvement plan is not supposed to be the automatic consequence of one missed milestone. A project can slip for all kinds of reasons:
Another team misses a dependency
An external vendor falls behind
The original technical approach does not work
The scope was larger than anyone understood
A higher-priority incident interrupts the plan
The date was unrealistic from the beginning
None of those automatically means the engineer assigned to the project is performing poorly.
There is a difference between the outcome being off track and the person refusing or failing to engage with the problem. That distinction matters. I have written about when a struggling developer should be raised with their manager, and the same principle applies here: early communication creates room for coaching and correction. Silence removes options.
If you miss a date because a dependency moved, that is one problem. If you knew the dependency moved, said nothing, explored no alternatives, and let everyone discover the delay at the deadline, that is a different problem.
Ownership Starts When The Plan Breaks
When I talk about accountability, I am not saying that you must personally control every variable. You cannot.
What you can control is how you respond.
If the project is slipping, ownership means communicating that clearly. It means looking for alternatives instead of sitting back and hoping the problem fixes itself.
Maybe the date can move. Maybe the scope can shrink. Maybe there is a temporary implementation that meets the immediate need. Maybe your team can help the dependency team finish its work. Maybe you need to abandon the original design and choose something that is available now.
Actionable Tip: When you raise a delivery risk, bring the clearest options you have.
What changed?
What does it affect?
What can still be delivered?
What tradeoffs could protect the date?
Who needs to make the decision?
You do not need to have every answer before speaking up. But “the project is late” is much less useful than “the project is at risk, here is why, and here are the three paths I see.”
This is where radical accountability differs from a blame culture. Accountability is about improving the situation. Blame is about finding the person who should absorb the discomfort.
Those are not the same thing.
Managers Own More Than Individual Performance
As an engineering manager, one of the most important parts of my job is helping people do their best work and grow in their careers.
But that is not my entire job.
I am also responsible for the charters of my teams. I currently have three sub-teams working in different areas of a routing plane for Microsoft 365. Those teams have different focus areas, including firewall technology, but they contribute to a larger mission.
If everyone is happy, growing, and producing excellent work that has nothing to do with our charter, I am still failing in my role.
On the other hand, if we deliver everything by grinding people down, ignoring their careers, and treating them like interchangeable output machines, I am also failing.
The job requires both. I need to support the people and help the organization get the outcomes those teams exist to produce. That balance is part of what is expected from an engineering manager.
So when a project slips, I cannot point at the engineer and say, “That was their project.” I might not be the person writing the code or coordinating every dependency, but I am accountable for whether the team has the clarity, support, coaching, and escalation paths needed to move forward.
Accountability Bubbles Up The Organization
This does not stop at the engineering manager.
If I repeatedly ignore my team’s charter, miss important outcomes, or fail to coach people who need support, my manager should notice. If that continues for months and nobody addresses it, accountability moves another level up.
Every layer has expectations of the layer below it.
That does not mean every missed delivery triggers a chain of performance plans. It means leaders should be able to explain what they own, how they know whether it is healthy, and what they are doing when it is not.
This is why measuring manager effectiveness is so difficult. You cannot reduce the role to one number. Technical direction, delivery, hiring, coaching, team health, and stakeholder trust all matter.
A manager might be strong at supporting people but weak at connecting their work to the team’s charter. Another might drive delivery while leaving a trail of burned-out engineers. Neither extreme is what I would call effective management.
Coaching Is Part Of The Manager’s Deliverable
The original question also called out hiring and coaching. Yes, managers should be accountable for both.
If I repeatedly make poor hiring decisions, someone should ask whether I need help improving how I assess candidates. If an employee needs performance support and I neglect them, that is not the employee’s failure alone. Coaching and mentoring are part of my job.
That does not mean every unsuccessful performance plan proves the manager failed. Sometimes a manager can provide clear expectations, frequent feedback, practical support, and reasonable opportunities to improve, and the employee still does not meet the role’s requirements.
The accountability is in doing the work properly.
Actionable Tip: If you manage people, do not wait for a formal process before providing useful feedback.
Use regular conversations to make expectations visible. Talk about what is going well, what needs to change, and what support would help. Effective one-on-ones should evolve around the person and the situation, not become a calendar ritual where neither person says anything meaningful.
If a formal performance process becomes necessary, it should not be the first time the employee hears that there is a problem.
Ask What Each Person Did Next
When something goes wrong, I would avoid jumping immediately to, “Who gets put on a PIP?”
Instead, ask:
When did the risk become visible?
Who communicated it?
What alternatives were explored?
What support did the engineer request?
What coaching did the manager provide?
What decisions did stakeholders make?
Did this happen once, or is it a repeated pattern?
Those questions give you a much better picture of accountability than the missed date by itself.
Projects will slip. Dependencies will fail. Estimates will be wrong. That is software engineering in the real world.
Ownership is not pretending you can prevent every problem. Ownership is refusing to become passive when the problem appears.
Join me and other software engineers in the private Discord community!
Remember to check out my courses, including this awesome discounted bundle for C# developers:
As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.
Nick “Dev Leader” Cosentino
social@devleader.ca
Socials:
– Blog
– Dev Leader YouTube
– Follow on LinkedIn
– Dev Leader Instagram
P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!