The Build Better Software Podcast

"Don't Say That At Work" with Michael Callaghan

Buy the book here: https://gum.co/dont-say-that/podcast-special Michael's pluralsight courses here: https://www.pluralsight.com/authors/michael-callaghan Rough 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 story Michael 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 you George 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 did Michael 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 foun...

Engineering Leadership with Tess Rinearson

Tess on Twitter: https://twitter.com/_tessr George 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 where not 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 oriented way 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...

Product Roadmaps with Bruce McCarthy

Bruce's site: https://productculture.org Bruce's book: Product Roadmaps Relaunched [https://www.oreilly.com/library/view/product-roadmaps-relaunched/9781491971710/] The 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 output George 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...

Should your Team adopt that open source project?

Open Source initiative: https://opensource.org [https://opensource.org] Transcript (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 m...

Resilient Management with Lara Hogan

Show Notes * Lara Hogan : @lara_hogan [https://twitter.com/lara_hogan]  * Website: WhereWithAll.com [https://wherewithall.com/] * Lara Hogan's Book - Resilient Management [https://resilient-management.com/] * Black owned DEI Consultants taking on more work [https://docs.google.com/spreadsheets/u/0/d/1giDIGTd5XvuCrP9n-Y70_NQPegvmcejdg8x3ypM5Iu4/htmlview?urp=gmail_link]; * Manager Voltron Bingo(PDF) [https://larahogan.me/resources/Manager-Voltron-Bingo.pdf] * LeadDev Together 2020 (Training for Engineering Managers) [https://ti.to/whiteoctober/leaddev-together-2020/] * Project Include [https://projectinclude.org/about/%20] * BICEPS Model [https://www.palomamedina.com/biceps%20BICEPS%20Model] 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 work George 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. ...