The toughest question you can ask, isn't tough enough

One skill all engineers need to have in order to ship high quality software is the ability to ask hard questions.  No matter if you are a developer, a tester, or a project manager, you need to look at each situation, line of code, architecture/design, or user scenario and determine if you and your project team members are doing the right things.  In order to know this, you need to ask questions, lots of hard questions.  The most difficult questions to answer are by far the most important.  I like to call this skill of asking questions "critical thinking" because you aren’t just thinking about getting your own work done, but you are thinking more broadly about the bigger issues and where the problem areas could be.  The more people on your team that have critical thinking skills, the faster and better your team will be at shipping software.  The team full of order-takers and yes-men will never deliver more than the minimum expected and if there are any surprises along the way, they will have a difficult time handling them.  So have you asked any hard questions today?

Now there are different levels of tough questions to ask.  I guarantee you that you aren’t actually asking the hardest questions.  Unless you are a very successful higher level manager (who I have found are the best at this), your questions could use some work.  The first level of questioning is really just to help you understand something (the design, the project scope, the customer) and doesn’t really challenge the recipient of the question (unless they truly don’t understand their own work that they are producing).  Questions of this type would be “what does this part of your design do?” or “why do we have to meet that specific release date?”.  The next set of questions challenges the recipient a bit more.  “How are you designing for reuse?”, “How many unit tests are you running before you check in?”, and “What are your performance targets and have you benchmarked those featured?”.  These questions are intended to show places where the recipient may not have even thought of these ideas (reuse, unit tests, perf targets, for example) and so they may not have the best answers.  Are you comfortable asking a question that would make the person answering it feel uncomfortable?  Many people are not.  Many people will only ask questions where they either already know there is an answer (like my first examples), or where the answers should exist and if they don’t, you’ve now helped the recipient understand that they need to be thinking about these things.

But there’s one more level of difficult questions, the ones where you know there are no answers and where by asking it, you’ve set expectations so high that it not only makes your recipient feel uncomfortable but everyone else in the room also feels uncomfortable.  These would be questions like “Why is it taking this team 9 months to ship something that another team can release in 2 months?”  “Why are you not marking this item red in the status report since it is obviously a lowlight?”  “What would it take to get more automation written and shorten our test passes and why are we not doing this yet?”, “Why are we not measuring our results and entering this data in the same tool everyone else is using?”.  These questions set expectations like shipping faster, reporting accurate status, and being consistent with other teams.  Granted, the previous set of questions also set expectations like needing to consider reuse and have performance targets, but this last set of questions are a bit broader and potentially need more than one engineer to answer them.  These are also more targeted to the leaders in the team and not the individual engineers.  Questions where the answers need multiple people to answer in unison are the hardest ones to answer, especially when they are asked in a way that increase the expectations of the team and are asked knowing that the best response is “we don’t know but we will look into it and get back to you”.  These are the types of questions high-level managers and execs ask.  They don’t shy away from them but instead expose systemic problems within teams and companies by asking questions that potentially don’t yet even have answers.  This causes the employees to figure out the best answers and propose something over the course of time that will help address that question the next time it is ask.

So are you asking the tough questions, the really tough questions?  Are people able to answer your questions?  If so, they aren’t difficult enough to drive change.  And are you prepared for being the recipient of these most difficult questions?  Don’t find excuses.  Either you can answer these questions or you state honestly that you can’t and then go figure out the answer and report back.  Driving change and thought leadership through questioning is a powerful skill to have.  Practice it and you'll be surprised how it will impact your team in a positive way.