Friday, January 29, 2010

A good advice from my leader ...

When a Colleague's Mistakes Affect You

In an attempt to function in this increasingly complex world, organizations are becoming increasingly complex themselves. They are built on collaborative partnerships, dotted lines and matrixes, all of which mean more and more of your work depends on the work of someone else. When a colleague is making mistakes, this interconnectedness can feel like a major pitfall.
Yet a job where you don't interact with others is nearly impossible to find, not to mention somewhat boring. So, you need to figure out how to make relationships work. Every management expert would agree that positive working relationships are essential to getting things done. So what do you do when a colleague is not doing her part and it's affecting your work? Fortunately, handling your colleague's mistakes in a productive way cannot only help remove barriers but may also help your colleague, and you, gain new skills.
Principles to Remember
·         Keep in mind that relationships matter
·         Be direct and honest with your colleague about how the mistakes are affecting you
·         Offer help if the colleague is struggling with a short-term issue such as a heavy workload or a personal issue
·         Badmouth your colleague to anyone in the organization
·         Assume your colleague is aware of the mistakes
·         Go to your colleague's manager without first talking to your colleague and your manager
Case Study #1: Stopping Mistakes Before They Happen
For Drew Chatto, a software engineer who worked at VeriSign, close collaboration wasn't just part of his job, it was his job. While he wrote code on his own, it was always reviewed by others and then put together with his colleagues' work to form a complete product. Eddie, one of Drew's colleagues, was a less experienced — although not less talented — engineer. Because Eddie was relatively new to VeriSign he wasn't familiar with the specifics of how the company wrote code. Instead of asking questions, he made assumptions and often finished code quickly. During code review, Drew regularly found mistakes with Eddie's work and had to ask him to rewrite it. Eddie never argued but he continued to make similar mistakes. Tired of having the same conversation over and over, Drew offered to help Eddie think through his code assignments before he began writing. These conversations gave Eddie the opportunity to ask how specific things were done at VeriSign, instead of making the decisions on his own. As Drew said, "I couldn't expect him to know the right questions." Eddie was open to the suggestion; he knew Drew had more experience, and he was likely tired of having to redo his work. Drew's approach helped Eddie avoid mistakes before they happened. While those preliminary conversations took more of Drew's time, they saved him time in the code review process and built a stronger, less contentious relationship, with Eddie.

Case Study #2: The Risk of Escalation
Allan Cohen is a professor and dean at
Babson College, and one of our experts from above. In a former role at a major university, his good friend and colleague Carl served as the Associate Dean of Allan's department. Allan was proposing a new program that required Carl's approval. Despite Carl's background in accounting, he kept making accounting errors when attributing costs to the new program. Worried about him, Allan stopped by his boss's office one afternoon to explain what was going on. His boss was the Dean of the School and as such, was also Carl's boss. In the middle of the conversation, there was a knock at the door and Carl walked in. Carl's office was directly next door and he explained that he had heard the entire conversation because of a chip in the concrete wall between the two offices. Allan explained, "We never mentioned the incident again but it took me well over a year to repair the relationship." Allan regrets not going to Carl directly first. "If I had, I could've saved the relationship and maybe even helped him."