Posts Tagged ‘personnel’

How Can An IT Leader Change An Engineer Into A Team Player?

Monday, October 20th, 2008
IT Leaders Need To Be Able To Change Engineers Into Team Players

IT Leaders Need To Be Able To Change Engineers Into Team Players

At my core, I am an engineer. I recognize this, I accept this, I am proud of this. However, during my career many mentors have been kind enough to hold up that damning mirror of self-vision and have allowed me to see myself as I was: an engineer’s engineer. One key characteristic of this part of an engineer’s personality is that everything in the world is seen as falling into one of two buckets: right or wrong. Oh, and an another characteristic of the engineer’s personality is that we’ll have no problem speaking up and letting you know just exactly where we think something falls. That might be why an engineer’s life is so hard.

It took me 20+ years to develop a “wrapper” to put around my engineering personality. This wrapper helped my career progress, made difficult tasks much easier, and just all around simplified my life. I was reminded just how important this evolution of my personality was today when a younger version of myself asked to talk with me. He’s involved in the electrical power generation industry and he’s been having a tough time of it lately. He told me that he felt that he was just “banging his head against the wall” and that he was finding it really hard to get anything done at work. He described himself as a “guns ‘a blazing” sorta of guy who feared no conversation. Read this as classic engineer talk for “I’ll tell you when you’re wrong.” Clearly this was a social / political career crash that was just waiting to happen. What could I tell him that would help him to save himself?

The first thing that I realized is that I wasn’t going to be able to help him until he wanted to be helped. Right now he just wanted to complain about how wrong everyone else was. I let him vent for awhile and then asked him a few questions. It turns out that he’s had a number of projects (both work and social) that he’s been the leader for. In the past, a number of them have flat out failed. This is classic engineer talk: “they just didn’t get what I wanted them to do!” Recently he did organize a successful gathering and I probed to find out more about why that one worked. It turns out that others helped him out with that one. This was a bit of an eye opener – he had not realized that he had always failed when he tried to do everything by himself.

Next we talked about that whole “guns ‘a blazing” thing. He had just gotten off of a call that had started badly and he’d gone in shooting the meeting leader for not being clear about the purpose of the meeting. After he got a few shots off, he basically tuned out of the whole meeting. Clearly, this had been a showdown in the OK Corral that had turned out badly for everyone. My big challenge here was to find a way to make him see himself as the world sees him. My first try, “what do you think the other person though of you” didn’t go very far – he was too fixated on the fact that the other guy was “wrong” to consider this. I then asked him if the call had been successful – he admitted that it had not been. I then asked him that if it had been his assignment to make sure that the call was a success, while still playing the subordinate role that he had played, what would he have done differently? This question floored him. He didn’t have an answer – an engineer hates it when he doesn’t know the answer.

Having gotten his attention and partially getting him to understand that his actions had not moved the call closer to a successful ending, I then went in for the kill. I suggested that the only way to accomplish his goal of making sure that the call was successful, would have been to understand what the call leader was feeling and then persuade him to move in a direction that would make the call successful. My young friend considered this for a bit and agreed. Hey, it’s sorta like a control system problem back in school. I finished by pointing out the the “guns ‘a blazing” approach would never persuade anyone to move in the direction that you wanted them to move. He agreed. Now all I have to do is teach him how to be successful when interacting with others and I will have changed an engineer into a team player!

Do you have any classic engineering personalities on your team? Do they hurt your ability to solve team problems more than they help? What have you tried to get them to temper their engineering personality in order to create more teamwork? Has it worked? Leave a comment and let me know what you are thinking.

How An IT Leader Can Manage Competitive Arousal In Their Team

Wednesday, October 15th, 2008
Competition Can Change IT Workers Into Bad Decision Makers

Competition Can Change IT Workers Into Bad Decision Makers

It’s great to have an IT team that is full of go-getters. However, as with everything in life, sometimes teammates can be too competitive. When we let the heat of battle overcome our better judgement, then we’ve got a real problem. When this happens, we stand a very good chance of starting to make very bad decisions. Long after the competition has been resolved, we’ll still be living with the effects of those decisions and that can come back to haunt us over and over again.

Last time we discussed that rivalry, time pressure, and a bright spotlight of public attention can all contribute to making us become competitively arroused. This is how we start to make bad decisons. Given all of this, now lets spend some time talking about what can be done by IT leaders to manage competative arousal within their teams.

An IT leader can work to prevent problems by minimizing the potential for competitive arousal to occur in the first place by doing two things: avoiding the certain types of interaction that can lead to competition among teammates, and working to defuse the common risk factors that can lead to excessively competitive behavior.

In the first case, an IT leader needs to have the ability to think like a chess master and look into the future. He/she is looking to identify those interpersonal dynamic conditions that could lead to competitive arousal within their team. Once an IT leader has spotted these potentially volatile conditions, then they can step in and can work to restructure the deal making process into one that they believe will still lead to a successful outcome while not leading to a overly competitive situation.

Additionally, an IT leader needs to be constantly working to defuse the risk factors that may lead their teammates to enter into competitive arousal. There are three ways that this can be done:

  • Reduce Potential Rivalry: Luke Skywalker was motivated to overthrow the Empire at all costs because he saw it as being “evil”. When IT workers start to view rivals as being “bad”, or “evil” they can start to view winning as being required no matter what the cost. When this happens, the IT leader needs to identify who is feeling the greatest amount of rivalry and then limit their role. Another helpful approach is to do your homework before the competition begins. Clearly lay out how much you are willing to “lose” in order to “win”. Doing this before competitive arousal kicks in ensures a more rational decision will be reached.
  • Slow Down The Clock: In order to reduce the pressure that a ticking clock brings to the table, an IT leader needs to search for ways to stop the clock or at least to extend its window of time. Deadlines are almost always too short in which to complete the work. Extending or eliminating them is a key IT leader job.
  • Dimming The Public Spotlight: A great way to take the burden of meeting public expectations off the shoulder of individual IT staffers is to spread the decision making responsibility across multiple members. This isn’t a perfect solution, but it go a long way towards reducing the stress felt by individual team members.

Although it’s not often that the IT leader is the one who is getting caught up in a competitive situation, he/she does play a key role. The ability to anticipate that a member of the department is going to enter into a rivalry situation, come under time pressure, or get caught in a spotlight is part of an IT leader’s job. In the end, we all overestimate just how rational, careful, and even logical that we are in high pressure situation. It’s the role of an IT leader to save us from making bad decisions when we find ourselves there.

Have you ever had to diffuse a rivalry situation within your department? Did you see it before it became a problem or did you have to react after things started to get bad? Have you ever been able to remove a deadline that was causing your team to start to make bad decisions? Leave a comment and let me know what you are thinking.

IT Leaders Have Two Of These But Do They Use Them?

Wednesday, October 1st, 2008
You Should Be Listening Twice As Much As You Talk!

You Should Be Listening Twice As Much As You Talk!

About a year ago I had a chance to sit down with a member of an IT team that was working for me in order to have a heart-to-heart with him. We’ll call him Tim. Tim was a project manager on one of my teams and so far he had been a steady performer. I’d say that he was strong on the analytical side and soft on the interpersonal side; however, he was doing a good job and I had really had no complaints on his performance. Recently, things had changed with Tim. His whole demeanor had been transformed as a deep depression seemed to both surround him and flow off of him and onto anyone that he interacted with. It had gotten so bad that nobody really wanted to have anything to do with him. Clearly this was having an impact on his ability to do his job. It was time for me to step in and see what I could do.

I took Tim with me down to the cafeteria in order to get him into a neutral location. I started my conversation with him by explaining that I had been pleased with his work up until recently. I told him that it sure seemed like something had changed and I needed to find out what it was because things couldn’t continue like they were. Tim initially said exactly what you’d expect a guy to say: “Nothing’s wrong.” I thought about opening up on him with both barrels – look, he was doing a lousy job and he was going to be out the door if he didn’t shape up. However, I knew better and so I kept gently probing. Finally, Tim got around to saying “I hate my Director.” Once again, my gut reaction was to tell him “Too bad, he’s not leaving so you had better make some changes.” However, somehow I was able to hold my tongue and instead said the three most important words that an IT Leader can say “Tell Me More…”

Tim started telling me the standard things that everyone says about their boss behind their backs “He doesn’t give clear instructions, he changes his mind too often, he’s never around when I need to talk to him, etc.” This is regular stuff – not enough to cause such a change in personality. So I went on and said “What else has happened lately?” This finally got Tim to confess everything. In a staff meeting, his boss had found some errors in some slides that Tim had prepared showing the status of the project and had called him out on it in front of the rest of the department. Given Tim’s personality, this was just about the worst thing that anyone could do to him. He was wounded and still sulking several weeks after the event. Bingo! We had our smoking gun.

This was a problem that I could (and did) fix rather easily. That’s not the point of this posting. Rather, my first reactions as Tim’s story unfolded would have been the wrong ones to act on and if I had, then I would have ended up doing a great deal of damage and not fixing the problem. I guess that’s why we all have two ears and just one mouth.

David Benzel is an author and a speaker and he points out that as IT Leaders we all have four main responsibilities when it comes to communicating with our IT teams:

  1. To listen
  2. To get the facts
  3. To determine the problem
  4. To help resolve the situation

As hard as it is to do, listening is both an art and a science that all of us IT Leaders need to get better at doing. Listening is hard to do because it requires you to focus your attention and use your full brain to process what is being said – no multi-tasking allowed! By keeping your mouth shut and your ears open, you allow your staff to do the talking and when they do that, you will learn amazing things.

Have you ever been in a situation in which you spoke too soon without doing enough listening? What happened when you did this? Have you ever seen someone who was a good listener at work? How did people respond to them? Were they more or less effective at their jobs than their peers? Leave a comment and let me know what you are thinking.

4 Drivers Of Employee Motivation That All IT Leaders Must Know

Wednesday, September 24th, 2008
The Four Drivers Of IT Staff Motivation

The Four Drivers Of IT Staff Motivation

We’ve talked about the fact that sometimes employee motivation can be a lot like performing brain surgery – you’ve got to be careful or you’ll end up doing a lot of damage. If an IT manager can realize that their staff (indeed all humans) have four fundamental emotional drivers that need to be met, then they are well on their way to maximizing employee satisfaction and maximizing productivity. So what are these four drivers that we all respond to?

  • The Drive To Acquire: More! More! More! As human beings we are all programmed to go out and get scarce goods (iPhone?) that make us feel better about ourselves. I think that we can all agree that we feel “happy” when we are successful and we feel “sad” when we fail. It’s not just physical things that we desire, but also experiences and improvements in our social status. This drive is relative – we are always comparing what we have to what those around us have. Oh, and it’s insatiable – we always want more, more, more!
  • The Drive To Bond: We all know about how we bond with our parents, siblings, etc. However, the human creature is amazing because we have the additional ability to extend who we bond with to associations, organizations, and even countries. This is a big one – when we are successful in bonding, then we fell loved. When we are not successful in bonding, then we fell loneliness. For your IT workers, bonding at work is a critical part of who they are. When staff feel proud to be part of an organization (Starbucks?) this can be a big boost to their motivation. It also explains why we get so depressed when we get fired or laid off – we feel that the organization has betrayed us.
  • The Drive To Comprehend: We are creatures that really want to understand the world in which we live. We are constantly using scientific, cultural, and even religious theories to try to make sense of it all. Our reason for doing this is that we want to be able to come up with reasonable responses to things that happen in our environment and to be able to determine what actions we should take next.
  • The Drive To Defend: You knew that this one had to be on the list! When external threats show up, we humans naturally defend ourselves, our family & friends, our property and things, etc. Remember that “flight or flight” thing? Fulfilling this drive leads employees to feel secure, failing to fulfill it leads to strong emotions like fear and resentment. This drive is one reason why mergers or buyouts can be so devastating for staff.

Now that you know what the four drivers of your staff are, the big question is how can you use these drivers to make sure that they are motivated to work hard. We’ll talk about that next time…

How many of these drivers do you see driving your own behaviors? Which one do you think is strongest in you? When managing a team, have you come up with ways to make sure that these drivers are being satisfied? Leave me a comment and let me know what you are thinking!

The Meaning Of (IT) Life

Tuesday, May 13th, 2008

Why Do We Like IT WorkBy Dr. Jim Anderson

Most IT jobs consist of doing work in a constantly reoccurring cycle: define, design, create, test, deploy, repeat. When we get our first IT job or when we jump onto a new program, this can all seem so very new and exciting. However, once we reach the fourth or fifth cycle, it all starts to see the same. We also start to ask the BIG question: why am I doing this and does anyone really care?

Ultimately this is THE BIG question. I know that I have grown bored with my IT jobs once they seemed to be repeating themselves. An interesting point to understand here is that just when I became most valuable to my employer, I was no longer interested in doing the job. If you’ve got a team working for you, this is going to be a big problem for you too.

There are two ways to deal with this type of “IT job cycle” burnout that actually work. The first is to have a manager who is a real leader. The phrase that we always used was “I’d crawl over broken glass for him.” These folks are very rare, but you’d recognize them by the fanatical loyalty that they create in their teams. The few times that I’ve had such a boss, I really felt that he “had my back” and I worked hard to make sure that “I had his back.” He was able to convey to me a real sense of purpose that was much larger than the current development cycle that I was working on. I truly felt that I was part of a team.

Alternatively, since such leaders are few and far between, if each member of your team is working on a longer term self improvement project then they will also be able to see beyond the current development cycle. This can be as simple as going back to school, getting some flavor of Cisco certification, or simply tutoring under your project’s DB Master. Because of the desire to improve our technical knowledge that is our core, the ability to have this longer term goal makes us happier living in the here an now.

In the end, I guess that once you become aware that you are working in a never ending development cycle, you will become dissatisfied. However, if you can provide yourself or your team with a goal that is longer term than your current development cycle, then you can create stability and retention within your team.