paint-brush
How to ask questions that drive change at workby@scottashipp
2,810 reads
2,810 reads

How to ask questions that drive change at work

by Scott ShippMarch 2nd, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

This is another story of a software engineer doing it wrong, and one way to do it better.
featured image - How to ask questions that drive change at work
Scott Shipp HackerNoon profile picture

This is another story of a software engineer doing it wrong, and one way to do it better.

At a past employer, the culture had taken a turn into a bonkers world where nothing was agile, but everyone talked about what we were doing as “being agile.” Yet this company couldn’t release software more than once a quarter. Among other things, I and another guy on my team began advocating for smaller, more frequent releases in order to stop the madness.

But we did it wrong.

To advocate for more frequent faster releases, we basically set a confrontational tone with questions like this:

  • Why aren’t we releasing faster?
  • It costs $XXX,XXX every time we release, because we involve the entire engineering organization in every release. Why are we doing that!?
  • Why can’t we work toward smaller releases?
  • We’re actually not agile! We should be! Did you know one way we can be more agile is by releasing more often?

These are all terrible questions. Imagine someone asks you a question like these. How do you answer in a constructive way? Your first inclination is to answer the question on its face. When asked “why aren’t we releasing faster?” you might name all the obstacles preventing the org from moving towards more frequent releases. And when asked, “Did you know one way we can be more agile is by releasing more often?” you might say something like, “yes.”

And, in fact, that’s pretty close to the answers our managers gave.

In other words, these aren’t constructive questions. They’re just variations on “whyyyyyyyyy!?” which is exactly what we were feeling.

One day as I was sitting in a one-on-one with my manager, she gave me a bit of advice like, “If you really believe in something, make the case.” She was probably getting at something else, but the next thing I did was hilarious (as in hilariously bad). I prepared a Jerry Maguire style memo (10 pages with footnotes) about why we should be releasing faster and I emailed it to everyone on the senior leadership team.

It was politely ignored.

A Better Way

Is there a better way to ask questions in software organizations?

Yes, I think so.

  1. State a shared purpose
  2. Ask a collaborative question


Shared PurposeIt’s often hard for the recipient of a hard question to place the question in a shared context. When we were asking, “Why aren’t we releasing more frequently” our managers probably heard an underlying tone of “I’m frustrated” (which was true) far more than they heard, “I want to help.”

That’s why it’s important to state the purpose that you and your manager share, and create a context for your question. Instead of blurting out, “Why can’t we release faster?” what if I had started the conversation with my manager like this?

We both want to make customers happy. I noticed one thing keeping them from being happy is that when they file a bug, they have to wait at least until next quarter to see a fix, since we only release once a quarter.

The shared purpose here is clear: make customers happy. The tone of the conversation shifts from, “whyyyyyy???” to “here’s a problem I’ve been thinking about.” And it naturally leads to a conversation where solutions can be discussed back-and-forth.


**Collaborative Question**Collaborative questions invite the other person into the conversation. They create a solution-oriented discussion, and the person hearing the question becomes part of the solution-making process.

So, after stating a shared purpose, ask a collaborative question. Here’s the above shared purpose statement, with the question added:

We both want to make customers happy. I noticed one thing keeping them from being happy is that when they file a bug, they have to wait at least until next quarter to see a fix, since we only release once a quarter.

One thing I’ve been wondering is how we could get bug fixes into our customers’ hands faster?

Given this style of question, a conversation can happen that wasn’t happening before. There’s no tone of frustration here, no confrontation. Everyone involved is activated towards a practical shared goal. It’s possible that if I had done this, things might have gone a lot better.

From doing it wrong to doing it right

No matter where you work, nothing is perfect. It will always be difficult to have conversations about the warty, ugly things at work. But I’ve found that there are good and bad ways to get conversations going and gain consensus towards a solution. Take it from me, a bad way is simply to express frustration (even if that’s not your intent). A good way is to state a shared purpose and ask a collaborative question.