Latest / DevQuestions with Tim Corey / 027 How Do I Communicate What I Do To a Non-technical Boss?

Transcript

027 How Do I Communicate What I Do To a Non-technical Boss? · DevQuestions with Tim Corey

• 0:00
  SPEAKER_00: Welcome to the Dev Questions Podcast with Tim Corey.
• 0:03
  SPEAKER_00: Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology.
• 0:12
  SPEAKER_00: If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered.
• 0:19
  SPEAKER_00: Now, here's your host, expert developer and online educator, Tim Corey.
• 0:24
  SPEAKER_01: How do I communicate what I do to a non-technical boss?
• 0:29
  SPEAKER_01: This is a question that Switta asked me recently that I want to cover in today's episode of DevQuestions.
• 0:36
  SPEAKER_01: Now, software development is both the process of creating something new and connecting existing pieces together.
• 0:46
  SPEAKER_01: And that's that's the difficult part about what we do because the existing pieces, that's kind of the easy part.
• 0:55
  SPEAKER_01: It's the known part.
• 0:56
  SPEAKER_01: And so when we look at, we've talked about project time estimation and how you do that well in a previous episode of Dev Questions.
• 1:05
  SPEAKER_01: And we talk to the idea of breaking things down and identifying, you know, what those different pieces are, because when you look at a project, you tend to see the things that you know how to do.
• 1:17
  SPEAKER_01: And those seem pretty not necessarily easy, but known.
• 1:22
  SPEAKER_01: And so you go, okay, I know how to do that, and I know how long it's gonna take to get that done.
• 1:27
  SPEAKER_01: But then it's those new things that you're just not sure of.
• 1:30
  SPEAKER_01: And new things, they can take five minutes or it can take five hours or five days or five weeks, been there.
• 1:40
  SPEAKER_01: So that can be difficult when you're communicating with a non-technical boss to say, I don't know.
• 1:49
  SPEAKER_01: And a non-technical boss, from their perspective, they need to know.
• 1:54
  SPEAKER_01: They need to know how much this is going to cost them.
• 1:58
  SPEAKER_01: So the first thing I would do if your boss is non-technical is share this illustration with them.
• 2:06
  SPEAKER_01: Think of software development like being a chef that has to create new recipes all the time.
• 2:14
  SPEAKER_01: You see, chefs know how to make the recipe they've made a thousand times already.
• 2:19
  SPEAKER_01: They know how long it's gonna take, they know the ingredients, they know the steps, they know the process.
• 2:25
  SPEAKER_01: But when they create a new recipe, how do you estimate that?
• 2:29
  SPEAKER_01: How long is it gonna take?
• 2:31
  SPEAKER_01: How many blind alleys do you go down?
• 2:34
  SPEAKER_01: How many times you have to redo the process over because it didn't work quite right?
• 2:40
  SPEAKER_01: You know, you thought that this spice and that spice and and this thing would go together well, and they just didn't.
• 2:47
  SPEAKER_01: Now, as you get more experience, as you become a world-class chef, you'll know how more of those things fit together.
• 2:55
  SPEAKER_01: And that's the same thing with software developers.
• 2:57
  SPEAKER_01: The more code you've written, the more things you know how to go together well, the less that's um brand new and more is just kind of doing what you've already done before.
• 3:09
  SPEAKER_01: And the same way.
• 3:10
  SPEAKER_01: So share that illustration, kind of set the stage for this is the stuff that I go through so that your non-technical manager or boss knows that it is difficult, and it's it's not something that you are just being difficult about, and it's not just you're not skilled enough.
• 3:32
  SPEAKER_01: There is an element of the unknown in what you do.
• 3:36
  SPEAKER_01: But I think there are four keys to communication with a non-technical boss.
• 3:43
  SPEAKER_01: Number one, be patient.
• 3:49
  SPEAKER_01: Be very patient with your non-technical boss because you are speaking in a language they don't understand, and yet they are responsible for making decisions about what you do.
• 4:07
  SPEAKER_01: So it's going to take some patience, it's gonna take um communication over and over, it's gonna take um over-communication, it's gonna take time to build a relationship.
• 4:20
  SPEAKER_01: Be patient with all of that.
• 4:22
  SPEAKER_01: Don't feel like because you know software development that you're somehow better than they are.
• 4:29
  SPEAKER_01: It's your responsibility to be able to communicate with them.
• 4:33
  SPEAKER_01: So be patient, number one.
• 4:35
  SPEAKER_01: Number two, when you're talking to your non-technical boss, reduce or eliminate jargon.
• 4:45
  SPEAKER_01: Jargon can become a language of its own.
• 4:49
  SPEAKER_01: So if I say, you know, um I built my C sharp ASPNet Core application, it was a actually a Razor Pages application.
• 4:58
  SPEAKER_01: I use a CIC process on Azure DevOps to package that up into a Docker container, which I uploaded to um, you know, Azure Kubernetes Service, and from there we we scaled it out.
• 5:12
  SPEAKER_01: What if you're not technical, those words mean nothing.
• 5:16
  SPEAKER_01: And even if you are, half of those might not, anyways.
• 5:19
  SPEAKER_01: So reduce or eliminate the jargon.
• 5:23
  SPEAKER_01: Say I built a website and I used an automated process to make sure that it was built correctly and that it was deployed automatically, or it was put on the production servers automatically.
• 5:39
  SPEAKER_01: We use a service that allows us to scale out so that as more people hit it, we can still maintain a load on those servers that's appropriate.
• 5:49
  SPEAKER_01: And if we have too much load, we create a duplicate of our site so we can have that load now shared.
• 5:57
  SPEAKER_01: That's different, and yet that communicates to our boss the same thing without all the jargon.
• 6:06
  SPEAKER_01: And if the more you learn to talk without the jargon, and if you do have to use jargon, you explain it.
• 6:14
  SPEAKER_01: So if you have to talk about Azure DevOps, if your boss says, What's this bill for Azure DevOps?
• 6:22
  SPEAKER_01: Say, well, Azure DevOps is a place where we can store our code.
• 6:28
  SPEAKER_01: Now, none of these things are perfect.
• 6:30
  SPEAKER_01: They're not gonna your illustrations, your your um non-jargon speak speech won't be perfect.
• 6:39
  SPEAKER_01: It's not gonna be the exact thing it does because storing code is not really what Azure DevOps does.
• 6:48
  SPEAKER_01: It uses Git to version our code and allow us to you know uh be the central location for our code storage.
• 6:58
  SPEAKER_01: And you don't have to explain that.
• 7:00
  SPEAKER_01: Just say it's the place where we store our code and that that backs up our code and make sure that if we make a mistake on our machine, we can get the older version of our code.
• 7:10
  SPEAKER_01: We have a history of our code, and it also allows us to have all of our issues.
• 7:15
  SPEAKER_01: We have a list of issues, um, Azure Boards, where you know we have a list of issues that we can prioritize, we can make sure that we do them in the right order and that we um figure out which features we want to add to the software and what their priority is.
• 7:31
  SPEAKER_01: And then there's a place where we it takes our software and makes sure that it's written correctly and that it then uh sends that out to our different servers.
• 7:43
  SPEAKER_01: That'd be the CICD process of um our Azure DevOps, and then you can keep going like that, where you explain what it does in a way that makes sense in a way that your non-technical boss can relate to, and that allows you to have a common ground to communicate.
• 8:05
  SPEAKER_01: Because then going forward, you can say Azure DevOps because your boss remembers, you may have to remind them, but your boss prior remembers what you talked about, about how important Azure DevOps is.
• 8:17
  SPEAKER_01: So you've kind of increased their vocabulary a little bit, and you've created some common ground to talk about when you talk about your various systems.
• 8:28
  SPEAKER_01: Now, that's number two for a key to communication.
• 8:30
  SPEAKER_01: Number three is focus on the outcomes.
• 8:35
  SPEAKER_01: It's often easy to get tied up in um the process, in the process of building the software.
• 8:43
  SPEAKER_01: You know, your boss says, you know, why is it gonna take an extra four weeks to build a software?
• 8:48
  SPEAKER_01: And you say, well, because you know, we need to implement uh, you know, TDD, again, jargon, but we need to implement, you know, test-driven development and make sure that we you try all the things that you're doing, not the outcomes.
• 9:07
  SPEAKER_01: If instead your boss says, why is it gonna take that extra four weeks?
• 9:10
  SPEAKER_01: You're gonna say, we're writing software to test the software you wrote.
• 9:15
  SPEAKER_01: And the reason we're doing that is because at the end of this, first of all, it's gonna find the bugs earlier.
• 9:22
  SPEAKER_01: It's gonna find the bugs in our software before it goes to production and takes production down.
• 9:26
  SPEAKER_01: But also, it's gonna make it easier for us to fix bugs once we find them.
• 9:32
  SPEAKER_01: So if it doesn't catch a bug and you find it later, it'll make it easier for us to identify where that bug is and fix it so that if there is a bug that goes to production and it takes production down, that we can get production up faster.
• 9:49
  SPEAKER_01: So now you're talking about outcomes.
• 9:51
  SPEAKER_01: The outcome is that you'll have better software that is easier to maintain, and that takes production down less.
• 10:00
  SPEAKER_01: Those are outcomes.
• 10:02
  SPEAKER_01: Those a boss can take to their boss and say, the reason we're gonna spend an extra month in this project is because we've got something that will allow us to write better software and have less bugs in production.
• 10:18
  SPEAKER_01: Everyone all the way up the chain can understand that.
• 10:21
  SPEAKER_01: So focus on the outcomes, not on the process.
• 10:26
  SPEAKER_01: And number four, and this is a long-term thing, but build trust.
• 10:31
  SPEAKER_01: Build trust with your boss.
• 10:35
  SPEAKER_01: Be honest in saying things like, I was wrong.
• 10:40
  SPEAKER_01: Or that didn't go the way I thought it would.
• 10:43
  SPEAKER_01: Where maybe you say, you know what, I know, and don't ever say this, I know for a fact this software will only take two weeks to write.
• 10:51
  SPEAKER_01: Clue, it won't.
• 10:52
  SPEAKER_01: It'll take more than that.
• 10:54
  SPEAKER_01: Um, so don't say that.
• 10:55
  SPEAKER_01: But if you did, and it takes three weeks, be honest about that and say, you know what, I was wrong.
• 11:03
  SPEAKER_01: And here's the things I'm doing for the future to make sure it doesn't happen again.
• 11:08
  SPEAKER_01: And create a track record of being reliable, of eliminating that jargon so it's easier to understand what you're doing, about being patient when your boss is frustrated, about focusing on the outcomes and about what your boss is most uh focused on, too, so that your boss comes to trust you as a partner rather than a person to be controlled.
• 11:36
  SPEAKER_01: That comes through time, it comes through you being patient because it's not gonna happen overnight, probably.
• 11:42
  SPEAKER_01: But build that level of trust with your boss so that when things do come up where it's hard to communicate, where you might even say, I don't know how to eliminate this jargon, I don't know how to explain to you why this is so important, but it really is important that you will have a measure of trust with your boss that you can say, This is important, and your boss says, Okay.
• 12:13
  SPEAKER_01: So those are the four keys of communication.
• 12:16
  SPEAKER_01: It's gonna take time, it's not gonna be perfect.
• 12:19
  SPEAKER_01: And again, number one, be patient because of that, but you can effectively work with a non-technical boss as a software developer.
• 12:29
  SPEAKER_01: I've done it, I have succeeded in that.
• 12:32
  SPEAKER_01: I've had great bosses who really knocked it out of the park for me.
• 12:38
  SPEAKER_01: They they were my biggest fans and they were my biggest supporters, and they helped me a ton, even though they didn't know a line of code, they never saw my code, they never had a clue of how my code worked.
• 12:53
  SPEAKER_01: But by doing these four things, these four communication steps, they were able to trust me, they were able to um understand what I was trying to accomplish, and we were able to work together well.
• 13:09
  SPEAKER_01: So, four keys of communication, follow those four keys.
• 13:12
  SPEAKER_01: It will definitely help you out.
• 13:13
  SPEAKER_01: So, thanks for asking the question, Swita.
• 13:15
  SPEAKER_01: If you would like your question answered in the series, um either go to the podcast page and fill that form out with a question that you think that would be valuable for everyone to uh hear, or leave a comment on any of the YouTube videos in this series, and I will try to get to the question.
• 13:34
  SPEAKER_01: I will at least add it to the list and um hopefully get to it soon.
• 13:38
  SPEAKER_01: All right.
• 13:38
  SPEAKER_01: So if you're listening to this via podcast, I love if you give the the podcast a review, preferably a good review if you like it, um, because this allows other developers to find the podcast and also it helps them see that it's valuable for them too.
• 13:56
  SPEAKER_01: Now, no matter if you're listening on the podcast or watching us on YouTube, I appreciate a share.
• 14:02
  SPEAKER_01: I appreciate any comments and feedback you have as well.
• 14:06
  SPEAKER_01: Thanks for listening.
• 14:07
  SPEAKER_01: And as always, I am Tim Corey.
• 14:09
  SPEAKER_00: Thank you for joining us for this episode of Dev Questions.
• 14:12
  SPEAKER_00: Tim is committed to making it easier for you to become a developer.
• 14:16
  SPEAKER_00: If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions.
• 14:23
  SPEAKER_00: You can also send your questions to questions at Iamtimcorey.com.
• 14:28
  SPEAKER_00: Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did.
• 14:35
  SPEAKER_00: When you're ready to learn to think and code like a professional developer, head over to IamtimCore.com and enroll in a course.