A lot - maybe most - of my work for companies has to do with “remedial” coaching. In HR-speak, this translates to something like, ” He/she was really good for a while; but now they just aren’t performing at the level we need. If they can’t get back in the game, we probably won’t be able to keep them. We want you to help them to get re-engaged.”
Occasionally, I am also asked to work with stellar performers to help them move up the ladder more quickly. But those situations are few and far between. I think this simple fact says a lot about most organizations and their management styles. And what it says is important…..
See if this next sound bite sounds familiar - you may have had it said to you; or you may have said it to a member of your own team:
” (Insert name here), you’re doing a great job! We’re very impressed with the way you get things done; and to show you that we think you’ve got real potential, we’re going to let you take over a bigger responsibility. You’ve shown us you have the skill, talent and dedication to move forward in this organization and we like that. So, here you go - more people working under you (or more job scope, or more dollars in a bigger budget, or more whatever). We’re going to keep an eye on you (insert name again) and if you perform like we think you’re gonna; we’ll keep giving you more responsibility. Everyone will see that you are a key player.”
In most cases, the person who was given this new extra responsibility is very happy with the verbal pat on the head and moves into her or his new role with great enthusiasm.
Often, they continue to excel and the boss sees this. And then to show appreciation, the boss gives the high performing person another level of responsibility or a promotion. And both sides feel good again. But this is where things may get a little sour.
Some people refer to what happens next as The Peter Principle in action. If you’re not familiar with the term it’s from Dr. Laurence Peter, who said back in 1968 that “..every employee tends to rise to his level of incompetence.” Peter intended it to explain the upward, downward, and lateral movement of personnel within a hierarchically organized system of ranks. You have probably seen this occur - may have had it in your own career. This is when the HR department calls on a success coach to help “fix” the situation.
I don’t think Peter’s concept was exactly sound however because it contends that the team player was responsible for the poor outcome. I believe that the manager is the one responsible for the situation when the team member started to fail.
Many managers do this when they should do precisely the opposite. They take their great players and burden them, little by little, until they finally go sour. They use the great ones to offset the weaknesses of other team members, picking up more work while the slackers or incompetents get away with doing less. Often what occurs is that the great ones end up working 10 or 12-hour days and the weak links in the chain get to work 8 or 9 hours because they have less to do.
Inadvertently, the stars get penalized for being stars!
What to do?
1. Re-think your use of talent. When you’ve got a great one under you; use them to help you run a better group.
2. Rather than job enlargement - go for job enrichment. Give them juicy-but-challenging special projects that will help develop new skills.
3. Or let them have the luxury of time to help you by studying and examining processes or tasks to determine how they can be improved.
4. Let them see that you value them by treating them special. They’ll perform with continually renewed enthusiasm which helps make you shine at the same time.
5. And when they need some help that you or others can’t provide, bring in others from the organization or even outsiders to mentor and coach them to help them grow even more quickly.
Your organization will gain a reputation as a place where people want to work. You will attract and retain the best available.
Showing posts with label Workforce Management. Show all posts
Showing posts with label Workforce Management. Show all posts
Tuesday, November 27, 2007
Thursday, November 15, 2007
Does seniority equal entitlement?
I was speaking with a colleague the other day about a recent reorganization we were aware of at another company that essentially replaced the head of a department with that person’s subordinate. My colleague noted that was a shame because the person demoted (he wasn’t let go) had seniority over the person who assumed his duties.
My reaction was “What does seniority have to do with the ability to manage effectively and drive a unit to success?” Seniority is one of those areas in work life that I am really torn on. I believe that hard work, commitment, and loyalty should be rewarded but longevity in a position is not necessarily proof of that. Because of poor management practices, there are times when a person with less than stellar performance remains around for a long time because she’s trouble and rather than deal with her, management passes her around. Over time this employee not only remains with the organization but often climbs the ladder as well!
I’m not implying that this was the case with the employee my colleague and I were speaking of, just that when you begin to talk about seniority, the waters can get muddy really fast.
There’s no doubt that an employee’s longevity in an organization can be beneficial. However, does being around a long time mean that one should be automatically promoted should the opportunity arise?
My answer is no. While I think it should play a factor in the decision making, I don’t believe it should be weighted so heavily as to make the outcome inevitable. I stand by the argument that the most qualified person for the position should be in the position - period. This is, of course, ignoring office politics (which is the elephant in the room that I am conveniently ignoring right now).
Those readers who are unionized are probably reading the above and having a conniption fit right about now. Organized labor is often heavily slanted towards seniority and one must “pay his dues” (no pun intended) before getting a shot at a promotion. Perhaps even more importantly, they place a great deal of emphasis on seniority when it comes to reductions in force, with a first-in, last-out type of mentality thta can result in less senior employees “bumped” out of their positions.
While I understand the safeguards this provides (it curtails management from cutting higher-wage employees and replacing them with lower-paid less senior employees), there’s an underlying unfairness in it all. Being someplace for a long time should not equate to entitlement at any level of the organization.
Having said all of the above, in a perfect world, the most qualified person for a position would fill a position when it becomes available. However we don’t live in that perfect world nor is determining who is best qualified anything close to an exact science. In fact, it’s closer to an art than a science.
Now, let’s talk about that elephant in the room. Politics can and does encompass everything from personal likes and dislikes, organizational power, organizational and personal values and beliefs, contracts, policy and procedures, just to name a few. These factors add to the complexity of the promotion/retention process. Seniority can and often does fall into the area of organizational and personal beliefs or explicit rules based on a contract.
If the rules are explicit regarding seniority, the process is simplified. But I’ll argue that the results are not optimal for the organization.
If the rules are not explicit, then the results vary and can lead to optimal hires for an organization or not, depending on the culture of the organization and the tendency for management to view seniority as an entitlement.
We’re all familiar with the Peter Principle, that people rise to their level of incompetence, is strongly rooted in promotion by seniority. Being around for a long time doesn’t necessarily equal being best qualified for a position. I will reiterate that there is some value in longevity, but it should not be over emphasized.
It’s a problem when employees who haven’t been “around long enough” are not even considered for a higher position.” That practice can be detrimental for the organization and demoralizing for staff. People don’t want to see someone get promoted who is less qualified than they are, no matter how long they’ve been with the organization.
Obviously this is not clear cut issue, but in the realm of management and leadership, longevity may or may not make you wise and it should not be a guarantee for promotion. Agree or disagree? Have you been passed over for promotion because someone more senior got the position and you felt better qualified? Let me know what you think.
Thursday, November 8, 2007
10 ways to make meetings more effective
“That meeting wasted my time.”How often have you made this statement? Like you, I’ve attended many unproductive meetings, but a recent one topped them all. I had been talking about my consulting and training work with an employee of a company in central New Jersey. Things had gotten to the point that, after receiving information about me, the person suggested that I come to his New Jersey office for a meeting he would set up that would include him and his boss, the director of a training program for new professional hires.
The day of the meeting came, and I made the two-hour drive to the New Jersey office. I met my contact, who brought me to a meeting room with two of his co-workers and his boss. Following our introductions, the boss asked me about the work I do, and I described it. After hearing it, the boss said, “I’m sorry, but that work isn’t in line with what we had in mind.”
What went through my mind at that moment is probably unprintable, but you get the idea. Of course, the trip proved to be a waste of time for me. However, maybe some good did come of it, because ironically, thinking back about it gave me the idea for this article.
The following tips, which apply both to attendees and the chair of the meeting, will help minimize the chances that you’ll be similarly aggravated.
The day of the meeting came, and I made the two-hour drive to the New Jersey office. I met my contact, who brought me to a meeting room with two of his co-workers and his boss. Following our introductions, the boss asked me about the work I do, and I described it. After hearing it, the boss said, “I’m sorry, but that work isn’t in line with what we had in mind.”
What went through my mind at that moment is probably unprintable, but you get the idea. Of course, the trip proved to be a waste of time for me. However, maybe some good did come of it, because ironically, thinking back about it gave me the idea for this article.
The following tips, which apply both to attendees and the chair of the meeting, will help minimize the chances that you’ll be similarly aggravated.
#1: Determine whether the meeting really is necessary
Does the meeting really need to occur? Do multiple people really need to interact with each other? Reducing the number of attendees saves time for everyone, both those in the meeting (because it probably will end sooner) and for those not attending (because they can do other things).
If the meeting involves a review of documents, status reports, or other material, sending them to attendees prior to the meeting saves time and might even make the meeting unnecessary. Consider my example of the New Jersey meeting: I wonder whether the boss had even reviewed my materials beforehand. Had she done so, or had she spoken to me by telephone, it would have saved time for everyone.
Even if you determine that a meeting is really necessary, does it have to be in person? Consider a telephone or video conference call, which can save time, money, and energy (and which is an option I should have considered for my New Jersey meeting).
#2: Be punctual
Have you ever been on time for a meeting and found that only about three-fourths of the attendees were present? Did the meeting leader say, “Well, let’s wait a few minutes for more people to arrive”? Think about the message that action sends. You, the person who showed up on time, are being penalized for doing so. The people who are late, conversely, are being told that their lateness has no consequences. How likely is it that you will be punctual to the next meeting this leader holds?
I’ve heard of companies that remove all extra chairs from the room once the meeting starts, forcing latecomers to stand. While that technique may be extreme, it does reflect the idea that peoples’ time should be respected.
In the same way, if you’re going to be late, try to let the meeting chair know in advance. Simply showing up late might send a message to the other attendees that to you, the meeting is unimportant.
If you’re the chair, try to end the meeting on time. Attendees have other commitments, and keeping them late is unfair to them and to the others with whom they have commitments. A friend blogged about how she hinted about the late running of a meeting, which was supposed to end at noon: Her stomach growled audibly at 12:05.
#3: Be wary of recapping for latecomers
On a related note, be careful about recapping a meeting for latecomers. By doing so, you are in effect starting the meeting over.
#4: Be prepared
Did you receive background material prior to the meeting? Reviewing it and being prepared with comments saves time for everyone. You might even spot something that could make the meeting unnecessary, as in the case of my New Jersey meeting. If you have questions about the material, consider e-mailing them to the author or to the other attendees in advance, so they have time to think about what you’ve asked.
#5: Have an objective
Author and consultant Stephen Covey counsels readers and clients to “Begin with the end in mind.” When planning a meeting, therefore, ask yourself “What do I want to see as a result of this meeting?” Put another way, ask yourself (as a famous politician and U.S. president did), whether, at the end of the meeting, you and the attendees will be better off than you were at the beginning.
If you have no objective and no purpose, why meet at all?
#6: Publicize the agenda
Having and distributing an agenda prior to a meeting alerts attendees to the nature of that meeting. Attendees who believe a particular item should be added or removed have an opportunity to discuss that issue with the meeting chair.
#7: Be clear about responsibilities
In your agenda and in conversations beforehand, be clear about your expectations for the attendees. Regarding a particular topic, are you looking for a short update, a discussion, or a formal presentation? Being clear about expectations leads to efficiency and avoids embarrassment.
#8: Address important things first
Dr. Covey uses a demonstration involving sand and a collection of medium-size and large rocks. He challenges audience members to place all of them into a pail, so that there’s no overflowing of sand and the rocks all stay below the top of the pail. After many people fail, Dr. Covey shows them how to do it: He puts in the large rocks, then the smaller rocks, then pours in the sand. Those who fail do so because they reverse this sequence.
In your meetings, as in other aspects of your life and work, try to address the most important issues first. Get them out of the way, so that if you do run out of time, all you have left are the less important things.
#9: Avoid being distracted by side issues
It’s easy, during a meeting, to be distracted by side issues. If that happens, you risk losing control of your agenda and the meeting itself. Is the issue one that really needs to be addressed right now? Does it need to be resolved to continue the meeting? If not, consider “parking” it. Section off part of a flipchart page or whiteboard, write the issue inside, then continue the meeting. Afterward, document the issue, as well as any others that have similarly been parked.
If the issue really does need to be addressed immediately, you have a difficult decision to make. Among your current attendees, do you have the necessary people — and only those people needed to resolve the issue? If so, and this issue is important, you may have to take time to address it with the other attendees. If you lack the necessary people, you might have to defer the issue. In that case, try to proceed with other agenda items you can resolve.
#10: Document your meeting
Within a day or two after the meeting, distribute minutes so people have a record of it. Make sure that the minutes list the specific people assigned to specific tasks. Without minutes of a meeting, questions will arise as to who said what and who committed to what. Follow-up actions from the meeting might happen more slowly, if they happen at all.
Note: This information is also available as a PDF download.
Monday, November 5, 2007
Management Blunder of the Month October
Anyone can make a mistake, right?
Misunderstanding a situation, shooting ourselves in the foot, failing to take action as or when required - these things happen occasionally. It comes with the territory when you’re in a management role. And, as long as our good decisions outweigh our goofs, we’re usually OK by the time for the annual review and bonus conversations roll around.
But sometimes, we screw up in such a colossal manner, that nothing is going to overcome the lingering affects. At those times, you either move on to someplace else or another person makes the decision that it’s time for you to “take some time to be with your family.”
Because we can learn from others’ mistakes, I intend to use this space occasionally to highlight some of the humdingers. This month, it’s FEMA. For those of you who don’t know, that’s the Federal government’s emergency management agency. It’s in place to coordinate, support, and augment the efforts of all the various agencies at local and state levels which are in place to deal with crises. FEMA is one of those agencies that everyone is supposed to love and look forward to having around in difficult times. And up until about 2004, it was highly regarded. However, as a result of some changes organizationally that took away much of its autonomy and budget decision authority, it’s not so fab any longer.
Over the last week or so, California’s been experiencing some very bad fires. Thousands of people have been affected. This is precisely the kind of very demanding situation where a leader’s good management skills become clear to everyone around her or him. Or not.
Faced with some unfavorable press about its reaction to the fires, the guy in charge of FEMA’s communications decided that a press conference was required to show the world that the agency was on top of the situation and doing a good job.
This, in itself, was good thinking. It works in any organization. If you’re under a microscope, go out of your way to show that you know what needs to be done and that you have the skill set to get the tasks completed successfully. Don’t wait for others to come looking (and maybe finding) weak links in your chain of management.
But with all management decisions, it’s the execution that counts. A good idea comes across as very dumb if poorly executed. That’s what happened at FEMA.
Rather than have a real press conference; they staged one. In the staged conference, employees of the organization played the role of the press. They threw a few powder puff questions at the man who was playing the communicator and for a few minutes it looked like it was going to work. The “press” would ask, “How do you feel about FEMA’s response to the fires?” The spokesman would reply, “I am pleased with how were doing out there.”
And (I guess the plan said) everyone would watch and believe. There would no longer be any worry about FEMA’s work or capability. But trying to fool the press isn’t so easy. FEMA got busted for being phony.
The guy who staged this debacle, John Philbin, was earlier scheduled to be moved up the ladder before this occurred. He was going to become the head of Public Affairs for National Intelligence next week. But instead he got fired. (What does it say about National Intelligence if they wanted a communications guy like this?)
What can we learn from this management blunder?
1. You can still fool some of the people some of the time. But if you’ve made a big mistake in the past (remember Katrina’s press statements), bear in mind that your credibility will be tainted. People will watch your every action more closely from then on. In this case, it’s likely that some members of the press and the government were waiting for FEMA to hit a banana peel again so they could jump on them. Same thing happens in all organizations.
2. Good work usually speaks for itself. When we start to believe that we get past mistakes by managing communication flows, we start to miss the point of why we’re there in the first place. This can breed a very bad management philosophy which invariably filters down throughout the entire organization.
3. Bad management can’t hide behind BS forever. If someone’s a crappy manager, they can BS their way through it for a while. It’s frustrating to watch someone getting away with a poor performance by conning others - but it usually catches up to them. Even naive bosses have some intuition and catch on after a while. Then the BS’er gets busted.
And recognize this one when noodling about a new job opportunity -
4. Don’t attach your star to an unhealthy environment. Even good managers at FEMA are now tarred by the actions of senior leaders. It’s not going to be easy to move to other organizations with that on the resume.
Misunderstanding a situation, shooting ourselves in the foot, failing to take action as or when required - these things happen occasionally. It comes with the territory when you’re in a management role. And, as long as our good decisions outweigh our goofs, we’re usually OK by the time for the annual review and bonus conversations roll around.
But sometimes, we screw up in such a colossal manner, that nothing is going to overcome the lingering affects. At those times, you either move on to someplace else or another person makes the decision that it’s time for you to “take some time to be with your family.”
Because we can learn from others’ mistakes, I intend to use this space occasionally to highlight some of the humdingers. This month, it’s FEMA. For those of you who don’t know, that’s the Federal government’s emergency management agency. It’s in place to coordinate, support, and augment the efforts of all the various agencies at local and state levels which are in place to deal with crises. FEMA is one of those agencies that everyone is supposed to love and look forward to having around in difficult times. And up until about 2004, it was highly regarded. However, as a result of some changes organizationally that took away much of its autonomy and budget decision authority, it’s not so fab any longer.
Over the last week or so, California’s been experiencing some very bad fires. Thousands of people have been affected. This is precisely the kind of very demanding situation where a leader’s good management skills become clear to everyone around her or him. Or not.
Faced with some unfavorable press about its reaction to the fires, the guy in charge of FEMA’s communications decided that a press conference was required to show the world that the agency was on top of the situation and doing a good job.
This, in itself, was good thinking. It works in any organization. If you’re under a microscope, go out of your way to show that you know what needs to be done and that you have the skill set to get the tasks completed successfully. Don’t wait for others to come looking (and maybe finding) weak links in your chain of management.
But with all management decisions, it’s the execution that counts. A good idea comes across as very dumb if poorly executed. That’s what happened at FEMA.
Rather than have a real press conference; they staged one. In the staged conference, employees of the organization played the role of the press. They threw a few powder puff questions at the man who was playing the communicator and for a few minutes it looked like it was going to work. The “press” would ask, “How do you feel about FEMA’s response to the fires?” The spokesman would reply, “I am pleased with how were doing out there.”
And (I guess the plan said) everyone would watch and believe. There would no longer be any worry about FEMA’s work or capability. But trying to fool the press isn’t so easy. FEMA got busted for being phony.
The guy who staged this debacle, John Philbin, was earlier scheduled to be moved up the ladder before this occurred. He was going to become the head of Public Affairs for National Intelligence next week. But instead he got fired. (What does it say about National Intelligence if they wanted a communications guy like this?)
What can we learn from this management blunder?
1. You can still fool some of the people some of the time. But if you’ve made a big mistake in the past (remember Katrina’s press statements), bear in mind that your credibility will be tainted. People will watch your every action more closely from then on. In this case, it’s likely that some members of the press and the government were waiting for FEMA to hit a banana peel again so they could jump on them. Same thing happens in all organizations.
2. Good work usually speaks for itself. When we start to believe that we get past mistakes by managing communication flows, we start to miss the point of why we’re there in the first place. This can breed a very bad management philosophy which invariably filters down throughout the entire organization.
3. Bad management can’t hide behind BS forever. If someone’s a crappy manager, they can BS their way through it for a while. It’s frustrating to watch someone getting away with a poor performance by conning others - but it usually catches up to them. Even naive bosses have some intuition and catch on after a while. Then the BS’er gets busted.
And recognize this one when noodling about a new job opportunity -
4. Don’t attach your star to an unhealthy environment. Even good managers at FEMA are now tarred by the actions of senior leaders. It’s not going to be easy to move to other organizations with that on the resume.
Monday, October 29, 2007
Write a resume that will land you a programming job..PART 3
Watch your formatting
While technical pros’ resumes do not need to be pretty, formatting can make a huge difference in a resume’s readability. If you cannot put three pages of text in front of me in a readable form, do I really want you touching the UI or writing code that someone else might have to maintain?
I recommend that you stick to a larger font size (e.g., 10 - 12 pt.) in a font that reads well onscreen and in print (e.g., Verdana, Arial, Tahoma, Calibri, Helvetica). If you want a slightly fancier font, use it only for section headers. Also, do not mix Serif and Sans Serif fonts — that is just ugly. Do not use “Comic Sans” anywhere, especially in hot pink or baby blue (and yes, unfortunately, this needs to be stated). Keep your margins and space between paragraphs large enough to provide the reader some “breathing room.”
Employment history
I give applicants some slack on employment history. For instance, five year stints are fairly rare in IT, and I give anyone a lot of leeway if their history includes anything that occurred during the dot com boom/bust.
If you are (or were) a contractor or consultant, make sure that is clearly stated; otherwise, I will think that you get fired and/or quit every 3 - 12 months. If you were not a contractor or a consultant, and it looks like you have a hard time staying at a job, I am going to be very cautious. If I see an increasing progression of job titles, “mercenary” pops into my head. Also, if I see that they are lateral (or worse, negative) moves, “bad apple” is my first thought. Of course, sometimes you get hit with a string of employers that go under or get acquired — it happens to the best of us. If that is the case, find a way to convey that information so I don’t think you are unemployable.
Spelling and grammar
It is critical that the spelling and grammar in your resume is flawless. I have seen applicants misspell the name of their state and the name of their school. If grammar and spelling are not your forte, ask someone to look over your resume for you. While I understand that many IT pros are not native English language speakers (or are English language speakers who paid little attention to those subjects in school), you should still ask someone for help. In fact, knowing when to ask for help is a hallmark of the best developers. If I interview you and realize from your speech that you had the sense and humility to ask someone for help on your resume, I am going to be truly impressed. (For examples of what not to do, check out this list of real-life resume blunders.)
Stay out of EEO (Equal Employment Opportunity) territory
In the United States, companies with more than 10 employees need to follow EEO rules. These rules state that an employer cannot discriminate against or show preference for an employee based on certain group membership items or personal lifestyle issues, such as gender, age, ethnicity, nation of origin, religion, sexual orientation, and so on. So, do me a favor and try to not expose any EEO-related information to me on the resume. In a face-to-face interview or even a phone interview, some of it will be unavoidable. But I will never solicit that information. Not only do I want to keep my employer and myself out of trouble, but I personally feel that EEO is important. I can understand that many names (or even college attended) are strongly correlated with ethnicity, religion, or nation (or at least general geographic region) of origin, and college graduation or attendance dates give some age clues. Minimize this as much as possible. Please do not tell me about your church, your family situation, your home life, your parents, and so on. It is not that I am not interested — I would probably love to learn these things about you if we hire you — but I do not need or want to know them before that you come on board.
Outside interests, hobbies, achievements, and activities
I like to see these, but only if they are relevant. I really do not need to know about how big of a fan you are of the New York Knicks; but if you wrote a piece of software that can do something nifty with the team’s statistics for fun, I would love to know about it. People who contribute to open source projects get a huge gold star in my book, but only if I feel like they would be comfortable working on proprietary software with proprietary tools, and not bringing anything GPL’ed into my codebase. That is a small caveat there. “Contributed to project XYZ in the areas of ABC and DEF” is enough to whet my appetite. Show me some outside learning too — don’t let me think that you get home at 6;00 and shut off your brain. If this work is not interesting enough for you to read about or experiment with on your own time, why would I think that you will be engaged or even interested in the job we would hire you for?
Gracefully show your inner geek
Please give me something meaty that we can discuss during the interview. So, where it is relevant, try to show me how much of a nerd you are.
For instance, try to mention the hovercraft you made from an inner tube and a lawn mower engine. Make note of the iterative, evolutionary game theory system you coded in Lisp that proves that Nash’s equilibrium is dead wrong. Tell me something about your three chess championship victories. I do not want to know that you memorized UHF or that you have a pocket protectors collection that have logos of now defunct minicomputer vendors.
I know most of this falls under the previous section, but it is relevant. I love to work with programmers who love technology and logic and using their brains. People like that are simply better programmers. Why would I want to hire someone who is intellectually lazy for an intellectually challenging job?
Obscure or nonmainstream technologies
I am not hiring Lisp, Prolog, Erlang, APL, Scheme, Clipper, PowerBuilder, Delphi, Pascal, Perl, Ruby, Python (forgive me for including those four in this list), Fortran, Ada, Algol, PL/1, OCaml, F#, Spec#, Smalltalk, Logo, StarLogo, Haskell, ML, D, Cobra, B, or even COBOL (which is fairly mainstream) developers. If you show these on your resume, I will want to interview you just for the sake of slipping in a few questions about these items. I am serious. As part of my secret geekiness, I am really into obscure and almost obscure languages and technologies. I know that a lot of those items take better-than-industry-average intellect and experience to do; they also provide a set of experiences that gives their practitioners a great angle on problems. While you will never directly use those skills in my shop, you will be using those ways of thinking, and it will give us something to talk about on your first day.
(Aside: A coworker was shocked to learn that I played Half Life. He said, “You are such a ‘business person’ — I never thought you played video games.” I guess I’m camouflaging my secret geekiness too well!)
Good luck
I’ve given away crown jewels here. In my perspective, these tips will help any programmer write a perfect resume and get them an interview.
What do you think gets applicants an interview? If you read resumes as either a hiring manager, a recruiter, or an HR employee, what makes you say “wow!” or “ugh!” when you see it on paper?
source @TechRepublic
While technical pros’ resumes do not need to be pretty, formatting can make a huge difference in a resume’s readability. If you cannot put three pages of text in front of me in a readable form, do I really want you touching the UI or writing code that someone else might have to maintain?
I recommend that you stick to a larger font size (e.g., 10 - 12 pt.) in a font that reads well onscreen and in print (e.g., Verdana, Arial, Tahoma, Calibri, Helvetica). If you want a slightly fancier font, use it only for section headers. Also, do not mix Serif and Sans Serif fonts — that is just ugly. Do not use “Comic Sans” anywhere, especially in hot pink or baby blue (and yes, unfortunately, this needs to be stated). Keep your margins and space between paragraphs large enough to provide the reader some “breathing room.”
Employment history
I give applicants some slack on employment history. For instance, five year stints are fairly rare in IT, and I give anyone a lot of leeway if their history includes anything that occurred during the dot com boom/bust.
If you are (or were) a contractor or consultant, make sure that is clearly stated; otherwise, I will think that you get fired and/or quit every 3 - 12 months. If you were not a contractor or a consultant, and it looks like you have a hard time staying at a job, I am going to be very cautious. If I see an increasing progression of job titles, “mercenary” pops into my head. Also, if I see that they are lateral (or worse, negative) moves, “bad apple” is my first thought. Of course, sometimes you get hit with a string of employers that go under or get acquired — it happens to the best of us. If that is the case, find a way to convey that information so I don’t think you are unemployable.
Spelling and grammar
It is critical that the spelling and grammar in your resume is flawless. I have seen applicants misspell the name of their state and the name of their school. If grammar and spelling are not your forte, ask someone to look over your resume for you. While I understand that many IT pros are not native English language speakers (or are English language speakers who paid little attention to those subjects in school), you should still ask someone for help. In fact, knowing when to ask for help is a hallmark of the best developers. If I interview you and realize from your speech that you had the sense and humility to ask someone for help on your resume, I am going to be truly impressed. (For examples of what not to do, check out this list of real-life resume blunders.)
Stay out of EEO (Equal Employment Opportunity) territory
In the United States, companies with more than 10 employees need to follow EEO rules. These rules state that an employer cannot discriminate against or show preference for an employee based on certain group membership items or personal lifestyle issues, such as gender, age, ethnicity, nation of origin, religion, sexual orientation, and so on. So, do me a favor and try to not expose any EEO-related information to me on the resume. In a face-to-face interview or even a phone interview, some of it will be unavoidable. But I will never solicit that information. Not only do I want to keep my employer and myself out of trouble, but I personally feel that EEO is important. I can understand that many names (or even college attended) are strongly correlated with ethnicity, religion, or nation (or at least general geographic region) of origin, and college graduation or attendance dates give some age clues. Minimize this as much as possible. Please do not tell me about your church, your family situation, your home life, your parents, and so on. It is not that I am not interested — I would probably love to learn these things about you if we hire you — but I do not need or want to know them before that you come on board.
Outside interests, hobbies, achievements, and activities
I like to see these, but only if they are relevant. I really do not need to know about how big of a fan you are of the New York Knicks; but if you wrote a piece of software that can do something nifty with the team’s statistics for fun, I would love to know about it. People who contribute to open source projects get a huge gold star in my book, but only if I feel like they would be comfortable working on proprietary software with proprietary tools, and not bringing anything GPL’ed into my codebase. That is a small caveat there. “Contributed to project XYZ in the areas of ABC and DEF” is enough to whet my appetite. Show me some outside learning too — don’t let me think that you get home at 6;00 and shut off your brain. If this work is not interesting enough for you to read about or experiment with on your own time, why would I think that you will be engaged or even interested in the job we would hire you for?
Gracefully show your inner geek
Please give me something meaty that we can discuss during the interview. So, where it is relevant, try to show me how much of a nerd you are.
For instance, try to mention the hovercraft you made from an inner tube and a lawn mower engine. Make note of the iterative, evolutionary game theory system you coded in Lisp that proves that Nash’s equilibrium is dead wrong. Tell me something about your three chess championship victories. I do not want to know that you memorized UHF or that you have a pocket protectors collection that have logos of now defunct minicomputer vendors.
I know most of this falls under the previous section, but it is relevant. I love to work with programmers who love technology and logic and using their brains. People like that are simply better programmers. Why would I want to hire someone who is intellectually lazy for an intellectually challenging job?
Obscure or nonmainstream technologies
I am not hiring Lisp, Prolog, Erlang, APL, Scheme, Clipper, PowerBuilder, Delphi, Pascal, Perl, Ruby, Python (forgive me for including those four in this list), Fortran, Ada, Algol, PL/1, OCaml, F#, Spec#, Smalltalk, Logo, StarLogo, Haskell, ML, D, Cobra, B, or even COBOL (which is fairly mainstream) developers. If you show these on your resume, I will want to interview you just for the sake of slipping in a few questions about these items. I am serious. As part of my secret geekiness, I am really into obscure and almost obscure languages and technologies. I know that a lot of those items take better-than-industry-average intellect and experience to do; they also provide a set of experiences that gives their practitioners a great angle on problems. While you will never directly use those skills in my shop, you will be using those ways of thinking, and it will give us something to talk about on your first day.
(Aside: A coworker was shocked to learn that I played Half Life. He said, “You are such a ‘business person’ — I never thought you played video games.” I guess I’m camouflaging my secret geekiness too well!)
Good luck
I’ve given away crown jewels here. In my perspective, these tips will help any programmer write a perfect resume and get them an interview.
What do you think gets applicants an interview? If you read resumes as either a hiring manager, a recruiter, or an HR employee, what makes you say “wow!” or “ugh!” when you see it on paper?
source @TechRepublic
Write a resume that will land you a programming job..PART 2
Show me that you are different
Even if my project is a run-of-the-mill Web-based, data driven application (which it is not), I still want to see that you are more than someone with 10 years of experience writing run-of-the-mill Web-based, data driven applications. For example, compare these two items:
BORING!
East Coast Power - Programmer 1999 - 2005
* Wrote VB applications to control machinery. The hardware interface was handled in a COM library that was written by another team. Application was robust and reliable.
* Wrote Web-based tool to track system faults.
* Created Web service to allow partners to consume portions of the database.
WOW!
East Coast Power - Programmer 1999 - 2005
* Wrote VB applications to control nuclear reactor. Real-time control and monitoring of systems handling 10,000 unique data inputs per second.
* Wrote advanced algorithms in C# to detect imminent system failure, which were used within a Web-based application.
* Created Web service in C# to allow partners to access data in a secure, reliable, and responsive manner; typical data set was 1,000,000 rows and concurrency challenges needed to be overcome at the database and application layers.
See the difference? Control machinery does not help me much – you could have been working on the elevator system for all I know. Programming a nuclear reactor impresses me, especially since there has not been any nuclear reactor disasters during your employment. Writing advanced algorithms in C# touches my engineer’s heart; whereas writing a mere Web-based tool is ho hum. And, while writing a Web service is fairly simple, particularly in ASP.Net, it’s not so easy to write one that is “secure, reliable, and responsive” with that size of a data set. It’s also not easy to deal with concurrency issues at two different levels.
I am not saying that it needs to be wordy or full of minute details, but if you are doing work beyond what a summer intern could do, I need to know about it. Every developer has written a Web-based, data driven application. Show me more.
Make sure that your experience highlights your skills
I don’t expect your employment history to include a list of all your skills. But if you are looking for work as a .Net developer, show me that you have done some .Net work. If you do not list that experience, I am going to assume that you have little or no experience with it — even if it is on your skill list. If you have large amounts of experience outside of the workforce, find a way to show that on your resume.
Keep your resume between two to four pages long
I have struggled through seven-page resumes filled with jargon and boring details that made me want to cry. An overly long resume doesn’t necessarily make me rule out a candidate, but why make it hard on me?
On the other hand, a resume that tries to stick to the one page rule is not going to cut it for a technical person unless they are new to the field. In my experience, two to four pages is just right. Also, please use some whitespace, so I do not feel like I am drowning.
continued...
Write a resume that will land you a programming job..PART 1
I usually read 5 - 20 resumes each week. Both my boss and I are extremely busy, so it’s important that a programmer’s resume grab our attention quickly by providing the right mix of necessary information with something that makes that person stand out from the pack.
I’ve been involved with our hiring process for more than six months, so I feel fairly confident that I can distill what it takes for a programming resume to get me to say, “Let’s arrange an interview.” Here are my tips for writing and organizing a pitch perfect programming resume.
Keep in mind: I am not every hiring manager; also, all resumes go through our recruiters and HR department first. Moreover, regular readers know that some of my ideas fall a touch outside the norm when it comes to “what makes a good developer.”
Put your skills front and center
Reading the in-depth details of how you used mainstream skill XYZ to accomplish typical task ABC is not at the top of my agenda. I want to see your skills up front, so I don’t need to go trolling through your resume to see if you meet my minimum needs.
Skip the summary and maybe even the objective
Those summaries are a waste of my time. It is going to say something like “seasoned IT pro with great communication skills” or “proven veteran with 10 years of programming experience.” How do I know this? Because they all say this. Skip it, please.
The objective is a slightly different story; it is useful only if it informs the interviewer about something that the skills and experience does not. The objective’s relevance to me is largely a function of whether you wish to keep doing what you have been doing. If I see you have been programming — particularly at the data access layer and the business object layer — and there is no objective, I am going to assume that you are looking for more of the same with a different employer or location. If you want to do more of that work and put an objective, you are wasting space. If you are looking for a change of pace — like getting more into the presentation layer or heading towards a management track — it’s important to state that in your resume. Otherwise, we may discover during the interview that you are not interested in what we have to offer.
List your education last
Some IT hiring managers put a huge emphasis on certain educations but I do not. I always want you to list your school and your major, but I will only ask you about your education if there is something unusual or intriguing.
For instance, a candidate with a Computer Science degree from MIT or with a PhD in Organic Chemistry will draw my eye because these degrees show a level of high intelligence. On the flipside, an AA in basket weaving or a lack of a degree will not count against you.
In most cases, I am not even curious about your education until I have already made up my mind. This includes certifications — MCSEs and CCNAs do not impress me that much at this point. They matter to some folks, and they do not hurt you in my opinion, but I will only take that certification into account if all else is equal.
continued...
I’ve been involved with our hiring process for more than six months, so I feel fairly confident that I can distill what it takes for a programming resume to get me to say, “Let’s arrange an interview.” Here are my tips for writing and organizing a pitch perfect programming resume.
Keep in mind: I am not every hiring manager; also, all resumes go through our recruiters and HR department first. Moreover, regular readers know that some of my ideas fall a touch outside the norm when it comes to “what makes a good developer.”
Put your skills front and center
Reading the in-depth details of how you used mainstream skill XYZ to accomplish typical task ABC is not at the top of my agenda. I want to see your skills up front, so I don’t need to go trolling through your resume to see if you meet my minimum needs.
Skip the summary and maybe even the objective
Those summaries are a waste of my time. It is going to say something like “seasoned IT pro with great communication skills” or “proven veteran with 10 years of programming experience.” How do I know this? Because they all say this. Skip it, please.
The objective is a slightly different story; it is useful only if it informs the interviewer about something that the skills and experience does not. The objective’s relevance to me is largely a function of whether you wish to keep doing what you have been doing. If I see you have been programming — particularly at the data access layer and the business object layer — and there is no objective, I am going to assume that you are looking for more of the same with a different employer or location. If you want to do more of that work and put an objective, you are wasting space. If you are looking for a change of pace — like getting more into the presentation layer or heading towards a management track — it’s important to state that in your resume. Otherwise, we may discover during the interview that you are not interested in what we have to offer.
List your education last
Some IT hiring managers put a huge emphasis on certain educations but I do not. I always want you to list your school and your major, but I will only ask you about your education if there is something unusual or intriguing.
For instance, a candidate with a Computer Science degree from MIT or with a PhD in Organic Chemistry will draw my eye because these degrees show a level of high intelligence. On the flipside, an AA in basket weaving or a lack of a degree will not count against you.
In most cases, I am not even curious about your education until I have already made up my mind. This includes certifications — MCSEs and CCNAs do not impress me that much at this point. They matter to some folks, and they do not hurt you in my opinion, but I will only take that certification into account if all else is equal.
continued...
Geeks and communication skills
It is a commonly held belief that geeks do not need to be able to communicate outside of Nerdland. In fact, it is an outright expectation. Programmers who gets nervous around pretty girls, systems administrators who cannot give a presentation to more than two people at a time, and DBAs that stutter unless they are discussing Dungeons and Dragons are what many people envision when they think of IT professionals. These are all common stereotypes of IT professionals. Sad to say, many IT professionals buy into this idea, and sometimes even actively encourage it!
I am not going to pretend to be surprised by this. Up until the age of sixteen or so, reaching Level 4 as a bard seemed more important than reaching first base with a woman. Weird Al Yankovich was “romantic” in my mind and a “nice wardrobe” meant a closet full of shirts from hardware and software vendors, preferable ones with multiple years’ worth of pizza stains on them to prove my “authenticity”. I thought that if people did not understand me, it was because they were stupid, not that I was unable to communicate with them.
Thankfully, I changed. Mostly. I still think Weird Al is funny on occasion, and the ratty shirts are still there (though they now tend to be Metallica and Mr. Bungle shirts from my post-ubergeek years). The biggest change was that my communication skills improved significantly. I took classes in high school such as AFJROTC and Mock Trial that taught me how to speak to an audience, with or without notes. My classes in college (I will merely admit that I double majored in “cannot-get-a-job-ology” which is code for “the liberal arts”) involved few tests, but endless amounts of paper writing. What few tests there were tended to be essay questions. In other words, I was learning a lot about communication skills.
What does this have to do with the IT industry? Plenty. If you want to know why your manager seems to be a “grinning idiot” with no clue what your job is instead of someone with technical skills, take a look at what that manager brings to the table. That manager is very likely to have an MBA or maybe an MIS degree. Their external learning is probably in “risk management” or Six Sigma, not the Cisco or Red Hat certification you just earned. The manager’s job is to interface between “the suits” and the IT people. The manager does not actually need to know how to do your job if you communicate your needs to him properly. What manager does need to know is how your job relates to the business.
It has been my experience since I started blogging about IT issues on TechRepublic, that the majority of the time when I receive heavy criticism, it is because I failed to write clearly and properly communicate my message. Sure, there have been instances where someone climbed all over me for using one bad example or analogy in a 3,000 word post, or where someone was obviously unable to comprehend the topic at hand. But by and large, when I receive negative feedback, it is my own fault for not writing clearly.
At my current position, my manager does not understand much programming (he knows some VBA), systems administration, database administration, networking, computer repair, or any of the other tasks I do. He knows how to run the company, deal with customers, and so on. He really does not need to know the gritty details of what the project is hung up on; he just needs to know how long the delay will be. He does not care what brand of motherboard I buy or what CPU I select; he needs to know the price and business justification for the expenditure.
Many of the IT people that I have worked with simply do not understand this. They fill a proposal with technical details, and expect the person reading it to understand the benefit of the proposal from the technical information. In other cases, they write an email that is littered with typos and spelling mistakes. These types of mistakes do not help the recipient to understand why they should approve your request or give your project more resources, or otherwise help you with whatever goal it is that you are trying to accomplish. Tailor your message for the audience. If the recipient is a technical person, make it technical. If they are a non-technical person, use language that a non-technical person can understand. As I often do for programs that I have written, I pass it through the “Mom test.” In other words, I ask my mother to review it. She is about as non-technical as it gets. If my mother can understand what I have written to the point where she can make an educated business decision, then it is a good communication.
Many of the IT people out there seem to think that this is degrading. These are the same types of IT people who make web sites that only display in one particular web browser, or require you to go find some funky external library, or insist that you recompile the application yourself without providing any documentation. These are the IT people that may be excellent at their jobs, but are hated by everyone that their job touches. You do not need to go this route. No one will criticize you or complain if you learn to effectively communicate with non-technical people. In fact, they will appreciate you even more. My experience has been that improved communications skills leads to better opportunities in life and in my career. If a manager is evaluating two candidates for a promotion, they are more likely to pick someone with less technical skills who communicates well than a more technical person who does not communicate well. Why? Because the person with good communication skills is able to show that they know what they are talking about, while the person without those skills simply cannot be understood.
If you feel that your communication skills may be lacking, there are things that you can do to help them improve. One suggestion is to read more books and magazines. If you already ready books and magazines, escalate the difficulty level of your readings or try reading about topics that you are not familiar with. I have found that crossword puzzles are great tools to expand your vocabulary. Try your hand at writing something, whether it be short fiction, how-to articles, or poetry. If you can, try to go to new places or talk to different people; sometimes we find ourselves in cliques with a shared mindset that makes it difficult to learn how to communicate outside of that group. There are lots of different ways to improve communications skills, but at the end of the day, they all amount to “increase the frequency of your communications, the diversity of the mediums, and the people that you communicate with.”
courtesy @Techrepublic
I am not going to pretend to be surprised by this. Up until the age of sixteen or so, reaching Level 4 as a bard seemed more important than reaching first base with a woman. Weird Al Yankovich was “romantic” in my mind and a “nice wardrobe” meant a closet full of shirts from hardware and software vendors, preferable ones with multiple years’ worth of pizza stains on them to prove my “authenticity”. I thought that if people did not understand me, it was because they were stupid, not that I was unable to communicate with them.
Thankfully, I changed. Mostly. I still think Weird Al is funny on occasion, and the ratty shirts are still there (though they now tend to be Metallica and Mr. Bungle shirts from my post-ubergeek years). The biggest change was that my communication skills improved significantly. I took classes in high school such as AFJROTC and Mock Trial that taught me how to speak to an audience, with or without notes. My classes in college (I will merely admit that I double majored in “cannot-get-a-job-ology” which is code for “the liberal arts”) involved few tests, but endless amounts of paper writing. What few tests there were tended to be essay questions. In other words, I was learning a lot about communication skills.
What does this have to do with the IT industry? Plenty. If you want to know why your manager seems to be a “grinning idiot” with no clue what your job is instead of someone with technical skills, take a look at what that manager brings to the table. That manager is very likely to have an MBA or maybe an MIS degree. Their external learning is probably in “risk management” or Six Sigma, not the Cisco or Red Hat certification you just earned. The manager’s job is to interface between “the suits” and the IT people. The manager does not actually need to know how to do your job if you communicate your needs to him properly. What manager does need to know is how your job relates to the business.
It has been my experience since I started blogging about IT issues on TechRepublic, that the majority of the time when I receive heavy criticism, it is because I failed to write clearly and properly communicate my message. Sure, there have been instances where someone climbed all over me for using one bad example or analogy in a 3,000 word post, or where someone was obviously unable to comprehend the topic at hand. But by and large, when I receive negative feedback, it is my own fault for not writing clearly.
At my current position, my manager does not understand much programming (he knows some VBA), systems administration, database administration, networking, computer repair, or any of the other tasks I do. He knows how to run the company, deal with customers, and so on. He really does not need to know the gritty details of what the project is hung up on; he just needs to know how long the delay will be. He does not care what brand of motherboard I buy or what CPU I select; he needs to know the price and business justification for the expenditure.
Many of the IT people that I have worked with simply do not understand this. They fill a proposal with technical details, and expect the person reading it to understand the benefit of the proposal from the technical information. In other cases, they write an email that is littered with typos and spelling mistakes. These types of mistakes do not help the recipient to understand why they should approve your request or give your project more resources, or otherwise help you with whatever goal it is that you are trying to accomplish. Tailor your message for the audience. If the recipient is a technical person, make it technical. If they are a non-technical person, use language that a non-technical person can understand. As I often do for programs that I have written, I pass it through the “Mom test.” In other words, I ask my mother to review it. She is about as non-technical as it gets. If my mother can understand what I have written to the point where she can make an educated business decision, then it is a good communication.
Many of the IT people out there seem to think that this is degrading. These are the same types of IT people who make web sites that only display in one particular web browser, or require you to go find some funky external library, or insist that you recompile the application yourself without providing any documentation. These are the IT people that may be excellent at their jobs, but are hated by everyone that their job touches. You do not need to go this route. No one will criticize you or complain if you learn to effectively communicate with non-technical people. In fact, they will appreciate you even more. My experience has been that improved communications skills leads to better opportunities in life and in my career. If a manager is evaluating two candidates for a promotion, they are more likely to pick someone with less technical skills who communicates well than a more technical person who does not communicate well. Why? Because the person with good communication skills is able to show that they know what they are talking about, while the person without those skills simply cannot be understood.
If you feel that your communication skills may be lacking, there are things that you can do to help them improve. One suggestion is to read more books and magazines. If you already ready books and magazines, escalate the difficulty level of your readings or try reading about topics that you are not familiar with. I have found that crossword puzzles are great tools to expand your vocabulary. Try your hand at writing something, whether it be short fiction, how-to articles, or poetry. If you can, try to go to new places or talk to different people; sometimes we find ourselves in cliques with a shared mindset that makes it difficult to learn how to communicate outside of that group. There are lots of different ways to improve communications skills, but at the end of the day, they all amount to “increase the frequency of your communications, the diversity of the mediums, and the people that you communicate with.”
courtesy @Techrepublic
6 (bad) reasons managers avoid personnel issues
I’m always amazed when I see otherwise good managers falter when they have to deal with a personnel issue.
I’m talking about all kinds of individuals. Those who are strong technically, smart, even outgoing are as likely to waiver as are others who don’t have the same knowledge or brainpower or extroverted attitude.
Why is it that managers who rarely fail to meet their other deadlines, don’t do as well with personnel issues?
Here are 6 key reasons:
1. Because they can. It’s easy to avoid dealing with people - especially when you’re in a more senior position. A simple, “Sorry I can’t meet with you, this project’s got to be done by such and such date and it can’t be delayed,” gets you off the hook. After all, very few people will argue that they are more important than THE PROJECT.
2. Because they don’t know how easy it is. For a lot of people, it seems easier to simply avoid dealing with an issue that’s personell related. Of course it’s not. Avoidance, over time, makes a manager feel bad. Often those who avoid problems frequently will report feeling like they are weak, indecisive, unempowered, or even a fraud. But when they finally have to deal with the issue they often report that they feel much better. Even if it was a tough meeting.
3. Because their boss does it to them. They say things like, “Heck, it’s what everyone around here does. So why should I get involved in this hassle; no one else cares anyway.” I hear this in a lot of very poorly-performing organizations. No surprise if you think about it - when people are disregarded or problems avoided for a long time; the message to all is clear - “we managers really don’t care.”
4. Because they think their leaders are full of it. I mean, how many company leaders DON’T say stuff like, “our people are our most important asset” today? It’s like a BS mantra. But then they’re not accessible to the employees or other managers. When I hear this from a C-Level person I ask if I can see their appointment schedule. The ones who truly care have a lot of meetings with employees, union reps, or other lower level managers. Most don’t. And the rest of the company just learns to live with the boss who says stuff but doesn’t act on it.
5. Because they haven’t been trained. With good training, even a rep who has to deal with customers’ complaints all day can keep his or her perspective. They are taught what to expect with the interaction between them and unhappy customers, and how to respond without taking it personally. Understanding how to deal with personnel issues is a key part of being a good manager; yet many companies don’ t have a training program in place. So we expect the manager to deal with it like a pro. The manager knows (s)he’s not. And avoids.
6. Because they don’t care. Face it - some managers really don’t have any concern about the well being of the company or their fellow co-workers. They are there for the paycheck and to get out and spend it. If you see these people, recognize that they are not simply screwing the ’system’. Their lack of care may cause a waterfall affect which makes your company the next one to go out of business, beaten by another filled with managers and employees who really want to deliver a good product or service.
In today’s world, a failure to recognize the importance of personnel issues, and then deal with them isn’t just bad - it can be fatal.
courtesy @TechRepublic
I’m talking about all kinds of individuals. Those who are strong technically, smart, even outgoing are as likely to waiver as are others who don’t have the same knowledge or brainpower or extroverted attitude.
Why is it that managers who rarely fail to meet their other deadlines, don’t do as well with personnel issues?
Here are 6 key reasons:
1. Because they can. It’s easy to avoid dealing with people - especially when you’re in a more senior position. A simple, “Sorry I can’t meet with you, this project’s got to be done by such and such date and it can’t be delayed,” gets you off the hook. After all, very few people will argue that they are more important than THE PROJECT.
2. Because they don’t know how easy it is. For a lot of people, it seems easier to simply avoid dealing with an issue that’s personell related. Of course it’s not. Avoidance, over time, makes a manager feel bad. Often those who avoid problems frequently will report feeling like they are weak, indecisive, unempowered, or even a fraud. But when they finally have to deal with the issue they often report that they feel much better. Even if it was a tough meeting.
3. Because their boss does it to them. They say things like, “Heck, it’s what everyone around here does. So why should I get involved in this hassle; no one else cares anyway.” I hear this in a lot of very poorly-performing organizations. No surprise if you think about it - when people are disregarded or problems avoided for a long time; the message to all is clear - “we managers really don’t care.”
4. Because they think their leaders are full of it. I mean, how many company leaders DON’T say stuff like, “our people are our most important asset” today? It’s like a BS mantra. But then they’re not accessible to the employees or other managers. When I hear this from a C-Level person I ask if I can see their appointment schedule. The ones who truly care have a lot of meetings with employees, union reps, or other lower level managers. Most don’t. And the rest of the company just learns to live with the boss who says stuff but doesn’t act on it.
5. Because they haven’t been trained. With good training, even a rep who has to deal with customers’ complaints all day can keep his or her perspective. They are taught what to expect with the interaction between them and unhappy customers, and how to respond without taking it personally. Understanding how to deal with personnel issues is a key part of being a good manager; yet many companies don’ t have a training program in place. So we expect the manager to deal with it like a pro. The manager knows (s)he’s not. And avoids.
6. Because they don’t care. Face it - some managers really don’t have any concern about the well being of the company or their fellow co-workers. They are there for the paycheck and to get out and spend it. If you see these people, recognize that they are not simply screwing the ’system’. Their lack of care may cause a waterfall affect which makes your company the next one to go out of business, beaten by another filled with managers and employees who really want to deliver a good product or service.
In today’s world, a failure to recognize the importance of personnel issues, and then deal with them isn’t just bad - it can be fatal.
courtesy @TechRepublic
Subscribe to:
Posts (Atom)
Posts
