> So, what do you do to build up trust? You talk.

What do you do when talking leads to them saying "I understand, next time I'll either get it done faster, or let you know when I realize it's gonna slip" but then what actually happens is that it slips without them giving you any updates again after all? Repeatedly? Talking doesn't build trust when the actions don't match the talk.

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.

I think you're oversimplifying. I bet that what you're saying may work fine in a factory line, but when we're talking creative work such as programming, holding people to account without zooming in deep sometimes is impossible.

If a designer makes an unresponsive site, the manager can just say "hey do a responsive design tutorial". But if the designer gets all kinds of patterns or structures or the company design language just wrong, it's very hard to discuss that without making the designer feel like you're micromanaging them.

Micromanaging is no different than telling someone what to do, at an extreme level.

All of your examples can be handled with good communication. If a designer makes an unresponsive site but the site should be responsive, then the communication failed and the requirements were wrong.

If you're a manager or a leader then, ultimately, you are responsible for the failures you presided over. You can't sit back and observe the chaos.

Sometimes you end up with someone who can’t do the job that they were hired for, or won’t, without constant direction. Sometimes they come into the job this way, sometimes factors outside of your control put them here.

Sometimes you can have a Frank discussion about it, or regular ‘adult’ type discussion, and there is something that can be done that fixes it, and it can be fixed. That is not always the case. Sometimes the person is fundamentally incapable of doing the work (rare), or in a place they can’t care about or don’t want to do it - but won’t or can’t acknowledge it.

Re:accountability - there are many different definitions one can use for what this really means. The clearest I am familiar with is ‘if you can’t or won’t do the job to standard, and there is no special circumstance like a leave that should be applied, you don’t have that job anymore’.

That is easier said than done in many business environments.

I’ve worked in places where someone literally not doing any useful work was going on a year+ of dragging on with the team, constantly changing reasons for why they couldn’t do the job, and killing the teams morale. Literally 4 layers of management involved in HR processes trying to drive this to a useful conclusion, but new buttons being pushed every month by the employee and a highly risk adverse HR/Corp culture meant the situation couldn’t be resolved. All this on top of 6 months of coaching and attempting to help this individual be a productive member of the team.

These environments all require micromanagement of low performers as part of the performance management process - it’s the way things have to be to get the documentation and proof of coaching for CYA.

Your last example sounds like a complete failure of leadership. And the accountability buck stops with them for enabling that situation.

Accountability isn't easier said than done; it exists everywhere, but you choose how to apply it and when and you use your bias to decide how hard to apply the discipline.

If you feel you need to micromanage someone, then you've lost your leadership too.

Easy to say, but pretty useless on the ground. Which leadership is failing? Who holds whom accountable?

If you, as a leader, will get fired for holding someone accountable to the job (and firing them) and stopping a toxic environment from happening on the team, what then? What if the reason for that is some meta PR corporate reason that makes sense for corporate maybe but not for you and your team?

What if your job includes not causing those larger corporate issues and following the rules of the larger org?

It’s a failure of a large organization, and part of that failure is often making sure there is no one to actually hold accountable in a real way. It sucks. It happens.