Soft Skills Engineering - Episode 25: Understanding the Business and Managing Without Being a Developer

Episode Date: September 5, 2016

In episode 25, Jamison and Dave answer these question: How do I understand the business side better? Analysis of tabs vs spaces How does your business make money? Just ask your CEO/manager Kill the myth of the pointy-haired boss Smaller companies expose you to this more Just ask questions: What was our revenue last month? How much did we spend last month? Who are our biggest customers? How does the sales process work? The Dave Smith Method® for learning business jargon. Be kind and have empathy when you learn. Can I be a good technical manager without a technical background? Technical leadership vs management. Management means empathy and understanding. Can you get that without “coming up through the ranks”? What are the skills of a good manager? Does being a developer give you those skills? Dave is a Night Elf Code Mage. How do you handle technical concerns as a non-technical person? Don’t fake technical knowledge. Leading a team when you don’t directly see the effect of your actions. Managing Nerds by Rands. Jamison’s former boss’s technical expertise

It takes more than great code to be a great software engineer. Welcome to Soft Skills Engineering. I am your host, Jameson Dance. And I am your co-host, Dave Smith. Ooh, you're the co-pilot and I'm the pilot? Is that what that means? That's right. So you can say, you're plane, sometimes, and I'll take the yoke. Yeah, that means you get to land it, right? Crash landing. You're doing a great job. I think we have a story from a listener about getting fired.

Yes, we do. An anonymous listener wrote in with a great story. You know, these stories all have a certain element of tragedy, but I still say they're great because I think they're good for everyone to hear. It is kind of funny that we start out the pot. Maybe we should clarify if you're a first-time listener. We did an episode a while ago on getting fired and kind of how you deal with it. And we realized that I don't hear of getting fired very often.

It's like a shameful thing that people seem like they want to hide. so part of that uh one of the outcomes from that was we wanted to hear your stories and share them with people to kind of take away some of the stigma and show it happens to a lot of people it's kind of a part of life even if it is painful and and you can recover from it yeah absolutely and that's the best part and that's why we share yep so here's the story i'm gonna skim some parts and read some parts verbatim so this developer is from the dominican republic with four years of experience as a developer. And last year, a colleague of this developers recommended him to work at a company in the United States. So he began working remotely doing web development for

the company. It was awesome until a couple months in the lead support engineer left the company and his boss asked him, I'm just gonna start reading now my boss asked me to move to the support team temporarily right like famous last words right since i'm proficient in english most of the developers here come from countries and they have a very strong or some from non-us countries and they have a very strong accent i hated that job but i did the best i could i was behind my teammates in stats like tickets resolved and stuff and my boss asked me several times why i was behind i told him several times that i wasn't fast enough to work with customers i'm a software developer and I've never worked directly with customers before

and this is my first remote job and there's so many variables and they never moved me back to my original team. So just to summarize, two months in and this poor developer got moved off the development team and to temporarily cover a support position. So two months after that,

he says, my boss got me fired claiming they had financial problems and had to let me go. That shred me to pieces since I'm really conservative with jobs and I was doing my best to do a great job. Since I was a contractor,

they only had to pay me the hours billed that month that was almost two months ago and i only just started to get back on my feet thanks for reading so far if it make it makes it to the podcast i would love to be anonymous and that's from just kidding yes so so the story here is a developer basically got pushed into a job that wasn't really trained for and then did poorly and then got fired but it's like oh what a hard situation you know yeah that's that's another one where i don't really know what they could have done differently it just seems like seems like external forces conspired against them yeah and it and it's a i think it's a good reminder for people because sometimes businesses have weird needs right like it's like oh something

crazy just happened and we need you to stop writing code and start doing this other thing for a while but don't worry it's only temporary and i think as a if you're in that circumstance and you know that it's going to be something you really don't want to do uh you need to be very clear with your management about what the track is to get back to what you do want to do sure you know and i don't know how to do that exactly other than like making it very very clear that you're willing to take a hit but that you need a clear pathway back just quit and get a different job the go-to yep quit before they fire you well thank you for sharing that story yeah thank you um i will read the first question okay it's very short how can i gain a better understanding of

the business side there is no business side it's all code it's all code it lives or dies based on tabs versus spaces that is the business oh that's what they mean by the business side they uh there was a uh somebody did a an analysis of some github data and and space is one i'm sorry to say all you tab lovers i guess by one i mean are more common and by by what margin was it like a presidential election it depends on the language c was pretty evenly split but the rest were pretty heavily in favor of spaces but i guess you could say like walmart is more popular than like some fancy boutique store but that doesn't make it better and then you get all snooty about the superiority and the the just unwashed masses use spaces but the true sophisticated people use tabs

every boutique store i've been in uses tabs for sure it's so true so what the heck is the business side uh i assume that means like how your business makes money and and how it exists like all the other operations that aren't you sitting in your little cave writing code with mountain dew yeah yeah i i think this is a great question to ask we've talked a little bit on the show before about how we i think we both kind of had awakenings at some point where we realized hey without business people i would not have a job yeah and before that we kind of had this uh idea that we did the real work and everything else was just nonsense yeah the only the only reason they do business is because they can't write code yeah yeah they

couldn't hack it in our world uh which is so so dumb um so the fact that this person is asking this question i think reflects some maturity and it's cool so um i have a little story i'll tell please i had been in the engineering world for about two years and i got a new job and that company had a tradition of letting all the new people go to lunch with the ceo within a few weeks of their hire date and it was really cool so he went to lunch i sat down with him his name was gary uh he was an older gentleman approaching retirement but he had been running this company for the last, I don't know, 20 years or so. And he told the coolest stories.

Like I asked him, you know, what was it like in the early days? And he told me stories about how they had these shoestring budgets and they just like... Tell me of the old country, papa. And he talks about how they barely made payroll a bunch of times

and he had to go without pay so they could pay their people. And I'm like, that's so cool. And it gave me a lot of empathy for what he had done to build this business not really being an engineer himself but um building up the business so that engineers could have a great place to work and doing all this super hard stuff and it was awesome so i recommend that if people want to get in touch with how the business operates go all the way to the top if you can so go say hello to bill gates and go to lunch with

them if you work at microsoft oh no it's uh who is it now it's not balmer anymore and they have a new ceo satal or something i don't know yeah yeah i don't know i've lost track anyway go to lunch with that person and ask about the uh company ask about what they know you can you could maybe as an alternative it's a larger company you could find the person who's been around the longest and just ask if they'd go to lunch with you and tell cool stories satya nadela i know what he looks like i couldn't remember his name well you'll get you'll get to know him better when you go to lunch with them yeah that'll that'll help a lot i think uh this is kind of harping on the same point but i would i would kill the myth of the pointy-haired boss um that idea

that again the business people are some combination of an incompetent and like scarily competent at ruining your life which i don't know how those two things go together but uh yeah it starts with empathy um and and understanding that there's probably a reason they exist and they probably do something the business isn't in the in the habit of just like paying people to waste time so yeah you mentioned talking to the ceo of microsoft and that brings up a good point which is this is a lot easier to do at a smaller company i feel like most of my understanding of business stuff has has come from working at smaller startups where i know the ceo and i like sit next to him or I can tap him on the shoulder, or he's in the team or company meetings, he or she.

So just being in a smaller startup, it has a lot of trade-offs, but one of the good things is you're a lot more exposed to that kind of thing just because there are fewer layers insulating you from that part of the business. Yeah, and when the startup inevitably shuts down, you'll get very familiar with how the business works or failed to work. business side when you first hear we missed payroll and you'll be like that's a thing that you can do what uh yeah i i mean especially if you're in a small company it's so easy just ask just ask like what does this thing mean or you can ask what's our burn rate or i guess if you don't know what burn rate is you you don't know to ask that but um just in my experience people

on the business side are so happy when engineers take an interest in it, partially because they have bad experiences in the past from being discounted or ignored. But also, I think engineers that care about the business are incredibly valuable because it means that their work is more likely to affect the business side positively versus the ones that care purely about the technical things where um generally you need to kind of find a way to point them at something that that happens to help the business so that they can get excited about that totally so true plus one yeah i mean you you can just ask about numbers ask like how much money did we make um and and some people will tell you that and some will not but that's a valid question to

ask like how much did we spend last month how how much cash do we have like what do what are our investors? Who's on the board? I don't know. Just, just ask stuff. Yeah. And I've got a few questions too. Maybe I'll throw out my list here. Do it. So you run into a business person and after you recover from the shock, here's what you, here's what I would ask. How did you get into the business or how did you go into business? Why did you join this company? Where does most of our revenue come from? What are our biggest expenses? How does the sales process work? And you will be amazed at how much depth there is when some of these questions get asked that these people have it might just open a world you didn't even know existed um what do you mean by

oh yes dave are you gonna do our intro song next time i would love to love to hear that uh what do you mean by when you recover from the shock of running well you know because these two worlds aren't supposed to collide right it's like anti-matter and matter engineering and business i guess i don't know open office plans mean everything collides all the time that's true it's like a super collider yeah oh i hate open office oh we need to do an episode on uh seating yeah yeah we do i've got it'll just be a 30 minute rant but we should do it i've got some rants stored up yeah so one other point uh i want to ask you about is the jargon how do you i mean there's there's a lot of terms there's a lot of uh things you hear that you want to

understand, but there's a lot of unknown unknowns as well. How do you break through that? Yeah. And this goes both ways. And I'm sure business people will hear a lot of engineering jargon and think it's nonsense, but they actually have a lot of jargon too. So I like to, whenever I hear a piece of jargon, I write it down. I don't, I usually don't stop the meeting or stop the conversation. I'll write it down unless I need to know, you know, right away, but I'll just make a note. And then over time I'll accumulate enough to where I feel like, okay, I need to go ask somebody this and I'll actually go sit down with somebody and just say, Hey, tell me what all these terms mean. Um, some terms that I learned when I came to my current job about five years

ago were, uh, ARR, which I think is annual run, annual run rate or annualized run rate, TCV total contract value, annual recurring revenue. Oh yeah, that's right. Uh, MRR I think is monthly run monthly recurring revenue. See, clearly I don't do it. Tell me more about how you're an expert on this dave look the the big secret is this is actually a comedy show it's like the daily show excuse right we are a comedy show about the news we don't we're not a news show right right and they say that but they're totally a new show anyway so tcv total contract value you know just things like that and most of them will end up being acronyms and um i'll usually hit wikipedia to see if i can find them and if not then i'll go ask somebody and

sometimes they uh might be intimidated by you but a lot of times if you just say hey i'm just curious and i want to know that'll help give them context instead of being like i'm going to take your job yeah don't say i'm gonna write a program that does your job based on the information that you tell me uh it's a bad way to learn one other thing i thought of is um knowing this stuff is a great way to move into something more entrepreneurial a lot of it if you're just really passionate about a product idea you'll kind of be forced to learn in order to not die but if you can go into it knowing more about the business side it'll help you make better decisions and avoid a lot of mistakes too i mean people have figured out smart ways to do things just

like there are best practices for code there are probably best practices for all kinds of different business things. And if you can learn those, uh, ahead of time, it'll, it'll improve your chances of success, I believe. Yeah. Jameson, have you ever been, uh, like on a sales call? Yes. Yes, I have. Can you tell us about your experience? Uh, yeah, I, I've talked about it a little bit before. Um, but it was, it was fascinating. Uh, I mean, uh, before my interaction with, with customers was through product people. So someone had already done the hard work of looking at what we had, looking at what they wanted, coming up with some kind of diff, figuring out what's the important stuff out of the diff that they need. And then,

and then we start talking about features. Um, but it was just coming very raw from the customers. And, and it was a little overwhelming. Like you, you hear a lot about how, how horrible salespeople are because they promise features to try and close sales and then that drives engineering in it it does suck but it's so easy to do when there are humans on the phone that are excited and they ask like what about this thing and and there's just there's just an instinct to say like yeah we could we could do that two weeks how hard could it be and then they're so happy with you and they promise give you a ton of money um or alternatively you hear uh what they actually think of your product not not what the cheerleader that's trying to encourage your team says about your product

um and that's very eye-opening as well to hear um issues where they get really hung up or where it doesn't quite fit their needs that you might not even have heard of some of that is kind of will come out in user testing if that's ever a thing you do as well but but definitely sales calls are a way to see the truth of what customers think. Yeah, so true. And I went on a sales call once and we had built this software product for interviewing engineers for hiring. And I thought that it had all the features you needed. And I'm like, we're good to go. Now I'm just going to get on the sales call and I'll go with the salesperson and I'll tell the prospect how it works. And they'll be like, awesome. But what actually happened was they described their hiring process

and like the logistics of getting people in the door and like how they, um, make decisions and stuff. And I was like, Oh, there's so much more that we did not build for. And it was just, just like you said, Jameson, just super eyeopening. It was really cool. Yeah. It's, I mean, it's, it's a journey of discovery and I wish you luck on your journey. I think it'll make you grow as a human being. And I think people, I mean, yeah, people love it when you ask them stuff about themselves, right? They love people.

Everyone loves to talk about themselves. So it's really not that hard to say like, what do you do? Oh, that must be so hard. And that's all you say. And then they just talk forever about their job. Cool. Anything else you want to say about this? One last thing is that even after doing all these things and talking to people a lot,

you'll be amazed at how little you actually know about the business like it is it can be a very involved complicated field of study and um you know just like business people after talking to you for even a couple of hours won't really have a clue about how to write code or build a software product you too will also not have much of a clue about how to run a business even after spending several hours with these people yeah talking about this stuff so keep that in mind and be humble about it and you know recognize that there's a lot more to know than what you know Oh, for sure. I mean, there, there's a balance between, uh, giving a unique perspective and assuming that everyone is a moron and clearly hasn't seen this obvious thing that why don't

you just do this? And it turns out there's usually a good answer. Why? Um, but, but I don't know. Yeah. Have, have a small ego. Good life advice too. All right. Question answered. We did it. Do you want to read the next question, Dave? Sure. This one is from a listener named John. It says, can I be a good development team manager if I'm not a developer? John goes on to say, I've led product teams for years, but not specific things like growth, mentoring, code reviews, et cetera.

Would this just annoy the team if I was their manager? I think there are two parts to this. One is technical leadership, and the other one is managing the team. And I think your team absolutely needs technical leadership. There should be someone who is experienced to do code reviews and to help with broad technical issues. And if you can't do that, that's fine, but someone needs to. And we've talked about this before, but that can often be like a technical lead. but that doesn't necessarily have to be all wrapped up in the same person i guess as as uh

yeah the team manager okay true i think what i'm saying is yes and and here's why i think management is about empathy and if you can understand developers and what motivates them and what they want and how they're feeling then you can manage them and if you are a developer it's you kind of get that for free because you lived it yeah free empathy but you can still if there is such a thing as free empathy yeah i guess i mean i mean assuming you're you're you you care and you're good with people and and that's the thing that's important to you you you get that but you don't have to be a developer to get that so i don't have a lot of experience to draw on from this one because almost all of my managers have been former

engineers um and uh both the good ones and the bad ones so i know that as a former engineer it certainly doesn't guarantee that you'll be a good manager i mean that's good evidence that as a non engineer that's not a guarantee that you'll be a bad manager either right or is my logic all bad on that nope it's perfect perfect logic you've proved it you've solved the puzzle um qed all right i'm hanging up now i will this is a broad question and it's kind of putting you on the spot but what would you say are the skills of a good manager i think a good manager can recognize and fix problems on a team that include interpersonal dynamics organizational problems, process problems. Um, they know when people are giving their best and when they aren't

and they know how to help them. They know how to organize people in such a way that they'll optimally work well. You know what I mean? Like, uh, most productive, happiest they can be. They know how to defend the team from things that would harm the team, like distractions or, uh other things like that they they know what a bad culture looks like and they know how to like find bad incentives and shut those down and i think you know jameson as you know you asked me to list these things and i'm just kind of spewing what comes to my mind oh yeah it's totally put you on the spot and but as i'm listing yeah oh fake it till you make it but as i'm listing these things i'm thinking like why do you have to be a developer to do any of that

stuff yeah that's what i was thinking too i could see how being a developer would help with a couple of them but but i would say most developers don't know what makes them productive so if you're not a developer you're not that far behind on on the productivity part and process i mean uh yeah being a developer just gives you the power to complain about process but it doesn't magically make you know what a good one would look like so it's that's so true i i think in thinking about this, I could see how being a developer, I play video games, right? I'm confessing to the world. I play some RPG games and there's usually a part where you create a character and you assign some points and different strengths and weaknesses. And in my mind, a developer who

turns into a manager has some more points allocated to the technical stuff. So they might be better at recognizing when you are approaching a technical problem in the wrong way. I'm like a level 7 code mage manager. Yeah, exactly. Like a night elf code mage. Yeah, a night elf code mage. And so you have strong code powers.

But there are a whole bunch of other aspects to it. And someone who is not technical will have weaker code mage powers. But maybe they're like a berserker or something and they just get in and chop people in half. And so they do a real good job at management. They chop through bad process. Yeah, exactly. Maybe, I mean, if they come from being a product designer or something, they'll have a very

different perspective and different strengths and weaknesses, but they can still do a great job. I agree. So I think the real question of the day is, to what degree do you need to be technical in order to be an effective manager? Do you, for example, need to be able to review the code of the people who work for you? Absolutely not. I don't think so.

But you do need to be able to identify someone that you trust to do that. What about speaking the lingo? Like the team is having a debate about whether we should do multi-process or multi-threaded web transaction handling. And they're looking to you for a tiebreaker. What do you do? I mean, that sounds more like a tech lead role. Dude, you go multi-process, Jameson. Oh, shoot.

Oh, I knew this one. Dang it. Oh, man. How many more questions are there? Can I still get an A? So I think you do. You need to know like where your limits are and you need to know the lingo to a point.

But gosh, it can be really irritating when a manager steps in and they're like, oh, well, you clearly have to go multi-process. No, I think that comes from a good relationship with the team. And if the team knows, like, you will help them estimate well and kind of, like, manage their process well. But they know that you don't, you've never, like, you don't know what sockets are or something. So you can't, I don't know, you can't decide if they should use Node or Ruby or whatever.

I don't think everyone expects that of a manager, especially if you're clear about, like, hey, this is the team's job. Yeah, I agree. but i do think a manager needs to be able to identify when the team has adequately explored a question and be able to ask enough questions that the team can respond or to be able to identify that the team has made a good decision like for example node versus ruby right like if you can't explain to your manager why one is better then you probably haven't thought the problem all the way through and a good manager will be able to recognize that even though the manager may have no idea what node or ruby even are do you think that sounds like a reasonable

statement i i think it does um i i think especially in that case where the manager comes from a non technical background yeah um they they probably need to make sure they're not being the tiebreaker but they're just helping the team come to a decision um yeah that sounds right but but the larger point is you don't need the technical background but you should try and pick up as much as you can i think over time yeah especially around things like oh go ahead nope just saying i agree because i agree with everything you say oh say it more even though even though we already know that i just have to say it out loud sometimes yes it's for you well i'm just thinking about uh i think it can help you i mean estimation is one area where um more technical knowledge can be

better because if you're not very technical it's easy to be really surprised by by estimates because you you maybe look at things from a ui perspective and say like oh we just need to make that button flash purple three times when they click but you don't have the knowledge of like it's actually implemented with like a slideshow in the background or something and the slideshow program was lost decades ago and so you can't change it um so so trying to get more technical knowledge can maybe help identify when estimates are totally out of whack or can help you from saying like now like how many minutes will this take when it's something that will really take like days or weeks yeah yeah exactly i think but even then again like engineers don't know how to

estimate. They've just made a lot of bad technical estimates. So a good manager needs to know what questions to ask, even when they're not in their area of expertise. So let me give you an example of a not good manager when I was a tester a long time ago. And the story goes something like this. I'm testing this program. We have nightly builds that come out. And, you know, the previous day, my testing yielded like 10 bugs, you know, so the developers go to work on those bugs and they get fixes in and then the next day i come into work and i get the nightly build and i and i run my tests and i get my results and my manager comes to me and says how many bugs do we have today and i said i found one bug and my manager's like that's great news you know and didn't really ask

any follow-up questions and i was too young and stupid to really go any further with the manager but the point the problem was that one bug was actually that the program wouldn't even start and so it was like you didn't the manager didn't quite ask the right questions now granted i was kind of an idiot and i should have just said inconclusive results program won't start we'll have to try again tomorrow with a new nightly build right but but i just said one bug and the manager was like woohoo 90 bug reduction so don't be that manager like even if you don't know don't have technical skills um you've got to still be sharp and critical like you have to be a critical thinker even though you're in an area where there's jargon and stuff flying at you that

you just you don't know you know yeah i think maybe a way to summarize this is part of being a good manager is making the team feel like you have their back and if you can say like i i've been where you are i was i was in the trenches remember remember visual basic back in the day oh like kind of gets you an in and it might give you a jump start but it's not the only way to do it and if you can um show your team that you care about them and that you will act in their best interests um and and you're capable of helping them i think i think they'll trust you yeah i think you just said the key word which is trust you have to be able to build trust with them and sometimes that might mean saying out loud things like hey guys i don't have a technical

background or i haven't been a developer so help me with this and just basically putting your ego aside instead of having it be the elephant in the room that no one can talk about you know oh they can smell it we can totally smell it when somebody is is faking technical knowledge smells like elephant in here yeah yeah it's true that becomes really obvious that's not a game you can play so don't even try to play that you remember the t-rex scene in jurassic park that's what it's like where they can they can see movement oh that does not make any sense never mind so developers are t-rexes and if you make a sudden move you'll get eaten yeah be afraid no that's not what I mean hold still it's more like shake it's more like here's

what it's like you know how in all the sports movies there's some point where the new coach comes in and they're all skeptical and everybody's crossing their arms staring at them and then the coach somehow wins them over you that's what you have to do you have to be Denzel Washington in remember the titans just be the most charming human being that has ever lived and it'll be fine i agree and then they'll start calling you coach yep yeah just be denzel hey coach i need a code review here yeah so one of the things that i find really difficult about leading teams of software developers even as a technical person myself with plenty of years of experience under my belt

is that A, I don't have time to review everyone's code, first of all. And B, everything you do in software is indirect. And here's what I mean by this. As a developer, when you write code, you can't see the code running on the computer. All you can do is see the effect of the code having run on the computer. And as a manager, when you're looking at your team, you can't see how productive they're being. You can't, not directly. And you can't see how happy they are directly either there's not like a bar above everyone's head like a health bar that's like the happiness and productivity bar right and and so you have to learn how to observe things indirectly and that means trust because a lot of times it'll be up to the developers to tell you

when things are going badly and if you don't have that trust relationship then you know you might be missing out on a huge input into your own managerial information yeah so you've got to be the coach you got to be trustworthy and uh yep even even if you're a developer you still have to earn that yep they got to be able to knock on your door and say coach let's talk let's talk coach you know before we went into this answer i was actually in the camp of you really have to be a former developer to be a good manager but i think as we've talked through it i've realized that all the things that make a good manager good are basically orthogonal to being a good software developer yeah it's you see that in the promotion cycle too where someone who's an amazing

software developer just becomes promoted to a manager and they just can't do it at all yeah because it's not the same um and some people work it out because they're just really smart and that's what makes them a good developer and then they apply that smartness to being a manager but but some people just don't don't do it which is fine so in other words the street this is a two-way street of dysfunction yep you can't you can't go either way but you can like what i'm saying is uh i don't know what i'm saying that one really what no i so i i want to say two more things one is that even though we have said you do not need to be technical i would say the expectation and the industry and for most developers is you need to be technical so exactly that is so true i think

you will probably encounter some people we've kind of already said this but you'll probably encounter some people you need to win over or convince that might be a little skeptical because this is just the way it works that engineering managers come from engineering um yeah this really goes back to our last question too right it's like the business side yeah it's like well you know if you were really smart you'd be an engineer why are you a manager yeah it's a broken expectation but it is out there yeah so i mean i i even i know of people who um have excellent organizational and people skills and and are just really good at empathizing and they have tried to move into management some have been engineers but just haven't been engineers for

air quotes long enough right the the idea you have to kind of like pay your dues and it just didn't work out because of that kind of built-in cultural expectation uh so so that's the thing you have to fight against but i think you can do it um the last thing i would do it yeah you can totally do it don't be scared of that t-rex it's fine it's a friendly t-rex once you once you get to know it the last thing i would say is i'll point you towards a blog post by ranz i think we talked about him last time just famous famous blogger he blogs a lot about um engineering management actually but he has one called managing nerds which is uh it's kind of his worldview on how to understand developers and i don't know that it applies to all developers but it's definitely

an interesting read to see like here's here's a model you can use to understand what motivates team if you don't know anything about engineers or or how they work or what gets them excited start here i mean talk to people after that but but it's it's an interesting read written uh to someone who is smart but maybe not super technical in their background yeah now i get the impression that rance himself may be an a manager of engineers who has never been an engineer is that right i'm pretty sure he was an engineer i think okay yeah i think i googled him once okay see i've been reading rants for about i think about 10 years and uh he's been a manager that whole time so yeah whether he was an engineer in the past or not he's not one now really like not day to day

yeah that's another point that that some people move into management after a few years in engineering and like somehow that counts but they've been managing for way longer than than they ever wrote code yeah and you know how quickly skills go out of date in our industry oh yeah So what does that say? I mean, I think that's case in point that you can be a great manager without having up-to-date software skills. My former boss wrote a Visual Basic 3 book or something like that. And that was his like technical cred. That was Joel?

Yeah. We gave him. We had a good rapport about that. Did you give him a hard time about it? Oh, yeah. Yeah. We talked a lot about rewriting in VB3. using his book as a guide yeah just train up the team you'll you can already have the material

yeah and and then all our problems will be solved see and then there's an example of someone who's been able to create a fantastic engineering culture um although his skills are pretty much outdated since visual basic 3 he did write a single uh slack bot it was like three lines of coffee script or something like that credit restored yeah reputation restored yeah still got it all right anything else you want to say about this question no you can do it john give it a shot and uh we'd love to hear about your experience all right i think that wraps up our our episode for today how can people hear more from us dave go hit us up on our website soft skills.audio you can play past episodes there you can stream them or you can also subscribe

and if you're interested in sponsoring our show we would love to have your money you can call you can find out details about how to sponsor us so that we can take all your money I'm an engineer

can I learn sales skills that's gonna be in an alternate world this will show up in someone's like sales Q&A podcast in an alternate world where engineers want to go to sales hey do you have money we will take it it'll be great anyway if you want to get your name out there for literally ones of people who are listening

to this podcast no there are thousands we we can say thousands of people oh that makes me nervous thousands of people suddenly i have stage fright thank you for joining us for yet another week of amazing intellectual conversation and uh remember don't be a t-rex we'll see you next time see you later