ยซ All Episodes

Substitute Better Questions

Published 11/23/2021

Substitute with better questions, and you'll have more insightful answers. Questions are a major contributing factor to behavior, and the way you ask questions is a habit that can have a high-leverage cascading effect on the rest of your life.

Find better questions.

๐Ÿ™ Today's Episode is Brought To you by: LaunchDarkly

This episode is brought to you by LaunchDarkly. LaunchDarkly enables development and operations teams to deploy code at any time, even if a feature isn't ready to be released to users. Innovate faster, deploy fearlessly, and make each release a masterpiece. Get started at LaunchDarkly.com today!

๐Ÿ“ฎ Ask a Question

If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

๐Ÿ“ฎ Join the Discord

If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community by visiting https://developertea.com/discord today!

๐Ÿงก Leave a Review

If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.

Transcript (Generated by OpenAI Whisper)
What questions are you asking? My name is Jonathan Cutrell. You're listening to Developer Tea. My goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. Much of our work comes from decisions. But many of the crossroads that we find ourselves at are the result of questions. These are kind of two pillars of action, or at least kind of generators of action in our lives. Questions generate a crossroads. We determine that we have options A, B, and C as the result of asking some kind of question. And then actually choosing one of those options is that second pillar of decision making. We talk about decision making a lot on this show. And we certainly have talked about questions on this show. But today I want to talk about whether or not you're asking the right kinds of questions. And it's hard to know what kinds of questions are the right kinds of questions. But in today's episode I want to give you a couple of examples to point you in the right direction. Let's first talk a little bit about the characteristics of a good question. How do you know, generally speaking, what are the kind of the heuristics you can use to judge the quality of your question? This kind of goes back to what we were talking about with modeling last week, the idea that you can have some characteristics of models more generally and apply them to all of your models and you'll probably improve across the board. This is also true for these critical questions. Now let me be clear. Not every question needs to be run through this process. You don't need to judge every single question this way. For example, you may not necessarily have to judge the question, what do you want to eat tonight through this arduous process? But for questions that are relatively meaningful and particularly related to your career and for questions that have significant impact on other people, and you're making decisions that cascade into the lives and the work of other people, it makes sense to focus on the quality of the question itself. A very kind of simple, classic example of this is how many hours did you work? How many hours did you work? This is a bad question for a handful of reasons. Hopefully if you're listening to the show, you can kind of intuitively guess some of those reasons. It better questions might be. What did you accomplish? What did you do with your time? What kind of problems did you solve? What did you learn? There's a lot of questions that could be substituted for how long did you work? How many hours did you work? Generally speaking, a good heuristic to look for is questions that end in a description rather than a data-based answer. In other words, you're not trying to query out a specific data answer, a single word or a single number or some kind of reductive answer. Instead, you're looking for answers that require context to be complete. The basic mechanism here is that good questions are going to elicit more information. A bad question elicits only a specific kind of information or only a limited amount of information. The reason this is not very good, the reason this can lead you down bad pathways is because these bad questions have assumptions baked in. In our previous example of how many hours did you work, the assumption that's baked in is how much value did you produce based on my predetermined per hour value metric. This is something that I've decided your time is going to produce a certain amount of value per hour. A second characteristic, and this will be the last one that we focus on before we provide some examples, is that most good questions are abstracted away from the question that are from tactics. In other words, most of those questions are unlikely to start with the word what, this seems like a really basic heuristic, and it is. It's a very helpful heuristic because what typically implies some specific action and again going back to that first heuristic of not providing that data based answer, not providing a specific data point kind of answer, but instead providing an answer with context attached, usually why or what kind, how, those are the kinds of questions that are likely to lead to better answers. We're going to take a quick sponsor break and then we're going to come back and talk about a few examples of questions that could be replaced with better substitutes. This episode of Develop a T is brought to you by Launch Darkling, feature management for the modern enterprise, fundamentally changing how you deliver software. Here's how it works. Launch Darkly enables development and operations teams to deploy code at any time, even if a feature isn't ready to release to users. Launch Darkly allows you to wrap feature code in flags, feature flags. This gives you the safety and the environment to test features and infrastructure in your actual production environment without impacting the wrong end users. When you're ready to actually release more widely, all you have to do is update the flag. You have to do another deployment or anything, those features are made instantaneously available to your user base. You can innovate faster, deploy fearlessly and make each release a masterpiece. Get started today at launchdarkly.com. Thanks again to Launch Darkly for sponsoring today's episode of Develop a T. We're going to talk about a couple of examples of questions that could likely be improved by substituting a different question. And really, you're still answering the intention. This is another kind of processing idea. When you're asking a question, a lot of times, the best way to improve the question is to peel away the assumptions that are embedded into it. We've already mentioned this and making sure that your questions are not just looking for atomic data point kind of answers, but instead are providing context. And you do this by peeling away those assumptions. And so when you're asking a question, you may ask a question about the question. This is, once again, going back to our meta modeling, we can have meta questions. So what is this question really trying to understand? What is the motivation behind the question? Is there another question that we can ask that accomplishes what the original motivation was better? So a simple example of this, especially for younger engineers, we might be asking ourselves, how much do I want to make? How, what is the salary that I'm shooting for? And the problem with this question is, it's too broad. It doesn't have any kind of context. It doesn't think about function. It just returns a number. And that number has to have built into it a bunch of other considerations. And it's important to actually take those, take the moments necessary to consider some of those things explicitly rather than implicitly. For example, what kind of lifestyle do I want to have? This is a little bit better, but you may end up in a trap of spending to just maintain that lifestyle. But this question does provide you a better concept. You might also ask, where do I want to live? Your salary in a specific location might provide you a lifestyle that your salary, that same salary in a different location wouldn't provide. And then perhaps the most appropriate answer or the most abstract answer is, what kinds of things do I want to do with my money and time? From this point, you can kind of back your way in using kind of continuous questioning beyond this into what kind of salary you would like to make. But what specific things do you want to do with your money and time? Gives you the framework to answer the original intent. The original intent is, what is the salary that I really need to do the specific things that I want to do with my money and time? For example, how should our teams be organized? How should our teams be organized? The answer to this one, once again, is kind of a data point answer. Our team should be organized like this and provide an org chart as the answer. This isn't a great question because it doesn't ask what the point of that organization of the teams is. A lot of organizations actually end up in this scenario where they just pick an organizational structure that they've seen work elsewhere. Maybe that's their underpinning reasoning or maybe they have kind of chaotically evolved into a particular organizational structure. They haven't asked the question that is necessary to ask about why, why are we organized this way or perhaps the best answer to the intended question here is, what do we want to focus on? What different areas do we want to focus on? When we create team structures, we provide an opportunity for a group of people to focus. This is kind of the point of having teams. We provide an opportunity for a group of people to focus. What you'll notice is the focus will follow those lines of organization, the group of people who are working on Project X. They're the Project X team. They're going to be focused on Project X. This seems intuitive when you think about it this way, but very rarely do we use the question, what do we want to focus on to derive what our organization should be? For example, how do I solve this very complex problem in code? How can I solve this complex problem in code? Hopefully, as an engineer, you immediately think, okay, well, we don't solve complex problems. We break complex problems down into smaller problems and too easier to solve. That is a better, more abstract question. How do I solve the simplest case of this problem outside of code? How do I solve a subproblem of this more complex problem in code? But in a product level, when you're actually facing this kind of problem in your job, in the real day to day, perhaps a better substitute question might be what makes the solution to this problem the most valuable? What parts offer the most upside and what parts offer the least upside? Is there an item on that parts that offer the least upside that's also creating a lot of the complexity? And if so, can we ignore it for now or could we eliminate it? These are the kinds of questions that allow us to solve the problem without making the assumption that the whole problem, as it stands today, needs to be solved. One final example of this, kind of substituting better questions, where do I want to work? Where do I want to work? This is a single word answer. Once again, providing not very much context. But a better question or a handful of better questions that might lead you to understanding what kinds of places you want to work rather than one specific place. How do I want to work? Maybe I want to work remotely or maybe I want to work at my own pace or maybe I want to work flexible hours. Who do I want to work with? What kinds of people do I want to work with? If there's only a handful of people that I want to work with and they are split between two or three companies, then that narrows my list down. What do I want to work on? And the answer to this one can be very broadly ranging and I'll let you fill in the blank, but it could go from particular areas, different domains, or it could also talk about various kinds of tech. But a great question that abstracts away from all of these specifics is, why do I want to work in the first place? Why do I want to work in the first place? If you can nail down the answer to this question, so many other questions that you have about your job, so many other specifics that you want to nail down about what you're going to work on in your career can be answered. Why do you want to work in the first place? Is the answer primarily money? Certainly, that's probably a component. And there's probably many different answers to this. You probably have multiple things that you would put on that list of why do I want to work in the first place. But your list is going to be different from mine. And we really think about the answer to these kinds of questions, the higher level questions, we can derive better answers to those lower level questions. Where do I want to work? Depends very heavily on why do I want to work in the first place. Thanks so much for listening to today's episode of Developer Tea. Thank you to today's sponsor, Launch Darkly. You can get started, get started with feature flags and releasing your software in a much more sane and reliable way, heading over to launch darkly.com. Thanks for listening to today's episode. If you want to join the Developer Tea Discord community, you can discuss what we talked about on today's episode or you can discuss pretty much anything going on in your career. You are welcome in that community, no matter who you are or where you're from or what kind of experience you have as an engineer. If you have no experience at all, anyone who's listening to this show, you are welcome to join that Discord community developertea.com slash Discord. Thanks so much for listening and until next time, enjoy your tea.