But what happens if there is obviously some sort of personality problem and two team members just do not get along?
There are two possible reasons for this. First, there's some kind of history or bad karma between the two. They just flat don't like each other for whatever reason. You may have no idea of the background of the discord, and, frankly, there's really not a reason to know. You have to take steps to fix it.
You solve this kind of a problem with team building. People don't have to like each other to work on teams and still crank out a professional level of work. It happens all the time all over the world. Try your best diplomacy and team management techniques for a short time, hearing out each of the differences and seeing if you can arbitrate toward some amiable solution. Stress the importance of each person's role in the project.
When you've exhausted your efforts to get them to reconcile, consider getting your human relations department involved and see if you can get some team-building exercises going. One of the better exercises to involve a small group in is the Myers-Briggs (MB) Type Indicator instrument for evaluating personality types. Putting a team through an MB exercise causes them to find out differences about one another they had not known previously. There are other team-building efforts you can go through, each producing some sort of great motivational and inspirational fruit. Check with your HR
specialists to see if they can help. This isn't a job you should feel you need to take on yourself.
The other problem that develops is that one individual simply isn't of the caliber required to accomplish the tasks set before him or her. You may be really stuck because there simply isn't anyone else out there to do the job— you're forced to use this person. A derivation of this problem is when you take a perfectly competent person and put them in front of a new technology that does the same thing as the technology they're already using. The person is fully qualified but can't drive the interface well enough to act like he or she knows what they' re doing. You might, for example, take an Oracle expert and put them on a Microsoft SQL Server project—effectively blowing them out of the water while they get used to the new interface. The basic precepts are the same, but the look and feel are totally different. And in this instance, you run the risk of generating quite a bit of resistance as well.
You fix this problem with training, if there' s time, or contractual help if there ' s not. If neither time or money are available, then you ' re stuck and you have to manage it with team-building skills, which are probably going to be only marginally successful until the team member comes up to speed.
You can also fix this problem with a mentor of some kind. Perhaps there' s a person with a background in SQL Server, for example, who' s not assigned to the project because their job isn ' t working as a PBA. Maybe you could "borrow" this individual for an hour or two of mentoring from time to time. Alternatively, if Susie' s the problem, perhaps you could ask Joe to see what he can do to assist her instead of fighting her.
The bottom line in all cases is effectual communication. You need to call an apple an apple and an orange an orange. What I mean by that is don t gloss over problems such as this—talk about them. But also don't be blunt and belligerent about telling someone they lack a skill. Use diplomacy and tact while being a truth-teller.
Was this article helpful?