MOTIVATING YOUR TECHNICAL STAFF 31

[NAP1214]

FIRST OF ALL CONSTANT PRAISE FOR A JOB WELL DONE IS GOOD!&nbsp;&nbsp;ALSO, STRESS HOW IMPORTANT THERE JOB/POSITION IS WITHIN THE ORGANIZATION AND THE IMPORTANCE OF OPEN COMMUNICATION BETWEEN END-USERS, TECHNICAL TEAM AND MANGER/SUPERVISOR STAFF.<br><br>IT'S JUST LIKE BELONGING TO A SPORTS TEAM NO ONE PERSON CAN FUNCTION WITHOUT THE CORPORATION OF THE OTHER TEAMMATE.&nbsp;&nbsp;EVERYONE HAS A PART TO PLAY AND THE JOB CAN GET DONE IF EVERYONE IS ON THE SAME TEAM AND GOALS ARE GENUINELY THE SAME.<br><br>(COOPERATION/COMMUNICATION PLAYS A BIG ROLE!!!)<br><br>ALSO, INDICATE THAT SOMETIMES MISTAKES HAPPEN AND NOT TO BE AFRAID TO MAKE A MISTAKE.&nbsp;&nbsp;BUT MOST OF ALL NEVER BE AFRAID TO ASK A QUESTION OR TO SIGNAL WHEN YOU NEED A HELPING HAND.<br><br>THAT'S MY ADVISE FOR HOW TO MOTIVATE MY TECHNICAL STAFF! <p> SHERRY MCKEOWN<br><a href=mailto:NAPHIRA@AOL.COM>NAPHIRA@AOL.COM</a><br><a href= > </a><br>

 

[Voyager1]

Madorney writes: &quot;First, unless the pay is grossly out of line, nobody leaves for more money.&quot; Oh, please - this is the most common reason for changing employers. I've seen people bail for $1,000/year...

Also &quot;Fourth, techies want training - if you don't offer it, at least give time off for it (most training is available cheap).&quot; - Define &quot;cheap&quot;. Most training that will really benefit someone will cost upwards of $1,000 a week. If that's &quot;cheap&quot; then I'm not doing as well as I thought.

Great thread - ;-)
- Bill

&quot;You can get anything you want out of life, if you'll just help enough other people get what they want&quot; - Zig Ziglar

 

[fasttoon]

I think the most important thing is communications and training.

Review everyones work and have praises for them on a job well done for only those areas that were well done, get employees feedback on areas that need work and help them figure it out.

Set a regular meeting once a week to review the past weeks activities, problems and how they overcame it or if still ongoing this is the time to brainstorm, if it was resolved then everyone will know how to handle it in the future. Also this gives everyone a chance to participate and show their stuff. Really motivates people and shows who are the potential leaders, teachers, innovators, etc. This is the time to do a quick check on what else needs to be done on current projects. The 5 M's work here (money, manpower, management, materials, methods) and which is needed at this time and in the future.

 

[ljzman]

To be quite honest with you all... I think all these are good ideas, but I have found it most rewarding to motivate an IT Department is to follow these simple management rules:

1. Leave them alone. The only real motivator is not having them put up with stupid little &quot;GO TEAM!&quot; signs, and getting them the tools they need to do their job instead. Let them do their job, and kick them back into play when they mess up.

2. ALWAYS be there to bail them out of a jam. When they call and say they can't get it working, tell them there is no doubt they WILL get it working and this is how to do it, or here's the resources that can help. Always have resources for them. Always be ready to fix anything your techs can't fix, and don't expect your techs to fix something you don't have the guts to try to fix yourself.

3. Follow the basic rules of command, passed down for centuries:

a. Don't mess with their food.
b. Don't mess with their family.
c. Don't mess with their pay.

4. Always reassure them. No matter how bad it is, everyday tell them there is a &quot;method to the madness&quot;.

5. Keep new techs as far away from the accounting department as much as possible, because all the intra-political gossip will drive them down and they will be eaten alive.

Follow those rules, and morale should never sink too far...



Lance Johnson

 

[SteveTheGeek]

>>4. Always reassure them. No matter how bad it is, everyday tell them there is a &quot;method to the madness&quot;.

>>5. Keep new techs as far away from the accounting department as much as possible, because all the intra-political gossip will drive them down and they will be eaten alive.

Hmmm... With #4 you run the risk of them not listening to you anymore - &quot;We know the VP screwed up and yet boss is painting this as rosy?&quot; There's a fine-line difference between staying positive and being unrealistically optimistic, IMHO. With #5, it may be specific to your company. I've seen where the techs and accounting folks be really tight, and it helped enormously because each gained an appreciation for the others' job.
-Steve

 

[aphillips]

There are some very good ideas here (and a few more of my own below), but it is very important to remember that people aren't stupid. If you do any of the above and people suspect your motives it will have no effect or even a negative effect. Are you reading this to find better ways to exploit your staff?

A manager's role is to do all he/she can to help staff to do their best work. It is not to find the best techniques to manipulate staff and make money.

Here are a few more tips:

1. Never react badly to a problem. (Instead treat problems as a challenge to improve your procedures.) Staff will stop telling you what's happening, and either things will start taking a lot longer than they should for no apparent reason, or you will eventually find out when the problem has escalated to a disaster.

2. Never play staff of against each other (or unintentionally appear to). For example, &quot;Anthony gets to work 2 hours before you&quot; or &quot;Paul could have done that in half the time&quot;. This works against teamwork by building resentment. People also waste time trying to prove their relative worth rather than doing their job.

3. Empower people. For example, give an individual or a team total responsibility for a project. This includes analysis, design, and even testing. &quot;Ownership&quot; is a great motivator.

4. Promote awareness of the customer/user of the software. Nothing motivates most developers than knowing that other people use and enjoy using the software that they create. You could even let them talk to real users!

5. Don't believe people who tell you that the developers are not the best testers. The people who created the software know intimately how it works and should be able to figure out all the myriad ways it can go wrong. If you use point 3 above then they should be keen to fnd the bugs. A great demotivator is to be part of a testing (or so-called QA) team. Separate testing teams should be banned.

6. As mentioned before, meetings can be a motivator. It helps people feel they are part of a team working towards a common goal. Code review meetings, done properly, can not only produce a better product but build teamwork and motivation. (Done wrong they can be a disaster.)

7. React quickly to fix any complaint, esp. if valid. Even fixing something that you think is OK anyway is a good idea.

8. If something goes wrong blame yourself. When things go right congratulate your staff.

9. Never make anyone feel stupid, even as a joke. Always assume they know more about how to do their job than you do (they probably do).

 

[garwain]

>5. Don't believe people who tell you that the developers >are not the best testers. The people who created the >software know intimately how it works and should be able >to figure out all the myriad ways it can go wrong. If you >use point 3 above then they should be keen to fnd the >bugs. A great demotivator is to be part of a testing (or >so-called QA) team. Separate testing teams should be >banned.

I will have to disagree. I'm working on specialized software, and I can test the functions to see that they produce the right answers with any given input I can think of, but I don't have a full understanding of the buisness that the software is developed for, so I have to rely on a 2nd group to do the testing to verify that everything works properly in a production environment.

A QA team that is just going to test each component of the system to verify that it works is no better than the programmers testing it, but when you have a group of people who work in the domain that the software is designed for, testing the software, they will be able to use real-life situations to test with. This will allow them to find bugs and design flaws that the programmer, or a internal QA department would never have seen.

I'm lucky that my software is for internal use by the company so it is the users who do the testing. I'll usually release a new version and then within the next week or 2 I'll have to release several minor versions with bug fixes and cosmetic changes that will allow the program to be useful in the production environment. No matter how much I test the software my lack of knowedge in the domain makes the users the best testers. I can give them a working program, they can help me make it a solid program.

 

[aphillips]

> I have to disagree. ... I have to rely on a 2nd group
> to do the testing to verify that everything works
> properly in a production environment.

You are absolutely right. The point I was getting at was that you often get an organisation where some, usually novice, programmers get relegated to testing and debugging. To them just working on these tasks can be extremely demotivating and demoralising.

The real problem is that the original designers/coders are too lazy or unmotivated to test the code properly, or better yet GET IT RIGHT IN THE FIRST PLACE. The argument is that they have &quot;mental blocks&quot; in some areas which cause them to introduce the bug and not to be able to see it when testing. But they are really the ones who understand the internal design and so are the best at being able to see where something might go wrong and working out the reason when a bug is found.

 

[DonQuichote]

There are two kinds of testing:

Unit testing: testing if a procedure has the right behaviour: gives the right answers to some defined input and also fails if it has to.

Functional testing: testing if the program as a whole works

Now, unit testing should ideally have to be done by the developers themselves. If they do not know the business background of their own program, than there is a major communication failure and their job just cannot be done.

Functional testing should ideally be done by someone else (just to have a fresh mind), preferably a customer on the programmers's site.

See also

http://www.extremeprogramming.org/

 

[WebbWill]

WOW,
I see some really great ideas and practices being used to motivate and inspire.
I wished I worked for someone that had these skills.
I am going to email a link to my boss and mark it as suggested reading.
Maybe the ideas will be put to use here.
We are told that we can all be easily replaced.
There is nothing special about what we do, any fool could accomplish our tasks. Then the fools that try have us clean up the mess they create, and cover the mistake so people don't know of it.

 

[shelron]

Many valuable contributions here. My experience has revealed the following:

People are people whether they are techies, iron workers or soldiers. They all have common and individual needs. A clear division among people is those that are leaders and those which prefer to follow.

People that are not leaders wish to be led, not managed. People want to be contributing members of a team that is reaching worthy goals. Lifes sucesses are usually measured against ones personal and professional acomplishments. Afterall, once a goal is reached, it is a fulfilling feeling for only a brief time, the human spirit must always strive for more.

I have found success by applying the following pricipals:

1) Know and care about your people. (This is probably 50% of the whole) If you REALY care it shows and is appreciated. (I don't mean &quot;be their buddy&quot Employees have friends, they don't need their boss as one.

2) Have a clear mission/objective.

3) Make sure people understand number 3 and their role in reaching the objective.

4) Solicit and consider your peoples opinions. Carefully weigh the probable impacts to the mission AND clearly state why they will work, or not work. (There can only be one leader, I have found that most people will react positivly if it is clear why an idea does not fit)

4) Have the stones to say NO. Don't let issues fester. Their can only be one leader. If a decision has been made, go with it, nothing has a more negative effect on an organization than indecision.

5) Be consistent.

6) Provide all the resources available.

7) Fight for what is right.

8) Respect everyone.

9) Provide a good working environment.

10) If there is trouble in the ranks, weed it out.

Ron

 

[chogben]

Give your staff the business problem, don't just give them your design and assume it's right. Give them the problem and let them figure out how to solve it. Most IT people (the better ones, anyway) like to solve problems.

Going back to training. Give them brouchures, let them choose their training...

 

[johnny99]

Chogben you are right.
I most cases I always tell my people what the business need it for. They need to know the WHY not the HOW to do things.
The HOW is there business.
Some times I change the HOW because they don't always think about the money (a 155 Mbit/s internet connection sometimes pops up)

/johnny

 

[grtammi]

My 2 cents worth ...

I've found that the best way to motivate my staff, as well as gain ultimate respect for my position, is to ...

NOT SWEAT THE SMALL STUFF !!!!!

My other tip: Everytime you see someone make an error (or what you think is an error), think of something positive that that person does - this way, you end up focusing on the positive qualities of that person, and not the negatives (which is the human condition).


Here's 2 more cents ...

Which scenario is more appealing?

a) Job paying $30k per year, with a great boss who treats
you with respect and makes you feel great about yourself

... OR ...

b) Job paying $60k per year, with a boss that makes you
feel like @#$@$# and you hate going to work everyday?

Greg

PS: This thread is great - I should make a printout and put this on the bulletin board for EVERYONE ...

 

[SCPCGuy]

Many good comments above, so I won't attempt to add too much:
1) Make sure you have good lines of communication with your staff--two way lines, so you know what they're up to, and they know what you're doing (i.e., no installing a major upgrade without telling your help desk staff, who then have no idea what to do when users call)
2) Make sure you praise your staff, genuinely but often, and PAY them in accordance with their performance; don't praise but pay poorly, or pay well but never praise. People need both praise and pay commensurate with performance.

 

[johnny99]

I think SCPCGuy is right, but I also tell my people when they do something that I think they did wrong or could do better.
And I know that this is also very importend to them that they know when there are things I don't like.

/johnny

 

[nkulsh]

This topic is so dear to my heart that I can go on and on talking about it. But I would be repeating what most of you have already said. &quot;Retention&quot; is basically dependent on a few important factors...( let me use some real life examples to emphasis what I need to convey)

On a visit to a foot wear factory in Japan, a gentle man was extremely suprised when the official taking him on a tour of the factory started apologizing for the inconvieneance caused to the gentle man due to the cat strike called by the employees. What suprised the gentleman was the fact that he could see that all the employees were working even though they had declared a cat strike. He enquired about the same with the union leader whose answer is history today ( as a important quote in the best MBA programs worldwide)...he said , If you notice that we are only making the left foot of the footwear today. The day the management agrees to our demand we would make the right foot to complete the pair. Without the right part the pair is incomplete hence worthless to the employer, but just because we have a few issues with the management why should the company lose on it's productivity? Hence we are making the left foot only... This story explains the factor called ...BELONGING. It is very important to have your employee feel that he belongs, that he is a small but important part of a big family and is as important to the family as the other.

 

[JGirl]

The biggest things I can think of (as someone who just stopped working for a boss who seemed to get something out of making everyone as miserable as her) to keep your employees happy is to:

- give them the respect that they deserve,
- pay them what they deserve,
- treat them all fairly, and
- try and solve the real issues......
- dont make promises and not keep them

There is no point cracking down on 'female shoulders being exposed in the workplace, and types of acceptable footwear for an office environment' (yes, I am for real - we didnt even have any external clients ever coming into the office) when the department has much bigger issues with high staff turnover / excessive system downtime etc.

Also....avoid feeding your empolyees b/s about how things will change blah blah, if you arent prepared to actually go the distance and make the changes. There is a huge difference between talking about changing things and actually making the changes...after a while they get tired of hearing the same old stuff ('flavours of the month') and start doubting your ability as a manager.

Every time we asked for more money (people in similar jobs with other companies were earning up to $20,000 more) we got some spiel about what the company offered to us that other places couldnt....Things like ocean views.....Well, thats great if you are a manager and have a nice office to sit in all day and look out over the water, but no one else really cared - they were going there to work and get paid, not for the view.

Anyway, thats my 5 cents worth - better stop before I get all bitter and twisted.
J

PS...This forum is great....I needed to get some of you guys in as replacement bosses

 

[gurner]

This company is going a head with Citrix relling and installation, BUT only one engineer is going to be trained

and it isn't me

I've been told i can get a book and the company will pay for it.

You can't learn Citrix properly from a BOOK!

Just as much as you can't pass an XP MCP with just a book (which i didn't)

Looks like i am going to have to stay on this helpdesk bluffing my way through SQL (that book didn't help either)

Help, i want a company with imagination and drive, someone that understands the value of keeping thier engineers fully versed with the products they sell.

I was employed under the pretense that i would be a (currently unqualified but very good and soon to be hopefully qualified) site engineer (90% of this job so far has been helpdesk) been here a year now.

Just my rant!

 

[shelron]

Girth, my two cents:

Look with in for solutions.

Get the book and do the best you can while asking here for assistance.

Assess what you section needs are and provide remedies.
Managers usually welcome employees who can resolve problems with little assistance. Take what is given and maximize the return for your employer, and yourself.

Perform at the level you want to achieve; if the reward doesn't come in a timely fashion, try somewhere else.

Good luck, Ron

 

[flapeyre]

Girth:

You can't learn Citrix properly from a BOOK!

I agree. As one doctor put it, you can't learn to perform an appendectomy just by reviewing the procedure in Cutler's Atlas of Surgical Technique.

That applies to all applications (although some have a more steep learning curve than others).


&quot;When once you have tasted flight, you will forever walk the Earth with your eyes turned skyward, for here you have been, and there you will always long to return.&quot;

--Leonardo da Vinci