In today's episode we're talking about getting too much in the weeds vs. being too far removed. We'll talk about the pros and cons of each and offer suggestions to get out of the weeds and get down from the clouds.
Often as a developer you'll find yourself either too far in the weeds of solving a problem or too far up in the clouds. In today's episode, we're talking about the levels in which we choose to contribute to solving a problem and tips to identifying roles our teammates can play help us solve a problem we're all facing.
How do we solve the relational issues that a team is facing and how can we support each other in solving problems we are faced with?
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.
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/.
Have you ever been accused of being too in the weeds? Too nitty gritty? Or maybe you've been accused of something kind of the opposite that your head is in the clouds, you're too far zoomed out, you're thinking too abstractly. In today's episode, we're going to talk about what causes this kind of problem and what you might be able to do in conversations to fix it. My name is Jonathan Cutrell, you're listening to Developer Tea. My goal on the show is to updriven developers like you find clarity, perspective, and purpose in their careers. Developer Tea was initially built as a show that focuses on a very narrow subject for a short period. Today's episode will be an example of that. We're only going to have a few minutes discussing this topic. And necessarily, we are discussing something at a zoomed-in perspective and we don't always cover every single implication or detail. It can leave that as an exercise to the listener. If you want to dive in deeper, you can. But what's necessary to be able to do this is choosing what level we're going to talk about the subject at. What do we include and more importantly, what do we leave out? Of course, when we're putting out content as a podcast and we kind of get to choose what level is appropriate for the podcast and for what I want to talk about on the show, but it's not necessarily so autonomous when you're in a work scenario. When you're collaborating with other people, when you're trying to solve a problem, when you're trying to build a successful business, the economics of the discussion, the economics of your approach, all of this deals with the level that you choose to solve. And if you've experienced this, you've probably experienced it at an interpersonal level in some kind of meeting scenario. One-on-one meeting, for example, between an individual contributor and that person's manager, developer and the manager. And the manager is trying to solve the team dynamics. They want to understand how do we create positive relationships between the team members. And the individual developer brings a specific solitary problem. One issue that they have with another developer. And these are two different levels. The question being asked is, how do we solve the relational issues that the team is facing? But the answer that's being provided is zoomed in on one specific instance of a problem. Now, this specific instance of the problem may help us understand the larger picture that the manager is asking about. And it certainly shouldn't be ignored. There's nothing wrong with this level of thinking. But in the conversation that's being had, perhaps the most functional thing that can happen is either the manager chooses to address the specific problem first with that individual, which is probably a good first step, by the way, or the individual recognizes or the manager tells the individual that, hey, you know what, we're trying to solve the problem at one layer above and one layer abstracted from what you're talking about. And this difference could even be quite minor. The difference between these layers is not necessarily substantial. But defining what layer you're going to solve the problem at helps both sides focus on the problem at hand, rather than whatever the irrelevant details are in the disparity between approaches. You've probably also experienced the opposite of this where the question being asked was that a higher layer and the answer given was at a lower layer, where the question asked is that a lower layer and the answer given is at a higher layer. This kind of response often feels defeating to the person that's asking the question. Sometimes this is just a question about tactically solving a problem. And the answer moves up to a process level, for example. This is a very common scenario in management. Now, this doesn't mean, once again, that the thoughts about the process oriented approach are wrong, very often. The conversation should eventually evolve to that point. But the person who has, and this is my personality, tends to do this as well, for the person who tends to abstract problems quickly, to respond by abstracting to a level of a system's thinking rather than answering a tactical issue, this can sometimes frustrate the people that are asking the question similarly to someone who is getting into the weeds. It's kind of the opposite problem, but the same level of frustration can happen because it's a communications breakdown. So how can we fix this? Consider the idea of answering a question being largely about understanding the question thoroughly to begin with. You've probably heard the Socrates quote, understanding a question is half an answer. And this certainly applies in this scenario. But someone engages in the conversation with you, especially when you are engaging together to solve a particular problem, to solve an issue on a team, for example, understanding the question, understanding the problem, understanding the concern thoroughly is part of the solution. Don't approach these conversations as if the question is clear and obvious. Even if the question has been worded and reworded multiple times, even if both sides believe they have an intuitive understanding of the problem at hand, the problem needs to be defined and redefined and explored together. This is part of the collaborative process. In providing feedback, do it in a conversational way that is always also looking for more feedback about the feedback. So in this scenario where you're starting to get into the weeds, make sure you're answering in a way that is aware of the fact that you may be answering on different levels. Ask the question of, is this two in the weeds? Or do we need to talk about something more abstractly? If both sides of the conversation are aware that people tend to answer questions at different levels, then frustration can be replaced by communication. And getting at the right level is one step in getting the right answer. Thank you so much for listening to today's episode of Developer Tea. This episode, as with every other episode, is available on spec.fm along with other podcasts that you as a designer or developer will likely find valuable for your career. And by the way, if you did find this episode valuable, then I'd like to ask you to do two things. The first one is subscribe. If you haven't already subscribed to the show, go ahead and subscribe in whatever podcasting app you find useful. The second thing I'd like to ask you to do is share this specific episode with someone that you think will uniquely find value in it. There's not everybody is going to find value in every episode of the show. It's why we do so many episodes, we cover a lot of topics, and people find value in different episodes. But you probably know someone right now who deals with this problem. And my request is that you share this specific episode with them to help them solve their problem. Today's episode was produced by Sarah Jackson. My name is Jonathan Cutrell, and until next time, enjoy your tea.