I came upon a wonderful post entitled The Illusion of Managing People at Nucleus Insights. You can find it here:

The focus of the article was away from “managing” and more towards “leading, inspiring, and focusing”.

There were three key points made:

1. Nurture the culture, can the controls;
2. Paint the big picture, skip the little instructions;
3. Always ask, never tell.

They wrapped up the article with the following quote:

Next time when you have the responsibility to “manage a group of people”, spend time creating a consistent culture, painting a compelling vision and developing the habit of asking meaningful questions. If you do that, and do it well, you can watch the magic happen. You can see the miracles take place. You will never have to “manage people”, ever.

Next

If you’ve been reading many of my blog posts of late, I often gain inspiration from others’ posts and then react to or augment them in some way.

This post inspired me with its on-point nature and simplicity. I especially resonated with the always ask, never tell point.

It reminded me that there can be a line between asking meaningful questions and asking manipulative questions. As the article alluded, meaningful questions can drive wonderful team behavior.

However, I’ve been seeing less of them of late. Instead, I’ve been seeing more dishonest and manipulative questions being directed towards teams in agile contexts. Let me share a story to start illustrating the point.

A Story

Many, many years ago I worked at a company called Micrognosis. I wrote a little about my time there . During a part of that time I worked for a gentleman by the name of Hank White. Hank was an old-school IBM’er and had 30+ years of experience at the time. Hank was the President of Micrognosis and I was his Director of Development.

Periodically, Hank would call me into his office to discuss the latest customer request (opportunity). The discussion always surrounded very limited scope definition and very urgent dates. In essence, Hank was looking to get my “commitment” to the work; particularly the schedule.

Hank used a technique I’ll call Death by a Thousand Questions to get the answers he wanted.

He would initially start by asking me to visit him in his office. Then he would describe the need to start planning further in our roadmap and/or a customer request that required significant engineering work. In either case, Hank was looking for me to make a “commitment” for me and my team to some new development work.

Now Hank didn’t really care about the fact that there was tremendous ambiguity. Nor that the customers rarely fully understood what they were asking for. What he cared about was (1) would I commit to the work, and (2) would the dates fit his image for what was aggressive.

As we explored scope, Hank would constantly challenge me with questions, for example:

Hank: How long do you think it will take to deliver “blarg”?

Bob: Based on what we know (very little) it will take 6 months.

Hank: That’s too long. Unacceptable. What can you do to improve the date?

Bob: I’m doing a high level guess based on minimal information. I think this is my best guess at the moment.

Hank: Bob, you’ve got to be bolder in being able to make high-level estimates based on little/no information. Why can’t you accept that reality?

Hank: Since it’s a guess, why can’t we limit/cut this, this, and this? And why do we have to do design, or regression testing, or documentation? Are those things really necessary? Let’s cut them. Why not?

Bob: I don’t know. Perhaps…

Hank: Great, so you can meet the 2-week date commitment! I’ll hold you to that Bob. Now you better get moving because you’ve got a lot to do.

Bob: Sigh!

Upon reflection, I’ve realized that Hank was a fairly poor leader. He was accustomed to using strong armed tactics, micro-questioning and intimidation to get the answers he wanted to hear.

Once he heard what he wanted to hear, he would disengage from the process until the very end. Then he would come gleefully back looking for a wonderfully successful project. Skipping if you will.

Did the projects ever complete on the terms he brow-beat from his teams? The sad answer is NO.

But we did manage to successfully meet our clients’ expectations despite these strong-arm tactics.

Example of Leadership – Death by a Thousand Questions, questions:

To further explore some of these manipulative questions, here’s a sample of some that I’ve seen and/or experienced:

• Why can’t we do more in parallel?
• Do you really think the teams are working hard enough? And are they committed enough?
• So it takes 10 months with current staff. If I bring in 3x staff, we can get the date down to 3 months – right? What about offshore?
• I don’t understand why it takes so long to…
  • Design the app?
  • Code the app?
  • Test the app?
• Why do we have to do (that) now? Can’t we defer it to later?
• Please help me to understand why (blarg) takes so long…
• Do we really need to do so much testing?
• We’re agile, I thought things would be delivered faster. Why not?
• We’re agile, I thought you could handle frequent changes. Why not?
• Can’t we outsource all of that?
• Are we really working as hard as we can?
• Can’t we be more positive, more can do, and think more out of the box?
• The customer needs it by April 1’st, what do you suggest I tell them?
• Can we try working smarter and not harder to achieve our goals?
• Let’s drill into the details. I think you’re leaving capacity on the table, don’t you?
• How can you expect me to buy-into numbers that don’t meet our date commitments?

The key difference in these questions is that they are not deliberate or honest or genuine. They are also not driven by interest or curiosity.

Instead, just as in Hank’s case, they are intended to get a predetermined answer. Usually surrounding a delivery date that the leader is looking for.

Once they break down your defenses and get your “commitment”, they usually leave you alone. That is until the committed date starts to near.

This is also not a collaboration or a partnership. It is command-and-control at its very worst. And my hope is that by “shining a light on the behavior”, I might influence a decline in the practice.

Only in the large?

Is this tactic only used by senior leaders or in larger contexts? I wish that was the only case.

But no, I see this as more of a cultural practice cascading from senior leadership’s exampled down to all reaches of the organization. For example, if the software team managers are exposed to Death by a Thousand Questions inquiry by their bosses, then there is a high probability that they will do the same to their teams.

The bad behavior then permeates the entire culture. Not only does it spread, but it is often recognized or rewarded as a good management practice.

I’ve often seen Product Owners use this technique in backlog refinement meetings to get the estimates to “line up” with their date expectations. It’s as if each story is a micro-negotiation and opportunity for Death by a Thousand Questions.

Wrapping Up

Clearly the point of this post was to first expose this practice. But I’m also curious.

• Have you experienced this, or a similar practice?
• How have you handled it? And what have been the results?
• And finally, if you’re actively leveraging agile approaches now, do you still see this practice?

I know, I know, that’s perhaps too many questions. But please consider leaving a comment with your experiences. It might help the next person (victim) of Death by a Thousand Questions better defend themselves.

Stay agile my friends,

Bob.