Tuesday, April 26, 2011

Randomizing

This is a relatively good post to follow last week's post on enforcing boundaries; this post is about the randomizing factors (sometimes people, sometimes events, sometimes resources) that make standing up for yourself, your team and/or your boundaries that much harder.

The heart of managing randomization is communication with others and reliance on yourself. It's ok to let people know that randomizations will affect the other tasks/projects on which you are working and how. While you might be a super hero and do them all, even with the additional complication, your health and sanity are more important. Most people read that list sentence and say "Yes, I'm sure its that way for everyone but me," but let me tell you: working yourself to a point of crazy doesn't get more work done, it creates more work to do as you make mistakes.

Part of fighting randomization and violation of your work boundaries is agreeing that, right here, and right now, what you think is important is important. They do pay you to be an expert at what you do (or to become an expert). If you can't agree that you are allowed to make normal time frames out of abnormal events, then you will never fully maintain your boundaries. Boundaries are not necessarily there for the day-to-day, but to handle and bolster you against the random.

Reality is a harsh mistress: just because you want to do too many things at once doesn't mean that you can. Boundaries are there to help you not hit the wall and let people down. At some point you'll take on too many tasks--often because of randomization--(no matter how much you try) and not be able to do them all as expected with the level of quality you would like them to have. People need to know that in advance. Some people would rather have the work product late than low quality. You deprive them of the choice of what they receive if you just blindly accept work. Use your boundaries--and the occasional randomization--to assess what is physically possible for you, and then communicate that to the interested parties. In addition to making your workload more bearable, it will improve the quality of you work and your relationship with others.

Randomizing factors are not always humans, but always lead to the need to communicate with and reinforce boundaries with human beings. Random events or resource losses still affect people other than you, even if they only happen to you, and of course, randomizing humans always require some human intervention (unless you're moonlighting as a serial killer).

Many people are familiar with the human randomizer; maybe you live with one, maybe you work for one, and (possibly) you are one. The traits of the human randomizer are that your natural operating procedure is that of exception to whatever the rule is. Typically the randomizer either has a really good reason for violating the convention of process, or they have sufficient power over the situation that a good reason is not necessary. Rarely is the human randomizer malicious. Typically he or she has a radically different method of getting things done than, well, probably everyone, and what makes sense to him/her completely messes up a work day for someone else.

A good example is the randomizer boss; for whatever reason--maybe he/she is very reactive to other departments, or a procrastinator so that they only get work to you just before it's required, or she/he is very, very unlucky--daily, sometimes hourly, the randomizer boss will drop by your desk or send an innocent-seeming email and suddenly a new project is now your top priority.

Other human randomizers include co-workers and executives higher up on the chain who may have let something go to the last minute or found a "really cool idea" and gotten it approved by upper management and need you to work on the new hot thing RIGHT NOW.

Randomizing events are (usually) easier to handle simply because they don't happen as often. Usually. An earthquake may disrupt production meaning that you have two days of nothing on your current urgent project and need to use that time on the next one, for example. Or a competitor's product is announced to come out two weeks before your product, so you have to work crunch time to get your product out first. If you work in a competitive field or an earthquake zone, you are aware these things can happen, and while you often may include some float in your schedule for it, it so rarely happens that it can still ruin a perfectly good schedule/day/task experience.

Randomizing resources are the least predictable of the randomizers. When you come to work you typically expect your equipment to work. Rarely does a project manager on a three week project schedule time for hardware/software/internet failure. Most people assume, also, that they'll be healthy for the entire run of a project, so when the other engineer is out sick and his projects are due before your projects, it can be very unexpected to get them dumped on your plate in an effort to get them done when he really, really can't do them himself because he's ill.

Whatever the reason for the randomization, in addition to the time away from whatever your previously "current" project was, you also have to the pay in additional work for transition time.

Transition time in electronics is "the time a dynamical system needs to switch between two different stable states, when responding to a stable input signal." Assuming that "Stable" isn't required for the definition of transition time for humans, transition time is the time it takes to move from one task to another. From physically moving materials or hoofing it building to building to allowing your brain to let go of one activity and get organized and then started on a new one, this transition time can take up to 20 minutes per transition.

Dealing with randomization is a little different than establishing your boundaries, and a little bit the same. When a force can be reasoned with, establishing and maintaining boundaries is actually a lot easier. Randomization typically involves some lack of general reasoning (by someone, something, or the cruel hand of Fate), and while you still have to deal with it, your typical tools of reality and logic are not as easy to apply.

So, to start with randomizing humans, it is always good to have established boundaries before the randomization. As noted in last week's post there are a variety of good ways to do this, which you should check out.

If you don't have normal boundaries established prior to the randomization, there's really no time like the present to clarify what your priorities are. As I always say to my bosses, "I am here to work." It doesn't matter to me what I'm working on, for the most part, as long as everyone in the food chain gets out of my way and lets me work on it, or accepts why I am not working on their thing right now. I usually keep that last part a bit more diplomatic, or entirely in my head, but you get the gist.

There are always two outcomes to the randomizer humans: you can do it when they want it done or you cannot do it when they want it done (for various reasons, up to and including that what they want done is impossible). No matter what the randomizer says, or what other things speckle your plate, or the urgency of the five items you're already working on, you really need to think about it in terms of: can I do what they are asking when they are asking or not?

Once you've determined that answer, you need to look at what you have to do to either communicate that you cannot do what they want when they want it done or what you need to move/pause/alter in order to do what they want you to do when they need it done. Please keep in mind that in either case you determine, just from what you're desk and tasks look like, you do not actually make this decision alone. The randomizer human would like you to think that you have sufficient control of time/space/your destiny that you can, but just like when you established boundaries by getting agreement at a peer level and above, you still have to take your initial decision about randomized items and subject them to similar review.

For example, if the task is impossible (not just because you have other tasks, but because it literally is impossible, like trying to hold your breath for 30 minutes), just telling a randomizer the task is impossible is frequently not going to work. Remember I mentioned that logic doesn't always play into this?

Using our impossible task above as an example, you would need to both tell the randomizer the task is not possible AND provide that randomizer with an escalation path. Typically you're being randomized with a passion (something is late, something is too cool to wait, etc.). Just saying "not possible" works like saying "no" in last week's entry around boundaries. If they don't have a method to escalate, they'll make one. So when you determine its physically impossible, go to your boss (provided he/she isn't the randomizer), and explain both the issue and the escalation path. Maybe you need to call in a Scientist so that the randomizer has outside confirmation that no one can hold their breath for 30 minutes no matter what.

In the event the task is possible but unlikely (ie: you have tasks that are prioritized above the randomized task), you would do the same thing: talk to your boss and then provide an escalation path to the randomizer and clear instructions: "If you can get tasks 1-5 off my plate for two weeks, then it's possible." Get the randomizer pestering someone other than you, someone who really does have control over your schedule and tasks.

In the event the task is possible and likely, THINK CAREFULLY. Even if the task is a 5 minute task, are you setting a precedent whereby people feel that they can randomize you regularly? If you have caved in the past and this has become a habit, work with your boss, a project manager, or even a fellow co-worker to deal with it. Ask that all tasks go to person X (manager, project manager, co-worker, etc.) before it comes to you. Often people will reduce their overall requests if they don't feel they'll get instant gratification for making them. In the event that this is either the fifth time or the first, you will want to notify someone--such as your boss or a project manager waiting on your work--that you are doing this additional task. Talk to your boss and/or project manager and have them talk to the randomizer about controlling future tasks. If you are the boss or the project manager, put a process in place to handle randomization...from planning extra days into the schedule on the knowledge a specific VP likes random additional features to a process by which current features get de-prioritized under certain circumstances to allow for the new "cooler" features, have a way for randomizers to, well, not randomize.

With events and resource randomizations, less front work can be done. While it's often hard to argue with a high level executive about adding in a cute smiley face because people like smiley faces, there is no arguing with a tornado (one actually touched down less than a hundred feet from one of the places where I worked) or a dead computer.

In the case where an event or resource randomization has taken place and you are feeling overwhelmed/not sure what to do (there is really no maintaining work boundaries with electrical equipment) take a step back. Get up and go for a walk. Breathe a little. Come back to your desk and make a list of the items you have to do in addition to the work and transition time created by the new randomization. Then, talk to your boss or a subject matter expert or your project manager about the priority of items. If, for example, things are just not there for you to do, say, testing on a video game, they are not there and those people can agree with you on what you should be doing next. If you cannot do testing because you cannot get the computer to work at all, it's ok to walk a list over to people or call them, and let them know you have a new number one priority.

Today's post was more of a meandering, which sort of makes sense, given that its about randomization and I went all random on you. In the interest of full disclosure, one of my nicknames is Random Girl (which is not something you usually expect of a manager, (Im)Perfect or not).

The point of today's post is "things will happen and you will expect it, but you won't REALLY expect it until it falls on you like a ton of bricks." Being randomized SUCKS, and you are not alone in feeling that way. However, you are also not alone in being paid to do a job, be an expert, get work done, and it's OK to stand up for yourself and your work against all kinds of random things. You matter, and your belief in yourself (and others) affects your quality of work especially when you are being randomized.

Thursday, April 21, 2011

Bonus Blog: What do you want to hear about?

It's that time again when I pester the readers (Hello to both of you!) and ask what you are interested in me doing a post about. I tend to get better responses to user-generated topics, so please, let me know what you'd like to read about.

Thanks!

Tuesday, April 19, 2011

Managers can haz boundareez

Sorry for the LolCat-eez. Personally, I believe that if Cats spoke English, it would be in complete sentences and they'd all sound like Oxford Professors (even the really dumb ones, which would then be hilarious).

That said, the main method of not going crazy at work is having and enforcing boundaries. This always sounds simple. Feel free to read that sentence aloud. Easy to say, right? How do you freaking make other people comply with it?

That's rather the trick, then, isn't it?

Most work environments are sort of precarious places as you are expected to both do as you are told AND take initiative and somehow guess which times are which for the entirety of your employment. How independent your boss or co-workers want you to be is inverse to how much they want you to do something specific for them under certain conditions/time frames. Which is to say, they want to hand you a piece of paper with three sentences and have you drop everything and hand deliver them the Taj Mahal in two days, exactly as they'd envisioned it where you take your own initiative to "make it happen" (get resources, hold meetings to approve the design, etc.) but you hand it off to them to their exact specifications.

This is pretty much true if you have a manager or are a manager, but often gets stickier when you're a manager or project manager because you have resources that other people want to use in this exact way. You know, resources that you've already tasked with doing other stuff (as you can't have them just sitting around and doing nothing). Other stuff you may well be invested in from the last time you got a piece of paper with three sentences.

Step 1: Assert yourself. Who are you in the org? Who are you in relation to your boss and your boss's boss? If you're an individual contributor, what are you responsible for. Is it spelled out somewhere that you can reference/point to/hide behind? If not, why not? If you are a manager or a project manager, what is your current set of goals for this year? Have you got that agreed upon from your boss? If not, why not? These statements--in written form or transcribed by you from verbal conversations, is the basic framework by which you and/or your team will take in new work and, more important, decline/postpone new work as needed. So, get your initial idea of what you're doing written down, and get your boss and (if you can) his boss, to sign off on that. Could be your job description or could be a series of bullet points about what your team does and in what priority order.

Step 2: Never say no. This may seem weird in an article about asserting boundaries, but the truth of the matter is that you are never really the one saying no if you have guidelines about what you are and are not supposed to be working on. As a coder, you can not be co-opted to move boxes on the loading dock; as a back end developer you cannot be demanded to write graphical user interfaces; as a manager, you can be asked to do individual contributor work, but you are allowed to pass that down to a subordinate as it suits that person's capabilities.

What this means, then, is that you are not saying no--the process by which work is managed is the one doing the declining. For example, demanding that the person at the fast food restaurant change your tire makes no sense, and once you can show the person asking you for the equivalent (or asking your team for the equivalent) what you're team's goals and priorities are (and job descriptions as needed), they can't BLAME you for not being a mechanic who can change tires. They have to look to someone else to help them. Simple, real, and no-nonsense.

Note that most of the time, the savvy people of the world will find a way to fit your structure of work intake. So, you are a fast food restaurant...you can't change my tire, but you can FEED THE PERSON I HIRE TO DO SO, right? Well, yes, I suppose we can (to extend a metaphor well beyond the point of logic).

The next step in not saying "no" is saying "Not now."

Step 3: Be helpful. When saying you cannot help someone by doing the work they are requesting, it's a really good idea to point them to the next person on the chain who might be able to help them; in this way they have direction. People without direction who feel they've been told "no" will escalate, even if your group is not the group who can help them. This wastes a ton of time and makes all parties look bad.

Instead, send them to someone who can help them, or let them know "Not now, but sometime" you can be the person. If you know you will be updating them as to your readiness in two weeks' time, you know they won't be foisting new requirements on you for that particular project before two weeks--your time is effectively your own (or belongs to the various people who have already managed to wrangle it).

Step 4: Deal in reality. It's easy to say yes. Very, very easy. It's hard to actually deliver yes. If you have a five pound sack and ten pounds of stuff, only five pounds is going to fit into it, no matter how much the people that want you to do stuff yell at you. Your job, as a manager, is to tell the truth, even (and sometimes especially) when people don't want to hear it. Get your facts in order, know the capacity of yourself and your team, and tell people that they can have all 10 pounds in the sack, just not all at the same time.

This also applies for multiple priority 1 projects/issues/revelations from the muses. Everything can't be a priority 1; when you start to work on it, you'll select something to do first. The choice of the people giving you marching orders is that they can either tell you what's first on your list, or you can pick it yourself, but reality dictates someone does the picking...then suggest it be them. The actual explanation as I wrote it actually seems to work wonders, even with the most dedicated followers to the rule of "everything is really, really important and must be done first."

Finally: Share the responsibility. You report to someone, even as the manager. Even if it's a group of people, talk to them and let them know what you're doing first, second, and third. With agreement from them on your priorities (and a quick run back to your desk to sum up the discussion and get it in writing winging its way to their inboxes), you can do the work you know you can get done in the time you can get it done and if anyone questions, argues, or gets upset, you can send them to the other folks who made the decision with you/gave you permission to do your work in a way that, well, actually works.

Tell tale signs that you need to watch your boundaries (and possibly the boundaries of your team) are working more than eight hours in a day for more than three days in a row (when you normally don't do that), and dreading to come into the office. When you face why these things are happening, then implement some of the ideas above, you'll get some breathing room, and probably find you--and your team--are happier within the walls of your own boundaries.

Thursday, April 14, 2011

Bonus Blog: Delivering News about changes in the workplace with as little jackassedness as possible

How many meetings have you been to where the gossip has been in full force about layoffs or reorgs or people leaving, the sky falling, the return of Godzilla, etc. and then the meeting sort of answered your questions, but may have left you in a further panic while having to sit through another hour and a half of things that management wants you to hear in hopes that you will not freak out about whatever the change is?

I have sat in a lot of those meetings.

From time to time, I've had to give the occasional meeting. When I do it, I like to follow the guidelines below:

1) Make it a short meeting. People get shook up, they want time to process it. If you're not giving them time to process it by talking to them continually, you are effectively wasting your breath because after the news and the immediate five minutes after (during which they're looking for additional info), you've lost them. These kinds of meetings should be booked for an hour and last a half hour or less so everyone has plenty of time for questions and/or to flee to the parking lot to quietly talk amongst themselves.

2) The first ten minutes of your half hour "the world is changing" speech should be exactly what is changing the world: we're going to have a re-org because budgets are down. You can explain why budgets are down, or why you're good people, or how awesome things are, but for sure communicate that a) the thing is happening.

3) The second ten minutes should be information the people hearing the announcement should find useful. This means that a lengthy explanation about how rough the decision was to make, etc. should not go here. This is not about you or the company, this ten minutes is addressing the fears and concerns of employees. This is the ten minutes when you care about their feelings and their future. This is when you tell them when changes will apply and what happens next or, when you expect to know more about changes and where to go to get info about what happens next. For example, "We're having re-orgs, but no one is being let go," or "We're having a re-org and we'll be reviewing all positions from now until May 1, at which time we'll have additional information for you about the reorganization" or "X is leaving us, and a complicated process of internal promotion will be taking place in the coming weeks. For more information, please see your manager after this meeting."

4) The final ten minutes are things that you are saying to prove that you are a human being relating to other human beings. Validating feelings of loss or frustration, assuring them that you'll all get through it together, and so on. These ten minutes are often empty platitudes (I did do a whole blog about how you sometimes have to lie as a manager), but people who have been shaken up need comfort, however you can give it to them, as honestly as you can give it to them. They need to know that things are safe, that they are heard, and that even if there's nothing they can do, they are not alone. This is also the time you ask them if they have any questions and you answer those questions as honestly as you can.

5) When the 30 minutes are over, interrupt the discussion and let folks know they may flee if they wish, but that you will be there for the next half hour to answer questions. Make yourself available then (or later if you have to), and work with other manages to be available to ask questions/have a unified message front for employees.

6) Now is not the time to announce additional instability or ambiguity. If your VP is leaving, telling people that you're also thinking (but haven't decided) about a complete realignment of the department will only spread panic. You don't want people to panic anymore than they already are. Also, despite the fact that it seems like it's best to pull the bandaid off all at once, it's not. People need to feel some stability, especially if you haven't decided, for sure, to make things unstable.

7) If new changes have to be introduced after a major one, make them as positive as possible; so, if a dept is realigning after a VP is leaving, frame it with positive language such as being more efficient, and letting people do more of what they want to do. And try to make it that way while you're at it.

If you are not a manager, or not a manager involved with the big announcement (whatever it may be), you can still help. Talk to your manager (if you are an individual contributor) and ask for a group meeting and suggest he/she go over the points: what the change is, how it was made, what exactly will affect the team, that we're all in it together. It will make you and your manager and the rest of the team feel much better.

If you are a manager, but not the one dropping the announcement, you can set up your own meeting to hit these points, and to be available to your team or others to answer questions and be available for venting. People don't like change. Let them feel safe expressing themselves and they'll adapt to that change pretty rapidly. Further, they'll follow you through it, because they know you'll treat them right, because you HAVE treated them right.

Tuesday, April 12, 2011

Being Right or Being Happy

In the modern workplace, you will work with people you didn't hire such as people who were there before you, and people who are likely to be there long after you are gone. Maybe you hired your team yourself, maybe you inherited it, maybe you just got added as an individual contributor.

Whatever your circumstance, there is always going to be that special time when there is conflict among the masses.

Now, when you're the manager, its not really anymore fun than when you are not. The quality that makes a good team is people feeling comfortable telling other people that they have dissenting views AND the team handling that and pulling something productive out of it.

As with any conflict between two or more parties, it is possible for all parties to be wrong, all parties to be right, and just about any other juxtaposition of right and wrong possible depending on the number of people involved.

In technology, which is where I have done most of my work, I do find that the logical minded folks--the ones who could probably have written the paragraph above this one--are the most likely to argue unto death about right and wrong in a conflict. With great education and experience comes...well, great responsibility, yes, but a great deal of stubbornness, too.

No one enjoys being wrong, unless it's about learning that they don't really have some terrible disease or something. At work, for the most part, being right is rewarded and being wrong is greeted with cautious neutrality and occasionally, outright scorn. Work is where a lot of people have developed their worth as individuals, and that worth can (and in their mind, is) questioned when you doubt them such as when they might be wrong.

Some people love their work. Some people love their friends. Some people hate being agreeable. Whatever the motivation is, you're going to find yourself in a battle of "right v. wrong" in the workplace at some point in your life. When it happens, and you're imagining screaming at the person (or persons) who are adamant that the world is flat or that the sun rises in the west, here are some things to consider.

1)People sometimes come to the conversation in a bad state of mind. For example: one of the greatest sins in America, where I live, is not hearing something. Someone says something to a co-worker who fails to acknowledge them or responds with, "I'm sorry, what?" and that person repeats himself, usually a little tensely, but with good nature. They say "what?" again, and the second time that the person has to repeat himself (the third time you're saying it), that person is suddenly, and unreasonably, angry. Now make the conversation a natural conflict--"Should we go with white or black?"--and emotions are now mixed liberally with the actual facts in the data. Hearing is only an example here (and a freaky one, if you think about it, because everyone has moments when they aren't concentrating on their hearing), but anything could have happened to the person before the potential conflict started, and they are bringing all those hidden--even to them--issues with them to you when you need to talk.

2)A lot of decisions made in the workplace are not important. Let me repeat that: a lot of decisions made in the workplace are not important. From how you'll name variables in code to how you'll decide which group is required to get their flu shots first, there are dozens of relatively meaningless decisions being made daily. Oh, you could say its VITALLY important for either of those things under specific circumstances, but in the general scheme of things, a decision gets made so the task moves forward. Not rocket science, and typically not a matter of life and death (although if you are working in a hospital, thank you for reading my blog and your mileage may vary).

3)Sometimes the consequence of doing something in a non-opportune/less efficient aka "Wrong" way is not "horrible terrible things with bad sauce on top." Sometimes people actually learn from their mistakes. Obviously the company isn't excited about your making mistakes, but sometimes its the best way to learn something: to try and fail.

4)Sometimes people care too much. It's a pet project, for example, or its in a technology they are DYING to try out. Maybe its political--if this person gets it this way, then he/she feels they are getting ahead/putting an opponent behind. Whatever it is, people get freaking attached to some decisions, whether they are rational or not.

5)Sometimes you have bigger fish to fry. In the grand scheme of a day, you're probably going to have to make dozens and dozens of decisions. Do you really want to waste thought, time and energy on one of them? The conflict in question may not matter in the grand scheme of things (like #1) or in the scheme of things ranks low (do I covet goodwill by acquiescing to this other person to build capital to get what I want later?) Sometimes you just don't have time to argue.

What this all adds up to (and I'm sure there are more than just five things affecting decision making, but that's where I'm stopping...for now) is that every argument has multiple variables, most of which you don't know until you engage.

Once you engage, you need to measure your own reaction (in case any of those things are affecting your judgment) and query the other person on the matter.

Where possible, it's important to repeat back what you've heard, and to ask the other person to do the same to verify they heard you--your brain processes language with more clarity when you're saying it than when you're hearing it, and it makes the other person feel more at ease that you really are listening.

Then, I recommend, take a break. Come back to it.

Think about the conversation while you're gone. Don't obsess on it or anything, but think about all the factors and then ask these questions:

--Could this be a learning experience for me or others?
--Is this a meaningful decision? If not, why am I bothering?
--Would I get more for letting the other person have their way and giving up my own, either by them learning or us being able to move forward?

Once you've answered those questions you know that either a) you don't need to fight/worry--you can let the other person go with their decision or b) you do need to invest in this, and come up with compatible arguments, and why you need to do so.

It sounds simple, but people frequently are driven by emotion and habit (hence this post).

One comedian said, of his relationship with women, "You can be right, or you can be happy, but you cannot be both." Often in work situations you can be both, but more often than not, a good compromise leaves everyone annoyed. In a world where happy endings aren't the norm--the work world--knowing about other people's motivations around decisions, and that sometimes its all right to give up or give in (sometimes its even more productive to do so!), can be uncommon common sense.

Tuesday, April 5, 2011

The Value of Letting People Do What They are Good At

This blog could also be entitled, "Why people still have to do things they hate/suck at, but won't care as much" or "Yes, people can still grow technically and in their careers doing things they are already good at. Seriously."

Ever worked with someone (or had them work for you) that was kind of a terror-on-wheels? Maybe they gossiped too much, didn't code with detail in mind, or plain failed to produce things at required times.

You know what? Those people did have things they were good at. It just wasn't whatever they were sucking the life out of your team with they were doing at the time.

This is not to say that every screw-up has a silver lining, nor am I saying that bad performance should be explained away by "they're not doing what they're good at." What I am saying, though, is sometimes life gives you lemons and not a lot of options. The best way in those situations to make lemonaid is to use what you've got in the best way possible.

I had a beautiful lady on my team who was a decent coder, quick on her feet, very personable, and could keep up with anyone in a conversation. She also had Attention Deficit Hyper Activity Disorder. There were days you could feel the air vibrate around her. We did pair programming--where two developers sit together, one codes, and the other reviews and discusses the code as needed--and she would make them crazy sometimes; her attention was just not right there.

So I put her on bug fixes (no pair programming required on our team for those) and people management; she could entertain our client like nobody's business. Fast on her mental feet (as well as her physical ones), these were activities she could grasp and transition between repeatedly and easily, and we could get the best possible work out of her. On days when she'd hyperfocus--another issue that happens with ADHD and ADD--we'd give her new features to investigate, because I knew she wouldn't miss a damn thing.

Most people who have issues in a group, or who have not been very team oriented, are well aware of the problem. When given the choice, most people do not want to suck at anything. So, the theory in this blog post is, you can't control the things they suck at, but you can give them opportunities to do the things they don't suck at.

Where before that lovely lady had had problems on other teams, she flourished on mine. I adore her to this day.

I had another guy, in the same group, who came across as tyrannical, set-in-his-ways and a lecturer. There was not a fight he couldn't pick. So I turned that to my advantage: having had some problems with the team working parallel to ours not always being helpful, I put him in charge of team relations (they were already bad, what worse could happen?). Turns out his tenaciousness and stubbornness paid off...when aimed at someone else. The initial successes brought some actual admiration from the team that was previously planning terrible things involving boards with nails in them and the back parking lot. He thrived under the positive attention, and was able to start--gasp--not arguing with the team. When we talked to him about how much he knew (which was substantial) and that he could teach it, rather than lecture it, he fell in love. And the team benefited.

Not all stories of putting people in positions to do what they're good at end quite as "after school special" as these did, but they always improve the situation with potentially problematic people. Always.

When I was in high school, the one and only retail job I ever got was in a toy store. I have, shall we say, utterly crappy spacial analysis skills. The assistant manager assigned me to the "games" row, considered the hardest to organize (rows upon rows of boxes seemingly randomly shoved into the shelf as many as could go) and required a ton of my spacial abilities (which I had, really none). Night after night he'd keep me there working that same row, and keep all the other employees, assuming that repetition and peer pressure punishment of making me do what I wasn't good at would somehow magically make me better. I'm sure for some people that worked. It didn't work for me. My father got tired of waiting in the car until well after midnight for me to come home and told me I had to quit. I have never been happier. The next job I got was data entry...people, I can type. I was also not afraid of computers. The difference was night and day; my whole demeanor changed. Where my old teammates hated me (I was the reason they were all staying an extra hour and not getting paid for it), my new ones loved me. Who knew typing 70 words per minute could make you feel like a rock star?

Reassigning that individual to a task that he/she is better equipped to succeed at also helps your entire team. If they are no longer suffering the pain of that person suffering through what they suck at (ie: my poor teammates at the toy store watching with mute horror as I tried and failed to put back board games), their attitude and productivity also increases.

The gist is, people having a hard time are not really enjoying it anymore than you are. If you can talk to them and observe them, and find something (even just one thing) that they are good at, you can start the process of changing them from a drain on resources in your team, to a contributing member. Some get the opportunity for success, and fail. Then you know they truly don't belong. For most, however, they get the taste of success and never want to go back.