As software developers, we're always very focused on the technical aspects. However, when it comes to working with other stakeholders, how can we translate the value of what we're doing so they get it?
📄 Auto-Generated Transcript ▾
Transcript is auto-generated and may contain errors.
all right folks I'm just headed to the office I got the insta 360 going it's Friday and uh depending on how this video uploads you'll potentially see little Vinnie and veto in the window behind me super cute okay let's go um topic today is from something that was submitted um from an engineer on LED in I think this is a in my opinion a very important topic like pretty relevant and uh I would imagine many Engineers probably maybe not at the junior level but when you're going from midlevel senior and especially Beyond uh you'll start to notice that this becomes probably like increasingly important um so uh we're going to talk about trying to convey U business value business impact in the work streams that we have and um just want to make sure that I can turn out of here first and then I'll
I'll start going but it's probably a good opportunity to remind folks if you want questions answered you can uh submit them in the comments below or reach out to Dev leader on social media that's also my main YouTube channel and uh you can send me a message I'll keep it Anonymous and uh also a reminder too if you want your resume reviewed at the time of recording there's no pay wall or anything you can go to my main YouTube channel Dev leader look for the resume review playlist uh if you watch the beginning of a video it'll explain how to submit your resume and uh at this point not pay Walt but if there's increasing demand because it costs me money to edit those videos I literally lose money to edit or to to uh to review your resumés but I think it's uh I
think it's valuable so I want to make sure that I can try doing that for folks so but that said let's talk about conveying business value so the uh I'm not going to go into the specific situation that this engineer is kind of going through um because it's I mean I'll try to keep that part I don't know like more generic I suppose um and the idea is that they're working on mostly I would call like a platform slash uh not quite devops but like internal tooling like it's going to affect productivity of Engineers um and when I was chatting with them they were describing to me that they're having some difficulty in terms of uh they're saying the metric that they have is sort of challenging and the reason that they were saying to me the metric that they're using to try and convey
like the importance of this is challenging is because it actually is like a bit of a moving Target so as they make progress the metric that's being used is Shifting and so they were describing this to me um and I I just want to be very transparent because i' I've already kind of chatted with them on LinkedIn uh to go back and forth on this so I I've already said it directly to them but in their situation I do think that they're working on a project that I would consider having a lot of business value um so I just wanted to to make that very clear but when they're trying to explain it or why they're having challenges to me I was saying to them I think you're I think you're missing the point uh to kind of put it bluntly right um I think
that when you're describing having sorry I have to wave someone on here this person thinks I'm letting them go you can watch in the insta 360 I'm literally not waving them on but whatever let's you can go go lady it's fine fine I'll just sit here forever um this light out this light ahead is out so it's kind of crappy and my camera just fell off the ceiling let's put that back on suction cup power everything's going wrong this road is going to be an absolute part of my language show but let's see sorry for the disruption here my God this road is such a disaster now oh my God okay couple couple more seconds here let me get through this just cuz I want to make sure I'm paying close attention okay okay well at least if the insta 360 doesn't fall off my
car you can see what the road looks like they've been working on this for a little while and the uh if you're looking at the road itself you might see like they have these huge Metal Sheets on the road like this whole thing has got to be torn up I can't imagine like they can't leave it like this and I I can't imagine they just try to Pat the spots like the whole thing has been torn up and you can see him about to drive over another spot like you're not going to go patch this like you need to repave this entire thing it's a nightmare and there's potholes everywhere anyway okay we're through that so the um the metric that they're talking about when I'm hearing them talk about this metric and that it's moving and that's why it's challenging and cuz they're saying
like I can't do a good job kind of conveying the significance of this project right and I'm going like I just think that you're talking about the wrong metric to be to completely blunt so um the metric that they're describing is very much an engineering metric it's a count it's a count of things so the I know I'm kind of being very generic here uh I'm trying to think if I can just come up with other random examples but um you could talk about account of dependen that your code base has you could talk about a count of repositories that are in your code base if you're familiar with like C and net development you could be talking about just a count of projects right it's a it's a count of things and what they're saying is that they have this count and as they're
making progress that count uh it will un they'll uncover more things and that count will change and they're saying that's why I am having a hard time conveying conveying business Val and what I'm saying is I think even if you could perfectly predict that count that that's not going to help you convey the business value because the count is not something that anyone cares about at all except the people that are doing the engineering work because they'll understand what that means anyone else from a business perspective is not going to care about that number if I went to my my CVP at Microsoft and I said hi I'm doing this project and we're going to uh reduce the number of repositories we're going to reduce that from 100 to five I don't I don't think she'd give a she'd say like like or how much
effort's that going to be and what's that going to get me oh it's going to take a year and it's going to take a full team of uh 10 people it's going to take a year and what does it get me well we'll have fewer repositories like this is the the challenge right like the the metric that is being used used is not it's not a useful one let's get away from that guy with the trailer god um and it's sorry when I say it's not a useful one it's not a useful one for the audience right it's a useful one for the people working on it because that's what they're going to be looking at and for them it might be a measure of progression through the project but it's certainly not conveying business value so when I was talking with this individual I
was uh trying to find ways where it's like um you know i' go back to them and and try to ask them essentially like different ways to try and get them to say what the value is um and it's a and I'm not I I don't mean to pick on this person because it's a very common thing but they would put a lot of effort into the response which I appreciate and they would elaborate further but they're still elaborating on like on that number and like and how it's being measured and I'm going like it's maybe I'm not being clear when I say this but like I'm trying to tell you that I don't give a about the number so like again I understand from an engineering perspective exactly what's going on because I I actually do uh fully understand like what this person is
is trying to accomplish like I I get it but what I'm trying to show them is like the the number that you're telling me ites it has no significance from a business value perspective I need you to think about the outcomes of this right so it's a really challenging exercise because I would go back and I would say no like tell me tell me more about the the impact this has or tell me like which like who cares about this right and it's like well people should care about this because if this number goes down then um and then they would give me like another answer that's not like a very tangible business impact so I'm going okay I need to find a way to to try and explain to this individual that it's not that you're telling me bad things or wrong things like
you you're literally justifying things which I think is great the problem is that how we're communicating that is not effective again it might be effective to me as another engineer where and as a you know I I understand the space that so like I said I get it but I don't need you to justify it to me I need you to think about justifying that to someone who is thinking about the business so um and to be totally transparent the last part of our conversation I'm not totally convinced I left because I had to start working I'm not totally convinced I left that conversation at a point where I was like I think this person or like I made a breakthrough with them and that's not that's not a fault of theirs right again trying to be transparent here I'm not picking on this person
I'm trying to spend time with them to explain like you know pretend I am you know uh your manager or your manager's manager like someone who's uh in like more senior leadership that needs to fund this project pretend I'm that person how are you going to convince me that there is value like why should I invest into this right this is this is a challenge because as Engineers we always think about the technical imp implications of what's going on right but we're Engineers working in a business so what do businesses care about right so one of the last things that I had said to them was like okay let me let me go one step back not the very last thing but one of the last things I said to them was trying to see if I could make them step away from the the
pure engineering language right and maybe this wasn't effective but my train of thought was like okay how could how could I make someone step away from engineering language well think about some people that you might talk to that have no idea what you do for work right you you know that you can't go at least for my mom I couldn't talk to my mom and be like yes like I'm GNA have fewer repositories or we're gonna have even fewer lines of code she would be like I don't know what you're talking about right she might be excited for me because I'm excited about it but she's not going to understand no offense to my mom I love my mother my father might get it a little bit more because he's worked in Tech but like he might I think with my father he might kind
of be like oh yes I totally get and he probably wouldn't really um oo something on the road um so I was like okay like imagine you had to tell your mother or father that you're working on this project for work and you want to tell them why it's so beneficial for your company and again I don't know maybe maybe this person would repeat the same thing and say like I'm driving this countdown to some number and therefore that's the benefit maybe and like I would say okay well then we need we still need to work on the communication so um I think my framing with that though is trying to get them to step away from the technical part the technical part is valuable for the people that will be working on the project we have lots of different stakeholders with big projects right
we have the people that are carrying out the work we have people that are trying to help coordinate the work there's going to be potentially different teams involved that might have different responsibilities so you have to kind of like partition the technical information to the different groups but then there's going to be people that are mo more focused on like business or they're trying to think about how parts of the organization are operating and the level of technical depth will be reduced and the level of like business impact will be increased in terms of what they want to focus on I mean or their level of understanding of these things what they care about so the next part that I was saying to this individual was like okay you could Pro I I didn't give it that much thought but I was like the things
the few things that come to mind that a business would really care about are going to be money time and risk there's probably other ways to slice this but these three things came to mind so what I had said to them before kind of uh having to shift gears and start working um was like you keep talking about this number and how it's a moving Target but like when it comes to time risk or money tell me about that like as someone who might be a business stakeholder that needs to fund this like those are the things I care about are you helping me drisk things are are you helping us save money or create more money for time right like if we're going to be investing resources into this like either people or money both because people cost money if we're doing that are
you going to be reducing my time for other things so we put in I'm just going to make up an example in terms of like human hours we put in a thousand human hours into this but going forward we're going to save you know uh 2,000 human hours every year and just making something up right so you you're trading something we're trading some time and money and that means we're going to be able to move faster going forward than I might try to rationalize that investment so I had said like those are three things I want you to think about and I mean obviously if you can think of more that's great but again from a business perspective I don't care about number of rep depositories number of dependencies specifically number of lines of code tell me about those three things and how they relate
to the business so in one of their messages um they had hinted at like being able to um save time so they were again we're talking about some internal tooling that kind of thing and they were saying um you know for an organization of like I think the number is like 350 people so assume like just Round Up to 5 00 people there's going to be 500 people that can potentially be impacted by this positively on a regular basis and it's going to save them time in one of the steps that they have to do for 500 people across an organization okay like I think we're getting somewhere now right you're talking about the scope of the impact right the scope of the impact is for an organization of 500 people and this is just one slice of things by the way one way to
look at it but for organization of 500 people they're going to save some time awesome okay how much time are they going to save right like and and on what because I think that now you're getting somewhere so let's assume it's 500 people and we're talking about build infrastructure okay and let's assume a build takes I'm just going to make up right it's going to take 3 hours so it's going to say 5 00 people um on a on their builds that take 3 hours it's going to reduce things down to 1 hour so their costs have been reduced to 33% or like a 66% 67% savings okay and how often are they are they doing these builds and waiting on them well every day okay so you're telling me that 500 people every day are uh you know wasting 3 hours or at least
have potenti blockages for 3 hours and we can trim that down to 33% of the time okay now we're really getting somewhere now there's some nuances to that like okay what is that actually blocking people right if they had because it's not necessarily work is being done serially all the time you can do things in parallel so one might argue okay um that's not actually having a that much of a positive net effect because it's not like the critical path of people's work but it if that even if that were the case it might give people more agility in their work so imagine if you were at a company and you were used to builds taking just going to make something up a build takes a full day so a work day is eight hours let's say a build is going to take eight hours
always nervous to drive by cops I don't drive crazy or anything but I just saw a cop and I'm like is he going to pull out um so let's assume a bill takes 8 hours and you're at a company and you just get used to it taking eight hours you get your work done and you're pushing uh your changes up and you're like well I got to wait 8 hours you would probably change how your your development looks such that you would say I'm going to make sure that before I leave for the end of the day I'm going to push things up so the build can run right eight hours overnight I don't give a about that I'm G to come in in the morning and it's going to be ready and you would kind of change your working schedule and your working habits
around this now I'm not saying that's good by the way but if that's how things were you might change your working habits but if instead if I said hey like we can make that build only take 20 minutes or it can take an hour whatever now you have a lot more agility or flexibility in how you're doing your work right you don't have to say Okay I'm going to schedule everything so that at the end of the day I go push it up no you could be pushing up stuff you know over your lunge break and then getting the build and then you're good to go so that's a little bit harder to quantify but at least we're able to start talking about potential Time Savings if it was a critical path and the scope of people that it's going to affect right that's one
part in this individual's situation he was also talking about drisking from a technology perspective so being able to talk about uh an organization in terms of their their technology being locked in so having a huge dependency that is uh you know their Tech stack is tightly coupled to some third parties uh Tech stack and at any point like they could be at the mercy of you know that third party being like ah we're closing shop or yeah we're going to start you know putting a licensing cost on this so they're saying because this dependency in this technology is so great that it is risky furthermore there's example apparently I don't know all the details but they said there's apparently examples of them of this third party do some of these things before so it's not just like totally like oh it's a conspiracy they could
do it it's like no there's been some evidence that they operate a little bit like that so come on what's going on here um so there's another whole aspect right we we're talking about Time Savings now we have this story that could be drisking and drisking can be hard to quantify as well but I think we have to talk about um like the significance of some of these scenarios right so for I'm just going to make up an example this technology is so intertwined that if uh if they were to put a licensing cost on this that was like per seat then we would look at how many uh developers or how many build uh sites are are using this and we could estimate like this is how much you know cost could go up uh based on some other data right like if they
were to make their licensing you know $1,000 a year per seat like we would be paying this much um so like you could be looking at things that way but the point is that from a business being locked in could be pretty scary uh again you lose agility uh you could have Associated like uh like Financial costs um you this maybe this might be a little bit harder depending on to sell sorry based on who you're talking to but uh try to explain that like you're locked into a technology and that would mean if there's more advancements I'm just going to make up a totally random example imagine that you were a business and you decided at some point in the business's past we're going to make our own database our own database engine and it's going to be great so you build all of
your products using this database engine and everything's extremely coupled to it and then at some point like 15 years go by and someone's like look man like I don't know why we're using this database like there's a million other options that are like highly optimized ours is like kind of ridiculous it's like homegrown it's always buggy it's slow but like everything we have uses it and it's super uh sorry got to move over for people and it's uh super intertwined like we can't really do anything about it like that's a risky spot to be in because it means from a technology perspective like what are you going to do it's going to be really hard to refactor things it's going to be really hard to uh you know if you're like we want to unlock new performance gains or uh that could be even Integrations
with other system systems you might say it's going to be so much more complicated to do and that puts us at a risk because when these opportunities come up that we would want to take advantage of we can't pivot to them we'd have to invest so much more at that point just to be able to do it that's a risky thing because we're unable to have business agility and take advantage of opportunities cool like I think that could be a really interesting story right so at the end of the day I think that as Engineers like I get it it's we have our mind on the things that are technical they're in front of us they're they might be quantifiable to us they make sense from how we would think about progressing through things but it's a huge opportunity for people to improve this skill
about thinking about communicating to your stakeholders soft skills right and I'm not saying I again I just want to be clear like I I don't think that the person that was messaging me I I fully believe they have a solid project I think that they're a very intelligent person so I don't mean for any of this to come across like oh this guy's a dummy he doesn't know what he's doing absolutely not um but this is such a good opportunity to be practicing this right I think he's got a great project something that does have a lot of impact and let's like let's find a way to get him to convey that business impact and like I say I say all of this like I I'm he's watches the videos I'm going to send him this video right I'm not uh literally not trying to
pick on him or anything I'm trying to use this as a generic example to walk through like why this kind of thing is so helpful um so for you you as in General audience um it might be very helpful to consider like okay let's park like you might have in your mind why something's important okay but let's park the technical aspects of it for a moment and then think about it if you were running a business goals of a business are going to be to generate money right there is a a customer that you are serving customers will pay money for value and then in the end the business makes money that's how people are able to get their salaries and businesses grow that's fundamentally what businesses are doing so it's not enough to want to focus on projects you might think a project is
really cool because it's interesting to work on um it might there might be some technical aspects to it of it where you're like this is exciting for me or yes we get to use newer technology but just being able to use newer technology does not necessarily mean that there's a positive business as uh element to it right so we if we think about the cost of the investment that goes in right let's it's going to take 2 years for us to finish this and well the gains are going to be that every year we say save 100 hours it's like well that might take us X number of years to go recoup our investment and then there's this opportunity cost where we could have been working on other so so no like even though yes you're proving a benefit and yes there is some business
value relatively speaking the business value is not worth it so I think it's really important to be able to think through this stuff and I think sometimes that's why um a really common one that I know developers get uh get stuck on and get pissed off about is like Tech debt right there's a lot of frustration we don't get time to address Tech Deb No One lets us do it we don't get to schedule it everything's falling apart the code base is spaghetti product managers don't understand my engineering manager is opposed to Tech debt it's like what are you like when you're trying to tell them the significance of addressing that Tech de what are you telling them this code is really messy who gives a this code is hard to test who gives a what's the impact of code that's hard to test well
it's always buggy well is it that's Legacy code that's been running for 10 years and like what are the what are the customer reports for bugs there extremely low okay well don't touch it like we're not investing into that right you have to you have to start thinking about these things from like a a business business impact so just because code is messy if you're not going back to go iterate on that code to go add more features or because it is bug ridden and customers are complaining about it why are you spending time trying to go clean it up it's probably not a good use of time I'm not saying that the code can't be cleaned up I'm just saying that it's probably not a good use of time and I think that's really difficult for some people to get but then they're unable
to understand like well they get frustrated like I don't know why it won't get prioritized it's because unfortunately a lot of the time and not and I'm not saying this is universally 100% of the time before people get too triggered um unfortunately lot of the time people just have a really difficult time trying to con convey the impact of it right it's Legacy code it's hard to work in so what oh you want you know you want to go uh add these new features for for this part of the product and guess what they're all in this space it's actually going to take us um you know significantly longer to be able to go even introduce these features and because that code's all untested and it's a critical part of the code base we're actually going to be highly at risk of introducing bugs to
that critical part and unfortunately because there aren't tests we're not going to know until that code is being you know exercised at scale and so again risk right time it's going to take us way more time but if we were do invest some time up front we could actually shorten the time maybe not for these this first set of features but you said you wanted to keep investing here right so the future features will also go faster so a little bit about front cost but we're going to drisk significantly and allow us to have more speed going forward that's a more positive story than the code is spaghetti so anyway um I hope that helps but yeah we have to think about how we're messaging business value to stakeholders so thanks for watching and I'll see you next time take care
Frequently Asked Questions
These Q&A summaries are AI-generated from the video transcript and may not reflect my exact wording. Watch the video for the full context.
- How can software engineers better convey the business value of their projects to non-technical stakeholders?
- I advise engineers to step away from technical metrics like counts of repositories or dependencies and instead focus on outcomes that matter to the business, such as saving time, reducing risk, or saving money. By framing the impact in terms of how it affects business goals, like improving productivity for 500 people or reducing build times, the value becomes clearer to leadership and business stakeholders.
- Why is focusing on engineering metrics alone insufficient when explaining project value to business leaders?
- I find that engineering metrics, such as counts of dependencies or lines of code, are meaningful only to engineers working on the project but do not resonate with business leaders. These numbers don’t explain the impact on money, time, or risk, which are the key concerns for business stakeholders who decide on funding and prioritization.
- What are some effective ways to communicate the impact of technical debt to business decision-makers?
- I recommend framing technical debt in terms of business impact by explaining how messy or untested code increases risk and slows down feature delivery. For example, investing time to address technical debt upfront can reduce the risk of bugs and speed up future development, which translates to cost savings and faster time to market, rather than just saying the code is hard to work with.