Want Job Security? Be Underpaid

For as long as anyone can remember, there has been one primary driving force in every career: money.Job Security

I’ve been in the staffing industry for over 20 years. During that time, I have helped thousands of candidates seek their next position and hundreds of companies secure top talent for their organization. My observation over that span probably won’t surprise you - salary is always one of the, if not the, top criteria candidates consider before taking a job. And why not? The amount of money you make (or don’t make) can have a dramatic impact on how you live. For most of us, the calculus is simple: more money = more security = better life.

As if the “better life” argument isn’t compelling enough, the ubiquity of technology (smartphones with corporate mail, VPN, SaaS-based systems), has blurred the line between personal and work time – like our devices, we’re now expected to be “always on”. Maximizing income isn’t just smart, it’s fair . . . right?

Unfortunately, it’s all too easy to lose perspective on the real driver behind compensation. People typically aren’t paid more simply because they have new skills, longer tenures or more experience. Instead, they are paid more because those skills, tenure and experience bring greater value to their employers.

Which leads me to my point:  Be underpaid.

This probably sounds strange coming from a career headhunter, since we get paid based on what you get paid. But, I passionately believe that if you over-deliver… or are underpaid, there will always be a seat for you at the table. Now, I don’t believe you should be taken advantage of in this worker/company relationship – rather that you should be delivering more real value to the company than what they are paying you. Relationships are based on mutual need and mutual benefit. You need a job and the associated money - and companies need your skills, abilities and experience.

Think about the top NFL quarterbacks today and their sky high salaries. The value they bring to the organization must still be greater than what they are paid, or there won’t be a spot on the team for them. Sure, the money paid to Tom Brady, Aaron Rodgers and Tony Romo is almost too much to wrap your head around. But, clearly the value they bring to their respective organizations is greater than the millions they receive in salary. You see it all the time. As soon as their value to the team drops below the millions they are paid, they are cut or traded.

Whether you’re a top NFL quarterback, IT developer, finance manager or marketing guru – to keep your seat at the table – always strive to over deliver for your employer. I know it sounds counterintuitive, but I suggest that you feel just a little underpaid for your contributions. Keep in mind that your career is more than just your current job. If you approach your selected profession as a marathon and not a “what’s in it for me – show me the money” sprint, the long term gains you’ll enjoy will give you not only the income you desire, but job satisfaction and security for many years to come.

About the Author: 

Jon Davis is Executive Vice President of National Sales for MATRIX Resources. He has over 20 years of experience in leading sales teams and corporate recruiting efforts in all verticals ranging from startup companies, mid-market organizations and the Fortune 100. Follow Jon on Twitter for more career tips: @JonDavis12.

Posted in: 
Job Seeker

Distributed Agile Teams: The ART of the START

I’ve been sharing about agile methods for over ten years at conferences and workshops. One of the top three questions I always receive from attendees is:

Does agile work with distributed teams?Distributed Agile Teams

And sometimes the question is phrased another way:

The notion of co-located teams is nice in theory, but in real life we have team members all over the world. We need to cobble together teams based on our business needs from wherever they are. Does agile support that level of high distribution?


Photo credit: Flathead Beacon

I often smile at the repetitiveness of the question. It indicates clearly that enterprise level software development is often distributed. It also indicates that outsourcing is still alive and well. I’ll try to provide some answers to these questions by sharing two stories of distributed teams I have experienced.

A Tale of Two Distributed Teams

The “Good”

I was lucky enough to be invited to do an agile jump-start for a new client. They are a rather large firm that builds hardware and software devices supporting mechanical control systems. They were kicking off several projects that encompassed many teams, some of them offshore and many distributed. They were looking to leverage Scrum as the method for starting these projects, and they invited me in to do some training and get the teams sprinting in this new style of product development.

When I arrived at my first class session, I learned that they had invited four complete Scrum teams to attend. In fact, one of the teams was based in India, and they had flown the entire team in for several weeks. The first week was for our Scrum boot camp, and the next few were to work with local teams as everyone started sprinting together.

I distinctly remember at the time thinking how novel this was. My typical experience with firms kicking off agile in distributed teams was more along the lines of the following:

  • Throw disparate individuals (local and remote) together into “teams”
  • Tell them they’re “going agile”
  • Send them some references on agile; at best, run them through a short class
  • Expect the team to start sprinting … ASAP
  • Expect great results
  • Rinse and repeat if you still have a customer…

Clearly I’m joking a bit here, but there is a good bit of truth in these steps. Many firms don’t start up their distributed agile teams very well. So I was understandably surprised at how thoughtful my client was in investing in their teams’ start.

I returned to the client several sprints later to do an informal assessment.  By now the remote India team had returned home and was happily working with the local teams. I sat in on some of their stand-ups and other meetings. I was incredibly impressed with how well they were working as an agile team. I was even more impressed with how they integrated and collaborated with the local teams — it was virtually seamless.

It struck me that the cost the company had incurred in bringing everyone together to generate a solid start was paying them back big time. That solid project start-up had put everyone on the same footing and really solidified them as a set of cross-functional teams that had the same vision and were working toward the same goals.

As an aside, I’ve seen this same investment pay similar dividends at multiple clients. Now let’s explore another story.

The “Bad to Ugly”

I was invited to visit another set of teams to help them with some difficulties they were having working across distributed locations. They were executing sprint number five of a 12-sprint release sequence. There was a distributed UX/design team, two front-end UI development teams (one in the US and the other in Brazil), and a back-end development team in Singapore. In short, a very distributed mix across four distinct teams working on a single project.

One key challenge I remember was that the front-end and back-end teams were really struggling to figure out how to work together. They were using email and documents as their primary means of collaboration. But quite often, it would take days to sort out a simple interaction that was required to move a user story forward. And the issues weren’t focused on one team or one locale. There were pervasive communication problems across the teams.

One idea came up in a local (US) team's retrospective. It turned out that nobody had ever “met” the offshore Singapore team that they had to integrate with (at an API level and at a project collaboration level). The idea was to have a video conference call across the two teams as a means of introduction and familiarization. Everyone thought it was a great idea and we scheduled the intro.

I volunteered to serve as the facilitator of the video introduction. There were eight members on our local UI team. We fired up the video and zoomed into the room in Singapore, eagerly expecting to meet a team roughly our size and composition. And they started filling the room — and filling, and filling!

In the end, over 30 people came into the room from Singapore. We were amazed and during the course of the introduction quickly realized some things:

  • We had assumed some of them were men and they were actually women and vice versa … who knew?
  • There were two expectant mothers in the room … who knew?
  • We thought there were roughly 8-10 members of the team, and there were 30. Even funnier, we’d been working with them as if their capacity was 8-10. Who knew?
  • Clearly nobody on either side had ever seen or met each other. Apparently ALL collaboration was via email, text messages, and documents. Not a phone/video call to be had.
  • We learned about their background and skill levels, realizing that they knew much more than we had been giving them credit for … who new?
  • We learned that they were heavily multitasking and being interrupted across many projects. Ours wasn’t their highest priority … who knew?
  • We finally realized that they didn’t like this “agile stuff” and preferred more traditional development approaches. So this was a major and difficult change for them and their leadership … who knew?

It was a fantastic, baseline setting call for the two teams. It created a much better understanding and led to much improved empathy, understanding, teamwork, and results going forward. But why this wasn’t the first thing that happened when the teams were formed and the project begun? They could have avoided a tremendous amount of frustration, waste, and missed progress. Who knew?

Three CORE Starting Patterns for Distributed Agile Teams

I hope my two real world stories have convinced you that a fundamental aspect of successfully implementing distributed agile is how you start your teams and projects. Here is a bit of a checklist to help you improve your distributed agility:

Establish the Team(s)

  • Formation – Take some time to thoughtfully form your teams. Introduce them. Allow for social collaboration of some sort.
  • Leadership – Take a look at the leadership within your organization and ensure that each team has some experienced technical leadership. Also ensure that each team's local functional leadership is aligned with agile leadership fundamentals.
  • Co-Locate in Clusters – Look across the members you have to work with and try to cluster team members together (geographically) as much as possible.
  • Skills Aligned with Backlog – Remember that team skills need to align with the Product Backlog and that each team must have sufficient skill and domain experience to deliver high quality results.
  • Cross-Cutting Concerns - Consider how the team will handle cross-cutting concerns like UX design, architecture, and integration testing and deployment.

Train the Team Together

  • Basic Training – If possible, training should be approached as a whole team effort and is best done face-to-face. Everyone needs to hear the same things. Simulations should be a part of the training so that the teams get the opportunity to work together.
  • Roles & Responsibilities – Developing clarity around expectations is crucial for agile teams to start up. Taking the time to establish team and cross team roles and responsibilities and/or rules of engagement early will pay dividends during sprint execution.
  • Focus on Scrum Master and Product Owner – These are the most important and specialized roles within agile teams. Ensure you’ve selected wisely, don’t overload other roles, and provide sufficient training and ongoing coaching for these individuals. It’s crucial in distributed teams!
  • Start the First Sprint Together – If at all possible, start your first sprint with the team in the same locale. If that’s not possible, then start slowly, so that teams aren’t rushing to produce working software, but rather a “working team” should be their first goal.

Establish Norms, Standards, and a Charter

  • Team Norms – Set norms for listening, respect, behaviors, collaboration, quality, retrospectives, etc. Establish these as a team, post them on walls, and continuously remind yourselves of your agreements.
  • Meeting Norms – There can be an awful lot of meetings when moving to agility and conducting them can be exacerbated by time zone differences. Place heavy focus on just enough, just in time, and well facilitated meetings. Don’t forget the power of a time box.
  • Definition of Done – I have a nice presentation that depicts four levels of Definition-of-Done (DoD) or Done-Ness consideration within agile teams. There’s a link in the references. This is an area to truly focus on when working in a distributed team.
  • Tooling – Tools become more important in support of distributed teams, but they can also get in the way of collaboration and learning. Carefully select a minimal set of tools, while reinforcing face-to-face collaboration. Then grow your tools over time based on team feedback and needs.
  • Commitment to Agility – It is clearly harder to support agile tenants and tactics when participating within a distributed team. It will test your mettle. Establish broad commitment to your agile principles across teams and stick to them.
  • Chartering & Release Planning – These can be critical for cross team integration, dependencies, sharing a mission and vision, and determining and measuring success. The more time you can spend in up-front chartering activity, the better your results will be. So resist sprinting too soon!

Sprint Review Together!

One final point, distributed teams should perform their sprint demo/reviews together as much as possible. That would include members of each team and teams that are working together to deliver a project or product. The more you can integrate the demonstration of results, the more you will drive effective cross-team collaboration.

And improvements surfaced during the reviews will naturally cascade into the teams’ retrospectives, driving collaborative improvements.

Wrapping Up

Going back to my theme of what attendees ask me about distributed agile teams, there’s often another question:

Do we really have to do ________________?
It’s really hard to support that agile practice because we’re distributed!

You could fill in the blank with any of the following: swarm, collaborate, stand-up, groom, sprint plan, code review, design review, pair, test, talk to each other, etc.

My consistent answer is always — yes, you do. Now you may need to get creative with the how and the when in your support of solid agile team collaboration tactics, but skipping them when the going is tough is rarely good practice.

I’ll leave you with this thought.

Is agile harder to do in distributed teams? Of course it is. But is it possible to do it well in distributed teams? Absolutely. It’s truly up to the business to commit to properly starting their projects and the teams to commit to agility and figure out how to drive great results.

It’s simply another choice as you “go agile”. Please choose wisely.

For Further Reading

  1. A related blog post from Johanna Rothman and Shane Hastie: http://goo.gl/YypJY
  2. A presentation on agile done-ness criteria: http://goo.gl/GXL3u
  3. I highly recommend a wonderful book related to Agile Chartering. The title is Liftoff: Launching Agile Projects & Teams by Diana Larsen and Ainsley Nies.
About the Author: 

Bob Galen is a software engineer by trade and a technical leader by experience. He is a principal in RGalen Consulting Group, based in Cary, NC. For the past 15 years, he has held significant leadership roles at Bell & Howell, ChannelAdvisor, EMC, Lucent, Thomson/Dialog, and Unisys. Currently his focus is Agile Methods Coaching, Training, Evangelism & Speaking. He has a track record of effectiveness in leading diverse technical teams towards project success in an energized and humane fashion utilizing Agile & Traditional methods. If there is a key to Bob’s style its Balance and Effectiveness. His is a member of the Agile Alliance, a Certified Scrum Master & Scrum Product Owner, and an experienced XP Coach. http://www.rgalen.com

Posted in: 
PM-Agile

5 Ways to Get Ahead in the Digital Age

Learning how computers work is no longer an optional skill for people hoping to find jobs in the next few years. I don't mean being able to turn a computer on, or transfer a word document into a PDF format: new job seekers need to know how to present themselves, and their future companies online.5 Ways to Get Ahead in the Digital Age

I entered college hoping to study books, and will leave knowing how to code. In all honesty, I'm a novice computer programmer by any measure, and that's okay. Unless you want to build websites or fix technical problems, understanding the ins and outs of programming really isn't that important.

What's necessary for young job seekers is an understanding of the basics. Knowing what your company's site can and cannot do, how your web audience responds, and how to use social media effectively are skills that can make you more valuable to a company and help you do your job more effectively.

Understanding the internet on a personal level can be a great next step to helping a company work online. I manage an online media company in Austin, TX and have never had any formal classroom training.

Here are five things you can do that can help you get ahead of your peers and on your internet game:

Brand yourself: Companies spend years figuring out how to brand themselves in order to be the most appealing to their demographic, but how much time have you spent thinking about how you yourself are branded? If you know what you want to do, or even if you have a vague idea, branding yourself around your end goal can help you appear more qualified to prospective employers. For example, if you want to own a food truck that sells ice cream, you would try and make your presence online demonstrate both a love for ice cream, and a love for being entrepreneurial.

Understand Social Media: Social Media has much more potential than liking your Aunt Debbie's cat photos on Facebook. Social media can be a great way to brand yourself, and make connections to other people in your industry. I use Twitter to connect with other media industry professionals and to help reporters scoop stories more than I update my friends on the new Katy Perry song.

Keep up with Analytics: Nothing you can do in branding or social media is important unless you know if it's working or not. Playing around with an analytics site that tracks who comes to your website can help you get a grasp on what you are doing that works, and what doesn't. Sites like google.com/analytics even have entrancing graphs.

Learn basic computer programming: You don't have to be able to code in Ruby to make a big impression on your future boss, but it certainly wouldn't hurt. Learning the basics of coding languages like HTML and CSS can help you understand the way sites work and help you communicate your ideas more clearly and effectively with your company's tech team. I learned to code on codeacademy.com, which is a free website built to teach inexperienced people the basics of computer programming.

Showcase your skills: Building your own website is a great way to show off the skills that you've honed in the other steps to potential employers.  Sites like wordpress.com and tumblr.com can be great places to round out your online presence and display all of your abilities in one place. It will also increase the possibility that you show up in online search engines.

The internet can be what you make of it. You can use the internet to look at 27 photos of cats licking teacups, but it can also be a great resource to building your online identity and helping you find your next job.

About the Author: 

Kelsey McKinney is the Associate Managing Editor of The Daily Texan. She has written articles for Reader's Digest, The Atlantic, Slate and Time Out NY. Follow Kelsey online at kelseymckinney.com or on Twitter @mckinneykelsey. She likes big sandwiches, Rangers baseball, and writing about feminism and popular culture.

Posted in: 
Job Seeker

Transitioning From IT Expert to IT Supervisor: Part II

This is Part II of Carol Hacker's advice for making the transition from IT expert to IT supervisor. Read Part I hereIT Expert to IT Supervisor

Learn How to Delegate

Experienced, as well as new supervisors, often struggle with the idea of “letting go.” Some supervisors are afraid to assign responsibility for fear of losing control.  This could be an unfounded fear or one that has its roots in bad experiences in the past. You cannot possibly look after every detail in the area for which you are held responsible.  You will have to delegate some of those details or you will find yourself overwhelmed with tasks, projects and customers.  In the words of mega-retailer, J.C. Penney, “The inability to delegate properly is one of the chief reasons leaders fail.” 

The critical issue is to know when, to whom and how to delegate.  Delegating is about sharing authority, not just assigning tasks.  If you are the type of new supervisor who believes that you are the only one capable of making decisions or completing challenging assignments, delegation will be a difficult skill for you to master.  Supervisors who fail to delegate tend to do so for the following reasons:

• They don’t trust the people who report to them.  They typical think: “If I want it done right, I have to do it myself.”

• They believe that if they delegate all of their work to others, that they might be seen as dispensable and lose their job.  Some supervisors are afraid that their employees will do a better job than they do and consequently make them look bad.

• Many supervisors have a need to know what’s going on at all times.  They think of their involvement as simply “staying on top of things.”

• Some supervisors get a lot of satisfaction from doing the work themselves and are thus unwilling to let go and delegate.

If you expect your employees to excel, you have to delegate and empower them to make decisions.  The benefit is not only happier employees, but also more time to do other things that you need to do.  Start by delegating in these four areas.

•    Simple and routine tasks
•    Repetitive tasks
•    Tasks that will help the employee grow
•    Tasks that can best be handled by someone other than yourself

The following basic steps will help you become more confident in delegating.

•    Decide what needs to be accomplished
•    Set up standards for results and control
•    Divide the project or task into segments that can be delegated
•    Know your employees, their qualifications, expertise, strengths and weaknesses
•    Decide who will be assigned what tasks
•    Explain standards of expectation and limits of authority
•    Let capable employees determine how to achieve the desired outcome
•    Expect people to make mistakes, but don’t count mistakes as crimes

Feel Comfortable Solving Problems and Making Decisions

Supervisors solve problems of all kinds every day.  It’s part of what they are paid to do along with making decisions.  The two processes are related; one requires the other.  Decision-making is the process of choosing between two or more alternatives.  The impact of the decisions you make can be far reaching, depending upon the type of decision you need to make.  Some decisions are spontaneous while others require considerable planning.  Following a step-by-step process will make problem solving and decision-making easier for anyone who has this important job.  The six steps of the problem-solving process are:

• Be aware of the problem; know what’s going on around you.  In some cases you can handle the potential problem before it occurs.  State the problem in writing.

• Discuss possible solutions.  Brainstorm, seek advice from others including experts, find out what’s been done in the past to correct the problem, form a task force, and don’t be afraid to get creative.

• Evaluate the possible solutions.  Compare the costs and benefits of each.  Of each possible solution ask yourself: “What will be the consequences if this action is taken or not taken?

• Make a decision.  You will be choosing one of the possible solutions.  If you have followed this step by step process, you should not be afraid to make a decision.  Avoid delaying the decision out of fear.

• Evaluate the outcome of your decision.  Was your objective met?  Was the problem solved without creating more problems?  Did productivity increase?  Did performance improve?  Was the decision a good decision?

In summary, moving from IT expert to IT supervisor is not about running a popularity contest.  Your goal is to develop and refine your leadership skills.  You will need them for survival.  Successful supervisors are confident, direct, caring and honest.  They respect people and know how to interact, delegate, empower, solve problems and make decisions.  If this is your first assignment as a supervisor, you have a lot to learn.  However, you can do it if you are committed and open to constructive feedback.  You may not always agree with what others are telling you, but it comes with the territory.  Good luck and have fun!

About the Author: 

Carol Hacker is the former Director of Human Resources for the North American Division of a European manufacturing company, Employee Relations Manager for the Miller Brewing Company, and County Office Director for the US Department of Labor. Headquartered in Atlanta, GA, Carol has been the President and CEO of Hacker & Associates since January 1989. She specializes in teaching managers, supervisors, team leaders, HR professionals, and executives how to meet the leadership challenge. Carol is the author of over 400 published articles and 14 books including the bestseller, Hiring Top Performers-350 Great Interview Questions For People Who Need People. She earned her BS and MS with honors from the University of Wisconsin. She can be reached at www.carolahacker.com or 770-410-0517.

Posted in: 
Hiring Manager

Transitioning From IT Expert to IT Supervisor: Part I

“Congratulations!  You’ve just been promoted to Supervisor.”  These are the words that many people long to hear because it typically means more money.  However, it also means more responsibility and a change in the kinds of things you are expected to do on a daily basis.  Excitement and challenges await you, but are you prepared to EXCEL as a first time IT supervisor?

This article is not meant to be all-inclusive, but it will cover the highlights.  Let’s start with leading a team of people when you’ve been promoted over them.IT Expert to IT Supervisor

Promotion Over Peers

You are an IT expert who has been promoted over your peers and now you have to lead them.  They may resent the fact that you were selected for the job instead of them.  Or, they may feel that now that you’re the boss that you will no longer be their friend.  Start by meeting with your staff immediately and discuss what’s happened.  Here are some ideas to help you get started.

• Acknowledge the fact that some of them also applied for the job and were qualified.

• Tell them how much you are looking forward to working with them in a new capacity.  In a positive and friendly manner, discuss how your role has changed.

• Help them to understand that you haven’t changed; only your role has changed.

• Because your role has changed, your relationship with them has changed.

• Tell them how much their friendship and support means to you.

• Let them know that one of your goals is to be fair and impartial toward everyone.

• In return for your support of them, you are asking for their cooperation and willingness to do a good job for you.

Establish Your Authority

Whether you’ve been promoted to management from within or are joining the business as a new IT supervisor from outside, don’t think that your employees will automatically respect you.  You will have to earn it—one employee at a time.  Establishing your authority is critical to your success.  It’s something you must do quickly.  Consider the following.

1. Get to know your staff if you don’t already know them.  To effectively manage them, you need to become familiar with their strengths, shortcomings, and what makes them want to put forth their best effort.  You can do this by meeting with your employees as a team and then follow up with one-on-one discussions.  This is also the first time and best time to share your background, expectations, and goals for the team.

2. Resist the urge that many new supervisors have to make lots of changes shortly after moving into management unless you’ve specifically been hired to do so.  Give yourself time to establish your authority and gain the respect of your employees before making major changes of any kind.  Ignoring this advice can lead to disaster.

3. Express confidence in your team’s ability to meet or exceed expectations.  Let them know that you will do whatever it takes to help the team reach its goals.  Don’t lose sight of the fact that you will become successful by helping others become successful.

4. Gradually give directives.  One of the first and biggest mistakes first time supervisors make is ordering people around.  After all, you’re the boss, right?  Wrong.  You may be the new supervisor, but you need to build credibility.  You can do this by first giving instructions that they are accustomed to receiving and then gradually move to new and more challenging directives.

5. Be confident in yourself.  It’s normal to be apprehensive, especially when you’ve been promoted to supervision.  However, if your lack of confidence is apparent, it will be difficult for your team to accept you and your authority.  On the other hand, don’t let your confidence be perceived as cockiness.  If that happens, you’ve lost them, oftentimes for good.

Make a Habit of Consistently Communicating

Frequent and meaningful communication is essential if you want to quickly excel as a first time supervisor.  It starts with being a good listener and includes, but is not limited to the following.

1. Listen for understanding.  Some supervisors spend more time talking than listening.  In reality, it should be just the opposite.  Good listening requires concentration and a sincere interest in hearing what others have to say.  It’s a skill that requires some effort, but it will reap rewards for years to come if you are truly interested in listening in others.

2. Make sure your communication is crystal clear.  Don’t assume anything.  Keep in mind that you can never over-communicate.  Most employees believe that their supervisors don’t give them enough information on a regular basis.

3. Be aware of your body language.  How we act speaks louder than what we say.  Non-verbal communication is about eye contact, facial expressions, gestures and body posture.  Inconsistency in your verbal and non-verbal communication sends mixed messages, something you definitely want to avoid.  Your goal is to motivate a change in behavior and/or performance.

4. Learn how to give feedback without causing defensiveness.  This is another skill that deserves attention.  Practice and a desire to learn how to give critical feedback without alienating the receiver is an important job that falls on the shoulders of every supervisor.  Coaching someone to complete the task they’ve been assigned in a quality manner should be a goal for which you strive.  Get off to a good start by learning how to do this well from the beginning of your career as an IT supervisor.

5. Delivering critical feedback is only one side of the coin.  Provide plenty of positive feedback.  Research shows that most employees feel that they don’t get enough positive feedback from their supervisor.  Yet, we also know that a few encouraging words on a regular basis is often more meaningful than a monetary reward.

6. Make a commitment to manage by walking around.  Be visible and approachable.  Don’t fall into the trap of being “too busy” to interact with your team on a daily basis.  If you’re not comfortable with talking to people you are in trouble.  Your interaction with your employees is extremely important if you hope to excel in your new position.

Stay tuned for Part II of this blog, which will be posted next week.

About the Author: 

Carol Hacker is the former Director of Human Resources for the North American Division of a European manufacturing company, Employee Relations Manager for the Miller Brewing Company, and County Office Director for the US Department of Labor. Headquartered in Atlanta, GA, Carol has been the President and CEO of Hacker & Associates since January 1989. She specializes in teaching managers, supervisors, team leaders, HR professionals, and executives how to meet the leadership challenge. Carol is the author of over 400 published articles and 14 books including the bestseller, Hiring Top Performers-350 Great Interview Questions For People Who Need People. She earned her BS and MS with honors from the University of Wisconsin. She can be reached at www.carolahacker.com or 770-410-0517.

Posted in: 
Hiring Manager