In favor of asking hard questions

I am in favor of asking hard questions. A lot can go assumed. No stone should be left unturned. It’s wise to think ahead and it’s the professional who makes sure that there are measures in place for anything that can go wrong.

Still, there’s friction to fight when asking hard questions. The person who asks hard questions might be seen as a troublemaker. Or less insidious, it’s easy to hurt other team members’ feelings. Someone who put a lot of work into a feature only to hear questions about it might not appreciate that.

72762_china_abacus_md

Sure, I don’t want to rock the boat. I also don’t want anyone on my team to feel bad. But more than all of that, I really don’t want to be up at 2am because of a support escalation over something that could have been prevented.

And I think it’s possible to be polite and fair when raising problems. Asking hard questions can be done diplomatically, with tact. It always helps to approach the team or an individual on the team with a helpful attitude. “Put a smile in your voice,” as they say. Mix in some praise.

What is a hard question?
A hard question is usually any question that isn’t being asked. There are reasons why questions aren’t asked. People often fear the result of asking hard questions. By asking a hard question, you might be signing yourself up for more work. That’s often the number one reason for resistance.

Well, buckle up. This isn’t school. It’s professional software development. We’re all in this together. And, by the way, I really do believe that asking hard questions ultimately leads to less work. Not asking hard questions usually means leaving a landmine around to blow up at an inopportune time.

So let’s ask those hard questions! What would happen if smoke started pouring out of your dev machine today and it wouldn’t turn on any more? Is your work committed and pushed up to source control? What if your internet at work went down? What if you accidentally ran a “DELETE FROM” command without a WHERE clause in the database? If your CI or CD server got borked, could you recover all the jobs in a reasonable time frame? If a team member quit tomorrow and never came back, would the rest of your team be able to support and develop on the system just fine? Or would he walk away with knowledge that is unrecoverable?

Notice I didn’t even go into questions about your production environment, and maybe you feel uncomfortable already.

The best part is, it gets easier
The more hard questions you ask the more often, the more comfortable you become with them. Partly because just by asking them and holding the inevitable conversations you find solutions. In the long run, I’d say that asking hard questions is a good and healthy practice for any team.

Mark me down as being in favor of hard questions.

Leave a Reply

Your email address will not be published. Required fields are marked *