The Regenerate Web

From the Ask Tom mailbag.

Question

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.

Response

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.

At the Rushmore Monument, there was a sign in the museum talking about the workers, who were mostly miners or lumberjacks from the area. The bottom of the description read:

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’m at the SHRM conference in Chicago this week, courtesy of Dice.com. I blog for them, and am working on an agile recruiting series. Watch for it, in the coming weeks.

I read this piece, The War for STEM Talent is a Lie. I agree. Until we do all of these things:

• Hire the people who are in their 40′s and 50′s. People who are older than 35 do know something.
• Hire the unemployed and train them
• Hire the people who are not in your general geographical area and provide some relocation assistance
• Train the people you have!

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.

So the actual reading would suggest "all model are wrong" ... and the correct answer cannot be obtained by making the model more elaborate. A simple model is needed.

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. 

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.

If you are confused about how to do this, read Hiring Geeks That Fit, and download the job analysis template (available to everyone).

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.

• Tell me about a project you worked on, where teamwork was important?
• What was the project?
• How long was the project?
• How many people on the team?
• What was your role on the team?
• What was the critical element in this project that made teamwork important?
• When the team worked well together, what was happening?
• When the team did not work well together, what was happening?
• What did the team adjust to work better together?
• What did you, personally, have to adjust to make the team work better together?

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.

“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.

See the management myths on Stickyminds here, and on my site.

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

1. If you are willing to read a boring set of study guides, sit for a really boring test that may or may not be applicable to your domain, pay some money, and get a certificate that demonstrates you have “some” level of commitment to learning how to do your job from a broader set of practices — You’ve stated to everyone that you’re not a lone wolf, making things up, creating your own version of how to manage projects, redefining terms and processes and claiming they are applicable to “projects in general.”
2. With that certificate, you’re now connected to a community of others like you. If you don’t like that community, or you disagree with how that community works, then don’t join. Standing on the side of the road being a Blustering Bully about how evil that organization is, or how that organization is somehow not doing it right, is pretty much consider “bitching” here in the US. Get over it and get back to work. Unless you of course are “selling the alternative,” and need to slam the competition as part of your sales strategy. Having an MBA, allows me to understand that is a bad sales tactic and makes you look naive and uninformed about the selling process.
3. No one can connect certification with competency. I have personal experience with my mother-in-law and the misdiagnosis of a brain tumor from a renowned neurosurgeon here in Boulder County. Board certified, head of the department. He was fundamentally incompetent. We went back to Toronto and got a second opinion. She was born with that small mass in her head, get back to work. The symptoms had nothing to do with the mass. Certification does not mean competency in exactly the same way a PhD does not mean anything in the absence of tangible contributions to the professional referenced and acknowledged by peers. I know this from graduate work in Physics. Count the number citations of your thesis in the citation databases to see if anyone on the planet acknowledges your “thesis” (a hypothesis by the way) has been accepted or verified by others. This is the basis of the physics world and it likely the same in all research based PhD’s, including the soft-science domain of project management.
4. Everyone is selling all the time. Test the message the seller is selling against the broader background of your own experience, the experience of trusted others, and the rationality of the message. “You can lose weight in 10 days, with my special diet,” “You can take 6 strokes off your golf game with my special utility wood,” “You can ride much faster on your bike if you only adopt my training program.” You don’t find many used women’s golf clubs in the “play it again” stores, because women know you can’t “buy a game,” so they rarely trade up. You can’t “buy” competency, but a certificate says you are at least trying to understand a few things about the “game.”
5. In the end having more knowledge may not help, but it can't hurt. Being a member of a group with similar background let's you test the question every month - do I have sufficient experience to do my job?

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.

There are several things we need to remember about agile:

• Agile means paying to discover the requirements as we go. No problem if you know that up front.
• #NoEstimate means you don't have an Estimate At Completion (EAC) other than the passage of time multiplied by the total labor load. No problem if you understand that.
• When there is a budget cap, and deadline for delivery, and a minimal set of useable features, then some notion other than we don't make no stink'in estimates probably needs to be in place.

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. 

• Quality - does the product work as defined?
• Technical Performance - does the product work as needed?
• Key Performance Parameters - does the product meet the needs of the consumer?

These are all wrapped into the word scope. Here's a better way to look at the Triple Constraint.

If our project management method uses the PMI paradigm, we could be on budget, on schedule, and providing the scope but have no clue about the items shown below:

• Technical Performance Measures
• Measures of Effectiveness
• Measures of Performance
• Key Performance Parameters

And of course failure to assess these are the root cause of most project failures.

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.

Once you have your credible Integrated Master Schedule, you're going to want to keep it that way and assess its credibility.

With these two documents, you'll have a starting point for creating schedules that actually describe what done looks like in units of measure meaningful to the decision makers.

“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.