"You're Fired!" (How To Let People Go With Class)

Ouch! one of the worst parts about being an IT manager is when it comes time to fire someone. It really doesn't matter if the person truly deserves it or this is one of those "cut 10% from every department" exercises. Handling the situation where staff decides to leave by themselves is hard enough, this just makes a manager's life that much more complicated. Some companies have training for their IT managers on how to handle this part of their job correctly; however, most just leave it up to the individual managers to learn how to do it over time.

If we can agree that there is no easy way to turn somebody that you work with's life upside down, then at least we can take a moment and talk about a few guidelines for how you can terminate people with some measure of class for both you and them.

• Best Time To Fire Someone: hands down it's best done at the end of the day. Most often the person is going to be in shock and will need time alone to deal with what has just happened to them. Going home is better than sitting around at work. Additionally, if they need to clean out their desk, then they don't have to put up with EVERYONE dropping by to tell them how sorry they are for them / glad that it wasn't them.
  
  
• Have A Good Reason For The Firing: Being fired is hard enough for IT professionals, but not being given a reason for your termination seems to make it 10x worse. A weak excuse like "I was told to fire you" or something like that is no better having no good reason.
  
  
• Do The Firing Face-To-Face: The IT industry is full of really bad ways to fire people using technology. Bad examples include leaving voicemails telling people that they've been let go and sending termination notices out via email. As much as it hurts to deliver this news in person, it is really the right way to do it.
  

One of the best ways of thinking about why it's important to do a good job of firing people was said by Bob Wilson who is the Chief Human Resources Officer for Elliott Davis: "We never want to lose sight of the fact that the person is forever an alumni." Amen to that brother.


Tags: attrition, downsizing, firing, job loss, rightsizing, termination

Employee Motivation: What To Do When You Feel Passed Over

I recently had a chance to talk with a friend of mine who works as a developer in the information technology department for a major telecommunications firm. I was surprised to discover that he was very angry and was thinking about quitting his job. It turns out that he had just completed a major project. He and two others had put in those non-stop 60-70 hour days. He had been away from home for the better part of two months and he was very proud of what was finally produced.

However, what had gotten him angry was that two other individuals had joined the project late in the game, had not worked nearly as hard as the core group of three had, and in the end they not only got credit for the project's success, but they also got promotions while the core group of three were not promoted. Is is any wonder that my friend was so angry?

We spend a lot of time recruiting the best information technology employees and then we spend at least as much time worrying about employee motivation all too often only to end up with angry, bitter staff. In the case of my friend, what had gone wrong was instantly clear to me because I've done it to myself countless time. I call this situation, the "engineering field of dreams" problem.

Jobs in Information Technology allow us to focus on building things using only our minds and hands (for typing). As engineers we have a bad habit of completely focusing on solving the technical problem that we've been assigned and not lifting our heads up until we have a finished product. The problem with this is that we then expect the rest of the world to look at what we've made and realize what a great worker we are. In my case, I blame my Mom because whenever I took something that I had made to her she always reacted with joy and surprise and told me that it was the best thing that she had ever seen. Unfortunately, the rest of the world doesn't work that way.

So what should my friend have done? While he was working on the project he should have realized that he had another job to do at the same time. In IT management speak we'd call this an "overlay job". Every single day he needed to be managing his career -- thinking about what he needed to be doing in order to get recognized for what he was doing and get considered for a promotion the next time an opening showed up. You know what he said when I told him this: "Hey Jim, I just don't like to brag about myself!" Two quick replies to that: (1) if you don't, then who do you think will? and (2) bragging would be bad, informing others would be good.

I ended up having a very long talk with my friend; however, here is the gist of what we talked about. He needs to identify who he needs to make aware of his contributions (his boss, his bosses boss, and the bosses of any department that his project interfaces with). He needs to communicate with these people regularly (Monday, Wednesday, and Friday). Communicating does not mean sending them mindless status reports. He needs to send brief, concise emails that provide valuable information such as "We had a problem, but here is how we solved it..." When he sends an email to these important people, he needs to address it to only them -- don't CC them or send it to a distro list. One-to-one sends a powerful message. Finally, he needs to do more than just send emails: he needs face time with the decision makers. I suggested that he use the excuse of "checking to make sure that you agree with the decisions that we've made" line to set up a meeting.

So remember: you are in charge of your career and nobody else. As technical professionals we all suffer from a "love my work, love me" syndrome and we need to do a better job of communicating with those in charge in order to move our career along.

IT Employee Motivation: Fixes Are More Important Than Problems

The engineer in all of us can rise up and take over whenever a problem shows up. In the world of information technology, when either ourselves or one of our staff screw up, personnel issues can get shoved aside as we focus on finding a solution to the problem at hand. However, if you can take a step back for just a moment, you'll find that this is a rare opportunity to define your career. In this day and age in which IT employee retention is so important, the ability to pause can be critical.

We all make mistakes and the same goes for those who either work for us or work on our team. When somebody really makes a mistake, the whole world seems to come to a screeching halt when both the problem and the person who caused it are finally identified. What you do next will define how everything turns out. You've got a bunch of options:

• Don't Go Bi-Polar: All of us tend to favor an extream reaction when we realize that a mistake has happened. Either we blow our top and insist that someone else is responsible or we get very embarassed and think "Oh no, I really screwed up this time." Both reactions are the wrong response -- instead, take a step back to evaluate the situation and keep calm even if that is the hardest thing in the world to do.
  
  
• Plan, Plan, Plan: don't ignore the problem. And yes, you should probably tell your boss about it so that he hears it from you and not someone else. Be sure that you accept responsibility (I mean, what else can you do?) and make sure that you have a plan for what to do next BEFORE you tell him.
  
  
• Don't Point Fingers of Blame: Focus on finding a solution to the problem instead of focusing on the source of the problem. One key aspect of IT jobs is that we seem remember and reward the heroes who fix problems and we rarely seem to remember how the problems happened in the first place. This is your time to shine!
  
  
• Find A Problem Mentor: If ever there was a time in your career to find someone to talk to about your situation this is it. Keep in mind that they may not be in your office and may not even work for your company. Find them, explain the situation, and seek their guidance as to what you should be doing next.
  
  
• Say That You Are Sorry: Amazingly enough, this may be the perfect time for you to simply say "I'm sorry". A sincere apology may be the hardest thing in the world for you to do; however, it may act like a sudden rain storm over a forest fire. If an apology is not appropriate or needed, then at least state how you feel "This is a bad situation and I'd like to help correct it" and then move on.
  

We have all made mistakes in our career and we will probably make even bigger ones as we move forward. However, it's how we react to these mistakes that really defines who we are.


Tags: apology, calm, career, mentor, mistake, plan

Motivation For Your Team Provided By MIT's Sloan School of Managment

What if...you could somehow find the time to fly out to Boston and take two days to attend the MIT Sloan School of Management's course on "Managing Technical Professionals and Organizations"? This course is designed for "senior management" but no matter what your title is, you've got my permission to attend. Umm, I guess there are the separate issues related to travel to Boston for your two days of training and, of course, the fee for taking the class ($2,600). Dang -- those restrictions just about put this opportunity out of reach.

Those of us who work in the Information Technology field need more of that: information. I've secretly obtained information on this MIT Sloan course and, for free, I'm going to share it with you. Please feel free to share it with your team.

If you took the course, what would you hope to get out of it? How about:

1. Learn ways to avoid turning the organization into a parking lot for bright folks whose abilities to generate new ideas far outstrip the ability of your organization to do anything with them.
   
   
2. Get a hand on how to manage functional relationships between different functions within your company including research, development, marketing, engineering, manufacturing, and, of course, finance.
   
   
3. Identify and find ways to reward those individuals who act as gatekeepers and yet who are able to break down internal barriers and help to promote technology transfers.
   

Sound like a good set of goals? Great -- lets take a look at the four sections of the course and what you'd cover in them:

• Making Technical Organizations Work: On Corporate Culture, Technology Transfer, and Effective Reward Systems.
  During this section, you'd learn from the rest of the class that their companies are just as screwed up as yours is. The classic problem of different departments not wanting to share information would be discussed. The solution to this would be presented as finding information "gatekeepers" and convincing them to allow information to flow more freely between departments. Once this was solved, you'd talk about the sticky problem of how to reward technical professionals. You'd discuss the "technical" ladder approach and would agree with the rest of the class that it doesn't always work well. The class would brainstorm on ways to provide technical professionals with increasing challenges in the workplace without trapping them in obsolescence.
  
  
• Managing Performance and Productivity In Technical Organizations:
  This time around you'll be spending your class time talking about motivation and how employee motivation is the key to a successful technical team. A great deal of time will be spent on helping the team deal with uncertainty and the stress that it causes. Finally, you'd work with your classmates to find ways to integrate your technical professionals in with the rest of the company (can anyone say alignment?).
  
  
• Sustaining Innovation and High Performance:
  We're all familiar with this issue -- how do you manage star IT individual contributors? You'd talk about how you can move star performers into management roles and what kind of training they are going to need for these new roles. The key issue of how to teach them not to be a "scary" manager due to their deep knowledge will be covered. We'll wrap this section up with a discussion of how to keep that "creative tension" alive in the team in order to maximize everyone's productivity.
  
  
• Structuring The Technical Organization:
  Welcome to the world of organizational behavior! You'll be told that the matrix approach to management is the best approach for managing technical professionals on projects. Your two days of classes will wrap up with a discussion of the physical structure of the workplace -- where we work has a big impact on how we work.
  
  

There you go! You've just successfully completed your MIT Sloan class and you still have $2,600 in your pocket. You might complain that this was just an overview and you'd get more out of the real class. I think that you'd be correct; however, how much of the class would you remember a month later, a year later, etc? The nice thing about blogs like this one is that, you can always come back and take this class again -- for free!


Tags: course, MIT, Sloan School of Management, technical professional

But I Don't WANT To Work With You!

In the April edition of the Communications of the ACM, Peter Dennine and Peter Yaholkovsky discuss an interesting topic: just how do you get a group of people to stop thinking about "me" and start thinking about "we"? They are talking in broad generalities; however, it did get me thinking about how this can be accomplished in IT departments & teams.

Messes are defined as large, complex, problems that appear at first glance to be unsolvable. Really big messes have a special name: "wicked problems". Peter & Peter point out that the only way to solve problems like this is through the use of collaboration. Collaboration is defined as a working together synergistically. Here in the 21st century, this should be easy to do, right? We've got blogs that talk about important things, wikis, IM, and cell phones. How hard could this be?

Well, it turns out to be quite hard. Most of the collaboration tools that we have turn out to be pretty poor at enabling collaboration. Things got even more complicated when researchers did some testing and found out that you and I don't really like to collaborate. When we are working on a wicked problem in a group setting, we first like to use authoritarianism, then competition, then finally collaboration. Researcher Nancy Roberts says it best when she said "People fail into collaboration." So why do we do this? Two guesses: first, we seem to think that we can win in every negotiation by standing our ground. Secondly, we have a hero culture - we look for a hero to arise and solve the problem. If they solve it, they'll get the credit so why make the effort because you're not going to get any credit.

In IT we seem to encounter more than our fair share of "wicked problems". What can we do to encourage collaboration within IT teams when our very nature resists it? If we adopt a three stage process for dealing with wicked problems, we can solve them together: design, collaborate, and follow-through. The design stage simply requires us to identify all of the affected parties and what questions that they need to answer. Hosting a meeting where a moderator leads the team through a series of follow-through steps can cause collaboration to occur. Basically, you want to state the problem, have everyone discuss it, have folks start to throw out ideas, and then when people start to refine the ideas offered by others, that's when you'll see the real collaboration start to happen.

The authors finish up by asking one last intriguing question: how far up can you scale this approach to solving wicked problems? They've shown that it can work in groups of 50-200 people. The open question is if it can be scaled up beyond that. From an IT perspective, it doesn't matter because that size works well with departments or specific project teams.

In the end, collaboration happens when a team or department comes together to create a solution to a wicked problem that takes care of everyone's concerns at the same time. It sure sounds like we should be trying to make this happen just a little bit more often!


Tags: authoritarianism, collaboration, competition, problem solving

Take Your Pick: Task Or Time?

As we reach the end of the first decade of the new millennium, the IT workplace is once again starting to change. For at least the next few years we're going to be seeing three distinct generations working together side-by-side: boomers (born before 1965), Gen-X'ers (1965-1979), and Gen-Y'ers (1980-1999). This arrangement causes conflicts and friction in all parts of a company; however, the IT department feels it the most because of the rapid changes that have happened in IT.

In order to keep an entire IT department staffed and motivated (and avoid having unhappy IT workers), things are going to have to change. One key change is going to be how we all think about IT jobs. In the immediate past, IT jobs were simply 40-hour-a-week commitments that pretty much started and ended at the same time each day. We might work different shifts; however, the company was fairly insistent that we show up and put our time in. All sorts of tools were created around this structure: time clocks, time sheets, overtime, comp-time, etc. Things are changing now and it's because Gen-Y has arrived in the work place.

The Gen-Y crowd clearly prefer jobs that are defined by their task, not the amount of time that they take. This of course means that they want to be compensated for what they produce. In a way this is sort of a step backwards. Back when everyone worked on a farm or in the early days of factories, people were paid based on their personal output. This had its pluses and minuses and after the Great Depression when manufacturing got more complicated and unions arrived, the shift to paying by the hour started.

Younger workers are used to working in an asynchronous fashion -- something that older workers may do also, but they hid it better. Getting into the office by 8am or staying at the office until 5pm makes little or no sense to younger workers if they have completed their work.

You can call task based work whatever you choose ("virtual work" seems to be winning), but by necessarily text="Virtual Work" it is catching on. At IBM, 40% of their employees have no official offices. So what does all of this change mean for those who are in charge of making sure that a multi-generational IT department produces results? Here are the three key skills that will need to be mastered:

1. Clearly articulate the results that you expect -- leave no room for misunderstanding. Then follow up by tying accountability to getting the job done.
   
   
2. Make physical attendance at the office / meetings optional. Note that everyone still needs to show up for meetings and communicate with team members.
   
   
3. Gage worker performance on the quality of the work performed.
   
   

What can you expect to gain from making these changes? Best Buy has implemented many of them and they claim to have seen a 35% increase in productivity and voluntary turnover drop by 320 basis points. What's even more remarkable is that when asked, employees were unsure if they were now working more or fewer hours -- they had simply stopped keeping track.


Tags: 40 hour week, productivity, quality, work task, work time

Q: What's Worse Then An Unhappy Worker Leaving? A: If They Stay...

We all know that having high turnover can at best be disruptive and at worst can throw projects off schedule, kill budgets, and doom overall employee morale. So you would think that if you are somehow able to have a low number of employees leaving that everything would be hunky dory, right? Wrong -- you might now have lots of unhappy employees who have for one reason or another decided that they can't leave right now. They'll keep coming into work each day (or logging on if they are unhappily telecommuting), but they will be dragging their virtual feet and just going through the motions. They are not going to be helping the company be a success.

Why are so many non-leaving employees unhappy? I think that I know the reason and the author Patrick Lencioni has captured them quite nicely in his book "The Three Signs of a Miserable Job". In his book, Patrick states that he believes that people become unhappy in their jobs when their basic social needs are not being met. Yeah, yeah, yeah -- we all love a paycheck and the bigger the better. However, we really go to work in order to have some very basic human needs met: to get a sense of accomplishment, to boost self-esteem, and to feel that we are part of a community.

When we aren't geting these needs met, Patrick calls the problems "anonymity, irrelevance, and immeasurability". Great, now you've got the silent problem of unhappy IT workers lurking in your department. What to do?

Don't dispair! In order to reach out and change unhappy workers into committed employees you have to tackle these key issues one by one. One-on-one feedback is the key to providing emplyees with both a sense of accomplishment (they know who I am!) and boosting self-esteem (they like what I do!). Developing a sense of community is somewhat more difficult -- in the IT field if this is done incorrectly, it can come across as fake. However, if done correctly you can turn a lackluster department into a team of overachievers. Now that's something to cheer about!


Tags: community, motivation, self-esteem, sense of accomplishment