It depends on whether your demands are reasonable or not if it's going to work, but:

If there's a persistent lack of communication when it should've been known that a deadline is not going to be met or is at least going to be close, set-up a PIP where you lay down a checklist to follow at the start/end of the day of behaviors you expect regarding communication.

If that doesn't help, then yes, firing is the correct response, not permanent micromanagement.

This is all under the generous assumption that your deadlines are actually very important in the business and plans will have to be shifted if they're not met because of a harsh business reality. Otherwise it's your fault for allowing the cost of deadlines to be incurred in a team where all they will do is hinder morale, add bureaucracy and reduce productivity.

> This is all under the generous assumption that your deadlines are actually very important in the business and plans will have to be shifted if they're not met because of a harsh business reality. Otherwise it's your fault for allowing the cost of deadlines to be incurred in a team where all they will do is hinder morale, add bureaucracy and reduce productivity.

As far as most dev teams are concerned, timelines are less important for the business than they are to each other.

People don't like it when they are constantly waiting on person X to finish their part of the work. (That's a good way to know you've really dropped the ball as manager: the other team members start asking YOU what's going on with the other person.)

PIPs are a waste of time imo. Usually if you're at the PIP stage, you're going to end up firing them anyway. I've only heard a handful of cases where PIPs actually *worked*. The rest of the time they were a waste of everyone's time.

That's why there are usually progressive disciplinary steps. I've been on the receiving end of that in a couple of situations (which I'll admit after the faact, were due to my own issues). It's not pleasant but it was necessary, because I wasn't going to give up trying, but I was in no shape to actually succeed. Better to cut the cord - I wound up in better situations after each occasion, mostly because I wasn't bailing water anymore and had energy to do well.

I worded this badly, but this is the accountability piece.

You say that you want X. X has to be reasonably achievable. You don't tell them how to do X, though.

That introduces another set of problems. You have to do X within Y.

Suddenly you know more of Y than X. So then you turn towards Z and you have to do XY within Z, but Y is more important than X.

It could be that the IC is just very bad at estimating schedules, so much so that they don’t realize they are falling behind. If that’s the case, some training on software estimation and how to set good milestones could pay large dividends.

Another possibility is that the environment is one in which it’s not okay to admit that schedules are slipping, despite the manager’s insistence to the contrary.

There are many more possibilities of course. Does the employee have any insights into why they failed to take the action they promised?

You fire them. What's so difficult about that?

A lack of trust and/or misalignment on goals doesn’t automatically mean the employee is a poor performer. If your first resort is to fire them, there is no reason to believe the same problem won’t happen with the next employee.