From the Ask Tom mailbag.
When you talked about interviewing for “fit” with our company culture, you said that we should interview for behaviors. I understand what you mean, but I don’t know what the questions sound like.
Creating interview questions for candidate traits like fit, values and attitude just takes a couple of steps. First, we have to translate the warm fuzzy into a behavior. Let’s start with “fit,” since that is the one you asked about.
Ask yourself the question, “How does a person who fits our culture behave?”
I work with a company that has a real sense of urgency in everything they do. People show up to work early, they start projects early, they return phone calls quickly, they turn paperwork around fast. It is a real culture of “gitter done.” People without that sense of urgency don’t last long at this company. It is an important area to interview for.
So, step two is to ask the person about those critical behaviors. Here is how it sounds.
Tell me about the working hours at the XYZ company? In your position, what time did you arrive for work? In your position, what was the most productive time for you?
In your position, what kind of customer interaction did you have? How many phone calls per day did you receive? How did you handle that phone call volume? When you could not answer a question in the first phone call, what was your system to make sure you returned the call later with the answer?
In your position, tell me about your paper workload. What kind of paperwork did you handle? How quickly did it pass across your desk and on to the next step? What was your system for handling that paperwork?
Remember that the purpose of these questions has to do with behaviors that “fit” the culture. I am not looking for the correct way to run an “in” basket. I am looking for momentum, energy and action, because those are important to “fit” in our culture.
Many years ago, I started a job as a contract manager, and it became clear I had a big problem. I had developers who knew one area of the code well. I had testers who knew not much of any area of the code well, even though they had worked for the organization for many years. Why? They had been shuffled from one project to another almost every month for years.
The writers had more domain expertise than anyone, because they had learned the product from end to end. What was I going to do? This project needed to finish in eight weeks, I needed to hire my replacement, and the people were shell-shocked from one manager after another. I was the fourth Director of Software Development in six months.
I decided to make a project portfolio, and rank the projects to know which projects were first, second, and third. I knew about this first project, but what was second and third? I was sure we had more crises, waiting.
Next, I asked people what they wanted to work on. I was sure that people could select their areas of responsibility, and it would work out. This is before we had agile teams. I was using a staged delivery lifecycle, so we had cross-functional teams and we worked by feature.
Next, I asked the teams to develop their deliverables in two-week chunks: what deliverables, as in features, could they deliver in the next two weeks, working as a cross-functional team?
The teams started to work together. They started to work across the code, not just in one area of the code. It wasn’t perfect, but it was working. The testers expanded their knowledge, because they were able to focus on the entire product. The developers learned the product end-to-end. The writers were happier, because people answered their questions.
About three weeks into this, a crisis happened with the second-ranked project. A senior manager wanted to yank a bunch of people off the top-ranked project and put them onto the second ranked project. He told me I had to give him people.
“No. I have no one for you.”
“But you work for me.”
“Yes, I work for the organization. But this project, the one that everyone is on, is more important than your project. So, I have no one for you, and I won’t for another two weeks. Unless I hear from the CEO that your project is more important than this one. In that case, we will stop working on this one, and everyone will work on your project.
We only have eight people. We can’t multitask. We can only work on one project at a time. Moving people off and onto projects as if they are chess pieces doesn’t make sense. This top-ranked project has two more weeks to go, and then it’s done. When it’s done, I can assign all eight people to your project, no problem. But assigning them now? Craziness.”
Now, should I have called him crazy? That was darn close to a career limiting conversation. Don’t do that! But the rest of the conversation? Useful.
And that’s the topic of this month’s Management Myth #18: I Can Move People Like Chess Pieces. When you move people like chess pieces, you deny them the opportunity to learn domain expertise. You don’t manage the project portfolio, and you decrease the capacity of your organization. It’s all around bad.
Did I want to be nice to the senior manager? Of course I did. But, good management is not about being nice to everyone all the time. Much of management is about saying no when you have to. And, I really needed to say no.
With agile approaches, I would have had more options: I could have used iterations and sequenced the projects differently—maybe. But that would not have allowed the organization to release the top-ranked project in the next few weeks. It would have made the people feel horrible, as if I’d yanked the promised dessert away from them. Yes, the project was that close to completion.
While you can move people as if they are chess pieces, it’s rarely a good idea. You want to leave people with project teams, to let them create a solid team—that’s the forming, storming, norming part. And, you want to keep people on a product long enough that they develop significant domain expertise in the product. When they become bored and ask to move, then they will tell you in a one-on-one that it’s time to move.
In the meantime, don’t move people as if they are chess pieces. People need to develop mastery over their work. They need the autonomy to select the areas of their work that they will develop domain expertise in. They need to feel as if they have a sense of purpose about the work. Gee, it sounds as if I’m parroting Dan Pink, in Drive. I guess I am. When you commit to project teams, and leave people where they are, so they can learn the product and learn how to work with their teams, and let the work flow through the teams, you create an environment that allows for autonomy, mastery, and purpose. And, that’s part of what a great manager does.
It's amazing what a few days away can do to clear one's mind. A little time in Rocky Mountain National Park, followed by some time in Wyoming and South Dakota were just what the doctor ordered.
Of course, I like to start at the end of the trip, and the last full day was spent in the Black Hills, enjoying Mount Rushmore and Crazy Horse. Both of these monuments astound me, not by their magnitude and beauty, but by the effort undertaken to appreciate their creation. Gutzon Borglum led the effort to create Mount Rushmore, an effort which took over a decade. Recruited from the Rushmore crew by the Lakota, Korczak Kiolkowski worked on the Crazy Horse monument for decades until his death in the 1982, and it is now carried on by his children and grandchildren (all without Federal funding, I should add).
What fascinates me about both projects is the passion of the workers. The topic of professional love has been at the front of my thinking of late. Most of the time, our projects are measured by weeks or months, for others, projects may last a few years, but many of us in the profession are time boxed because our executives are anxious to get things done and move on to something else.
For some the work was just a job, but for others it became a special calling.
"More and more we sensed that we were creating a truly great thing, and after a while all of us old hands became truly dedicated to it," Red Anderson, Mount Rushmore Carver.
There was plenty of time to become an "old hand" as the project stretched from 1927 to 1941. As for Crazy Horse, the first rock was dynamited in 1948, and the project is still underway. During the introductory video, we learned that project is measured in "tons (of rock) and decades" rather than the weeks and months and deliverables by which we measure current projects.
So what are YOU doing to instill passion in your project teams, especially when the project seems to drag on "forever"? On my last project, we tried to build in appreciation for the installation team spending several weeks on the road. They were the real heroes of the project, traveling to numerous locations across almost a dozen states. But they also knew WHY the project was important. They saw the importance of the end result. And it was that belief which drove them to success. Very similar to Mount Rushmore and Crazy Horse, the best way to build passion for a project is to provide the workers at all levels a view of the future and what it means.
I read this piece, The War for STEM Talent is a Lie. I agree. Until we do all of these things:
Then I don’t think we have a war for STEM talent.
If you can’t find people for your open position, you are not looking hard enough. You have created a job description that does not fit your job. You are not looking in the right places. You are not thinking about how to create a job that fits the profile of the people who are available.
Now, if you are a candidate, you must act, also. You cannot think that the skills you learned 20 years ago are still valid. What have you learned today? Have you thought about the Depth or Breadth of your career lately?
If you are trying to hire someone, extend your thinking.
If you are trying to become hired, make it easier for your potential employers to hire you. Differentiate yourself with new skills that you have learned with practice. Practice on open source, or with internships, or something. Show potential employers you are learning.
Read the hiring strategy chapter in Hiring Geeks That Fit. (That chapter is in the sample book.) Read the chapter called “Move Forward” in Hiring Geeks That Fit that talks about what to do when you can’t find someone.
But most of all, think about what you are going to do. This is a problem you can solve.
Now, we were in a pickle. Our top salesperson for last year, $450,000 in gross sales, was on the chopping block to be fired.
In January, he had been promoted to sales manager, moved to a guaranteed salary equal to last year’s total comp, and now he was failing. Relieved of all, but the most critical accounts, he was supposed to be leading the sales group, holding meetings, inspiring, helping others to set targets and holding them accountable. As a salesperson, he was great, as a sales manager, he was the pits.
Classic mistake. Take your best producer, whether it is in sales, production or research and make them the manager. Management requires a totally different skill-set, with a high interest in getting people to work together, miles apart from producing technical work.
Once done, tough to get undone. No one likes to move backwards. Most importantly, whose fault was it?
There is a quote from George Box that is used - misused actually - by many populist blogers and authors that goes like this...
All models are, some are useful
Of course this quote is used to avoid asking and answering questions around models, forecasting, and assessment of possible future states of systems, a project being a system.
The actual quote is from Science and Statistics, George E. P. Box, Journal of the American Statistical Association, December 1976, pp. 791-799.
But how simple? That's always the challenge.
The nonsense that #NoEstimates is the answer is of cource just as foolish as overparameterized and overelaborated models. This of course is lost on both sides of the modeling discussion.Related articles Models ... Calling BS on "All Models Wrong" Everything is a Random Variable Models All models are wrong
Marge was frustrated. “I am fed up to here,” she stated flatly. “”I spend more time correcting than I do controlling the work.” She had just paid a visit to the shipping dock. Four orders, mis-packed and two orders with the wrong ship address. Luckily, the errors were discovered before the freight company picked up, but the orders would now be delayed another day.
“What do you think the problem is?” I asked.
“Well, Martin just doesn’t seem to be catching on. He has been here for five weeks, now, and I swear it’s like he is still in his first week. He is supposed to be matching and proofing orders and picking tickets, catching mistakes before they get out the door.”
“When you look at his job, how would you describe the longest task he has to perform, longest in terms of time frame?”
Marge thought for a minute. You could see some insight wave across her face. “He gets an advance report every Monday that looks two weeks out for orders and their target ship date. It’s like a rolling two week calendar. Of course, the orders during this week are much more definite, but we want him to think out two weeks.”
“And how far in the future do you think he is working?”
“Oh, no more than one day. If you ask him about tomorrow, you get that deer in the headlights look.”
“Did you ever think about that when you hired him?” I asked.
“No, he had experience as a packer, but not as a supervisor. I never thought it would be that big of a deal to really control what was happening.”
“Marge, don’t feel bad. Most companies underestimate the time span required for success in the job. And if you key in on time span, you can get much more specific about the level of the person you need. Here is the key question. When you look at the job, how would you describe the longest task the person has to perform, longest task in terms of time frame?”
“I need each of you to become an author,” I said. The management team looked at each other. I saw a set of eyes roll in the corner. I smiled.
“I need each of you to write a story.” I stopped for dramatic effect. “The story will only be four sentences long.” I could see a silent sigh of relief wave across the room. “In fact, we are going to write that story right now. To make it easier, you will all work with a partner. So, pair up. Let’s get going.”
We had been working on how to communicate our list of values throughout the organization. The idea was to create a story, four sentences long, that captured a positive example of a behavior aligned with one of the values the group had selected. Each manager in the group would be an author. In the room, we had vice-presidents, managers and supervisors. All told, twenty-three members of the management team.
Once each week, a story, written by a member of the management team, would be included in the weekly paycheck of each employee in the company.
In ten minutes, twenty-three stories were created and signed. We had a volunteer from the clerical staff to collect and type them all up. We were covered for the next twenty-three weeks. Better than a teamwork poster on the wall. Meeting adjourned.
When I taught that one-day workshop in Sweden, one of the questions we discussed was the number of essential skills to list in a job analysis, and by extension, the job description. Too few essential skills, and you don’t differentiate your position from anyone else’s. Too many, and you over-constrain the role. Surely, there must be a “Goldilocks” approach, right?
I suggested you start with three or four essential qualities, preferences and non-technical skills. Just three or four. Remember, these are essential. You can always add more desirable qualities, preferences, and non-technical skills. You want these for cultural fit.
Next, think of the technical skills: functional skills, domain expertise, industry expertise, and tools experience. Now, think of no more than three technical skills that you require as essential.
Now, you have plenty of essential skills. Plenty. More than that and you have over-constrained the position and you will make it impossible to hire.
If you are taking more than six weeks to hire for one of your open positions, review your job analysis. Do you have more than three essential qualities, preferences, or non-technical skills? Pare them down, and consider which ones are desirable vs. essential. Do not keep too many qualities as essential. You are kidding yourself, unless you are trying to hire a very senior person for a ton of money.
Do not over-constrain your job descriptions. Spend a little time analyzing your job, and you will hire fast and well.
As I walked through the entry way to the lobby, I noticed Miguel had posted the list of values in a cheap plastic frame next to the Mission Statement. I ducked into the conference room. Miguel sat up. “I know, I know,” he said. “At least it’s a start.”
I stared at him. “No impact. It’s not even a start!”
The rest of the management team huddled around, taking their places at the table. “Look,” I continued. “You have done a lot of work, but until you breathe some life into these values, communicate them as part of your culture, you might as well have stayed in bed.”
We worked the values list for thirty minutes, and in that short time, a series of ideas was constructed. There were details and accountabilities.
Hiring topped everyone’s list. That meant identifying behaviors connected with those values and constructing interview questions for those behaviors. We spent ten minutes brainstorming those questions. Interestingly, that ten minutes revealed more about the meaning of those values and how they would positively impact culture than any framed poster on the wall.
On teamwork, we asked ourselves, “How does a person behave, who values teamwork?” Then we constructed questions for those behaviors.
We amplified those questions by circulating an email copy to several other committees and groups in the company. We got lots of feedback and suggestions for more questions. Values are important, but you cannot interview for values, you can only interview for behaviors (connected to those values).
I've concluded the #NoEstimates advocates have difficulty stating the domain and context in which their exploration is applicable. Without a Domain and a Context in that Domain, it's difficult to have a conversation about the merits of the idea.
Can I apply it to embedded flight control systems? How about emerging databases for nuclear safety and safeguards? Enterprise health insurance processing? How about pipeline right of way document management? Maybe editorial systems in media? Turbine controls, emergency shutdown, fire and gas monitoring? Radar signal processing?
You see the problem, right? General claims like making estimates is a waste of time seem to beg the question - in what domain? Answer comes back Software Development is a domain. Ah, not really. Kinda ends the discussion doesn't it.Related articles Complex Problems Require Better Solutions Estimates and all that... Estimate Anything
“It’s a good list,” said Miguel. The list had emerged from a values exercise the week before. After an extensive word pairing process, some heavy lobbying, push back, protest and negotiation, this was the list that made it.
“So, now you have a list,” I said. “What do you do with it?” Miguel’s eyes brightened, then his brow furrowed.
“I’m not sure. I guess we could print it out on fancy paper, frame it and put it on the wall next to the Mission Statement.”
I stared straight at Miguel. “Dude, you are going to have to do better than that.”
Miguel nodded in agreement.
“Get your team back together and take this to the next step. If you want to create a positive culture, you have to live by your values. Everything you do as a company should support these values. You have to identify the stories, the examples and the people. Then you have to amplify them. You have to amplify them in meetings, newsletters, memos and emails.
“Get your team together and figure it out. In what way can we communicate our values and the behaviors connected to those values to every person in the company. Frequently.”
I gave a talk last week at Better Software/Agile Development, called Exploding Management Myths. This is my first talk based on some of my management myths. Yes, the ones I’ve been writing for the last 18 months. Yes, I have more in me :-)
I have posted the slides and the audio from my talk at slideshare. I still cannot understand how to properly sync the slides and audio at slideshare. I don’t talk evenly, which is what slideshare expects. I tried to separate the slides and audio. Can’t do that either. Grumble, grumble. However, it’s posted, and if you download the slides and then listen to the audio, you can manually sync the slides and the audio :-)
If you have a favorite myth that I have not yet addressed, please let me know. I will write about it.
I really need help from you. I need a title for the eventual book. Everyone talks about debunking myths, so I don’t think I want to go with debunking. I thought it might be “Exploding Management Myths.” Maybe. Doc List suggested it might be “Blowing Up the Bullshit.” Maybe :-) Do you have ideas for the eventual title for this management book? I would like at least a few more options.
Twenty three people milled about the room. We had gathered together to talk about culture. Culture is that unwritten set of rules that governs our behavior as we work together. With such a large group, from vice-presidents to managers to supervisors, we broke into six smaller groups so quick discussions could occur. The CEO was in the back of the room with strict instructions to simply listen.
“On the table, everyone grab a little stack of sticky notes. Please identify five values that you believe are important in guiding our behavior as the company works together. Write one value on a separate sticky note.” Within 90 seconds, most had completed the assignment. Each small group was given another 90 seconds to share their responses, to make sure each person had five sticky notes. We were three minutes into the meeting.
“We have a big white board up here. I know it will get noisy, but everyone stand and come stick your five values to the board. Once all the notes are on the board feel free to group all the duplicates together and then sit down.”
And so the room was thrown into chaos for a few minutes. In the end, 62 different values were represented on the board. Those 62 values were quickly and randomly rearranged into 31 pairs of words.
“This next step is like a double-elimination tournament for a softball game, only quicker. For each random pair, we are going to vote on which value best represents what we want for our collective culture. The winners will go on one side and the losers on the other. Then we will pair all the winners and pair all the losers. To get off the board, the value has to lose twice, so a losing value could earn its way back to the winner’s side of the board.”
The voting went quickly. As the selections went from 62 to 31, down to 12, we then broke into group discussions to get the last 12 down to six. Groups were allowed to advocate for their most important values. In the end, we had five values, with very clear understandings what behaviors were connected to each. The process had taken an hour and a half. Our next meeting was scheduled for the following week.
Shim has asked a question - a recurring question - about having a PMP. Since everyone is selling all the time - it's part of being human. There are those in the community that encourage a PMP. There are those who oppose the PMP on principles. There are those selling alternatives.
Here's my sales pitch for a PMP
The #NoEstimates notion has merit in the right domain. If you're looking for motivation for estimates outside of the domain where the customer doesn't really care about the final cost, just the final product developed inside a "level of effort" budget, look here and remember.
When you are spending other people's money - billions of dollars of other people's money - you'd better have a credible answer when they ask "how much is this going to cost and when will you be done? This is separate from "will I get what I asked for?" That's another topic all together.
PMI and most other project management educators use the notion of the Triple Constraint - Cost, Schedule, and Scope. This is sometimes called the Iron Triangle. It is call Iron because when you change one thing, the other two change as well. This has been talked about here before.
Cost we know about. Cost starts with the Budget and then includes the Actual Cost of performing the work - consuming that budget. Schedule is the same. We have a Plan and we execute the project against that Plan. As the project proceeds, we are either on plan or off plan. That is we are ahead or behind schedule.
Scope is supposed to be a description of the deliverables from the project. The Outcomes of the projects schedule and budget. But in the PMI vernacular, scope fails to explicitly include several things.
These are all wrapped into the word scope. Here's a better way to look at the Triple Constraint.
The management team was assembled in the conference room. Culture was the topic of the day.
“You can either try to get people on board with your culture, or you can build the culture that people want to get on board with. Which is it going to be?” I asked.
Since Miguel called this meeting, everyone looked at him. The silence worked its discomfort. I broke the group into teams of two. Erica’s team was the first out of the gate.
“I don’t think you can talk people into it. The culture has to make personal sense and they have to believe it is really true. People can smell a pig no matter how much lipstick is on it.”
“What do you mean, it has to make personal sense?”
“I mean the values of the company have to be close to the values of the person. If there is a conflict, either the company has to change or the person has to go find another company.”
“Do you think culture comes from values?” I continued to probe.
Erica wasn’t sure where this was going, but she had already stuck her neck out. “I think culture is the collected values of every person who is a member of the group. Culture is that unwritten set of rules that governs our behavior as we work together. It sets the expectation, creates the environment in which we work.”
“So, would you agree that the first conscious step toward a positive culture is to actively collect the values of each member of the group?” I stopped. “A little scary, perhaps. Until we collect the values, we can get away with ambiguity. Once we collect the values, there is no place to hide.”
Here is a handbook for developing credible Integrated Master Schedules. There are many suggestions but this one comes from the place where schedules are critical.The Train Wreck of all Projects Starts With These Problems Scheduling Guides Unrealistic Cost and Schedule Estimates Uncertainty is the Source of Risk Probabilistic Cost and Schedule Processes
“I guess I am feeling a little burned out,” Cynthia said. “There is just so much to do, now that I am a manager. I feel stretched, way stretched.”
“How did the manager, before you, handle all of this workload?” I asked.
“Oh, that was different. I am still working all my old job responsibilities, plus my new responsibilities as manager.” Cynthia stopped. “So, I am working twice as hard. No wonder I feel burned out.”
“Who do you plan to give your old responsibilities to?”
“Well, I am trying,” Cynthia continued. “I just haven’t figured out how.”
“Wrong question,” I said.
“What?” Cynthia was startled.
“Wrong question,” I nodded. “You will never make any headway figuring out how. You will only make headway when you figure out who. The solution is almost never a how, it’s almost always a who.”
“So, I should stop trying to figure out how I am going to get it all done and focus on who is going to do it?” Cynthia was surprised at her own question.
She knew the answer.