For example, a colleague with tons of project management just took a CSM (Certified Scrum Master) course. She’s no dummy. She’s used these ideas before. Timeboxes are not a new project management idea. Finishing small chunks works are not a new idea. (I wrote my inch-pebble article in 1999, and my iterative planning article in 1997. I’d been practicing these ideas long before. I bet my colleague has, too.)

The real problem is that too many hiring managers do not want to do any on-the-job training for people who may well have the right preferences, qualities, and non-technical skills. This is so short-sighted of them, I can’t begin to say how wrong-headed it is.

In I Like My IT Budget Tight and My Developers Stupid, Lisa Vaas has a great quote:

The first technical person I hired last summer was somebody with very little experience, but I saw raw talent. I hired him to basically learn on the job. I haven’t provided training, but he’s dramatically increased his skill set since being hired, just by working.”

You will need to do some explaining. No lying, please! But you will need to explain how you and your attitude are right for their job.

Do you have more examples? I am happy to add them to the table above and to the eventual ebook.

As part of the problem solving, I asked him to send me the job analysis and the ad. When I looked at the analysis, I could tell why. He’d done a job analysis, but to me, it looked like a surface attempt.

We reviewed his job analysis and iterated on it. Armed with a more detailed analysis, he rewrote his ad, which is now running. I don’t have data yet on whether this ad is helping potential candidates screen themselves in or out. Certainly, the hiring manager will have be able to tell faster with his phone screens.

If your ads are not working for you, first look at your job analysis. Iterate on it. Ask other people to review it. See if it’s detailed enough for you to write a job ad from it. It might not differentiate the essentials from the desirables. It might not differentiate the levels enough. It might ask for too much in a junior level person, which is why more senior people are applying.

Remember, your job analysis is your user story for everything you do next. You don’t have to be right the first time. You do want to use the feedback of not-quite-right candidates to refine your job analysis and job ad. Take your time and make the analysis right. Iterate on the analysis. Then your job ad will work for you.

First, there’s the well-meaning manager who wants a current tester to be “motivated” to do manual testing. “How do I motivate him to do manual testing?” was the question. I asked, “What’s that person doing now?” “Automated testing.” “Why would you have the person do manual testing??? If you have someone who is more capable, why would you ask that person to do less than their capabilities?” “Because the other people aren’t as capable and  I want everyone to feel like part of a team.”

Asking someone to do less than they can is not the way you make a team. The way you make a team is by having people work together, committing to each other. If you are not sure of the work you need done, you do a hiring strategy and a job analysis.

Next, there’s the director who marched an automation expert to HR to fire the expert because he wouldn’t do manual testing. Now, I have no idea if this guy was warned or if there were any other issues, but my goodness, test automation engineers are few and far between, and he seems like a reasonable enough guy. Firing someone because you are a bad manager is more bad management. Firing a rare person is the height of stupidity.

And then there is the organization who thinks that they must be the best organization in the world to work for, especially in this economy. They specialize in taking young idealistic people, putting them to work in entry level jobs, and making them turn off their brains for a year. If they are lucky, they get to do something useful the second year. In the meantime, all these bright people can do is see the waste. And look for a new job. And, because they have a year of experience at a known organization, they will get a new job. The organization’s HR policies do not allow these bright young people to look for a job inside the organization until they have been there for a full year. By that time, these people are so dead inside, who can wait to look for a new job? They’ve had their fill of bringing self-important know-it-alls coffee and lunch and setting up meetings, and printing (yes, printing) email.

All of these situations could be avoided by first defining a job strategy and then defining a job analysis. If you over-hire for a job, you will hire someone overqualified for a job. Although, I honestly do not understand how you can have a software product and not need test automation people.

If you over-hire, do not expect to have happy people. Do not think you can do team building by having people work below their capabilities. But you have a very interesting option: building a community of practice.

If you have one “overqualified” person, why not use that person to help bring other people’s capabilities up? Is that reasonable? I don’t know. Can you use those capabilities in your context? In the case of the software organizations, I know that they need test automation. I’m perplexed about why they would move from automation to manual scripted testing. These are the same organizations complaining about shortened schedules, insufficient people, technical debt, and how it’s so hard to get anything done. Why would you cripple a group by removing a tool (test automation) from the toolbox? Why would you remove a person with more capability? There’s gotta be more to this story.

Managers, look at yourselves. Do you think you have “overqualified” people? Are you tempted to dumb them down? Consider your other alternatives. You can pair a person with more capabilities with a person who wants to learn. You can create a formal community of practice. You can invite people to learn from each other informally. And that’s just three options.

These stories are all true. I wish I had the imagination to make them up. But not in my wildest dreams could I imagine managers thinking this way. Managers, “overqualified” employees are not a threat to you. Great people reflect well on you. They make it possible for you to get more work done. Nurture them. (Ok, if they are jerks, give them feedback, but we all need help on our interpersonal skills. We are technical people.)

I don’t recommend hiring people who are overqualified. But if you find yourself in a position where you have people who appear to be more than you need, find a way to use them for the betterment of the entire team. Whatever you do, do not ask them to dumb themselves down, to give up their capabilities. They will leave. And, they will tell people why. Do you want to be known as the organization or the manager who couldn’t handle a smart employee?

Is the coach going to be developing? I hope not. Testing? I hope not? Let’s see. The hiring strategy for an agile coach is that you need someone with great problem solving skills, skills learning your technology and product, the adaptability to fit into your group and the cultural fit to fit with your people.

In a job analysis, I would expect someone with substantial initiative and flexibility. Someone who could take technical leadership, but not always make it look like he or she was the leader. Someone responsible and independent, but responsible to the team. Someone who can work with a team of 3-7 and work individually. Someone who can help the team see what they are doing, without offending the team members.

I would expect the coach to sit with the team members to help them split stories, to help them see how to automate the system tests. I would expect the coach to help the team members learn how to create acceptance criteria. And, if the team members don’t already have unit tests, to help the team members write unit tests.

I would expect a coach to know some programming language because otherwise it’s too difficult to speak the language of the developers and some of the questions are too code-centric. I would also expect the coach to understand the way testers think about testing and how to automate tests and when not to automate tests, because otherwise it’s too difficult to speak the language of the testers. I would also expect the coach to be fluent in potential metrics such as burnup charts, burndown charts and cumulative flow diagrams, and when to use regular agile boards and when to use kanban boards to show bottlenecks better.

I am suspicious when a job opening wants an agile coach to know a specific programming language that they don’t want an agile coach. I suspect they want an extra pair of hands. That’s okay. Well, it’s not, but if the coach knows what he or she is getting into, maybe it’s okay. That position is not an agile coach. It’s a something else.

Maybe there’s a darn good reason for this position to ask for a specific programming language. I’m dubious. Seems like an overconstrained job description to me. But what do I know? I’m just an agile management coach (among other things).

In Hiring the Best Knowledge Workers Techies & Nerds, I have a section about what to do when you don’t know the essential technical skills, as in when the job is new to you. You have several options:

1. Ask someone who does already know what the job entails, someone who already manages that job in another organization.
2. Ask a recruiter for help defining the description. Use this with care, to make sure the recruiter does not over- or under-inflate the necessary skills.
3. Use analogy. If you know the essential job functions, use analogy to explain what you need a candidate to do, even if you don’t know what to call the job or what the essential technical skills are
4. Use a compensation survey to see if the job title is listed. Use this one with caution too. Once HR is involved, they might try to make the position more or less than it should be.
5. Ask a potential candidate, like Jack, what the job description should be!

Not everyone needs a knowledge management person. And don’t get me started on social media guru. I have no clue what that is or why anyone would need one. I understand why companies need Jack. If you have a product development process or a manufacturing process and it’s stuck somewhere, you need Jack. He’ll figure out why and help you unstick and keep you unstuck (that’s the knowledge management part). That simple.

But the bigger lesson is that it’s really hard to see how to define these roles. Especially if the role is not neatly tied up with a ribbon and comes with a generic job description. Not all the work in the organization can be done by people with generic job descriptions.  In fact, I would say, that none of the knowledge work in the organization can be done by people with generic job descriptions. And that goes for administrative assistant help too. Who do you think really runs the organization?

So, when you have a new kind of job, don’t throw up your hands in despair. You have options for analyzing the job. Consider which ones are right for you.

To change “easy-going” into abilities, I asked what easy-going looked like. The person said, “Relaxed in the interview.” I asked if the person would just interview or do other work. “Do other work.” We went back and forth for a bit. So then I asked “Would this be more accurate: able to keep his or her head in the midst of chaos?” Yes, that was it.

That’s different than easy-going. It’s something specific to the organization (which is good), and you can ask for examples in behavior-description questions.

So if you see adjectives, think about the deliverables and activities the candidate will have to do. Then see how to describe that in terms of abilities. You’ll have a better description and be able to ask better questions.

Many years ago, I was working as a “senior member of the technical staff.” I was a tester, had coordinated beta tests, much of the testing work for the last couple of releases, and was working as the tester-project-manager and helping the project manager realize what her job was. My boss left the company. I was “obviously” the next one in line for his job. I didn’t get the job. When I asked why not, I was told “You’re too valuable where you are.”

That’s a non-answer. But I did talk to my new boss, and told her I wanted to know what I needed to learn to get the promotion. She smiled and said, “people skills.” Ok. Clearly not my strengths, but I figured I could learn. I told her I wanted her to teach me. She agreed.

I put away my resume and stayed at the company another 4 years. I learned how to be a great manager. I learned how to be a great program manager. I learned how to do strategic planning, both the stupid way and ways that made sense. I doubt I would have learned how to do any of those skills that quickly without my new boss’ coaching and mentorship.

Managers, telling people they’re “not ready” or “too valuable” is a cop-out. Provide authentic feedback, offer to teach/coach/mentor, and you will have a loyal employee who will amaze you.

I stayed because I asked why and because I learned what I needed to learn. If you’re frustrated with your job, maybe it’s time to ask why, before you go look for a new one. Ask. What can you lose?

When I hear testers say, “I control the release” that’s a red flag for me. Testers provide information. The release decision is way above their pay level.

When I hear business analysts (or anyone!) say, “I just know what the customers want. I don’t have to go back and talk to them.” Oh yeah? If they’re so clairvoyant, why doesn’t all software work the way I want it to?

When I hear architects say, “I don’t write code. I architect a system.” Oh sure they do. On paper. Or in PowerPoint (full credit to Venkat and Andy for naming these people PowerPoint Architects in Practices of an Agile Developer). Architects who don’t participate in product development are just as bad as house architects who never use the bathrooms they “design.”

Red flag words are an indication that the candidate is not sufficiently introspective about why the company pays him or her. You might still want to hire a candidate with red flag words, but you’ll have to work with that person to make him or her a fully valuable member of the team.

This almost happened to me today. I’m the conference chair (the program manager for the whole conference) for Agile 2009 (in Chicago, August 2009). Internally, I think that position is called “program director”–but I’m not selecting any part of the actual conference. The program piece is that the position is like a program manager position. I asked to be called the conference chair instead. That’s what I’ll be calling myself!

If you have internal names for jobs, that’s fine. Keep the internal and external names separate.

But the piece Lisa missed is integrity. Without integrity, the other qualities, preferences, and non-technical skills are useless. To be fair, she implies it in her post. But I like making it explicit, because then I can ask questions such as, “Have you ever been in a position where the company wanted you to do something that went against your integrity? What happened?” If you want to ask about what the person learned, ask, “What did you learn from that experience?”

It’s possible that less seasoned managers have not been in an integrity-binding position, yet. I have yet to meet a manager who’s been managing for more than a couple of years who has not been in this position. When I’ve been in a position to hire managers (or to be hired as a manager), I want to know how the candidate has performed while in the integrity bind, or how my potential managers have performed.