[fighterpilot]

  > When people don't deliver what you expected, it's because you did a shitty job of communicating it to them.

Why is this necessarily the fault of the manager's communication skills?

Sometimes the person sucks beyond repair and needs to be fired.

If you have a competent person who didn't deliver what you expected, then yes, it's probably the fault of the manager's communication. Not so for the lower-end of that competence spectrum.

It might still be the manager's fault for hiring that person in the first place, but that's separate to it being their fault at not communicating properly.

The shitty job here is not firing that type of person quickly enough, and misdirecting the blame towards your communication skills.

EDIT - edited the first sentence for clarity.

[takeda]

If requirements were provided and person didn't fulfill them, they did a bad job. If requirements were fulfilled, but you aren't happy with the result, then you did a bad job.

[fighterpilot]

> If requirements were fulfilled, but you aren't happy with the result, then your requirements were wrong.

Isn't it possible for a dev to fulfill requirements but still deliver a bad result as measured by subjective (but important) things such as code smells, bloat, crappy algorithmic logic, and so on? Or do you think managers need to spec things out in such strenuous detail that surprises (but also, to an extent, autonomy and ad hoc decision making) aren't possible?

There's also the case of R&D roles where it's hard to spec things out exactly in advance, and you're partly relying on the employee's ingenuity.

[takeda]

You're talking about completely different thing than what OP was talking about. It's about developer having a different vision than you.

You either need to accept that someone sees the problem differently than you and accept their solution, or if it is something important to you, you need to get better at explaining your vision.

Anyway, back to your requirements, as you pointed those requirements are subjective. If those are important things you should still outline what's expected. You don't have to do it for every project, and can be when person is being on-boarded.

[fighterpilot]

Right, in that case I'm in agreement, if the employee didn't deliver what was expected because they didn't understand (or weren't convinced with) the manager's vision, then that's most likely the fault of the manager's communication.

[Aeolun]

> If requirements were provided and person didn't fulfill them, they did a bad job.

Requirements covers a VAST range of different garbage that can be provided to someone under the guise of letting them get on with it.

[irrational]

This happened to me this past week. I built exactly what the spec said. They came back and said it all looks good, except we expected this to be that. Um, nothing about that was in the spec, nor was it ever mentioned verbally in a meeting. Making the change from this to that will require everything to be redone since it requires fundamental changes. I would have built it differently had it been communicated to me from the beginning. Apparently it didn’t occur to them to mention it. But they really want it. So I’ve started rebuilding it. Sigh.

[brazzy]

A key skill of a senior developer is a sixth sense for this kind of unspoken requirements, and asking questions to flush them out. Not always possible, of course.

[tstrimple]

This is why it’s important for devs to understand the problem being solved with their code, not just blindly executing to a spec that everyone knows doesn’t spell out every last detail the customer is interested in. Stop treating devs as fungible spec builders and more as partners of the business so they can shift from building against specs to solving real problems. The devs who have this “sixth sense” are finding a mismatch between the spec and the underlying business problem problem they know they are trying to solve.

[nine_zeros]

> A key skill of a senior developer is a sixth sense for this kind of unspoken requirements, and asking questions to flush them out. Not always possible, of course.

While true, a key requirement for even senior developers to function well is good management or a good team lead.

If effective management doesn't exist, the senior engineer should be made manager/team lead since he's doing that work anyway.

On the other hand, if management is micromanaging, then the responsibility of clarification is on the micromanagers.

Management of knowledge workers is a hard job. Most managers are incapable of understanding their reports and understanding their OWN standing among their reports.

[darkerside]

It's always shades of gray when it comes to management. You need to sort the grays into blacks and whites, but don't forget that they are gray.

[erikpukinskis]

> Sometimes the person sucks beyond repair and needs to be fired.

Which is... also the responsibility of the manager. Q.E.D.

[fighterpilot]

I edited my first sentence in my post to make what I'm trying to say clear, I realize it was worded in a confusing way.

I was trying to say that it's not always the responsibility/fault of the manager's communication skills specifically.

[goto11]

In management you can't really deflect responsibility downwards.

[fighterpilot]

I'm not trying to suggest that. I'm suggesting an accurate diagnosis of the mistake that was made by management.

In the case of my example above, it was a failure of management to hire a sufficiently competent person, or a failure to fire the person when their lack of competence became apparent. It wasn't (in my example) a failure to communicate requirements properly.

[goto11]

OK I get what you are saying, but if a manager is not able to communicate clearly enough that employee understands the directions given, then it is the fault of the manager.

If the employee understand the task given but does not have the skill to carry it out satisfactory, then it may be a question of the competency of the employee.

[Buttons840]

It doesn't matter who's fault it is. Communication failed. You can fix it by changing yourself or the other person, but only one of those solutions is within your power.

[yowlingcat]

> Sometimes the person sucks beyond repair and needs to be fired.

And who does that person report to? Who made the decision to hire them in the first place?

[fighterpilot]

That's why I said "It might still be the manager's fault for hiring that person in the first place"

[yowlingcat]

First of all, nobody "sucks beyond repair" -- everyone can grow and evolve although some people may start at a point where the company doesn't have adequate enough resources to make an ROI off of its investment.

The problem is, some people have a fixed mindset rather than a growth mindset because they've never seen anything different so they think it's impossible. When you say "Sometimes the person sucks beyond repair and needs to be fired" it ends up functioning as a red herring to deflect away from poor people leadership. It's a naive excuse made to hide a lack of understanding regarding how something really works.

To figure that out, let's ask this: how do you think the manager hired that "wrong" person in the first place, and how do you think that person ended up in a place to end up failing?

My point is not to be socratically pedantic here, but to point out that communication is /hard/ and often times an inadequate deployment of it is at the root cause of these kinds of failures. What kinds of communications could have gone wrong here?

1) Failure to adequately communicate with higher ups about headcount, business goals and necessity/capability to deploy extra headcount

2) Failure to adequately communicate requirements for the job before hiring

3) Failure to adequately communicate during the interview so as to properly assess candidates

4) Failure to adequately communicate expectations, progress, onboarding and plans after a candidate onboards

Guess what happens if anything about this chain of processes is broken internally? The candidate will fail, and due to circumstances out of their control. And then they will move to a more functional organization, and wonder why they ever wasted their time with this one.

Now, whose responsibility is it to make the right judgment call about that? Whose responsibility is it to have the right internal /communications/ to make sure the decision is well thought out and solid, to make sure it is brought through to fruition successfully? Who reaps the ultimate rewards, and who ultimately shoulders the greatest burden for mis-execution?

Not the IC. It is leadership. This isn't rocket science.

[iamhamm]

Could be the current manager or could be a past one.

[throwaway98797]

you are not as bad as the last person who miss understood you.

if people generally understand you and one person does not its them. if most people don’t understand you its you.