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:
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.
Is there a better way to ask questions in software organizations?
Yes, I think so.
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.
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.