The Build Better Software Podcast

Buy the book here: https://gum.co/dont-say-that/podcast-specialMichael's pluralsight courses here: https://www.pluralsight.com/authors/michael-callaghanRough Transcript (powered by Otter.ai)George Stocker  0:00  Hi, I'm George Stocker, and this is the build better software podcast. Today I have the pleasure of talking with Michael Callahan, lead software engineer at Walt Disney World. And I want to welcome you to the show.Michael Callaghan  0:11  Thank you, George, happy to be here.George Stocker  0:13  So for the those of us who may not know about you, or what you do, tell us a little bit about yourself,Michael Callaghan  0:19  where can I start, I am halfway through my third decade of professional software development. It was way back in the ninth grade in buoy High School. When the data processing teacher, we actually had that class, took pity on me, and allowed me to essentially use her dumb terminals in the classroom after school to teach myself basic. That led to a love for computers and software that never really waned. Even though it was about 10 years after graduation, before I got my very first paid software development gig. And I even got burned out in the late 2000s. Well, mid mid to late 2000s. And didn't work for three years in the industry. And fortunately, that that changed. And I'm now in my 10th year at Disney with Disney Parks experiences and products, where I build what we call cast facing web applications.George Stocker  1:28  So applications for the internal employees that work at Microsoft, or not Microsoft at Disney,Michael Callaghan  1:35  correct. As you may or may not be aware, Disney Parks refers to their employees as cast members, because the entire place if you will, is the metaphor as a as an ongoing show. So even us, we were called backup house cast members, because we're never on stage.George Stocker  1:53  And now you have a book that just came out, which I had the privilege to read. It's called "Don't Say That at Work". Tell us a little bit about that.Michael Callaghan  2:00  What can I tell you about that, as you can probably imagine, if you've done anything for any length of time, you're going to make a lot of mistakes. Hopefully you recover from those mistakes and learn from them. This book is about some of what I consider the more egregious errors that I've made over my career, and some cases, mistakes that somebody else might have made or things that I've observed. And I just decided to put them down in essay form, came up with 20 topics and went ahead and publish the book. So far, it's been well received. George Stocker  2:36  Now, before we dive deeper into your background, I want to dive a little bit into the book. And in the book you talk about not only, you know, mistakes that that you've made, but also things that both software engineers and software leaders should be aware of. And you have a story in it about about one of your bosses, can you go deeper into that storyMichael Callaghan  2:57  I mentioned a few different bosses in the story is which one he is talking about in particular,George Stocker  3:03  it was it was a boss that was not was not altogether truthful.Michael Callaghan  3:09  That was a fun experience, because that was very early in my career. And so I was still naive, wet behind the ears, whatever phrase you want to use. And I never had a college degree, at least not at that point. I was a University of Maryland computer science dropout twice. So when I got my very first software development job in 1995, I felt very fortunate that someone was willing to give me a chance without a degree. That did not turn out too well. And then I got my second job. And that was this particular boss. Not only did he not give me the job that he hired me to do, which was that of a Macintosh developer. And yes, I was a Mac developer before it was cool back when we used Pascal. But not only did he not give me the job that he had hired me to do a few years into the into the job, I want to say bout a year and a half, maybe two years. He asked me to falsify my resume. Because what he would do was send resumes of his employees when he when he would bid on a job. So we were as we were an independent software development shop. And he would go and bid on different development projects, bring them back in house, and then he would manage the project. So this particular client wanted only college graduates to work on their project. And that's their prerogative. I didn't have a degree. And when I pointed that out to him, and he did two things very quickly. One he got annoyed with me for not having a degree even though he knew that and then second, he went ahead and modified my resume to say that I had a computer science degree when he sent it to the client. As you can imagine, I didn't take that very well. But this is my my boss. This is my livelihood, doing what can you do about it. Eventually, I decided that I couldn't in good conscious, keep working for this guy. So I started looking for other jobs. So I went ahead and submitted my resignation and turned over the key to the office and walked out the door, essentially.George Stocker  5:16  But that's not the end of it, is it?Michael Callaghan  5:17  It is not.You have read the book. So right after I resigned, I thought we were on pretty good terms. He sent me an email that said, Hey, would you mind signing this affidavit? I just need something for, for the record saying that, you know, you officially quit and you don't have any company property. And then you're not going to solicit any of our clients or, or employees to try to poach them. I was good with that I looked through it didn't seem to be anything scary in there. So I signed it to the back a day or two later, I was cleaning out my desk, at home, my work from home desk, and I found a couple of CDs that obviously belonged to my employer, my former employer. So I sent off a quick email to him, I said, hey, I've got these CDs. I must have overlooked them. If you want, I can bring them by the office sometime, put them in the mail, whatever you want, set them aside. didn't think anything more about it. That Saturday, I got a priority overnight, FedEx letter from his attorney, accusing me of stealing, not only the CDs, but also source code, and informing me that I was now the subject of both civil and criminal investigations.George Stocker  6:31  And so at that point, how are you? How are you feeling like to get that that letter petrified,Michael Callaghan  6:38  absolutely terrified. And here I am, I've got a wife in a newborn, I think my son was about 18 months old, maybe close to two years. And here I am being told that I'm going to be arrested and thrown in prison. Because I committed perjury by saying that I hadn't kept any company property. But youGeorge Stocker  6:57  did the right thing, and that you engage the lawyer in this kind of entertainment that ever gets in the situation. talk to a lawyer before you do anything. And you talk to a lawyer and a lawyer. I didMichael Callaghan  7:07  talk to a lawyer. But keep in mind, it was Saturday. There was no Google there wasn't really much of an internet in 1997. To speak of. So I there wasn't a lot of research I could do there wasn't, I couldn't go to a website and ask questions or, you know, legal online forums, I had to go to the Yellow Pages for New Hampshire, find a lawyer pretty much at random, and wait until Monday. So I had to wait two whole days, not knowing what was gonna happen. And then Monday morning, I called someone that I had found that offered one hour free consultations and explained to him what happened. He had me come into his office with everything that I had, you know, the letter or the the email the the letter that I had signed, saying that I wasn't going to take anything and meet him in his office that morning. When I got there, he reviewed everything he heard my side of the story said, this seems like overkill. This seems kind of silly. So let me just go ahead and give this guy a call. Maybe we can take care of it right now. I won't even charge you anything. I'll just, I'll just help you take care of it. And when he made the call, my boss flipped out. I don't think he was expecting me to fight back. I assumed he just thought I would roll over and cower, which kind of what I want it to do. But one of the one of the cool things about the call from my attorney said, Let's call him Mr. Smith, said Mr. Smith, you can't go around threatening criminal prosecution to as a private citizen. He said, That's not how this works. He says, in fact, you could be putting yourself in legal Jeopardy by doing that. In this state, he goes, so I would appreciate it. If you don't go around making threats like that to my client. You know, now I'm getting nice and puffed up. That was the wrong thing to say to this guy. He he was not one that could be intimidated. And I could hear through the other end of the phone. He was just screaming at my attorney. Eventually everything calmed down. But when they got off the phone, the the lawyer looked at me and said, Well, I thought we could take care of this pretty easily, but it looks like not. And so I had to hire him officially and give him a $500 retainer. And then he took over negotiations with my former bosses attorney. And the way it all ended up, I ended up driving to this other attorney's office, giving him the two CDs and another affidavit and believe it or not, I was also required to apologize for putting my boss and all in his company through this ordeal, and it cost me $500 so for the privilege of doing that, but in the end, I never served any prison time. So I guess it's all good.George Stocker  9:49  Yeah, no, it was it was a harrowing story to read. And it it reinforced at least for me in my background is Ensuring that when you're interviewing at a company, or when you're working somewhere, you know, if you see small things that look like they're out of place, you see small moral misgivings that that can, you know, that's not just the first time that somebody's done something about, you know, falsifying your resume and sending out to his clients or prospective clients for the company is not probably the first time that they've done something that is ethically questionable. And you need to be on the lookout for that, because it could lead to in fact, what you went through, which is a pretty harrowing experience.Michael Callaghan  10:38  It was definitely a harrowing experience.George Stocker  10:41  Now, on the lighter side of the book, the book has 20 some odd lessons about things not to do at work. And one of the other passages that really stuck with me was, don't say no at work, and you give an example of how things are handled during a Walt Disney experience. Can you go into more detail?Michael Callaghan  11:03  Yes. And let me preface that by just explaining that. I am not a Disney operations cast member. I don't work in the parks. Well, I do sometimes, but not it's not my job. So I haven't been through a lot of this training. But I've seen it in action. And I've always marveled at it. So if, if, if I can let me start with a real quick story that's not in the book. Have you been to Walt Disney World?George Stocker  11:27  I have about some I'm ashamed to say about 20 years ago now, I have only been one. Okay.Michael Callaghan  11:34  So the location that I'll mention probably wasn't won't mean anything to you. In the one of the newer sections of Magic Kingdom is new Fantasyland. And in new Fantasyland is the beasts castle from beating the beast in that castle is in a restaurant called br guest. And on one of the few occasions that I have actually gotten to work in the parks. I was helping out on on a abnormally. Let's see what how the right how to put this to the right way. It was a holiday period with increased Park attendance. How's that? And I was working in VR guest a kind of as a volunteer, helping with keeping parties together and handing out menus. And someone came up to me holding the menu and they said, Hey, can I keep this? Keep it? What do you mean? You know, do you get your food? No, no, I want to keep it for forever as a souvenir. I was taken aback as I never heard that question before. And it wasn't something that I was trained to deal with. And my first thought is, well, of course you can't keep this it's you know, people need these. This is its menu. And so that was mine. incident reaction was? No, of course not the look on this guest face when she handed me the menu and walked away. Something I won't forget anytime soon. And what I learned from that, from the manager in the in the restaurant was we don't tell guests No. What if they make something you know, what if you can't accommodate them? What if it really is an unreasonable request? And she said, Well, first of all, that's not an unreasonable request. People take our menus all the time, we're we're aware of that. You're Second, you need to learn to say no without saying no. Okay. So that leads me to the story that's in the book. And we were in my family and I were in Disney's Hollywood Studios outside of the sci fi dining restaurant, and we had reservations and we had checked in, we're waiting for our table or our car, if you've ever been there, and people would come up to the hostess at the podium outside the restaurant and ask, do you have any tables available? And I never once heard her say the word no. And I watched for quite a while. She would say things like, I'm sorry. We don't have any tables available. But would it be okay, if I helped you find another restaurant nearby? That seemed to be her go to answer. Or, you know, another possibility for another restaurant might be? Could we see you at the bar? Could we can you know? Would you be okay? Or would you be open to take out? Apparently some of the Disney restaurants do that. And I did not know that at the time. So there are all sorts of ways to tell people No, without telling them No. Because when you tell them no, the conversations over, you really can't go any further. But if you say I'm afraid I can't help you in that particular request. Is there another way I can help you? And we can move forward? Or there? We don't have any tables now. But what about an hour from now? Would that work for you? So the goal is always to be trying to help rather than just shutting down saying no. So you can move on with your day.George Stocker  14:36  There are a lot of stories in your book and they and they all seem to have a a personal perspective to it, which provides a lot more of an emotional background. And we won't go into the example here too much. But you you put yourself into this book, you know with with all of the examples That you wrote, like the time that and people should read the book, like the time that you were in a net meeting call and accidentally, after a rather tense conversation accidentally ended the conference for everybody on the call. And it's, it's just like, I can feel your how much of yourself you put into this book. And it shows when you're reading on the pages, and I feel like I was feeling those emotions with you. While you were writing it, how was that process for you?Michael Callaghan  15:28  For the most part, it was just me in a brain dump of what I remembered about the situation. And the particular one that you're referring to now I call it my temper tantrum. That was at HP back in 2005. And the reason I remember that one so well, is because I almost wrote a book at the time about it. And I never got any farther than a bunch of chapter titles. And so I was cleaning out my harddrive one day. And I found this file, looking through it. And I said, I remember this. Oh, yeah. And I had forgotten about that. I'd forgotten about that. Oh, yeah, I remember doing that. So in that one. And I think that's probably one of the more detailed chapters in the book, because I had all that information right in front of me, that I could draw from. Now, if you're asking, how was it emotionally? Looking back on it, it's just kind of funny to me now. Because I remember, right after I hung up on that call, I started getting instant messages from my co workers. Did you just hang up on everybody? And I said, you know, did I? I guess I did because I initiated the call. And it's not like today's zoom calls Weren't you click leave it says, you know, disconnect. Everybody, yes or no? It was just the call has been ended by the by the originator or something of that nature. And it was done.George Stocker  16:45  Now you are the lead software engineer atMichael Callaghan  16:49  Disney Be careful. Let me let me correct you there. I am a lead software engineer. It's a title. It's notGeorge Stocker  16:56  I'm not the lead the lead of anything. The lead the lead, you know, you're one of several correct InMichael Callaghan  17:02  fact, there were four leads on my, on the team that I'm currently on. SoGeorge Stocker  17:06  now as a lead at Disney, what does that entail? What is your day to day look like?Michael Callaghan  17:12  It really depends on the project. So I've done everything from lead the team, which is what you would expect from the title. So I was on a team and I would help with the running the stand ups and work with the the business owners on story grooming and everything you might imagine that a lead would do. And seeing the project through from initial funding, through planning through execution and delivery, through getting sustainment turned over. So I've done that these days with everything going on in the world and with with Disney, it's more of a where do we need something right this second? Can you go help with that? It wasn't long ago that I was writing node scripts to talk to JIRA, the live in Ohio, quote, what do you call JIRA?George Stocker  18:07  I try not, I tryMichael Callaghan  18:08  not to also but at this point in time project management system, right. So we were moving the system from from one machine or one version to another, and they wanted some custom code written to copy a lot of the the issues from one system to the other. They said, well, Mike, do you know node? I do know node. All right. Can you run with this for a few weeks? Sure. Because literally, it's wherever we need you right now. And I think that's a result of COVID. At this point, I'm just happy to have a job.George Stocker  18:40  And how big is your team at Disney?Michael Callaghan  18:43  About a dozen of us total, including some managers,developers, testers, etc. George Stocker  18:50  Okay, and the and this team is the team responsible for internal facing a cast member applications or there's severalMichael Callaghan  18:59  there are several teams. So I want to be careful not to try to you know, dig into the the internal structure workings of the company, because I am not a spokesman for the company. So I'm working on a very small, vertical segment for reservations. And that's about as far as I'll go into, at this point.George Stocker  19:19  Okay. Now, during your career, you've worked at Disney, you've worked at HP. And you and you've talked about a little bit at the top of the show you talked about a few years where you were burnt out. Can you talk about what led up to that, to that burnout Michael Callaghan  19:35  temper tantrum and howGeorge Stocker  19:36  and you recovered for it. It was the temper tantrumMichael Callaghan  19:38  temper tantrum.I think this is in the book that I was given the opportunity to stay on with with hp. They didn't fire me. But they also didn't let me continue on in that project the way I had been because I was I was a de facto leader on that project. And so when I made the decision to do what I did, that led to the lukol The temper tantrum. I kind of knew that if it didn't work, it was going to be bad. But I did it anyway. So when my manager called and she was in California, at the HP headquarters out there, and I was in Southern New Hampshire, so we couldn't have been farther away physically, if we had tried, she gave me the option to stay on with hp for no less than a year in a probationary state, which meant no, no raises no potential promotions or anything like that. So and then they would revisit it in 12 months to see where I had whether I had been a good boyfriend for the year, I did not relish the idea in 2005, of continuing on a project that at this point was five years old and written in Visual Basic six. So I told her, I had another option for her. And that's that I would just give her my two week notice. And she wouldn't have to deal with me anymore. She negotiated an extra two weeks out of me. So I stayed around for another month after that, essentially, helping the the contractors that then hired, understand the software. And then I left. A few months later, I packed up, I moved from Southern New Hampshire to Central New Hampshire. And for the next two and a half to three years, I was a failed real estate investor. And I say failed, because it started out pretty good. And then I started losing money and losing money and losing money.George Stocker  21:29  Was that around the time that the bubble burst on housing?Michael Callaghan  21:32  Yes, right after I made my first few deals, where, where it looked like, Hey, you know, I can make a living doing this. And so I started making a living doing that. And then suddenly, I was no longer making a living doing that. Now, I went from making $50,000 on two deals on a row, to making 15,000 on a deal. That's okay, you know, if you do one of those a month, that's still pretty good, right? And then $7,000 on a deal, and then barely breaking even on a deal. And you'd think that with a software development background, that the pattern would emerge. But it didn't, because I was blinded by my desire to make it work. And so from there, where I should have simply stopped, I lost over the next few years, I think I lost over $200,000. So that was fun.George Stocker  22:20  I'm, I'm trying not to like betray the fact that my mouth is agape. And I'm like, that's, you know, that's that's a lot of money. Michael Callaghan  22:29  Fortunately, I didn't lose it. I mean, it didn't come out of my pocket personally.What had happened was the, the properties were over leveraged. And there were two in general, though, that really were the killer. And I don't know if you want a real estate story that's not in the book, but I consider it one of my biggest failures.George Stocker  22:48  failure is something that helps us learn so sure,Michael Callaghan  22:51  there was a house. And in reality, it was a mobile home was a quote unquote, manufactured home in the town of Jaffrey New Hampshire, right at the base of Mountain monadnock, the tallest mountain in southwest New Hampshire, gorgeous countryside, beautiful mountain views. It was a pristine, open level lot that someone stuck a mobile home in the middle of, but the price was right. It was in good condition. It already had a tenant in it. So I went ahead and bought it and then immediately refinanced it. Because it was undervalued. I took I took the cash, to put it into another property in Concord, New Hampshire, which is the state capitol. So I'll get to that one in a minute. But the tenant I had already talked to, and she wanted to buy the place. But she needed some time to line up her finances. I said, Well, you know what, this is a great opportunity for me. I bought the property from the original owner, who was an out of state landlord, refinanced. It took $80,000 in cash out to fund the no the next investment, immediately put it under contract with the tenant and said, okay, you'll pay rent to me, because you know, you're still a tenant, you'll pay rent to me. Until we go to closing. She said, that's great. I said, I'll tell you what, I'll make it even better. I'll credit you the monthly rent towards the purchase price. Between now and closing. She's wonderful. We're all friends, everybody's happy. Tenants don't always keep their word. I don't know if you're aware of this, but sometimes they stop paying rent. And that is exactly what this one did. And what I later found out is that that was the reason that the house was available in the first place. She hadn't been paying rent to the other guy, either. She gave me one or two months, I guess to string me along and then stop paying. New Hampshire is pretty landlord friendly, not tenant friendly. They're pretty landlord friendly. So I gave her an opportunity to to catch up said hey, do you even still want to buy this place and she finally admitted to me that there was no way she would ever qualify to buy the house. So we agreed that she was just going to go ahead and move out. month went by. I heard nothing jafra was a little bit too far for me to be driving by on a regular basis. So I figured I'd give it another week and then maybe I drive out and see what's going on. Instead, I got a phone call from the town of Jaffrey foot. Well, this can't be good. They said, Mr. Callahan, we just wanted to let you know that we shut the water off to your property on mountain road. May I ask why is it Yeah, the the water guy reading the meter, he said, we noticed that you had used twice the amount of water that you normally do in a month. So he went to the door knocked the only sound nobody answered the door. But the only sound he could hear was water running.George Stocker  25:39  Oh, no.Michael Callaghan  25:41  This was probably January. I don't know where you live. But January in New Hampshire is cold, single digits for weeks at a time. What he or what we eventually discovered was that the tenant had left took all of our stuff moved out, turned off the electricity. Now there's no heat, water pipe leading to the toilet froze and broke. When the temperature went back up, and and the pipe unfroze. Now it's spewing water throughout the entire plot property. By the time I got there, it had all drained out because the floor had collapsed, for the most part with all the water. And there were water stains going up about a foot on the walls. So this thing was a foot underwater at one point. And as I mentioned, it's a manufactured home. It can't handle that the walls were destroyed, the floor was destroyed. There was nothing salvageable about this place. I eventually talked the the lender that had refinanced it into accepting $80,000 for the property when it was originally had been valued around $200,000. And I sold it to a guy who was going to demolish the thing and build his own house on it. So that was $120,000 paper loss. I still had the money from the from the cash out from the refinance. But for some bizarre reason, they didn't ask for that. And I Well, I guess I didn't have it because it was in the next house. So they ended up taking what's called a short sale. So they accepted less for pay off. And then they sent me a 1099 tax statement for the remainder. So I had to pay income taxes on that, on that, quote, unquote, gain,George Stocker  27:18  which is really just the amount that you wouldn't have had.Michael Callaghan  27:20  Right.George Stocker  27:24  Now, the you get back into software development after this this hiatus, you know, what was it like getting back into software development? And what did you do?Michael Callaghan  27:38   I got a call from a friend of mine, guy I went to high school with who knew that I had been a computer nut since ninth grade. He had a company in Maryland. And he needed a software developer, contractor, essentially, he said, Hey, I know, you really, really want to do this real estate thing. He says, but I could use a favor. Would you be open to maybe 1020 hours a week, just consulting and doing a little bit of programming for me, that led to a heart to heart conversation with him. After I agreed I did it for a little while part time, because he said I could do it from New Hampshire, I didn't have to come to Maryland. But then after my next real estate disaster, and there was a funny one after that, that one. He said to me something I'll never forget. He said, I think you might be better off if you stick to your core competencies. And as long as I've known you, your core competency has been software development. And I could use you. So at that point he offered me and I accepted a full time job with this company. And that's how I went back into the industry.George Stocker  28:43  And from there, you eventually found your way. Do you work? Or do you live in Florida now?Michael Callaghan  28:51    I do. So the the Maryland gig led to was a was a number of years, probably good three years, remote work, I flew down to Maryland once or twice a month just to show my face in the office. And that company eventually went out of business. financial problems, right? If you don't sell you don't, you don't bring in revenue, you can't stay in business. That's that led to a couple of minor contracts here and there. And then I got a chance to go to Dell in Texas. The skills I picked up at Dell in Texas, directly led to my current gig at Disney World. So if I hadn't gone to Dell, I probably wouldn't have qualified for my current job and could not be more grateful for the path that that I've been on since then.George Stocker  29:38  And so what were those things that you learned at Dell,Michael Callaghan  29:42  I was hired at Dell, essentially to be an ASP dotnet developer, when and when I say ASP dotnet I mean web forms if you're familiar with that at all. So doing C sharp, server side C sharp web development with heavy web form technology. While we were at Dell, or while I was at Dell, Microsoft came in, did a training, remember what they called it, it was like a developer conference. But it was only for people at Dell. So it was just a small conference room at a local hotel. And I was excited when I heard about it. But then I figured it was only going to be four employees. But they said, No, no, no, no, go ahead and take it. So we can't pay you to go. But you're welcome to go. So I went ahead and went, I met Phil hack, who was with Microsoft at the time.George Stocker  30:31  It was this when they were introducing ASP. NET MVC.Unknown Speaker  30:35   Exactly. Well, it wasn't the very first time because it was MVC version 2. version one didn't impress me much. So we kind of stuck with, with, with web forms. But it was the perfect time, the perfect opportunity, because the product I was on was feeling heavy. And it had a lot of a lot of code that was there, specifically to do the things that MVC two gave you out of the box. So over the next, I think it was there about a year and a half total, I was able to take what I had been introduced to at that developer seminar, and help rewrite that entire project with MVC two, and I think the code size got cut in half. Because of all the boilerplate we were just able to delete, and things like view state. Oh, gosh, I had forgotten. How can you bring that back into my mind?George Stocker  31:34  I will never forget my scars with webforms. Sadly,Unknown Speaker  31:39  yeah, so MVC 2. And that technology led me to when I interviewed with Disney, that was one of the technologies that I had on my resume. And they asked me about it. So I explained that story to them. And it turned out that the people who interviewed me knew a lot of the folks at Microsoft. And so they were, I guess that I dropped the appropriate name. And so I got thatGeorge Stocker  32:04  job. And now at Disney, what sort of technology stack do you use?Michael Callaghan  32:10  I don't think this is a secret. Yeah, I don't think it's a secret. Because if you look at if you go to Disney tech.com you you can find job postings for for all sorts of web development technologies, but it is mostly known on Angular. So I don't think it's a secret, if we're advertising for that. So just about everything I do these days is either node or Angular. I have not I was hired as a dotnet. developer, haven't done dotnet since 2012 2013. Except for one time when I I kind of sneaked in into a project. Not the same story. Yeah, not it wasn't the same as my as my my temper tantrum. But it was very similar circumstance, it was, folks, the dotnet will work perfectly here. Let's just use it. But instead of being sneaky about it, I got the approval up front to do it. Interestingly enough, sorry that that project, went live on Valentine's Day. So February 14 2018, it's now been two and a half years, the dotnet portion of that application has had one problem in production. And it was a configuration typo on my part. Other than that, it's been flawless. They don't reboot it. They don't touch it. It just works. I wish I could say the same for most of our web technologies.George Stocker  33:33  Yeah, I find myself cursing Angular every few months or so as we upgrade. But one of the things I know about Angular is that it really does remind me a lot of web forms. It's the it's the same paradigm. Just this time shifted all the way to the client and wrapped up in a pretty new bow.Michael Callaghan  33:52  interesting you say that because I'm I'm fond of telling people that it reminds me ofGeorge Stocker  33:55  Silverlight. Did you were you able to develop in Silverlight before they killed it?Michael Callaghan  34:01  Yes, I did both WP F and Silverlight.George Stocker  34:03  Yeah, they are now I guess blazer today would be the new would be the new Silverlight.Michael Callaghan  34:11  Yeah, I haven't looked at it.George Stocker  34:13  Yeah. So you as a technology leader, one of your jobs, I assume is to evaluate new technology choices and ensuring that it works for your organization. Now, what are some questions that you ask yourself when you ask your team when someone brings up a new technology choice, like let's say blazer or you know, moving from template driven forms to reactive forms in Angular?Michael Callaghan  34:39  Well,I guess I have to start by correctingyour your original supposition there, and that is that I really don't have a lot of say in what technologies we use. As you can imagine, it's a huge company. So they There are teams whose job it is to is to evaluate those technologies. I was on one of those teams once. And that's kind of where we came where we came up with Angular or the use of Angular and node.George Stocker  35:11  Is it sort of like an architectural Review Board of some sort?Michael Callaghan  35:14  Something like that? Yes. So there's a series of teams that make these decisions, they evaluate these technologies, they come up with reference implementations of these technologies. They set up training to show people how to use these technologies, they approve open source technologies, or maybe, in some cases, do not approve open source technologies. Do you need me to say that again? Did you hear the buzz?George Stocker  35:38  I did, but it's it's okay. Now with how do you interact? You know, in general, what are your What is your advice for interacting with such a committee? Because I've, I've had those, I've interacted with them in the past. But I've also been on small teams, also, where you have a lot more autonomy. How do you, you know, what's your advice for trying to sell them an idea you have?Michael Callaghan  36:01  I think the, the trick, so when this team started, I was actually on it, I had been lent out from my manager to work for a few months on that team. And one of the early decisions we made is that we don't want this architecture team to be considered an ivory tower. We don't want to be up, you know, in our tower on high making commandments. But instead, we wanted it to be collaborative. And although we didn't really get what we were hoping for, I think we had envisioned almost an open source model. If here's our here are GitHub repos. If you have something to add, add, it will will will take pull requests will, will collaborate, will do whatever you need to do, so that it feels like a partnership, not just thou shalt do this. And for the most part, I think that worked, this would have been 2015 2016. So it's been four or five years. And some of that spirit lives on in the team. So they they will collaborate, they will they will send someone to a project to help collaborate on the development in the selection of the technology. And if the technology that the development team needs is not currently in the approved basket, there is a reasonably simple process to get it approved. For example, I had to use ionic once or I didn't have to, I chose to use the Ionic framework for a project that was very time and dollar sensitive. Ionic had not been approved by this team. Fortunately, the project was given to this team. And I was sent to the team to help not only build the project, but also to help sway the technology choice. And so after a little bit of demonstration, and some proofs of concept, I was able to show Hey, we really do need to use ionic for this project to get it done quickly, ahead of schedule and under budget, because in this particular case, there were a bunch of old Windows CE II handheld devices that were going to stop working by the end of the year, because of they were no longer receiving security updates, and would not be able to handle the new Wi Fi certificates. So they were going to die if we didn't do something. So we were able to use the technology we needed to and because of that ionic got approved for use in the company.George Stocker  38:27  Yeah, and for people who may not know what ionic is, is a hybrid mobile application framework. It uses. It sits while the old version of version one x set on top of Cordova and was effectively a UI framework and a a one time for producing mobile applications that could work on both Android and iOS based devices. Now, what were your constraints where ionic made the most sense where it was at those constraints? Was it the UI framework and just the speed of development with JavaScriptMichael Callaghan  39:01  a little of both. So I've told this story publicly before, so I'm pretty sure I'm authorized to continue sharing it. It was for Disney's magical Express. And they have handheld devices, where when you come here on vacation, you can sign up for Disney's magical Express, it's a shuttle from the airport, to the resort, and they take care of your luggage as well. So you get luggage tags sent to you a few weeks before your arrival. And you put your put these tags on your luggage and they've got barcodes on them. At the airport, they wanted to use ruggedized Android devices to scan these barcodes. After resorts. When you get to Walt Disney World property they were using iPhones. So there was an argument early on about well, are we going to do it for Android. We're going to do it for iPhone. And so I raised my hand I said, Well, why don't we just do it for both? Well, we don't have that kind of time Rajat. Well, no, no, we'll use ionic and then we'll just deploy it to either to both of them. Because I only can do that. So they asked me to do a proof of concept. And the hardest part about the perfect concept was the fact that they had a hardware vendor chosen for the barcode reader, they weren't going to use the camera because the camera is too slow. So they had hardware barcode reader, and I fired off an email to their support folks. And I asked them if they supported ionic. And the reply I got back was something to the effect of Never heard of it. But if you can handle Cordova we have a plugin. So okay, downloaded their plugin, fired up a new ionic project, deployed it to my iPhone, and that afternoon was scanning barcodes of Kleenex boxes, soda bottles, everything that that I could find in the conference room. So they said cool use ionic.George Stocker  40:44  They that's the when I was dealing with I was doing Bluetooth Low Energy, BLE. And the hardest part, just like for you The hardest part was the device interaction for the hardest part for us was, you know, tapping into the Bluetooth on the device. And there were Cordova plugins for it. And then ionic, you want to wrap those into Angular wrappers. And that allowed us to use these Cordova plugins inside of the application. But that was in fact, the hardest part was anything dealing with the device, if you had nothing, if you didn't have to deal with the device at all, any of the device hardware, it probably the easiest thing out there. But still, it's even easier using ionic than it is to try to do the same thing with Android that you would do with iOS. Now in the time we have left, you know, where can people learn more about you? And where can peopleMichael Callaghan  41:41  grab your book, the place to learn more about me is probably my blog website, which is walking river.com. My books are all available at Amazon. You can simply search for Michael de Callahan. Or you can go to walking river gumroad.com. anything, any title that's not Amazon exclusive will be available at gumroad.George Stocker  42:05  Wonderful. Now, the book is don't say that at work. And it's lessons from Michael Callahan. And my guest today has been Michael Callahan. Mike, thanks for joining me.Michael Callaghan  42:16  It was a pleasure, sir. I appreciate you having me.George Stocker  42:18  All right, folks. That'll do it for this week. We'll see you next time on the build better software podcast. Thanks

Tess on Twitter:https://twitter.com/_tessrGeorge Stocker  0:00  Hi, I'm George Stocker, and this is the build better software podcast. Today I'm joined by test rynearson. And we're here to talk about engineering and Engineering Leadership tests. Welcome to the show. Hi, thanks for having me. Thank you for being here. Now for people who don't know who you are or what you do. Could you tell us a little bit about yourself? Tess Rinearson  0:19  Yeah, absolutely. So I am the VP of Engineering at a small blockchain company based in Berlin, which is called interchange. GMB H. GMB H is like LLC or Inc, but in German.And I've been working in engineering management at blockchain companies for the last while I've been in the blockchain space for the last five years or so. And for about the last three years that I've been in, in management positions. Before that, I was a software engineer at medium and before that I was a computer science student.George Stocker  0:54  Okay, now let's let's start backwards. You're working in the blockchain space now, as someone who's never been in the blockchain space and doesn't really know what that's like, describe, you know, developing new products in that space. Tess Rinearson  1:09  Yeah, totally. Um, it's a really fun space to work in because lots of things are new. And because the, like most blockchain projects have a bit of a unique funding model wherenot necessarily all of the funding but often a lot of the funding comes from token sales. And so a lot of the people who are sort of like, like invested in your product are also your users are also like, like regular people in a lot of ways. And so there's, there's a different kind of like, like product development and funding cycle from a lot of other like software tech companies, I would say, and I think that gives you like a lot of a lot of latitude and also like a very community orientedway to do your work. When you're building software,George Stocker  2:01  and you're in a nascent market, I mean, we like we don't know the full potential of blockchain. We at least seen it realized yet. So how do you as a leader, how do you work within that that largely unexplored territory?Tess Rinearson  2:18  Yeah, totally. That's a really good question. So when I got started in the blockchain space, it was 2015. And I joined a tiny blockchain company which is called chain because this was early enough in the sort of like blockchain, you know, lifecycle that you could actually call your blockchain company something like that. And chain worked on like a really, really wide range of products built, you know, first of Bitcoin and then kind of like our own blockchain product, and some stuff with like cloud blockchains, like explored a really, really wide range of products that you could build with block chains. And none of them really stuck. And the team ultimately got acquired by another blockchain company, which is a whole other story. But anyway, what I learned from that experience was that even though I am personally super, super excited about the technology behind blockchains, I don't really think I'm like the person who's going to build like a great product from it, at least not a great End User Product. And it's funny because I think that is like kind of the thing that needs to happen for the blockchain industry to really advance like, like when we get when we finally have something that you know, is used by, by regular people, by everyday people, not just by like, crypto nerds. I think that that will be a huge milestone for the whole industry. But I'm not sure that like, I am the person to work on that particular effort. What I realized is that I'm really excited about the infrastructure and like kind of the lower level stuff. So what I work on now is mostly a consensus algorithm, which is basically like one of the key building blocks for building block chains. No pun intended. And so it's just like a lower level thing. And so most of our users are other engineering teams that are also in the blockchain space. And they are building. Most of them are building products that can be used by end users or again by like non blockchain teams. So I'm kind of like one step removed actually from from, like, the product product process. And so what we think about really is just like, you know, what do we what do we need to do to make this tool basically, this piece of infrastructure, as stable as possible, as secure as possible? as standard as possible is actually a really big thing because there's so many things you can explore and do and innovate on in the blockchain space. Like we want to keep everything that we're not trying to experiment with as standard as possible. So that's like something else that we've been really driving towards this year is trying to standardize You know, it As much as our own pieces as much as possible. So yeah, again, just trying to like build really good software for other engineers fundamentally.George Stocker  5:09  Okay. everything I know about blockchain, I learned from the show Silicon Valley. And so I probably know next to nothing, what is the consensus algorithm and how does it work?Tess Rinearson  5:19  Yeah. So, this is one of my favorite subjects actually. So if I, if I get too deep, please cut me off. But basically, consensus algorithms, let a group of computers come to consensus on a value, right? And you can do this in a centralized way in a really easy way where you say like, okay, one computer is, you know, the canonical source of truth and if you need to know what value you should be having, just go ask that. Just go ask that computer for most blockchains or really for most like open blockchains on open networks where, where anyone should be able to join And it's like truly meant to be decentralized. You don't want to have one machine that is like the only source of truth, because that's, you know, very vulnerable to malicious behavior from that, that single entity. And so broadly speaking consensus algorithms are Yeah, how you get here you get a bunch of computers to come to agreement on a value. But in the blockchain space specifically, we really focus on consensus algorithms that are Byzantine fault tolerant, which is a term that means like, you know, able to withstand behavior from from the machines from the computers where they may tell like part of the network one thing and another part of the network, another thing you know, some people say like malicious behavior, which is roughly correct. And yet you want to be able to protect against that in a blockchain network. Because if you can have anyone join, you know, you're sort of inviting potentially bad actors into your system. If needed to be able to withstand a certain amount of that kind of like, Melissa, malicious or inconsistent behavior.George Stocker  7:08  And because the work you're doing is, like I said, largely unexplored, you're relying a lot on theoretical papers and computer science research. You know, how do you how do you find ways to to learn more about this topic? And how do you? How do you level up to where you are with understanding how blockchain works?Tess Rinearson  7:34  Yeah, totally. So we have actually like a, like a sister company that has a lot of researchers in it. And a lot of those folks are from like, have an academic background. And they largely are the ones who kind of like design the what's the right way to say this, like the protocol, and especially like the finer kind of like binary details of the protocol. They do a lot of that design work. And they actually also are in the process of formally verifying it using TLA plus. So TLA plus lets you like, kind of write out your specification, not using English but using this language called TLA plus and then like run it through like a proof checker. And that checker will tell you if, you know, conceptually, your algorithm holds. It doesn't test the implementation or anything like that. And that implementation piece is actually really where my team comes in. So, you know, we have a protocol, we have a spec that we're implementing to make a lot of like design decisions around, you know, our implementation details and choices and things like that. But we, my team, as it is is not really like designing the algorithm.George Stocker  8:51  Okay, you're taking those designs and you're implementing and testing them. How do you test something like this?Tess Rinearson  9:00  Yeah, so there's I mean, the formal verification piece, the TLA plus piece is a huge part of making sure that this is correct. There's a lot of kind of like standard, you know, unit tests, integration tests, things like that, that my team works in. And then there's also kind of this like, novel sort of emergent way to test these open networks. That's emerging, which are these. They're called incentivized test nets. So a test net generally is like a blockchain network. But you say, okay, it's gonna be like short lived, the value on this network isn't actually worth anything. Often you like reset the network periodically to make sure it doesn't accrue value, you know, test networks, right. And incentivized testnet is one where someone basically like organizes a competition on top of that test net and says like, okay, anyone who can execute a certain kind of attack on this network will give you a bunch of money. Basically, anyone who can, you know, make sure that their node conforms, you can run a node on this network and make sure that it conforms to certain constraints for a long enough time, we'll give you somebody and so you kind of set this up. And so in the cosmos ecosystem, so I work on a project called tender mint, but tender mint. Tender Mint is the consensus algorithm and it underpins this network called the cosmos network. So most of these test nets are sort of through the cosmos network. In the cosmos network, there have been to kind of like major incentivize test nets that have been executed one pretty recently a few months ago, and then another one about a year before that. And each of these have had, you know, like, on the order of, of dozens, or maybe like 100 teams participating in it. So they each run, you know, a node that runs all the software and then they try to like attack each other. And so that's a really great way to like, basically, yeah, incentivize people to see if they can, if they can do damage to your stuff if they can break your stuff. Obviously that's not like the the beginning and the end of it. And that's kind of what we do all all these things, you know, again, starting with formal verification with the specification and then kind of like building up. But yeah, I think the incentivize test nets are are one of the cool things that have come out with blockchain space.George Stocker  11:26  Cool. Now the dive back into the the people part because if I stay on this track, we could be here forever. Yeah. Are you in in my own efforts as an engineering leader and as an engineer, you'll projects that have failed or experiments that have failed, especially when there's business that runs on those experiments, or those projects or those products not failing? It's difficult and it's it's hard to maintain morale and to, you know, pick back up and keep going. Especially if you know, you You're finding a lot of ways that don't work. And the business is concerned about cash flow and about, you know, actually turning a profit as an engineering leader in an unexplored space. You know, how do you handle the inevitable setbacks that will occur? And how do you motivate your team when those setbacks do occur?Tess Rinearson  12:20  Yeah, that's a great question.So in a lot of ways, our stakeholders are our community members. And so, we, I think a huge part of what we do is, you know, trying to communicate as actively and as openly, with, with community members as possible. And you know, it's it's community members who run these incentivize test nets, ultimately, because everything we do is open source. community members make a lot of contributions. So we really are like building all of this in public and we just try to be as transparent as possible with our community, which is to say, with our stakeholders. Just be as transparent as we can be, and share, you know, what's going on. If we've had any setbacks, things like that, you know, I think I think setbacks are pretty inevitable. Especially when you're like building with technology where you can, you know, there's a lot of unknowns. Like, frankly, right now we're in the middle of a bit of a release delay, because someone realized that, like a certain kind of attack could be executed, you know, when we introduce this new feature, it like, opens up the surface area for like a new kind of attack. And so we're like, you know, working again, with our sort of our research partners, to make sure that we have like, covered we're going back and forth with them, you know, and that's the kind of thing we're like, we're going to be really transparent with the community about why that's happening and what and how that's happening, while also trying to do things like so like tender mint, the consensus algorithm is kind of at the bottom of the stack in a lot of ways like, like a lot of other pieces in the ecosystem depend on tender mint and tender mint doesn't really depend on most of the other things. So we try to like, you know, produce artifacts that are downstream dependent products can use to, to to move forwards, we're not blocking them. So even though for example, in this case, we don't have a release out, like we wanted to have a release out a couple weeks ago, it's been delayed, but we managed to give them all what we call an integration target. So it's kind of like a release candidate, where you know, the API's are exactly the way they're going to be, when we actually do the release. The features are all the same, it's just missing this, like protection against this one attack. So we're saying like, don't, you know, don't use the integration target, in pump in production, right. But if you want to, like upgrade your software to use our next version, you know, this is a thing that you can like play with, to get to that point. So we do a lot of things like that. Where we, you know, just try to like unblock people in creative ways? Well, so you know, making sure we're covering our butts in terms of things like potential attacks and other like security issues.George Stocker  15:12  Right. Now, as a as an engineering leader, as a VP of engineering, how do you spend your time? what's a typical day for you like,Tess Rinearson  15:20  it varies a lot.Right now, because we're sort of at the end of this like release cycle, I've been spending a lot of time. Honestly talking to other leaders at different orgs and trying to figure out like, what we really need to make sure is in our next release, so it's a mix of like, talking to, you know, the other engineering leaders at other companies in the ecosystem, talking to people on my team. It's honestly it's a lot of a lot of talking and a lot of writing, I would say, in the writing actually, especially since we went I mean, everyone is like remote now, right? And so since since I spend all my time sitting at my kitchen table, and I'm not necessarily like, like trying to have a lot of zoom meetings to get everyone on the same page, I found myself just writing like a ton of Google Docs that can be like, circulated and dissected. And like, that's kind of the the thing that I've found has been effective in this environment, in terms of like building alignment, especially again, in an ecosystem where like, you know, we're one team building one, one thing, basically, but we have lots of community members, we have lots of other engineering teams, who are our users and our collaborators. Again, we have this like sister team, that's like doing the research side. So there's just a lot of people who kind of need to all get on the same page. And we do. We do do zoom meetings sometimes. But you can't do that every time you need to make any decision. Right. So I spend a lot of time in Google Docs.George Stocker  16:56  Yeah. And that's that transition from the company. You were was all in person before the pandemic.Tess Rinearson  17:04  It's It's funny, itwasn't exactly all in person. But we had, we had a few remote people. And in fact, my and like the tendermint core team that works on this consensus algorithm was was kind of split. So it was about half co located in Berlin, and then a few folks in other places around Europe.But,but we still were having, you know, a lot of our like planning and kind of like decision making meetings are all happening in person. Right. And obviously, we can't do that anymore.George Stocker  17:39  What's that transition been like?Tess Rinearson  17:43   Um,I think it's mostly been easier than expected.You know, I think to be totally honest, like, I think, you know, Europe has just not been hit as hard. And so I talked to a lot of friends in the city. Dates where they're managing a lot of emotional stress, as well as like logistical stress, because there's so much uncertainty. And at least in Germany, at least in Berlin, from what I've seen, you know, the logistics are still challenging, but there isn't the same sense of like, kind of like uncertainty about the future, overall, if that makes sense. No, that's just been it's been managed a little bit more directly in Germany than in the US.George Stocker  18:33  That's true. And one of the issues that we have is that as you know, the 50 states 50 different ways of doing things you would hope for a coordinated national response to this point, but we don't have it. And right now, we're about to start back to school and I have, I have two, I have two kids that are school age. And, you know, my wife is a teacher. And so they're planning on going back in person. That's what you know. their school decided to do yet all the other schools around us are staying remote for the first thing virtual for the first month at least. So there's a lot of uncertainty around that. And as you said, it's it's emotional uncertainty. And the mental and the mental load is makes it more difficult to concentrate on, you know, important your day to day activities. Because always in your mind, there's this thought that Yeah, like we could be three weeks away from us having COVID from my wife getting it from my kids getting it from me getting it. Yeah. What, what do you do? And so that's only to only to paint a picture of what it's like over here right now, at least where I'm at, in the Washington DC area. That's, that's what we're feeling and that's a common sentiment that I've heard from your friends or neighbors as well.Tess Rinearson  19:57  Yeah, totally. I mean, I've heard from Many friends in the US who have you know, who have kids of school aged kids. And it's, it's like a no win situation, as far as I can tell. So one thing you know, that, frankly is like, I guess, a sort of privilege in this, in this unusual circumstance is that we don't actually have anyone at my company who has school age kids. One person has like a, like a baby, but everyone else is like, pretty young and doesn't really have families. So that's another aspect of like transitioning and to sort of the like, you know, pandemic situation that we haven't had to deal with. So in a funny way, I think that's been kind of a kind of a privilege for my team. But, but yeah, it's made things a little bit easier.George Stocker  20:52  Yeah. Now, there was a recent, I think it was on the orange side. I think it was on Hacker News. But basically the founder of the orange site, you know, tweeted out, that, you know, effectively that in five years, you know, the person who comes into the office is going to be the person that gets promoted. And the people that stay remote are just basically not going to not gonna get promoted. And then of course, as usual on the internet, it bounces around some people think remote work is the way of the future other people think that Yeah, I know you're gonna have to be in person to get promoted, you know, or there'll be a healthy split. What's your view on you know what you see the trend towards his remote asynchronous work, where things are headed or is it really a stopgap and things will go back to in person as soon as the pandemic is over?Tess Rinearson  21:48  Yeah, I mean, I don't really want to make a prediction for the whole industry, but I bet a lot of teams will stay remote and I bet it will work for them. You know, I think the the one thing that is cool is that We all have learned how to work remotely now. And so, you know, even if that doesn't end up being like, the thing that everyone does, if it doesn't, even if it doesn't end up being the default, it's a skill, right? And we've, we've sort of like, across the industry, everyone has, like, practice that a little bit. And so my hope is that, that basically creates more flexibility and more options for for everyone, like both for you know, for for workers as well as for companies. So, yeah, I wouldn't I wouldn't say that I have a I'm definitely not on on the like remote work is the only future side of things. But I also think it like can work can work pretty well. And I think it will work for a lot of teams. SoGeorge Stocker  22:45  what has helped you as an engineering leader during this time, you know, communicate with your team and to keep your team's morale up and keeping them focused on the direction you're taking.Tess Rinearson  22:59  Yeah, So,we do,we do have regular meetings. And you know, we begin every team meeting with some time for people to just talk about, like, how they're doing, you know, what, what's on their mind what they did over the weekend. And, you know, that's something we've had been doing actually since before the pandemic started, but I think it's really useful in terms of kind of like, trying to foster some connection. We've also been experimenting with a number of sort of, like, remote. I don't want to say team building activities exactly, but just like, like opportunities for people to connect remotely as well. I'm not sure that any of those have been a slam dunk. We've tried a bunch of stuff. You know, we obviously tried the like zoom happy hour a couple times. We tried, doing like a cooking class together. We tried doing German lessons together. But But yeah, it's it's, it's it's tricky. And I don't have a great answer. I'm still experimenting and trying to figure out what the right way to connect people is.George Stocker  24:14  Yeah, I'm, I'm helping a client right now. freelancing for a client and they have monthly required happy hours. And it somehow doesn't feel like it doesn't feel as fun when it's a required happy hour, right? But it is something at least right, it's to it and they and before this, they were very much in person all the time. And so this has been a real shock to the organization. Everybody's handled it really well. But it's still a shock to the organization because you know, the organization's DNA was in person, and now everybody is forcibly removed. And so that that changes the dynamic. And you know, the first few months are really people adjusting to the new dynamic While you're in a pilot in a pandemic, which is difficult enough without the pandemic, Mm hmm.Tess Rinearson  25:07  Yeah, and one thing also that we have been aware of that, you know, I think our leadership team wasn't necessarily aware of at the beginning, but it became clear over time, was that there is, again, like almost like privilege associated with being in Europe rather than being in the us right now. And so we have people who are we have a few people who are in the US, like on the East Coast, and the most of the team is in Europe, and most of the team is in Berlin. And, you know, for a little while, people were like, Oh, you know, well, we can travel around Europe, which is technically true. I don't know if it's a great idea, but it's the future. We can travel around Europe or like we can meet up in person in Berlin. And this just, you know, when we started talking about it just seemed so unfair to the Americans. And yes, and the Americans are actually like, yeah, we're really unhappy. And we're really stressed out and like really sucks to see people on the other side of the Atlantic, like, going to the beach or whatever. So trying to have more sensitivity and awareness around that dynamic is something something we've done too. And so like Actually, we started planning you know, getting getting everyone together like our our operations person sort of started making some plans and I was like, Look, we can like talk about talk with you about this, but we cannot commit to anything until the borders open with us and people feel confident traveling, like, like we can put these plans in place, but like no one is committing to anything until we know the borders open. So yeah, it's been a new dynamic as well.George Stocker  26:47  Yeah, we in our area. Everyone wears masks, which is nice, because it's not true even if you go 45 minutes south of here. Yeah, it changes really quickly once you get outside of the That is Washington DC. But, you know, as a family, we've stayed home since March since mid March. And we went to one vacation, but it was to a remote isolated place that we normally go to. And we know well, and we know that we can quarantine ourselves there. But for the most part, there's a lot of anxiousness in the Americas about, you know, we want to do things that summer, we want to travel we want to, we want to be normal, and this won't let us be normal. And so there's a lot of built up. anger, resentment, a little bit of jealousy, about you know, other parts of the world where, hey, they did what they were supposed to and now everything's fine. We're not fine, but you know, it's close to fine. Yeah, where's here, you know, we're dealing with that plus, of course, the the the Black Lives Matter, protests against police brutality, which are long overdue for us to do something about For us to improve our justice system. And so you've got all that. And then you've got, of course, in the Americas it's election season. Yeah. And, you know, that is, you know, with all of these things coming together as a software developer, it's actually I hate to say this, but it's really hard to concentrate on building software right now. Mm hmm. So I'm glad you I'm glad you all have it, you know, a better but I understand that with the, with the regional differences. It's very tough as a leader.Tess Rinearson  28:35  Yeah, totally. I mean, I can even see so like, I'm probably obviously I'm American. And I actually only just moved to Berlin last year. But my team is really interesting mix of like, you know, Americans living abroad and then a bunch of Europeans. And it has even been interesting to see the difference in kind of like the, I don't want to say just stress level but kind of like general posture towards the world. Between The Europeans and the Americans. So it's not just like where you are in the world, but it's also like, you know, like, I'm worried about my friends and my family in the states I'm worried about, I'm very worried about the election, like, in my one on ones with every with every American on my team, I'm like, are you registered to vote? Do you know how you're getting your ballot remotely? Like, tell me what you're doing? Like, let's make sure that that you're ready for this. So yeah, I think you know, even even to be physically removed from the situation where we're feeling it too, in a way.George Stocker  29:29  Now, you, you as you said, You're an American, you moved to Berlin. You know, when you join a new company, they're every new Every company has its cultural differences, but now you're also an American, you're moving to Germany, and they're their cultural differences there. What was that experience? Like?Tess Rinearson  29:50  Yeah, so that's something I've been thinking about a lot. Not really, because it felt like a huge change for me. I mean it in a funny way, obviously. was moving abroad, that was a big transition, I was changing teams and changing. You know, a lot of a lot of change happened, obviously. But because I stayed in the same industry, I kept basically the same kind of role. And because my team is very international, and we have a lot of Americans and our working language in the office is English, and all these things like that. You know, and and also, frankly, because I came in, in a leadership position, and I could say, like, we're going to do things this way, you know, I could kind of set Not that I tried to be a dictator about anything, obviously, but like, you know, I can, I could definitely bring my preferences in my kind of American way of doing things to the table. Which has also been an interesting challenge in I'll give it go on a slight tangent here. But one thing we've been talking a lot about on my team. And partly honestly, in light of the Black Lives Matter protests in the US has been about being more hands on and like, like actively working on diversity and inclusion practices in our company and on our teams. Now, the interesting thing for me is that I think I was fairly, like, I would say, like fluent or competent with this subject in the US. You know, I, I built an engineering team that was headed had an equal gender split, I had some idea of, you know, what, like a racially diverse team should look like. And I had some avenues and organizations to work with to help make that happen on my team. I show up in Germany, and I'm like, I don't even know what a racially diverse team in a German context should look like. I mean, I know what a homogenous team might look like. But, you know, in the US, for example, there's a there's a big emphasis on black and Latino engineers specifically. And that doesn't necessarily make sense like in the German context, you know, like Like, like Latinos as an ethnic group or not, are not a big part of Germany. But there are a lot of people from the Middle East. There's a lot of people from Turkey, there's a lot of people from North Africa. And so like, even just like shifting my sense of what racial and ethnic diversity looks like, or what you should be, should be targeting has been a really interesting, kind of, like, cultural learning experience for me. And I'm still I still have so much to learn and honestly probably, like, all listen to this in a year and I'll be like, wow, I really had no idea what I was talking about, even then, like, I'm really at the beginning of my journey. But that's been been something that, you know, I kind of have to learn from scratch when I came here. Okay, so to go to go back, though, to your original question about sort of, like making the cultural leap. I've had a number of friends and other you know, other people in my network asked me like, you know, what's it like, and frankly, I know A lot of people who are looking at the situation in the US and they're like, maybe it's time to try living abroad for a while. So I think this is a is a is a question that's on a lot of people's minds. And one thing that I've been asked is like, you know, is it possible to come in as an American, maybe, especially as an American who's only worked in the Bay Area, which is true for me, basically, I come in and lead like an engineering team at a German company. And I think the answer depends so much on like, first of all, how open minded you are, you know, are you willing to like, try different things and like, learn some things from scratch, like the diversity stuff I mentioned, or even like, you know, hiring practices. You can bring a lot of stuff over but not everything. And then also, it depends a lot on whether or not the team you're joining is like, international or German. So like, I would say, My team is very international. Germans are a minority actually. But there are also teams They're like, you know, the founders are German most of the employees are German, the working language might be German. The way that people communicate even if you know you can speak English or speak the same language, like just the general level of enthusiasm or positivity is like, radically different, like a lot of Germans are like yeah, I've had to work with Americans and everything is awesome. Why is everything awesome? All the time for Americans so just like a different you know, there are just like differences in in communication and things like that, that come up. But I would say there are so many companies here and probably all over Europe that do have that really, really like international bent that are, I would say, like very, very accessible and very easy to to jump in on as an American.George Stocker  34:52  Cool. I have no experience in that so I have nothing to add there. But you going Back to you were your VP of engineering now you were an engineering manager previously. Mm hmm. What was the biggest part of that transition for you from just an engineering manager to now you're the VP of engineering?Tess Rinearson  35:12  Yeah. So, you know, I've had the VP of engineering title, a few places. And they've all been small. Right? So it's not I would say there's, there's definitely been a transition. And it's mostly been in kind of, like the scope of what I've been doing, but it's, it's not. It never felt like a huge leap. And I think for me, a lot of that also, is that the other engineering managers, you know, even if they are reporting to me, I really have worked with them as like partners, right? So, you know, maybe, maybe, I might like coach them through a few things. But typically, like I view them as Yeah, my partners and like leading the engineering org and kind of making decisions together. So I think that that is been sort of the, the way that I work as a VP. I'm trying to think what the biggest, I mean, yeah, the biggest difference really is just that, like, when I was responsible just for a single team, or maybe like two small teams, I was a little bit more hands on with like, the product or like, sometimes like specific engineering decisions, or like reviewing code or things like that. And in a VP role, I tend to be a little bit more oriented towards like, all of the engineering teams, right. So like, making sure thatyou know, like, our feedback structures across the whole orgareworking well and stable, making sure that like, you know, if there's a leveling system that's like fair being applied fairly, making sure that the recruiting processes are, again, fair, you know, being executed well, and kind of meeting everyone's needs. So it's like more of a that. Yeah, I would say the transition has been more about kind of taking more responsibility for just like a broader scope of things, which for better or for worse means being a little bit less hands on often with the like, nitty gritty details of certain, you know, engineering decisions or things like that. Interestingly, right now, I you know, I'm, I am the VP for interchange mbh. And so I do a lot of the stuff that I just described, sort of for the whole company. And actually, because interchange mbh is like 90% engineers, a lot of the stuff I do is actually really for like the whole company, not just the engineering teams. But But I'm also kind of like the the engineering lead for tenement core, this consensus algorithm. So, I do have to balance being as hands on as I can be with tenement core, as well as keeping an eye on the larger engineering team, which is a tricky balance, I would say I'm still, I'm still learning how to make that work.George Stocker  38:07  How often are you able to open up your ID and commit code?Tess Rinearson  38:14  Really, it really depends on like everything else that's going on, right? And like where we are kind of in the development cycle. And so the the reality is that that's almost always going to be like the lowest priority thing. Because there's always going to be someone who can someone else who can do it and probably someone else who can do it better. Right? So So it varies widely at this point, because we've been kind of in the middle of like really trying to get like a release out the door and I've been doing a lot of planning and a lot of talking to people. It's been a while since I committed any any real code, but I do I do spend, try to spend a decent amount of time doing code review and just like keeping keeping an eye on things and trying to Help out.George Stocker  39:01  I had a pure mentor. Back when I was a solutions architect, I had a peer mentor, who said to me, you know, optimize for, optimize and do the things that only you can do and delegate everything else. And which meant, of course, that No, I didn't push production code, like, I was needed in the strategy meetings, I was needed in the design meetings. Right, I didn't get a chance to do the things that actually produce software, but the things I do were necessary to produce software. As an engineering leader, you know, what's your, what's your version of that? Yeah, ITess Rinearson  39:41  would say very much the same. You know, and I think, actually, like, so. So one thing that I think hasn't been mentioned on this podcast is that interchanging mbh is actually like a really young company. So it's actually only founded in February. And it's a funny situation. This is the kind of thing that you can do. In the blockchain space, I mentioned earlier like there's often an unusual funding model. So one thing that can happen and happens somewhat frequently in the blockchain space is that like product or engineering teams can like detach from one company and then like, go to another one, or or start their own. And so that's actually what happened in this case where we had been working for the tenement core team had been working for a different company that had started the tender mint core project and and fostered it for a long time. And then they kind of wanted to like move in a different direction and do some different stuff with their product and their work. And we were like, you know, what it's like would be better to just have a place where we can really focus just on this core technology. And so we so we floated over. And the funny thing is that because of that, we've been in the process of like, like rebuilding a lot of our processes, and things like that. And so kind of sense that transition happens. You know, a lot of my work has been around. Yeah. Again, like rebuilding a hiring process, rebuilding feedback systems, things like that. And so my hope, when I anticipate is that as that stuff sort of starts to settle, I'll have a little bit more bandwidth to like, get back into tender mint, you know, tender mint engineering, and that project. But yeah, a lot of what I've been focused on lately has been like, like hiring and like, yeah, we just we just went through our first like feedback cycle as a team, which was, which I think was fun. A lot of people were like, I've never gotten formal feedback before. This is really cool. This like, validates a lot of things that I thought were probably true about myself, but I wasn't sure. So yeah, I think I think once a lot of that stuff kind of settles. My hope is that I'll get back into touching the code a little bit more.George Stocker  42:00  Now your, your feedback process. Is it a 360 feedback? What does it look like?Tess Rinearson  42:05  Yeah, it's a 360 feedback process. And I like it's the same process I ran at chain and Interstellar. Actually, I just brought it over wholesale. And I had copied that from someone else. Someone that the former think former VP at nihlus had walked me through it was really like, he like gave it to me. I've sort of been adopting it and tweaking it ever since. So it's kind of this this process that I think is like floated around to startups for a little while, but it's a 360 process. People sort of like nominate people who they think are their peers to write them peer reviews and then managers compile the feedback. And they also like write reviews, other managers. And so managers get feedback from their direct reports. But that feedback from the direct reports is like compiled by, you know, another person who can kind of Qt is like a filter, like help anonymize anything that might be sensitive. And the interesting thing about this feedback process, the thing that I think is really important is that we've really directly explicitly decoupled this feedback from any kind of like compensation or leveling. Like we're like, okay, the goal of this process is for you to learn to literally just get feedback from your teammates, on how you can grow and how you can be better. And we want to incentivize people to be as as honest as possible. And we know that you all like each other, respect each other want to help each other out. So if I say, you know, hey, go write a review of your teammate. Oh, and by the way, if it's too negative, like they're not going to get a promotion, like no one's going to be give the constructive feedback in that environment. So we really like narrowed the scope of sort of like what we're trying to achieve with this feedback process. And we were like, Look, this is Just like to get, you know, personal feedback for your own professional development. And we're not going to use this as a management team to decide like, if you're getting promoted, or like what level you are or anything like that.George Stocker  44:13  That's wonderful. I like now that you say it, it seems like Yeah, everybody should be doing that. But they don't. What so what how do you determine leveling? How do you determine compensation increases?Tess Rinearson  44:27  Yeah. That is one of the things to spend a little bit honestly like a little bit tricky with a new company, because you're like, yeah, I kind of had a blank slate. We'd do get our funding from a Swiss foundation. I'm laughing just because I know it sounds like complicated and like I keep introducing pieces to this picture. But again, blockchain companies all kinds of funny stuff happens. All of our funding comes from a Swiss Foundation, which is called the interchain Foundation. And they have a model that they recommend for compensation. They have people in teams all over the world. And so they sort of, you know, it's combination of like, people's level, their role, the cost of living piece, which I know is like a really hot subject right now, with so many people being remote and moving around, but they do have like a cost of living multiplier in there, kind of like calculator. And so they recommend that we use that and we more or less follow that, that doesn't answer the leveling question. We have a ladder that again, I like, borrowed from my previous company, which I'd like in turn kind of borrowed and adapted from like another engineering leader. So again, one of those things that I think is kind of like floated around a number of startups and and kind of gets adapted and tweaked to everyone's use cases. So we've used that as like a rough a rough guide to get a sense of where people are Or should be. And the one thing that I would say is interesting about that is there's pretty heavy emphasis on how you. Like, if you're just a really great engineer, like a really great programmer, you can only get so far, you really have to be a great like team player and help level the people up around you and ultimately help level the whole company up, if you want to, like proceed all the way through that that leveling system. So that's kind of the one thing that I would say is kind of interesting there. But yeah, so we have we have like a rough a rough leveling system, combined with this, like standardized kind of calculator, I suppose. From our funding organization.George Stocker  46:41  I'm really gratified to hear that because in tech, the idea of the core skills, new Essential Skills being as important if not more important, than the technical skills, you know that that transition is still happening where we're, we're coming from the old school programmer, good old boy network of if you're a technical hacker in your basement, then you're fine to know you actually have to be able to handle other people and to work together to build software that has a has a good outcome. And so I'm really glad gratified to hear that. That's the approach you're taking.Tess Rinearson  47:16  I mean, I think it's especially important for blockchain companies and open source projects. And we obviously are both, because again, we have so many other teams that we're working with potential contributors. You know, like, if you're on like, every one of my team has to be good at collaborating and like, giving code reviews to or helping out, you know, external contributors who maybe they've never spoken to before. They don't know anything about maybe there's even like a language barrier. And so, you know, in order to be a successful engineer on my team, you really have to have really great collaboration skills and honestly like a lot of empathy for the people you might be working with again, even if you like never see them or To them outside of GitHub.George Stocker  48:02  Yeah, you worked at on the subject of you know where you're at today you worked at both valve and Microsoft as an intern. Now, what sort of impacted to working at those well established companies and valve with its, you know, internet famous handbook. What? How did that have an impact on you and where you are today?Tess Rinearson  48:24  Yeah, the, I think valve particularly had a had an impact on me. That was like my first real job. So I had nothing to compare it to. Right. And after, after I after I left after my internship ended, people would be like, what was it like? And I was like, it's just like, how you work like, I had never seen anything else. And what became clear to me and I could kind of see this at the time, but it became clear over time, was that, you know, in order to make that particular culture and that particular work style work for them, they really sacrificed a lot of other things. So Like hiring was really hard. I remember, you know, as an intern, I was not on any interview loops, obviously, but I would remember my whole team, like going out for interviews constantly felt like every week, there were like, multiple interviews happening. And I don't think they made that many offers. Because when you have a really, you know, when you have a culture where everyone has to be really, really self directed, you can only select for those people, that's a hard thing to select for in an interview. The cost of a false positive is like pretty high when you're when you have that kind of culture. So like, it's like hiring was was I think was pretty hard for them. And not for any shortage of like interested or smart people, right? They just were had a really particular kind of person they needed to hire. You know, I think sort of in the same vein, like the the workforce wasn't particularly diverse. And you know, at the time I didn't really like, understand why that was not ideal. But as I've learned more about, you know, why, why diversity inclusion are important. And, and honestly, like, as a woman engineer, you know, becoming more aware of what that means. It's, that's become more more important to me too. So anyway, the thing I would say that I learned there is that like, you can have a really particular culture. And you will ultimately you will find people who work and fit well in that in that culture. But you're going to like, like, the farther you deviate from the norm, the higher the cost you're going to pay is, you know, in a sense, that's like, one of the things that you're building and experimenting with is your culture. And so it's like, do you want to spend kind of like, like product energy, or like, like innovation tokens on that cultural piece? Or do you want to reserve that for like your actual product? And I'd say it's a mix, like I like I work in a situation now where we spend a lot of innovation tokens on like an unusual org structure, right? We've got this thing with the Was foundation. All of these other like sister teams that we work with, it's like an unusual thing. We spent a lot of time figuring out how to make that work. I think it's worth it. But and I think probably for valve like their their culture is is worth it. But it really did give me a sense of the kinds of trade offs you can make with your with your culture.George Stocker  51:21  And the innovation token that is from a blog post that I seem to remember, well, there's my guessTess Rinearson  51:27  that is a blog post from a blog post by Dan McKinley. And I think about it a lot. I got innovation tokens a lot. It's one of my like, it's like a kind of like a mental tool that I break out a lot. And, you know, sometimes if we're thinking about like, adopting a new technology or like adapting a future or like,you know, writing our owncivilization serialization format, or whatever it's like, is this what we want to spend an innovation token on? Just doing that little check has been like really, really, really helpful for me, and really helpful for my team, I think.George Stocker  52:07  And the idea is that you only get so many innovation tokens and you know, spending them immediately, you know, you lose that innovation token and now you have fewer to innovate with. And your goal should always be to not innovate, but use what's tried and true where you can. Yeah,Tess Rinearson  52:26  or just like, be really deliberate about it. Right? Like basically, I would say the thesis is you want to recognize that doing anything that is innovative, or unusual or different, is going to cost you more mental cycles, more energy as a team to figure out how to make that work and how to like blaze the trail there. And yeah, just be like, be thoughtful about what you choose to do that with.George Stocker  52:50  Now Tess, in our in our closing moments, if people want to learn more about you and about what you do, where can they go?Tess Rinearson  52:57  Yeah, so my Twitter Is underscore tests are someone else got tests are first. So I have the underscore in front. And our company website is interchange dot Berlin.And the most interesting link of all, I think is our GitHub repo, which is at tender mint slash tender mint. So that's where I think the most interesting stuff is, is in there. George Stocker  53:24  Awesome Tess. Thank you for joining me today. Tess Rinearson  53:27  Thank you so much. This was this was super fun, and I had a great time. George Stocker  53:30  I enjoyed it. Alright, folks, that's it for this time on the build better software podcast. I'll hope you join me next time. Bye.Transcribed by https://otter.ai

Bruce's site:https://productculture.orgBruce's book:Product Roadmaps RelaunchedThe product Scorecard: https://walkerux.wordpress.com/2017/08/21/notes-on-bruce-mccarthys-prioritizing-product-goals/Transcript (powered by Otter.ai; please let me know about any discrepancies!)George Stocker  0:00  Hello, I'm George Stocker, and this is the build better software podcast. Today we're talking about product roadmaps with Bruce McCarthy. Bruce, welcome to the show.Bruce Mccarthy  0:09  Thanks, George. Nice to be here.George Stocker  0:11  Now for people who may not know who you are or what you do. Can you tell us a little bit about yourself and your work?Bruce Mccarthy  0:17  Sure. The way I always introduce myself is I'm a Product guy. I've been a product manager, Chief Product officer, an engineering manager, a design manager, business development, guy marketing, sales. I've done all these different things, agile, enablement, and whatever. But I always come back to my roots as a product guy. I like building stuff. I like solving problems. I like getting the team together and working on Alright, how are we going to tackle this folks? How are we going to make things better for the customer and for the business? So I always kind of go back to that product leadership kind of role and these days For the past seven or eight years, I really been teaching and workshopping and coaching teams how to do that stuff. After a long career of being fairly successful at it myself, I felt like I had learned the ingredients and how they fit together properly. And so I do workshops, public ones that you can buy tickets to, and private ones for companies. And I have a forum for invitation only for Chief Product officers where we get together and workshop each other's challenges. And I do consulting and speaking at conferences and things like that. I also wrote a book that I think you've seen called product roadmaps relaunched, and how to set direction while embracing uncertainty came out from O'Reilly a couple years ago, and it's become kind of the standard, the standard book on product roadmapping.George Stocker  1:58  And you brought up solving problems from customers. And I'm glad you brought that up. Because at least in my career, when I've seen product roadmaps they have, well, we need these particular features at this particular time to grow. And you know, this particular outcome, and it was laid out in a calendar fashion with exactly what features the product team needed to build and what they needed to do. How does how you view a roadmap differ from that?Bruce Mccarthy  2:23  Well, I kind of think that that, in my mind, old fashioned view of a roadmap gets teams into trouble a lot. Number one, it gets them into trouble in terms of broken promises. They are constantly finding that their dates were over optimistic and so they're constantly feeling behind. Also, those kind of optimistic roadmaps don't take into account. stuff you got to do to keep the old things the things the features you shipped last year still working for clients and updated and free of killer p one bugs and so on. And it doesn't take into account shifting priorities because you might make up a roadmap at a point in time, say just before the sales kickoff in January of a given year. And it might go for a whole year or even longer. But your process as a product person of learning what's going on in the market doesn't stop an end there. Even if you've done a ton of research, and you think you know exactly what's right on January 10. of that year, on January 11. Someone's going to come to you with some new information. And you're going to be like, Huh, I wonder if that really should change our priorities? And maybe on January 11, you're not sure yet. But by February 10, you're probably like, Yeah, yep. You know, that thing we were thinking about for the end of the year. It no longer seems as important as this other thing that's just clearly becoming a theme among our customers, or you got to respond to competitive pressures. are new and unpredictable. So this idea of committing in advance to exactly what features we're building on what dates is kind of a doomed effort, because you're going to change your mind and you're going to find that some things take longer than you expected them to. So my approach to roadmaps is to admit that upfront, and to have a regular process of updating the roadmap every month or every quarter with the latest information, and to say upfront, this is not a commitment. In fact, our confidence in anything beyond this quarter is increasingly low. Some teams I work with actually publish a percentage of confidence on each item and the roadmap or each timeframe in the roadmap say quarters or something like that. That goes down to something like you know, four quarters out, it goes down to like, we're 20% confidence that that this is actually what we're going to be shipping at that point. time. But there's one more critical point that I really want to hit on aside from unpredictability. And that is that most roadmaps, forgetting just about the time commitments. They are, as you said, a list of features. There are a list of things we plan to ship changes we plan to make, and those commitments to features and changes and tweaks and redesigns or whatever, are made well in advance of actually opening up the code and digging into it, or testing the idea with customers or producing a design and seeing if it works. And those commitments are made really prematurely. If you've got a problem to solve and you think you've got a good idea for a feature to solve that problem for the customer, like make them more productive or, or something like that. You really can't know in advance whether That feature will effectively solve that problem or whether that feature is the best way to solve that problem. You can measure it after the fact. But what if it turns out that you were wrong? What if you ship feature x? Because you're sure that it's going to raise your conversion rate or your retention rate or something like that? And you find out, it doesn't actually do that at all, or it does it but not half as much as you need to meet your business goals. What are you going to do? You're going to go back to the drawing board and come up with another feature, or another idea. And if it's six months before you ship that, well, that's a really slow way to improve your business, right. So instead, the in the book I described a different way to approach the core content of a roadmap rather than being features. The core content tend to have a roadmap is problems, problems to solve or customer needs that are Currently unfulfilled or under fulfilled. And so, you know, you would actually put on the roadmap productivity, customer productivity or some more specific example like that like something you could measure, like increasing their outputGeorge Stocker  7:17  conversion rate for checkout or,Bruce Mccarthy  7:21  yeah, if it were an e commerce site, for example, that's a good example. For e commerce websites, one of their biggest bane of their existence is abandoned carts. People pick out a product, put it into their shopping cart, and then never check out. And it's hard to know why. But if let's say that was the problem you're trying to solve is low checkout rates or abandoned cart rates that are too high. Well, there are a variety of things that you might try to fix that problem. Maybe the problem is, your checkout process is too confusing. And so you might read design it. Or maybe it's too long, there's just too many steps and people get tired and they abandon partway through. Or maybe it's not the design at all, maybe you just don't accept the credit card they have in their pocket. And the real problem is you need to accept American Express as well as MasterCard and Visa, or Apple Pay or whatever. Or maybe the problem is that they don't find out about the shipping charges until late in the game, and the shipping charges are much higher than they expected. wherever they are, or maybe it it's, you know, the list goes on and on and on. And any one of those is a reasonable guess. And any one of those might have a small incremental effect on your conversion rate, your checkout rate. But rather than put all of those are some of those and try to guess ahead of time, which ones are really going to work on my roadmap. I'm just going to put increase the checkout rate or decrease the cart, abandon And then rate, and I'm going to have maybe a list of things to test. And that that list of things to test is not a commitment to features and dates. It's a commitment to solve the problem. And these are the things we're going to start trying and prototyping rather than shipping to see what actually makes a difference in simulated situations until we can figure out which of those 10 ideas that I just rattled off, maybe three of them are really highly leveraged, let's focus on them. Now, when I'm putting this item of improving the checkout rate, on the roadmap, it could be nine months before we even start the research process to figure out which of those 10 ideas is the right one. So why am I going to put any of them on the roadmap at this point? I just don't know. And it's foolish of me. It's misleading, kind of fooling myself and it's misleading my audience about my certainty about what's the right thing to do them Makes sense?George Stocker  10:01  It does. And what jumps to mind immediately is that leadership tends to be released from leaders that I've interacted with. It tends to be about projecting confidence and projecting certainty. But it sounds like your roadmap process focuses on accepting the uncertainty of product development. How do you get leaders? And how do you get product teams? We're used to the old way to adopt this way. Now, where you say, hey, the emperor has no clothes, and everybody can see it. Everybody knows it. Yeah. How do you help teams make that change?Bruce Mccarthy  10:37  Well, the thing that I see with with leaders is, they are used to extracting commitments from their people in order to get things done especially this is true and to a degree of executives at many, many companies, but it's particularly true at early stage companies that are founder led where they're used to To extracting commitments and what they call high integrity commitments, right? You've heard those words probably. And they really are going to hold you to those commitments because they're trying to do way too many things. They're trying to do it all on a shoestring and they're trying to bootstrap this thing. And it's generally worked for them to put the pressure on people, and you can't change that tendency to want to hold people accountable for for what they commit to in a personality like that, nor should you try because a it's doomed and B. That's what got companies from zero to one, you know, that's what got the that's what got these people into a position of authority in a company. And so let's go with that instead of trying to fight it and the way I go with that, is gradually to get there trust that I can be held accountable for results rather than Then for specific features and dates, if I can convince them that if I get asked, and this happens all the time, right, for a specific feature, and when Can I have it? I can answer the question, but then I can answer it with this is the this is the real skill of a product manager, I can answer it, answer it with another question. Okay. Yeah, we could probably do that. But tell me if we do that. What is the hoped for result? What is the desired outcome from this particular output that you're asking for? Now, sometimes, from an executive, you'll get lack of patience. I don't have time to get into it, just do it. That's not a good answer. If you get that you still want to come back and say, Well, I want to make sure that we design this thing correctly in order to meet the needs. Yeah, I know, you told me this thing. And maybe it seems fairly simple, but there's 1000 little decisions that are Gonna go into the implementation. And if I can get just even 20 minutes of clarity right now even five minutes of clarity right now on the desired result, we can make sure that we're building the thing you actually want. Okay, so you've sold me on the idea that I can spend five minutes now and explain to you that if we do this, and the customer does that, then this will result in that this other thing for the company, we think, and as you say, an executive of that type will project confidence that this will definitely work. And then your analytical brain, whether you're a product manager, or an engineering manager, or a designer should come into play, and you should see if you can start playing out alternate scenarios, not just not to poke holes in the plan, because that'll just make them defensive, but to suggest alternatives. Well, what if we could get the same result quicker and easier with x y Instead, you know what if instead of redesigning the whole checkout flow, we just added American Express or consolidated, the two slowest steps, you know, as an incremental thing as an experiment to see if that actually improves the numbers. And then you can, then what you've set up as a conversation where you are together trying to cooperate on evaluating alternative solutions to the problem. And then maybe, maybe that person's mind is opened up to the idea that there might be two or three or four or many possible solutions to the problem. And even if you can't get them to stick with you through all of that, you've set the stage that the real. The real goal is to change the customer behavior and change the financial results for the company. And if you know exactly how to manage That will then just as good practice, you go back to the drawing board, and you say to your team, okay, we've been asked to to redesign the checkout flow to increase throughput to increase conversion rate. How can we test this idea and validate whether it's actually going to get the result that we want before spending months doing the work? Can we get some users in and do some mock ups? do some tests of mock ups and stuff like that? And see, what happens? Can we build a micro site and then in a totally non scalable way and do an A B test?and just see what happens and then when you come back to that executive and say, so that thing where you wanted us to redesign the checkout flow? Well, we tried these three different options and because we're, we're always optimizing for the conversion rate, right? And we found that this alternative, which is turns out is no different than we realize. Thought is actually the best way to increase our conversion rate. Because you had the conversation about what's the real goal, because even you had to have an uncomfortable moment where you were pushing to get clarity on the desired goal. You've set up that later conversation about what's really going to get you the desired goal. And so if you're always trying to even on the roadmap, wrap, the project stuff in the product stuff, the the the wrap the output in the desired outcome. Then gradually, you get leverage and trust in those conversations that you are thinking, like they want you to think and as a responsible steward of the resources.George Stocker  16:54  With the roadmap, we've talked a little bit about how it's set up, and how there are outcomes on the roadmap. And what you're looking to test during here, timeframes. Is it now near and later, is it quarter? next quarter? How is that set up? And then what else is part of the roadmap that you put together?Bruce Mccarthy  17:15  Yeah, so you got to have some kind of time buckets, even if you said it's now next and later, just really broad, no dates, kind of buckets. And you've got to have the problem oriented themes that we discussed. And you've also got a for an internal roadmap, you've got to have those business objectives like, Okay, if we do this, what does that mean for the company? And I don't mean that you need to make a sales projection, but I do mean that you need to say the objective here is to increase the conversion rate. And if we can raise it by two points, then here's what the result might be. Or maybe the objective is, for a SaaS business renewal rates. We want to improve those So you want to build those business objectives? The reason why from the, from the point of view of the people who are funding this effort, right into the roadmap, I even there's an example in the book where this company actually gave a percentage of the resources that were placed against each different business objective. so that they could sort of take a portfolio view of what they were working on. CFOs love that kind of that kind of analysis. So business objectives, problems to solve, rather than features, timeframes. And I think it's all got to start with a vision of the value that your entire effort your entire product, your entire program to produce this product is aiming for, for the customer. Maybe it incorporates a piece of the business side to like, we want to we Want to make security foolproof for enterprises? And that's a, you know, hundred billion dollar market. So we want to be the number one vendor in that space. I don't love the we want toGeorge Stocker  19:16  that's the big hairy audacious goal,Bruce Mccarthy  19:19  right A B hag for the product. And I like it to focus mostly on the benefit to the customer, like making security foolproof, or providing, you know, a better, faster, easier something for the customer and a little piece of a little dash of what's our differentiator Why Why should you consider us? It's like a Actually, it's really like a boiled down version of your value proposition as a product. It names the customer, the benefit to the customer and the differentiator. That should be like at the top of the page. If you have a roadmap like many do that's a timeline or it's a grid with hopefully not features, maybe themes, products. have problems to solve and timeframes. Above all of that is. And if we achieve if we do all of these things, here's the result. Here's where we're solving for this. As the constant Northstar reminder of why we're here. Though, all of those things are four out of the five components, I think that you must have in a roadmap. The fifth one is the disclaimer. Now, maybe that sounds like a while, of course, you know, sure. You gotta have weasel words down the bottom right? You gotta have the Safe Harbor statement. But I actually really like to lean on that when I'm talking to customers in particular, but any stakeholder pointed out and say, not only is the roadmap subject to change, but it is highly likely to change. It is a constantly evolving document, it is likely to change and one of the ways that it can change is if in this discussion, you convince me of certain things that I didn't know or wasn't really Thinking about you give me new information that changes my priorities or informs my strategy. Well, why wouldn't I change my roadmap? I should, I should change as a responsible product person trying to do the best thing for the customer and the company, I need to take advantage of that new information incorporated into my plan and publish it in the next iteration of the roadmap. There's sort of a, this sort of one other piece. It's not a component of the roadmap, but it's a component of the road mapping process. And that's the update. I think a lot of people forget this, that kind of like the roadmap is the thing we do in either the end of the year or the beginning of the year. And then we forget about it until the end of the year when we have to make a new one. And we pretty much ignore the old one because we didn't do any of that. And instead, what I want is to republish an updated version of the roadmap really regularly I have a friend Sam Clemens, who was head of product at a company called insight squared in Boston for many years. And the way he did it was, it was a quarterly roadmap with percentages of percentages of confidence going out for quarters. The confidence level for the last quarter was like 25%. And he published it in a one page document that the sales team was encouraged to pin up in their cube. So that when someone asked, Is there, is it on the roadmap, they could answer the question, along with the disclaimer. But here's the thing, it was a quarterly roadmap, but he updated it every month. He sent out a fresh version of it with an annotation of all the changes and explanation of all the changes and why all those changes were made every month. And you know, a lot of some of them were things like well, this has taken longer than we thought. Others were like, We tested this idea and it doesn't work and so what We're taking it off the roadmap, and we're putting on something that we think will work based on what we learned. Or we're reprioritizing, we're taking based on signal from customers, this thing that was four quarters out, we think is far more important. And so we've moved it up to next quarter and swapped out some other things to make room for it. And when you're that sort of radically transparent about the changes to the roadmap, it I think, begins to increase confidence that you are constantly updating your thinking based on the latest evidence of what's going on, with customers and in the marketplace, and what's the best thing to be doing, and you train all of your stakeholders to expect it. It's not, oh, the roadmap changed what went wrong. It's like, Oh, great, updated version of the roadmap. This is awesome.George Stocker  23:51  So that brings to when the roadmap changes in an established marketplace, there are competitors and then those competitors have features, how do you guard against, we have to have this feature because our competitor has this feature.Bruce Mccarthy  24:07  Right? Um, honestly, the fastest way to commoditizing your product and losing all of your margin is a feature war. You don't want to get into that situation where it's just me to feature after me to feature. That way, all the products eventually become the same, and there's no differentiation and the only thing you have less left to compete on is price. And that's where all your margin disappears. So why would you want to get into that situation? You wouldn't. So instead, what you want to do is figure out how you differentiate how you have something that a nobody else has, and B is difficult for them to duplicate so that they can't have it next quarter. And C is something that speaks to particularly to your segment of the market. So, if you if you want to have a red ocean strategy, referencing that book where you and a couple of other behemoths are just slugging it out continuously over the same customer, then Okay, you're stuck in a feature war and eventually a price war. And honestly, that that kind of that kind of situation is no fun. Instead, you can carve out a niche. Maybe it's big, maybe it's small, but one that you are uniquely able to serve and where you are the obvious answer to the customer's unique problem. You know, amazon.com is the answer to most commodity purchases right now if they're not super perishable, right? So why am I am I going to try to compete compete with them on selling books or going into the video streaming business? No, I'm not going to do that. But There are lots of products where Yeah, they sell them. But they aren't the best way to get the best version of that product out of them could could they get into the selling business of selling cars? Well, they could. But I'm not sure they'd be very successful because people want to touch and feel and test drive a car first. So that's not going to be a real great way to compete. I'll give you another example. Much more recent. Did you see that the guys that Basecamp came out with a new product called Hey, I did it's a, it's an email service. And you think, Oh my god, they're gonna try to compete with Gmail and outlook. That's crazy. Why would anybody do that? Those guys are enormous. But those products are commodities and they're mostly interchangeable and they're mostly free. Hey, has a subscription price and not a cheap one. It's like 30 bucks. A month. So it's a premium subscription price for a consumer to pay for themselves. How does that make any sense? Well, they're not expecting to have the number of users that Gmail has. And they're not expecting to have the profile of the typical Gmail user. They're expecting to have somebody who is very addicted to email but wants to be super productive on it. And who buys into their very opinionated way that we should manage our workflow. If you really like the way Hayes workflow works, it's the only tool of its type. And so it's the only option for you they have in that sense for that particular user, if they can identify them, they have no competition at all. There's another there's a sort of competitor called superhuman, which you may also have heard of, that's also a subscription based email client, butGeorge Stocker  27:59  they work on top of Gmail don't think they did or not their own email provider.Bruce Mccarthy  28:03  That's right, hey, actually, because they wanted to really take control of the whole stack and the whole experience, you would get a Hey, calm email address, whereas with superhuman, it's whatever email address you have on top of Gmail. And so they just exist at that layer. And they're strictly about throughput and focus in the interface, whereas hay is much more about filtering out noise, and bucketing things in a very, very opinionated way that they think is the right way to do it. You know how you can set up rules in Gmail to put things into folders? And at some point, every nerd like spends all day one day making all these little folders and rules and stuff like that. I know I did. But, hey, doesn't allow you to do that. They just have three buckets. Well, four if you count the no you can't email me bucket. And you can't configure them. So you either love it, in which case, it's very low effort for you, or it doesn't fit. And you're going to go check out to superhuman, or you're going to go back to Gmail,George Stocker  29:11  in the case of superhuman versus Hey, since superhuman exists on top of Gmail, they're dependent upon Gmail for their livelihood at gmail subsequently could copy their features tomorrow, but they could copy their features and they could send them out of business. Whereas Hey, it sounds like a tougher proposition for any competitor.Bruce Mccarthy  29:30  Exactly right. Gmail could copy their features. It could also turn off their API or their forwarding or whatever it is that superhuman uses. And then superhuman would be out of business overnight.George Stocker  29:45  Now, in my time on a product team, I've generally dealt with three or four interest groups in any product or product management folks, the sales folks versus the engineering team. Then of course, you've got the board of directors, you have upper management, and they all have different things that we're worried about. Engineering groups are worried about keeping the lights on and making sure things can actually be done. The sales group needs to meet their quotas. Upper management's looking at the health of the company writ large, and products is sitting there trying to hold it all together. Now, if there's just one group that had to adopt change for roadmaps, that would be tough enough. Now you've got four groups you're dealing with, when you're introducing your process into an organization.Bruce Mccarthy  30:25  Oh, and it's worse than that. A lot of organizations, they also have marketing and partnerships and channel sales. And maybe they have to deal with external analysts and technology partners. And maybe they have enterprise customers who are used to having input on the roadmap, the list goes on and on and on. Finance also usually has a voice and in the roadmap, the list of potential stakeholders is quite lengthy. And there's a there's a big challenge. There, I find that the way to approach that is a couple of things. One is, at the highest level, at the simplest level, everybody should be hearing the same story about how this all fits together and how we all succeed together, everybody should understand the product vision that we described how a future world will benefit from the existence of this product or the success of this product, and how it serves the overall company mission. If those are different if it's a big enough company to have multiple products. Everybody should understand what problems are we trying to solve in order to achieve that what business results should we expect if we do achieve that? And that the timeframes and the disclaimer so the first you know, few slides of your PowerPoint presentation, if that's the form your roadmap is in should be the same for absolutely everybody. You don't want to have 14 different roadmap For all your different stakeholders, but within that deck, each different stakeholder like that kind of wants their own drill down into their own worries into their own concerns. So sales wants to know when am I going to be able to sell XYZ. And so for things that are close enough to delivery that you actually can give them a feature and a date, you should have that information, either in a delivery plan or on slide number four. And for engineering that wants a deeper dive into the features that are not yet being worked on, but are maybe on deck, if you will, up next. You should have a slide for what are the possible features under each theme that you'd like to discuss and go through the investigation and research process with engineering on but you don't show those that slide to anybody outside of that. Engineering, because it's all completely unbaked. At that point for, for investors, you know, you might have not revenue projections, but hope we might focus on the business objectives for the marketing team you might talk about, well, what sorts of things might you be able to demo at the next conference? Or should they be ramping up a campaign for in the fall or something like that. So for each one, you can imagine a deck that starts off with the same three slides for everybody that tells the high level story and then has seven or eight more slides one or two for each other stakeholder group, that give them just the information that they need. And then just having a roadmap is not enough. You've actually got to involve all those stakeholders in your process. If you want the buy in that you're looking for. You've actually got to go to talk to those stakeholders, not when you're done with the roadmap. But when you're in the beginning to middle stages of developing it, so that my favorite words are, hey, I'm working on my roadmap, and I need your input. Can you help me and being asked to help and give input early in the process is super flattering for those folks. And it makes them feel like they got inside access, and it makes them feel like they're helping you and you're helping them and you're collaborating on this. And even if you say no to them on some things, they feel like you gave them the opportunity to be heard at the right time and place. And so they end up feeling a sort of a sense of authorship, co authorship of the result. And I would do that as informally as you can don't like schedule a meeting and have a review of the roadmap and ask for their sign off. If if you're in an office with them, hang out at the coffee machine. Wait till they come by and say Hey, you got a minute, I want to I just, I'm working on this and I need your need your help. If you can't do that, slack them and ask them for five minutes, you know, and rather thanrather than try to make it super formal. And then when you do have the formal meeting where it's like the roadmap review, instead of them, like, trying to show how smart they are, but poking holes in a roadmap, they're trying to take credit for how great and insightful the roadmap is, because they see their fingerprints on it.George Stocker  35:32  Now I had the privilege to be a part of one of your sessions. I don't remember if it was a two or three day roadmap engagement, where you came in to help us develop a roadmap at a previous employer. But for everyone who is not aware of what this process is, like, if a team wanted to call you in and say, Hey, Bruce, could you help us out? We need to produce a roadmap. What is your engagement look like?Bruce Mccarthy  35:52  Well, first I do public roadmap workshops that are these four sort of four days have to Our sessions, but then we, we have people from all different companies and we use a made up product. And we put them in teams and I deliberately, even if there are multiple people from one company, I deliberately split them up, put them into teams, and we have a lot of fun with it that way. But if I'm, if I'm on the occasion that I'm working with a single company, and they're trying to produce their real roadmap, it takes a little longer. And so it's usually a several days process. And we get the key stakeholders into a room for several days, we get the folks from sales, we get the folks from engineering, we get the folks from marketing, maybe design as well as product, sometimes in the right size company will have the CEO in the room the whole time, or for strategic parts of it. And the whole idea is to get us all on the same page about those major components. What is the vision What does success look like? What are the business objectives? What problems do we need to solve? How do we prioritize this stuff? You remember from our engagement, we were like all writing lots of white yellow stickies, putting them on a wall, and arranging them seeing where the common themes played out and debating the priority of things based on how leveraged we thought they would be for the results we were trying to get. One particular technique that I like, in that kind of workshopping situation, is to sort of crowdsource the ideas and not let any one voice really dominate the conversation. Because often there's, you know, a few people who have very verbally dominant sort of behavior, you know, often they're in sales or they're the CEO or something like that. And then there's other people may be an engineering or design who are more thoughtful and introspective and they won't just blurt out The first thing that they're thinking, so to level that playing field, so that we get all those ideas on the table, because all of them are useful is I have people first write stuff down silently without talking to each other, so that we get everything on the table without anybody getting shouted down. Then we put all put all those stickies together. And we we look at them together without anybody's name on anything. And that tends to get a better result that sometimes you'll be like. Like, you'll have two or three stickies of ideas of how to solve a problem that at first blush, to maybe the to the CEO, or the head of sales makes zero sense. They seem to be coming completely out of left field. But then when you ask for an explanation, you discover that there's a really clever idea there that nobody else thought of, and that one bounced off of some of the other ideas. begins to really become a promising direction. And those nuggets aren't going to happen. If you don't, if you don't crowdsource like that.George Stocker  39:08  We've talked a lot about product teams. And your advice seems especially centered towards product teams, what can non product software teams that maybe work on internal software, or teams that work in services based business with software? What can they take away from your process?Bruce Mccarthy  39:25  I think a lot of these principles, although they were developed with software product teams apply broadly across businesses. I'll give you an example. I did a version of this workshop, a half day version of this workshop for a company in New Zealand, and it was just for their for their marketing team really, but they got all termed up about the method of thinking about the objectives and the desired outcomes rather than the solutions or at least before thinking about the solutions. And they brought me in to run their corporate planning process for their next annual planning process, that way to run it completely based on desired outcomes rather than outputs. And they ended up organizing and budgeting for the entire year this way. This was an electric power utility. This was not a software company, not a hardware company, not a consumer goods company, nothing like software. And yet they found that the principles really applied there. So I mean, if you think about it, there's the What's our vision? What are we trying to do that benefits the customer? What are the measurable business objectives that we need to meet? What are the problems we need to solve along the way? What are the critical timeframes in those are all universal business considerations? The one exception people might think be tempted to make is for internal teams like you said. But I don't think that's a real distinction because even though your product isn't sold to some external customer, it is used by internal customers for some reason, it is providing some kind of value to whoever is using the product, even if it's like a back end system that supports another product. Still, there are outcomes that are desired from doing any work to change or create in the first place that system. And if you can describe those desired outcomes, you can get a much more reliable result in terms of achieving them. Just because you frame the problem correctly. Does that make sense?George Stocker  41:50  It does. Now there's one thing I want to talk about because it was revolutionary when I read the book. In the book, you talk about a way to prioritize work and you come up with a formula and it's scorecard that can prioritize work. Can you talk about that?Bruce Mccarthy  42:03  Yeah. For me this, this comes from going back to what's the desired result. I always ended up with a list of way too many good ideas, especially through this kind of brainstorming process that I described. And all of them seemed like things that we should do. But we couldn't get even half of them done in any period of time. Like I, I started at this company, and went around to all the executives and asked them, What projects they thought we either should be working on this year, or maybe already we're working on this year. And the list was 75 items long. And we only had five developers. And some of these things were really chunky big things. And so it seemed to me like yeah, we could maybe get two or three of these 75 things done. How We pick. So over time, I've developed this method of scoring these things to decide which things are the winners. And the basic idea behind it is that you should score things based on the likelihood of getting a positive result with the least amount of effort, you should score them on ROI on bang for the buck, right? If, but you can only do that. If you agree on what the bang you're looking for is, you can only do that if you agree on what your business objectives are at that particular company. Fortunately, we have just gone for a round of investment and we knew exactly what the the business objectives we had sold to the board and the investors were so I was able to fill them into my scorecard at the top and rank every single idea as to how much I thought it would contribute to those objectives. Each each objective separately was given a score for each item And then added up. And then divided by a couple of other things. One was effort, our rough guess as to how hard a problem this was to solve. And then also confidence. Sometimes, two ideas look roughly similar in bang for the buck, but you just have a lot more knowledge about one of them than the other about whether about how to solve the problem, or about whether the customer will really get value out of it. And it will really drive the business results you think it should. And so that confidence becomes your fudge factor and you're your decider in those kinds of ties. And the confidence comes from basically your confidence that your scoring is correct that it will really work out that way in the real world. On the other hand, sometimes also you run into things that look really good before you put the confidence factor in. This should be really And I'll bet the customers will really love it. Awesome. It's at the top of the list. Except, well, we've never done anything like this before. So we don't really know what's involved. And it's kind of different than our usual value proposition to the customer. So we don't really know if they'll like it until we try it. So now you put the confidence of only like 30% in and it falls way down on the list. But that's just telling you not it's a bad idea, but that you need to do your homework, you need to go and actually do a design project or a research spike, or something that's going to get your confidence up where it should be before you attempt it. So I I love the scorecard method as a way of breaking those log jams and also of managing your stakeholders. Because if you This is the other thing I did at that same company, if you all agree on what the goals are, and you kind of go through and discuss your scoring on All the things even if you don't 100% agree on everything, what you're doing is you are unpacking the prioritization logic for all the stakeholders in exactly the same way and then a logical framework that they all agree on and buy into. And so it's very easy to bring a bunch of people who don't usually agree to alignment, if you can get them to go through this process with you.George Stocker  46:23  Nice. Now, where can people go to learn more about you and to get in touch with you?Bruce Mccarthy  46:28  Thanks for asking. My website is product culture.org. Because I believe that these things that we're talking about sort of come down to a culture of focusing on the product discipline of making customers successful and how that makes the company successful. on there, you'll find info about my book, product roadmaps, relaunched and a link to Amazon and I also have a weekly what I call it nano letter which is called one thing on product culture, and it's really short. It's meant to be read, you know, like while you're making coffee or the coffee line. It's just one thing on product culture each week. And you can also sign up for my public workshops on the website.George Stocker  47:14  Wonderful papers. Thanks for joining me today.Bruce Mccarthy  47:17  Thanks for having me, George. It was great talking about this stuff.George Stocker  47:20  It was and we could talk about it for hours, but unfortunately, our listeners won't listen for that long. Alright folks, that's it for this week. I'm George Stocker, and I hope you'll join me next time on the build better software podcast.Transcribed by https://otter.ai

Open Source initiative: https://opensource.orgTranscript (Provided by Otter.ai) (Please reach out with corrections):George Stocker  0:00  Hi, I'm George Stocker. And this is the build better software podcast, a podcast, where we talk about the issues that will help software teams build better software. Today, I'm answering the question, should your team adopt that open source library? Now for the purposes of this episode, I'm going to use the Open Source Definition provided by the Open Source Initiative. At https://opensource.org. There are two main divisions, there are copyleft licenses, which require that derivative works, use the same license as the original work. And then there are permissive open source licenses. And that's anything else that's not a copyleft license. A permissive license basically allows you to do anything you want with the software. Again, I'm not a lawyer. This is not legal advice. This is just my understanding of it. So back to the question, should your team adopt that open source library? First question we want to ask is, is the license that you is going to help us or hurt us. That is, is the license of the project copyleft license, which means that we probably need to redistribute what we're doing if we use that library in the same license form, or is it a permissive license? Will it basically allow us to do whatever we want with the software? That's the first question you have to answer. And that's a legal question. I can't answer it for you. The second question is, is that open source library central to the problem domain your software operates in? Or is it 10 gentle to it? Here's what I mean by that. If you are a data processing company, then you will pay very close attention to how your sorting and searching algorithms work. You may even adopt your own ETL processes for data warehousing. That's to be expected after all great data processing company. That's what you do. Now, if you're a web designer, company and you design websites for other businesses, then you're probably not going to build your own web framework. Because that's not how you make your money. You make your money by giving someone a finished product, not by putting your time and money into making a web framework. If the software that you're trying to adopt as tangential to your problem domain, you're more likely to decide you either want to buy it or use an open source library than you are to say, we want to develop this functionality in house ourselves, then to say we want to develop this functionality in house ourselves. The next question you're going to ask is, Will adopting this library helped my team solve the problem it's trying to solve faster? Here's what I mean by that. All software, whether you build it or whether you buy it, or whether you adopt an open source library has an adoption timeframe. You have to take that into account when you're deciding whether or not to adopt a library or framework. For instance, when we were adopting RabbitMQ as our message bus We had to adopt it and understand what it did with each and every language that we use to interface with it. So it had drivers written in Perl and C# in TypeScript. And what we had to do is everybody that taught to RabbitMQ, had to invest that time into learning those API's. Now, in some cases, that'll be a very trivial amount of time. After all the software has good documentation, or it has very self explanatory use cases. Other times, it won't be, and you can't just pay that time for the person implementing it. It's everybody on the team that's going to be touching that open source library or framework. They all have to worry about this. And that gets to the next problem. What is the worldview of the open source library you're trying to adopt versus what is your applications worldview? If you're adopting something like SQLite as a database engine, it has a very strict understanding of the world. It believes that it's going to be a single consumer database that is, that might be one connection to the database. And it will run on a local or a situation where only one person will try to talk to it at a time. That doesn't mean it can't handle bigger workloads it can. But it means that it was designed around the idea of a self contained database isolated from the larger world. Contrast that with something like SQL server or Postgres, and its idea of the world is, yeah, there's going to be a lot of people connecting to me at once, and they're all going to want data. How do we handle that? Every open source framework or library has a worldview, and you have to understand its world view, to understand how much trouble or how easy it will be to integrate into your application. George Stocker  4:52  The next question you have to ask is, how often is this open source library updated? What is its traffic look like? If it's on GitHub, how many forks does it have? How many open issues does it have? How many closed issues does it have? How many pull requests are pending? How long have they been pending? For, you want to know the answer all these questions because it's going to determine whether this is a hobby project, or whether this is an actual serious project that you will be able to rely on without having to pick up the pieces yourself. Just like my own hobbies, I get to them when I get to them. I haven't played golf in almost three years now, just haven't been able to get around to it. Now, if golf are my job, I'd be playing every day no matter what open source software runs the gamut from Hobby to business. And before you adopt a library, you have to know where it fits. If an open source library isn't updated very often, or if it has open issues, then you'll have to fix those issues if you decide to adopt that library, which means forking the project. There's a second part to updates. Once you've adopted an open source library into your system. You now have to keep up to date with its security releases with its minor releases with its major releases. Hopefully it's following something like semantic versioning where you can tell Just by looking at a version number, whether or not a change would be breaking or not. If you're going to adopt a library, you have to fit its release cadence and its update cadence along with your own. Miss gets further complicated if you're releasing your software as a distributor, as a distributable, to your users, in maintaining open source software that you've adopted into your project, you also have to worry about forking and releasing changes that may not be upstream of you. For instance, you're using a data grid, you find an error in that data grid, you fix it, you've released an upstream patch, but you don't want to have to wait for the library that you're using to be updated for them to release a new version. So you go ahead and you fork it, you make the change in your forked version, and then you use that version. That's something that you're going to find yourself doing. Often in open source software, the longer you use it. You need to plan for that and you need to understand it can happen What to do when it does happen. And in fact, if you're going to adopt an open source project, look at how it's built and look at how it's deployed. Those are two areas where you're going to find trouble when you need to fork or make changes in the software for your releases that aren't going to be accepted in the upstream release. Overall, with open source software, there's a certain feeling of you've adopted it, you get to maintain it. Now, whether or not that's legitimate is up to each project that you've adopted. It's different for each one. In some projects, changes are adopted very quickly, and they're fixed very quickly. In other projects, it could take weeks or even months for changes to be adopted. That means that whenever you adopt an open source library, there's a high likelihood that you will have to fork it and make changes in your fork. Your team needs to be prepared for that. The next step is giving back does your company Allow you on the company's time to give back to open source. Now in the example I just gave where you found a bug in a library and you fixed it, well, you've got to give that change back in order for it to be included in a release. To do so, there could be copyright issues. In other words, the code that you wrote for your employer on their time, as a work for hire is different than you making the change on your own time on your own computer. Without doing it for your employer for pay. You need to clear with your company's legal division. If you have one, what code you are allowed to submit back to an open source project and whether or not you're even able to submit code back to an open source project. This is a legal question, talk to your company's lawyer. But if you're able to give back, that's a very good thing. It allows us to keep it open source software going reinvigorates the author of the open source library that they have people that want to help out and it looks Good for your company too. Now one of the most difficult parts about adopting any piece of software is understanding it through its documentation. Before you adopt a library, you're going to see what kind of documentation it has, whether that's on the libraries on site, or whether that's on GoogleGeorge Stocker  9:19  Stack Overflow, blog posts, anywhere, you want to see what people are writing about it, so that you can better understand whether or not a problem that you have with it will be solved by someone else. With open source library, you can assume that there will always be a problem when you adopt it. Always. The trick is, is can that problem be solved before you have to solve it? Has someone else solved it and fixed it? Or has someone else even seen it? The smaller a community is, the fewer number of people who have written about it, the fewer number of people who've probably seen the problems you've seen, and it's always a consideration when you're deciding Whether or not you want to adopt an open source library is, what's the chance someone else in my tech stack is having the same problem with the library, and will found a solution to it, or will have written a solution to it. Before I get to that problem, it does go without saying that every problem that you find in software affects your ability to deliver your product or the problem that you're trying to solve. So it's always something to keep in mind. Now on the subject of community, you want to look for an active GitHub community. If the project's on GitHub, you want to look for Stack Overflow questions and answers about it. And in general, you want to see a lot of Google hits when you Google problem with library acts. Now, one of the problems we don't talk about enough in open source but it happens because of the way the open sources set up is project abandonment. Rarely, a project author will come out and say I'm no longer maintaining this. Good luck. Have fun with it. More often than not, it just sits There with no one answering questions, pull requests not getting accepted, and issues not being responded to, or no commits to the project for a given length of time. And you need to take it into consideration with every library. If I use this library, will it go away? Will the author stop supporting it? If the author stops supporting it? Who will step in? Is there a community that may step in? Is there not? Am I willing to step up and lead a community around this project? If the author abandons it?George Stocker  11:33  Now you don't have to answer Yes, in order to adopt an open source library. But you do have to keep that in mind. Because if the author abandons it, and you need to make changes, you're now on the hook to make those changes, even if it means forking it, making the changes and not releasing them upstream. Now, we talked a little bit about legal considerations before but your primary legal considerations are, does this software's license. Let me do what I need to do with it. And does it affect my financial interests as a couple Money? And am I allowed to give back to this project? Through my company's own legal policies? Will there be copyright issues? If I fork this project on company time, make a fix to it on company time, and submit that fixed on company time. There's always also a consideration that a project may change its license in the middle of its lifecycle. MongoDB that this, Elasticsearch has done this, and a few other big name open source projects have done this. And they've done it because cloud companies that shall remain unnamed, swoop in, fork the project, release a commercial version of it, and then take all the bread crumbs for themselves. Now this affects everybody that uses that software, you now have to determine Are we going to pay for this new license? Or are we just going to use the other older license and not accept any new changes? So these are everything that you have to consider if you want to adopt an open source library. Now on the other side of that You can build it or you can buy it not going to cover buy it here, that's pretty much a financial question is does your company have the resources to pay for a library? Or to pay for a framework? And then do they have the resources to keep paying for it? After you build it yourself? You don't have any of the issues that I talked about before the civvie their documentation or just their community exist? Or do they abandon it? Or do I have to give back to it? Or, you know, how often do their updates come? Or what is their software's worldview? No, I mean, this is all centered around you and what you need as a company. If you build it yourself, you're now responsible for it. anything goes wrong, you're on the hook to fix it. Every developer from hither to Yon in your company, will now have to become an expert on whatever this thing is. It's also going to take longer than you think to build it, especially if it's tangential to the problem that your team operates in and the problem Your software tries to solve, the closer it is to your core competency, the faster to go farther away it is, the harder it will be. If you want new features, you're going to have to be the one to add them. There's no magic feature fairy that's just going to add features to the software that you build. No, you get to add it. And there's now a documentation cost. You built it, now you get to document it, then if you don't document it, you have to run institutional knowledge to understand how to use it. And if you're relying on institutional knowledge, that's people and people leave people win the lottery. And people forget. There's also the idea that you may not actually have the expertise needed to solve this problem. Think about ORMS and the object relational mapper has been around for at least 20 years. One time I worked with an employer where they created their own object relational mapper. Now they weren't experts in database design and an object oriented programming, but it seemed like an easy process. To solve Sure, I can write my own object relational mapper. And they did, or the following 6, 7, 8 years, the entire team had to deal with this framework that didn't have wide adoption had no adoption outside of the company had no documentation, no new features other than if someone on the team spent the time to create those features. And there was nothing portable about the object relational mapper, they couldn't take their knowledge of it somewhere else. It created lock in, in the worst possible way. It locked employees in to a dead end technology that they were sad to use every day. Now, this is just one example of not having the expertise required to solve the problem. When the team needed something new that the software couldn't do. Well, that wasn't taken into account when it was developed. And then therefore, they ended up using another ORM anyway, because the software couldn't do what they want them to do. And that's going to happen. If you're building software. That's not part of your core competency. You're going to miss fundamentals in that software, and your team will have to pay for it in some form or fashion. This isn't to say you can't write your own software that you can't write your own ORM or your own web framework, to really need to ask yourself, are you going to get the value out of it for how much it's going to cost you? Now, all this is going to depend on your business contexts, your social context, your team's context, the technical context the software operates in and your customers needs. I can't answer all those questions for you. But they're questions that you'll need to answer in order to be able to decide whether or not you want to adopt an open source library, or you want to build it yourself. Now, that's all for this week. I'm George Stocker, and I hope you'll join me again next time on the build better software podcast.Transcribed by https://otter.ai

Show Notes Lara Hogan : @lara_hogan  Website: WhereWithAll.com Lara Hogan's Book - Resilient Management Black owned DEI Consultants taking on more work; Manager Voltron Bingo(PDF) LeadDev Together 2020 (Training for Engineering Managers) Project Include BICEPS Model Rough Transcript (via otter.ai )George Stocker  0:00  Welcome to the build better software podcast, the podcast for software leaders who want to enable their teams to build better software. I'm your host, George Stocker. And today I am joined by guest, Laura Hogan, to talk about resilient management. Laura, welcome to the show. Thank you so much. I'm so excited. I'm really excited. Now, for folks that who are just meeting you for the first time, could you share a little bit about who you are and what you do?Lara Hogan  0:24  Yeah, these days, I coach managers and leaders, fortunately, all over the world. Before I was doing this, I worked as the VP of Engineering at Kickstarter. And before that, I was an engineering director at sea and before that many other small startups in the tech space. I started out as a self taught front end developer and then figured out that management was definitely the place for me.George Stocker  0:48  Yeah, so you've worked at large companies, you've worked at startups, and they're, those are typically differently paced. So I want to go into that deeper. But after you after you did that, you've now started your own company.Lara Hogan  1:07  Yeah, it's called WhereWithAll . So I realized I had read this study eons ago now about firefighters and how they develop expertise. It turns out, you know, it was it was still basic expertise, but in this study, it was trying to figure out, okay, comparing firefighters in urban areas to firefighters in rural areas, which are the deeper experts just kind of controlling for number of fires and years experience. And the study showed that firefighters in this case in urban areas were deeper experts because of the diversity of fires. So different buildings, sizes, different materials, different you know, just like different kinds of population densities, it was diversity of experience kind of led to expertise building and I realized, I really wanted to get some more expertise in lots of different kinds of companies. And so now that I run my own business against a pretty managers and leaders of all kinds, different levels, also different kinds of organizations, ancient Organizations organizations with lots of hierarchy organizations with no hierarchy, distributed organizations co located you know, it's just the the diversity of organizations that get to support right now is is pretty cool. I'm definitely learning a lot very rapidly and it's been lovely.George Stocker  2:14  Okay, and what sort of offerings Do you have to help out leaders?Lara Hogan  2:18  So I kind of split my time between one on one coaching and group coaching and training. So I either go into companies and provide workshops or I offer like ticketed workshops which you have actually attended one of my in person workshops at the time now it's of course all remote. But it's it's been amazing to be able to go in and support all of these different heads leaders, both hands on application, skill based training for mentors because I don't know about you, but I didn't get any training when I became a manager.George Stocker  2:44  No, the only reason I ever had any managerial training was through the army which is a bit unlike everything else. Yeah. But there are 200 year organization and they do they have a an entire they've books upon books and manuals. about leadership and about running teams, and there's a lot that we could learn from it, but it is a completely different space.Lara Hogan  3:07  So many fields have actually developed management training curriculum, tech, I mean, classic engineers, like we get to, we're like, oh, we're gonna figure this out for ourselves, like, we know, we can reinvent. Yeah, precisely. It's been fascinating to try to support tech leaders, specifically, because I'm sure you've experienced this, like people are just so hungry to do right by their teams. And so it's been lovely to bring in not just management experience, but also, you know, I've done a lot of studying on how to be a good trainer, a good a good educator, a good facilitator. And that's also a whole new discipline. And so it's been really, it's been really nice to try to bring in these skills to tech organizations to try to help people out.George Stocker  3:45  You you run a at least the workshop I went to it was a one day workshop, I think might have been to at the lead dev conference. Now, if people who don't know the lead dev conferences, it's a conference for as it says on the tin lead developers, so it talks about so groups that are useful to tech leads, software managers and the like. And I, I loved it, I can't recommend it enough.Lara Hogan  4:07  And they're doing online right now. So they've got a whole bunch of amazing, they've got like a seven part series starting in this fall. It's all like three hour online events. It's gonna be just there. They're doing such great workGeorge Stocker  4:20  and supporting so many people. I'm going to drop that in the show notes, because I think everybody can still hear about that.Lara Hogan  4:27  And I'm actually co hosting the first ones. The first one if folks are interested in this is all about how do we support our teammates as they grow? What are the skills that we need to use as lead devs to help our other teammates grow and develop?George Stocker  4:39  So I don't want to spoil the subject, but what are skills that we need to help our our teammates grow?Lara Hogan  4:45  So the thing that I've learned in doing this job for a while is that as knowledge workers, we're taught that the best way we can help our teammates is by teaching them pair programming or sharing with someone how we would do a thing They're working on mentoring them providing our perspective and our advice. And a bunch of research shows that those skill sets like the teaching, the mentoring skill sets, the advising skills, skill sets are really only helpful and getting someone unblocked or helping someone on board. That's it. If we actually want to help people grow, we need to use this whole other set of skills, which most of us are not equipped to use. And we've never been taught that they're important. Like, again, we've been taught that the best thing we can do is give our knowledge to other people, but actually not help people grow. So the three skills I really like to focus on, I'm missing like a broken record to you here is coaching. So helping people connect their own dots, introspect, reflect. This is when someone's like, Huh, like, what's important to you about this? What's hard about this? If you could change one thing right now what would you change those kinds of open questions really prompt like lightbulb moments in someone you know, it's it's so powerful to like, connect your own dots and be like, Oh, I know what I'm going to do next. And most of us have that in us already. So coaching is one big skill set. sponsoring is another big skill set. So sponsoring has to do with fighting to get someone to the next level by putting putting your name on the line for them your reputation on the line for them, giving them access to visible stretch projects, developmental assignments, putting the name in their name in the ring for a big leadership opportunities being in a company meeting time someone's manager that they're doing a great job. So sponsorship is, is the is the skill set that's most directly correlated to growth and career trajectory. So again, we never talked about this thing, but there's a huge power in this. And then the last one is feedback, which we already all know about. But most of us are pretty scared of doing. So I focus on that a lot.George Stocker  6:35  Yeah, so the the common or most common approach I've seen the feedback is what we like to think of is the feedback sandwich which is they did a good thing. Here's the bad thing you did, and I'm going to close with a good thing and at least personally for me, I never listened to the good parts. Once I realized that that feedback sandwich is coming backLara Hogan  6:55  coming.George Stocker  6:56  Yeah, it will feel terrible for this. Today we'll focus only on the negative because I feel Like the good part was, it wasn't a lie. But it wasn't. It wasn't genuine, because it's set at a moment where they want to couch bad feet. Exactly.Lara Hogan  7:10  It wasn't designed to help you grow. It was designed to help soften the blow. So we're not going to like listen to the good stuff. If, if it's not there to help us learn. It's just there to help us hear the bad stuff. Yeah, it's awful. I mean, I think we've all done it, like no shame, I get it. This is a normal part of human behavior. But it really comes back to the to the six corners that humans have at work. There's these six core needs the acronym for which is biceps that I also love talking about, because these corneas are all about what are our brains need to feel safe and secure, like our fight or flight response will kick in, if any of these expressions are not met. So part of that feedback, the compliment sandwich, is to try to make sure that this person's amygdala doesn't come online or fight or flight responses and come online and in doing so, we actually totally activate that person's amygdala. It's just it's infuriating and frustrating.George Stocker  7:59  Yeah, so If we weren't doing the feedback sandwich what what should we do?Lara Hogan  8:04  So the way that I like to frame this is kind of like three parts here. It does a little bit from SBI situation behavior impact. The first part is observation. So what are just the facts? Again, just talk about just the facts, not your assumptions, not your judgments that helps keep someone's prefrontal cortex the rational, logical part of the brain online. Because you're like, Yeah, yes, I did speak for 20 minutes in the meeting last week, or yes, I do care about this project getting off the ground or whatever the facts are about this. It helps us sometimes they can still sense that feedback is coming into their amygdala still might come on but if you start out with assumptions like I think you're doing this because or judgments like man that email that you sent, it was super It was too short like that's what you know, those are not things are going to help someone's prefrontal cortex stay online are going to activate that fight or flight response. So we want to stay factory. So that's the first thing observations fact basedGeorge Stocker  8:57  and one of the things that you said in the workshop At least and then I've kind of stuck with is, you think of it like if there's a camera looking at this event, and there was there's no people interpreting but just a camera recorded sound recorded video and this is what it saw. What would it say?Lara Hogan  9:14  Precisely? I do like to caveat every time I send it out to cabinet by being like, please don't record your co workers just because it feels important. Exactly like what could what could a video camera record?George Stocker  9:25  Yeah, precisely. And so what's the next step?Lara Hogan  9:28  It's impact. So one of the weird parts about feedback is that we often describe why why we want someone else to change their behavior, like what's the impact to me, like, I care about this because it's ruining my day, or I care about this because it's disrupting our team meeting or I care about what could be anything. We're so rarely ever prompted to think about why should this feedback recipient care about this? And the thing is, every one of us cares about really different things. Like if I say to you, like, you should really care about this because this gonna really help you know your promotion. But you don't care about getting promoted, you're not going to care about this feedback. So what we've got to start to do is stop is remove our assumptions, remove our own reasons why we care. Instead, take a step back and say, what does this person care about? Maybe we do care about a promotion, maybe you care about being liked on the team. Maybe you care about getting his project done on time, it could be anything. So taking a step back saying what does this person care about just generally, and then reframing or translating the feedback into that thing that they care about? Usually, any behavior is going to have lots of different impacts to choose from. So just pick the one that feels it's going to resonate the most with this person. It doesn't have to be all about you the feedback giver, it should be about this feedback recipient and why they would be motivated to change this behavior.George Stocker  10:44  So as an example, during your presentation, it feels like you were nervous and stuttered. Yeah, the impact was I'm not sure people heard the really important idea that you gaveLara Hogan  11:00  Yeah, yeah. Well, so And the thing is,it feels like you're nervous is an assumption. Oh,George Stocker  11:09  help me, make me better. How can we do that better?Lara Hogan  11:11  So like, if someone's stuttered, first of all, does this person have a stutter? That's probably something that they are already thinking about working on. Like, I'm not sure how this feedback is gonna make them better. But let's say they, let's say, they tripped over their words constantly. So for either for the duration of the of the talk, the presentation, the trigger for their words, I would say, Hey, I was posting an impact, like, Hey, I know you care about getting this to land with your audience, whatever the thing is, like, I know you care about getting practice delivering skills. I would like to start with an impact here. Then I'd be like, one thing I noticed is that at times, like it was, there were a lot of words that came out at once, or you started in stop sentences repeatedly. So like, again, I'm just like just fact base as much as I humanly can Then I would cap it off with a question. So, again, we've all been taught to, like, offer requests, like, therefore, could you please stop tripping over your words, it's like not a thing that's gonna be helpful to this person. And again, usually if you've, if you've gotten the observation, right, it's just fact based. And you've gotten the impact, right? Like, it's something they already care about at this stage in the game, they're already there. They know what they want to do, they're already motivated to change. So you think therefore, could you please speak more slowly or whatever? It's gonna short circuit, this whole process. This should be like a dialogue, not like a one way brain dump. So ask an open question. And I don't mean a question. It's like, what if you tried blob because it's still a request? Asking an open question means what are you genuinely curious about with this person? Like I might say? What do you want the audience to know? When they're done watching your talk? Like, again, like, what's the one number one takeaway you want to have? Or what's what's the number one skill that you want to be practicing For this because I genuinely do want to know is it? Is it word choice is a body language? Is it how much you're presenting? You're like speaking at volume, it could be anything. These kinds of genuinely open questions that start with the word What? really help make this feel less like a like a, like a feedback issue and more like okay, we're gonna build this together we're gonna we're gonna help change this behavior together.George Stocker  13:21  Oh, now, yeah, no, I'm I'm almost embarrassed because I wish I had I had known about that, you know, when I was started to be a manager A long time ago. Yeah, yeah.Lara Hogan  13:36  Because if you're eating right, reflecting back you're like, Oh, man.George Stocker  13:39  Oh, sorry. Edie reported me I'm really sorry.Lara Hogan  13:43  Yeah, yeah, I we also have like, wait like long term to go. Like we even even I still it's so hard to break out of the old feedback patterns. It's hard to remember this shouldn't be just like a big dump of information. This should feel like a two way dialogue and you should be framing it in terms of what this person cares, that's really easy to forget, because we're so driven to give us feedback. We're like, I know why I care about this. I bet they care about it, too.George Stocker  14:09  Yeah, I'm gonna make an assumption here, but it and it's just a connection I just made at this moment. But this sounds like this could be also good for teams in a retrospective format that are doing something like ScrumLara Hogan  14:22  100%, the questions part in particular. So I think it's totally cool to say facts, like in a retrospective like, here's a fact based thing that happened is much better than here's what I'm assuming is happening, or here's my judgment about what's happening. So again, keep those keep those illegals offline, keep the prefrontal cortex online. But then questions are really really powerful, like, Hey, what's our number one a shared goal here? Or, if I could wave a magic wand and change one thing? What would it be? It could be anything any of these open questions can help to prompt that intersection help someone connect their own dots and figure out together a path forwardGeorge Stocker  15:01  Now, you've just finished writing a book,Unknown Speaker  15:03  haven't you? Yeah, resilient management? Yeah.Unknown Speaker  15:06  Tell us about it.Lara Hogan  15:09  This was like the culmination of so many hours of coaching and training. You know, I, I found that the same topics were coming up consistently. And the managers that I was working with at all levels, like, this is a book, not just for people who are brand new or curious about management work, but people who've been doing it for a long time. Because there's stuff in here that just even senior leaders struggle with like, why is Why is no one getting on board with our new Okay, our process? Why is this person I try to keep delegating things to not picking up the slack. Like all of these are topics that we all have in common, regardless of level. And there's a lot in here in the book too, about adapting your leadership approach when things aren't working, because I think as managers we all kind of default to what to what we know or what's worked for us in the past or what we wish we had in a manager and we don't get a lot of practice. using other kinds of leadership styles or approaches, and it's really I think, as leaders, it's so critical for us to know how to use different kinds of styles, leadership styles and approaches more direct, more empowering, based on the context and what the people around us need and not just what we need.George Stocker  16:13  Hmm. Now in the army, they had they listed three and again, being in the army, they'd release things into you. So years later, I can still mention what they had three styles of leadership there was directing, effectively a dictator, there was delegation, where you have other people do it, you say, hey, go do X, they do x. And then there's participatory, where you work with the team to make things happen. Now, that's definitely a different words, maybe for the same thing, maybe for different things that you talk about resilience management. So let's talk about the ark of leadership that you bring up in your book.Lara Hogan  16:46  Yeah. Oh, that's so interesting, because when you said delegating, I was trying to piece together like how does that how is that distinctive from the other two styles because you could delegate in a directive way or you could delegate an opinion separatory away.George Stocker  17:01  That's true. That's true. I don't think that they I don't think that they ever made that distinction at least once. But you're right.Lara Hogan  17:09  It's interesting. So I kind of think about it as like a spectrum between two endpoints, which actually sounds mirrors that a little bit one is directive, like being really directive. You know, being really firm, blunt, clear, just setting the path forward. empowerment is the other end that I usually think about. And it sounds like that's probably closer to the participatory style that you mentioned, like coaching style and sponsoring style are totally on the empowerment end of the spectrum, like helping someone connect their own dots, bringing people along for the ride, not just telling them what to do. And strong leaders, I think, kind of bounce around the spectrum based on what the situation calls for. So like, we all have a default. Mind by default, is empowering. Like I'm just like, if I could coach all day, I would. But there's failure modes to either end like there will absolutely the circumstances in which they are defaults isn't useful. Like if I had if I was onboarding someone When new to my team, and they had no idea what to do, if I just ask them questions like what's important to you? They'd be so stressed out, they'd like to tell me, can you tell me what this job is supposed to keep the home supposed to talk to? You know? So there's, there's times you need to answer. And same on the directive side, if I constantly just telling people what to do, there'd be no growth, there'd be no learning, there'd be no stretching. So it's really important as leaders for us and as managers to kind of figure out what the situation calls for and get practice using not just each end of the spectrum, but all the spots in between toGeorge Stocker  18:32  Okay, and you mentioned, sponsoring and coaching on the empowering end of the spectrum. Yeah, and coaching is asking people open ended questions.Lara Hogan  18:44  Yes. Bingo. Yeah, exactly. Asking people open ended questions again, helping them to kind of track their own dots and not telling them so not mentoring right, not advising but instead, reflecting back what you're hearing them say giving them time and space to introspect and asking them those beautiful open questions to help like process That kind of introspection,George Stocker  19:01  and once that most useful, you know, what was it success mode? I guess?Lara Hogan  19:06  Yeah, it's most useful when you're trying to help someone develop a new skill or just grow just in general grow as a human as coaching is the most powerful one to use them. So basically all the time, but the caveat like, I'm talking like 50 to 80% of the time coaching is the mode that we all should be and there's like a subset of cases in which you know, mentoring is going to be helpful, but otherwise coaching is coaching.George Stocker  19:32  Do you have Do you have any imagery that will help say, hey, an example of who'd coaches Well,Lara Hogan  19:37  yeah, other questions so I would say if you see someone at work, who's like hey, here's the outline of a project that I need I need help with it my my go to example for this is a blend of sponsorship that like giving someone a stretch goal and also coaching them through it. And coaching which was my boss was like, Hey, I don't I've got too much on my plate. If you're a director, I know you've never worked with corporate budgets before. But can you figure out the engineering budget for education? Like training, travel all this stuff? I was like, okay, where do I start? And he was like, Well, here's probably the people you need to talk to, here's the end outcome that I'm looking for. But like, it's totally up to you to figure out what that is that that sponsorship, like that's giving me the outline is the delegation. So here's a stretch project, I think you can be supportive with what I was missing was, hey, let's figure out where like, let me ask you some questions. Laura, what feels scariest about this for you? Where do you think you want to start? Who do you already know who's good at this you can rely on like those kinds of questions that prompt the intersection that would have been a beautiful coaching moment, if only I mean, I had a great coach the whole time was like actually a train coach. She was really helpful. But that's it kind of brings up the point that one person can't be your everything. Your manager is not going to be good at all these things. I think it's really important to build out a network of support that, you know, I like to call a manager Tron.George Stocker  21:01  You do talk about that in the workshop go deeper into that.Lara Hogan  21:04  Yeah. So I think I learned this the hard way. I think we've all learned this the hard way, like your managers, it is a subset of skills, you know, need more than just one person. So I started to think about this as like a group of people, a diverse group of people that I lean on as I grow as a as a, as a manager, as leader as a human. And they're each going to have different skills are each gonna have different defaults on that spectrum. they're each going to have different experiences and perspectives. Some people I lean on have like completely opposite leadership styles to me, some have way more experience in me in a completely different field than I do. So people are great at giving feedback. Some people are great at coaching, you know, it could be any of these set of skills actually have a bingo card. I don't know if we can link to stuff in the show notes at all, but like great, beautiful so you can link to the bingo card to help you kind of brainstorm who's already in your network of support for these kinds of skills and where are the gaps like where should you be adding people to your Voltron to help you grow?George Stocker  21:57  One of the issues I'm I struggle with is asking for help. We all need a manager. How do you like, if you're like me? How do you how do you get to that next step, which is asking for help.Lara Hogan  22:13  Right? And it's like the only advice out there is like, go out and network. Like, what does that even mean? It's not clear, especially though, right? It's absolutely like we're where everybody's so underwater. So even if you could find, let's say, a Slack channel to go find and meet some people in everybody's drowning. So, the best way I've seen to add people, to your Voltron is like someone in your extended network. It could be someone inside your company but kind of outside of your normal field of work like someone in a different department. It could be outside like, you know, friend of a friend, manager of a manager style. But once you kind of have an inkling that there's someone in your network that you already have a connection to. It can be the tiniest little connection in the world. I recommend coming up with like figuring out all of all the problems that you have What's one that this person can help with either provide their experience on, or maybe be a good coach to you for give you feedback, something specific, choose a specific skill that you would like them to use. And then reach out to them and ask them for that specific help. So the way that this first happened to me, and I really realized it for the first time was the former CTO of meetup event Pasqua she, I had, like, met her at something randomly. You know, we connected on LinkedIn or something. And she she reached out and said, Hey, I know that you run an infrastructure team at Etsy. I'm a, I'm currently thinking of reorganizing my infrastructure team, do you have any opinions on like, how how to do or how not to do rewards? And sure, it was a shot in the dark, but like, do I have opinions on reorg of infrastructure? So like, I was, like, immediately wrote back and was like, yeah, let's, in this case, it was in the before times, and I was like, let's get coffee. And it was, it was so it was such a beautiful example of what when you ask someone to give their opinion. And something that they may care about deeply, it's so easy to form that connection and genuinely get their help. And she she didn't make up that problem that was actually a thing that she was thinking about. And so it was it turned into a lovely two or three hour meeting in which we talked about so many things. And that was her way of adding me to her Voltron crew. And it goes both ways. Like now I lean on her for all sorts of things. And I have, you know, the honor of supporting her through a bunch of stuff too. And it's it I've seen this happen time and time again, if you just reach out to one person that you have, like a distant connection to ask them for specific help on a topic that they may be jazzed to share their knowledge, expertise on, it can lead to beautiful things.George Stocker  24:36  One of the things I don't want to skip it because it's, it's very interesting, but we almost skipped it is sponsorship. So you're coaching. Now, let's talk about sponsorship. What does that mean and what does that entail?Lara Hogan  24:50  So sponsorship, if you think about the times in your life and you as a person who have grown, like if you think about the times when you had a manager who really skyrocketed your growth And you think about what skill sets they used or what they did to help you with that growth. Nine times out of 10. It was not giving you advice. It was maybe giving you feedback, but most likely it was giving you the stretch opportunity. Like for some reason, this person trusted in me. They gave me this project, I didn't know how to do it. And that helped me grow so much. That's sponsorship. And again, it's so much more powerful than any of the other skills when it comes to actual career trajectory. There's a bunch of studies on this. And whenever I talk about sponsorship, I also like to bring up that members of minority groups are often over mentored but under sponsored which means that white people in my case actually white women are often get lots of unsolicited advice, but very rarely opportunities look sponsorship people going out of their way to provide those stretch goals and and support through meeting those stretch goals. So this is true for people of color. This is People with disabilities, trans folks, non binary people, there's just so many folks out there who really deserve sponsorship. But because of something called in group bias, the way that we network as humans often means that we are referring to people and referring people, for the people who we think about first, they are really similar to us in a variety of ways. And until I started learning about this, frankly, most of the people who I sponsored, were white cisgendered women like me. And so it just takes a lot of hard work to combat these very natural instincts of how we network and support each other to kind of break out of that shell and sponsor people with different backgrounds, different experiences, went to different colleges, you know, all the all that stuff, all the normal in group stuff to break out of that.George Stocker  26:42  Yeah, and I don't have to tell you that, you know, diverse teams will build better software all the time. 100% and we just have to sponsor and give people the chances that they might have otherwise gotten, I think thenLara Hogan  26:56  yeah, and the prime support to do so. You know too often we see people be like, here, person here's a huge stretch opportunity. Good luck I believe in you and then providing no extra support and they're gonna fail, you know. So yeah, I think that it's it's definitely needs it takes intention and then hard work to support those people and succeeding.George Stocker  27:15  Yeah. When you were bringing up sponsorship I remember the times where I've grown the fastest in my career have been when somebody sponsored me but didn't let me go out there on my own. Like they were they weren't, you know, they were behind the curtain. And they were helping me to pick up any pieces that I might have dropped, but they weren't visible to other people. And it's so so to other people. It was me. And when I look back, it was them.Lara Hogan  27:44  powerful is that Yeah. And like that, it's that that behind the curtain part is the critical part. Like we can't be sponsoring for ally ship cookies, right. That's like, that doesn't that's not what sponsorship. We need to be behind the curtain. We need to be allowing this person To be to really succeed in the in the spotlight. And I love what you just said. And it actually makes me think of the other skill that you mentioned about the army training, which is the delegation skill. And a good delegator is one that doesn't micromanage doesn't doesn't tell you what to do. But gives you the like, illustrates the end goal, like, here's the problem that we're here to solve, and then tells you how they can lean on you for support. So like, are you calling on them for support, rather, so like, you know, I expect that you'll want to get on the executive team agenda. Reach out to me when you're ready for that, and I'll help you get on there. Or I'm super happy to provide you feedback on any of your drafts before this goes live. Like just be really clear about the ways in which you want to support them so that they're not like worried about reaching out to you when it's time for some help.George Stocker  28:43  Yeah. And the funny thing is, is of course, the armies are focused on on fighting and winning wars, but there are there are takeaways. One of them, just like what you just said, is something called the commander's intent. So whenever there is a, hey, we need to take this hill for example. They started The battle plan with the commander's intent is by the end of this, whatever the outcome is, and that starts it, that ends it. And if at any point there is no communication or you know, the fog of war happens, then everybody every unit down to the individual platoons they know what was the commander's intent, what is the ultimate, you know, outcome that we are looking for. And so that allows for platoons and for companies that are outside of communication or when things break down, which they invariably do that allows them to take initiative on their own and get to the right outcome that they were looking for in the beginning.Lara Hogan  29:38  Yeah, it's almost like at the end of this what do we cross check? What do we what do we like triple check to make sure that we met the God at the intent? Yeah, yeah. I love that.George Stocker  29:48  I actually think I would be talking about the Army Today at all. So you right now with, as as we as we record, this show, live 14, California, Florida and Texas are on the rise. Other states are either on the rise slightly or a lot or holding steady at best. This is a tough time for even even if you have nothing else going on, this is a tough time. What is your advice for managers of teams at this time?Lara Hogan  30:24  It's just, it's just the worst. It's just it's really illustrating, illustrating what a lack of leadership looks like. Which means that it's in many ways falling two leaders with less power and less privilege to try to pick up the slack. So in the internal to a company sense, this means that lots of managers need to figure out how to support their teams, and their individual teammates, all of whom are dealing with different circumstances. One of the one of the pitfalls that I see happening a lot right now is managers and team leads are trying to create support in ways that they personally would benefit from them. They're projecting their own needs on to the rest of the team, like the beginning of corn times, I saw a lot of managers be like, let's create 6pm happy hours every day. So we can also feel connected and like, maybe that helped one person, most of us would have been like, I got these other I need to go take care of these other things. I cannot be on zoom any longer, you know, got three kids. Right, exactly, exactly. So I see a lot of managers falling into this very normal natural trap of like, let me do all that I can to help people and just take shots in the dark about what's going to be most helpful rather than taking a step back and listening. Asking, I don't recommend the What do you need right now question first. I recommend that later. I definitely recommend a few things for managers start with first tell them what you're optimizing for right now. I am optimizing for making sure psychological safety is happening on the team or I'm I'm optimizing for making sure everybody Has the energy that they need to get through this project, or I'm optimizing for making sure everybody has the information and clarity that they need, whatever the thing is, be really clear constantly about what's the number one goal for you, as a manager, the thing that you're optimizing for right now, that's a good example of like one way communication, which I'm going to emphasize a lot like, anytime you require there to be a two way communication, it requires synchronous communication, or even if it's async, you require a response to something makes it really hard for people to like, find the time and the energy to do so. So over index on doing lots of one way communication. In one on ones, though, be really clear about how you're planning to support people or how you're trying to support people say, Hey, here's a few things that I've realized we could use in the team. What are your thoughts on that? And that's when you can say, what else would be helpful to you right now? Like, it's only after you've gotten through this initial like, here's what I here's what I'm optimizing for. And here's the things that I'm trying in case they're helpful. What else do you need, kind of opens the door for people to be specific about what they might need. And then it's kind of circles back to something I mentioned at the top which is the six core needs that humans have At work, those things that are amygdalas are trying to, you know, keep us safe with they're all threatened right now. I mean, when we think about it, and they include things like how we belong to a group anytime you feel others are alienated or left behind, are muggles going to feel threatened?George Stocker  33:16  And is that they haven't biceps?Lara Hogan  33:18  That's the visa. Yes, yeah, biceps is the acronym. Thank you coined by Paula Medina. So blogging is the first one. improvement and progress is the eye. So we want to feel like we're making a sense of progress and forward motion or lives. And anytime we feel stagnant or like we're taking steps back, that cornea is going to feel friend, it's really obvious that's happening right now with the numbers that we're looking at. The cc stands for choice. So how much autonomy Do we have right now there's so we're being forced inside or being. I mean, as much as anybody else. I don't like wearing a mask, it's really important to do so. But for many people I'm seeing their need for choices is kind of showing up in that in the area of equality and fairness is the ease so we want to As humans, we want to believe that everybody's been doing Fairly and as they should be, and obviously a number of populations are being over impacted by this horrible pandemic. And it's a bunch of communities that need extra support right now, it's just unfair. Also, at the same time, the Black Lives Matter movement is really again shining yet another light on the lack of equality and fairness in our, in our communities. It's just, it's obviously a corny that we were taking to the streets over predictability is the P, we want to have some sense of the future, what's going to happen, so certainty. And then last, but not least, is significance, which is effectively status, like where am I in this informal or formal hierarchy. So when I think about the people that I support, as a manager, every single person's going to have a different combination of these core needs at play. And the trap that we need to not fall into is projecting our own core needs onto everybody else, like my core need right now is instability. I need it. I have a little, a little post it note. You can't see it, but George can on my laptop. This is predictability. Just to remind myself, hey, when you wake up in the morning, create as much stability as you can. So this is the corny that your amygdala your limbic Big system needs the most right now. Everybody's is going to be different. I can't project my need for predictability onto everybody around me I need to start to listen ask questions to figure out which of these their core needs is being threatened. on the blog, we can link to it on the blog, I've got a bunch of open ended questions that you can use with your teammates to kind of check in and how they're coordinating. They're doing to make sure that you're, you're correctly supporting them in the ways that they need.George Stocker  35:22  It's funny. We've talked about success and failure modes, and it feels like a failure mode of our current political system is, you know, of federalism is the fact that you have a large pandemic that affects the entire nation. And you can't like you have to have that leadership that strong leadership at the top which our system of federalism at least practiced by the current administration, administration. They're, you know, they're trying to practice that I think, but it is a failure mode right now. It's not going to help us succeed, and which is, unfortunately is devastating like, this has really Life consequences. And that's what we should remember whenever we're trying to vote for new leaders. Yeah. Now, who do you recommend? As far as you know, who do you lean on for? I don't want to say diversity inclusion, because it just puts, that puts like a label on something, it's so much more important, you know, making sure that the biceps model works for everyone in our organization, who do you lean on to understand how that can help with people of color? You know, with minorities? You know, who do you lean on? Who is your, your go to for more information on that?Lara Hogan  36:36  Totally. So there's a bunch of I mean, just everyday, there's a bunch of new resources out in the world that are being developed. There's this amazing spreadsheet that's going around that I can provide a link for in the show notes for black owned di consultants that are currently taking on new work, which is just incredible what an incredible like, group people that we can continue to invest in the support as they do this amazing work for Me personally, I've been leaning a lot on existing resources from project included when it comes to like tech workplaces and how we can continue to make our workplaces more inclusive. They got a bunch of good research and a bunch of really important frameworks that we can kind of lean on for all aspects of our business. And then the creator of the of the biceps core needs acronym Paloma Medina, she also has a bunch of resources on our website that have a lot to do with equity and inclusion work that I find myself often citing for lots of different parts of whether it's the hiring process, or the retention process promotion processes, just to really try to triple check and look at the research again, not just try to make it up like as we engineers are want to do, actually look at the studies and say okay, what works and what doesn't like there's a bunch of studies that show that different styles of unconscious bias training, make things worse, look better. So it's actually taking a look at like what works what's, what's real, what works and applying those things.George Stocker  37:56  Wonderful. Yeah, we only have a little while. left. But you know for a team that doesn't have psychological safety or maybe has less psychological safety then you know they need to be productive what you know what are the first steps you know for them is how do you figure out what you don't have a psychological safety into? How do you get yourself out of it?Lara Hogan  38:22  It's this stuff is so hard and there's so there's so much research on it. Amy Edmondson, if people are looking interested in doing a lot more on this, Amy Edmondson, has written so much about this. I'm far from an expert in it. When I start to think about this, this topic and trying to just figure out from the start, do we have it on our team? I start to pay attention to not just things like body language, but also how many questions are being asked in team meetings? Are people pushing back? When people push back? How does everybody else react? You know, how is that as how safe is it to be wrong? But how safe is it to ask questions? To provide other solutions, or just to say that something feels bad or wrong. If none of those things are happening, you don't have psychological safety on your team. A failure mode would be to think everything's fine because no one's saying anything. The opposite is true. So when I think about this stuff, I think a lot about using coaching skills and active listening skills to provide a sense of like, Hey, I'm listening, I want to I want to make things better here. I want to support you, as you grow as a person. And try to understand people as individuals, and then the most important thing for me as a manager is following through and they commit to, for me that like, you can't ask for trust, you got to like demonstrate that you deserve Trust has a lot to do with saying is doing the things that you say you're going to do. And for me, that's a huge core piece of creating psychological safety on a team.George Stocker  39:47  Nice. Now that, you know, it's not always good news. As a manager and leader, you know, how can I either How can I deliver that's a great news through their mind Boss or my team? And you know, what does that look like? What do you recommend?Lara Hogan  40:03  Yeah, so there's so many different ways to go about this for me, I just see so many failure modes here about trying to dance around a problem, or trying to over explain, there's a lot of a lot of things that I see when it comes to people leave managers being nervous, deliver bad news, as much as humanly possible. Bottom line, the news that you're that you're trying to deliver meaning in one sentence, what's the point? Then you can also add more context, especially if you give people time to ask questions. But I would say get practiced and bottom lining and being really, really clear. I don't mean being a dictator. I mean, just stating a fact or stating what the thing is happening. If you've got bad news delivered to your team, it's coming down from above you. It's really important to not just bottom line, what that news is, but also provide some context that's yours. So like, Okay, listen, here's the deal. layoffs are coming. My personal On this is blah, blah, blah, blah, blah, that might be, here's what I think is going to happen or what's not going to happen, which is risky to say that might be, here's what I'm going to be doing to support you each as we move forward. That might be, hey, here's what I'm going to follow up on next to get some more clarity information on this, whatever, whatever the thing might be, give it give your perspective or your I'm not gonna say spin, because that's that means like making it false. But how are you feeling about this? Or what are you seeing about this, try not to make it at all about your feelings, because that's going to feel very weird. But the final thing to close with is when Can people hear from you next on this and in what medium? Mostly when people hear bad news, all they're doing every single day following that is waiting for the other shoe to drop. So letting people know hey, next Thursday, we'll have another update for you on this via slack or in our team meeting or whatever. Or hey, the next thing we'll do is talking one on ones about this. That's can be that can be so clarify and give people the certainty predictability they need about you know, in a very otherwise ambiguous, awful situation. One littlesliver of predictability going forward.George Stocker  41:59  You One of the things that we happens in tech in it, it feels like it happens in tech far more than other industries, although I have no data to back that up. His turnover is there's a lot of turnover in tech, from your perspective. And from the teams. You've worked with your Do you see that as a manager admin thing, are you so that's purely because of, you know, compensation and benefits, it's easier to get better if you jump? What does that mix look like from your perspective?Lara Hogan  42:28  You know, it's really interesting, the retention rate stuff, it's just mired a lot of complexity. Like I see some HR folks or executives bragging about how low turnover they have is actually I learned there's a healthy amount of turnover. If you've got too little turnover, it's actually unhealthy. So there's, there's like a, there's like a threshold. That's normal. I couldn't give you numbers on it, but like this, you got to ask yourself, Am I in the correct pressure, there should be some kind of healthy change internally. A lot. The folks that I coach, if they're leaving jobs, it's because they're perceiving things to be unfair. More often than not people who I coach are members of minoritized groups, and so they might be perceiving a wage gap or a promotion rate issue, when you look at minoritized groups compared to, you know, non minoritized groups. So it's been really interesting to support these folks, which is obviously a good niche of the population as they choose to change jobs because there's also a lot of risk involved. When you when you change organizations, that means you are introducing a bunch of numbers about how you're about to be treated and how fairly or not you're about to be approached. And so it's Yeah, it's, it's just layered in complexity. So I would say again, if you've got too little or too little turnover, take a little look at that, because probably it's time for some people to go. And you've got too much turnover if it feels like it's too much. Ask yourself, how do I know what can I look at to see See if this is a healthy amount, because the act of you believing is can be really healthy. So check triple check with yourself who's leaving? Is it kind of normalized across the board, there's an article that I wrote about wage equity and promotion equity that includes some tips on how to measure across different demographic groups, what your retention rates are and what your promotion rates are to triple check that nothing is, is wrongacross the board.George Stocker  44:27  The one of the things that I'll say to new managers is the first thing you should do as a manager from a numbers perspective is probably it's not the first thing you should do when you meet your team, at least my numbers perspective, you should see you should know what your people make, and you should make sure that you equalize it, you know, bring people up if they're not making what they should be making, try to bring them up immediately. Because that will, that will, that's a way of building trust. When you come in you say hey, look, this is what I see. I'm putting in for that. That's a fast way of building trust of showing them You care and of making sure that you do have justice, in equity and pay on your team, which we all want. We're in tech and one of the richest industries in the world. If we can't pay people what they're worth here, nobody can. And so we should be doing it. Yeah.Lara Hogan  45:17  It's amazing to me that the traps that people in mental traps if you volunteer around this, like they think there must be a reason why this person is being paid less. We default to like, what are the specific unique circumstances under which this person is being paid less rather than saying what you just said, which is, let me pay people equally first, and then we can figure out the rest later, which I think is going to save you a lot of heartache.George Stocker  45:39  Yeah. Maybe we maybe it's just a you know, a mental thing where we're like, Well, clearly they didn't do something right. And we'll I don't have enough information. So I shouldn't change things rather than wait a minute. These are my people. I'm responsible for them. I need to into your trust. I need to be their leader. And starting from there, which you might fail like, there might be Be a good reason why they're not being paid off. But that happens a lot less than, you know, all these assumptions that you talk about all these prejudices and these biases, that that stops someone from getting the money that they actually need and deserve, like,Lara Hogan  46:14  precisely. And if there's performance issues, you deal with that with performance management, do that with feedback. You don't deal with that with compensation, and inequity and compensation and so I maintain paying people the same for the same job is one of the most obvious things to me that still is causing a lot of issues in our industry.George Stocker  46:34  Yeah. Laura. So people, how can they find you on the internet? How can companies get in touch with you to do coaching and what do you want to leave us with?Lara Hogan  46:45  Yeah, Laura underscore Hogan on Twitter and we are wherewithall.com for all your coaching and training needs.George Stocker  46:52  Buy the book and schedule a coaching call with Laura. Laura, thank you so much for joining me today. I really It's been a pleasure having you.Lara Hogan  47:01  Thanks so much for having me.George Stocker  47:03  All right, folks. That's it for this week. We'll see you next time on the build better software podcast. ThanksTranscribed by https://otter.ai

Dapper: https://github.com/StackExchange/DapperTranscript (Powered by Otter.ai. Please send corrections to george@georgestocker.com)Hi, my name is George Stocker, and welcome to the build better software podcast. Today we are talking about object relational mappers. Now object relational mappers or ORM s, as they're commonly known, are used by developers and development teams to not write SQL. Now here's what I mean by that. Whenever you're using a relational database, somewhere, somehow you have to write sequel object relational mapper does that for you. Here's how it does it, you create a poco in C sharp, or a plain old C sharp class, and you decorate it with some metadata to tell your ORM that this class represents a table in your database. Now whenever you ask the database for the information from that table using C sharp code, and if you're using C sharp past link 3.5, and you're using some form of language integrated query or link style queries to pull data from the database It translates your link into an actual SQL statement that gets executed by the database server. Now, this is really cool. If you didn't have this, you'd always have to write SQL in your code, map that SQL when it returns a data reader or some other type of database representation of the work you're doing into your classes and be a lot of mapper code back and forth by using an ORM. You don't have to do any of this. Sounds great, right? Shouldn't everybody use orams now? And the answer to that, of course, is no, they shouldn't. Now let's talk about why arms are good when you need to pull out data that roughly matches what your classes look like. And there's nothing too difficult about those, however, or I'm start to fall apart when you need to do more complicated queries, or when a query has lots of relations. Since forums are meant to pull data back and map it to your class automatically, they work really well in simple scenarios. But if you find yourself operating at scale larger than you already can handle, then you have to start and tuning those queries that it generates. Now, the API for doing this varies from Rn to Rm. But all of them have the same thing in common, which is, they don't exactly have the same API that you would use in the database itself. For instance, if I wanted to create an index in a database, tonight would use a create index statement. in SQL Server. If I want to create an index in let's say, Entity Framework, I have two different ways of doing that. I can put the index attribute on a field or fields, or I can use their fluent API to create an index. Now none of these are just as easy and as universal as Creating an index using the databases technology. And when it comes time for me to tune the queries that use that index, it's going to be far easier for me to do that in SQL Server Management Studio than it would be to use that translation layer that the ORM would provide. Because of this, using Rmi. To create queries that need to be finely tuned, is generally a mistake. Now I'm not dumping on RMS here. The fundamental problem is that we use relational databases far too often, even when we don't need them, or EMS make it easy to use a relational database. But it makes it a lot harder to tune our code, the way a relational database would expect, in most cases where we feel like we actually need a relational database, it's more of a vestige of inertia than anything else. Not all use cases. Is are meant for a relational database, if you have relational data, and that is data that actually has relationships to other data, then consider a relational database. But if what you really need are lookups by an ID and your data fits a non relational model, consider not using a relational database using something like a document dB. Now, object relational mappers, they again make it easy to write plain classes that translate to tables and they reduce your need to write sequel. One of the lesser advantages these days of using an ORM is that you may be able to switch out your database still keep the same order. This is sometimes touted as an advantage I have yet to see it happen in person, although I hear it's happened before. It's not one of those advantages I would count on. They do reduce your need to write SQL and they allow you to do Ogg pulling data back from the database into your integrated development environment like Visual Studio. They're really good at things like when you don't need SQL or you don't care if your SQL is highly performant. It's really good to use an ORM when you just need to get a prototype working. It's also really good to use for small projects, personal projects, school projects, things that don't have high load considerations. And it's really good when your team and business context is such that speed to market is more important than maintainability and scale. It's also good when your team doesn't have a dedicated DBA. And you'd rather make changes in code than modifications to the database. Now, I don't say all this to say that, or EMS can't scale they can. Many large teams use alarms for high traffic systems and they work. The problem comes in is that you end up doing a lot of hand tuning to make it happen. If you don't, you end up dealing with two different API's both the database, which has been around since the 70s, and your ORM. And its documentation. This is problematic for most teams. And in general, the more layers you add, the more dependencies you add as a team, the more you have to understand to get new work done. That isn't safe. Don't use an ORM. But it is to say, make sure you're getting the value from the ORM before you commit to using it. Now one issue that tends to compound the problem of using ORM is teams were the idea of consistency of data access is more important than ease of data access. Here's what I mean. If a team says we're going all in on Entity Framework, you must use Entity Framework code first, for all database work. Now immediately, anyone who's used Entity Framework code first will find the problems with that statement. Entity Framework code first does not have first class citizens like views. So if you need a view, you can't even do it through code first. Now, other problems crop up, and they're small problems. Some are some aren't. But they all come down to, there is no ORM out there, that gives you the entire API available to your database. And if you don't know your exact use cases, present and future, then you run the risk of running into problems, when you say consistency is more important than ease of data access. An easy way to get around this is to say you know what, in some cases, we will use RMS and others we will not make that a part of your planning discussions. Because sometimes solve a problem, the easiest way to do it is to read a database index, or a database view, or a stored procedure, or report. And those are things that orms generally have problems with. Now not all teams should consider ORMs. I typically shy away from ORMs entirely. If I need one I'll use a micro ORM like dapper. When I need that simple data access from column to C# property. When I need anything more complicated or anything where I need to tune it, then I'll write my own SQL in code and go from there. This works out well, Since Dapper takes care of that mapping between Column and C# Class Property. RElational Mappers are also not for teams that have dedicated DBAS. And when I talk about dedicated DBAS, I mean DBAs that can help you tune queries and help keep the Database at peak performance.  Probably just insert a translation layer that will be harder to debug, and harder to tune. And if your team has a good understanding of SQL, relational database engines, maybe you don't need that ORM maybe the time it takes you to translate code into SQL isn't enough to justify the cost of an ORM. And that's really what all of this comes down to is cost. What are you getting out of an ORM? And what are you paying for using it? And the answer is never nothing. You're always paying in something, even if you don't know it yet. That's it for this week on the build better software podcast. I'm your host, George Stocker, and I hope you'll join me again next time. Transcribed by https://otter.ai

Josh Heyer (Pronounced "Higher", sorry Josh) aka Shog9 can be found at shog9.comJosh is a Developer Advocate for Enterprise DB https://www.enterprisedb.com/Twitter: @shog9Jon Ericson : https://jlericson.com/ and on medium at https://medium.com/@jlericsonTwitter: @jlericsonI uploaded a remixed version that should result in a higher volume for Josh Heyer on 10 July 2020.  If you listened to it before then and were annoyed by the levels; that was my fault, and I hope I've fixed it. If not, please reach out.Rough Transcript (Powered by Otter.ai -please submit corrections!)George Stocker 0:00Hello, and welcome to the build better software podcast. I'm your host George Stocker, and today I'm joined by john Erickson and Josh hair. Welcome to the show.Josh Heyer 0:11Hi, hello,George Stocker 0:14john and Josh, for people who may not be familiar with who you are and what you do. Tell us about yourself.Jon Ericson 0:21Sure, we both talk at the same time.George Stocker 0:23One, one after the other.Josh Heyer 0:26To talk over somebody.Jon Ericson 0:29If we let you talk first, this will be the end of the episode, right?Josh Heyer 0:33Yes, that is plausible. I'm just this guy, you know. So, john. Uh,Jon Ericson 0:40well, you probably if you know me at all, it's because I was a community manager at Stack Overflow and Stack Exchange. I did that for almost seven years. And and now I am a community and product operations manager at college confidential, which you is a forum site for people who are applying to school for college and universities?Josh Heyer 1:09Yeah, that's a good intro. I'm going to just steal that. So pretend I said what john just said, except replace seven with nine and replace college confidential with enterprise DB or EDB. A Postgres company.George Stocker 1:24Cool. Now, I'm not gonna let you get away with that either of you know, yeah, so Josh, you were actually the first Community Manager hired for Stack Overflow, as I understand it, you were IJosh Heyer 1:36was, I was, let me see. 123 I was either the third or fourth. I'm gonna say third. It was Robert cortino. He was number one. Although we all had different job titles in the early days. I don't think we settled on Community Manager until like a year. He was Robert could Hannah was was the first year Community coordinator. And then and then it was Rebecca turnoff. Remember Rebecca?Jon Ericson 2:08Yeah, our turn Archer and yeah,Josh Heyer 2:10yeah, she was she was number two. Now. Now see, Rebecca was Rebecca was not originally community coordinator. She was I think it was community evangelist or developer evangelist, something like that. And then we all we all kind of coalesced on Community Manager after a while, as the least offensive generic name we could come up with, I was never comfortable with evangelists. That was that was what Jeff suggested to me. Right away and I was like, man, and then I came on as adjunct community coordinator, yeah. And working part time for the first year. Just kind of trying it out to see if, see if maybe the company just go under. I could save myself some work. And when that didn't And I came on full time in 2012.George Stocker 3:03Yeah. And so you know when to remember back in the day these this is 10 years ago is that community management from a public internet community perspective was still very new. And in fact, the only way I knew of it was through video games was that places like dice had community evangelists and community managers that helped manage manage video games, or manage the communities for video games. So, you know, in this fresh new world of community management, how did you all acclimate to that job?Josh Heyer 3:39So first, I want to say video games are like, the trendsetters in this field. They, they they were and still are kind of leading in terms of what it means to manage a community because I have I think they figured out way ahead of just about everybody else that you, you really do need people who are focused on that specifically, a lot of other companies had people doing similar things. But it was almost like, you know, this is something you got to do in your part time, above and beyond your real responsibilities. and video games pretty quickly figured out especially the massively online multiplayer versions, they figured out that, oh, we actually need to culture to nurture to guide this community of people that we depend on in order to, you know, have a viable game and, and put focus squarely on that. So we took our lead from that in a lot of ways. JOHN, we brought in because He was super awesome in our community. He was writing stuff that was better than what we were writing. Okay.George Stocker 5:13So how did you how did you come to be at StackOverflow? JOHN?Jon Ericson 5:17So I was I was a beta, user on stack Stack Overflow, and then I threw a fit, because I didn't like some of the things that Jeff was doing. I thought closed, closed votes, some closing questions was dumb, like, Are we going to run out of bits on the internet? And so I quit and then and then Stack Exchange came along, and they're all these crazy sites. And I was like, Oh, these are interesting. I thought gardening and philosophy. That was my, that's gonna be my entry back into it. And it turns out, it's hard to do gardening when you only have a little apartment, condo thing. AndJosh Heyer 5:57fluffy is great man space.Jon Ericson 6:01I so I knew so little bad gardening, and I've got a house now I actually could use the gardening site. And then, but the thing that really got me going was biblical hermeneutics, which is about interpreting the Bible, which was really something that I still am fascinated by. And so I got into that. And I think what Josh was saying, at one point, there was a bunch of controversy over what the site meant. And I ended up spilling tons and tons of digital ink on the meta site. So why not workGeorge Stocker 6:39biblical from a memetic? site? mentor? What what what almost almost likeJosh Heyer 6:43hermeneutics and exit Jesus are not words you use in everyday conversation? IGeorge Stocker 6:48can't even pronounce them.Jon Ericson 6:51Yeah, so. So the difficulty with biblical hermeneutics is that some people look at that and they're like, Oh, cool. I'm going to be an evangelist, too. pick up another word that Josh isn't a huge fan of.Josh Heyer 7:05For people who actually legit are evangelists I don't I don't feel like it's a great job title for people who are, you know, doing community management?Jon Ericson 7:15Yeah. Well, I guess it is a geeky connotations, right?Josh Heyer 7:20It is located. Yeah, it is complicated. You you there was another word by the way that you you guys struggled with a little bit unexpectedly. And that was biblical. Yeah.Jon Ericson 7:34Why? Why is that?Josh Heyer 7:35Well, different people have different ideas of what the Bible is.George Stocker 7:40That's right. Catholics, we would there, you know, five extra books for Roman Catholics in the Old Testament that aren't present next version.Jon Ericson 7:52And those five books, I mean, this is a huge, huge problem for us. So we got to, we got to excommunicate you. You're not A lot on our site.Josh Heyer 8:01And then there's there's like a whole group of people who who consider, you know, the entire New Testament, even calling it the new testament to be.Jon Ericson 8:12So but uh,Josh Heyer 8:14yeah, yeah. SoGeorge Stocker 8:16this is about to become a Bible podcast, podcast where we talked about we can totally make it No, no theJosh Heyer 8:22head during this period when we were launching these sites, we would have I kid you not three to four hour conversations every day involving the team, we would try to hash this stuff out, really. And clearly, we didn't succeed because the problems were still in existence when the site launched. And so john got stuck with them.George Stocker 8:41So how do you do that as a, as a community manager, you know, you're you have this new thing. You know, in the case of Stack Overflow, obviously, it was all new to everybody. But by the time you're getting to this biblical forum site, you've got, you know, you've got, hey, we want to put this thing out there. We're gonna have Have people using it? How do you? How do you make any of that happen?Josh Heyer 9:08So prayer for peace in war, wait, the opposite of that.Jon Ericson 9:14I was gonna say it's not necessarily given that people will use it. And so like, I think that's a that's a problem that like, it's actually a nice problem to have if you've got people are using it, you're like how we're gonna direct it so that it's, you know, people are playing nice with each other. And my philosophy was always a like, give empower, empower the users to make the space what they want, which is why I ended up in lots of controversies over like, Hey, why don't we just let those Catholics talk about those extra five Bible books? What What do I care? It's just another question on the site. And other people like no, no, no, that's that's not that's not what it is. And so my philosophy was always like, Sort of cliche, but sort of democratize the community, like make it so that everyone has a say everyone has input into it. I wonder if I wonder if shark has a little different perspective on the thing?Josh Heyer 10:15No, that sounds all about.George Stocker 10:18We'll see. So why are you sitting up there on the Bible site, you know, Josh, or shark and you'll hear us call them refer to miss shark throughout this entire recording simply because that's how we've known him for years. But Shawn, you are dealing with the expansion of Stack Overflow, and taking over from really being the full time voice of community management from Jeff Atwood from the founder of the site, and you started doing, you know, those those public interactions with communities that he used to do.Josh Heyer 10:51Tell us about that. Yeah, so what do you do when you have Have a very very opinionated voice effectively leading a community that just suddenly disappears. I, I struggled with that problem for a while because I didn't particularly want or think I should be a replacement for that voice. I didn't feel like that was appropriate for numerous reasons. And I quickly repented of that attitude because what actually happened was Oh, to use a biblical analogy, the Book of Judges, every man doing what was right in his own eyes. You ended up with chaos. To to bring us forward a few thousand years. We we had the The chaotic natural law that Thomas Hobbes wrote about. You can have people all with very honorable reasons, doing what they feel strongly is the right thing and still end up with all at war. Because those those perspectives conflict, people try to make use of the same resources in different ways in different ways that are not compatible with one another. And if you don't have somebody willing to come in and say this is how things look, and this is the way forward. There is no possible resolution to this. And in fact, we've seen in human history over and over again, where these situations arise. Someone will always take on that role. And if you if you don't, if you try too hard to avoid that, all you're really accomplishing is setting up a situation where you have no influence, or you have no voice in the government that is eventually constructed. AndGeorge Stocker 13:27decisions are made by those that show up.Josh Heyer 13:29Decisions are made by those that show up decisions are made by those who are willing to put the time and willing to put the effort in to to convince others. And I, I came into StackOverflow in 2008, with a very strong opinion about what I wanted the site to be. And I didn't presuppose for a moment that that was the only opinion or that that was necessarily how it should come out. But I wasn't willing to stand by and see it, turn into something else.George Stocker 14:00Now you've got that you've got those users. And that goes to the to the point of the show today is that community is an integral part of software, whether that software is a public q&a forum. Oh, sorry, not forum, public q&a site, or whether that software is really incidental to the problem being solved. But you, but you have people, and you're always going to have users and they're always going to have opinions. And as software developers, we need to effectively mold and fashion those opinions, and listen to those opinions to help us produce good software. And that's why I have both of you here today, because you have different takes on that. And you're both in different verticals. Now. Both of you started out Stack Overflow, which is, as you said, a very opinionated place. And now you're dealing with different types of communities. How do you form for teams that may not have what StackOverflow had was a very public presence in a very public way of managing your community. How do you find your users? How do you interact with them if you're not dealing in such public software?Josh Heyer 15:14So first I want to say you don't have to you can you didn't totally blow him off. I mean, that's, that's an option you have, it's not necessarily a good option. But if you don't have the, the desire, or the wherewithal to, to handle dealing with the community, you can you can't really ignore it, but you can absolutely squelch it. Apple is fantastic at this site, a very large example they they sort of have a community in spite of themselves.George Stocker 15:54Are you referring to the latest with the no actuallyJosh Heyer 15:57that if you're talking about DHH? No. No, okay. I, I i've been using them as an example of this for years, I think they, they tried very hard to sort of keep their community at arm's length. And, and that works for them. I don't think it will work for most companies that their scale. It's definitely a risky move. But that's how they do things. And it's not, you know, it's not a accidental decision that that attitude pervades their organization. And, and they, they work towards that from many, many different angles in their development and rollout processes in their marketing in their support organization. I I wouldn't Recommended. But if you got a Steve Jobs complex, and you really want to go whole hog on it, yeah, by all means, throw up the middle finger to your community and just roll on and see how that works out for you, john?Jon Ericson 17:18Yeah, so the question about how you interact with thick meat, it's, for one thing I have to say we have, like college confidential is a form. It's so freeing, I can say forum and no one would yell at me. We actually have forums, that's the adjustment I'd make. It's not one forum as many forums. And and I agree like you can, you can totally play hands off with it. And, you know, things things can could work that way. That's, in fact, the model that I stepped into was, they didn't really like the people who own the forum didn't know what to do with it. They didn't have necessarily a vision for it. They just sort of fell into their lap. They bought another A couple of years part of this company. And and so when I stepped in the one of the things that I decided early on was I'm going to engage with the community. And that means, like, I do some posting, I happen to have a son who is considering school, going to college. And so I have, I have a voice I can, I can talk about what I'm experiencing, so I can be part of the community. And then and then there are spaces within you know, like, one of our forums is for parents, and I can talk directly to the parents on the forum via that space. And I try opposite of the apple approach. I I don't have a lot of secrets. We don't have big reveals. I kind of considered a mistake if people find out about something, the day that we release it. And that may work for Apple but it doesn't work for for our team because Our community wants to have input, their input is actually valuable. Like we've seen, we had a major redesign. Last year, this is before I was part of the company, and it fell on its face, because none of the user feedback was was incorporated into the design. So I just like I feel like it's a pounding the pavement, go out, meet people as much as I can shake babies and kiss hands, is that what you're supposed to do as a politician? sounds right. The other way around.Josh Heyer 19:38All of those words are in there somewhereGeorge Stocker 19:40in some form or fashion. So that that's interesting, because one of the issues that we all have, most recently that I dealt with was through slack or slack changes or UI, and they're like, Hey, we're changing our UI. It's so awesome. I looked at I don't know how to use this anymore. And we even see to a certain extent, with StackOverflow when they would make changes, and you'd get the people who were really invested in, in the software as it was saying, like, Hey, you move my cheese. How do you deal with that as a community manager?Josh Heyer 20:14I got opinions here. So first of all, I want to address the idiom there. The moving cheese corporate table is complete bullshit. Anybody want to argue about that? No.George Stocker 20:34I want to hear why it's complete bullshit. Because this is gonnaJosh Heyer 20:36be good. No, no, it's okay look. as as as as creatures. We are optimized from top to bottom for efficient use of energy. Our brains are muscle memory. our nervous system chews up a massive amount of energy both in thinking and in mistakes. When we have to retrain, there's a huge cost to that. I mean, you can think of a simple example, something you do every day some, some some little tool. You're you're moving from, I don't know, a pair of scissors to a left handed pair of scissors, and suddenly you have to figure that out. You're gonna be super annoyed if you I don't know if you're one of those people who's super into keyboards.George Stocker 21:41I'm not but I know people who areJosh Heyer 21:43you Do you know what I'm talking about keyboards. I hate I get flustered and irritated if I got to move to a keyboard when they put the return key in an L shape instead of a bar shape like God into But there are people who will switch up between normal keyboards and split keyboards, and cord keyboards and weird little keyboards that like scatter their keys all over creation and, and retrain themselves on that. And you know what if that's your hobby, more power to you, but I just want the words in my head to appear on the screen. I don't want to have to stop and think about it. And I would argue that most people are in that same boat. We don't want to expend energy to accomplish a task we already know how to do.George Stocker 22:37So how do you help the community when you have something like a redesign or a new feature or a change in a workflow? They're used to FirstJosh Heyer 22:44off, you're starting at negative 100. Right? You you assume that when you go to announce this, your post, it may not reflect it yet. 100 people hate it right out of the gate. And then you have to dig yourself out of that hole, right?George Stocker 23:11SoJosh Heyer 23:13don't come in with the idea that hey, I'm gonna roll out this huge, impressive, shiny new feature. And everybody's gonna love it. You may love it. You've spent three months thinking about it, maybe longer. Nobody else has. The first thing they see is wow, I have to expend energy. I have to burn hours of my precious life and calories that I worked hard to obtain in order to do the same thing I was doing yesterday.George Stocker 23:48No, that's an interesting change. I hadn't thought about it like that.Josh Heyer 23:52So that's, that's where you're coming in. You have to dig yourself out of that hole. You have to you have to crawl up Out of this pit that you were starting in, how are you going to do that?George Stocker 24:05That's why, tell me,Josh Heyer 24:06ideally, you don't, you don't dig a pit with straight wall sides, right? You You spend those three months that you're working on this thing. digging a nice, gentle ramp down into there, you you lay the groundwork for this explanation you're making for this announcement, you go and talk to people in your community. You shop around the idea, you find ways to address concerns more than anything, you find ways to convey the advantages that this change is bringing that they might not have thought of. But once they get it in their heads that hey, yeah, this is going to cost me time and energy in one regard. But in the long term, it's an investment, it's going to save me time and ever or maybe it's not going to say anything. Maybe I'm going to have to pay a cost but for some others portion of this community, it's going to be a win. If you can get all that stuff together, especially if you can get a cadre, a posse of people in your community who are already on board, when you make your big rollout, then you don't have so much work to do. You've got that nice ramp out of your pit that you can just roll up out of. You've had all of the arguments before you have honed your presentation, your your your announcement, to the point where any concern somebody raises. You're standing right there to address it. You have the phrasing and the presentation ready to go. I was telling somebody earlier today, I've written a tremendous number of announcements in 30 minutes or less. But in all those cases, I have spoken Then months preparing to write that announcement, I've spent months doing the research doing the the acclamation to the concept that I'm introducing to the design that I'm presenting. If you don't put that prep work in, it doesn't matter if you spend a week agonizing over what you're writing. It's still gonna go over like a lead balloon.George Stocker 26:27JOHN, I see you, I see you nodding.Jon Ericson 26:30I can totally concur with that. So an example that some of you may be aware of, we had this project called documentation. And documentation was for Stack Overflow for Stack Overflow. It was built in a in a lab. No one was allowed to enter the lab, and then they float open the doors and people are like, What is going on? And you know, I thought that was a fun project to do. It had a lot of nice features to it, but it failed and So that, you know, you're kind of doomed both ways if you do a poor job of announcing it, and then you get people who actually figure it out and are enjoying it, and then you have to shut it down. Like, that's another, that's another spot where people have gotten used to Google Reader to name an example. And now you're taking it away. And you're saying you can't use this piece of software anymore. And so at the same experience that Josh was talking about, where, like, it literally took me a couple hours to write the worst sunsetting documentation, meta post. I did it, you know, a few hours in the afternoon. But that wasn't the first time I had thought what we were going to do when we shut down this documentation. I had written six months before a like, this is what I'm going to say when we shut down documentation, which I didn't, you know, broadcast to anybody in the company because like, you don't want be labeled as the Put Doomsayer. But But I had that ready. I knew it was, it was a possibility. And so I had been thinking about it for four months. And also like, what's my victory lap? going to be? So like, I had those thoughts in mind. So what what sharks that is absolutely true.George Stocker 28:19So that gets us to a touchy topic is telling your users The truth is how is dealing with the fact that you have users of your software who are invested in it. And you have to tell them something that they don't want to hear. What What do you do? How do you do it?Josh Heyer 28:48So first off you you need to understand why you need to understand why they don't want to hear why they're apprehensive. Second, you need to understand why you You need to tell them that why why they need to hear that why you're doing the thing that you're doing, or can't do the thing that you're not doing. If you don't understand both of those things, then you're really not going to have a good time to communicate.George Stocker 29:22You work for enterprise DB a company. JOHN, you work for college confidential. A company, Stack Overflow is a company and companies exist to, you know, put money in their bank accounts so that they they exist day after day. And but your users don't have that point of view your users are theyJosh Heyer 29:44absolutely can.George Stocker 29:46They can, but I, in my mind,Josh Heyer 29:49the fact that companies need to make money.George Stocker 29:52Yeah. So how do you square that circle where you know, you're like, Hey, we got to shut down documentation. It's not making any money right? losing time losing effort losing money and you've got users that have put hundreds, if not thousands of hours, probably only hundreds because it didn't last that long. They put hundreds of hours of their life into it, like how do you how do you tell people the truth when the truth is, you know, money based when the truth is, you know, a misalignment of, I guess values.Josh Heyer 30:26So, I think john actually did a really good job of this. In terms of communicating that thing. If you go back and look at the documentation project, there were a lot of mistakes.Jon Ericson 30:46A lot of mistakes, as I said,Josh Heyer 30:49and these mistakes were not a secret. They were called out at the time or Very shortly after they were made,George Stocker 31:02some seem tactical now for our audience, people who may not be aware of what this is documentation and I'm going to say a little bit about it and you guys fill it in, fill in the parts I missed documentation was an effort to expand beyond question and answer and actually go into the things that we saw from poorly maintained documentation across the internet for programming, API's frameworks, all sorts of things related to programming, either library or framework, what have you, and actually putting the documentation with examples in a way that was easily searchable, editable, and stayed up to date. Now, that's how I saw it. How did you guys see it?Jon Ericson 31:42So you mentioned the key word, and you just slip right past it. examples. So the concept was, it wouldn't just be replacing the documentation. It would be giving you examples, focusing on code that people could have read and understand. And so there was debate about whether the whole thing should be called examples or documentation. And naki toots Yes, I forgot about Dr. toots. What is Dr. toots? documentation tutorials?Josh Heyer 32:17Ah, the compromise solution you see.George Stocker 32:20Now it's funny as you say that, you know, documentation has been tried multiple different ways across the internet. There's read the docs. There's a few others that I can't offhand mention, but I know exist. And documentation is just slides always. This is a bland usage that no one actually ever uses it that way they use it, you know, in furtherance of something else that the documentation never covers. So why not examples? Why did that lose? Because that sounds like a really nice reframing of what it did.Jon Ericson 32:55Why did that lose? So So like, it's part of it as politics like internal politics, but part of it is just like, documentation sounds like a bigger idea than examples. Right? And so there's this temptation to say, Okay, if you've got two choices, we can do the grand idea, or we can do sort of the focus, practical idea. And your odds of of accomplishing a focused practical idea are better than the grand idea. But, like, oftentimes, it's easier to sell the grand idea internally. Like, you say, documentation means so many different things to so many different people. And it can be more people signingJosh Heyer 33:41on because they think they're signing on to something they want. Exactly what you're actually doing. This by the way, it comes back to my thesis of you have to know why you're doing what you're doing before you start writing.Jon Ericson 33:57Yeah,Josh Heyer 33:58so that sounds like all almost almost a tautology, right.George Stocker 34:02Right. But it is truism. Yeah,Josh Heyer 34:04it it it is. It is a something that a great many people, including myself, strive to avoid in almost every project because it requires work up front. He requires discipline to define what your goals are and what your goals are not. It requires discipline to be precise in your wording, which we all hate. And it, it requires, it requires work. It is way too easy to come out of a meeting. really psyched, just just really jazzed about this thing you're doing. And then to sit down and start writing it out. to shop that idea round to the other people who are on the same call. You were And to suddenly realize that, number one, it isn't actually as exciting as you thought it was. Number two, we don't actually all agree on what we thought we had agreed to build. And now, you feel like you've lost momentum, right? You feel like you've done this thing, which was tedious, and took a lot of focus to do. And it hasn't bought you anything. It's cost you the energy that you were going to use to build it. So you have this kind of innate motivation to not do it. But of course, we all know where that leads. George, you talk a lot about test driven development, and I think this fits into the same boat with that. It isn't a ton of fun to write tests, especially to write tests up front. And worst. Once you have that, you find that your code is failing. those tests like all the frickin time, and you got to go fix that instead of just, you know, getting in the zone and speeding away, right and page after page a logic that you're pretty sure is rock solid. It feels like it saps your energy.George Stocker 36:15You're right. And you said it earlier and it wasn't about test driven development No, it could have been is that you've got to know what you're trying to accomplish while you're trying to accomplish it. You've got to have a crystal clear picture of your goal with TDD. Otherwise, you'll get halfway through and realize, wait a minute, the way that I thought this architecture was going to flesh out doesn't work. And oh, by the way, all that stuff I did, it's got to go away. And nobody, nobody wants that.Josh Heyer 36:39Well, so that's it, right? It's an investment. You have to look at it that way. You can't look at it as like this is this is going to be the fun part of the process. You got to look at it as like, this is gonna save me so much stress and time later on. It's an investment in The future success of your project. And it's absolutely just as true for you communication as it is for the actual code you write.Jon Ericson 37:12One of the things that happened on documentation was, we didn't do some of that investment. Ironically, there wasn't enough documentation, run documentation. And we showed it to people inside the company. And the first time we sat down, did a like a usability interview where we just said, go here, show me what you think you should do. People had no earthly idea what to do. Like the goal of the project was confusing to people using using it the first time. And that meant we had to throw away a bunch of work that's been done or revamp it or change the way that it worked. And it just seemed tedious like, Well, the problem isn't my software. The problem is these people who don't understand The very obvious thing that we're trying to do, and and it's so easy to overestimate how quickly people will pick up on something because we spent six months or something, some number of months working on it. And of course, it felt natural to us. We'd seen happen built from nothing up into this, the system. So super easy for us, but you throw an average person and say figure it out. They need more than that. They need a lot more because they canJosh Heyer 38:30catch up. I struggled with it. I just figured you guys were smarter than me. We were smarter than you.Jon Ericson 38:38See, here's the problem. Like you can't just like there's not enough people who are as smart as we were. That's why it failedGeorge Stocker 38:46you everybody has to be at this level and we're trying to ride this ride. Now I'm gonna I'm gonna ask a question and this is purposely a loaded question for the sweet summer children among us that have never dealt with this but why not just assigned personas and why not just build software to those personas? Why deal with community at all?Josh Heyer 39:06That's George, that is a fantastic idea. As long as your community is composed entirely of fake people, it will work 100% of the time. Um,Jon Ericson 39:18yeah. So I'm working with a great marketing department, and that should not come out as sarcastic as that might sound. Like, honestly, they're wonderful. And they came up with these personas. And I looked at him, I was like, Wow, that is fantastic. This is great. This before I really knew anything about the community, and I started meeting the people in the community. I was like, which member which persona is this one? And, and then later, I did a poll, I tried to do a poll of who's actually using the site. And we had three personas for less than 20% of our population. And we had four personas total. So that one persona had to take on a lot of stuff. Yeah. Yeah, and so it was it was all wrong and like we're still using them. I mean, there's nothing wrong with having those personas from a marketing perspective. But you have to realize it's, let's call it aspirational. These are the people who would like to be using the site. But to get to that point, we need to actually work with the people who are using the site. We can't be you can't live in the aspirational space, you have to live in the space that you're where the work has happening already.Josh Heyer 40:29You ever done that thing, where you're like really dreading a conversation. And so you rehearse it in your own head, like and you make up the responses that the person you need to talk to is going to be given to you and somehow, you know, after a few practice runs, maybe that conversation just goes off perfectly. You You have no snappiest responses to to every reply you get from this figure of your your target In your head, and and then you go to have the conversation. And they got the temerity to not give any of the responses that you imagined them giving and instead say completely other things and you're sitting there stumbling over your words, trying to figure out why they're being so rude to you. And, and now let you just pair it all of the candy lines that you have so diligently rehearsed and eventually it dawns on you that you know maybe I didn't really know the person that I intended to talk to. Maybe I just thought I did.Unknown 41:40Mines meJon Ericson 41:42reminds me Shaka, you make a terrible straight man. Like you do not respond the way that I expect when I asked you a question. So all my fingers that I've been preparing weeks in advance, they just fall flat because you didn't set up properly.George Stocker 41:57Ah,Josh Heyer 41:59there's a there's A tangential story I could tell there but we're, we're at about 10 minutes or something, so I'll leave it for another call. But, you know, this is the thing people are people are complex people or rich people are like, like a, you know, a good craft beer. You can expect a good solid glass of Coors banquet. But that's not what you're gonna get. And you just got to kind of roll with it. You can, you can practice you should practice. But you should practice with real people. Because that's the only way you're you're actually going to learn how to deal with real people.George Stocker 42:43What's that phrase? plans are dumb planning is essential. However. I'm sure it makes Diane's God laughsJosh Heyer 42:55No, I mean, look, we're all in some sense where we're doing We're doing improv here. We're trying to get to a goal from a starting point, but we really don't know what the road there is going to look like. And the more detailed and inflexible we make those plans, whether that's communication or code, the more likely they are to break and leave a stranded out in the boonies someplace, no road in sight.George Stocker 43:27Now both of you were at Stack Overflow. And this is really interesting because both your stack overflow from one extreme to the other. When Stack Overflow started out, it was extremely transparent. And then over the years, it gradually became less so to the point that they're trying now to bring transparency back as a avid I guess, I think they have it as value so that it now that's on the wall as a value, maybe we'll do it. But they're trying to bring transparency back now as community managers you sit at a you sit between Users of your software and the company who is producing that software extensively for a financial reason, you know, how do you how do you deal with the users wanting transparency? And the company? Maybe not, you know, having transparency is their, their top priority.Josh Heyer 44:20I gotta say irony of this is, john, you go ahead.Jon Ericson 44:25I would probably say the same thing. Who knows, but I was gonna say, there was probably more of an illusion of transparency when I first started then then you might imagine, so we were free Intel telling, you know, telling the community what's going on, but there was a lot going on behind the scenes where he was sort of manage transparency. And I think that's perfectly fine. I don't think there's any problem with with that. And so just the question is, it's not like I didn't feel like it's necessarily extremes. It's more of like how, you know, what sort of transparency Lucian is probably a little too cynical, but like, you know, like, what are you gonna share? How are you going to share?George Stocker 45:07Yeah, the near?Jon Ericson 45:09Yeah, something like that. And I don't know, I mean, I never felt like we were completely transparent or even that that was necessarily appropriate. But you can have functional, functional non transparency unfunctional and I felt like there you know, kind of, like you said if transparency is a value that you have to get back to maybe something went wrong along the way.Josh Heyer 45:37I think at the point you put it on the wall, you've you've lost sight of what the purpose of trends so I'm gonna I'm gonna dispute something you said, john, I think I don't think there is perfect transparency. I think all transparency is superficial. Hmm. From a certain perspective, trends transparency is something you have to struggle to achieve and I Ideally, you know why you're struggling to achieve that you you have specific use cases in mind, you're building out transparency for a purpose. Once again, you have to know what you're doing and why you're doing it. You can't just say we're going to be completely open and transparent. This is the this is the open source conceit, that, you know, given enough eyeballs all bugs are shallow. Well, that's probably true, but it's true in the same sense. As you know, putting Infinite Monkeys in front of typewriters is going to give you Shakespeare, it's not necessarily a practical utility, unless you happen to have an infinite number of monkeys sitting around in which case you have a bigger pool probably run on a typewriter robot. That's it's hard to find now, man, the so so when you're designing I wrote an essay on this a few months ago, but the when you're designing for transparency, the first thing you've got to establishes Why do I want this What? What purpose? Is the transparency supposed to achieve? Who is it for and and what are they trying to do that they needed for. And once you've done that, you may end up building a facade that is transparent. I use the analogy of the the the electronic control system in your car, where the actual functionality of your engine is anything but transparent. You go in there with your your analyzer, your code reader, and see what the ECU is telling you. It is a it is a fiction based on what the computer thinks it knows about what your engine is doing. But it's a very useful fiction. In almost all cases, it will give you a better idea of where a problem is or what you need to do to fix a performance issue. Then sitting there with an old school analyzer hooked up to the spark plugs is going to tell you, you have a lot better summary of the information than what you would have otherwise and you're able to make good decisions based on that. And that should be your goal for transparency and if you can be transparent down to the atomic level, okay, fine, great, more power to you. But if you can only do that at the cost of the actual utility, then you're not helping your audience by doing this. Your unbridledGeorge Stocker 48:36transparency all disasters what you're saying,Josh Heyer 48:38I it doesn't have to be but you have to keep in mind your gold. I mean, you know, I got a hammer hanging on the shelf next to me here right now. It's pretty transparent. Even though I can't see through it. I can see exactly how it works. All of the important bits The business and the client, the bit that I hold on to. Those are all very visible to me. I can pick that up blindfolded and probably even hit something with it. Although possibly that would be my thumb.Jon Ericson 49:15So I'm thinking of aJosh Heyer 49:17glass hammer I just cut out didn't I? Just you didGeorge Stocker 49:21at a weird point. Ah,Josh Heyer 49:23I don't need a glass hammer was my was my punch line, but I completely destroyed the setup to that.Jon Ericson 49:30Well, I was gonna, I was gonna use that analogy with the class hammer. I don't know if I will use class hammer but I was thinking, you know, the aphorism should be people who live in glass houses shouldn't take showers. Because Oh, man, maybe there is such a thing as too much transparency.George Stocker 49:49So what are you guys doing? Now? Like what do you how do you spend your time now john?Jon Ericson 49:57So some of that shocked me earlier this week was I had a little moment of grief. And it turned out that I haven't been programming like at all. And when I was at Stack Overflow, I could always pretend like, Oh, yeah, I'm a programmer a little bit because like, I'm working with programmers. And I work with people who are definitely not programmers. And I had a moment of grief, realizing that's not my field anymore. And so I'm actually a people manager as much as anything else. I've got a small team of people that that work I work with, but they work for me. And so I do a lot of meetings. I am, this is I've had a meeting, straight meeting since eight this morning. So I'm glad glad we were able to fit this in. Yeah. I have a short period of time where I don't have meetings and and then I write a lot of documentation about what I'm hoping to accomplish with our platform. The changes we're trying to make. I guess I talked to the community, because I believe that's important. So, yeah, my manager.George Stocker 51:14That's its own field. So I guess it's okay. Now, Josh, what do you do now?Josh Heyer 51:20So funny enough, I'm writing documentation. At this at this moment, I've, I guess a few other responsibilities or areas I'm investigating. But my big focus this week is writing introductory documentation for a few different programming concepts. Which has required me to step back and spend a lot of time analyzing what people who are very new to a system struggle with, where they get in the weeds. Because I can look at the existing documentation, I can look at the stuff that's out there. It all looks fine to me. It's perfectly easy for me to get up and running with it. And so I need to put that out of my head and stop writing phrases like you simply do x. And then y is easy. You just do z.George Stocker 52:25You don't use simply injustice in the documentary you become so much better. Right?Josh Heyer 52:29If If I was writing for me, I wouldn't be writing at all. I'm writing for the people who are posting on StackOverflow reposting on Twitter, reposting in the in the slack rooms or IRC who are struggling with stuff that I already know how to do that. The existing documentation is sufficient for for me, but not for them. They've gotten in the weeds. There's some concepts there's some idea terminology, something that they don't don't quite have their head around yet. And I need to identify that I need to identify where they're struggling and try to make sure that I'm taking the time to explain that ideally without writing, you know, 3000 words about it. because nobody's got that kind of time.George Stocker 53:20Now, I guess, final question for our audience, who, you know, may or may not have community managers on their team, but for software teams, should all software have community managers is this or is this a bit like asking a barber if I need a haircut? Oh, dude,Josh Heyer 53:38I, this this we could go another hour on this, but I'm gonna throw something at you. Software is government. That's not an analogy. That's not a metaphor. I'm saying software is literally a form of government. Do you agree Jon's nodding his head? Yeah, you guys are onGeorge Stocker 53:59the phone. I think my I think my head is now blown Actually, my mind is blown up my head. But don't make software. For my government, IJosh Heyer 54:08had a camera, I would point to my wall, string and the little cutouts for software is a form of government. If you go back to good old Thomas Hobbes, who I mentioned earlier, and think about his theories on government, you'll see this becomes immediately apparent government is a structure put in place by mutual agreement, maybe not in reality, but effectively. That allows us to delegate control in exchange for some measure of safety. Or to broaden that a little bit in exchange for something that we couldn't have without delegation. What do we do for software, we delegate control in exchange for the freedom to do something else. And whether you're talking about social software like Stack Overflow, Facebook or Twitter? Are you talking about application software like Microsoft Word, or I don't know, the venerable tar utility. All that software is doing is constraining your freedom in exchange for something else. It accepts a limited set of inputs, it will produce a limited set of outputs based on those inputs. And you are accepting those restrictions in exchange for something that it gives you effectively in exchange for time. possibly an exchange for accuracy or freedom from thought, ultimately, in exchange for calories, which is life, which is freedom.Unknown 55:45So,Josh Heyer 55:47software is a form of government. And I think this if you look at it from the perspective all software is in some sense social software. Everyone using Microsoft Word alone on their computer at home is implicitly accepting this social contract that their documents will take on certain formats allowed by the application and will be stored in a format dictated by the application. They are accepting that certain people will be able to accept those documents and read them. certain other people will not everyone using tar is accepting that, you know, it's not going to write zip files. You have to use something else for that. This I think explains a lot about the classic Unix philosophy of one tool one task as well as the the other classic Unix philosophy which is I think something along the lines of libertarianism forever ah the ultimate point of this In frustrating little rant is is that you don't necessarily need a community you don't necessarily need community managers. But in some sense your software is social. And if you want to serve the, the group of people governed by it if you really want to serve them as a body, if you want to leave your government unassailable from our servers, you do so you you then you ignore the needs and wants desires of your, your constituency at your peril. And a community management team can be the bridge to what your users as a group are needing, are suffering underGeorge Stocker 57:58with a hierarchy. approval rating the Congress, I assume?Josh Heyer 58:02Well, you know, I, I strongly suspect that certain companies have a lower approval rating Congress right now. So you could you could do worse than Congress. What's, what's the phrase, everybody hates Congress, but everybody loves their congressperson.Jon Ericson 58:21It is true. I do love my Congress person.George Stocker 58:25So what about you, john? is essential or separate from us.Jon Ericson 58:30So I, one of the things on this job, we have all these trainings, and I'm skeptical of trading, but we had one that was called change management. And unfortunately, change management. The acronym for that is CME. And so I saw people at my company who didn't have much. I'm the first basically the first CME that they've, they've had, using this acronym that I had an immediate idea for They were calling it change management. So community management. Then I took the class and I discovered that what change management is, is the people side of change. And so you're managing, like reactions when you change something on them. You're trying to figure out where the resistance is you're trying to, you know, like we were talking about before, what's in it. For me, it's a big phrase. And what I realized is there is almost a one to one relationship between change management, community management. And I was thinking about sharks example just a minute ago, and I actually know of a piece of software that that doesn't change or is pretty much locked in Ember, and that's the tech formatting system. At Donald Knuth, a bunch of words that are hard Knuth has me pronounce. He's basically said there, there aren't going to be any more updates and the updates are only like very rare. And it's a great system, I love it. But like it, you have to build on top of it, you have to build something more to make it usable, it's really hard for the average person to write in raw tech, you have to use some other extension to it. And one of the advantages for him is it's it's locked, he doesn't have to argue with people about how do you change, you know, what's the next change to it, you can just say it's not changing. And, and so the place where community is happening, and that software is at the extension level at the law tech, or other other extensions. And, and so I think I think it's absolutely true that because when you change something, you have to deal with people's response to it. If you want your software to change, you're going to have to deal with how people respond to that change. And that's whether you call it change management or community management is is 6100 Doesn't have another you are going to have to gonna have to talk to people and figure it out or you don't have to but like shark says a lot easier or it's a lot, a lot easier. things work out better in the end, I think.George Stocker 1:01:16All right. And on that note, john and shag or Josh, thank you for joining me today. Hey, you bet you This is absolutely. Alright folks. That's it for this week. Join me again next time for the build better software podcast. ThanksTranscribed by https://otter.ai

## LinksJobs to be doneMilkshake in the morning theoryPractical Empathy - Indi YoungSales SafariMichele Hansen's talk at MicroConf 2019: How to get Useful User Feedback 30x500 - Amy Hoy## Transcript (powered by Otter.ai - Please raise any issues found in the transcript.  AI will one day get us there, but until then...)George Stocker  0:00  Hello, I'm George Stocker, and this is the build better software podcast. Today we're talking about product discovery and customer product research. I have the privilege of welcoming Michelle Hanson, founder and CEO of Geocod.io to the show to talk about this. Welcome, Michelle. Hi.Michele Hansen  0:15   Thank you for having me on today.George Stocker  0:17   Thanks for joining us. Now for people who may or may not know you, could you tell us a little bit about yourself and your work? Michele Hansen  0:24  Yeah, so I'm co founder of geocod.io, which is a bootstrap software as a service company that my husband and I started about six and a half years ago. We started it as a side project and over a couple of years of slowly growing, listening to our customers and building for what they needed, and where the gaps in the market were. Transition to full time. So my background is in product development. And that's primarily what what I would say my background is, is in and where my heart really lies. So now running a company was just the two of us take on a lot of hats far beyond product.George Stocker  1:05   Yeah. And before GeoCod.io Do you also did product research or product management type work for the Motley Fool? Michele Hansen  1:16  Yeah, so I did product management and product development, which was an incredibly fun part of my career, worked with some really wonderful people and did a lot of fun research that led to some some good outcomes. George Stocker  1:30  Okay, so what was so I think that the Motley Fool is a is a services company. They have financial newsletters that they that they sell subscription services to. And Geocod.io is a SaaS product?Michele Hansen  1:48  Yeah, that's right. Yeah. So so one was b2c, and the other is b2b, which has shown me some really interesting differences and what it's like to do customer research and in a consumer context versus in a business context, I think there are a lot more similarities than people might think.George Stocker  2:06   Okay, so let's let's dive first into the into the b2c context the consumer. And so that would that would be your work at The Motley Fool I, I believe, right?Michele Hansen  2:16   Yeah So So you mentioned that they create financial newsletters and a lot of what we're doing is basically how do we modernize the concept of a financial newsletter so they had gone from being print newsletters and then and then been fairly revolutionary and bringing them online fairly early. And then how do you evolve that into something that meets the expectations that consumers have now of things being customized and personalized and meeting their interests and being consumable very quickly, all those those kinds of things about that are that are very, that have been very relevant in consumer for quite some time now. How do we make the concept of a financial newsletter or a fight or a sort of financial publishing product meet those kinds of experts. Yeah. And so what was the where would an idea start? And where would the customer come in? When you were designing something new for a customer at the fool? That's a really interesting question because it came in and a lot of different places. When we first started really working directly with customers, when I was there, it was at the very end of the process, which people say is generally not when you should start talking to them, you should start talking to them before you even have the idea. But when we first started, the customer was was not in the beginning part of the process. And so it was more at the very end in terms of usability testing. And the more and more we did that, and the more and and more that we were creating things and then they weren't reaching the KPIs that we were hoping for that we started going back in the process and talking to the customer earlier and earlier and earlier, until eventually the customer was the very first start. We did a lot of different types of customer interaction from in depth interviews that could be an hour or an hour and a half to usability testing to. We did testing of products, we did testing of landing pages. We did observations through tools like hot jar and user testing, where you're not actually interacting with the user. We were fortunate to do a lot of different types of learning from our customer.George Stocker  4:26   Yeah. And so you noticed that there was a KPI difference. So when you talk to the customers earlier, did it did it affect your KPIs? Did they go in, they start going in the right directions. Was there a correlation between the two?Michele Hansen  4:39   Yeah, so where the product process would start, what for probably about the first year I was there was you you would have you know, a spreadsheet of all of the different KPIs and measures of you know, different groups of users and whether they are meeting them and you know, so if a user clicked on this, their livelihood, that they they ended up meeting the KPI was was this but if they didn't click on this, but they clicked on this and said, You know that they and sort of all sorts of permutations like that. And so it really start out with Okay, what's the what is the spreadsheet say about the users who are the most successful did these actions so then how do we make more users do those actions so they become more successful? And the problem was that was that those those actions really weren't weren't causative. And there was an awareness that those actions weren't causative. But there was a limited ability to be able, well, if we don't, if we don't use the spreadsheet, then what are we going to use? And so there could be a little, you know, well, let's bring in customer support and see what they think. And so we would you be gradually refining the products. And it really wasn't until we started interviewing the customers and diving deep into what they were trying to do. And baking usability testing into the process and bringing developers and designers into those interviews and into those usability sessions, that we really started to have breakthroughs. And so it sounds like the fool had a very robust technical process. For getting metrics from users like they, and it sounds like from what I'm hearing, at least that you took that you also but you think started may or once you focused on actually face to face conversations with with your customer. Yeah, there was an extremely strong culture of quantitative data. And where we ended up evolving the process was bringing in the, the qualitative side to explain why the quantitative data was showing us what it was because you can, you can, you know, look at Google Analytics all day, but it's never going to tell you why somebody did something. Only a person can tell you that, of course, you shouldn't just talk to one person, you need to talk to lots of them. But But we found that that really helped explain to us why things were happening as they were. And once we started working more collaboratively with the users throughout the process, then the data started to make more sense.George Stocker  6:57   Yeah, my background is In programming, programming and architecture, and though I've been in customer facing roles, I always get nervous talking to people who are not already, like using the software and not already customers. And I especially would get nervous thinking about, oh gosh, how am I gonna? How do I talk to these people to these people about, you know, a product or a service that they that I want to build for them? But, you know, it's not, it's not baked, it's not formed, how do you how do you reach out? How do you get past that? You know, if we share it with them, it's, it may be embarrassing, maybe not what they want, you know, how do you get past that initial bump? Michele Hansen  7:43  There's so much fear and so much justified fear that when you make yourself vulnerable, and you put something in front of someone that you have created, or you've been you've been working on for years that they're going to say this doesn't make any sense. And so the first big hurdle to get over is that The purpose of the interview is understanding their worldview and how they understand things and what their mental model is. No two humans are alike. And everyone has a different way of doing things. And so what you're trying to do in an interview or a usability session is understand how their brain works. So that you can better craft what you are doing to in a way that makes sense for them. And so there's there is so much fear around, what happens if I put this in front of someone and they don't like it, or it doesn't make sense, or they're critical of it, or there there is also just as much of well, they're going to say something and I think that's dumb. And I purposely didn't do it that way. And I'm going to tell them why and you can't do any of that. Because someone giving you feedback is a gift. And until you can suspend your own judgments and your own insecurities about their reactions to what you have built. You won't be able to receive that gift and if you can put that aside and and understand that someone is taking time out of their day to talk to you about your product, they are giving you so much useful information. And if it turns out that what they are expecting is totally different than what you have built. That is some of the most valuable breakthrough feedback because that can help you overcome so many obstacles because you can understand, oh, this is why people aren't converting or this is why I get the same support ticket over and over and over and over again. Now the ways you could solve that is you could throw more money and advertising towards that landing page. Or you could throw more bodies at it in the form of customer support. Or you could fix the fact that it isn't reflecting how people expect it to behave or what they would want it to say or the kinds of problems they want you to solve. And so only through interviewing and conducting sessions with users can you really get to the bottom of George Stocker  9:57  now for the Motley Fool you had existing Paid premium customers you could reach out to for new features. But I take it when you were starting to build geocoding Oh, you probably didn't have paying customers. So how did how was your process for customer discovery with geocoding?Michele Hansen  10:15   Oh, so we did do interviews with non paying customers. At the full weeks, we interviewed a lot of different types of customers. So we would interview customers who were on entry level products, customers who were on mid tier products, customers were on the highest end products, customers who had cancelled all of those products, people who had only subscribed to free emails for a long time, but never purchased anything people who had never heard of the company before. So that was a really interesting breadth of customers. For GeoCodio, we built it from a place of it was a product that we needed ourselves. So that was where we started from because we had a couple of key blockers with the existing geo coders out there. So the first one was that they're really unaffordable. So at the time, you You could either get 2500, free to code from Google day, which is basically an address to a coordinate or coordinate address because computers don't understand addresses and coordinate. So you can get 2500 free per day. Or you could pay like $20,000 a year for an enterprise license. And like that was it. And so we're like, well, that's not going to work. Because we had this little iPhone app that showed you the opening hours of grocery stores near you. This is before you could just type it into Google. And it would tell you six years ago, it didn't do that. The other problem we had was that we wanted to be able to store the data. Because with Google, you could only cache it or worse, in some cases, you have to reload it every time the map loads. And so you run through those, those lookups really fast. And so you're like, we just want to be able to pay for whatever we need, and then just store the data on our end. And so those two frustrations led us to creating a very rudimentary geo coder that just solved our needs. And as we talked to our developer friends about this, they were like, oh, Like I have that problem, too. And so one day, my my husband ended up going, I think he was I think he was actually on maternity leave. So he brought our daughter who was two months old at the time to a 1776, which was like a hackerspace incubator in DC. I don't know if it's still around.George Stocker  12:19  Yeah, I don't know, either. Michele Hansen  12:21  Yeah. But it was a pretty cool space for a while. And I actually I did a hackathon there once. And so he brought it there and like, talk to some of our friends who were working at startups that were working out of there and like, got some feedback on the API. And so we built it to be very developer focused from the beginning. And on our first day of launch, which is really a sign of the demand. We ended up on the front page of Hacker News pretty much all day, which never happens. And I think today, it would be that would be the equivalent of being on the top of product on the product wasn't around yet. And so we got a ton of feedback from people. Like we got hundreds and hundreds of emails with, can you do this? Can you do that, like, I want to be able to do this, I want to be able to do that. And so from the very beginning, customer feedback was a key part of it. And I remember taking so many phone calls from people who had different needs. And one of the early ones that that came up really often was uploading a spreadsheet. So we had built this with developers in mind. But it turned out people you know, people in marketing or people who aren't developers had spreadsheets of addresses, and they needed this information as well. And the only other option out there was you could email your spreadsheet to like some guy, and he would get it back to you in a couple of days. George Stocker  13:38  You knew a guy, Michele Hansen  13:39  and yeah, it was like it was pretty sketchy andand there's this quote from Patrick McKenzie, that I love that see if you can find a business that where people are emailing spreadsheets back and forth to one another. That's a really good sign that there is a potential SAS out there. And so and so that was one of our first big features that was heavily influenced by customer feedback. But I would say from the entire beginning of the product, it's it's been guided by what people express to us and trying to understand those needs better and trying to eliminate frustrations in their process and their adjacent tasks make things easy for them.George Stocker  14:17   Do you have quantitative research that you do? Which Geocodio do or is it on the qualitative side? What's that? What's that mix look like when you're when you're dealing with product discovery. Michele Hansen  14:28  So the research I do do these days, kind of in two broad categories, and I so the first is direct customer interactions. So customer interviews, usability testing, and responding to customer support. So my husband and I, we do everything, including all the customer support, which people are always surprised by. But we find that we've been able to really, drastically decrease the number of tickets that we've gotten over the years just because we're the ones seeing the issues and so we fixed them so that we don't ever have that ticket recur again.And we do customer interviews are pre pandemic, I guess we do them on a regular basis. So I would have been doing maybe four to five a week. But we've really pulled that back. Now that's the pandemic and, you know, kids are at home and everyone's schedules a bit wonky. Yeah, that wonky? Yeah. And so then on the quantitative side, so I mentioned the fool the quantitative data was very much driven by user actions. So Google Analytics, site activity, that kind of thing. And I used to do that sort of analysis. And I really moved away from that more towards broader market level research. And so for example, you know, we have customers in banking, and they might say to us, oh, there's this specific act that our customers need to be compliant with. And there are these specific types of data that they're appending and there is this tool they use from the government for it, but they don't really like it very much because it's complicated and it's clunky as already thing you can do with that. And so what I would do with that is instead Okay, well, well, what is this act? You know, how many banks are subject to it? You know, what are the tools they're currently using? How good are those tools? You know, it's more it's more market research from a macro level, then it is, you know, specific people. And these days, if I want answers from specific people, I will just go ask them myself, rather than trying to sleuth through numbers and figure out what they're trying to do. George Stocker  16:33  So you'll fire up an email and send it out to a customer. Michele Hansen  16:36  Yes. So for example, if say we are we're looking for we're working on these specific data pens. So our niche in the market I should probably explain is not only the geocoding, but unlocking pieces of data that are only accessible if you have the coordinates. So for example, let's say that you have a charity and you want people to contact Congress about an issue that is important to your supporters. So if you're a To use any other service, in order to send an email to that person with their Congress person's phone number, you would first have to hit one API that gives you their coordinates, then you have to go ahead another API that goes coordinates to the congressional district number, then you have to go to another API, that is congressional district number two, the congresspersons phone number, and then you have to throw all of that and MailChimp or whatever you're using, and what you do, instead, you can just send us the address, and we'll give you all of that information back in one.George Stocker  17:28   Wow.Michele Hansen  17:29   So we'll also do that with with census data or, you know, if you if you want the median household income for an area or you need time zones, or you know, all sorts of other things are very often people or if you need to connect to government datasets, they're at this designation called the FIPS code. And so all the government data is at those levels that is basically down to sort of the the neighborhood block level. And so we make it easy to add all those types of data to eliminate steps simples process. And so if we're like, you know what we are creating Adding on these. So for the banking, for example, we're considering adding on these appends that are the customers who are already using this type of appender. Using that I would fire off an email to, you know, let's say 200 people who have used it recently, and see if I can get five of them on the phone. That's usually my rule of thumb is five people. The real rule is you stop interviewing when you start hearing the same thing over and over again, whether whether that's when you're when you're putting a landing page in front of someone or you're trying to interview people about a specific discrete question, though the most interviews I've ever done for one question is 11, I believe, of course, there can be a lot more for exploratory research.George Stocker  18:44   So for that, for those 11 just ballpark how many ballpark did you have to reach out to to get 11 people to talk to you, you said before was 200 to five is that? Is it roughly linear from that?Michele Hansen  18:56   Yeah, that was a project at the fool so I'm not quite sure how many People, because I was not involved in the recruiting. I think in my recruitment emails to pull up the stats on it, I want to say I usually get about a 5% response rate. So I had I have an email that fires off to two people after they make their first payment, trying to figure out why did they come to us? What are they switching from? What are they trying to do? You know, what, what caused them to switch services and come to us. And I have been, you know, tweaking that every month to try to get that response rate higher, and about about 5% is the best I've been able to get from, and that's for b2b. That isn't that isn't b2b. And so it really depends on on where you're recruiting from. So I've recruited from a lot of different places from users who are already using the product to people who have expressed interest in it to people have no idea that it exists, and I got them off of Reddit or Twitter. It's really run the gamut.George Stocker  19:58   So do you you do sleuthing on Reddit and Twitter to find to find people to interview. Michele Hansen  20:05  Yes. So and and just observing what people are talking about can be such a great way to understand what's going on. If you're familiar with Amy hoy, she has a whole course on sales Safari. And this is one of the tactics she talks about is see what people are already complaining about. What are what are they saying they're trying to do? And they're frustrated by it? What are they tweeting at your competitors, I have found Reddit to be a great place to recruit users who, who don't have any biases about your product, they will tell you, you know, and it's so great for honest feedback when something isn't working. And, of course, you have to provide an incentive, I generally find that a $25 amazon gift card is more than enough for people who have no association with the product. And And that applies in consumer as well. Though, oftentimes, because it's in b2b, and I'm one of the founders of the company. I Find that people are often so grateful to have a company that is willing to listen to them that a monetary reward is not necessary because they're just so excited that there's a company it's going to listen and not just ignore them. And so usually I send them a nice handwritten thank you note and a pair of God of socks.George Stocker  21:19   Nice.Michele Hansen  21:20  , never underestimate the power of a handwritten thing.George Stocker  21:23   Or the socks. I'm a big fan of socks myself.Michele Hansen  21:25   Yeah, those were a new thing that we got, like six months ago. We wanted to get some like fun swag, and you know, t shirts. You know, it's tough because you got to get sizes and be the socks have been a huge hit a lot. It's been kind of fun. And so your God, his business model, is that paid all the way through? Are there free trials? What's the, you know, what's the model look like? We have a freemium model, which I've heard people describe as it's not a pricing model. It's a marketing strategy, which is totally accurate because our our, our free tier does the marketing for us. So everything low level, you can get 2500 free per day, which we started that level because that's what Google was offering at the time. And so we basically, we had to offer that in order to be competitive. And then we have a pays you go plan. So you can just pay for whatever your usage was, which was the big thing that we really wanted beginning. But then we've had to add on a variety of other tiers to meet other needs. So we have an unlimited tier, which is a non rate limited plan for people who need to process up to 5 million addresses a day, which is a monthly subscription. We we also have sort of more custom, you know, on premise options, we launched a HIPAA compliant product about two years ago. So there's a lot of different options for people depending on what their volume security needs are nice. From a from a feature perspective.George Stocker  22:55  You know, how often do you find yourself needing to do research for new features? versus, you know, just go ahead and building it is is the is the interview now an integral part of every time that you want to release a feature? Or is it sometimes you're like, no, this is safe, we'll just we'll just release this?Michele Hansen  23:13  The features always come out of customer feedback, always. And so whether that's it's come up in interviews or in support requests, features are always coming out of a feature requests or feedback from users. We're never doing the, you know, gather the smartest guys in a room with a conference table and have them come up with something largely because we don't have a conference table. And we're not all guys. And but that's a very common, you know, product development process and a lot of companies is let's just, you know, get our smart people together and they'll figure something out. And we have thousands of customers who have been so generous with us on their own, their own feedback and sharing their own vulnerabilities of where they're frustrated with their own processes. We have more than enough to, to inspire us to move forward and to make improvements. So for example, we added zip plus for data for mailing purposes. So if you know you have your zip code, and then there's the plus four, that's more specific. For the USPS, we started receiving requests for that probably five or six years ago. And we just launched that in May. But that came out of years and years of customer feedback and learning very intimately, what people wanted and why they wanted it and how it fit into their process. So that it came time to build it. We had a very clear idea of it. And we also do, if there are questions about especially about interfaces, that's where usability testing really comes in handy.George Stocker  24:47  Interface like API or UI or other types?Michele Hansen  24:52  Yes. Yeah. So the API or any sort of other interface rather than this sort of conceptual level of the need, you know, how do you take tangibly translate that need into something that someone can interact with usability testing is really helpful there. And most of the time we do usability testing in advance of that unless it's a very straightforward change. So for example, we're currently converting our dashboard to tailwind which my husband's been really excited and wanted to do for a very long time. George Stocker  25:24  That's a CSS framework.Michele Hansen  25:26   Yeah, yeah, it is.And, and so we're not doing usability testing on that, but that's because we're doing a one to one copy over that right now. And then once we get it into tailwind, then we can do the usability testing on top of it because it's running on bootstrap three right now, and it's not a delight to work with. So we probably put off work on that, but now that it's in a much more workable framework, we'll be doing more iteration on George Stocker  25:54  modern software development we focus on generally avoiding talking to people A-B testing is big? Michele Hansen  26:01  Yeah, George Stocker  26:02  you know, if you were going to rank the methods of getting customer research, product feedback, and and doing product discovery, kind of what, how would you rank them in descending order?Michele Hansen  26:15   I think there's space for every tool. But I think there are a lot of tools that get used in scenarios where another one might be more appropriate. And, you know, maybe you're using a chainsaw when all you really need is an axe or a hammer. And, and so it's about understanding where those tools fit. And there are a lot of companies that are very, you know, we're very AV testing and this this is this is what we do, and then they don't do other ones or if I mean, if even if there was a company that just did interviews, you need other pieces of information from your users at a high level at at a large scale and at a micro scale. And so I think you need a holistic view of all of the different ways of listening to your customers. Whether that is literally listening to them in a conversation or listening to them in the in the form of which landing page or are they reacting to, but those landing pages coming out as a result of lots of interviews and done usability testing on them, and then you do the A B test, because you're unclear on which, you know, design is really going to work better, even though the copy from that directly flows from your interviews and from the research, the broader market research you've done, and you've tested them for the other other elements. I think a lot of companies skip steps or they see that they say that interviews and usability testing are time consuming, so they just don't do them. And or they're harder to articulate the benefits of them to upper management and so they get shelved. And I think companies are and leaders are doing this over a real disservice when they do that and under estimating the power of usability testing and interviewing. And and AV testing is also quite exciting as well. You know, I think the really underappreciated piece about user feedback, again, whether that's a B testing, or usability testing, is the power it has to invigorate a team. So some of my most exciting times working with other people, whether that's my husband or on teams with people before other jobs was when we're seeing how something is going, you know, sitting in a room with people who are not just product and UX people, but also the developers and the designers, seeing if someone can complete a top task analysis and everybody shouting at them to find you know, of course, then us on mute, hoping that they find the button that we want them to find.You know, I mean, it's so exciting. And then when they do and everyone cheers or you know, you're running, I think about running A-B tests on on login pages, and our logins went up 5% and the bounce rate went down and everyone's cheering and, you know, or you're in an interview when someone perfectly articulate the problem that The team thinks that solving but has not heard the user actually physically articulate and they do. And, you know, I've seen people throw up a touchdown in the in the middle of them. It's so exciting. And when you have those experiences as a team, and you're really connected with the user, and you've heard from them yourselves, or you've seen what they're going through yourself, it's so powerful. And it makes your your meeting so much easier, because you don't have to explain, well, this is our user persona for this type of person. And this is what they're trying to do. Because that's kind of boring. And it's really hard to build empathy for, for that user for that person that is trying to do this. If you can say, Well remember when we talked to Susan last week, and she was talking about how this, this and this? Well, we've seen that in our data of these thousand users. We're also trying to do that. And so here's why we're going to do this test or here's why we're going to redesign this particular page. And everything just clicks for the team so much faster and and and I felt like it just boom So much life and into the team and put the wind in our sails because everyone was moving in the same direction.George Stocker  30:06   Now, you actually had me thinking back to when I was doing customer interviews, it was a long time ago. It was for the army. And it was software to that allowed them to basically manage, set what the armies for string, fourth force strength would look like, and what units would be assigned, what they would have equipment and personnel wise. And we went out and we, you know, we've been getting complaints that the software was slow. And of course, it wasn't slow to us. But we went out there. And we spent a week at these different places talking with users, and you went in day to day and watch them just watch them use the system and watched and what they were expecting. But one of the things that we didn't have is we didn't have the analytic side. So when it came time to, you know, try to solve these problems. It was hard because we didn't Have the analytics were the qualitative, but the people in the decision making were quantitative people. But we had all this nice qualitative data, you know? How do you how do you deal with when there is the person who wants to make the decision? And either I don't want to say it doesn't believe the data or you know, prefers the type of data you don't have? How do you? How do you get around that? Do you? Do you build the quantitative side? Or do you just say, Oh,Michele Hansen  31:27   I think you really need both kinds of data. And what I found to be really, really powerful and helping people understand the value of qualitative data was to bring them into the room themselves. So you know, we had scenarios where there were people who really didn't didn't deal much with the tech side. So for example, you know, a portfolio manager who was used to interacting with people who used it, but but not really in that in that kind of a context. And we would just have them sit in the room as a silent participant in the interview, and it can be so powerful for them to just Hear these things because you could see like the wheels turning for them, and them having break for those Oh, so that's why, because I'm willing to bet that even those those people who arm themselves with data are can oftentimes be doing it out of a place of vulnerability because they want to understand what's happening. And if to what you were saying much earlier, they're they're scared of negative outcomes, and they're arming themselves with data to prevent those negative outcomes. It can be quite relevant to hear someone explain why those things are happening. And so I think whatever you you get friction, invite those people in the room with you. They don't have to be doing the interviewing. That's that's a, it's a skill that takes a lot of practice. And, you know, I'm grateful that I learned from some incredibly talented, well trained people myself, bring them in the room with you just have them sit there on mute. They don't say anything but they can just sit there and absorb because it's so powerful for them to hear it for them. themselves and not read it in a report or, you know, see it in a graphic, share it across the company, bring them in the room. And, you know, even at the fool, we got to a point where even the director of our team was running interviews themselves. And it's it's so powerful to do that. And I think there is there's also a stigma that it's worth addressing here that a lot of organizations have that speaking to customers directly is the lowest on the totem pole, right. And a lot of companies people work their way up from customer support. It's an entry level position. And, and I've seen this in company after company that people basically think that they get to a certain point where they're too good to talk to the customer. And that is one of the most dangerous and toxic attitudes that can exist in a company you are never too good to talk to a customer. Nobody is and in fact your customers always have things to teach you whether you are in the middle of company like, like I wasn't the fool or at the top of it like I am now, there's always something your customers can teach you. And I learned things from them every single day. And I'm so grateful for that. And everybody can talk to customers. George Stocker  34:13  So on that note, how do I, how do I get started? So let's say I'm building a new product. I won't say whether or not I am building a new product. And, you know, I want to take what you're saying, and I want to I want to apply it. How do I get started with this?Michele Hansen  34:27   Yeah, so I would. So it depends on what stage you're at. Right? So let's say you just have an idea for right now. George Stocker  34:33  Yeah. we'll go with thatMichele Hansen  34:34  I just had an idea, and I have this problem. And I want to know if other people have this problem. So the first thing I would probably start doing is I would try to see if I can find any friends who were acquaintances. acquaintances are better because they'll be more honest with you who have this problem or who have and really, when you're talking about having that problem, you want to find someone who is going through that process. They're trying to accomplish that same job. Right and jobs to be done perspective, they have that same end goal. And find some acquaintances you can talk to, but also go kind of like find people online that you don't know. So whether that is in on Reddit or on Twitter or on Facebook groups. I have a friend who did a lot of interviewing last summer. And she specifically wanted to talk to you stay at home military moms who are trying to earn money because she wanted to find a way, a more beneficial way for them to earn money and then getting sucked into pyramid schemes. And so she recruited from a lot of mom, Facebook groups, for example, and listserv. So assemble a group of people that you can talk to you about about the problem. Give them say 10 to $25 gift card in exchange for an hour of their time and do a phone interview with them. It's extremely important that it's a phone interview because they will be more honest with you over the phone than they would over video or sometimes I find even in person Because they basically forget that you're a person who has opinions and judgments and feelings. And the more they forget that the more open they will be with. So you have found your group of users. And I would create a script. And in this script, you're not talking specifically about your idea for something, you want to hear about this process about this problem that they have. And you want to hear about how often they're experiencing it, and how painful that it that is for them. And so pain can be in the form of it's expensive. It's literally painful. I was talking to someone a few weeks ago who interviews customers about knee braces.It could be --George Stocker  36:37   -- That is literally painful, Michele Hansen  36:38  literally painful. Yeah. And it could be that it takes a lot of time, or there's a lot of bureaucracy involved, or that they don't like the vendor that they have to use for it. And you want to listen for those problems that are both frequent and painful. So the so Dez trainer, the founder of intercom has a great blog post that I refer people to all the time. It's called Not all good products make good businesses. And what he talks about this and they're the sort of pain and frequency matrix, where you want to avoid the quadrant that is low pain and low frequency because nobody struggles with it. And they don't do it very often. You know, I often think of that, that startup that would squeeze bags of fruit to make you a smoothie or juice throw whatever is, right. Yeah, exactly. It's those startups that people like, why does anyone had a $700 juicer exactly is like this is not a problem, my experience and it's not very often, low pain, high frequency can be great, because it's annoying. It's the equivalent of a mosquito and people might be willing to pay to make that go away. high paying low frequency is a great category. Think of buying a house in this category, like people if they're lucky, maybe do it two to three times in their entire life. So we don't have a lot of experience with it and it's very expensive to get it wrong. So we're willing to pay a lot of money to make sure that it goes right your title insurance and realtors lawyers and high paying high Frequency is the best category to be in. So when I'm talking to customers, and they're telling me about their process and all the different pieces of it, I'm listening for those things that those tasks that they are doing, that they're doing on a regular basis that are in some way painful for them. And so have a script you want to talk about, you know, talk to me about, what is it you're trying to do? What have you already tried? Where are you now? And you know, where are you struggling with? Those are the four things you really want to get out of that ice just writing a script for yourself, demoing it on a friend or a family member. First, print out the script, leave yourself, you know, five or six carriage returns, so you can write your notes in it and make sure you're getting all of your questions. And then the big thing that I tell people is if you have told someone that you're going to interview them for an hour, I always plan that my questions are done halfway through. And at that point, I say thank you so much for Talking to me today. I'm so grateful, and I've learned so much from you. Is there anything else you think? And then you wait, and you wait until it is uncomfortable. And what I have found is the floodgates will open at that point. Basically, what you have done during the first part of the interview is you've gotten your information, but you have showed them that you care about this task or process they're doing maybe on a daily basis that probably nobody has ever cared about. This is especially true in a business context, like how many things do we do every single day, they're just part of our work that are not very exciting, and but nobody has really ever asked us about them or nevermind asked us to how they could be better or easier. And so what you've done in that first half, is build rapport with them and you build that rapport by not interrupting them by not negating them by not explaining why you did something one way or another. You can just let them talk as much as possible. And then so if you've built that rapport with them Then they, you've primed them to talk about this topic. And they've shown them that you're somebody who cares about this thing that nobody ever asked them about. And then they will be so open with you. And I find that the best information comes out of interviews in that second half. And and I have found this to be true with, you know, women who are my own age when I'm talking to them. And I have talked to 80 year old men about their retirement situations and how they're, they're consulting actuarial tables to see how long they're going to live versus their wife and make sure that there's enough money for their wife if they're like, like, all these things. I have talked to people who are interns, and students and people who are company leaders, myself, it works on everyone. Everybody likes to be listened to. And especially in a b2b context, people are used to being ignored. How many times have you filed a bug request with a company or sent off a suggestion and took the time to write that up, and then nothing ever came of it? Right. We're so used to being ignored.Having somebody who is willing to listen to you is it people are really caught off guard by it in a very positive way. And I think it's a really powerful way to start your company. And I tend to find even though this is not the intention at all, but the people I interview tend to become incredibly vocal advocates for the company years later, and it always pleasantly surprises me. But listening to people is powerful. Hmm. There was so much good goodness in there. If you send me the link to the blog post, I will happily add it to the show notes. The one that you were talking about with the four quadrants of pregnancy. And yeah, I think he uses different terms, but it's basically the same thing. George Stocker  41:46  Now, that's for a new idea. Let's say you have an existing team, you have an existing product, whether it's for an internal customer or you know, in a b2b, another paying business. You don't they they Don't currently do any qualitative, it's all quantitative. How do you suggest they get started is the same way is a different approach you would take.Michele Hansen  42:10   So I suggest that customer interviewing isn't done on an ongoing basis, just to build general team awareness of what your customers are trying to do and how you fit into that. And so building off of that, of that baseline, if you have a, you know, a specific tool that keeps surfacing as people having issues with it, the place I would probably start with that is is a combination of your quantitative data, and then some usability testing just to get a broad overview of Okay, where might the problems be, and if you do have a customer support team, definitely bring them in and have them in the room when you're planning this out, so that they can also contribute, you know, here's where we're getting the most support tickets on this or people often have confusion about this that that can helpFocus your script for your usability interviews. And then so you can recruit from your existing user base. Or you can also recruit from people who are prospects or, you know, someone, someone who has not encountered the product but experiences the problem like like from Twitter or Reddit. Okay. Now what resources would you share with people looking to learn more about this? field books, websites? Oh, my gosh. So I I'm a huge fan of the Rosenfeld books. And so Indi Young has a fantastic book that I recommend all the time called practical empathy, which is the use of of empathy and taking other people's perspectives in in business and work settings and the power of that, which I think is a foundational read. There are also several other great Rosenfeld books on this UX team of one is a great one.There are, I would say that I do tend to struggle with UX books, sometimesBecause with the exception of user experience team of one, they're often written from the perspective of a huge corporation that might have a whole usability testing team and lab and you've got 100 people who are just focused on UX and, and so they they can be written from from that perspective. And you know, a lot of the companies doing ethnographic research with customers are huge consultancies. So. So that can make a little bit tricky, but the tactics themselves are quite relevant. I think the best training you can do is probably to try this for yourself. And so we used to run a job speed done meetup here in DC and one of the things we did was had people interview the person sitting next to them about the last product they bought, and just see what see what you find. And there, there are resources available online, have, you know, a sample script for this and just trying to talk aboutWhat is the last thing you bought? We'll teach you so much about how you need to comport yourself in an interview because really, that's, that's one of the most important things to learn when you're interviewing someone, how you treat the other person is more important than what you say. So what's up next for you and for God to continue listening to our customers and building based on that? George Stocker  45:21  nice. So where can people go to find out more about you and more about Geocodio? Michele Hansen  45:26  so Geocodio is Geo COD dot IO . And I do have a personal website at MJW Hansen dot com https://mjwhansen.com/. There's some blog posts I've written other podcasts I've been on or on on twitter @mjwhansenGeorge Stocker  45:42  Nice. Thank you very much for joining me today. I learned a lot. This is really fun. Yeah. Alright folks, that's it for this week. Please join me next time on the build better software podcast.

Show Noteshttps://doubleyourproductivity.io Transcript (Powered by otter.ai):Hi, I'm George Stocker, and welcome to the build better software podcast. Today we're going to talk about whether or not you should adopt test driven development, commonly referred to as TDD. Now, test driven development is not about tests or even about testing or about test coverage. It's weird since the first word is test, but we all know naming is hard. test driven development is a development methodology. Put simply, it's a way for teams to write code and ship software systems reliably and consistently. tvV gives you the confidence that you can deploy at 5pm on a Friday because your tests passed. That's what TDD is. It does masquerade as a testing framework, and because of that, it gets a bad rap. But as I said, it's not about the tests. It's about about what the tests show you about your system. Now in systems that are easy to compose, testing is easy. But in systems where a component relies on another component, and they're tightly coupled together, testing is not so easy. Now that's a smell, that's a sign. And what TDV does is it shows you that smell or that sign early, so that you can avoid the problems that will inherently come from parts of your system being coupled together. And that's what it is for developers for a business. test driven development is a way of being able to develop software with confidence to produce software that can be shipped reliably and consistently, without regression bugs, and without deadlines slipping now I'm not talking about that full confidence of a white dude in tech. We've all seen that I'm talking about that quiet confidence that's usually disquieting and reassuring, at the same time, confidence of a system administrator that regularly checks their backups. Regression bugs can become a thing of the past. And even do developers can work on a code base with confidence, talking about that kind of confidence. Also for a business, it allows them to respond to change more quickly. Now, what do I mean by that? Your team has been given a new vertical to approach to develop a feature for and you don't know much about it. test driven development allows you to break down the problem to specify what the code is going to do in the customers language. And test driven development allows you to talk to your business or your customer in their language, and that's really important. Now, let's talk about a little bit about what test driven development is. What do you do Historically, there have been three rules of TDD, although that's itself a misnomer. And it briefly goes like this. You write a failing test, you write code that allows that test to pass. And then at regular intervals, you refactor your work. And it sounds simple. I know. And that's been part of the problem with adopting it. You see, there's a lot of detail into failing, test passing, testing and refactoring. You have an architecture and your system that will evolve from this. And that can't rely on just those three simple steps in order to work. So regular inspection of the work that you're doing, changing how you're implementing something, and then looking at an overarching picture. And that's why test driven development by itself won't make your team successful. There aren't any silver bullets in software development, as Fred Brooks once said, and he continues to be right. But test driven development together with other practices can make your team successful under the right circumstances. Now, those circumstances are why we're here today, should your team adopt test driven development to do that? I can't give you any absolutes. There aren't any. I can say that we can look at your context, look at your team, look at your business. Look at how you're set up. And we can go from there. But there are no absolutes and anybody who tells you otherwise. doesn't understand the problems that we face. The first thing that happens when you build systems through test driven development is you have to make sure the test for a given piece of functionality is written first.Now if you're trying to adopt TDD Establish system that may or may not be an easy thing to do. You may have to set up a lot of dependencies to even get that first failing test to run. And that's assigned your team needs a lot of outside dependencies to run that's going to make adopting TDD in the existing system harder. You can do it, but it's going to incur months pain before you finally see the benefit. And this is, as they say, sub optimal. Adopting TDD for an existing system takes drive and discipline on the part of the development team and your business. Because you're about to run a marathon. If you're in a business or organization that changes too quickly, or doesn't want to work can't invest in work over the course of months and years to get to a better result, may want to rethink adopting TDD for your project or your team. You will endure pain to pass design decisions that coupled implementations together often unwittingly Pain was going to be hard to fix because it requires putting in characterization tests over code that's already written to ensure you don't break it as you're trying to refactor it out into a TDD system. Now, characterization tests are tests that you create over a working system to spell out in test what the system does. It's been merely to show that this is how the system operates. You try not to mock out anything if you can help it, because there's always a chance you'll mock out behavior that you actually needed to be in the test. It is slow and tedious work. Now, it's not all bad news. characterization tests help you to see the system for what it is for what it is and what it requires to work. This is incredibly useful information as you start to adopt test driven development, as it shows here is the system that can easily bring under test alongside parts that will require extra scrutiny since they deal with external actors or hard to configure states in the system. The second factor in determining whether you should adopt TBD is your building deployment pipeline? how mature are your continuous integration and continuous delivery practices ci and CD? How automated are your builds, some member of your team have to manually copy files over from one server to another, or manually run a SQL script. How does this look up your deployment stack? What is it like to deploy software to test or staging or production and TDD part of the value is seeing that the test failed immediately. And while TDD does strive for fast tests, characterization tests may not be fast. After all, they are literally building up parts of your system to run. So you'll want to make sure you have an automated build pipeline before you adopt TDD. Now. Third, TDD is an investment. We say that a lot in tech, but it's really true here. TDD is a way of changing How your team develops software. It is the difference between building houses from experience and building houses from a blueprint. If your team is really good at building houses, they may not need a blueprint, especially if they're building the same house over and over and over again. But if what you're building is a little bit different every time, then it helps to have a blueprint. With tester development. those tests are your blueprint. They keep you in check. They help you make sure that whatever code that you're writing is not tightly coupled to other pieces of code. One of the ways they do that is how your tests are set up. If a test is hard to set up, then that's assignments to coupled with something else. And test driven development shows you that but it still requires some overarching foresight and a larger picture to build from. It doesn't replace upfront architecture or design, one of the problems teams have had in adopting test driven development is they, they somehow believe that those, those things can go away. Now, we don't need upfront architecture, we don't need upfront design. That's just not true. If you don't know where you're trying to go, you'll never get there. But for your business, you have to be sure you're in alignment with them. If you know what the final system is supposed to look like, if you know who it's for and how it's going to be used, then it's easier to build it through TDD. If those are things you don't know, or those things might change rapidly. For instance, you're on a product team, developing software for a new market, or the team has no experience in this market, then TDD may not be the way to go. A prototype might be build a small prototype, get out into the market, and then as you learn, have that second attempt, at second pass at building your system, be done through TDDNow if you are also in a long term IT team on a long term project or a long term intern product, test driven development may be for you. Some businesses may not want to invest in the time to rewrite their systems. And some businesses may be perfectly fine with that. You can adopt test driven development without rewriting a system, but it's easier to adopt it if you've started it from the beginning. It's a part of the core way that we're building that system. If not, you have to deal with as I said before characterization tests and those can be difficult to work with. But overall, if you want to adopt test driven development or if you think that you should adopt test driven development, there has to be a Why behind a wire that goes beyond we want clean code. No one cares about clean code except the people working in it. And so while TV has that advantage, it will give you to an extent code that's easier to maintain, easier to change and easier to understand. You won't be able to sell it. With those features, you will be able to tell your organization, we can now make changes with confidence. We can now deploy 5pm on Friday. No, you will not have any showstopper bugs or any regression books. The customer will gain confidence with the system because they're not going to get any of those nasty surprises. And that's how you can sell it. Now, why TDD? Why not unit testing? Why not automated testing? Why not automated UI tests? Automated UI tests, end to end tests and unit testing. Those are all tests. Their purpose is to verify something that's already written. Where's the purpose of TDD is to verify how something's supposed to work first. And to allow you to add on to that, without tightly coupling parts of your system together, unit testing, automated testing and indent testing. They don't take that into account. They simply say, Hey, this is what is and we will work within that framework. That makes him much more brittle than test created through test driven development. Because anytime you change how the system works, you're gonna have to change those tests, even if the ending havior is the same. You've probably seen this a lot if you work with automated UI testing. Forms name changes. Suddenly your tests break even though the behavior is still the same, or with an end to end test, you no longer call a specific piece of the system, you no longer add a row to a database. Now your test breaks even though the behavior hasn't changed. And that's the world of testing code. After you've written it. You will always be coupled to those implementations. TDD flips that on its head. You write the test first. You build incrementally against that test, and against more tests, and then you refactor as the tests become hard to write hard to read, or as you see that they are duplicating information. That's where most of the value of TDD is, is in finding ways to change the system without causing problems for your existing suite of tests. Now in a system built through TDD You would still have automated end to end tests, because none of the schools say that you don't need automated and tests. But done well. TDD can reduce the amount for automated end to end testing you need or automated UI testing that you need. But that's going to end up being a team decision, a style decision. If you have the context where you're able to introduce TDD into your team, it's going to bea method of development that the entire team adopts. If you're not able to do that, not able to say, hey, all of us on this team should use test driven development, then it may not be the development methodology for you. But all of this comes down to one fundamental truth. After 60 years of developing software. We still can't do it reliably and consistently. test driven development helps solve problem. But it requires a commitment from your team, a commitment from your business. And an upfront approach to understanding how your customer thinks, what the system is for and how it's going to be put together. Now, if all that works for you then adopt test driven development. And if it doesn't, don't, there's certainly not a requirement to produce software through TDD, but it will make producing software easier and faster. Well, that's it for today. I'm George Stocker, and thank you for listening to the build better software podcast. Hi, George, again. I also offer courses and corporate training through my website, double your productivity.io. If any of this sounded interesting to you today, and you'd want to see if you should, your team should adopt TDD, send me an email. You can find it on double your productivity.io Thanks

Links: Simon Wardley's book on Wardley Mapping Simon Wardley - @swardley (Twitter) Learn Wardley Mapping - Ben Mosior's site on... Learning Wardley Mapping. Ben Mosior: @hiredthought (Twitter). Site: Hired Thought Tatianna Mac - @TatianaTMac (Twitter) Tatianna's work on helping white dudes learn about systemic racism, how to recognize it, and what to do about it: "White Guyde to the Galaxy".   Tatianna Mac also wrote a white woman focused guide, called "Save the Tears: White Woman's Guide". Please support Black Lives Matter in any way that you can.Episode Transcript (Automated Transcript via @otter_ai)George Stocker  0:00  Welcome to the built better software podcast podcast for software leaders who want to enable their teams to build better software. I'm your host George Stocker. Today, I'm joined by guest, Ben Mosher to talk about wardley mapping, then Welcome to the show.Ben Mosior  0:16  Thanks for having me, George.George Stocker  0:18  For folks who are just meeting you for the first time, could you share a little bit about who you are and what you do?Ben Mosior  0:25  Well, my name is Ben Mosier. I do a little bit of this and that I kind of jokingly call myself a methodology whisperer, which roughly translates to God, I wish I had a job title because I don't know how to describe myself. But you know, roughly that means I take these methods that people are using for thinking that are relatively unknown, but quite innovative. And then I try to turn them into everyday tools. So for the mapping is one of those endeavors. There are others but yeah, that's that's what I do. I run workshops and things like that and Build resources for people to learn.George Stocker  1:02  Now for people who are new to wardley mapping, what is it?Ben Mosior  1:07  Yeah, wardley mapping is a strategic thinking tool. I like to think of it as like a knowledge creation tool that enables action. It was invented by this lovely old man who lives in a swamp by the name of Simon wardley. He lives in UK. And he created this method after quite an extensive bit of research into what I would basically point out as being kind of fundamental patterns of capitalism, or the mapping the practice is basically three things. It's first and foremost a visual communication method. It's about kind of creating an artifact that we can challenge and have a conversation around. That's visual. And the second thing is, it's a body of research around these patterns of supply and demand competition, you know, how does capitalism big work, how do things evolve. And then the final thing is a strategic thinking process that kind of ties both those things together in order to enable you to make new decisions based on seeing a kind of strategic landscape that most will not be able to see. So it's a knowledge creation tool in order to enable you to take action.George Stocker  2:24  Okay, and now with wardley mapping when when you start out with it, what are you mapping?Ben Mosior  2:31  Yeah, so when you make a wardley map, what you're focusing on are things like, you know, what is the system that you're a part of, and you can have to make some curatorial decisions about how how some curatorial decisions about what scope to pay attention to, but you could say map of business, or you can map a market. You could even map yourself as an individual But roughly what you're doing is focusing on what is the system? What is its parts? How do they relate together? And then you do two things. You think about how the system produces value for somebody, some user. And then you also think about how those parts are changing under the pressures of supply and demand competition, which is capitalism. So what is the system? How is it changing? How does it produce value for users? And is basically creates a way for you to interact meaningfully with the world by modeling it. We can get into more of what that actually looks like. But it's not as complicated or weird as it sounds. It's literally just what are the parts? You know, what do they like? And how should we treat those parts? How should we have intent with respect to each of those parts?George Stocker  3:51  Now, how do you spend your days with wardley mapping?Ben Mosior  3:55  So I spend time with teams doing strategic kind of training. assizes, where what we'll do is we'll kind of go through the basics of wardley mapping, we'll apply doctrinal principles about, you know, what you ought to do as individuals in the organization, how to think about, basically, what's it What's a universal principle that you can apply to the work that you're doing? That that value that you all kind of share. And then also thinking about what Simon calls climatic patterns, which is basically like, what what is relatively predictable about capitalism that if we only took the time to notice, we could actually use that to anticipate change that's occurring in the wider market. And then like finally just thinking about how to go about strategic thinking, I get more energized by the thought of getting into kind of like, what what is the you're doing George, like with this podcast and what, what are the big questions you're trying to answer? And then you and I riffing off of that, given the context of what I do, and Given the context of mapping and how I think about those things, I feel like a lot of energy coming out of that kind of conversation, and kind of nodding toward the mapping without having to like get big make it the focus so much, if that knows,George Stocker  5:14  no, I really like what you said. And that's, that's key is that, you? I, I believe that we, as software developers, and as an as a practice, software development itself is still in its infancy. You look at you look at construction, and they have building codes and building codes and building codes. They can tell you to a tee, how much a bridge will cost and how, what it can hold. You know, who's it for? What does it does, and with software development, we can barely tell you how long a little feature will take. And that's after 16 years of doing it. And then we'reBen Mosior  5:55  still having fights about about like whether or not estimates are a valid thing to do.George Stocker  6:00  Exactly what can you imagine? And you're to the point about building? Can you imagine if the building codes were like, yeah, you don't need blueprints. But we built software every day without blueprints without specifications. And we actively derived teams that do produce specifications that do produce tests in the form of test driven development. Now, what I focus on is I focus on I want every software team out there to know about test driven development. And I want to make it accessible for all software developers to a point that it becomes, I believe, it can become the standard way of developing software. Now I believe that we have we have taught it incorrectly. We have glossed over the hard parts. And we have, you know, over simplified it and not gone to, when you would use it, how you'd use it, why you'd use it, who it's for, and Who it's not for, and what the, you know, the two standard schools of TDD, get right and what they get wrong. And if you go inside out as an example, if you go in that inside out TDD, you're so focused on the feature that you forget the world around you. And when by the time it comes to getting to integrating with the world around you, you you're doing it haphazardly, or you're not able to do it at all. And then from the other side, if you go on the outside in and you take in the whole context of the world, you're operating around you, you're coupling yourself to that world through the use of mocks and stubs. And there are other ways and in fact, someone named Gary Bernhardt talks about a style called FOMO, which is a melding of the two worlds you inside of your domain inside of your business context. You keep yourself isolated from everybody, and then around that, that's the functional core of your SOP of your system. That's completely done through TDD, has no outside dependencies doesn't deal with anything, databases, API's or anything. But outside of that, that that impatience. If shell that part where you talk, the world has very few entry points into your into your domain into your application. And those you don't TDD, you may write end to end tests for those, but you've reduced because all of your system is inside of that domain is isolated from the world, you've reduced the surface area that your end end tests have to cover, you know, to to the end, down to a, relatively a handful. But we as a software development community, you know, have not embraced TDD because the way that we were taught it, we were we were taught these systems that that, you know, you got three rules, they just work and they don't just work. Your mocks and stubs don't make testing easier. They make testing harder, but we we've not given enough attention to the practice and really diving into the practice of sharing its value. How How can it help your beginning software develop And we have not gotten into how it can help teams and businesses. And I think that if we we hone in on the business aspect of the value it provides to businesses as far as fewer regression bugs, faster time to market, because you're not worried about making changes to the system. If we focus on things like that, and we focus and we give each person to your point about these people or these capabilities in these parts in the wardley map, you know, software developers worry about one thing, QA worries about another business, people worry about a third thing, they worry about the value they're going to get out of this feature. But if we focus on what can How can doing TDD, give you the value that you're looking for, no matter what your position in the company is. I think we might have a better time for it instead of focusing solely on developers which is what we've been doing for the past. 20 years with TDD and it hasn't worked. It's it's demonstrably failed. So we've got to change your tactics. And that's why I am here. That's why that's why I care. I believe that all software teams can produce value and produce more value for their customers faster. And I believe that software development itself must change. It must adapt to the world around it. And it must produce some sort of standard in order to be able to produce software reliably, which we still can't do. And I think that something like FOMO style of TDD will get us there. It will give us much closer it may not you know, it may not be the the end thing, but it is the next thing.And that's what I that's what I help teams do.Ben Mosior  10:46  Yeah. So it's like the Faux-O Manifesto, right? No, yeah.George Stocker  10:50  And it's not like it none of this is original to me. Like I learned about it. When I went to PyCon in 2012. Gary Bernhardt was on stage. And he's he's talking about it in the context of his own site, destroy all software, and in the context of it and its billing mechanism. And during this, I was watching it unfold. And I had been well versed in to that point both from the inside out perspective and the outside in. And I had, I had been dealing with all the problems that he talked about mocks and stubs and how brittle they were. Because once you start mocking something, you're now you're not coupled to it. If you're mocking a method, you were coupled to that method being called. And it bothered me because we would get failures in our test suites for no reason other than, hey, we took out this implementation detail, no longer calling this method inside of, you know, these three other methods. And that would break the test and it shouldn't break the tests. But in his talk, which is called boundaries, he goes through, you know, this is what functional core imperative shell Looks like this is how you can model your system. So that you you return primitives inside inside of that functional core. You don't mutate objects, you stay away from the Oh, which is I have one object I mutated state. Now you always return a new object with that new state, and you never mutate objects. Also, you deal with primitives, you don't deal with how external for instance, the Active Record pattern would return you an object, you don't deal with that you deal with your own method of object retrieval. Now it turns out the shell side of it when you do have to talk to the database, you're going to have to deal with that mapping. But inside of your domain, that mapping is entirely your domain objects, your primitives that don't have external dependencies, and you start there. That's how you decompose your system so heavy into it. Domain driven design flair. Understanding your bounded contexts of understanding your domain, and of speaking in the customers language. Now from all that you can, from all that you can make sure that the actual business work that your system does is testable and is fully tested through test driven development. And then your, your, your shell, you know, the delivery mechanism of your software is the thing that you need to write end to end tests for. But that's, you know, that's an API endpoint or two, that's not, you know, trying to have that API endpoint do all of the internals of your system as well.Ben Mosior  13:42  Yeah, what I'm what I'm so here's a, you know, here's an admission, right? So I'm a former systems administrator. And I have, I'll be honest, I couldn't tell you the difference between them. I couldn't tell you the difference between a stub and a mock I will set a mob and a stock and I'm notGeorge Stocker  13:58  sure They should have named him that.Ben Mosior  14:01  Yeah, honestly. No. But like what? What's interesting though is I heard you do something that I hear people do when they learn wardley mapping. I heard you disambiguate a term that is used almost ubiquitously. So test driven development, right? You You took that thing and you made it two things. And then you talk me through how each of those things is used in different contexts. And then you described that as a third thing. So test driven development is now three different things. It's inside out outside in. And then the third one, which I of course, have no idea what the name is called, but it sounds like fun to pronounce.George Stocker  14:42  Yeah, the Gary Bernhardt calls it Faux-O and it is, it's exactly a third way to do TDD. Yeah. From wardley mapping with with test driven development. Would there be a way to map out you know, a team adopting TDD Through wardley mapping?Ben Mosior  15:01  Yeah, it's really the question like, how would you ever be able to have the conversation? Like, what conditions would you have to create to have the conversation where you could contextualize each sub practice of TDD into a context that you in a way that you would enable you to know when to deploy? Which one? And so like, you shift the conversation from which one is right, always, to which one is right, in which case? And what conditions would you have to create in order to have that kind of conversation? And and frankly, the answer without something like wardley mapping is luck, to be honest, or really like incredible intuition, perhaps. And kind of like I know, we were talking before a little bit about like human shock absorbers, sometimes the embodied kind of cognition that people have, they have these like, tacit things that they just know without being able to explain and so sometimes they'll pick up on something like that and able to have the right conversation. But like, it looks an awful lot like luck to me. So I would rather have a predictable way to create conditions for conversations where we could disambiguate, like big, messy things like TDD into context specific deployment of specific methods. Now, I just used a bunch of $5 words. So I'm going to like, take a break, and pat myself on the back. Let's let's get really like concrete. This is this is what you did. You took TDD, you split it apart. And then you said, in one context, do this in another context, do that. That's what you what you did was you had a struggle of ontology. What is test driven development? And you You brought in a language of existing models, which is exactly what you can do when you're getting started. You're like, Well, okay, the thing that is test driven development actually turns out to be several different things. And so when should we use one over? The other is an interesting question. So just just pointing out that there are multiple things enables you to actually say, Hey, we should use one in one case in another in another case. So so what what happens next? Like what what are you thinking about?With respect to like?George Stocker  17:23  Yeah,Ben Mosior  17:24  actually, here's the question like, how would you create, like, currently create the possibility for that conversation? Like, how would you enable a team that you were managing to have that kind of conversation?George Stocker  17:39  Yeah, so for me, I'm always interested in the bottom line in what will this do for me or for the team for the business or for the customer? You know, we adopt TDD. What's Why? Like, why are we doing it? Are we doing it because we have Lots of regression. When we deliver code, are we doing it because we find it hard to change code? Are we doing it because we, you know, heard on a podcast, it was good idea. Why are we even doing this thing? And that's the first question that I want to answer. And I want to get that down on paper.Ben Mosior  18:17  Most of the time, the reasons people are adopting things is fashion and tribalism. Right? Yeah. It's what what's awesome is that's the phrase that I stole from Andrew clay Schafer, but basically, it's like, what's really cool that people are talking about that gets me excited, because, you know, what have you liked? hundreds of companies are doing this. So we should do it to or, you know, our group of people who believe this thing versus that group of people that believes in that thing. nobody's asking what test driven development actually makes possible for us. When we have it as a capability in the organization. What does it enable for us?George Stocker  18:53  Yeah, so for what I've seen is when you when you Do TDD and you use the right and and you went you, you hit on it earlier. And you really hit on the center of that is that not all forms of TDD are acceptable in all situations. But when you apply the right form of test driven development, to the right situation, to the right code base, you give yourself give the team confidence. So if your team is lacking confidence, or you have a lot of new developers on the team, you're giving them confidence that when they make changes, those changes won't break anything else, which, as a developer, new to a code base, that's the first thing I'm thinking of is I don't want to be embarrassed in front of my teammates, because I just made a change, and I broke production. I don't want that to happen. From a business's perspective, you're gaining the confidence that you can deploy at Friday at 5pm. You know, there's that mean, you don't deploy on Friday. And if you have a testable system and a system that is tested, you you gain that confidence of Hey, I really need this fix to go out right now. Can we do it and you as business you can. Now you To start to answer yes to that question, from a system perspective, from a maintainability perspective, you're now looking at, there's an I see it every time I'm, I'm with a new team, it's the desire to rewrite this desire to get rid of this thing and to replace it with this magical new thing. That is so much betterBen Mosior  20:21  problem of discipline to write, it's like, it's like this assumption that like, hey, if we just rewrite it again, it'll be fine. And so you start this, this whole new effort without having all of the understanding or the skills that would make writing good software possible, expecting to get a different result. And I do believe there's a word for that George,George Stocker  20:41  it's called insanity. And I've been guilty of it myself. And I've also been in situations where you know, the rewrite decision was made before I came in and I was asked to implement rewrite and say, Look, and I had to keep saying like this is not going to go the way you think it is. Because the rewrite you don't have the people who produce the original system. Usually, you don't have the original context. And you don't know all the cases where the system is in use, like you. There's a semantics, Twitter account that I love. But it's basically like the it tweets out, you know, things that are real in systems. For instance, the system does what it wants to do. It's not it has its own agenda. But you don't know those things when you rewrite. And you just think that the system is what you see in code, instead of the whole context.Ben Mosior  21:31  Not to mention that oftentimes the business doesn't even know what the software is supposed to be doing. The business probably couldn't tell you how the software actually fulfills user needs in a way that produces profit for the organization. Because like, this is this is like unintentional ality, which is a word I'm going to make up for whatever reason, like it's the absence of being intentional. Is it all the way down? It is it starts at the highest level of the C suite. It goes all the way down into our engineered engineering organizations, product organizations, operations organizations, it doesn't matter where you look, you're going to find this disconnect. And so the question becomes like you as a software developer or us a software leader, trying to make an informed decisions with respect to this entire system, unintentional ality, it becomes really, really hard. And so of course, it just, it starts to feel like a well, ah, it's a mess, and we didn't manage the legacy well, so I guess we should just rewrite it because that's at least going to be approved by the business as like a panacea, right, or a panacea that's gonna at least be approved by the business as a cure all for the problem, because, you know, they don't know any. They don't know any better either.George Stocker  22:48  Yeah, and sometimes it might be there are instances where a rewrite is the best thing for the team. But, you know, for for businesses that don't want a chance to rewrite information. teams that have the situational awareness to realize they don't know what they don't know about the system, introducing characterization tests to figure out what the system does. And then from that, you know, producing test driven development tests, you know, to port over new functionality to put it under test. And then gradually refactoring the system using those characterization tests, refactor parts of the system, into something that you is produced, or can be maintained through test driven development helps. But that goes to those three different types of test driven development. You know, if you're producing a new feature in isolation, and then you integrate it later, maybe inside out as your best way to go worry about your feature, worry about what it does, specify it through tests, implement those tests, or implement the test, implement the code for the test, and repeat that. You know, that's best when you have a feature in isolation and you're not as worried about trying to integrate it into a larger system. Whereas outside in or, you know, introducing mocks and stubs and mocking out things you don't own or stubbing the state of the system, or stepping parts of the system that you're using. That's good when you're trying to take something existing and put it under test. It's a good first step, the problem with mocks. And I said this earlier, the problem with mocks is that they tie you to an implementation. You know, I verified that this method was called Yeah, in refactoring might end up removing that method. And if we're not careful and don't realize that it's being called in this test somewhere by dependency, it's going to fail, our tests will fail, even though nothing changed behaviorally. And then that introduces that next third style of test driven development FFO, which allows you to then test the behavior of the system and not worry about the implementation. I'm testing the behavior of this billing reconciliation feature. I don't know care what methods actually get called? All I care about my input is, you know, this this bill, the state of the system is this bill is in a certain state and all I want to know is, you know, is it reconciled or not. And with that you can then change a lot of the implementation, and your test don't get affected by it.Ben Mosior  25:20  Yeah, one of the things that seems really critical in designing an organization, let alone designing software, which I mean, Conway's Law is a thing, but like, roughly speaking, where are the boundaries between the parts of the system, and very quickly in both an organization and in software, you start to realize that entangled pneus is one unnecessary evil, but also something that shouldn't be allowed to dominate as as an extreme or a default. Right. So like, what I mean by that is like tightly coupling things right where, like, you're being tied to implementations is probably not a great right thing to do, if there's a chance in the future that that thing has to change, right? So you have to pay attention to change. And if like, it's a 5% chance that that thing will have to change in 20 years, then maybe who cares, right? But like, if there's an 80% chance that in the next six months, there's going to be security vulnerability that requires you to actually adjust the implementation in a way that would have, you know, cascading effects and all the other parts of the software, then then, yeah, maybe I should be a little bit more concerned about being tied to an implementation in that case. So one of the things that I really like so wardley mapping really points at this idea of interfaces, and and cell based structures, both for organizations but also for, I think, in particular software. So So what is the interface? How do you create those clean lines, and unfortunately, there's like this whole body of skills that you have to build in order to do that. You have to be comfortable. Like taking a decent guess, under circumstances of ambiguity, where to draw lines, what to include inside the boundaries and what to push outside the boundaries. And if you're not careful, what you start to see is that in an organization, say between a development organization and an operations organization, you'll notice that there are things that get stuck between those two saw, like sets of things in the organization, that they're just, you know, crust that stuck somewhere, and nobody's responsible for it. And so it starts to decay and it starts to smell. Similarly, in software, if you don't have clean lines that, like, make responsibility for each part of the software clear, you really start to notice how like that is the zone of no maintenance, that those are the things that will not be touched. And that is equally applicable to organizational theory, from simpler like people's in teams.George Stocker  27:57  That's right, and you're going to get it Wrong. That's one reason if you use domain driven design, and you think about your bounded context, which is you know, inside of this context, a word means what it what it means. And outside the context, this word may mean something else. But in this context, the word has a specific meaning it's not going to change in this context. If you use things like your bounded context, and the domain, the language of the customer, the language of the problem you're trying to solve, you, you start to see where, where things are defined, and what they relate to. And you start to see those those boundaries crop up just from when words change, meaning. You know, change management means something completely different to a business person than it means to me.Ben Mosior  28:46  And it means something very different to a consultant as well.George Stocker  28:49  Yeah. And so, you know, when I know that word has changed, meaning I know I've crossed a boundary of some sort, and you're going to get it wrong. One of the tenets of TDD is that you don't start out with the right You don't start out with the right architecture, you're going to evolve to it. Because you're going to learn every time that you add a new test to test out a new feature, or you add a new feature, the system is going to change shape. And you'll figure out you know, what the system and you know what it should look like, through that evolution because you don't like you're never going to know less than you know about something at the beginning. So if I'm, I got a new system, I will never know less than I know about it right now. You know, every moment I will learn more and more and more. And you hope that when you learn more and more more systems easier, easy to change, it's not easy to change, like that's a that's a smell,Ben Mosior  29:43  that it's a huge smell. If for example, like you need to do a lot of exploring, right, actually, this is where the wardley mapping concept of evolution starts to become really helpful here. So like, we may or if you if you've looked at wardley mapping, you know, there's a This x axis kind of like idea of evolution, right? four stages from Genesis to custom built the product and commodity, you can also look at that through the lens of like practices. So like emerging, sorry, novel practice emerging that novel, practice emerging practice good and best. And so there's this progression from left to right. And like how evolve something is changes the way that you should treat it. So for example, things that are in like the first couple stages of evolution, so Genesis or custom build, those have to be easy to change, because they're so uncertain that you, you almost have to assume that like nine times out of 10, you're going to do the wrong thing the first time. And so that's where you start to see things like agile being really helpful, where you're basically trying to lower the cost of change of that thing, so that you can change as many times as necessary until you find the value, as in find the right form of the thing that produces value for the people that you're serving, by building the thing in the first place. Now that's completely different from say, like, if you're looking at something like a login function, right? Generally speaking, authen off z, like these are things that are broadly understood. And for you to reinvent that wheel, and to pretend like you need a low cost of change, and the need to rapidly change around logins, is kind of absurd. If you compare that to the way that the rest of the industry treats that kind of practice. And so there instead of reinventing the wheel and using an agile method, that you might actually want to just adopt something, either in terms of the design or in terms of an external solution, because it's so well understood. And of course, you're going to have trouble like adapting it to your local context to your software. But in truth, you don't want to be have to be the expert in that thing. And a high cost of change is okay, because the thing isn't going to change in 20 years very much. So it's like trying to understand how do you continue Realizing practice? How do you contextualize, like each of the different sub practices of TDD? What does each thing depend on? What does each thing? What depends on each thing? It's like you look up, look down. How does it How is it situated in this larger scope of things, such that you could make those nuanced decisions without just reverting basically to like, my way or the highway kind of approach?George Stocker  32:27  That's really interesting, because as you're describing it, I'm seeing, you know, both the forms of TDD. And when they would use animal types of systems and on what aspects of the systems like I'm seeing that overlay onto the workday map. So something that, you know, is going to change a lot. I mean, want to put a lot of effort into making sure that that part is designed through TDD, but something that interfaces with the login mechanism that's over on the commodity side of the working map. I may not I may only want to have an index Test around it and automated an automated UI test around it. I may not even want to deal with that from a, from a developer. I'm writing tests for this perspective, because it's, it's not in the novel. Or the emerging, it's, it's over there on the commodity side of things.Ben Mosior  33:24  Yeah, it's like, how certain is it? And do you really need to doubt that it's working? Now, it also depends on like, your organizational context, like if this thing doesn't work, what are the implications? Right? If this thing spits out garbage data, you know, what are the implications of that, like, Are people going to die? Or is it just that, you know, someone gets a 404 page when they weren't expecting to, right so, and that's where you start to notice that. Look, the whole system of software and the organization building, the software is A bunch of little negotiations between different parts of that system. And so that's when you start to find that things like SRP are really interesting. Because it explicitly calls out that negotiation as a function ofGeorge Stocker  34:15  site reliability engineering.Ben Mosior  34:16  Exactly. Yeah. And like, just, if you go read the free, like just the one chapter from Google on, sorry, about s ellos, and SL eyes, like just go look at that chapter and think about what it means to negotiate a boundary like that between operations and development, for example, you start to recognize that this this whole thing, all of this that we're doing, like we might think that software is like, understood or understandable. It is one giant human mess, and that's actually okay. But we should probably be careful about where things are more or less uncertain. And if we more explicitly have the kinds of caution conversations around negotiations between the boundaries of these components, we can actually start to be more intentional about how we're treating each thing. Like until we can build a software system that doesn't turn into a giant ball of yarn, in like a giant tangled knot. Eventually, if until software systems are not inevitably going to result in that kind of end up in that kind of state, I have a really hard time thinking of software development as something that's known.George Stocker  35:31  Yeah, that's you would you put it on the emerging end of the scale,Ben Mosior  35:37  possibly just to be a pain in the ass? But like, I think that it's an interesting question. And when you break down software development into its hundreds and hundreds of different sub practices, asking the question, what is software development becomes not super easy, and every single one of those sub practices is somewhere else. along that spectrum of evolution. And unless you're aware of that, I think you'll be reinventing the wheel for the foreseeable future.George Stocker  36:09  And now we're really getting into the value of wardley mapping. As a software leader, I can use it to contextualize my team, our practices, our relationship, business. And I can, you know, give myself a view of where are we at? What are we doing and how does it fitin this larger context,is a way to visualize you know, what is as opposed to what we want it to be.Ben Mosior  36:42  Yeah, it's really interesting because it enables Conversa- it like once you start sketching out artifacts like this. You can look internally and say, Okay, how should we be behaving like how should we treat this set of components, and then you can compare that to the way that the larger market treats that component. And you can say, Okay, well, how is everybody else doing? Especially in like public sector, like public sector can learn from private sector, for example, and go like, what are our counterparts in private sector doing? Like maybe they're not bound in certain ways that we're bound. But can we at least like learn from the way that they're doing, like authentication or something like that, right? You, there's a lot of learning that you can have just by looking outside of your organization and doing basic like open source intelligence gathering, like, read the press releases of other companies, when they talk about the thing that that is somewhat related to what you do. And you learn a lot about how different people view that same thing. But then you have to talk about time. Because if you notice a gap between what you're doing and what others are doing, and that gap isn't valuable, like it's not differentiating, it's just a waste of time. So for example, if your custom building a login function, I know I keep like hammering on that example, when you should probably just be adopting a library. It's gonna it's gonna take Little bit of work for you to get from point A to point B to actually resolve that bias. And so when time starts to be involved, you end up comparing like your your desired internal future state against where the rest of the market is going to be in, like, however long it's going to take for you to make that change. Because if you, if you set your ideal future state internally, to the current way that things are externally and the world keeps changing, then you might embark on a big heavy lift for nothing if the world changes significantly enough for your change to be out of date. I know this is like a really hard way to like, explain the phenomenon but it's like, that's what happens to most organizations when it comes to business strategy is even if it's just a gut feeling. By the time the organization actually implements the strategic initiative, so to speak, though So the world has moved on. And that may no longer be the right thing. So like this whole, like, unless you can have conversations about how to tackle that problem, like, I don't see a lot of hope for the for the quality of decisions being made, either in terms of the software that we're building or in terms of the strategy that we're implementing in our businesses.George Stocker  39:22  Now, for software leaders, I think those conversations less on the business side, or more on the, you know, what tech stack should we use? What database should we use, you know, what practices should we adopt among our team? building software? A thing that I see is that, you know, they try to answer those questions first, instead of answering those questions after they've done what you've suggested, which is figure out strategically as a business. Where do we want to be? Because once unlike, unlike other, unlike code, if you're using a data store, You're going to become coupled to that data store unless you're very, very careful. And I've not yet seen it seen a team that was careful enough not to become coupled to some aspect of their data store. And so, you know, if I'm sticking around and I choose Mongo, and I say, Well, you know, we're going to use Mongo. And then, you know, two years later, there's that nice article about how Mongo lose this data, like, Oh, we need to get off Mongo. Well, we're pretty coupled to it. That's not happening. But it sounds like with wardley mapping, you can we can, we can situate where we want to be strategically as a business, we can orient the software team towards that ideal future state. And then from there, you make decisionsbased off those factors.Ben Mosior  40:47  Yeah, I think for software leaders in particular, what something like wardley mapping enables you to do is to be intentional, you know, local way and I bet We just mean, when you look at all the parts of the system that you're responsible for, do you have an intention for each part. And that's, that's a serious obstacle for most. Because until they until they are able to actually grapple with all the parts of the system, they're not going to be able to make sense of it in a way that together, it is like a coherent strategy. And in particular, I think like software, leaders need to have that kind of intent. Because otherwise, they're going to become subject to what I would very lovingly call meddling from other parts of the organization, not because those other parts of the organization are bad or anything, but it's more like they just have priorities, and they have things that they think they want. And if you're about to make a new decision about either what data store to start with, or whether or not the news that mangos losing data, for example, is a significant enough. No impetus to actually change the data. Or if you if you aren't prepared with local intent for each part, then you're probably going to end up being swayed by the political winds. And you'll be making decisions based on other people's feelings. And I for one value feelings, but I don't think they are necessarily the primary way that you make decisions, especially decisions with impacts that lasted many, many, many years. So, when I think about this, I think it's strictly about being able to, to understand why you made the decisions that you made, especially when others around you aren't. When they aren't sure about those decisions that they they're making. This is a really like, messy thing, because you soon start to realize that like wardley mapping in particular looks like just a like, Oh, it's just another diagramming technique. And I know the DDD, people seem to like it as well as an approach and like, I'm encouraged by that. But like, what I think is like the, what I think is hidden underneath the surface of all that isit's all about conversations.And in particular, it's all about conversations about deep social problems inside the organization that are not going to be obvious that you can't exactly code your way out of. And when someone comes to you and says, I want to do this, and it's it's a bad idea, but you don't have a reason to say that it's a bad idea other than it just feels wrong, you're going to lose.George Stocker  43:40  But wardley mapping can help you show why it's a bad idea in context.Ben Mosior  43:46  It really like boring mapping is one tool and I in a huge set of tools that can help you be more intentional about the work that you're doing. I for sure, have experienced circumstances where by mapping out of space Honestly, one of the one of the typical experiences is you map out a space and you go, Oh, no, I made a decision A long time ago, that really is hurting me right now. And frankly, like the early, you rip that band aid off better. But once once you've reckoned with it, you start to recognize that you have an intent.And when you have an intent, you start to care about it.They make sense, I should do this this way. This is what I'm trying to do. And And ideally, you're having that conversation with other people around you in a way that brings them along and help them even challenge some of your ideas using some of the this kind of language like, well, what, okay, yeah, you want to choose Mongo, but Mongo entails all these dependencies, is that going to be right for us? And if you can't answer those questions, then you know, then that was an effective challenge and you've all learned something now because you'll go off and find out what you need to find out in order to answer that question. But otherwise, the other way that this works, sometimes it's just that people are will be making decisions based on their feelings. And they'll try to impose those decisions on your organization. And especially when you're in charge of an organization, that leg is full of other people. When their lives are disrupted because of someone else's feelings in the organization, you know, that's gonna really hurt morale, especially if it doesn't make logical sense to them. If you can't help communicate intent from other areas of the organization and make it make sense, then you're just going to produce an organization that is just doing what it's told, instead of thinking actively about how to make good decisions in terms of building software.Sorry, it's a bit of a rant but likeGeorge Stocker  45:50  no, that's that's great. And that's that gets to the value that you provide in teaching teams. wardley mapping is that you can help them ensure that their teams areProducing software intentionally by mapping out where they're at.Ben Mosior  46:03  Yeah. So here's what I'd say, if, if some of the things that I made that if some of the things that I just said, even if they don't make sense, if they're intriguing to you, then what I would highly recommend is go to learn more the mapping calm. And just click around a bit until you find some things that are interesting to you. And if you decide that it's interesting, go read the book, ask me questions, you can email me either through the website or by emailing Ben at hired thought, calm, reach out and tell me what's going on and I'll help you get started. Like I love helping people start to make sense of their worlds with this stuff because it betrays my optimism even. Even now, it betrays my optimism around how if people are just more intentional, I think they'll bring more good about about into the world.I want to help you get started. Socontact me say hello, ask questions. There's a lot of good resources just to start getting exposed to the method. And what I'll have to say, above all, do it like actually sit down with a piece of paper and follow the steps and try to do the process. And if you don't learn something, I will be surprised.George Stocker  47:24  I think I'm actually going to do that. I'm going to sit down and I hadn't done it yet. But you'd sent me some materials on wardley mapping. I'd like to sit down and put test driven development in that context and see what that looks like. But then this has been this has been an amazing time. You know, people can find you online at learning wardley mapping calm and they can email you then at higher thought.com. Are there any other ways that people can find you online?Ben Mosior  47:53  Yep, I'm on Twitter as well @hiredthought.I was going to say something self demeaning Because I hate that handle, but here we are. Branding is branding. Yep, I'm on Twitter @hiredthought. And I'm pretty accessible on there. What I'll say right now is like we're recording this on June 3. And you know, the United States is hurting. And I think a lot of people are hurting in general. And what I will say is like, right now, I'm not tweeting so much because of that context. I want to be respectful. But if there's one thing that you could do, even if you don't care at all about wardley mapping, if there's one thing that you could do that would help yourself and help those around you, it's learn a little bit more about race and the context of race and the way that it manifests in the United States. And what I'll say is that include this in the show notes as well. It's a URL to a list of books and other suggestions by Tatyana Mac. You can access that URL by going to https://lwm.events/race. So I opened up a page with some books that I highly recommend you engage with. And I'm currently reading The New Jim Crow. And frankly, I am learning about some things that I didn't know before for the first time and I'm kind of ashamed about that. So, use that shame for good. Don't let me be shame. shaming myself in vain. Go learn about race and learn why this country is experiencing the anger that it is.George Stocker  49:32  That's, that's critically important. Anybody who's watched my Twitter feed over the past few days is just just seeing retweeting and showing what's happening in these protests and how the protesters are being treated by people in power. And I second and I will put the show notes, Tatiana's work. I've read some of it. I'm buying the book. That she's linked to not on Amazon by buying the books that she's linked to. And I second it's, it's really important I struggled whether or not to bring up the we are indeed recording this on June 3, two days past the point where a sitting president ordered military or civilian cops to clear out the area right in front of the White House for photo opportunity. And just that, whether or not you agree with that actor, not just how historic and context changing that action is, you know, what it represents? Who would effects and more importantly, what it says about us as a culture as to what we allow and what we don't allow. And that's not even including all of the really important events that have happened, up until this point, that we as a culture have not yet learned from. We've not changed, we've not improved. And hopefully these protests mark a turning point where we as a culture, take a good hard look at ourselves at our at our past and say never again and actually live the values that we claim that we have. On that note, Ben, it's been it's been a pleasure talking to you. Thank you for taking the time out of your dayto talk with me, andall right. Alright folks. That's it for today. I'm George Stocker, and I hope you'll join me next time on the build better software podcast. Thanks

Transcript:Hi, I'm George Stocker, and welcome to the Build better software podcast. In this show, we explore practices, techniques and strategies that help software leaders enable their teams to build better software.That sounds a bit vague, so let's dive into what I mean.Software does not exist in a vacuum. While the act of programming involves a computer and compiler; producing software for humans to use requires so much more.  From the practices the team uses to create the code that runs the system, to the business interactions with the development team, to the societal implications of the software itself, everyone is affected by software creation in some form or fashion.  But, we don't build software that way, and we certainly don't teach software leaders -- those individuals accountable for producing software, how to take into account all these various aspects.For instance, we leave it to experience alone to teach software teams how to communicate with customers, conduct product discovery, decide on development practices such as test-driven development, determine the architecture of their software, not to mention important aspects like design, impact, and responding to change amidst an uncertain world. the Build better software podcast dives into these issues with experts in each of these fields; with the goal of helping software leaders enable their teams to produce better software.You don't have to be a manager to be a leader; and you don't have to be a leader in title to listen to this podcast, but I hope that by listening to this podcast, you'll become a better leader, and we'll produce better software for it.What does "build better software" mean?  It means to improve on all axes. Outward faces axes like impact, Value, Performance, Cultural, societal, and inward facing axes like team cohesion, strategic thinking, and knowledge creation.  This podcast will equip you to be able to address the hairy parts of producing software, before it's too late.So join me weekly to learn about the topics that will enable you and your team to produce better software, and explore what it means to build better software on the build better software podcast.