Avoid This Collaboration KILLER In Software Engineering

you already know why you have an opinion about why you could already take that next step for them as software Engineers our core responsibility is problem solving and a lot of the time people get that confused because they think that our core responsibility is just writing code it just so happens that problem solving with solutions that involve code is primarily what we do in this video I wanted to drill into some limiting behaviors when it comes to problem solving and I think that this is especially important as you become more senior as a software engineer because this can have a larger negative impact and because your circle of influence is larger this can affect more people before I dive into the topic just a quick reminder to check that pin comment for a link to my free Weekly Newsletter okay so problem solving is the core of what we do as software engineers and that's going to mean a bunch of different things so for example we're working with different stakeholders like our product owners product managers our engineering managers and we're coming up with a strategy for Building Systems that solve problems often technical problems where we have to write code but this is one part of the problem solving process the building and creation kind of prioritizing and planning but there's other sorts of things that come up in engineering organizations another flavor of things that come up is like Liv site issues how are we handling bug reports technical support and that kind of thing that are coming in from customers or we're using Telemetry and noticing that some parts of our systems aren't looking so great this is another type of problem solving and different Vector that we have to approach Ro but another thing that comes up is just working and collaborating with partner teams and that is if they're doing the same type of stuff that I just mentioned they're doing that on their own team as well but that's going to mean that at some different Cadence they have to reach out to you to get some insight and understand things and the limiting behavior that I want to be able to focus on in this video is when conversations are shut down and that means that effectively someone is reaching out for help or trying to drive towards some type of end State some goal that they have and there's some type of communication that takes place that unfortunately answers a question or sometimes not but ultimately doesn't leave the person who's seeking some type of Guidance with any further path to go forward and I want to give you a few examples that are hypothetical just to illustrate what I'm talking about so you can see the impact of this so for example if someone reached out to me and they said hey Nick I watch your videos and I was thinking about building a system and I want to have a asp.net core application with a mySQL database and I'm thinking about taking some type of object structure for memory and I want to put that into Json and put that into columns in the SQL database I could respond to that person and say that's not how you use SQL if I were to leave the conversation right there at that point that person might not really know what to do right I'm telling them you're doing something wrong or that's not right regardless of how I phrase that I could do do it even more politely but when you're abrupt like that and just ending the conversation there's not a lot for that person to pull on you're putting it all back on them to say well why right you already know why you have an opinion about why you could already take that next step for them I'll give you another example from my work experience and this is also going to be contrived but related to the field that I'm in I manage two deployment teams and if I had a partner team reach out to us and they said hey look we have a bug fixed for this service that we have and it's a really high priority we've talked with some type of leadership they've deemed it a high priority and we'd like to be able to try and roll this out and we're really hoping that we can have it out you know most across most of the machines by this time if I just said no that's impossible and stopped there this person would be left going well I have some type of expectation that I was working with other people on this and I'm now asking for help and support on it and it's fine if it might not be possible even though that's what you want but now this person is left with well what do I do now and if they're coming to you as the expert so if they're coming to me in this case and saying this is what I would like from a deployment team I need some help here if I just end the conversation and I don't provide any further guidance they're left wondering well what the heck am I supposed to do next and it might seem obvious to you when I put these examples in front of you that you're thinking well it's probably easy to answer this person and just give them a little bit more guidance right like why is it that deployment can't do that or what's the alternative if deployment can't do that what can we do in the first example if I said well that's not what SQL databases are used for maybe I could suggest well maybe you should try a document store that might be a better fit or if you need the properties of a SQL database is there a reason why you're trying to put things into Json and if I just took more time to understand that person's scenario maybe it's totally cool and acceptable that they're combining some type of data structure like that and putting it into sequel the point is that when you have conversations like this and communication where you just end the conversation and don't provide any more breadcrumbs for someone to continue it can make problem solving a lot more challenging ultimately the goal if you're working with other people whether they're in your organization directly or not same team or not you're all working towards a common goal or you should be at least right if you're working at the same company you might have different priorities but ultimately you're there to try and help improve the lives of your customers so it to me seems really weird that you would have limiting behaviors like this in some types of your conversations and different communication and not try to progress solving problems together so now that I've explained what this problem is and why I think it has such a big impact like I said especially as you become more senior you're exposed to more of this and likely you're in conversations where these different scenarios or bigger impact what can we do about that especially if I'm saying this and you're realizing hey yeah kind of talk like that right I can understand if you're in situations where you're feeling maybe a little bit overwhelmed you're feeling bothered by having lots of incoming questions like this it's just not a good pattern to get into so I wanted to be able to offer you some type of advice and hopes that you can try to make this a little bit better and for folks that aren't yet in this position just having some awareness about trying to improve this type of communication by the time you're in a position where you might experience it the first thing that I feel like is the most obvious is explaining why you don't think something is feasible I think offering context even if you're not giving them the next breadcrumb about what to do giving them the context about why something doesn't line up with what you think May in fact give them just enough of a breadcrumb to be able to ask you more questions right so in the first example about this Json structure going to SQL if I just said to them no that's not what sql's used for like I'm not really explaining myself like what is it about SQL that doesn't really line up with that I should be able to say well sql's supposed to be designed to be a relational database and you probably have records with columns that map to that data and an object store database is probably more suited for that right that's almost two parts and that might give them enough information well what do you mean object database like what does that look like but even the first part of that and just explaining why sqls usually not suited for that might get them to ask questions and you can provide more insight in the second example if was talking about the deployment team that I have and people coming to us I might be able to say hey look deployment is not able to go that fast because it's unsafe based on the different standards that we have if I could explain a little bit about our safe deployment practices the person who's asking the questions might go oh I didn't realize that and then start to ask other questions like so how fast can we go what is safe right they're not aware of these constraints and they're not sure that they can even ask those questions in the first place if they don't know about it so part one is providing extra context the next part building on top of that I think is a great option if you can go back to them and provide alternate Solutions or at least a direction to go in right so going back to the first example I mentioned document store databases I might be able to say hey have you considered or something else I think that a document stor database might be better suited for that it seems to be that these things are created for such a purpose so maybe you might want to go check that out if you haven't already in the second example with the deployment team I might be able to go back to this partner that's asking for some help and say well here's some things we could do in order to go faster but maybe not as fast as you're looking for so the second piece of advice is really just looking to try offering some additional Solutions and if you don't have those additional Solutions at least pointing them in the direction of where they might be able to get their questions answered could be very helpful and the third and final piece of advice that I'd like to offer you in this situation and it's not necessarily that it has to happen third it's just the third one in my list is asking more clarifying questions back to the person asking for help if you as the person receiving the question can understand the challenges more clearly you might be better situated to offer more contextual advice back to them I know if you're overloaded and trying to answer questions for partner teams and people coming to ask you for clarification you probably want to get this stuff out of your way cuz you're busy I understand but the reality is if you're not giving people the information they need and not supporting them they're going to be in a worse off situation so if you take a little bit of extra time just to understand the context you might even be able to redirect them to somewhere else much more effectively in that situation not only you getting some of your time back just by asking them a little bit more detail but you're going to put them on a better track to get their question answered and you can save yourself a lot of back and forth time if you're trying to avoid that because if you understand there circumstances more clearly in the first place the advice that you could offer is going to be way better so this is a quick video on some tips that I have for trying to reduce limiting behavior in communication for software engineers and if you want to see some other advice about two words that you can swap in your vocabulary that help a lot check out this video next thanks and I'll see you next time