[B]Go to your room[/B]
“You can’t do that, because I say you can’t.” “If you don’t know, I’m not going to tell you.” “I didn’t see it, so it didn’t happen.”
These sounds like things a five year old might say,
[*]Education: Graduate from college, two years of university
[*]Skills: C++, PHP, HTML, Public nuisance
No matter who you are, no matter where you go, I can guarantee you will encounter someone like this at some point. There is precisely one question you need to think about for this situation: What are you going to do about it?
There are very few reasons for someone to disrupt the team. Let’s start with the obvious; someone’s having a bad day, and is taking it out on the world. What can you do?
There are three basic options for dealing with a disruptive team member. Fortunately, these three options remain the same across all these situations, so we only have to cover them once. You’ll also find that some are better suited to certain situations than others, but we’ll worry about that later. This is one of those topics that falls under the realm of Project Management, which we’ll discuss ‘briefly’ a little later.
To give a slightly better understanding of the options, I’m going to use a specific example that my father actually had to deal with a couple years ago. When he took over a certain project, the team was running a little behind. He called a meeting, gave a pep-talk, made some jokes, and was generally encouraging everyone to raise their spirits and believe they might actually finish the project on time. Then one of the senior programmers said “Well that’s a stupid thing to say.”
In more general terms, a disruption problem is usually one of discipline and/or confidence. In this case, it was a lack of confidence in the team’s ability to get things done on time. As I said before, there are three basic methods to use, and there’s always one of them that each person will respond better to.
1) Encouragement. Some people respond very well to simple words of encouragement; call it a pat on the back. Take them aside, tell them they’re doing a good job (or in this case that the team is), and make them feel good about themselves. When you feel good about yourself, you become more confident; this is a fact. Point out the good things they’ve done, and how important they are. Make sure they feel like they’re contributing, and then walk away and let them do their thing.
2) A break. Sometimes, what they need is a lighter workload, so they have a slightly easier time getting it done. When there’s less on your plate, you suffer from less stress. When you have less stress, you work more efficiently, and you know it. When you know you’re being productive, you feel good about yourself, which will make you feel good about everyone else as well.
Additionally, finishing a project is a rush. When you’ve been really stressed out, and all of a sudden you finish what you were working on, the relief is almost unbelievable. Just ask any college student.
3) Chastise them. Sometimes they just need a good dressing down. Take them aside, and let them have it. Tell them why you don’t appreciate what they just did, and what will happen if they do it again. If this means threatening them with being fired, then so be it. This is the harsh option, and it’s meant to be so. Let’s face it, there’s no kind way to tell someone they’re on the fence.
There’s just one thing you need to know about this third option, and I cannot stress it enough: do not ever do this publicly! Under no circumstance should you ever dress down an employee in front of everyone (anyone) else. Your goal is not to make them look like a fool, but to stop them from being disruptive. If you’re going to chastise someone, you take them aside after the meeting’s finished, when nobody is paying attention, and you close the door behind you. The only people who should ever know what was said should be you and the person you’re talking to.
The trick to applying these three strategies is to know which one the person will respond best to. In the previous situation, my dad pulled the person aside two hours after the meeting. He brought him in to the boardroom, closed the door, and explained that the point of the meeting was to inject some sort of hope in the team that the cause was not lost. He also told this person in no uncertain terms that such an outburst would not be tolerated again, and would result in serious consequences. This person never stepped out of line again, and the project was brought in on time and under budget.
The obvious reason was just being in a bad mood, now let’s look at the totally benign: Ignorance. The second possibility is that the person just doesn’t know how things work. Have you ever been part of an online forum, and had a new member doing things that upset everyone? That’s a case of not knowing the rules. What do the forum admins do? They usually send a private message to the individual explaining how things work. When someone is being a pest for no reason other than not knowing the ropes, you just need to show them how things work.
Next is the most unfortunate reason: They’re just plain selfish. They’re being disruptive because they just don’t want anything to get done unless they’re the one doing it. Do you remember back in issue 16 when I was explaining why coders and concept should hold their meetings separately? The example I gave in that column came directly from the transcripts of my own concept department. When someone is being disruptive for the sake of being disruptive, you must act swiftly, and harshly.
The first thing you must do is explain why you’re pulling them aside; they have to know that they are the disruption, and that they’re preventing other team members from getting their work done. Then make it undeniably clear that similar behavior will never be tolerated. Finally, tell them in no uncertain terms what will happen if they persist.
That first step is common among all three strategies outlined above. Before anything can sink in, they have to know what’s going on, and that they’re the proverbial ‘odd man out.’ If I were to tell you to stop doing something, but didn’t tell you what that something was, what would you do? You’d be confused, have absolutely no idea what was being asked of you, and continue doing the same things. When someone’s being disruptive, they need to know what and why.
There are many different ways someone can be disruptive; too many to cover in even two full articles. Sometimes it’s as simple as shooting down an idea before anyone’s had a chance to discuss it, or saying the wrong thing at the wrong time. It could also be something deliberate, like withholding work from a manager, or not working at all. The most complicated disruption I know of is not trusting a superior to do their job, and acting on the assumption that they’re going to run off and do something stupid.
Whenever someone’s being disruptive, it’s important to know which strategy will be effective at stopping the problem. Just because chastising them didn’t work doesn’t mean a pat on the back won’t, but it’s important to get it right the first time. If you employ the wrong strategy, the effect could be worse than the problem was in the first place. So how do you figure this out?
Remember that first step I talked about three paragraphs ago? The key to finding the right strategy is to pay attention when you’re explaining the problem. Watch their face and pay attention to their reactions. You can start to tell from their body language and verbal responses which approach will be the most effective with them.
This is a huge topic that I’ve done my best to address in a very short co lumn. It’s also a very important topic, because you will need to know how to deal with disruptions when your project is underway. Being good at managing your workers is probably the single most important skill you’ll ever learn. You’d be surprised how often a sharp dressing down can lead to someone being the most productive worker in the company, or how patting someone on the back can lead to superb designs, because they suddenly believe in themselves.
Then again, sometimes it just doesn’t work out. Remember that coder? Everything in this column is something he did, and he’s currently looking for work. I hope he learned something from me.
[B]Disclaimer:[/B] Behind the Veil was written by Chris Marks and hosted by Diabloii.net. The opinions expressed in these columns are those of the author, and not necessarily those of Diii.net.]]>