Β« All Episodes

Improving Through Bad Ideas and Silly Questions

Published 4/8/2020

Why are bad ideas important and why are silly questions needed? Very likely you've been in a meeting welcoming any question, good or bad.

In today's episode, we're talking about being vulnerable in meetings with your peers and how the person leading the meeting can participate in the discussion by being vulnerable themselves.

🧑 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.

🍡 Subscribe to the Tea Break Challenge

This is a daily challenge designed help you become more self-aware and be a better developer so you can have a positive impact on the people around you. Check it out and give it a try at https://www.teabreakchallenge.com/.

πŸ™ Today's Episode is Brought To you by: Educative.io

Supercharge your career with interactive, text-based software courses. Visit Educative.io/DeveloperTea to get 10% off.

Transcript (Generated by OpenAI Whisper)
We've all heard the phrases, there are no stupid questions, there are no bad ideas. These are the kinds of phrases that we hear when we're kicking off a meeting and most of the time people don't buy them. Our instincts kick in and we hold back. We hold back a question that we think is going to make us look stupid or we hold back an idea that is out of the mainstream of ideas that are being presented. In today's episode we're going to talk a little bit about why we do this, why we present the false idea that the table is open to any input at all. And in reality on the flip side are social instincts and awareness kick in and prevent us from sharing those ideas. But then we're going to talk a little bit about why it's true that there is no bad idea or perhaps more accurately why you should share your bad ideas and your dumb questions. My name is Jonathan Cutrell, you're listening to Developer Tea, my goal in this show is to help driven developers like you find clarity, perspective and purpose in their careers. Most of the time in the meetings that we're talking about, there is one person who is bringing this kind of idealism to the table. Idealism in the sense that they're inviting anybody to provide any kind of input that they want to provide. But very rarely are these groups new. These groups have probably been working together. If you found yourself in this situation it's probably a group of people that you have previous context with. These are not new people. These are people who you have established a pattern, a working relationship with. And so in this kind of environment, it is nearly impossible to turn on the open ideas switch. And the reason for this is that within established context like this, you've already built a picture of who you are to your coworkers and they have done the same with you. And I want you to put yourself in this situation. Try to imagine sitting in front of those coworkers and their picture of, let's say, your competency as a developer starts to fall apart because you ask questions that they think you should already know the answers to. This is a scary concept. This is a scary place to be. And it seems a very realistic scenario. It seems that there is some question that pops up in your mind that you're likely to suppress and decide that you're going to try to answer it on your own later. And your reasoning for this is probably something along the lines of, well, that's just a small hole, a gap in my knowledge that other people don't have. And so I have the responsibility to fill that gap so I can catch up with everyone else. And here's the amazing reality that we've just uncovered. If every person in that meeting has a stupid question that they are unwilling to ask, it is almost certain that the question that you have will benefit someone else. The answer to that question will benefit someone else. Additionally, if you were to build a team where this kind of pattern is acceptable, where sharing this information is invited on a regular basis, not just in these special brainstorming meetings, but on a regular basis, then it's very likely that you breaking the ice with your question will open the door to other people. It's asking there silly questions. There are a lot of reasons why we would choose not to share information, ideas, questions in the social or professional social situations. Most often, the reasons are connected to an underlying fear. You don't want to be seen as incompetent. Perhaps you don't want to be seen as too opinionated. Maybe you have developed a kind of personality on the team of the one who always asks the questions and you decide one day that you're not going to be that person anymore, that you want to avoid that negative stereotype. And so even though you have a valid question, there may not even be a dumb question, you've chosen not to share it. And this is a hard problem to solve. There's no one quick trick that will solve this issue because we have a lot of kind of built-in motivations that are really core to our survival mechanisms as humans that help us avoid situations where we are introducing inconsistency. If we introduce a new picture of ourselves, if suddenly we are the person with a lot of opinions where previously we were easy going, well, that's inconsistent. If we suddenly share that we don't agree with our own previous views or our own previous assertions, then that is inconsistent. And so it's necessary and important if you're a leader that's listening to this podcast or if you are wanting to become a team lead, for example, that you are constantly encouraging this kind of questioning, this kind of sharing of ideas. It's also important that the person who's doing that leading is participating in sharing of those ideas. In other words, it is an advantage for a leader to be vulnerable and share the things that are confusing to them. Share the things that might make them look dumb. We're going to take a quick sponsor break and then we're going to come back and talk about why these questions, the silly questions or the bad ideas, why they are instrumental to developing good ideas together. Today's episode is sponsored by Educative. For developers, the learning never stops. There are always new languages, frameworks and technologies. And Educative.io is here to help you with that. Educative helps you learn faster and more efficiently because instead of using video-based courses, which require you to scrub back and forth and you see a very little code that you can copy, for example, their courses are all text-based. So you can skim and double back easily, almost like a book. Each course also contains pre-configured developer environments so you can practice as you learn. This is cover all kinds of in-demand topics like machine learning, Kubernetes, AWS, system architecture and much more. And they just launched their subscriptions at nearly 50% off. So this is a good time to check it out. But you can get an additional 10% off of everything by visiting Educative.io slash Developer Tea. That's Educative.io slash Developer Tea. Thanks again to Educative for sponsoring today's episode of Developer Tea. Why are bad ideas important? And why are silly questions needed? It seems like we should all be focused, like we should all be asking thoughtful and smart questions. And we should be proposing innovative ideas. These are all the buzzwords that you hear, but where do these labels come from? And how would you know if an idea or a question fit into those categories? The reality is that most of the time, the way we define what is a good question is based on other signals that tell us that it's a good question. Because of authority or thoughtfulness, signals of intelligence or even social hierarchy and being the leader in that hierarchy, we tend to take these signals and judge the questions that are being asked or the ideas that are being presented based on those signals and based on our previous experiences. And so if something seems to flow well with the given conversation, then we might judge that positively. But if someone interrupts that flow, if the question seems out of left field or if we don't necessarily respect that person or think that they're smart, going into the meeting, we're likely to cast our judgment and cast those labels on those questions as they're coming in. There's no one particular arbiter of the questions that are coming through. And it's important to recognize that dumb questions or silly questions, bad ideas, all provoke thought. And what's interesting about silly questions and bad ideas is that they tend to uncover areas of thought that otherwise would have been left dormant. In other words, when we ask a silly question because it is coming out of left field, because it is so different, perhaps then the rest of the questions that are being asked, it invokes a different thought pattern. Now we have to be general here because it's hard to be specific. There's no specific thought pattern than a silly question might provoke. But by introducing a new thought into the discussion, it's possible that we can take the raw ingredients, the fundamental ideas or kind of sub-ideas, the structures that are being proposed in those ideas and evolve from them. The bad idea may be the seed for the best idea. And the silly question may be the thing that turns the light pole on for the important question. So much about what we assume going into a meeting shapes that meeting. And by allowing these flexible and unexpected questions to happen or unexpected inputs to happen in these discussions, we could break the mold of our presuppositions. We break the mold and we introduce new raw materials to work with. Entertaining those bad ideas and those silly questions is cheap. It's very easy to entertain them. It's very easy to allow them. And if even only one good idea comes from five bad ideas, then it was worth the allowance. Thank you so much for listening to today's episode of Developer Tea. Thank you again to today's sponsor, Educative. However, to Educative.io slash Developer Teato get started today with that 10% off. This show only exists because you as a listener are there listening. And we need more listeners like you to continue this show. So I'd like to ask you to share this podcast with someone that you think would appreciate it. It doesn't have to be a developer. Obviously, we don't talk about only code on this show. Take a moment and think about someone who would benefit from this particular episode. And then send it to them. This is the most important thing you can do to help Developer Tea. The second most important thing you can do is leave us a review and iTunes. This helps other people like you decide to listen to Developer Tea. Thank you so much for listening. Today's episode was produced by Sarah Jackson. My name is Jonathan Cutrell. And until next time, enjoy your tea.