Soft Skills Engineering - Episode 423: freedom from deadlines and Actual firefighting to software firefighting

Episode Date: August 26, 2024

In this episode, Dave and Jamison answer these questions: Thank you hosting this show. This show has given me a lot of insight on nuisances of engineering that isn’t mentioned anywhere. Having some experience in industry for a while, I always find in this position where I want some autonomy but I am bounded by the deadline. What do you think should be the way to start a career that gives autonomy while having that sweet benefits from the industry? I used to be a senior manager of an operations team for a fire fighting service in Australia. I managed all of our physical operational assets - for example radio towers, mobile communications e.g. 5g, 4g technologies, mobile data terminals e.g. laptops in fire fighting appliances “fire trucks ;) “, data centers, networking so on… A restructuring means my team has grown to include in-house software development. While i am excited for this opportunity and on board with the changes, it is a very big shift from the physical and electrical engineering side to software development. The C level staff thinks the team lacks focus and there are “problems” to address. I have been meeting the new team and working through the changes. They are very nervous and are skeptical about how I’ll understand their world, which is fair. How can I best support this team? What are cultural things I should be aware of? What are key metrics I can measure that will fairly represent their hard work to the executive team? Any thoughts on what things a manager or managers can do to be supportive as the new drop in from across the room from a entirely different engineering discipline? Coding in my world is scripting and hacking about to make things work (telecommunication engineer)

it takes more than reviewing every change to package lock.json to be a great engineer this is soft skills engineering episode 423 i'm your host dave smith i'm your host jamison dance soft skills engineering is a weekly advice podcast for software developers who just would rather not review all 10 000 lines of the package lock json changes yeah i'm not a good i'm not a great engineer then because i don't look at that crap actually do i i guess i look at it as a signal of hey it got a lot bigger maybe we didn't mean to add all those dependencies but actually maybe i am a great software engineer because we actually have a pnpm lock.yaml oh i'm the more hipster refined version of the package lock.json file yes that's not what this show's about i'm gonna

thank our patreon our patrons we have weekly shout outs to hawk to a some kind of compound banana family emoji javier gonzalez chewy ted timbrel become a senior engineer.com unsalted french fries are morally objectionable dan from drone deploy chase w norton level up your type script with type here.dev never is not just a crater on mars flamingo emoji i like chicken i like liver miamix miamix please deliver trash panda the computer science book.com kyle boss kensi dodds nevar is not just a planet in the vulcan system jenny kim own shardle the stochastic parrot helicone.ai best observability tool for ai red panda is best panda everyone in this list jonathan king zanai beautiful functional user documentation an nth one-time shout out to will

angel is a great engineer travis braden canes lies damn lies and product driven deadlines If you would like to join this illustrious crew, go to softskills.audio and click the Support Us on Patreon button. And what's your favorite salad? What is your favorite salad, Jameson? What is my favorite salad? I don't know. I like a good old Caesar salad. Actually, there is a restaurant called Super Chicks by my house that's like slightly upscale Chick-fil-A.

And they have a buffalo chicken salad that is tasty. All right. That's probably my favorite. is it healthy like a salad no there's a bunch of fried chicken on it now but it still qualifies they didn't ask what's my favorite healthy salad what that person said yeah if you want to join go to softskills.audio click support us on patreon you will get an invite to our slack team you'll get the eternal fame that comes with us saying some words that you wrote into this list and our also our eternal gratitude which is worth more than any other

reward but that's like a long-term play you can't yeah exchange that for goods and services the area under the curve of our gratitude over a time period stretching from now to infinity is pretty big it's like it's like at least at least 10 gratitude units yeah and you can have them all dave do you want to read our first question yes this comes from an anonymous listener who says thank you for hosting this show this show has given me a lot of insight on new on nuisances of engineering i thought it said nuances and i think it's interesting that the difference between nuance and nuisance very few letters okay very nuanced yeah it's a you might say it's nuanced a lot of insight on nuances of engineering that are sorry i did it again

the the question says nuisances of engineering that isn't mentioned anywhere having some experience in the industry for a while i always find in this position where i want some autonomy but i am bounded by the deadline what do you think should be the way to start a career that gives autonomy while having that sweet benefits from the industry hmm what so what i interpreted this to mean is you it's a great job in a lot of ways you get paid well you do interesting work these pesky deadlines how do i get all of the good stuff without deadlines and work on something no one cares about is the easiest answer and in like 2019 when interest rates were low and money was high people were willing to take big bets for not a ton of certainty of a payoff

yeah i i think this i feel like i have felt this feeling myself and see it in others a lot that we could do some really good work if only we just didn't have these deadlines yes and i don't think that's a realistic i don't think that's true that's exactly what i was gonna say i was gonna push back on the idea that somehow deadlines are the problem here you can do deadlines wrong and you can have you can make poor decisions in light of deadlines but it's a pretty common trope that constraints help you make cooler things and better decisions than if you just have this totally free form blank check infinite canvas. Yeah.

And time is a constraint. It's also a constraint that forces you. It's not just a, you only have a certain number of keystrokes. So like work with that, but it's, it's a constraint that pushes you towards delivery to not, not just a resource constraint, but a thing that makes it more likely that you will get the thing done. So I think it can be valuable. There's a little bit of bias we have baked into our thoughts on this, I think, that's kind of leaking through. And I'll just state it out loud, which is that I think, Jameson, you and I both have this underlying assumption that actually delivering something valuable is the objective here, or is the objective, period.

Of course, if you give yourself full autonomy, some people just feel great just tinkering. Like, I'm here to just learn. I just want to see how computers do computering. And if that's your objective, then deadlines are the enemy. Well, maybe. Maybe they're not. I don't know. I got to bring this up.

But there is a current hot button issue circulating on the internets right now because there was an interview done by some guy whose name I don't remember, but who has started just a crazy amount of startups, all self-funded, all self-executed. And I think maybe doesn't even hire anyone and is making just like kind of obscene amounts of money. And I probably, you know what? I won't even mention the name of the guy. Not the least of which reason is because I don't remember. I know what you're talking about. Yes. You've seen this going around. Anyway. Yeah.

One of the constraints this person put on himself was that I will start a new startup every month for a year. I think it was every month. Am I remembering that right? Oh, I don't know that part. Anyway, I listened to like two thirds of the interview before it started to get hot on the internet because it's on a channel that I just listened to anyway. But he put that constraint on himself and he said, I will deliver a new valuable product

every month for a year. And that constraint was enormously beneficial to him because it forced him, like it brought clarity to a lot of decisions that he would otherwise have made differently you know things like how much engineering complexity will i bring in well none i can't afford any like i can't afford dependencies really i can only afford like carefully selected software dependencies i can't afford to ramp up on a whole new framework every time because you know i just don't have time for that like it might take me a month to ramp up and i i need to deliver something in the first week so i can iterate and get something going and i believe i could be making this up but i believe he ended

up creating levels.fyi is that is that the guy yep yeah which has been a really cool thing yeah i think it was famously just like a spreadsheet for a long time i don't know if it still is yeah no it's not it's like a proper website i think it has a subscription on it now and everything looks like it even has a mobile app okay which is crazy well now i can read my spreadsheet on my phone yeah perfect anyways yeah that so i think the the point is um this person gave themselves deadlines yeah they i mean they're probably bounded by how much money they need to live but they still imposed arbitrary deadlines as a way to help them get stuff done yeah so i think it starts with your objective if your objective is to just learn i you know you might

think, well, I don't need a deadline, but I would, I would posit that deadlines can even help you there where you say, look, I'm going to learn a new programming language every week for this year, you know, and that, that deadline, that constraint you place on yourself very much influences what you will and won't be able to do. For example, you'll never be able to spend more than a week on a single language. Um, but boy, does it broaden the exposure that you'll get, you know, 52 languages in one year would be an amazing outcome. And then maybe next year you pivot and just focus on one or something like that. But my general experience has been that unconstrained autonomy does not really yield a lot of benefit, even if what you're going for is kind of this like

tinkering, learning, you know, just playing. Yeah. I think there are some rare individuals who you can just turn loose on whatever and they'll make awesome stuff. But most people are not like that and especially if you are a business you're not willing to extend infinite trust to just say work on whatever you want for as long as you want and we trust that it will be worth it to us so there are hard external constraints we're also i mean we're coming down pretty hard on deadlines are actually good you can certainly do them poorly and you can have fake deadlines or uh a death march of it's always two weeks late and you push the deadline back two weeks and then it's two weeks more late. And you're just always in this rush where you feel

like you do not have time to breathe or make reasonable decisions. So I think I'm assuming that the deadlines are infrequent enough and supported by real needs enough that you're not just being harassed all the time and you feel like you... There's this feeling I've gotten into sometimes where I feel very time pressured, where I don't have time to think. I just have to put my head down and go as fast as I can. And it turns out that usually I will end up doing stuff that is worse and takes longer than if I felt like I had an hour to sit and talk to somebody about the thing. I don't have time to talk for an hour. I have 15 hours of coding to do, and then an hour would save me a week of coding. So we're assuming it is a good deadline, which is a pretty important

assumption to clarify but I think assuming it is good in that it is reasonable it's clearly communicated it's real it's not it's I think real deadlines are typically a couple times a year in the businesses I've been around unless you're a very event-based business I mean like I don't know real world like concerts or something like that that happen on a specific date yeah anyways assuming that i think i agree with you that that the absence of deadlines opens you up to a bunch of pitfalls around analysis paralysis and gold plating things that don't matter and deadlines can give clarity and they help you cut through stuff because it answers a lot of questions for you we can't write our own database we have a deadline okay yeah cool don't do that but what

if i wanted to write a database like what if my goal is to learn how to write a database and i think you know it's interesting just to pivot a little bit to answer a slightly different version of this question which is how do i find joy and satisfaction in software engineering when all i have is my quote real job which dominates all of my software engineering energy and i have nothing left to do stuff for fun and that's a little bit of a different question it might be what's actually being asked here yeah yeah like i i find this work soul-crushing to just crank out widgets or whatever yeah like like i want to go explore this thing and i just can't because it's you know and you know i've i'll tell you i have definitely seen a decline in my ability to do that as i have

aged most mostly because of well it's not because of any less energy or desire on my part it's mostly because of non-work priorities have become bigger as i have gotten older you know whereas i remember when in my first job out of college here i am working full-time i'd wake up at about six in the morning, kind of a normal wake-up time, I guess. And I'd go down to the basement in my house and I would just code for like an hour on a side project that I had. I had a couple things going that were really fun. And I loved it. I got exposed to new technologies, some new methodologies. I had open source. This was before GitHub, but it was on sourceforge.net. We didn't have stars, but we had download counts. And anyway, it was great. I found a niche of

users who loved my product in australia which is super random but they had me they had there was a reason for that maybe one day i'll tell that story but and uh it was super fun and then just slowly but surely the days each week when i was available to do that because of other commitments just started whittling away almost imperceptibly and one day i woke up and i'm like i don't have any side projects that was probably about 10 years into my career when i just didn't have any anymore and it'll happen to you someday i've come to believe very strongly that you need both deadlines to help express business constraints and you need slack time at work and i don't mean saying we have 20 time which you can use however you want which usually just goes away because

but there's all this stuff to do so you know what you're going to not do the important stuff to go like build your own email client or whatever by slack time i mean uh you need you need to have the team not fully utilized all of the time on planned work you need to have space for someone to say i think this is important and then to be able to say okay go explore that for a few days and come back with what you've learned and we can use it to influence what we build next you don't have to always work in this mode but i think teams do better if they alternate between these very focused periods of here's what we're building we just have to get it done we need to answer these questions as quickly as we can and deliver it to users as quickly as we can in a way that will not

make us hate ourselves later and like some some time to step back and survey the field and maybe that means we need to change how we're doing testing or queries or i don't know more more broad kind of engineering investment focused things. And often that work can be the kind of satisfying, exploring, stretching work that, that you also get inside projects because it's typically, it's not like add a button to the app here. It's, it's more leveraged, I guess. So just give that speech to your manager and then that's how you'll work. I think. Perfect. Just the manager will just completely change everything they believed, all of their policies all their preconceived notions if your speech it helps if you have a really big mistake

you can point to by having just put your head down and and tried to crank through stuff for a long time it makes it easier to say hey maybe we shouldn't do this anymore so make some mistakes i guess i don't know hmm well have we answered the question yeah but i don't really know what we said something like something how do you get freedom from deadlines just don't do that don't do that deadlines are good okay and how do you have fun while software engineering i don't know keep trying but eventually it will be taken from you like all the other joy in your life your capacity to build cool stuff will increase as your time that you can allocate to it decreases

So hopefully it kind of bounces out. There's some kind of law about conservation of side project or something. I don't know. Yeah, yeah, yeah. I think we've answered it, although I could not tell you what the answer was. But that's not our job. Our job is to answer the question, not then understand the answer that we gave. And we've done that job marvelously.

Dave, can I read our next question? I was hoping you would. This is from an anonymous listener who says, I used to be a senior manager of an operations team for a firefighting service in Australia. I managed all of our physical operational assets. For example, radio towers, mobile communication, e.g. 5G, 4G technologies, mobile data terminals

like laptops in firefighting appliances. And then they put firetrucks in quotes. So I guess a firetruck is what you call it if you're like a layperson. It's a firefighting appliance. Roll up. Yeah, roll up to the fire station and say, nice looking firefighting appliance you got there.

Anyways, data centers, networking, and so on. A restructuring means my team has grown to include in-house software development. While I'm excited for this opportunity and on board with the changes, it is a very big shift from the physical and electrical engineering side of software development. The C-level staff thinks that the team lacks focus

and that there are problems to address. I assume that means about the in-house software development team. I've been meeting the new team and working through the changes. They are very nervous and are skeptical about how I'll understand their world, which is fair. How can I best support this team? What are cultural things I should be aware of? What are key metrics I can measure that will fairly represent their hard work to the executive team?

Any thoughts on what things a manager or managers can do to be supportive as the new drop-in from across the room from an entirely different engineering discipline? Coding in my world is scripting and hacking about to make things work as a telecommunication engineer. Good news. that is also coding in software development. Hacking about until things work. Yeah, that sounds about right. Can you imagine if mechanical engineers did what we do? Well, the car blew up again, but let's just try again.

Yeah, let me rebuild a car with a small tweak to one of its parts and see if this one blows up. Having just spent the weekend doing painful and risky data migrations. Sometimes that's what we do in software also. Huh, migration failed there. I hope the data's all good still.

And then let's tweak it and rerun it. The data was all good still. It worked out in the end, but boy, was it stressful. How can I best support this? Well, first kudos to you for being aware that this is a thing that requires work. I think sometimes engineers across lots of disciplines can get a little high on their own supply and think because they understand a complicated field, surely every other field is

easy and they can just... They learn the hard stuff, which is conveniently the thing they specialized in. Yeah, what a coincidence. And then they can just hop in and be an expert or tell these jokers what to do in their own very specialized discipline yeah that's not happening here which is nice yeah yeah it's nice that you're aware that oh this is like a deep discipline that requires specialized skills and knowledge that i do not have and so you're already avoiding one pitfall which is just like roll up and say well you treat this code like you do a radio tower and then you say stuff to them about radio towers yeah then they go back to their desks and are like oh man yeah why things

that i don't know because i don't know nothing about radio towers yeah there's some gigahertz involved i think yeah sometimes they look like really crappy trees i assume that's important for functional reasons yes well i i think this person has been dropped into a very challenging situation you've got a team that has lost the confidence of the c-level staff and you've got a manager who doesn't have expertise to be able to firsthand assess the work of this team and so that's going to be hard i don't know how else i don't know how to sugarcoat this but you're going to get in there and you at best at least at the beginning all you're going to be able to do to say to the c-level staff that's

the word they used is repeating things that the team tells you because you don't you don't have the background to synthesize or evaluate what they're saying you know and so that's that's tough yeah yeah if if that's a really good point i didn't think about it that way if the c-level team is very concerned about your 5g technologies you know enough to go dig in and say your concerns are wrong because of this thing that i learned but yeah you probably don't know enough to evaluate if their concerns are correct or not. They think the team goes really slow. How fast is good enough?

Like what does not really slow mean for a software team? Yeah. I don't know. Oh, actually, I really don't know in real life because that's a very hard question to answer. I just imagine what would happen if you took me, so I lead a team of software engineers. And if you said, okay, Dave,

your organization is now going to expand to include some engineers and operations people who manage radio towers, mobile communications, and data terminals and firefighting appliances, I would say, and they're like, oh, and we think this team has some problems, so go figure it out. I'd be like, oh, man, I don't know. I don't even know the first question to ask. Like, do you have enough gigahertz? Could I bring you some more gigahertz? Hoses, I think. How are your hoses? I'm sure they don't call them hoses. They probably have some technical. Oh, yeah. They're like, who is this guy? Yeah. What's this joker?

That is rough. And it's crazy because I hear about CEOs who step in from one into a new industry from another. And sometimes they're wildly successful. They go from tacos to coffee or something. And it's like, wow, how did you figure out the ins and outs? And I think it's because a lot of the concepts translate. It's like, oh, this is a supply chain. I know how to manage a supply chain. Or, oh, this is an incentive program. I know how to manage an incentive program. They both go in your mouth. Got it. You can start there. Common ground. But I'm very impressed with CEOs who can jump from one industry to another and be successful in a new vertical. However, I got to say, those are pretty rare. And the more common

story is that CEOs jump from one industry to another. And what do they do? They apply all the same strategies that work across all industries, specifically financial engineering. Sorry. Cost-cutting, short-term cost-cutting. Oh, man. I mean, it's like crap like stock buybacks and other things. It's like, oh, I don't know anything about cars, airplanes, or coffee, which happens to be my company here, but I do know how to start a stock buyback program. And so that's what they do. And I know that's a little bit of a jaded thing to say, even though it's true. But I think about that in-

How dare you besmirch the good name of CEOs everywhere, Dave? You know, I've had it. I'm standing up for the CEOs. Had it with this. Yeah, attack on a vulnerable group. The underdog. Yeah. If you don't stand up for them-

We'll speak for the CEOs. I showed her to think what would happen if you didn't take a stand on their behalf yeah anyway oh boy but I so now you know translating that story to what's going on here you know you've got all this extensive operations experience with radio towers mobile communications and lots of gigahertz and you're dropped into this team that does software engineering and it's like it would be tempting to try to apply the concepts here that frankly just might not work. I mean, I've seen people try to apply hardware concepts to a software team, and the results are kind of disastrous. Like I worked for a company that at its heart was a hardware company

that sold, actually, coincidentally, it was radio equipment. And they sold these boxes to customers, big, big companies. And I was on the software team. So we wrote software that ran on these boxes. And the processes that we followed were just so hardware centric. They were like, okay we're gonna do a first article test on your software and i'm like what's a first article test they're like oh that's the first unit that rolls off the assembly line we test it to make sure that it works and i'm like huh what's an assembly line we don't we don't have that you know we don't have like costs associated with reworking the assembly line when you find that a there's a software bug we can just make new software we don't have to retool the whole assembly line yeah you know and

And so they were just totally oriented around this hardware production process. And so, I don't know. I mean, I just think you're set up to fail. I mean, I don't know how you manage a team like this without bringing in someone else to help. I mean, yeah, we talked about it earlier, but a dose of humility works or is helpful. But you also need to then... You can't just say, well, I'll never...

I don't know anything about it and I never will. So I'm doomed. Or tell me what to do, team. You do have to put some effort into understanding the high-level view of a software team. I do have a suggestion for you. You talked about metrics, and this is a famously hard problem to solve in software because it's so squishy and human and subject to incentives from metrics. But there is a book called Accelerate, which has been out, I don't know, a while now, maybe a decade. that analyzed a bunch of different survey responses

about software teams and came up with a set of four key metrics. They've kind of permeated the industry now. So they're a little bit, you can like read white papers about all these products and how they'll help you with these metrics. But there's still a decent place to start. And now I have to name them off the top of my head

and I'm going to get them wrong. There's like frequency of deploy is kind of the big one. How often are you shipping stuff? And generally teams that are more successful ship stuff more often change failure rate was one of them how often do the things that you ship break uh time to recovery i think is one of them yeah mean meantime to restore yeah i'm cheating by looking at the website one oh shoot i forgot the fourth one well you said important i've declared it not important well you said uh you said deployment frequency and the other one is

lead time to changes which is mean which i call oh yeah i actually call that cycle time i don't know if that's a different let's see oh no cycle time is different let's see but it's it's sort of like how long does it take you to decide to do a thing and then get it out there yeah yeah exactly because and that's a great that's a great proxy for measuring your how crappy your processes are it's like oh well if we have an idea today but it can't be in the hands of users for six months that tells you something about your processes yeah that's great i think this is a great place to start, Jameson. I think these are great metrics to consider. You also don't want to over index on them and say, well, these are the only things I know about software. So we will kill anyone that

increases our mean time to restore. Well, that was going to be my comment is don't don't pick a metric and obsess over it and force it. Because it turns out these metrics are they're actually kind of SAS biased. I don't know if if you've if you think that's true. But it's like, yeah, if you're building hardware, or you're making like a mobile phone app, you know, you might have very different metrics that matter for you and so that's my if you're shipping like embedded software that has to ship with the physical devices right and it has no over-the-air updating and stuff like that it's like a very different situation than oh we can just we can just roll back that change after a few minutes if it turns out to be bad um but yeah like i love i love these four metrics i

use some of these every day in my own management but i never obsess over them and i never you know when i see one of these metrics move in a bad direction i'm always looking for the story that it's trying to tell me, rather than saying, okay, you're all on notice until this metric improves. Yeah, get that number up. Yeah, I never say get that number up. I always say, why did it go down? Yeah, that's the, that's, is it Goodhart's law? If a measure becomes a target, it ceases to become an effective measure. That's right.

And often there is a good reason why the metric went in the opposite, quote, the opposite direction, because there's important stuff that pushed it. And if you just, the incentives get weird, if you say number go up no matter what right do you think i mean good news you are coming from a technical background it's not like you're coming from something non-technical so you're starting you're not starting from zero and you mentioned hacking about to make things work like you understand code maybe you don't understand kind of enterprise software development and that's different from telecom scripting whatever whatever that looks like uh i don't know but you're not starting from scratch. But you do have to pretty quickly understand why the C-level

thinks the team is not in a good spot and understand, develop an opinion. Do you think the team is in a good spot? Is this a communication problem where they're actually doing the right things, but it's not making it back to the team or the expectations are on? Or is it true? Are they actually not doing what they're supposed to? Yeah. And I'll tell you what, I would absolutely sit down with the C-level people who have a negative opinion of your team. And I would say, hey, look, I'm a new leader over this team. I have nothing invested in this team. My ego is not on the line. I'm open to anything you want to say. Tell me what you think, good, bad, whatever, let me know. And most C-level people tend to be a little bit more open in sharing their criticisms.

And you might get some great information. And I would take that information to heart. believe, you know, you don't, you want to believe it because it definitely is a belief that they hold, but you also want to then validate whether it's correct. And then I would talk to the team and you know, I probably would not directly share what the C-level staff said. Instead, I would sit down with each team member and I would ask them what's working great on this team and what's not working. This, look, I'm a new leader for you. So we have a blank canvas. We could change things. We could do things differently, or we could keep doing things the same. What do you think should be different here? And in my own experience, I actually had an

opportunity to do this just recently. Most people do not have strong opinions on how the team should operate. And I've observed that over the last 10 years, leading multiple teams, because most people are interested in pleasing you and not making waves. Like, hey, my job's on the line. I'm not going to say something that's going to get me fired. And so my experience has been, you will get occasional gems when you ask this question, but 80% of the time you will get nothing. And so there's a couple of reasons for that. One is that you haven't earned these people's trust yet. So when you ask them, what's not working, they're not going to say, well, I'm going to sue you. I have a boss who doesn't know anything about software.

That's one thing. That's what they'll think. But they also might think, I don't want to get fired. I don't know anything about you. I don't trust you yet. I don't know if I'm going to say something and you're going to misconstrue it and then get me in trouble or form a bad opinion. So I'm going to try to look as agreeable and positive as possible in our first interactions. That's what I've seen 80% of the time or more when you're a new team leader and you come

in. And so it's going to take weeks or months to build trust. And you should just explicitly tell people, listen, I'm not interested in firing anyone. I also don't think we should make any drastic changes right now. let's observe and let's just put our critical critical eyes on this together and you please feedback things to me that are not working and we will we will fix them and then you'll have to prove it because oh man sorry james i have a lot to say about this but you'll have to prove your trustworthiness by taking their because they're gonna they're gonna test you and give you little

things well the water cooler dispenses water really slowly you know like little things like that that are inconsequential to the business but they'll test you and see if you actually do things that help or if you just ignore them or if something bad happens to them when they raise problems and the more you can demonstrate that you are you respond positively the better off they'll be or sorry not the better off the more likely they will be to trust you with the big things i like that yeah yeah it can be tempting to say well that doesn't who cares like the email the signature the font in the email signature is is displeasing to you okay suck it up but it but it is a little test of like, are they going to, it can be a little test, I should say. Are they

going to care about my concerns? Yeah. They might not even know they're testing you on a conscious level, but they may be on a subconscious level. I'll also say, one of the challenges you find yourself in, in this situation is that you don't know whether to trust or mistrust the information that this team gives you. Like you might say, hey, our leadership wants to build this new thing. And your engineering team, your software engineers might come back to you and say, that's going to take two years to build. And you don't know if that's right. You don't know if that's like actually accurate or if the thing that, you know, they have beliefs that are wrong or they're thinking about the problem differently than you are or, you know, there's a lot of

reasons. Or they've been hurt before. So they're just giving a gigantic estimate because they don't want to get smushed. Yes. And I have seen this among engineers who I trust and trust me and whose opinions tend to be right. And I've asked them, how long will this take? And they're like off by 10x, you know? And I say, well, what assumption, you know, I try to explore like, what assumptions are you making? Or what part of the software, what part of the code base are you thinking about when we talk about this? That's something I can do because I have familiarity with the code and a background in software development. But someone who doesn't, man, it's just so hard to come in and reconcile that. So how do you overcome that? Well, you got to talk

to a lot of people and get a lot of positions. And you have to challenge them by, and when I say challenge. I mean, say, are you sure about that? Is there a way to do this differently? Or what assumptions are you making? Or what constraints have you applied when you think about this problem that I described? Anyway, over time, eventually, you'll get good at this. But it's going to be a long road because you just haven't done the job they're doing. But it is useful to ask that question even if you don't know the answer like if you get back at an estimate how could we do this i think part of what is implicit in what constraints are you are you assuming or what assumptions are you making when you give that is like say the deadline is the is the thing that is

immovable not the requirements how could we change what we do so that we can achieve we can we can hit the deadline because sometimes it is pretty common for engineers to assume well i'm gonna have to build this specific UX and that requires changing this other thing over here. And part of your role as a leader is to say, I can sweep away all those assumptions. I can get the requirements changed if we have to, to achieve it. Right. Exactly. Okay. Last thing I want to say about this is the question asker asked what metrics, and Jameson, you gave some great metrics that I think are good leading indicators of team performance. I also think you should have in your arsenal a set of outcome metrics, things that tend to be lagging indicators, but that

tell you if the software team is doing the job that they should be doing. And I can think of just two off the top of my head. One is how many bugs are being reported in your production environment and over certain units of time? Like how many bugs per month are being reported? And you can watch that. And then when your seed level staff says, I think this team has a quality problem. You can say, well, this chart suggests that bugs are going down. We've seen a month over month decrease by 10% for the last six months. And then the C-level staff can just be like, oh, great. So that's one bug rate. The other one is customer satisfaction. So at some point, you're serving someone with your software. And there are people who will either be happy or not

happy with the products that you're creating. And if you can query those people on a regular basis, and have some kind of number that you can say, well, you know, 65% of the people we asked this month said they were happy with the software and 35% said they weren't. And last month, that was only 60%. So we've moved the needle by five percentage points. These are the kind of things you need to be able to say to tell if the team is doing good. And if those numbers look good, those outcome metrics, it kind of doesn't matter that much what else is going on in the team. It doesn't matter what your cycle time is, if you're meeting the objective of your product. It doesn't matter what your mean time to resolution is if everyone's happy with the product, right?

So I kind of like those outcome metrics, even though they're lagging. And they certainly tell a much more potent story than, look, I talked to the team and they said everything's going great. One thing that just occurred to me is that it's possible that, I mean, we mentioned SaaS earlier, safety critical systems like firefighting stuff is probably a little bit different from SaaS. I have not worked on them, but I assume that the trade-off is much more on stability and uptime and safety over iteration speed. So I think, Dave, you and I both come from a more, I keep wanting to say sassy, and it sounds so dumb.

Sassy! Stupid pun or something, and I'm not. But we do. I think we are coming from a more, I don't know, B2B, not safety critical or B2C kind of, where like customer value and financial things come over, this must never go down or break. Yeah. Neither of us have worked at NASA. Yeah. Neither of us have worked on firefighting appliances, unless you count my laptop, which is what I call it when I'm trying to deal with a prod issue. Oh, I see. It's my firefighting appliance. Nice. I don't. What is my point? My point is, there could be a bunch of different lenses here, either from the C-level staff or from the engineering team. Maybe the C-level staff is a bunch of wise and valued business MBA grads, who I will not speak ill of, but do not have a strong background in what it takes to make a button that you can always click no matter what or people die.

Yeah. Or maybe it's the opposite. Maybe the software team is full of a bunch of people from from the private sector who have been working on, you know, like social networks or something, which have certainly constraints and requirements, but are not safety critical. So it might be useful to figure that out and see what what is what assumptions are people making about what soft what good software development looks like based on their backgrounds. Sounds great. This is an interesting question. We've talked a long time about this. I think it'd be really fun to work in the firefighting industry. Because what better way to say, I'm fighting a fire right now, and the whole team is like, what? That could mean two things. Yeah. I told my wife, work is on fire this week. And it'd be interesting if it was like, yeah, literally, the firefighting appliance is doing stuff with whatever word you use instead it poses there's a fire there's a fire at work yeah that's awesome oh no did your co-worker

make it out alive yeah yeah this is this is so interesting i think no matter what you will learn a ton yeah you've been thrown into the fire honestly software engineers have like a crush on on physical systems like this a lot of there's always conference talks about like airline crashes and the follow-up investigation they do on incidents there. And this whole system of like, or this whole field of resilience engineering often comes from government and medical stuff. And it feels like firefighting lumps into there.

So maybe you do know everything. You get to roll in and say, here's the truth about all these metaphors you've been using. Okay, have we answered the question? I think so. I think this time we really did. I just can't think of anything else that we could possibly say to help

this firefighting gigahertz manager. And certainly we will not end this call and then think of all the stuff we should have said. Maybe in our earlier days, back in the hundreds, but we're up to the 400s now. Yes. We got it figured out. Okay, dialed in.

Thank you for listening. What can people do if they want their own questions answered? Go to softskills.audio and click the ask a question button. We have received so many questions from you that Jameson's heart has grown two sizes in the past two weeks alone. So thank you

for keeping those questions going. We love them. We do. Actually, both of these questions were from pretty deep in the backlog. So we pluck from all over. Keep them coming

and eventually we will get to your question just like eventually we got to these questions. All right. Thank you for listening. We will catch you next week.