Hacker News Reader

Comment by rzzzt | Hacker News Reader

So... how does one break the cycle?

Managers inadvertently create this dynamic when they are focused on attacking obstacles rather than creating infrastructure. If <employee> knows how to do something, and that thing is not getting done, then <employee> is the obstacle. The discussion often doesn't make it to the point of 'why doesn't anyone else know how to do this?' Management needs to think more like logisticians rather than tacticians.

From an employee standpoint, when helping your peers ask them to take notes. Any additional requests -> ask them to refer to their notes. This sets a clear boundary and gives you a built-in defense while still helping the team achieve goals. Now you are no longer the obstacle, because you provided training. The obstacle is now <Peer's> inability to properly take notes or retain information. <Peer> knows this and is much more likely to attempt solutions rather than nag you into doing their job, or escalate to management. Additionally <Peer> will have better knowledge retention by synthesizing their own notes.

Documentation is a good barometer of this behavior (it's the first casualty). If your environment has little documentation, then you are probably looking at a group that will punish responsibility. No one documents anything if all that earns them is 'John's instructions don't work, I've asked him several times to fix it'.

For managers: better metrics or fewer metrics.

For programmers: jump ship. A well-executed handoff process will not only maintain goodwill but remind others of your value.

Start by actually talking to your management instead of just trying to be a rock star. "Hey, I'm spending a lot of time doing Team X's job and it's impacting on my assigned work, if you want me to keep doing this then put me in charge of Team X, otherwise let's all sit down together and clarify who is responsible for what."

So I'm asking this not to move the goalposts, but because it's the situation I'm in - what do if your manager is too weak/distracted/uncaring to actually act on this information and/or the projects in wait state on you are not actually within your manager's sphere of influence?

Hmm, tough one. The default answer is "follow it up the chain" - if your boss isn't doing the right thing, talk to their boss, and so on. Another approach is to talk to the manager of the team who's leaning on you, and let them know (if they don't already) how much they're depending on you and that you should really be in that team. This can cause drama with your immediate boss (they're seen as 'poaching' you) but if said boss doesn't care then this might not be a problem.

Of course, by the time you have upper management yelling at you because "several teams are waiting on you", the response becomes "why have you allowed several teams to become completely dependent on one overworked person?"

The other, more drastic solution (as someone else said) is simply to move jobs. This can be the only way to fix the issue if the entire management structure is corrupted and you don't think it's fixable from within. You could even just leave, start a consultancy company, and let the second team know that you're available for hire when they need you.

Unless something is keeping you there, just find a new job, here are some reasons:

- If you reach this situation, you're more competent than the rest of the group. Nobody to learn from, time to go.

- "Management" is a big machine, with its own insider culture and politics. It does not change overnight, do you want to wait 6 months minimum for things to get better?

- Changing job is good for just about everything: career, money, knowledge... as long as you don't do it too often.

- Meta-bonus: getting into a job with better peers means tighter work-friends. It's not fun to be around people overdesigning object-oriented projects when you understand functionnal programming and low-level debugging.

Reply on news.ycombinator.com