Chuck Weindorf, a retired IT director and chief engineer with nearly 40 years’ experience in software engineering, joins host Jeff Doolittle for a conversation about the concepts in Chuck’s book, Leaders & Software Engineers. Through personal anecdotes and insights gleaned from his extensive career, Chuck underscores quality assurance’s critical role in building trust with users and fostering a proactive culture of defect resolution within development teams. He highlights how ethical considerations underpin trust and integrity within the software engineering profession. Chuck and Jeff examine the significance of thorough documentation and the vital role of effective communication in overcoming silos within organizations, and ensuring that projects meet their intended objectives while maintaining high standards of quality and reliability. They discuss how to cultivate a positive, innovative culture within engineering teams. Chuck shares strategies for addressing challenges and opportunities presented by change, advocating for adaptability and continuous learning as essential qualities for both new and experienced engineers navigating the evolving technological landscape. He offers advice for those transitioning into leadership roles, emphasizing the importance of developing soft skills and the ability to empathize with and inspire team members. Finally, the episode explores the potential impact of emerging technologies, such as low-code platforms and artificial intelligence.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes
- CharlesWeindorf.com
- Low code: aws.amazon.com/what-is/low-code
- Leaders & Software Engineers (Mudsox Publishing, 2021)
From IEEE Computer Society
- Rethinking Engineering Leadership
- The Leadership Lever
- Leadership education for engineering students
- Leadership Annoyances
- Innovating AI Leadership Education
- Leveraging leadership lessons from software process improvement efforts for architecture leadership & management
- Regulatory Focus, Transformational Leadership, and Job Satisfaction
From SE Radio
- Episode 574: Chad Michel on Software as an Engineering Discipline
- Episode 520: John Ousterhout on A Philosophy of Software Design
- Episode 447: Michael Perry on Immutable Architecture
- Episode 407: Juval Löwy on Righting Software
- Episode 396: Barry O’Reilly on Antifragile Architecture
- Episode 331: Kevin Goldsmith on Architecture and Organizational Design
Transcript
Transcript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number.
Jeff Doolittle 00:00:18 Welcome to Software Engineering Radio. I’m your host, Jeff Doolittle. I’m excited to invite Chuck Weindorf as our guest on the show today for a conversation about leaders and software engineers. Chuck is a retired IT director and chief engineer with nearly 40 years of experience in software engineering. He encourages software engineers to understand their responsibilities, see their value, adapt to change, and focus on future direction with stories and humor. He influences software engineers to excel in their craft. Chuck is the author of the book Leaders and Software Engineers , which is the topic for this episode. Chuck, welcome to the show.
Chuck Weindorf 00:00:56 Hi Jeff. It’s great to be here. I’ve been looking forward to this.
Jeff Doolittle 00:00:58 Me too. So tell us what encouraged you to write this book, Leaders and Software Engineers ?
Chuck Weindorf 00:01:04 Well, I was an amateur writer as part of my part-time fund. While I was making an earning as a software engineer, and I got a flare for being able to communicate to my peer engineers on the happenings and what was going on, when I stepped into leadership, it became a weekly article. So I would communicate with 200 and some engineers and 700 folks in IT through this email and the demands of it, keep adding to my mailing list. So the company was passed around quite a bit and the things that I like to focus on were the things that helped other folks understand engineers from the outside. So not only were we encouraging engineers to do their best work, it was also helping the organization understand how to work with engineers because personality types weíre somewhat rare and very unique in the business place.
Jeff Doolittle 00:01:52 Okay. So you had some experience basically writing the book or elements of the book, I imagine, just as a natural part of your career.
Chuck Weindorf 00:02:00 Yes, so it is a compilation. So itís over about three years of articles written within the company I was working with and encouraging engineers then became, once I was nearing retirement, I began to assemble those stories into a war(?).
Jeff Doolittle 00:02:13 How did you end up as a software leader?
Chuck Weindorf 00:02:15 My journey to a software leader came from the ground up. So it came right out of high school as a hobbyist, and I was making pong type games and the like with a home computer. Went down to a company and they just says, I make these programs. You guys do any of this down here. And the company was Erie Insurance and are my local town. And I said, yeah, we got big mainframes here. So I came up that channel where I was constantly learning new things and technologies, each new technology that came out, I was jumping into it, folks began to, let’s say, follow along with my career. So a group of folks who were like-minded began to do that to the point where I’d reached in my forties and they said, look, you really ought to be in formal leadership track.
Chuck Weindorf 00:02:55 Now let’s move you over into that role, but we want you to stay technical. So I had that wonderful experience of being able to learn new technologies, be an evangelist for them, and be able to encourage others to try them and really help the company move ahead. This company was very traditional and so took a little extra effort to get them to try new technology. So that was my leadership role, was maybe being the first penguin to jump in the water. And if I don’t get eaten by all the killer whales, then great. Other folks are jumping.
Jeff Doolittle 00:03:26 Great. And I’m sure we’ll get to that more in the show as we talk about the career trajectory of a lot of software engineers. Because I imagine some of our listeners have a similar experience of starting with a technical background and then eventually, they find themselves in a position of formal leadership, which can be challenging at times. So the book is organized around four major content areas, people, responsibilities, culture, and leadership. And I want to make sure we get a little bit of time on each of those topics. So let’s start from the very beginning. In the book you talk about the engineer personality. So give us a sense of why four, where these four came from, and then let’s talk about them a little bit and how they play out in the real world in your experience.
Chuck Weindorf 00:04:09 The four personalities more or less came just by experience. I kept coming across the same categories of individuals in the course of my career. And it didn’t matter if they were my age or they’re much younger, we seemed to fit in four categories that are, they’re a little non-traditional, I’d say. I categorize them in ways that of their behavior. So the first personality was the Genius category, and in IT, the folks that go into IT can have some very high IQs. And with that comes an internal thought that I must be right, you know, I’m the smarter guy in the room, therefore I’m probably the one saying the right things and my ideas are probably the right ones. So there is with each of these personality types, there is a technique I need to help improve their performance. So geniuses, high IQ is their thing.
Chuck Weindorf 00:04:59 The All Stars, are those folks who are more natural to the technologies and can do the most difficult work and they tend to gravitate to difficult work. And the challenges for them might be to how do I get that knowledge out of their heads and into other talented people’s heads because they’re so focused on getting the worst things fixed and the best things done sometimes how do they help interact with the team and bring others along. The Introvert categories, another one, these folks have that ability to concentrate at a super deep level. So they can go down to the minute parts of the code and do fantastic things. And they may have some of the best ideas of our entire group. So how do we work with folks who are introverted and quiet the room down? So an introvert might be able to say their idea so that everyone can hear it.
Chuck Weindorf 00:05:49 This is like the backbone of the lines of code, if I’m going to say about millions of lines of code I’ve seen in my career. That group really produces a lot of work. And then finally, this is a bit of a wild card group. I call it Uncommon Sense. Anytime communicating with engineers I find that they just hear things different than the average person and they answer things maybe in a very literal way or in an unconventional way. And so I have to be specific in my communication with folks who are listening with their uncommon sense filter. And probably some of the most entertaining stories come from that.
Jeff Doolittle 00:06:26 Well, speaking of stories, can you give us some examples of how each of those personalities has maybe played out in some real-world scenarios that you’ve experienced?
Chuck Weindorf 00:06:36 Sure. I can give you a brief one for each of those. The Genius category, there was an old timer who was about my age and always excellent thinking, but always had, Iím always right is also the challenge. So how do I convince this individual to do something? I grab a marker and we had just put those walls sized wallpaper on the wallpaper you could write on with markers. Well, this guy didn’t know that we had put those things up there. I grabbed this marker and start writing on what looks like a white wall. And he’s just jumping up, hey genius, you’re writing on the wall, you know? And it just never occurred to him that somebody might actually, you know, have other reasons to do things. And so we always started off with, hey, I’m always right and I’m going to call people out on it.
Chuck Weindorf 00:07:19 And it was just, okay, slow down a little. Let’s go through the steps of it and then let’s then dig into your thinking so I can understand how deep you’ve gone into it as well. So this individual, that’s really all it took is like, okay, now calm down. We’re going to go through the steps. So that was always a good trigger for that conversation. For the All-Star category, these people are so talented and can do some of the most difficult tasks. The trick for them is to help them understand the interns. The other software engineers are just coming into a technology. You’ve really got to bring them along. And I almost think you have to trick them into doing it in some, hey, we’re going to have a pizza party. You’re going to present to us how you’ve done this really difficult piece of code.
Chuck Weindorf 00:08:02 So give them a spotlight to showcase their talents. And then it made them easier to begin to share. So I would be able to draw out from them all this talent if I just gave them the forum and then they can get the adoration of the less experienced folks saying, well that’s really great. For our Introverts category, the thing I really need to do is to slow the conversations down for them. So, there was one individual who may have even been on the autistic spectrum and he was so brilliant. It was kind of beyond understanding sometimes what he was thinking. And he would make a statement, well I think we should do this, this really unconventional thing. And they’re like, okay, now we’re all going to stop. And we’re quiet the whole room down and says, can you tell us in small words what exactly brings you to that?
Chuck Weindorf 00:08:48 And kind of making it a safe space. Let’s say that I’m going to hold folks responsible for staying quiet. We had a talking stick. If I hold a talking stick, you got to let me talk. And the one thing I would do with this particular introvert is you hold that, and no one will interrupt you. And then he was comfortable sharing the detail of the idea. Two thirds of the time, we ended up with something highly valuable from that process. And finally Uncommon Sense, we would have folks come in and somebody coming in from overseas who had that uncommon sense filter, I told him I got in on the ground floor of engineering and for two years he thought I worked on the first floor of the building when I joined the company. I said no, no, it’s the ground floor.
Chuck Weindorf 00:09:30 Another person, I said, hey, look at the color of that house. That’s a really unusual color. And he says, yeah, this side of the house looks like it’s colored orange or something. And I says, why’d you say this side of the house? Well, I don’t know what the other side of the house is painted. Right. Well it’s, isn’t it the same? Well I couldn’t assume that because the Uncommon Sense filter said maybe that’s not what it is. And so I had to be somewhat specific in make sure my sentence had a subject and a verb and a predicate that all worked together. And it was very clear because the filters of the Uncommon Sense might change what they’re hearing.
Jeff Doolittle 00:10:05 Have you found ways to help those different types of personalities overcome some of those challenges in communicating? Have you been able to help them to also find ways to interact together in more effective ways?
Chuck Weindorf 00:10:21 Absolutely. The advent of Agile and Scrum and all these other types of more collaborative team efforts has helped a lot. So on occasion, I can give that All-Star, hey, you’re going to do some very formative work. You’re going to go to this level, but you’re going to coach another to do a complex task and that seemed to be a good match. Or I’m going to assign the Genius some of the technical documentation responsibilities. Okay, well I know you know it and I know you’ve got this great depth for it, but you need to get it into words that can help you as a technical writer. You’re going to explain your world to them. It comes down to what youíre really good at and having them understand what they have in their skills and talents. And then what can you share to others and vice versa.
Chuck Weindorf 00:11:09 What sort of things can you gain from these others? In the introvert category, we had an individual who could do insurance rating down to the 2000th field of detail and know how it worked. Well, we really didn’t even have folks in our user community understand all of what their rating formulas did in some cases. And so giving them the ability to say, hey, here’s the important factors in rating, might be a very great conversation to listen to them. And so I think it comes down to having that really open conversation around a table. Agile’s great for that. Having the daily standup where we can get, hey, what did you really do yesterday that was awesome and exciting? Okay, well then that began to share with others what some ideas for their own work they might be able to employ. So that, I’ve really liked the Agile model to help teams with.
Jeff Doolittle 00:12:00 So what do you say if somebody says that these four types are maybe a bit simplistic or reductionistic?
Chuck Weindorf 00:12:06 Well, it certainly is. I’d like to say I’m in the Genius category. I even ask my son about that because he is an engineer also. Like, nah, you didn’t make that. But he does say you’ve got that weird, uncommon sense filter sometimes people have to tell you something twice. Did I do some all-star work? Sure I did. And did I tell somebody to go away because I wanted to work five hours straight on a problem as an introvert? Sure I did. So yes, the categories are really flexible. They’re just to call out maybe some of the pitfalls we have as engineers in our personalities and maybe we have an element of each. In a way it’s just to get people thinking about, hey, I’m a bit like that. I do those things too. Maybe I can try some of these techniques that will improve me in my job and our team also.
Jeff Doolittle 00:12:48 Yeah, and I appreciate that technique focus and like I said before the show, you know, the old adage, all models are wrong, but some are useful. So that’s what really matters at the end of the day. Well, great. So as you’re talking about people, you mentioned a few things that you might do with those different personality types as far as helping them with particular responsibilities to help maximize their strengths and maybe mitigate some of their challenges that come along with that personality type. So let’s shift gears and talk about responsibilities, which is the next major section in the book. And the first responsibility that you mentioned, the title of the section is Quality is THE Goal where THE is, is all caps. So let’s talk about why quality is THE goal as it pertains to software leadership and responsibilities.
Chuck Weindorf 00:13:34 This might be my hardest one lesson over the lifetime of providing software. The mistakes in software are magnified by maybe 10,000 users. A hundred thousand users can see how dumb we can be sometimes. And that really is a bad day. We can build a system with 300,000 lines of good code. However, the trust in us is going to erode if we make one significant mistake. And folks understand new software does some strange things, but really we’ll lose their trust quickly if this continues. So quality is really the only thing I can hang my hat on to say I’m a programming success as far as software development. That if they can depend on this app to do their job better and prove their day to make customer service or whatever element of the business that the software does if it works well.
Chuck Weindorf 00:14:27 So if it’s effective in its job, that’s primary and I don’t negotiate on that if there are some defects. One team that was mired in defects, I said, okay, here’s the deal. If a severity defect of level two, which was fairly high, comes in by the next release and we were an Agile team, so it was five, six days away, we’re going to fix this. No discussion, I don’t care what else weights. We’re going to fix these things for quality. The high-quality systems, and all of a sudden work begins to come to you from others. It’s the fun work, it’s the new and exciting, it’s maybe new features to your system, enhancements that the business would really crave. You get to work on that and you’re not just doing the whack-a-mole of hitting this defect and that defect and now you fix one defect and another pops up.
Jeff Doolittle 00:15:15 So what you mentioned before, you said you had a team with a lot of defects and if a certain level of severity came in, what happened as a result of that when you sort of implemented that zero tolerance for defects policy?
Chuck Weindorf 00:15:28 Well, they got annoyed pretty quickly. And I do think there’s a healthy annoyance that we can provide to everyone is that, look, I’m going to disrupt your day if your quality’s not good because now you’re going to have to sit and listen to the old manager come in and say, alright, we’re going to stop doing everything, and we’re going back and redo this thing we thought we were done with. Not to say that we were making it public, but internal to the team, we almost had a little bit of a scoreboard going on. All right, who’s stuck working on the defects that they created from the last release? And it became, let’s say it like the guy’s landing on the aircraft carrier, everyone’s known who’s hitting the second wire on the aircraft carrier every time and everybody knows who’s missing with the hook and has to circle around and go again. And so that internal competition was healthy because once we got down to where we were fixing them each release, for some reason they stopped showing up. We’ve got fewer and fewer significant ones because folks did a little bit extra on their enhancements. I’m going to make sure it’s working. I’m going to go back and do regression work. I’m going to automate some tests so I can make sure this is good forever. All those habits were good simply by making visible how good our quality was or lack of quality. Even more important.
Jeff Doolittle 00:16:37 Sounds like from what you just said that there’s a relationship between responsibility and accountability.
Chuck Weindorf 00:16:43 There is. I always struggled with whether I’m responsible or accountable for something and I says it isnít a lot easier if the work is good, you can say I did both, or I’m really counting both as a success as a leader. I always knew I was accountable for a couple hundred people in a way. And the responsibility of this gang was to give me high quality. When those things are going good, then folks are rewarded. We’re all celebrated. The world gets easier when quality is high because those other things fall.
Jeff Doolittle 00:17:13 And you have more time to do the fun stuff because you’re not dealing with those other things.
Chuck Weindorf 00:17:17 A hundred percent, hundred percent. This job could be very enjoyable and rewarding. They’re, hey, you’re making something out of nothing. How many people get to do that? And if your customers are excited and coming to you with new ideas that you didn’t think of, obviously, and it’s helping the business, you are going to have a real enjoyable career across the board. It’s less like work.
Jeff Doolittle 00:17:40 Yeah. In fact, I’d even say in a way we’re making nothing from nothing because it’s just ones and zero.
Chuck Weindorf 00:17:47 Itís down to the very root of it. I did program a little binary a hundred years ago.
Jeff Doolittle 00:17:54 Wait, you programmed binary, not assembler binary? Okay.
Chuck Weindorf 00:17:58 No, I even went that far back. I was doing some kind of encryption thing at the time, so I got to go through the ones and zeros.
Jeff Doolittle 00:18:04 Well, if this was a different episode topic, I might want to chase that rabbit, but for now we’re going to move on.
Chuck Weindorf 00:18:10 Okay, sounds good.
Jeff Doolittle 00:18:12 That’ll be the B side from after the show. Okay. So also in this section on responsibilities, you mentioned something that is near and dear to my heart. I know it is to yours as well, which is ethics. So let’s talk about the ethics of software engineering and software leadership from your perspective.
Chuck Weindorf 00:18:28 I learned my attention to ethics a couple ways. One was from my dad, you know, who was a military man, navy guy. And when I got to the company as a 19-year-old, the folks who were in the most senior positions were the World War II guys and talk about ethics, ethics is wired into these people. I mean some of them were toddlers during the Depression, so they didn’t have a lot. And when they did a job, well, they didn’t have to crow about it. They would tell me constantly, hey, don’t complain. You know, we beat the furor, we beat the emperor, you know, what you’re doing is kind of easy. I’m like, oh yeah, I guess you’re right. So for me, ethics came to having an attention that if everyone saw what I was doing in my day and they thought, hey you’re doing okay, then that would be a good habit to get in place for engineers.
Chuck Weindorf 00:19:15 Back in the day, I could pick up the master file for our company, $250 million of data in three reels, pick it up, walk it around the room, do all sorts of things. And so the ethics that they were giving to at the time, a 20-year-old, you know, the charge of ethics to me was, you got to take care of this stuff. This is the company’s lifeblood. And so today when someone is let’s say, fixing a production defect and to get elevated authority to go into at a production system and actually look at what’s going on there and that sort of thing, I have to be able to trust that they’re not going to go and pull up the owner of the company’s bio and see what policies he holds or other things. So ethics becomes very important to me to say, this data that you’re touching and the information you have access to is so precious that any kind of a breach of this information or in this trust is just fatal to organizations. So I have to work on the ethics, my own ethics, the ethics of everyone in my field, and to let them know this is non-negotiable. We’re going to perform at the highest ethical level, and if there are problems that we detect, we’re going to elevate them and talk about them and handle them.
Jeff Doolittle 00:20:24 So how have you instilled, you mentioned a little bit about quality, but maybe more broadly, how have you worked to instill those kinds of values in the teams that you’ve worked with in your career?
Chuck Weindorf 00:20:35 For quality? I tried to lead by example in one of my projects, it was a complex document replacement. So insurance documents, lots of rules, lots of laws and all sorts of things on many moving parts, hundreds of data fields. So it was easy to miss stuff and you couldn’t because you’d go into a court of law and if something wasn’t right, you really didn’t do well. So what we did was, we were early adopters of automation, repeatable automation, the most common policy, send them through, get your documents, compare them to the last time, tell what’s changed, and then our work directly with quality assurance to say, this change was intended, is that good? They give the thumbs up and then we would make that our new automated test going forward. So not only did we start doing that, but we said all requirements had to match the actual system all the time.
Chuck Weindorf 00:21:26 So this was, many systems would start with requirements, but then bug fixes would go in and small enhancements, and we wouldn’t document them the same way they’d be in different places. And I said, nope none of that. You open up this document and you’re going to see what the production system is doing at all times. So that level for quality, that made a big difference because there was no discussion about, well, who asked for this? And is that the right thing? The system was well documented down to its production level all times. So for quality, that was probably my best example. We were able to get down to single digit defects in a series of hundreds of documents.
Jeff Doolittle 00:22:03 I actually want to pause there for a second. I think that’s a really important insight that often can be missed in our industry. So maybe talk a little bit more about that, specifically about how documentation and quality go together, because I think there’s a lot of sense from certain corners of the industry about things like MyCode is self-documenting or phrases like that, that are sort of bandied about. And yet you just made a really strong correlation between excellent documentation and quality.
Chuck Weindorf 00:22:31 A little bit of my, I understand where the old timers come from and the level of documentation we used to do to these systems back in the day. And it was functional documentation when you need to make a change to what you do, these things, each time we had less of the formal written documentation and now the newer techniques, which is Agile, I’ve done 7,000 story cards. What does the system look like as a whole? Well, I don’t know, it’s 7,000 story cards. Okay, well that makes me nervous because a defect comes in and they said, hey, we think the system should do this. I’m like, oh my gosh, what story card was that? Can I call that a defect? Or is that a new enhancement? So it was important for team efficiency of an enterprise team serving, we’ve served 12 business units.
Chuck Weindorf 00:23:13 Look, we’re going to have the document precise, and when the document is incorrect, we fix the document, then we fix the application. And it always went in that order. If there was something in the document that was correct and we saw the document didn’t produce properly, there’s your defect. It was such an easy way to go about business because we all agreed on where we started. Developer didn’t do it properly, you fix it, the new requirement coming from the business, you add it to the requirements and schedule. And so it became just mechanically simple and we didn’t have to go hunt and peck for what was the system really supposed to be doing. Whenever we went and had a, let’s say a challenge, a legal challenge to how our, our operation went. Whenever we were audited, we could prove what we were doing. I mean, it just made life so much easier. Now it’s effort, it’s hours, and it’s attention to detail and you need the business’ help to make that document. But it was so worthwhile.
Jeff Doolittle 00:24:12 And there’s the other time that wasn’t measured, which is all the pain and suffering you didn’t endure because you had the document. It reminds me somewhat of it how in the construction industry they have as-builts, there’s the original designs, but then they keep updating the designs as they go so that when you’re done, you know exactly how the building was built, which is really useful for maintaining the building, which kind of pertains to quality.
Chuck Weindorf 00:24:34 We actually stole a construction term, a punch list was a term that came from a construction side thing. And we actually have a side punch list to say, here’s how you’re going to change your application outside of the original requirements. I’m like, oh man, I hate that. So we tried to wrangle that back into the mainstream that very important people asking for enhancements still came in through the front door and didn’t just spirally happen in our system.
Jeff Doolittle 00:24:56 And then how about ethics? You know, that’s one of those where instilling ethics in people sounds like an interesting proposition, but I’m, I’m curious what you’ve done in your career to try to help enhance that with the teams you’ve worked with.
Chuck Weindorf 00:25:09 I’ve been in interviews with, with so many candidates, whether they’re experienced or right out of school or overseas and all sorts of things. And I’m listening with my ears to hear are what you’re telling me accurate about yourself, and I’m asking some leading questions. Hey, in this situation, what would you do? How would you handle this? And most of the answers are well intentioned, but I also think some of them are, let’s say I want, I don’t want to make myself look terrible. And so there has to be an element of, you got to tell me when you make mistakes. I’m not going to club, we’re going to work together on this. We’ll have a true up conversation later about how we can improve performance, but you’re going to be able to approach me at any time and tell me things that you are worried about in an ethical sense.
Chuck Weindorf 00:25:59 Now, if I was a heavy handed manager and I’m just got a tight grip on every activity that the team does, I’m not going to have that trust from the individuals to try and, hey, here’s something that’s really going wrong, I’m going to try and fix it so Chuck doesn’t find out. Those were always bad days. So I was listening in interviews to say, how’s this this individual behave? Are they going to be open with their own failings and when things go wrong? And I’m going to also try and admit when I am wrong, which happens all the time, and I’m going to say, hey, look, I’m still here. It’s been 40 years. Look, you can make a mistake and still be okay here, but you’ve got to come clean. And the folks who could be very confident in themselves to come forward with problems and be able to tell me I felt were the most ethical individuals that kind of at the root and then we could build on that, then we could build on information security and data quality and those other things that we’re charged with. Here’s why we have to protect these things. But if they had it in their heart to be an ethical individual, then that was a great start.
Jeff Doolittle 00:26:59 Well I think that’s a really interesting segue to, it’s almost like you planned the book to kind of flow through because you’re starting to talk a little bit about culture, which is the next session of the book. And I think there’s a really interesting correlation there between the culture you create and the behaviors of the people and how they act within that culture in ethical or non-ethical ways. So with that in mind, let’s talk a little bit about culture. Why culture is important. Let’s start there.
Chuck Weindorf 00:27:27 Fantastic. I was fortunate enough my first big, big full-time job was with an insurance company. It really was still run by the original founding family was still working there. And so I heard right from the people who founded the place, what their culture was going to be like. And when I was listening to that, I was like, this is great. I got to remember this, I got to write this down. And one of the themes was above all in service, oh, that’s easier. And the word service as the word eerie inside of it. So there you go. I should be able to remember that. So just the very basics of being above all in service for them was to be very clear in helping the policy holder or the agency and to communicate with each other. Let’s enlist the help of others in the company to do that same thing.
Chuck Weindorf 00:28:13 Two people could succeed at the same job, which was wonderful. That culture meant I can do good, you can do good, and we’re both going to be rewarded. There was less of a, only one person can be rewarded this year ethic to it. They would just be able through the culture to encourage everyone to do well. And the company went from quite small to Fortune 500 over the course of 10 years. That was really impressive. But it was done based on employee loyalty and longevity was what really gave them their competitive advantage. So I think that the culture of the organization starting off is key because the leaders then that they bring in and say, here’s the people that are going to carry this culture out, need to be in same mind. You have to do the things the way the culture is designed that made this business a success.
Chuck Weindorf 00:29:04 So for me, I was fortunate, I had a great team that brought me in, taught me the ropes, set the bar very high, but also in the times where I knocked the bar off the rail, they’d come and help me put it back on and say, now you’re not going to do that again are you? I once misprinted 1000 forms with a little X that didn’t quite fit in the box that it had to be in. And rather than reprint the forms to teach me something, they gave me a black pen and I went and I exed off the blocks for about 800 of those 1000 forms. And that was the comment from my supervisor, well, you’re not going to make that mistake again. It’s like, you’re right.
Chuck Weindorf 00:29:43 You taught me something. And that was the last I heard of it, except for I write in the book and talk about it for 40 years later. But the culture was great that way you could talk about the things, the challenges that you had and it was okay if you looked a little silly or if you could talk about your mistakes. It didn’t penalize you.
Jeff Doolittle 00:29:58 So how about people who find themselves in maybe a more challenging culture and how would you encourage somebody who’s in leadership in a software company to address that kind of a situation and maybe build culture or change culture?
Chuck Weindorf 00:30:13 Yeah, it’s tricky. There are other organizations where, let’s say your margin is tight. You don’t have a cash reserve to make a lot of mistakes. That’s where the manager or maybe your resources are limited. You don’t have enough people to really do the adequate job that I’ve described. So the documentation and the automated testing are not as mature. The manager really has to, in that case, manage up in the organization. I’ve got to break down the CEO’s door and I got to come in and say, hey look, we’re just going to be in a bad way if we don’t do certain things right. And maybe picking your battle with that group is the right way to put it and to take the high route. So the ethics to quality, how do I keep that as paramount and okay, maybe we have to work some overtime to get some of these things done.
Chuck Weindorf 00:31:00 So the time management hurts for a little bit, but I’ll bring it back. So I think it’s the manager’s job not only to go to their leaders and say, here’s how we’re going to run the railroad. They also have to come down to their team and say, hey look, we got each other’s back, right? We’re not going to be sniping at each other. We’ve got to do this properly between all of us. So in a way, sometimes it becomes this team against the world mentality. But you have to have that for the folks who work every day. You know, they’ve got you and that they’re going to help you through the day. You can build some of that culture within your individual teams, but you’ve got to let the guys at the top know, hey, we’re doing things a little differently and you can’t come down on us too hard or it’ll break the momentum we have.
Jeff Doolittle 00:31:42 Yeah. And I think that speaks some to the protective aspect of an engineering manager or a software leader generally is helping to protect the team from things that might make the team challenged to struggle, frustrated, these kinds of things.
Chuck Weindorf 00:31:57 It seems to be easy to do. And in some markets sometimes engineers are in very high demand and you could lose top talent very easily if the culture shifts to where they feel like either they’re not valued, they’re not rewarded, or they’re becoming a scapegoat for the things that are outside of their control. If any of that happens, you’re going to lose some very good.
Jeff Doolittle 00:32:17 One of the things you talk about as it pertains to culture is communication. So what’s the connection in your experience between those two concepts?
Chuck Weindorf 00:32:25 Communications? This journey became, when I was in a room of 17 engineers, we had locked doors. We were kind of an extension of the computer room. The computer room had all these big security things on it. You had to pass things through in writing to get us to do anything. And people would see the engineers in the lunchroom and not come and talk to us or anything because we were those people. So I think that it was really important that communication had to get broader between engineers and other elements of the company just to be say, we’re on the same team. We’re trying to help you and we don’t understand what you’re asking for sometimes. So we need better communications to understand how to do this best. Within the IT then, there became those little silos and factions that said, hey, we’re the infrastructure team.
Chuck Weindorf 00:33:10 We do network wiring and that’s it. Well that’s great. Your network’s slow in this, in this note and I don’t know why can I help have them help me identify the problems and get things done. And communication channels between the silos were so important. So for my part, I was trying to find people who I could talk to in the other areas of the company that I could just have the very straightforward ones and zeros kind of conversation. Like, here’s what I see and we’re having trouble, can you help me? That then grew to the communications of, no, I should tell everybody the good things we’re doing in this area of the company and engineering and in particular. And let’s tell them about the things we’re not doing good at. Others tended to show up and start to help us. So communication really gave others understanding of here’s the successes we can provide to you and here’s the things we’re struggling with that you could help us with. And if I wasn’t communicating then I was still just that really young guy locked in the back room not understanding why I was doing certain things in my code. I just figured there’d be a smarter person telling me to do this on purpose. Well, I became more of the solution once I started communicating better.
Jeff Doolittle 00:34:19 Speak to a little bit because one of the sections of the book, you talk about optimism versus pessimism, and yet you just talked about highlighting the problems. So how do you kind of reconcile that?
Chuck Weindorf 00:34:30 I say I’m an optimist, but I have a slight pessimistic streak. So there’s the streak that says if there’s any problem in this system, I did it, it must be me. So I checked my stuff first, you know, that was my pessimistic streak. I just had solar panels put on the house this month. Guess what happened this month? A month ago, we all had an eclipse, I lost three minutes of sunshine. So I’m out there complaining about, yeah, I just got these solar panels on the house, now there’s an eclipse over my house. Unhealthy pessimism, which is that. And then there’s healthy pessimism, which is, I should double check my work. Maybe I made a mistake if I heard something’s a problem, I better look at my in the mirror first. But then there’s optimism. The optimism is, hey, what’s that end view?
Chuck Weindorf 00:35:11 If I go to heaven, what’s this look like, the system, how good is it going to be when we’re all done with it? Sure there’s going to be potholes and other things, but the optimism says, I have a vision of where I want to get to. So optimism isn’t, we just don’t think we’re going to make a mistake. That’s the unhealthy kind of optimism. So each has an element. Each of the stories I try and tell is, here’s somebody who’s over optimistic and here’s somebody who’s over pessimistic in the wrong ways. I have to say, will you people try and be positive for once this guy says, well I still don’t think the system’s going to work. Look, try a positive way to say that. I’m positive this isnít going to work.
Jeff Doolittle 00:35:49 It’s all that coming. Yeah.
Chuck Weindorf 00:35:51 And so it’s just how do you transform that though, right? And sometimes it’s just letting them vent their pessimisms and then we get back onto work. Great. I could live with that, but the continual over optimism, continual over pessimism is going to slow the team down. And that’s what I tried to work on.
Jeff Doolittle 00:36:06 Yeah, I tell software engineers a lot. I say our job is to be near term pessimists, midterm realists and long-term optimists. So it sounds like we’ve got a similar view, but I appreciate the self-reflectivity about that as well. That start with maybe the problems is me, I think that’s really interesting cultural element there that, I think is good to cultivate for sure.
Chuck Weindorf 00:36:25 I think most of my sports work that way too. I went and got new bowling shoes, new bowling ball, new bowling glove tape on my finger and all that. And I still had the same average and one of the guys on my team, like I think the problem’s between your ears.
Jeff Doolittle 00:36:38 Yeah, that’s right. He’s right. That’s right. Well, you know, we engineers, we have our jokes like the PEBCAK, which is problem exists between keyboard and chair, right? The PEBCAK error.
Chuck Weindorf 00:36:48 Lonely at the top. Yes, it is
Jeff Doolittle 00:36:50 That’s right. One of the things you also talk about as it pertains to culture is the old guard versus new engineers. So tell us a little bit about your experience and what you mean with that phrase.
Chuck Weindorf 00:37:02 What I’ve found that the old guard and the new talent both have wonderful minds for automation. They just approach it very differently. And the old guard will fall into that, hey, this old way of doing things might be the only way to do things. Or it’s, I’ve proved it out that it’s the best because it’s stood the test of time. At the same time, there are some programs and software out there that are decades old that still work excellently. So I need the knowledge of the old guard to bring others along and to be able to maintain these systems and to understand how they work and why were they good? Why does this work well? So the old guard has that knowledge of legacy systems, which we have many legacy applications in the world. And it’s important that they share that knowledge and they teach us the basics as a younger generation on the practice is good.
Chuck Weindorf 00:37:57 Itís high quality is still good, high performance is still good. Redundancy of systems is good. And so all those things that they’ve learned the hard way, I need them to share that information but also open their mind to the new techniques that are coming through. Agile was a bit of a war getting them to try that. That was, you mean I got to tell these other people what I did yesterday? I was like, yeah, it’s going to help people to hear it. Well the new talent that comes in might be, hey I’ve got this latest tool or toy and it’s great and it works for these particular roles. And both sides seem to be able to say, my favorite tech can do anything, therefore I’m going to use it as a screwdriver and a hammer and a wrench and you know, alright guys, hey, look, we have to be, let’s pretend we’re all architects for a day and say, what would be the best place to put this tool or that tool?
Chuck Weindorf 00:38:51 So to have the new talent learn some of the old technologies is always a challenge. And to encourage them to do that. And I’ve actually, rewarded with bonuses, some folks who have taken that leap. Hey, I’m going to go back and learn some of the old tech. I’m like, okay, well we need that. At the same time we’ve incentivized some of the old guard to step forward, do the teaching, but also turn themselves back into a trainee and learn. For example, low code was one thing I did. I had a couple old timers jump in there and get their basic certification. They’re like, hey, I don’t hate this. Okay, well then now we’re making progress. It’s too easy to draw the line between one generation and another and one, hey, I know what know how to do this. Don’t tell me anything else. And then the young folks like you old guys use that old tech, but this new tech’s far better. Well it’s, you know, there’s elements of truth to both, but you all got to work together. These systems are hybrids
Jeff Doolittle 00:39:43 And that new tech is going to be old tech in about 10 years. If and so it’s going to happen again.
Chuck Weindorf 00:39:49 You’ve just hit one of my favorite topics that I would say in meetings, an old timer’s talking about, hey, here we’ve done this way for years and here’s why we do it because it’s good. And one of the young guys saying like, you’re just saying that because that’s the only thing, you know. And I says, hey, in 20 years, are you sitting on that side of the table or are you telling me that C# is like the only way to do this? Maybe I am, and so it’s like, hey, this career is a journey. You’re going to be in that chair someday. So try and understand the journey when you get there.
Jeff Doolittle 00:40:19 Yeah. You talked a little bit about rewards and incentives just there. Can you speak a little bit more to how those shape culture?
Chuck Weindorf 00:40:26 Yeah, they’re a two-edged sword in a way. The recognition is very important and you’re recognizing specific things. We aren’t all on a conveyor belt, putting parts together. And I said, hey, I did 10 more parts than the other guy. I might do less lines of code, but I might have done something brilliant. So it really is very subjective to the leadership to be able to look at things and say, I want to reinforce the behavior of an individual and how they accomplished it, maybe more than the technical excellence of it in a way. So I wanted to be able to say, hey, if you are broadening your education and you’re trying something new, if you are sharing your knowledge to others, if you are stepping out of your head down coding role and you’re coming out with new ideas, I’m trying to reward those things as much as I was would reward, let’s say a man’s effort of hours for a team to get there to the finish line. You certainly have to recognize that. But there’s also behavior recognition that I really think is important because we’d make a show out of it. Everybody gets a donut and here’s a little plaque for this individual, and here’s what we’re recognizing. Oh, other folks, I like the donut, but I want to get the plaque too someday. And we move those folks along in their own interest to do better by rewarding the right things.
Jeff Doolittle 00:41:50 Well, and that kind of leads into the last section of the book, which is about leadership and encouraging engineers is the first major topic you discussed there. And you kind of just leaned right into that. So again, here we are, it just keeps, we keep kind of flowing right through the book, which is great. So what are some other ways that you encourage engineers to be successful in what they do?
Chuck Weindorf 00:42:11 When I started, I had one manager who I would say might be the anti-encouragement thing. He was like learning, hitting from Ty caught. Hey Ty how do you do that? You pick up the bat, you grip it hard, you swing it, and you hit the GD ball over there. So, okay, thanks
Jeff Doolittle 00:42:26 Thanks for nothing, Ty.
Chuck Weindorf 00:42:27 Yeah, thanks a lot. Now I can’t do it that way. And so we had to graduate from beyond that kind of encouragement. It’s your job, just do it because these individuals being very talented would like to see their best talents used and become visible. So what is my encouragement to an individual? It came in two ways. One is to say, you’re really good at this. I don’t want you to diminish this at all. Keep doing that. That’s fantastic. So that’s one type of encouragement. And the other is where I might see a hidden flare of talent in an individual to say, just like my communication talent was encouraged by some leaders when they say, hey you write some funny stuff. Can you apply that to IT? My encouragement for someone else to be, I’m going to create a no penalties zone for you to try this.
Chuck Weindorf 00:43:19 You’re going to try, if you fail on it, that’s okay. We don’t care. I want to see how you do with it. So sometimes encouragement was setting them up for the possibility of failure, but if they did fail, they’re like, nah, at least I tried, you know, and I learned something from it. But some of the best successes came from those folks realizing hidden talents. All of a sudden they would transform themselves in a whole different employee and resource for your team. And that type of confidence that I talk about, how do you get their confidence higher? That is definitely one of them to just let them try it. And if they don’t fail at it, they all of a sudden know that isnít going to kill me. I’m going to try that again.
Jeff Doolittle 00:43:58 Or you set up the fact that failure is a learning experience and it’s okay to fail in this context. And that’s another way.
Chuck Weindorf 00:44:05 I would frequently, in fact, almost weekly in my communication talk about here’s the way I did it wrong. And I think I had one in there. I was trying to open a bottle of pickles or something like that and I threw it all over my poor sister-in-law’s kitchen. And every year I pick up a can of pickles. Now her husband still calls me out, is like, put down the pickles. So you just, okay, don’t do that. A guy was the smallest hands tries to open the big kosher dill bottle. Don’t do that. And I use those kind of examples to say, yeah, maybe there’s some things I shouldn’t, you know, that don’t lend to my talents, but maybe I can try it and if I do try it, I’ll clean up the mess if it didn’t.
Jeff Doolittle 00:44:42 Sure. And there’s a culture element there too, right? Like reframing what happened and taking some of the teeth out of it. Maybe it reminds me of the Thomas Edison concept of I’ve just found a thousand ways not to build a light bulb.
Chuck Weindorf 00:44:54 Yeah. He knows what not to do. Now I’m very much a cause-and-effect guy. I think some of my best technical techniques was learned by being forced to figure out my own mistake and figure out how to correct it. The best practice seems to come, then you get a more resilient solution that just is going to work longer and better. And it’s only because you did something really uninformed or even dumb to start, but that’s okay.
Jeff Doolittle 00:45:18 That’s right. Knowledge is learning from your own mistakes. Wisdom is learning from other people’s mistakes. That’s where I really want to get. So another thing you talk about in this section, you say change is awesome except for engineers. So this hits home, I think, but share a little bit about what you mean with that phrase.
Chuck Weindorf 00:45:36 Yeah. I know what Moses felt like. Let’s say I’m going to lead everybody across the desert. Might take us 40 years. I would just say, guys change management. We are here. We take somebody’s doing a job with a pencil and paper when I first started. And now your people are doing things on a mainframe. I’m bringing it to the web. People are doing things on the web. I’m bringing it to mobile phones and devices and I don’t have the chip plugged into my head yet, but I’m figuring that’s coming someday too. I’ll have a new user interface that way. And so what I would try to tell them is like, hey, remember all those people when you were introducing your new system? They said, I’m not going to use this thing. This thing looks weird or it doesn’t work the way the old one works. And you would say, but this is the way to go.
Chuck Weindorf 00:46:15 This will help you. I’m telling them the same thing. The change management of the individuals, I’ve got 10 years of experience. You know what that looks like on my resume? It’s great. This company is now asking you to learn something else and your resume will be even greater when you get done with it and we’re going to help you through it. So in a way, the change management within engineering is to give them that, hey, you’re still just as valuable as you were before. And more so because you’re going to continue to move your organization forward. You’re going to lead at the front, you’re not going to back into tech. You’re going to take hold of it and use it for our betterment and we’re going to reward you for it. So change management. I wasn’t the kind of guy that says you’re going to learn this or else, because we did have so much legacy software and we needed some folks to do that. But I was really specific in my praise, even promotions about the fact that folks are trying new and difficult things and change management is just part of the business. Very few folks can start with one technology and end with it, and those who do that might not have very long careers as well.
Jeff Doolittle 00:47:26 So what would be your encouragement to someone who finds themself in a situation where they are being encouraged to shift from maybe being an individual contributor into a more formal leadership role? And a couple things in that. One, how would you help them with the decision process about whether to pursue that or not? And second, if they choose to pursue it, what would you encourage them to learn and do in order to grow into that role if they don’t have any formal training?
Chuck Weindorf 00:47:54 Oh wow. What an awesome question. So you get to a juncture where you’ve probably conquered in your own talents, the technical things that you can possibly do. You’ve probably done some of the most difficult things possible. And in my case, I was just loaded with, a nice history of good accomplishments. And a leader joined the organization who didn’t know anything about it, talked to some people and he says, he came over and said to me, you’re leading this technical effort. How about you try and teach engineers in general to do what you’re doing? So we end up with five of you, 10 of you. Are you sure you want 10 of me was my first reaction and he says, well, not specifically like you, but I want these behaviors. And so my charge, that was encouragement for me, right?
Chuck Weindorf 00:48:41 You have certain good behaviors I would like to promote and here’s what we’re going to do with you to put you in the spotlight. So they put a microphone in my hand in front of several hundred people. I’m like, okay, I’m definitely not qualified for this. I’ve been sitting in the back room all these years, so I had to learn certain things. They got me a speech coach even and says, look, you’re so goofy. We’re going to try and get you to speak better and give these ideas out because we want to show others that a career can extend into leadership and you still have your technical skills, but you’re now going to lead more and more people to the right technologies, the right behaviors, the right practices. Something called non-functional requirements was something I got to build from the ground up. And it was just a yardstick to measure how are we doing as an engineering community?
Chuck Weindorf 00:49:28 And we could see it at a glance. How is landing one system doing? It was important to be able to say for me, okay, this is how I see you happening from the management side, and here are the challenges where we can improve. If you like that type of work, if you like, guiding others to have a success and then be able to cheer the fact that they’ve hit the finish line and won a medal leadership is probably right for you. If it really worries you to be in the visible mode, to be out front talking to people and encouraging them, it’s just not for some people, then the technical career can be continually rewarding for you. You could be a technical lead, and leading people means you’re just going to want to go out and create more great behavior and more successes beyond yourself.
Jeff Doolittle 00:50:13 So what about those who find themselves in the formal leadership role, even though they might feel uncomfortable or like they aren’t really suited to it, but that’s just sort of where they’ve ended up?
Chuck Weindorf 00:50:25 Yeah. My first one was probably like that. I was implementing in an area where I had 70 some people that were all doing technical stuff and I was not by title, but I was actually doing the job. And they said, well here’s what we’re going to do. We’re going to put you in pure management for a bit, and we want you to forward this new technology to production and get the team to do things the right way. And I realized once I got there, like, oh my gosh, you mean I’ve actually learned something by being a technical leader for a while and helping people along this also applies just fine to guiding people in their careers, to guiding people in the right behaviors to have more of the soft skills? I had to develop the right way to say things.
Chuck Weindorf 00:51:09 The ways of not to make people angry and trigger emotions. I had a lot of work to do there, but it all came down to really wanting the best for the team and the people there. And if you can look at it from that perspective, I’m here to help these folks become better at what they do. The day gets so much easier and it isn’t so much of a, I’m the hiring and firing guy, I’m the disciplinarian. Not really. No. If you’re spending all your time in discipline, then something isn’t right. And that’s my chance to look in the mirror.
Jeff Doolittle 00:51:41 Absolutely. You mentioned something interesting before you said that they actually got you a speech coach or something along those lines. And I wonder what other soft skill areas you might encourage people who find themselves in a software leadership role but maybe weren’t formally trained. What are some specific things that’s one, improve your communication, by the way, I’ve also had the same thing. So that’s one. But what else? What other soft skills would you recommend that they develop?
Chuck Weindorf 00:52:13 Yeah, there’s so many ways to improve those things. One of my introductions into leadership was in a church council, hey, you’re kind of smart. Why don’t we put you on the church council? And I don’t know if that’s a good idea. I’m an engineer. I like trust us. We think you’d be okay. And so I was able to improve my written and verbal skills by being able to share in a round table and talk about the different people that ended up on this council. It was great. I got to see people from all walks of life and skills, but all hoping that our church continues healthily. And so volunteer efforts are great for that sort of thing. It doesn’t have to be complicated. It doesn’t have to be stressful. It can just be, maybe I’m good at this.
Chuck Weindorf 00:52:55 I’m going to try it out. And so I think volunteer efforts are excellent. Anything that helps your communication skills. There were times I would look at one of my kids and I couldn’t come up with their name for a few seconds because my head was in code. I would actually still be so far in that side of my brain, I’d go like, all right, I know your name is, you’re a girl and you’re this old, therefore you must be, you know, it would take me three seconds to come up with it. So how do I transition my brain back and forth more easily? How do I not get locked into technical thinking? Well, quite often things you can do in the volunteer world that that makes that happen. Writing fiction was a great thing for me. Can you put yourself in the shoes of other people? Here’s a character who’s an old grumpy guy. Well, now I’m that guy, so I guess I can’t say I’m in those shoes. Well, when I was younger, I was writing about people in other shoes and I’m saying, here’s what they think like. And over time I thought how wrong that was. Certain things that I was writing down wasn’t right at all. And my stereotypes weren’t right. Well, that was a great lesson.
Jeff Doolittle 00:53:56 Sure. What are some future trends you see for software engineers and leaders?
Chuck Weindorf 00:54:01 Yeah, I think that the low code world was interesting to me. I stood up in front of a coding conference of 250 people and I told them low code’s coming and you better learn something about it. And they booed me, that kind of stuff because they were all coders. Doesn’t mean you’re not going to code, but certain parts of your applications, low code makes sense. Multichannel delivery. Why don’t you let it figure all that out for you and not code everything in JavaScript yourself? So I’m a big proponent of that. I think that AI has its place, but I’m also one of those worried people that if we start using AI within engineering in certain ways, we’re going to be in trouble as well. So AI give me a routine that does X, it gives me this routine. I put it in my system 10 years later, there’s a lawsuit saying, you have a copyright. Some AI wrote part of your system, and we want some of your billions of dollars.
Chuck Weindorf 00:54:53 So I think that having an awareness of the right places for AI as a trend for the future is going to be super important. And using it in the right ways will be critical to engineers. This is where I get back into the ethics and the like, am I being ethical in how I’m using tools? AI is going to be a temptation and it will be a temptation for both leaders and engineers. So I think an appreciation of that is key. And then finally, the continued vigilance of information security, protecting our systems. It just never stops. It’s an arms race where the bad guys get better and the good guys will need to get better to defend the system. So all those things I think is where we’ll be spending a lot of time.
Jeff Doolittle 00:55:36 Of course, now I’m hearing Star Wars, darkness rises and light to meet it.
Chuck Weindorf 00:55:41 We’ve heard that. Anytime somebody learns a new tech, hey he’s come over to the dark side.
Jeff Doolittle 00:55:47 Alright, that’s right.
Chuck Weindorf 00:55:48 All over.
Jeff Doolittle 00:55:48 Well, Chuck, if people want to find out more about what you’re up to, where can they go?
Chuck Weindorf 00:55:52 I am out on LinkedIn. Charles Weindorf, Engineer has some of my latest work. I do have a science fiction novel series coming out. So Charles Weindorf out on Amazon midyear. You’ll start to see a series of six books come out there. And I do expect still to be writing about both fiction and in IT leadership. So there is Charles Weindorf.com is out there as well.
Jeff Doolittle 00:56:17 Okay, great. Thanks so much for joining me today, Chuck.
Chuck Weindorf 00:56:19 Jeff, this has been great. Lot of fun doing this.
Jeff Doolittle 00:56:21 Awesome. This is Jeff Doolittle for Software Engineering. Thanks for listening.
[End of Audio]
