I think the article misses an important point - never attribute to malice that which is adequately explained by ignorance (Hanlon's Razor). Many of these behaviours are not malicious, but are borne out of lack of experience, fear of failure, shyness or just plain misunderstanding. As a peer, you can certainly assist with these issues. It should always be your first assumption when appraoching the situation.
However, if you are dealing with a verified malicious/manipulative/lazy person I think its management's responsibility to do something about these behaviours. As a peer I think you can be proactive to expose some of these behaviours and the impact they have on productivity and team morale.
The key word is transparency.
Transparency to these people is like sunlight to a vampire. They will do anything to avoid it. The tightrope act is highlighting these problematic behaviours to management or other peers without being a dick about it. A key part of this is challenging the behaviour rather than the person. Tackle issues as if they are shared problems you need to solve rather than 'you versus me'.
Here are some approaches that have worked for me:
>Be Bossy and Critical
This is easy. If someone tries to palm off their work to me, or give I simply ask them to run it past management first as it may impact the deadline for other tasks. 90% of the time they never ask. The 'Oh my god, whats up with the reports? Am I going to have to do this myself??' attack is even easier to handle if you can exercise a bit of self-control and avoid getting defensive. Just reply via email (and CC the project manager) 'Yes, thankyou for offering! I'm snowed under with my allocated tasks so we'll have a better result if you're able to finish these reports'.
By thanking them for their generous offer, you turn the whole situation on its head. What a team player!
> Shamelessly Self Promote
Line up the self-promoted activities with the goals of the project. If they match, well, thats ok. If they dont, ask how we as a team can ensure we hit our deadlines. Remember that we're all a team, and we all (management included) want to hit our deadlines. As a team, will we have to cut back on any low priority tasks? What should the team be prioritising? Team Team Team.
> Distract with Arguments about Minutiae
Acknowledge the minutiae, do not dismiss it. Then ask how they see this impacting the project deliverables. Remember with project teams (and particularly software teams) each individual is focussed on their part of the puzzle....and that small piece becomes their whole world. I dont see this behaviour as malicious. Just a side effect of the tunnel vision required for difficult programming tasks. It helps to 'come up for air' every now and then and see the big picture. That puts these minutiae issues into perspective. Ask them to raise it as a discussion item post-deadline. Share your own little minutiae problem and how much it annoys you, but describe how you live with it because ultimately there are more important things to worry about. In my experience, this minutiae thing is not about laziness, its about team empathy and acknowledgement of effort.
> Time It So You Look Good (Or Everyone Else Looks Bad)
This is one of my pet hates. I work with an international team and some people really abuse the time difference with this scam. When two people on the opposite sides of the globe do this, its a thing of beauty. 4 days of non-work to restore a SQL .bak file. To be honest I dont know how to deal with this aside from daily progress reports which expose how little work is getting done. Explicity stating 'if you encounter a problem that stops you, just put it aside as we dont have the time to lose' sometimes helps.
> Plan Excuses Ahead of Time
I've noticed that sometimes this is not about excuses, its about a lack of confidence. Perhaps bad time syncing in linux can cause big problems? Who knows? Many people are scared of breaking things they do not understand. This is a reasonable attitude. Just need to encourage pro-active thinking. Ask them what they did instead? Perhaps set up a couple of VMs that people can play with and not worry about breaking? We've had alot of success with this approach. We had a support team who couldnt solve any customer tickets because they were terrified of 'messing with the system' and hadnt received proper training. After a couple of months active encouragement, a no-blame approach to problems, and a few short training sessions focussing on how to diagnose issues rather than following a script....they became incredibly effective. Now they'll jump right in, have a go, if they cant fix it, they'll describe what they did and where they got stuck. Ticket turnaround time dropped by about 75%.
> Take Credit in Non-Disprovable Ways
I dont really know how to handle this. It used to worry me but I dont really care any more. I've had the most indivual success when I remain team focussed instead of expending mental energy worrying about my personal brand. Granted, I now work in a large organisation. I've seen this behaviour in a small company (ie a manager/owner 'king of the castle' egomaniac) and it was terminal. Time to polish up the CV.