Learning is about asking the right questions. When I get a new client, I need to learn about their business and their software development process. I ask lots of questions. There are 2 questions that always seem to lead to the most insight. Asking these questions of ourselves can generate useful insights about our own software development process.
Why did you choose to do it that way?
In the consulting space, this question comes up a lot. Often the client will describe some problem they are facing. As they are describing it, I start to envision how I would solve the problem. At this point, I really should be more curious and more focused on understanding the problem than solving it, but sometimes I can’t help myself. I’m trying to stop this habit of immediately jumping to solutions, but it is a hard one to break. The customer then starts talking about their solution or at least how they have tried to solve the problem so far. Often the customer’s solution doesn’t look anything like what I envisioned. I immediately try to figure out why.
What do I learn from this question? The big thing that I learn is that typically I don’t yet understand the problem well enough. Nothing happens without a reason. The reason the customer’s proposed solution is often much more complicated than mine is that the problem is often much more complicated. There are wrinkles that I am not aware of. Asking why helps me to uncover the constraints that the team is working under. It helps to get those unspoken assumptions out in the open. We (myself together with the client) can then evaluate them. Sometimes we find they are operating under artificial constraints they’ve created for themselves. Sometimes we find new constraints. We also uncover what the clients value and prioritize. We always learn something.
Why did I do it that way?
In my own development, I like to ask myself this same question. Why did I (or we when I am working in a team) choose this particular approach? There is always a reason. The funny thing is that sometimes those reasons change. Constraints seem to disappear or change as we learn more about the problem space. By reevaluating why we made certain decisions, we are better able to adapt to meet the current constraints. It allows us to shed things that are no longer serving us and craft new solutions that better meet our new constraints. I like to ask this question not just about a particular piece of code, but also about our software development processes as well. They are equally shaped by the constraints we are working under.
How is that working for you?
This is another question that I often use a lot. Often I’ll bring up a topic like Unit Testing or Continuous Integration and I’ll get push back. The client goes immediately into defending what they are currently doing. “Oh we don’t do that because we do this other process…” or “We don’t do that because …”. Then I simply ask “How is that working?” We both already know the answer to that question, since if everything was working fine, they wouldn’t have called in a consultant.
If I know the answer, why ask the question? It’s simple really. To change the person’s thinking. Them formulating an answer to this question does 2 things. First, it reminds them why they hired me in the first place. It reminds them of the problem they are trying to solve. It gets them to be honest with themselves and with me about the difficulties they are facing. Second, it also reminds them that if you want different results, you need to try different things. We all know this intuitively, yet we resist. This question connects what they are currently doing with the results they are currently achieving. This opens them up to the possibility that maybe they need to change what they are doing. Maybe, just maybe, the thing they are resisting and that I am suggesting might be able to solve their problem.
Are my actions producing the results I want?
In my personal development, I ask myself this variation of the question all the time. It reminds them of the problem they are trying to solve. I would never be this direct with my clients but with myself, I find it useful. It clearly and directly ties my actions with the results I am getting. The clear implication is that if I am not getting the results I want, I need to reevaluate my actions. It also helps me to keep clear on what my goals are because in order to answer the question I have to know what my intended results are. This kind of clarity is incredibly valuable.
The 3to5 Club that I am a part of talks a lot about the value of outside eyes, someone outside your organization. This post is about how asking ourselves these questions can help us garner some insight. That is very valuable, but sometimes having a set of outside eyes can be useful. The 2 questions in this post are just the starting point. There are plenty of other interesting questions that could be asked. Outside eyes can ask the right questions to get us to see things in a different light. The way I think of it is that if I had seen the obstacle or knew the solution to it, I wouldn’t have run into it. Yet I still run into obstacles so obviously I don’t see everything. Outside Eyes are a way to help us see those obstacles and see those possible solutions before we run into problems.
If you would like to have a set of outside eyes look at your software development and see where the opportunities for improvement are, please reach out using the buttons below. We’d love to talk to you. In the meantime, practice some introspection. Ask yourself these questions and see what you uncover. If you discover something interesting, please share it in the comments.