Have you ever been working on a project, whether it says a freelancer or maybe work in a startup where an established tech company or maybe work like I do in an agency and you're going through the projects and things are going relatively smoothly and suddenly out of nowhere or at least so it seems, someone throws a curveball. That's what we're talking about in today's episode. We're talking about mystery voices. My name is Jonathan Cutrell, you're listening to Developer Tea. My goal on this show is to help you become a better developer. And the way that I'm structuring this show is to have these types of conversations. This particular episode is in our planning series because as we'll see later on in the episode, a lot of these kinds of curveballs from mystery voices can be avoided if we plan correctly. So we're talking about planning software is incredibly difficult. So it's a topic that needs to be covered. It's something we need to talk about together. It's something you need to talk about with your co-workers, with your clients, with your stakeholders, with your bosses. This is just a discussion that has to be had over and over because planning is difficult. Mystery voices are still very common where I work and probably where you work. So we're going to talk about this today and hopefully give you a little bit of a way to avoid this, a one of many ways that you might be able to avoid mystery voices. So you're going through this project. You have established a pretty good rhythm. Perhaps you're working like we do in some kind of iterative fashion where you decide the things that are important, the things that are next most important and you work on those things in constant collaboration with other team members and constant collaboration with something like a product owner, maybe a stakeholder, you have meetings and regular updates. And suddenly you get an email or a Slack message or even a text message that tells you that plans have changed or requests something that's totally not on your list of things to do for the week. And the question becomes very quickly, well, is this something that I should do? Is this something that now because this particular person asked for it, I'm compelled to just do it. Or perhaps on the flip side, you have an immediate visceral negative reaction that says this doesn't fit in my list of things to do. So I'm going to totally ignore this person. And unfortunately, on both sides of the fence, this is kind of a destructive scenario to be in. And it's one that we truly want to avoid. So we're going to talk about three different types of mystery voices in today's episode. We're going to talk about the first one. Then we'll do a quick sponsor break. Then we'll cover the other two as well as a way to hopefully avoid this scenario altogether. So mystery voices, there's three basic types of mystery voices. And the first type that I want to talk about is kind of the one that we've already been discussing. And I'm going to call it the late to the project voice, late to the projects. And really what this voice is representative of is someone who has come in either outside of the process or perhaps after some initial planning parts of the process, a later stage in the working iteration, whatever that iteration is. This person has come in a little bit late and they've expressed an opinion or expressed a desire for the team to accomplish some kind of feature, right? Whether it's a feature or a bug or whatever the work is, they've expressed this request. And because it's outside of the process and perhaps unexpected, it's kind of difficult to know what the next step is, right? This person wasn't involved and so they don't necessarily have the context that you may have if you were involved. And the general reaction might be to throw blame on this person that they should have been involved earlier or that they need to take a step back and ask us whether or not we can do this thing that they're asking for or ask what things we're already busy with. But this is also really not the most valuable way we can respond either. Once again, we want to avoid this scenario altogether. So that's the first kind of mystery voice, the late to the project kind of voice. Let's talk about today's sponsor and then we'll talk about the other two types of mystery voices. Today's episode is sponsored by Dolby. If you create web applications, many of the developers who listen to the show, you fall into that category, then you should be thinking about not only the visual aspects of what you create and not only the performance of the visual aspects, but also the audio and perhaps more importantly, the performance of the audio, you know, bad audio can turn people off. The quality of the audio matters. Trust me, I know this. I'm a podcast creator. The quality of the audio is important. And when you create a web application that has low quality audio, users will notice and users will care. Many percent of users say that audio quality is an important aspect of their digital ecosystem. And your audio is included in that. So it's not like you need to go and invest in new audio assets. Truly the audio that most of us are using has been recorded in studios with thousands and thousands of dollars worth of gear. So that part is good to go, but most of the time what you actually probably need is a better codec. And the codec allows people to hear the things that were recorded in that multi-thousand hauler, multi-million dollar studio in some cases. The codec allows them to hear those details better. And this is exactly what Dolby is providing to you as a developer. You can go and check out the Dolby codec and it's totally free for you. You can use it on Dolby's website. Spectreffem slash Dolby. You can use their online encoder. Of course you can also use Dolby's encoders in audio editing programs like for example Adobe Audition and stuff that you're probably already using if you're editing audio. Go and check it out. Spectreffem slash Dolby. Thank you again to Dolby for sponsoring today's episode of Developer Tea. So we're talking about mystery voices. We've already talked about the late to the project voice. Kind of like late to the party. The person who walks in, they don't really have the context and then they provide their opinion or they ask for something not having recognized that there's already a plan in motion. The second kind of mystery voice is the backseat driver voice. So we have late to the project and the backseat driver. Backseat driver voices are people who are involved in the project in one role or another. That isn't at the decision making position. And more specifically for most projects, there is a stakeholder or a product owner, someone who is designated to make decisions about what features and what work is actually performed. So this type of mystery voice is someone who is respected by the individuals in the team, they've been working alongside, but they ask for the team or they ask for an individual to do something different than what the team and the product owner has already decided to do. I don't know if you're very clear here. We're not talking about somebody who's maliciously trying to be, you know, underhanded. Most of the time this happens as a result of somebody seeing something that does truly need to be done, but the person who has identified the request, the person who has made the request, is not the person who normally is in charge of making those kinds of decisions. The person who has the authority to say what the team is going to or is not going to do. The final kind of mystery voice is the ghost voice. This is kind of a more complicated version of a mystery voice because really this happens in conversation even when all of the proper procedures are in place and the decision makers are making the decisions and the members of the team are collaborating. Everything is going smoothly as we said previously. A ghost voice is essentially an unidentifiable source of information and more specifically an unidentifiable source of information that is being used to inform the decision-making process. These voices are very often assumptions about the audience or in someone's absence, like for example, if a stakeholder is not available to help make a decision, the assumptions about a stakeholder's opinion. Another more subtle example would be somebody using information from research they've done before without having that research available to reference. In other words, perhaps they're using what they remember from the research, which could be wrong, and they're unable to directly point at the piece of research that supports their claims. The problems with this and with the other ghost voices is that very often these ghost voices are in fact expressions of real opinions, not ghost people. In other words, the people who bring those pieces of information to the table may be doing so because they don't feel the proper authority to make the decision and therefore they're justifying their opinions or they're justifying their concepts with the authoritative voice of once again the absent person or the absent research. And again, I want to be very clear that these people are not necessarily doing this out of malice and they aren't necessarily doing this in order to manipulate the situation, but rather they're doing this because the collaborative efforts, most of the time the collaborative efforts and the collaborative atmosphere is not inviting enough or is not responsive enough to those people's opinions in the first place. So what can we do about these mystery voices? There's so many other versions of mystery voices, voices that pop up that are not authoritative, they're hard to take action on without undermining some other effort that your group has collectively your team or whoever it is that you're collaborating on a project with, you've collectively decided in one direction and a mystery voice comes in and tries to influence towards a different direction. And again, there's so many versions of this, I've given you three today that I believe cover a pretty large ground, a large number of the sources of mystery voices. So how do we avoid this problem? What starts in the planning phase, it starts very early when you're first conceiving how you're going to go about executing a particular project. How are you going to go about working together? What is the collaborative process? Who is responsible for making decisions? And who is responsible for making decisions in lieu of the person who was responsible when they're gone? You know, this may sound kind of overly process oriented, but ultimately identifying these roles is going to be a very short amount of work. It's not a lot of articulation to explain these kinds of responsibilities. And you may even be able to establish, you know, part of your workflow and collaborative efforts in this process. So in other words, perhaps you want to only allow features to be built if two people agree. So it can't be just one decision maker. It has to be one decision maker, plus at least one of the person's approval of that feature being built. You may establish a majority vote in lieu of the designated decision maker whenever they are absent. It could be a majority vote that moves something forward or holds something back. Another thing you can do during this planning phase is establish a protocol for what to do when a mystery voice enters the picture. A few reasonable things might be, for example, identifying explicitly to the decision maker that a mystery voice seems to be influencing decisions. And this should be something that is shared between all of the team members. You know, it should be a shared value that mystery voices are going to derail a project. And so we want to work to avoid them. We may accidentally introduce them ourselves. I know I am definitely guilty of this. 99 times out of 100, it's not even on purpose. I'm not trying to derail the project. And I'm not trying to undermine the efforts of the team and I have to be, you know, I have to be called out on this. So establishing a protocol of dealing with mystery voices when you're establishing this protocol, just kind of an additional tip here. There are times when the mystery voices guidance is actually going to be followed. You shouldn't be so tied to your process that the people in your team and the decision makers can't adjust even on the fly to respond to the mystery voice. In other words, sometimes that mystery voice truly does have a very important detail, a very important feature that everything else needs to redirect and accommodate that feature. This is in a common scenario, but it underlines the importance of, you know, not being dogmatic, not throwing away everything that a mystery voice brings to the table. But instead, considering what the person is saying or considering what information is being presented and then dealing with that information in a reasonable way, recognizing that a mystery voice bringing something to the table may end up being inefficient and may end up undermining the people who already have the authority to make decisions and ultimately finding a way to move forward. Whether that means changing your direction collectively as a team or rejecting the idea of the mystery voice while still listening and considering the content of what the mystery voice brought to the table. Thank you so much for listening to today's episode of Developerty. Mystery voices are a big problem, but they can also be laced with opportunity. So I want you to treat each other with respect, don't yell at someone for bringing an idea to the table or for asking you to do something that isn't on your to-do list. Being dogmatic and being inflexible, these are things that can kill your career and these are things that can kill relationships with their co-workers and ultimately people will see you as a cynical and otherwise shut off person. This is not something that you want to have as a part of your career as a part of your identity labels that people put on you. Thank you so much for listening. I hope this episode has been challenging, inspiring, and insightful. I hope you take this conversation forward and figure out your own mystery voices and how you should deal with them, not dogmatically but flexibly. Thank you again to Dolby for sponsoring today's episode of Developerty with Dolby. You can have your listeners hearing things that they otherwise would have lost with a lesser codec. Go and check it out, spec.fm slash Dolby. It works in the browser. Lots of modern browsers support these codecs. Spec.fm slash Dolby, thank you so much for listening. If you don't want to miss out on future episodes, including the next episode, it's an interview with Rachel Neighbour. She's been on the show before. Make sure you subscribe in whatever podcasting app you use. Thanks so much and until next time, enjoy your tea.