Technology Leadership Podcast Review

33. Making The World’s Best Pencil

Jurgen Appelo on Agile Toolkit, Amitai Schleier on Mob Mentality, Colleen Bordeaux on Coaching For Leaders, Scott Hanselman on Hanselminutes, and Buster Benson on Lead From The Heart. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. And, if you haven’t done it already, don’t forget to hit the subscribe button, and if you like the show, please tell a friend or co-worker who might be interested. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting March 2, 2020. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. JURGEN APPELO ON AGILE TOOLKIT The Agile Toolkit podcast featured Jurgen Appelo with host Bob Payne. Jurgen says that companies go through several stages in their lifecycle and investors make investment decisions based on what stage they think a company is in. Some investors, for example, wait until a company has achieved product-market fit before investing. At first, budgets are small because the risks are higher. Then, as more evidence is accumulated and the weaker companies have failed, the remaining companies get the bigger budgets. This is called an innovation funnel. Seeing how well this works in startup funding, Jurgen started to see the benefit that this could have if adopted inside organizations. Corporations tend to invest in projects by predicting what ideas will succeed. Instead, they could create an ecosystem where all the ideas can participate and they would go through stages like a startup where they need to find product-solution fit, product-market fit, and those that make it to the end get the biggest funding. They talked about business agility and Jurgen says that it is more important to focus on innovation and you will achieve business agility as part of the package. Bob pointed out that organizations are setting up skunkworks and innovation labs but, unless they can integrate their innovations with the core business, they will end up like Xerox Parc and other companies will exploit their innovations and disrupt them. Jurgen says that this innovator’s dilemma, as described by Clayton Christensen, requires you to switch to the mindset that your products and services don’t have eternal life. This is normal for any organism, but a species can live forever. The innovator’s dilemma, he says, was solved millions of years ago in nature. We need to borrow this regeneration capability from nature and say that the innovation is not the product or service; it is the system for generating products and services. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/jurgen-appelo-startup-scaleup-screwum-lean-agile-dc-2019/id78532866?i=1000465296924 Website link: https://hwcdn.libsyn.com/p/2/d/3/2d3a6b2936031059/leanAndAgileDC2019_Jurgen_Appelo.mp3?c_id=64647230&cs_id=64647230&expiration=1582618595&hwt=2e7c8bfffbafc47eef3a10950edf34ae AMITAI SCHLEIER ON MOB MENTALITY The Mob Mentality podcast featured Amitai Schleier with hosts Chris Lucian and Austin Chadwick. As a technical Agile coach, Amitai likes to sit with programmers and program, sit with testers and test, and sit with managers and manage. He loves to put things in terms of cost and risk and one of his areas of specialty is legacy code. When Amitai tried to make a career change from being a developer to being a technical Agile coach, he believed that if he could just say the right words in the right order with the right tone of voice, people would have to agree with him and behavior change would occur. This didn’t work. He realized that getting the words right is important, but you need to earn people’s trust first. He pair-coached with Llewellyn Falco and this taught him about the synergy between mobbing and coaching. One example of that synergy is in how you know whether the coaching is working. You measure by observing whether the new behaviors the coach introduced continue to be practiced when the coach isn’t around. An expensive way to test this is, after a year of coaching them, go away for a year and come back and see what still gets practiced. A cheaper and more Agile way is to have an iteration with a feedback cycle where you visit just long enough for the team to form a new habit and go away long enough to see if the habit sticks. Chris asked Amitai to talk about teams that he introduced to mobbing. Amitai described a team that had problems working together. Amitai had the program manager say to the team that, in the next iteration, if the team didn’t get fewer stories done, the manager would be disappointed because the team wasn’t trying hard enough to learn something. In practice, teams that start mobbing don’t slow down that much, but they need to hear that they’re allowed to. As a result of the switch to mobbing, the person who had been keeping decision-making for himself started talking people through what he knew, people who had previously been uninvolved started to engage with the problem-solving process, and the whole team was energized by it. Amitai doesn’t love that he had to force it on them the way he did and prefers to invite people to change their behavior, but sometimes, he says, you have to manufacture the willingness. Chris asked about the benefits and difficulties of mob programming with legacy code. First, Amitai said, mob programming is more extreme than Extreme Programming. If we were defining XP today, we would skip pairing and go straight to mobbing. Legacy code, or, valuable code we are afraid to change, is a kind of nexus of extremes as well. The cognitive challenges of software development are turned up all the way and mob programming is a great way to deal with these greater cognitive challenges. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/amitai-schleier-on-the-synergy-of-mobbing-and-coaching/id1485950034?i=1000463210922 Website link: https://mobmentalityshow.podbean.com/e/amitai-schleier-on-the-synergy-of-mobbing-and-coaching/ COLLEEN BORDEAUX ON COACHING FOR LEADERS The Coaching For Leaders podcast featured Colleen Bordeaux with host Dave Stachowiak. Dave started by asking about a quote from Colleen’s book, “Am I Doing This Right?” The Charles Jones quote says, “You are the same today that you’re going to be in five years except for two things: the people with whom you associate and the books you read.” Colleen says that when she looks at the people from whom she has learned the most and the people who helped her become who she is today, she finds that they all credit their success to the relationships they’ve cultivated and the books they’ve read. They spoke about the health implications of loneliness. Colleen says that our purpose and fulfillment in life and work is connected deeply to the relationships we cultivate and our ability to cultivate relationships is about being able to show up as ourselves. To Colleen, authenticity means being open to connecting with people and sharing your real experiences, who you are, and the challenges you’ve had so that it gives others permission to do the same. People are craving real human connection and we need to a better job of facilitating it. When Colleen was most lonely and isolated it was when she was in high school and her older brother became addicted to drugs, putting her family through an upheaval. Her high school and community had a culture of perfectionism and her family struggled not only with her brother’s addiction but also a fear of judgement from other people. Colleen felt she couldn’t share her feelings of loneliness with her friends or teachers because she didn’t know anyone who would receive it without judging her family. As she grew up and her family worked through it, she started to share her feelings and realized that the people in her network had their own struggles in their own families and were also afraid to share. They talked about how the negative relationships in our lives can make us into destructive thinkers rather than productive thinkers. Colleen described a time when she fell victim to this. She was insecure, negative, gossipy, super-judgmental, and someone who would get jealous or envious when she saw people around her succeeding and happy. The root cause, she says, was that she was not introspective and had no control over her own mindset. She says you have to look at yourself and consider, “Am I a net-positive in the lives of the people who I surround myself with? Am I somebody who encourages, supports, and gives positivity and light to the people around me or am I somebody who is quick to judge, quick to shut down, and somebody who struggles to nip my negative impulses in the bud?” When Colleen helped herself evolve from a crab to a magnanimous thinker, her relationships blossomed. She told a story about being on a huge project that involved constant travel and little autonomy. Instead of trying to fix the situation, she allowed her negativity to run rampant. She decided the problem was everybody else and the firm itself, so she went looking for a new job. She got an offer and she told one of her mentors. This mentor said, “Colleen, you can go ahead and take this job, but eventually you’re going to end up in the same situation. What are you going to do then?” She says that this hit her like a ton of bricks. Changing her circumstances might momentarily have distracted her, but it was her own thinking that was the real problem. Her mentor’s advice was that running away from things doesn’t move you forward. You are better off staying put, focusing on what you can control, and seeking what truly excites and energizes you to the point where you can’t stop thinking about it and you want to run towards it. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/455-how-to-create-great-relationships-colleen-bordeaux/id458827716?i=1000465792556 Website link: https://coachingforleaders.com/podcast/great-relationships-colleen-bordeaux/ SCOTT HANSELMAN ON HANSELMINUTES The Hanselminutes podcast featured Scott Hanselman with host Jeff Fritz. For the first time in about 700 episodes, Scott Hanselman was the guest on Hanselminutes. This episode came from an interview he did with the Live Coders who write code live in front of an audience on Twitch. Jeff asked first about Scott’s longevity. Scott’s blog has been going on for seventeen years and the podcast has been going on for fourteen years. The reason he has been able to do it consistently for that long is because he is not doing it five days a week. Scott says you need to set up systems by which your community can be self-sustaining and not require you to show up every single day. The next question came from community member roberttables. He asked how Scott delegates responsibilities for aspects of a community when community mentorship is not part of your role. Scott says that one of the things he finds communities don’t do is they don’t express what their long term goals are. He compared it to a couple getting married and having wedding vows but no mission statement. He and his wife wrote a business plan for the community of two that they were creating. When you put together a community, he says, whether it is a marriage or a community of fifty live coders, you set a tone. You have to make sure that 80 to 90% of the people are 100% behind the goals. Then, if a troll shows up, they are overwhelmed by the positivity of the group. That’s how you scale. It starts with two people agreeing on what they are doing. As an example of doing this wrong, he talked about how Reddit communities have problems because Reddit wasn’t founded with the agreement that we would all be nice to each other. Now they are trying to retcon niceness into the community. Scott says, “You can’t retcon nice.” The next question was from rockzombie2, who wanted to know how Scott grew his following. Scott says consistency is king. He asked, “How often have you visited someone’s blog and the very last blog post is a rededication of themselves to blogging?” That’s because people set up failure systems. Instead, it’s got to be something that you can’t ever stop. The interval between blog posts should be large enough that you start to miss it but not so large that coming back to it is a chore. You also need to have an internal check-in where you ask yourself, “Does this feed my spirit? Is this the thing that makes me happy?” If you feel you need a blog to grow, then that’s the wrong attitude. Michael Jolley, aka, BaldBeardedBuilder, asked how Scott manages the various kinds of content he produces. Scott says he keeps a backlog of ideas that are so good that they can write themselves. If he gets excited about something, he will both blog about it and reach out to someone related to the thing that has him excited and schedule a podcast. KymPhillpotts asked about resources for improving interviewing techniques. Scott believes interviewing is similar to improv. Just as you would in improv, you want to use the concept of “Yes, and...” He also recommended listening to early Terry Gross interviews from the mid-nineties. He recommends ignoring the content and instead studying how she conducts the interview. He says that people seem to think that you can just turn on the mic and start interviewing people and it is going to go well. He argues that you need deliberate practice. You need to listen to yourself and watch yourself on video and learn what you need to do better. Being charming is an art. You can practice it and become better at it. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/myself-its-not-weird-at-all/id117488860?i=1000462813484 Website link: https://hanselminutes.simplecast.com/episodes/myself-not-weird-at-all-HZclNwEe BUSTER BENSON ON LEAD FROM THE HEART The Lead From The Heart podcast featured Buster Benson with host Mark C. Crowley. Buster has written a book called “Why Are We Yelling? The Art Of Productive Disagreement”. Buster started out by saying that disagreements as battles has been a useful tool for us as a species before we had institutions of reason and science. It was how you claimed your spot on the hill. While “might makes right” continues to be what we fall back to when everything else falls apart, it is no longer the most productive way to think about disagreement. The kinds of problems we face today and the arena that we’re having conversations in have changed. Before, it was about keeping the tribe together. Now, it is about creating relationships and collaborating across tribes. We need to train ourselves to become great collaborators and see disagreement as an opportunity and as a skill we can practice. Mark brought up a statistic from Buster’s book that says nine in ten of us feel that arguments are almost always an unproductive venture. As a result, we steer clear of them. He asked Buster what he has learned about why having disagreements is so highly supportive of having healthy relationships. Buster says that if you think about a disagreement as a milestone or landmark of something important that is currently in a stuck state and ask what, long term, is going to best guarantee the success of this relationship, it is about becoming high-functioning in terms of addressing and facing problems and resolving them. This is difficult because avoidance is natural. When you are thrown into an arena where you don’t have the skills to operate in it successfully, you naturally run away.  Buster talked about anxiety debt. These are the things you have not been able to face with confidence and they end up wearing you down, decreasing your happiness, and making you less healthy. Just as there is never an urgent need to clean up tech debt until it threatens the success of your company, anxiety debt in your relationships can be neglected and become harder and harder to address as it accumulates over time. Mark asked how to get yourself centered so that you can have a disagreement that doesn’t knock you off your foundation. Buster says the first step is get over the misconception that we can change minds. Minds do change, but we don’t change them directly; we change them with our own mind changing. Rather than thinking “I’m going to move your mind from point A to point B”, think of your own mind and the other party’s mind each as a pile of rocks and you each have to contribute your rocks to building a new, third pile that incorporates both perspectives. This third perspective is more inclusive and transcends the problem. You don’t know in advance where the third perspective is and you have to use the other person’s perspective to triangulate it with your own. That means you have to use them as a resource rather than a receptacle of new information. Mark asked about emotional situations where things are so polarized that each side thinks the other is crazy. Buster says that in these situations, the fact that we think each other is crazy raises the question, “What do I not know about you and what do you not know about me that makes us think each other is crazy?” To resolve this, you can ask questions that you don’t know the answers to. No matter what the other party says, it will give you new information and new insight into things. Mark asked for an example. Buster says that if you are with your polar opposite political opponent, you can ask a set of questions that help you understand how their beliefs arose. These questions take you out of battle stance and help you build a relationship with them. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/buster-benson-mastering-art-productive-disagreement/id1365633369?i=1000464961355 Website link: https://blubrry.com/leadfromtheheartpodcast/55513911/buster-benson-mastering-the-art-of-productive-disagreement/ LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website: 

32. A Bucket Full Of Crabs

31. Waiting For The Dinosaurs To Leave

Kevin Callahan on Engineering Culture by InfoQ, Matt Wallaert on The Product Science Podcast, Mirco Hering on Troubleshooting Agile, Ryan Ripley on Agile FM, and Adam Tornhill on Maintainable. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. And, if you haven’t done it already, don’t forget to hit the subscribe button, and if you like the show, please tell a friend or co-worker who might be interested. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting February 3, 2020. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. KEVIN CALLAHAN ON ENGINEERING CULTURE BY INFOQ The Engineering Culture by InfoQ podcast featured Kevin Callahan with host Shane Hastie. Kevin helps people solve complex problems together. Sometimes that looks like Scrum, Kanban, and technical practices, and sometimes that looks like organizational development and strategy. Shane asked about positive organizational development. Kevin says that positive organizational development is an interconnected body of work with the core idea that true sustained change doesn’t happen when we simply try to fix things that are weak or broken. Positive change suggests that you go to the places that are already good and you amplify them and the places that weren’t working so well cease to be relevant. Shane asked what this looks like in practice. Kevin says that, because he is actively inviting people into the room and looking to see what the group already knows together, he finds it energizing and refreshing and people lean into it and feel like they belong there. Shane asked how someone in a position of influence who wanted to create some kind of change in their organization would approach the organization and their people. Kevin likes to start with open questions that get the people to imagine everything was right in the company and ask what people are  doing differently, what customers are saying, what quality is like, and what stories people are telling each other when they don’t think anyone is listening. These positive questions get people to imagine what could be and starts in motion the change effort that makes it possible to achieve the change. You may get answers like “I only want to work four hours a day,” or, “I want six months of paid vacation,” but eventually you may get answers like, “I really wish I had the opportunity to learn more things.” Shane connected Kevin’s ideas to Dave Snowden’s notion of sense-making and asked how you make sense from non-viable statements like, “I want to work four hours a day,” so that you arrive at more viable questions like, “How do I stay at home more?” Kevin says that instead of reacting to non-viable requests by blowing them off, ask follow up questions to build a bigger narrative. You could ask clean language questions like, “What kind of four hour workday? What would come before your four-hour workday? What would come after?” This builds a bigger narrative that helps you respect something that is valuable to this person while still respecting the organization’s collective needs. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/kevin-callahan-on-positive-organisational-design-complex/id1161431874?i=1000462364585 Website link: https://soundcloud.com/infoq-engineering-culture/kevin-callahan-on-positive-organisational-design-and-complex-systems MATT WALLAERT ON THE PRODUCT SCIENCE PODCAST The Product Science Podcast featured Matt Wallaert with host Holly Hester-Reilly. Trained as a behavioral scientist, Matt is Chief Behavioral Officer at Clover. He says he is always fascinated by outliers, those customers that are using his products in unconventional ways. He says that having conversations with these users can sometimes push you in startling directions to build new things or think in different ways.  The behavioral science team is given behavioral outcomes that the company needs to accomplish such as, “everybody needs to get a flu shot,” and figure out what needs to be done to make it happen. They look at two groups of outliers: people who consistently did it and suddenly stopped and those that consistently did not do it and suddenly started. They found that people who get the flu shot for the first time often do so because of the birth of grandchild. This led them to start a flu shot campaign that was personalized to your personal health goal. Instead of saying, “You should get the flu shot for you,” it often said, “You should get it so you don’t get your wife sick, so you don’t get your grandchild sick, or so you don’t get your church congregation sick.” He contrasted this collectivist form of motivation with products like Spotify that are all about benefitting the user directly. Expanding the set of motivations we examine to include people’s willingness to do things on behalf of another person, on behalf of a culture, or on behalf of an identity, he says, is undeveloped in modern product management. If there is a number one product hobgoblin of early founders, it is their belief that the pros outweigh the cons. They massively overweight the pros and massively underweight the cons. But lately, there have been a whole host of startups that are not about providing additional value but simply about minimizing costs, and not just economic costs but also mental attention costs. Finance companies think about their products as “share of wallet”. For, say, American Express, of the financial transactions that a customer performs, they want to know how much of that is going on an American Express card. Their job is to maximize this share of wallet. Similarly, Facebook attempts to maximize share of attention. This is an impoverished view of product-building. Companies like this are leaving off the “I” in ROI. One of the problems of the “share of attention” view of the world, is that it means everyone is in competition with everyone else. Even products that seem far apart, such as a product in the exercise space and one the video game space, are competing for share of attention. Matt thinks people are going to get smarter about where they spend their attention. A whole new product class will come out around automating the things we don’t care about. The rise and fall of Blue Apron, he says, was a dramatic characterization of the misunderstanding of automation. Blue Apron sold the world on automated food. That is not what Blue Apron is. They went on to talk about the desire for statistical significance in every experiment and how the context of the experiment drastically affects how much certainty is really needed. He talked about how most quantitative analysts who see an intervention that is measured to work 80% of the time in the sample of the population measured would say, “I got nothing,” and end the experiment. So Matt says, “Let me tell you about this intervention: It is a tiny pill, dissolves in your mouth, has no side effects of any kind, costs a penny to produce, tastes like unicorns and rainbows, and instantly cures all forms of cancer forever. Maybe we should further investigate this intervention.” He compared his book Start At The End to Thaler and Sunstein’s Nudge. His book is more about how to create a process, a team, and an organization around behavioral science approaches. Instead of running his team as a research organization, he runs it like a factory. This makes it easier for an executive to understand how it all works. He says his book is more a handbook. Half the book is how you go about building the intervention design process and the other half is more advanced topics. He is seeing it being taught in college courses in disparate programs, including business administration, marketing, and implementation science. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/matt-wallaert-hypothesis-great-product-teams-use-behavioral/id1451623431?i=1000462456956 Website link: https://anchor.fm/product-science-podcast/episodes/The-Matt-Wallaert-Hypothesis-Great-Product-Teams-Use-Behavioral-Science-to-Build-Products-That-Create-Change-ea3s54 MIRCO HERING ON TROUBLESHOOTING AGILE The Troubleshooting Agile podcast featured Mirco Hering with hosts Douglas Squirrel and Jeffrey Fredrick. Mirco is the author of DevOps for the Modern Enterprise. They talked about dogmatism. Marco says that he sees Agile and DevOps as a toolbelt to solve problems in organizations but not everyone he works with thinks this way. One of the Agile coaches he once worked with said on his first day, “You shouldn’t call these user stories. They are PBIs (product backlog items).” Mirco asked, “What value would that provide? Nobody was confused about the term user story. If anything, you are now adding confusion.” He sees this kind of dogmatism in many organizations. He says that, for him, being pragmatically agile always comes down to identifying the next experiment and having rigorous continuous improvement. Squirrel asked Mirco how one can help companies that aren’t familiar with agile ideas to avoid the dogmatism and make the pragmatic choices that improve their process. Mirco believes it starts with value stream mapping. This gives you a good visual of the overall process and you can identify bottlenecks, quality holes, and things that take too long. Jeffrey brought up the book Crossing The Chasm and how the early majority change because they don’t want to be left behind and the late majority change because the new behavior is the standard. He asks how, when this is their motivation, do you help the business to get from “we need to be Agile to be Agile” to “having a purpose.” Mirco says that, very early on, you need to ask, “How will we know we’ve been successful?” Mirco sees companies at conferences describe a world where they can do forty deployments a day and have all employees singing and dancing everyday. They are not anywhere close to this ideal. They need to figure out how to see in two months time that they are making progress. They should be able to ask, “What does the business want to do that it can’t do now.”  As a consultant, the very first thing you do is listen. Often they start to tell you some stories. Then you start trying a couple of ideas. You could do a bit of decoupling on the architecture or a bit of Agile coaching on a failing Agile project. You have a large tool belt of tools to choose from. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/devops-for-the-modern-enterprise/id1327456890?i=1000462577701 Website link: https://soundcloud.com/troubleshootingagile/devops-for-the-modern-enterprise RYAN RIPLEY ON AGILE FM The Agile FM podcast featured Ryan Ripley with host Joe Krebs. Ryan was on to talk about the book he co-authored with Todd Miller called, “Fixing Your Scrum.” He says that the book came out of a conversation he had with Todd two years ago about the Scrum anti-patterns that they were seeing in the wild over the past twenty years and how the two of them, as consultants, solve them. Most Scrum books are very theoretical. Ryan and Todd, by contrast, spent only one page on the Scrum framework and jumped right into advanced topics. Joe brought up that Scrum tends to turn into something robotic and oriented around checklists. Joe considers this form of Scrum to be lifeless and low in energy. He finds that nobody leaves the events with a smile on their face and he wonders how the book would help such people. Ryan says that such mechanical Scrum is very common and it is because the principles and values are lacking. It becomes rote and legalistic. He says that he and Todd don’t care that much about Scrum. Instead, they care about empiricism and want to bring forward transparency, inspection, and adaptation, and use the Scrum values of focus, openness, courage, commitment, and respect to make adaptations to products as needed to deliver the right thing at the right time to the right customer. Without having the values in place, empiricism can’t work. Companies have gone to the mechanical version of Scrum to avoid empiricism. Empiricism is table stakes now. Twenty years ago, empiricism was a cute idea that people could dismiss because the blue chip companies were fat, happy, and dumb. Their problem was success. Today, no matter what industry you’re in, banking, taxi cabs, or real estate, there is a startup looking to destroy your market. He asks, “Who would have ever thought the taxi cab industry would be upended by Uber and Lyft? Who would have ever thought that the largest real estate company in the world would own zero real estate and be Airbnb?” Joe asked about the sentence, “The Scrum Master’s work is never done.” Ryan says that the statement comes from the rapid rate of change today. He and Todd believe that the majority of times a Scrum team fails, it is because a Scrum Master is settling. The Scrum Master is tolerating organizational or team impediments.  The reason a Scrum Master’s job is never done is that those impediments morph and change and emerge constantly. Ryan has yet to see a company where nobody leaves, markets don’t shift, and budgets don’t become constrained. As Scrum Masters, our role is to help organizations make sense of the complexity through the use of the Scrum framework and to help teams refocus and reshape what they could and should be doing to serve a customer. Ryan says nothing about the Scrum Master role is about the Scrum Master. When Ryan transitioned from a project manager to a Scrum Master, this part was difficult for him. Back when Ryan was a project manager, everything was about him: he was the one making the decisions, driving people to a date, or getting in front of boards of directors and making a speech. As a Scrum Master, we are in the back of the room watching the dev teams show off their software. None of this is about the Scrum Master. The job is to serve others. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/ryan-ripley-agile-fm/id1263932838?i=1000462512766 Website link: https://agile.fm/agilefm/ryan-ripely ADAM TORNHILL ON MAINTAINABLE The Maintainable podcast featured Adam Tornhill with host Robby Russell. Robby started out by asking Adam about the common traits of a maintainable solution. Adam first likes to see the solution optimized for understanding. Second, he wants to see alignment between the architecture, the team boundaries, and the way the system evolves. Last, he wants the capability to deliver anytime with known quality. In terms of team boundaries, Adam wants to avoid having multiple teams working in the same parts of the code for different reasons because that has a high correlation to quality issues and makes it hard for individuals to maintain mental models of the system. He says you want clear operational boundaries between teams but then you also want each team’s knowledge boundary to be slightly wider so that you are familiar with other parts of the system and know other teams’ members as people. Robby asked what about a separation between a team working on new features and another fixing bugs. Adam is not a fan of that form of separation because it cuts out an important feedback loop. Robby asked what other developers get wrong when discussing technical debt. Adam says that many developers call any code that’s bad technical debt, but to Adam, it is not technical debt unless you have to pay interest on it. With a high degree of technical debt, you tend to see lots of effects on the product roadmap, you get longer and longer lead times, and your end users experience defects that take a long time to fix. Robby asked about Adam’s book on behavioral code analysis, Software Design X-Rays. In behavioral code analysis, the emphasis is placed more on the organization and the developers building the code than on the code itself. You analyze using measurements from version control data and project management data and it is used to prioritize technical debt or reason about social factors of software development projects. Some examples are detecting knowledge gaps in the code, code written by developers no longer present, or uncontrolled coordination needs between different developers in the code. Robby asked what motivated Adam to write the book. Adam says that Software Design X-Rays follows in the tracks of his first book, Your Code As A Crime Scene, which was written to share techniques Adam had been using in his consulting work. The theme for both books is, “How can you make it easier and cheaper to maintain your software?” There are several patterns he uses often. One is the concept of hot spots, which help identify complicated code that we work with often. The data shows that any application can have its hot spots narrowed down to two or three percent of the codebase. This is a positive message that tells us we don’t need to rewrite whole programs but can make big improvements by changing only a small percentage of the product. Robby asked how to prioritize work on technical debt reduction. Adam says to prioritize the most complex modules using hot spot analysis. With slightly more advanced analysis, you can get hot spots down to the function level and get quick wins within days. For your initial refactorings, you should use techniques like mob refactoring to help spread knowledge of how to attack these kinds of problems and get everyone to align on the approach. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/adam-tornhill-prioritizing-technical-debt-behavioral/id1459893010?i=1000463144606 Website link: https://maintainable.fm/episodes/adam-tornhill-prioritizing-technical-debt-with-behavioral-code-analysis-yigwD2Ga LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website: 

30. 100 Steps To Product Delivery Nirvana

Johanna Rothman on Programming Leadership, Thomas “Tido” Carriero on Product Love, Adam Davidson on Lead From The Heart, Josh Wills on Software Engineering Daily, and Amitai Schleier on Programming Leadership. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. And, if you haven’t done it already, don’t forget to hit the subscribe button, and if you like the show, please tell a friend or co-worker who might be interested. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting January 20, 2020. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. JOHANNA ROTHMAN ON PROGRAMMING LEADERSHIP The Programming Leadership podcast featured Johanna Rothman with host Marcus Blankenship. Marcus started out by asking Johanna why it is important to think about managing ourselves. Johanna says that when we don’t manage ourselves, we don’t have the capability to manage other people. For example, if we insist on micro-managing people, they cannot grow and we prevent them from doing their best work.⁠ ⁠Marcus asked her what micromanagement has to do with managing ourselves. Johanna says that micromanagement comes from fear. You need to learn to manage yourself to manage this fear and reduce your need to micromanage. ⁠ ⁠She says the reason the first book is about managing yourself is that if you can avoid doing the things that make people feel badly, you can create an environment where people can excel.⁠ ⁠They talked about surveys and Marcus asked Johanna’s opinion on anonymous versus named survey responses. Johanna says that when you have a culture where there is a lot of blaming and micromanagement and little coaching, she would recommend an anonymous survey.⁠ ⁠Marcus talked about how technical managers often know how to do the work itself very well and he asked Johanna when this can trip us up. One way it trips us up, she says, is that people on the team don’t get a chance to practice if the manager is writing code instead of managing. Second, when you have not been in the code in a while, you do not know what it looks like anymore. ⁠ ⁠Marcus asked how managers can get time to think in today’s high time-pressure environments. Johanna says that if you are spending a lot of time in meetings, you should be looking at whether you can delegate any of those meetings to the people doing the work. This delegating is not sloughing off your responsibilities, but making sure you are not part of a team that you are not supposed to be a part of.⁠ Apple Podcasts link: https://podcasts.apple.com/ca/podcast/becoming-better-manager-means-starting-yourself-johanna/id1461916939?i=1000460138590 Website link: https://programmingleadership.podbean.com/e/becoming-a-better-manager-means-starting-with-yourself-with-johanna-rothman/ THOMAS “TIDO” CARRIERO ON PRODUCT LOVE The Product Love podcast featured Thomas “Tido” Carriero with host Eric Boduch. Tido oversees all of engineering, product, and design at Segment. Segment provides customer data infrastructure or CDI, helping companies collect, unify, and connect data about their own interactions with their customers. It gives these companies a unified view of their customer data across all channels.⁠ ⁠When he joined Segment, Tido was blown away by how robust the ecosystem was and by the attractive idea of empowering business teams, marketing teams, and product teams by installing application tracking once and being able to turn on integrations with the flick of a switch. Often, he says, a lot of business and marketing and less technical folks are blocked from doing the best job they could do because of tough integration problems that Segment solves.⁠ ⁠Segment naturally has a lot of adjacencies. They touch critical customer data and they need to decide whether to use that to empower engineering, marketing, or others. This requires being clear at the beginning of the year that they will pick two or three bets as an organization to focus on.⁠ ⁠Eric asked Tido what product leaders often do wrong. Tido says the biggest mistake product leaders make by far is not looking in the mirror and making an honest assessment of where things are. Getting attached to an idea makes it harder to give it a critical look. Often, you’re only a small pivot away from a valuable product. As the leader of an organization, he sees his job as creating a culture where failure is not just okay but celebrated. If people are getting slapped on the hand for failure, they will just get even more committed to their first ideas. Healthy teams that seriously innovate look at the data and are willing to pivot when it tells them unpleasant things.  Apple Podcasts link: https://podcasts.apple.com/ca/podcast/thomas-tido-carriero-joins-product-love-to-talk-about/id1343610309?i=1000459980786 Website link: https://www.spreaker.com/user/casted/edited-tido-joins-product-love-mp3 ADAM DAVIDSON ON LEAD FROM THE HEART The Lead From The Heart podcast featured Adam Davidson with host Mark C. Crowley. Adam Davidson is the creator of the Planet Money podcast and is staff business writer at The New Yorker. He has a new book called The Passion Economy. The theme of the book is that choosing your career used to mean choosing between work that makes your heart sing and work that pays well but disconnects you from your passions, but the new world order demands that we follow our passions and pursue work that leverages both our talents and our interests.⁠ ⁠Adam’s grandfather worked his entire career in a ball bearing factory and only made a good living by working double shifts. He believed that people who follow their passions go nowhere in life.⁠ ⁠Adam’s father was the opposite. Making money was far less important to him than following his dream of performing as a Broadway actor.⁠ ⁠These two men represent the dichotomy of having to choose financial success or your passion but not both.⁠ ⁠The people of Adam’s father’s generation and his grandfather’s generation had to choose between a life of passion and a life of financial success, but people today, Adam says, are lucky. They are lucky for the reasons that terrify us. Adam says, “All of these forces that have done so much damage to the stability of the 20th century economy also provide exactly the tools that allow us to figure out what we uniquely love and are good at and find those people, even if they’re thinly spread all over the country or all over the globe, who also crave what it is we can provide and are willing to pay for it.”⁠ ⁠Mark summed up the book as being about combining your training and expertise with a personal passion to find your own niche. According to Adam, some people take a total left turn and go into a completely different field later in their lives, but the most successful people he has met combine their passion with the skills they have previously acquired.⁠ Apple Podcasts link: https://podcasts.apple.com/ca/podcast/adam-davidson-new-rules-for-thriving-in-twenty-first/id1365633369?i=1000462188105 Website link: https://blubrry.com/leadfromtheheartpodcast/54035306/adam-davidson-the-new-rules-for-thriving-in-the-twenty-first-century/ JOSH WILLS ON SOFTWARE ENGINEERING DAILY The Software Engineering Daily podcast featured Josh Wills with host Jeff Meyerson. Josh Wills was the director of data engineering at Slack when Slack was building out a solution to scaling its data infrastructure. When the first analysts at Slack were hired, their only option was to spin up their own little databases that had cached copies of Slack’s main transactional database. Eventually, Slack hired data engineers that built systems that could scale up what an analyst could do. They built up a lot of infrastructure involving Airflow jobs producing Parquet files on S3 that were queryable through tools like Presto and it was, according to Josh, a “ghost city” for a while. All the while, the analytics team was still using the existing infrastructure of ETL jobs running on the transactional database. It wasn’t until Slack started aggressively hiring analysts, data scientists, and engineers from the Googles, Facebooks, and Twitters of the world that they had people who knew how to use the stuff Josh and his team were building. Jeff asked how the various design philosophies coming from the new hires from Google and Facebook got resolved. Josh said it got resolved by him making all the decisions. There were a million things to do, so the design direction was often the result of whoever was the first mover. If Josh had it all to do over again, he would do many things differently, but he knows that nobody would appreciate it because they would have never experienced the inferior designs. It is hard to appreciate the pain that something saved you. Most of your good decisions are invisible and taken for granted while your bad decisions cause pain and suffering forever. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/slack-data-platform-with-josh-wills/id1019576853?i=1000462100792 Website link: https://softwareengineeringdaily.com/2020/01/10/slack-data-platform-with-josh-wills/ AMITAI SCHLEIER ON PROGRAMMING LEADERSHIP The Programming Leadership podcast featured Amitai Schleier with host Marcus Blankenship. Amitai talked to Marcus about his fork of qmail called notqmail. Qmail is a Unix program for running an email server that, unfortunately, hasn’t been updated in twenty years and has a number of rough edges. Over the last twenty years, Amitai has invested time into softening qmail’s rough edges through improved package management. More recently, Amitai started thinking about getting the people who are working on their own forks of qmail to collaborate on a single fork. The first step was getting some advice. A key piece of advice came from Llewellyn Falco. Llewellyn said, “Qmail already has a lot of nice seams and interfaces. Without too much more work and risk, you could add a couple more seams so that whatever modernization is required could be done as plugins or extensions. The next problem to think about is egos. Not all ideas are going to win.” He then gave Amitai the best piece of advice: “Whatever you do, offer yourself to other programmers to get their code converted to extensions first. As to which implementation of a particular new feature is to be incorporated, that decision is not your call. Take as extensions as many implementations as people want to give and let users decide.” Marcus asked about how to influence a group of people on a project without being coercive. Amitai says that he discovered years ago that when a situation is a little confused, his default response is to seek to lower his perceived social status. Otherwise, he cannot influence the way he wants to if he’s a big shot that people are supposed to listen to. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/collaboration-and-notqmail-with-amitai-schleier/id1461916939?i=1000462047766 Website link: https://programmingleadership.podbean.com/e/collaboration-and-notqmail-with-amitai-schleier/ LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website: 

29. An Honest Look In The Mirror

Neil Pasricha on Coaching For Leaders, Corey Quinn on On Call Nightmares, Eric Ries on Lean Startup Company, Craig Daniel on Build by Drift, and Bryan Liles on Hanselminutes. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. And, if you haven’t done it already, don’t forget to hit the subscribe button, and if you like the show, please tell a friend or co-worker who might be interested. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting January 6, 2020. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. NEIL PASRICHA ON COACHING FOR LEADERS The Coaching For Leaders podcast featured Neil Pasricha with host Dave Stachowiak. Neil described his first professional role, working at Proctor & Gamble. He had graduated from Queen’s University in 2002, one of the top business schools in Canada and, at the time, a job at Proctor & Gamble was one of the top marketing jobs you could get. Neil felt like Charlie Bucket winning the golden ticket.  But he was horrible at the job. He had been expecting to spend his days creating PowerPoint presentations and instead was asked to create spreadsheets to analyze trucking, gasoline, and a million other variables to determine how much to increase the price of mascara. As a high achieving adolescent, he took his failure to be his own fault rather than a factor beyond his control. He worked late, came in on weekends, and started grinding his teeth. A few months in, the company wanted to put him on a performance improvement plan. He couldn’t handle the notion of being fired, so he quit nine months in. He catastrophized this event. He thought, “If I can’t work here, at the best company, with the most supportive culture, kind people, and a lot of structure, I can’t work anywhere.” He thought, “If I can’t do marketing, my highest mark in business school, I certainly can’t do finance,” and, “If I look for another job, they’re just going to call P&G who will say ‘This guy is horrible.’” He pictured the worst-case scenario: he thought he would go bankrupt and thought his life was over as a working person. He calls this, “pointing the spotlight at yourself”. High achievers have a tendency to think, “It’s all about me and I’m terrible.” He was a low-resilience person. He wrote his new book, You Are Awesome, about resilience because he identified himself as lacking it. Like most of us these days, he grew up without famines, wars, and other sources of societal stress. He got the gold stars and participation ribbons and didn’t have the tools to handle failure. He didn’t see for years that the P&G blow actually was his first lesson in resilience. He says we look at successful people and think their lives were a string of successes, but the most successful people are those that have also seen the most failure. He cited Cy Young, who has won the most games in baseball ever. He also has the most losses. Nolan Ryan, who has the most strikeouts, also has the most walks. Dave talked about his first full-time role as director of a center that helped students learn math and reading skills. He was average at the job and the culture wanted people to show a lot of initiative. He struggled, got passed over for promotions, and the feedback he was given was that he wasn’t moving fast enough, wasn’t taking initiative, and wasn’t meeting deadlines. Like Neil, Dave dropped out and started his coaching business. Neil says that Dave’s and his own feelings of incompetence are a result of the spotlight effect. The spotlight effect is the feeling that we’re being noticed, observed, and judged more than we really are. Nobody at P&G probably even remembers Neil, but the spotlight effect had caused Neil to feel that everybody had watched him fail. To help reduce this effect, Neil asks himself three questions: 1. “Will this matter on my deathbed?” 2. “Can I do something about this?” And 3. “Is this a story I’m telling myself?” For example, if you fail a biology test, the story you might tell yourself, “I failed my parents.” Dave asked whether Neil is now comfortable with being uncomfortable. Neil had thought that he had reached a point where he was finally comfortable with being uncomfortable, but when he left Walmart to take his side hustle full-time, he suddenly felt uncomfortable again. He says you have to treat it like yoga. You have to keep learning it until you learn it. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/448-the-value-of-being-uncomfortable-with-neil-pasricha/id458827716?i=1000461086169 Website link: https://coachingforleaders.com/podcast/value-being-uncomfortable-neil-pasricha/ COREY QUINN ON ON CALL NIGHTMARES The On Call Nightmares podcast featured Corey Quinn with host Jay Gordon. Corey started his on call career in what he called an “abusive” environment. One year in, a new manager was dropped in and the first thing this manager decided was that he wasn’t going to be on call himself. The number of people on call dropped from four to three and then another person left. So Corey was on call 50% of the time and he could never schedule his life around it. At the end of that time, Corey swore he would never put himself in this situation again. When he started the Duckbill Group, he decided that anything he did would be “business hours only”. Jay asked Corey what in 2019 most excited him in the world of cloud. Corey said that it was the awareness by the providers that building the fastest, most exciting, far fetched, far flung technologies was not going to be what won them the hearts and minds of their customers. Instead, he saw the large providers speaking to enterprises about migrating from data centers to cloud environments. They talked about Microsoft’s advantage in selling the cloud to enterprises. Corey says one of Microsoft’s big advantages in cloud is that they have forty years experience apologizing for software failures. Explaining these failures to non-technical audiences is something Microsoft excels at and Google and Amazon have had to learn. Jay brought up that the embrace of managed Kubernetes was a big trend in 2019. Corey says that his objection to it is that if you run everything on top of Kubernetes, you’ve abstracted away what you’re doing from the cloud providers’ built-in primitives so much that it becomes challenging to do workload attribution of cost. Programmatically figuring out which workload is the expensive one is surprising difficult. Jay talked about Hashicorp’s rise in 2019, providing tooling around cloud agnosticism. Corey said that one of the best conversations he had on his own podcast, Screaming In The Cloud, this past year was with Hashimoto. Hashimoto argued that Terraform provides workflow portability rather than workload portability and that one is worth pursuing and the other one is not. Jay said that this was the first year that Amazon talked about multicloud. Corey says they talked about hybrid but still avoided multicloud. Corey believes that every cloud provider hates multicloud until they realize a large customer is going to go with a different provider, then multicloud is wonderful. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/episode-46-year-in-review-corey-quinn-duckbill-group/id1447430839?i=1000460596737 Website link: https://www.podomatic.com/podcasts/oncallnightmares/episodes/2019-12-23T11_00_16-08_00 ERIC RIES ON LEAN STARTUP COMPANY The Lean Startup Company podcast featured Eric Ries with host Alton McDowell. This episode was recorded during the 2019 Lean Startup Conference in San Francisco. Eric Ries is the author of The Lean Startup and The Startup Way. Alton started by asking Eric what the Lean Startup is and how it got started. Eric says that Lean Startup is the application of theories like lean manufacturing, customer development, Agile, DevOps, and design thinking to the process of innovation itself. It started from a failure: Eric believed that if you had great technology and a good idea and were in the right place at the right time, you would be a successful entrepreneur because that’s how it happens in the movies, the magazines, and the case studies. Instead, the result of doing everything right was colossal failure. He, along with other entrepreneurs, developed a playbook of approaches to solve this problem. This included such insights as having customers involved in product development far sooner than was considered normal at the time, using a scientific decision-making framework to determine if the product was getting better or worse, and focusing not on the quality and perfection of the final product but on the speed of iteration and rate of improvement. From those insights we got the minimum viable product, Steve Blank’s customer development, the build-measure-learn feedback loop, and the idea that, if the strategy is not working but you want to stay true to the vision, you should pivot. Alton asked what advice Eric gives people who are at the beginning of their startup journey. Eric says people who come to talk to him expect to hear about metrics and iteration. The issue they need to hear about is a vision issue. Eric says that if you don’t have a vision, you literally can’t pivot. Eric says people bifurcate into those who say customers don’t know what they want and the entrepreneur is the visionary and those who are passionate about some technology but are in search of a problem or just want to make money. This second group can’t formulate hypotheses worth testing. Eric says entrepreneurship is a hard slog. If you’re working on something you don’t care about, if it fails, it’s a blessing. The curse is if it works because you have to keep working on something you don’t care about. So you may as well pick something you care about, both for emotional reasons and efficiency reasons. Your experiments will be better designed and your rate of iteration will be faster if you have some concrete idea of what is supposed to happen because you can compare your experimental results against expectations and pivot more quickly. Eric says that even though he loves technology more than anyone, the path to innovation and breakthroughs is not through technology itself. It is usually through the application of technology to a problem domain that has historically been underserved and requires a level of insight about the underlying problem being solved. Larger companies looking for digital transformation expect Eric to come in and say that if you Bitcoin and drone a little more, you’ll have digital transformation. Eric’s advice instead is that management transformation must precede digital transformation or it’s not going to work. Learning to manage a software project is not like managing other things. If you are not a technologist yourself, you are too vulnerable to being sold snake oil. Alton asked Eric what his personal pivot points in his career journey were. Eric said that he originally dropped out of an Ivy League university to start building a social networking startup but it was focused on networking with employers and was killed by the dotcom crash. He went back to school and finished his degree. When he graduated and started applying to employers, he got very different reactions to the section of his résumé about the failed startup. In Boston, they wanted to know what the failure in strategy was that led to his startup’s demise. At the time, he didn’t know how to answer the question. In New York, people didn’t care about the failure. In Seattle, the ex-Microsoft people liked the technology part of his story but didn’t care at all about the startup failure. In Silicon Valley, the fact that he had done the failed startup was the defining thing on his résumé and everyone viewed it as an unequivocally positive development because he learned on someone else’s dime and wouldn’t make those same mistakes again. Alton asked what an entrepreneur should do if they find out that another startup has a very similar product and how they can stay innovative. Eric says that competitors don’t put startups out of business; startups put themselves out of business. You have to stay focused on yourself and not get distracted by what your so-called competitors are doing. Eric finds himself in board meetings at least three times a year where people ask what to do about some competitor. The only correct answer is “nothing”.  The fear of competitors prevents entrepreneurs from testing their ideas. If you’re afraid that a big company is going to steal your idea if you reveal it to the world, Eric has an exercise for you. Take an idea from your backlog, find the relevant product manager and the relevant company, and try to get them to steal your idea. You will cure yourself of your fear. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/building-startup-for-long-term-success-eric-ries-alton/id734777473?i=1000459318894 Website link: https://soundcloud.com/lean-startup/building-a-startup-for-long-term-success-eric-ries-alton-mcdowell CRAIG DANIEL ON BUILD BY DRIFT The Build podcast by Drift featured Craig Daniel with host Maggie Crowley. Their topic was “What does Drift look for when hiring product managers?” Craig says that the product manager role is unique in that you don’t have direct reports but you need to be able to influence the engineering team, the designers, and a slew of stakeholders that includes customers. Regarding technical skills, Craig says they look for systems thinkers with the ability to break down a problem, articulate their breakdown, look at data and combine that data with qualitative research. Maggie asked about hiring for associate PM roles and Craig says it goes back to a core principle that a person’s aptitude and attitude outweighs their experience. Craig defines aptitude as a combination of ability to learn and curiosity. These people are those who can grow faster than normal. Maggie added that these people are paying attention to the world around them, are asking questions of the tools that they’re using, and are not just assuming things are the way they are. For more experienced hires, Craig is looking for results. Sometimes there are good people who were in bad companies or joined a startup prior to product-market fit that never got off the ground. If they don’t have results, you want to see outputs: shipping things, building partnerships, and media coverage. People who are successful in product are those that can build coalitions, roll up their sleeves, do the hard work, and get stuff done. Maggie says that PMs can be afraid to be accountable for the end result. It is easy to say, “I wrote my one pager,” “I wrote the spec,” or “We stuck to the timeline.” There are so many excuses that you lose sight of the fact that you need to be accountable for results. Regarding the interview process, Craig says Drift’s process consists of a design leader interview, a product team interview, an executive interview, and something called, “The Who method.” Craig himself is looking for fit. This is not culture fit. It means, “What is this person great at, what do they want to do, and what do we have available or can make available?” To get at fit, Craig asks about their superpowers. If they’re at a company with, say, five product managers, what would everyone say they are the best of the five at? What are they worst of the five at? He also wants examples of truly exceptional work. This tells him what they think exceptional is, what their emotional intelligence is (are they a braggart?), and what their value system is. Craig says he has made a lot of mistakes over the years hiring PMs and, as a result, has learned to be more systematic about it. You have to have a practical part of the interview where you have the candidate go to the whiteboard, break down a problem, or tell the interviewer about work they’ve done in the past. A particularly good practical problem is to have them talk about a product they use everyday and describe both what’s great about it and what needs to be improved about it. They talked about the Who method (https://www.amazon.com/gp/product/0345504194). For example, if the candidate tells you they were responsible for a half-a-million user product, the Who method lets you find out how much of that was their responsibility versus something they are just taking credit for. He talked about an aspect of the Who method called the threat of reference check. You ask the candidate, say, who their previous manager was, and then say, “When I call your previous manager, what are they going to say about you?”  Apple Podcasts link: https://podcasts.apple.com/ca/podcast/what-really-matters-when-hiring-a-pm/id1445050691?i=1000461459804 Website link: https://www.spreaker.com/user/casted/what-really-matters-when-hiring-a-pm BRYAN LILES ON HANSELMINUTES The Hanselminutes podcast featured Bryan Liles with host Scott Hanselman. Scott started out by asking Bryan what he means by “a complete engineer”. Bryan says he has rules for everything and rule #1 is that there is a competition out there but you are only competing with yourself. You can watch what other people do and you can emulate them, but don’t compare yourself to others. Regarding being a complete developer, he says you have two aspects of being a developer: 1) writing software for money and 2) providing an impact to the world. That impact may be helping other developers level up, providing a role model, or simply doing no harm. Growing up, Bryan’s dream was simply to have a better life for himself than his parents had. Now, he wants to show people that his life was not a fluke but is a result of preparing himself for opportunities. The world Bryan wants to live in is one in which we’re trying our best and we’re also looking out for the people that come after us. Bryan talked about his recent project Octant that is a console for showing what’s going on in your Kubernetes cluster. He says that often we start to make a product and we start listing a bunch of features we want it to have. He says this is like that friend that talks too much and tells boring stories that go on for too long. We all prefer the friend who tells simple stories and it is the same with software products: you need to start off simply and solve one problem at a time. The interview ended with Bryan’s three pieces of advice that he gives to all black males that he meets. First, he says to ignore the advice that says you have to be the dumbest person in the room. That works when you have privilege and you have a safety net. Instead, be the smartest person in the room, but don’t tell anyone. Second, opportunity is rare, so when it comes, be ready. His third piece of advice is to get used to, but not comfortable, with failure. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/being-a-complete-engineer-and-bryan-liles-rules-to-life/id117488860?i=1000460922091 Website link: https://hanselminutes.simplecast.com/episodes/being-a-complete-engineer-and-bryan-liles-rules-to-life-BiK2k99r LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website: 

28. A Cumulative Pile of Successes

Scott Belsky on Product Love, Beth Long on Maintainable, Mark Schell on Agile Uprising, Daniel Mintz on Product Love, and Kelsey Hightower on On Call Nightmares. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. And, if you haven’t done it already, don’t forget to hit the subscribe button, and if you like the show, please tell a friend or co-worker who might be interested. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting December 23, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. SCOTT BELSKY ON PRODUCT LOVE The Product Love podcast featured Scott Belsky with host Eric Boduch. Scott founded Behance in 2005, which he calls a “LinkedIn for the creative world.” They were acquired by Adobe in 2012. He is now Chief Product Officer there. He wrote two books: Making Ideas Happen and The Messy Middle. Scott founded Behance because his designer and artist friends felt a sense of frustration at how their careers were at the mercy of circumstance. He pitched them on the idea of a social network for creatives and they hated it. So he asked what problem they wanted to solve. Many said that their portfolio sites were always out of date and hard for clients to find, they never got attribution for their work, their potential clients found it hard to look them up if they saw their work for another client, and there was a lack of software that catered to the business aspects of being a professional designer or artist. This was a community of customers who didn’t realize that what they needed is what they didn’t want. Behance needed to pull their customers through their first mile of doubt. When they put out a beta, they asked customers to put their portfolio on it and the customers said no because they had a portfolio site already. So they asked their customers if they could interview and write a blog post about them and they said yes. So Behance made a blog of leading designers and asked them for portfolio images. Customers agreed and let them put the images in Behance. They found a backdoor way to get some of the most beautiful portfolios into Behance upon launch. People who now looked up their favorite designers found them on Behance and thought, “I should be on there.” This taught Scott the lesson that, while the science of business is scaling, the art of business is the things that don’t scale. The best businesses find the non-scalable things to prime the pump for their products. Scott says businesses need to nail it before they scale it. In other words, they should aim for high product-market fit with a hundred or so users. Eric asked where the average product leader struggles in making the transition from being hands-on to more strategic. Scott says a common struggle is not empowering design sufficiently. You want to find the right design leaders and empower them sufficiently at the right point in the process. Great product leaders don’t say much at all. They are conduits that are working behind the scenes to get people aligned and to get designers and engineers working together. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/scott-belsky-joins-product-love-to-talk-about-exploring/id1343610309?i=1000458667222 Website link: https://www.spreaker.com/user/casted/belsky-edited-audio-mp3 BETH LONG ON MAINTAINABLE The Maintainable podcast featured Beth Long with host Robby Russell. Beth is a software engineer at New Relic. She says that maintainable code is code that prioritizes intelligibility and is oriented to the way humans interact with it. It is simple, clear, and emphasizes readability over conciseness. The infrastructure the code deploys to and the deployment mechanisms themselves should also prioritize intelligibility and clarity to be considered maintainable. Intelligible code is code that tends to make sense even to those that aren’t intimately familiar with it. This might be someone who hasn’t worked extensively in the codebase or someone who worked in it two months ago and has just now come back to it. Robby asked about technical debt. Working at New Relic, Beth has had opportunities to talk with Ward Cunningham, the originator of the term. When Ward coined the term, he was working on a financial system and he described technical debt, like financial debt, as something you deliberately take on. You sacrifice some maintainability in the short term and pay it back over time. Robby asked how developers can bring up maintainability concerns with stakeholders. Stakeholders are often focused on velocity, so they says things like, “Can we have the person who is on call due the sustainability engineering work?” This doesn’t work. What works is giving the team focused, protected time. Developers need to step out of their own experience of the world enough to understand the pain and pressure that their stakeholders live under and make a compelling case to them. Beth has seen it work. She has seen New Relic customers make slide decks to present to stakeholders about the value of doing the work to add observability to their systems and getting executive buy-in as a result. Robby asked about second system syndrome. She says it comes from the book The Mythical Man-Month and refers to the tendency to replace small, elegant systems that work well with bloated, over-engineered systems. You have a system that works well enough but people want more features and there is a temptation to replace the old system with something new. The old system is full of known flaws and, in the potential new system, the flaws are not yet known and you can pretend they are not there. This is why she recommends against rewrites. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/beth-long-maintainable-code-prioritizes-how-humans/id1459893010?i=1000458429284 Website link: https://maintainable.fm/episodes/beth-long-maintainable-code-prioritizes-how-humans-interact-with-it-XHdDZOQF MARK SCHELL ON AGILE UPRISING The Agile Uprising podcast featured Mark Schell with host Andy Cleff. Mark started out working at an organization that had reached CMMI (that is, Capability Maturity Model Integration) level 5 (that is, the highest level: optimizing) but he struggled to see the worth of it. Eventually, a friend of his introduced him to Extreme Programming or XP and this got him energized about Agile. They got into a discussion about a talk Mark attended at the Philly XP conference that was given by Ryan Lockard. Ryan described the benefits of cleaning up old code. Mark says that the less you clean up after yourself, the more stuff you have to step around. This also means being careful not to add too much complexity, as this makes things more complicated for the user and for the developers. Andy asked Mark where he starts in such a situation where you inherit a system where there hasn’t been a great deal of taking out the trash. Mark referenced Foot and Yoder’s paper on the big ball of mud. He says you start with the smallest pieces you can find. Don’t be afraid to delete things; that’s what we have code repositories for. If you are using a compiled language and you have tools like Resharper, make use of them. Mark talked about tools like OpenGrok for making code files more searchable.  He says there are going to be cases where you have to take a leap of faith; you have to delete something that you know you may need to revert if you discover a previously unknown use. If you never take that risk and you’re always afraid of that code, you’ll never get to a cleaner state. Andy asked about how things get this way. Mark says that most developers’ passion is often around the building of new things. Combined with schedule pressure, doing chores like code cleanup becomes a low priority. Mark says that, ideally, it should be baked into the red-green-refactor cycle. Andy asks how we can push back as craftspeople when the business says, “More, more, more.” Mark says you need to find a way to tie this retirement of complexity to revenue. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/clean-code-refactoring-and-deleting-w-mark-schell/id1163230424?i=1000459008564 Website link: http://agileuprising.libsyn.com/clean-code-refactoring-and-deleting-w-mark-schell DANIEL MINTZ ON PRODUCT LOVE The Product Love podcast featured Daniel Mintz with host Eric Boduch. The work Daniel did in politics informed everything he does everyday. It helped him understand how people interact with products, how to scale and grow, how data can inform product decisions, how data can mislead product decisions, and how tools get built. When you’re running a giant volunteer political organization, that’s the lowest-attachment user you can imagine. Your product has to be good at grabbing users and getting them in the door or else it’s not going to work. Daniel says we often fall into the trap of being data-driven. He thinks of the episode of The Office where Michael Scott drives into the lake because the GPS tells him to turn right. There is a difference between being data-driven and data-informed and when data conflicts with your intuition, your qualitative research, and your experience, you should interrogate that. Eric asked how Daniel ended up at Looker. Daniel described his first experience with their sales team. After the salesperson struggled to describe what Looker was, he eventually asked Daniel to let him show off Looker by connecting to Daniel’s database and letting Daniel ask Looker any question about his own data. In ten minutes, the salesperson had shown him things about his data he had never seen before. Seeing Looker in this way, Daniel felt like he did when first encountered the power of SQL, but this time it was something that anybody could use. Just as any good product manager would try to get to the real problem when a customer comes to them with a solution like, “I want to make this button blue,” when a customer asks a data analyst to show them sales by salesperson by region for the last six months, a good analyst will ask them why. They might say, “I want to see if there is a big difference in how salespeople ramp over different regions.” The analyst might then respond, “What if we narrow that down and only look at people recently hired?” Product managers need to do the same thing when thinking about how they use data. For example, if you are trying to understand where people get stuck in the on-boarding path, then usage data may be useful. If you are trying to understand whether people’s impression of the product has changed over time, net promoter score might be what you need. Start with the question instead of saying, “This is the data I have available and here is what I can make of it.” Daniel says that good operational metrics are ones that, upon looking at them, you immediately know what you should do in response to them. Alternatively, dashboards of vanity metrics can be disempowering for people: if you are a product manager who isn’t working on a revenue-creating part of the product yet, a dashboard tracking a vanity metric like revenue is not something you can do anything about. Daniel gave an example of vanity and operational metrics for a company like Uber or Lyft. A vanity metric might be rides taken or cities served. It is the kind of metric that might be valuable to investors, not for the people that work there. An operational metric might be percentage of rides cancelled and that is only operational if you dig a level deeper to find out why they were cancelled. Eric asked Daniel for his take on net promoter score. From the consumer perspective, Daniel says, NPS is a great innovation because it is so simple and easy to administer that your response rate is going to be higher than any other survey question. Being a single question survey makes it easy to ask in-product rather than in a survey email and thereby increase response rate even further. He says that tracking NPS over time makes it even more useful. When it is used to just ask if something is good or bad, however, it just becomes another vanity metric. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/daniel-mintz-joins-product-love-to-talk-about-data/id1343610309?i=1000459282754 Website link: https://www.spreaker.com/user/casted/daniel-mintz-joins-product-love-to-talk- KELSEY HIGHTOWER ON ON CALL NIGHTMARES The On Call Nightmares podcast featured Kelsey Hightower with host Jay Gordon. Kelsey talked about what he calls “learning in public”, in which you share things as you learn them. He says that when you learn in public, you tend to not skip over the interesting bits from zero to getting started. A lot of times, we’re afraid to share that because we want to be seen as experts. Kelsey talked about his truest introduction to on call. He described how his CTO made it clear just how important their work was to customers. Hearing about the consequences for customers of system downtime put things in perspective for Kelsey. Kelsey says that if you fail to explain it, on call can feel like you’re overtaxing your employees. It is less like on call and more like glorified overtime. Another lesson Kelsey learned about on call at that company happened when he took on all of the on call work for two months. His goal was to find the patterns and make it go away. Over the two months, he made sure the issues were documented and the documentation was made consistent. The rest of the team saw Kelsey as “taking one for the team”. The team was able to do work in their areas of expertise to improve the on call experience. The number of incidents dropped from 1-2 per week every week to having weeks without any incidents. They had been in a cycle in which on call pain was spread out enough that nobody did anything about it. Stepping up and showing leadership by doing changed things. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/episode-45-kelsey-hightower-google/id1447430839?i=1000460193573 Website link: https://www.podomatic.com/podcasts/oncallnightmares/episodes/2019-12-19T08_16_15-08_00 LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website: 

27. Sitting In A Room Full Of Mousetraps

Emily Bache on Maintainable, Rod Collins on With Great People, Dominica DeGrandis on Troubleshooting Agile, Ariel Caplan on Greater Than Code, and Dave Aronson on Maintainable. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. And, if you haven’t done it already, don’t forget to hit the subscribe button, and if you like the show, please tell a friend or co-worker who might be interested. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting December 9, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. EMILY BACHE ON MAINTAINABLE The Maintainable podcast featured Emily Bache with host Robby Russell. Robby started out by asking Emily about common traits of maintainable software. She says that maintainable software has a design, is well tested, has names that relate to the domain, has had thought given to having levels of abstraction, and is the kind of code you would like to read. Robby asked Emily what developers get wrong when talking about technical debt. She says that some developers label as technical debt any code they don’t like or didn’t write themselves. Other developers don’t even admit that there is any such thing. This is problematic because there really is code that is bad, code that most developers would have trouble understanding. She says that your decisions regarding technical debt have to be driven by the needs of the users of the software. Code you don’t need to change doesn’t need to be improved.  They talked about examples of bad code and Emily mentioned Terry Hughes’ Gilded Rose refactoring kata as an example of horrible code that she uses to educate others. She herself invented a tennis refactoring kata and a Yahtzee refactoring kata that I got to try out myself in her workshop at the Agile Testing Days conference in November.  Robby asked whether these exercises are meant to be done alone or with others. Emily says it is always more fun to code with other people and you learn more. She says coding is a social activity. Very little code today is written by individuals. It is written by teams. Doing exercises like the tennis kata in a group lets you have discussions about design and code smells without it being personal and then you will have practiced such discussions for when it really matters in your production code. Robby and Emily talked about the individual genius developer and Emily says that while there are definitely still instances of software built by geniuses working alone, the best software today is often built by teams from the start. This led her to talk about mob programming, which she favors because it forces you to explain your ideas in words. You have to become good at communicating, in words, about software design and coding constructs. She says she didn’t have that skill when she started mob programming. Robby stated that he wasn’t familiar with mob programming. Emily explained that, as in pair programming, you have two people working together at the same machine, but in mob programming you have more than two people and, because of the increased number of people, you need an increase in structure. One piece of structure is that the driver, who is typing at the keyboard, cannot follow their own ideas about what to write. Instead, the navigator, a designated person in the mob, communicates what code should be written. The rest of the mob supports the navigator and the driver and you regularly rotate the roles. For the mob to work, the navigator has to get good at communicating in words, not just with the driver, but also with the rest of the mob so that they can assist and can take over when the navigator rotates to the driver role and the driver returns to the mob. They discussed how often to rotate and Emily says it varies from team to team, but her preference is to rotate every four or five minutes. As an aside, at the Agile Testing Days conference this past November, I got to experience a mob programming workshop led by Emily in which I got to be a member of the mob and rotate through the roles of navigator and driver and I highly recommend seeking out opportunities to experience this style of work if you get the chance. They talked about her work as a technical agile coach and how she splits her time among multiple teams at a given engagement, working with each team for two hours every day. These teams would work as a mob on their production code and she would sit in the mob and either take the navigator role, coach the navigator and driver, or simply observe. This allows her to help teams to learn practices like writing tests, doing refactoring, improving their design, breaking their work into small pieces, committing often, writing good messages, and all the stuff you need to do to be agile. They also do one hour coding dojos.  Being a guest in other teams’ codebases, she says, you have to be respectful because even when you see that the code is bad, you don’t know why it got that way. The first thing she does when she joins a new team is ask to see their code, their unit tests, and the code they find most difficult to work with. Robby asked Emily to reflect on the various projects she has participated in and describe common issues that affect most teams’ code and processes. Emily says she sees a lot teams struggling to meet expectations and not taking enough time to really communicate with each other and improve. Most software developers really want to do a good job and are under a lot of deadline pressure that works against doing a good job. Software development is a marathon and you have to make sure you are learning and your processes are improving as you go. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/emily-bache-its-always-more-fun-to-code-with-others/id1459893010?i=1000457798211 Website link: https://maintainable.fm/episodes/emily-bache-its-always-more-fun-to-code-with-others-PtzH4tY7 ROD COLLINS ON WITH GREAT PEOPLE The With Great People podcast featured Rod Collins with host Richard Kasperowski. Rod says that, in the 20th century, if you wanted to scope out the future, you looked backwards. You understood your business, product, and market metrics and forecasted from that because, in those days, the past was a proxy for the future. Today, the world is rapidly changing and planning can become a strategic trap. Planning is no longer the foundation of strategy. The basis of strategy today is discovery. Richard asked why Rod calls himself an information curator and Rod said that no one person can see into the future, but if you have processes that leverage the collective intelligence across experts, non-experts, and what Rod calls unusual suspects, it gets businesses to ask the right questions and find the unknown unknowns. Rod says that most leadership teams, especially senior leadership teams, don’t spend sufficient time on business strategy. When your challenge in a business environment is discovering the unknown unknowns, you cannot afford to meet only once a year to think about business strategy. Rod had his own leadership teams meet about strategy for a whole day every two weeks. Rod asks, “How much of a CEO’s time is spent bridging gaps between the various units because they are not getting along?” Meeting for a day every two weeks pays itself back many times because senior leaders are able to handle issues among themselves without involving the CEO. There is esprit de corps, a history that gets created among the leadership team, and the collaborative way of working together becomes the natural way of conducting business. Rod says that the leadership training of the last five decades is focused on the individual. Most train strategic leaders to hold their hierarchical authoritative power in such a way that it is beneficial, but treat leadership as fundamentally residing within the individual. Rod thinks that part of the transformation of 21st century business is the unit of leadership changing from the individual to the team. Leadership training, as a consequence, needs to happen in the context of full teams. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/rod-collins-innovation-discovery-how-to-do-it-right/id1262784541?i=1000457926652 Website link: https://soundcloud.com/withgreatpeople/episode28 DOMINICA DEGRANDIS ON TROUBLESHOOTING AGILE The Troubleshooting Agile podcast featured Dominica DeGrandis with hosts Douglas Squirrel and Jeffrey Fredrick. Squirrel and Jeffrey asked Dominica what she means by time theft. She says that time theft is the interruptions and context switching that often comes from conflicting priorities, unknown dependencies, and unplanned work. For example, you may go to work and have back-to-back meetings and cannot get your real work done until you put the kids to bed or on Sunday afternoon. As Squirrel says, “You can’t do your work at work.” It prevents you from getting into the flow state described by Csikszentmihalyi. If you ask people what prevents them from getting their work done, they often say it is because they are overloaded. She told the story of working with a team of 41 engineers working on 33 projects at the same time, building out six data centers in six countries in six months. They were carrying the duty pager and were interrupted so much that they put two project managers in front of them to protect them from the inbound demand, but their mutual dependencies within the organization interrupted them too. The project managers put a big Kanban board up and, every time an engineer was interrupted, they put a post-it on the board. In a week, they had 92 interruptions and the majority were due to product managers wanting to know the status of their project. Every day, people were walking past this board and this is how you get visibility on your problem. Making the work visible provoked the necessary conversations to inspire change. The change that occurred was taking one of each specialist, moving them into a different building and asking them their biggest pain points. Because work was being started without finishing previous work, they had a lot of projects at 90%. This isolated team was able to finish 10% of the projects in four weeks. As a build engineer, Dominica used to rant about teams not having enough automated testing but it got her nowhere, but once she started capturing the data, taking a scientific and systems-thinking approach, and presenting her data-backed case to leadership, the result blew her away. She got budget, she got headcount, and she got empathy. Jeffrey said that people often find themselves on an us/them divide and this is not what Dominica found once she could present the data to leadership. The problem is that people don’t have the shared information to work from and, in making the work visible, she was generating information that nobody had before. Squirrel says he worries that people will use the metrics to beat people up. Dominica says this is why we want to focus on business outcomes and not activity metrics. A lot of proxy metrics are captured because it comes with the tool, but these metrics don’t tell you how much business value a team is providing for the company. Dominica likes to use a balanced set of flow metrics such as cycle time and flow efficiency. Squirrel asked why the business leaders would be interested in such metrics. Dominica gave the example of business leadership thinking they need to hire more developers because the teams they have are not delivering fast enough. If you are measuring flow efficiency, development time is usually a low percentage of flow time, so adding more developers would not help cycle time at all. You need to know where your bottleneck is and measuring flow efficiency helps you make these kinds of business decisions. Jeffrey asked where someone should start in making work visible and reducing time theft. Dominica starts with the question of what prevents a team from getting work done. Decide on a few small experiments of four to six weeks to address these problems, find that one person on the business side who can be your ally and maybe sponsor these experiments, and address their business pain. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/making-work-visible-with-dominica-degrandis/id1327456890?i=1000458010204 Website link: https://soundcloud.com/troubleshootingagile/making-work-visible-with-dominica-degrandis ARIEL CAPLAN ON GREATER THAN CODE The Greater Than Code podcast featured Ariel Caplan with hosts Jamey Hampton, John K Sawers, and Jacob Stoebel. Ariel says his superpower is extreme irritability. He had to learn when to address the things that irritated him and when to let them go. He started a daily writing practice of noting what irritated him that day and also what he liked. He connected his superpower to accessibility. He says you can develop in yourself a sensitivity to examples of poor accessibility like the use of red and green as the only means to present certain information in a user interface. Ariel has been working on developing the corporate values for the company he works for. Ariel says that company values are often viewed with skepticism and he gave an example: a company had the values of communication, respect, integrity, and excellence, according to their annual report in 2000. The name of the company was Enron. John talked about helping his team of about 25 people come up with their team values to use as an interviewing rubric. He liked asking about values in interview questions because there is no wrong answer and, by asking the candidate what a good demonstration of a particular value is, it allows you to evaluate how they think that the value would play out instead of having them guess the magic answer to a tricky interview question. Jamey added that it is important to revisit your list of core values every so often. His company, Artemis, grew from ten to thirty employees and decided to revisit their values. Some of the values did not change fundamentally, but changed meaningfully in the way they were expressed. Ariel asked about when is it time to delete a value from your list and Jamey described how the original list of Artemis’ “values” included company goals like “we help indoor growers succeed”. These got removed because they weren’t really values, but they remain corporate goals.  Ariel says he pays attention to who is impacted and has to change their behavior because of a value. He gave as an example the values of grit, determination, and hard work and how this gets abused to put pressure on the front-line workers. Another example is a value like: “we challenge people; we ask questions; etc.” A better value might be “we create an environment where it is safe to ask questions, safe to challenge ideas, and safe to take risks.” The first example puts the pressure on the front-line workers to behave a certain way, while the second puts the pressure on management to create a better environment. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/158-exploring-company-values-with-ariel-caplan/id1163023878?i=1000458078372 Website link: https://www.greaterthancode.com/exploring-company-values DAVE ARONSON ON MAINTAINABLE The Maintainable podcast featured Dave Aronson with host Robby Russell. Robby asked Dave what his definition of software quality is. Dave addresses quality for the vast majority of software as a list of six aspects that form the acronym ACRUMEN: appropriate, correct, robust, usable, maintainable, and efficient. The N means nothing. Appropriate means doing what the stakeholders need it to do, where the term stakeholder refers to users, customers, operations personnel, and others. Where Appropriate refers to doing the right job, Correct means doing the job right. He uses the analogy of being asked to write a checkers program and, in response, writing the world’s greatest chess program. It can be as correct, robust, usable, maintainable, and efficient as anyone could ever possibly want, but if you wanted a checkers program, you are not going to be happy with it. In ACRUMEN terms, the chess program is not appropriate. Alternatively, a perfectly reasonable checkers program that may even have a few bugs is probably going to suite your needs better than a fantastic chess program. For Robust, he is mostly referring to security. He uses the CIA triad (confidentiality, integrity, and availability). The program should not reveal information, alter information, or become unavailable when it is not supposed to. Regarding Usable, Dave says it is not just the end user that needs to find the software usable; things like an API should be usable as well. In ACRUMEN, Maintainable means easy to change with low fear of error and low chance of error even for a novice programmer new to the project. Fortunately, the vast majority of software engineering advice is aimed squarely at this. For the last letter in the acronym, E for Efficient, Dave says there are more resources to make efficient use of than CPU cycles. There is, of course, disk space and network bandwidth, but also the user’s patience and brainpower, and the company’s money. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/dave-aronson-putting-the-m-in-acrumen/id1459893010?i=1000455264616 Website link: https://maintainable.fm/episodes/dave-aronson-putting-the-m-in-acrumen-n_6lX9fc LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website: 

26. Patience and Brainpower

Bret Weinstein on The Jim Rutt Show, Barry O’Reilly on The Product Experience, Dave Farley on Engineering Culture at InfoQ, Jim Mattis on Coaching For Leaders, and Ben Mosior on Agile Uprising. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. And, if you haven’t done it already, don’t forget to hit the subscribe button, and if you like the show, please tell a friend or co-worker who might be interested. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting November 25, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. BRET WEINSTEIN ON THE JIM RUTT SHOW The Jim Rutt Show featured Bret Weinstein with host Jim Rutt. Brett talked about the sustainability crisis (not necessarily related to climate) in which we are using resources and creating waste in a way that, mathematically, cannot continue indefinitely. Jim added that half of the mass of large animals on earth are now humans and domestic animals, most of which are cattle. He says this tells us that we are at or beyond the ability of our ecosystem to allow us to carry on the way we have been. Jim believes that the engine that is driving us toward eco-cide is the pursuit of money-on-money return powered by psychologically-astute advertising that got underway in the 1930s and is now reaching near-perfection with the highly-instrumented attention-hijacking mechanisms of social media. He compared it to the paperclip maximizer idea in artificial general intelligence. Brett says that the way you can tell that AI algorithms are out-of-control is to look at the behavior of people in the best position to understand the power of these algorithms. Defectors from Facebook or elsewhere describe the extreme measures they go through to retain control of the own lives in the face of algorithms they had a hand in writing. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/ep24-bret-weinstein-on-evolving-culture/id1470622572?i=1000456522456 Website link: https://jimruttshow.blubrry.net/bret-weinstein/ BARRY O’REILLY ON THE PRODUCT EXPERIENCE The Product Experience podcast featured Barry O’Reilly with hosts Lily Smith and Randy Silver. Lily asked Barry where his notion of “unlearning” came from. Barry said that while writing the book “Lean Enterprise,” he had an “aha” moment in which he realized that, while teaching people new things was tough, what was even harder was getting them to unlearn their existing behavior, especially if it made them successful in the past. Randy asked Barry what signs indicate when you are unlearning well as opposed to simply getting lucky. Barry says that a lot of people think knowing when to adapt is serendipitous or intuitive to other people, but there is a system you can learn that can make the process intentional and deliberate. People get stuck. They stick to the sets of behaviors that they know and understand or that feel comfortable to them. When those behaviors aren’t driving the results or outcomes that they are aiming for, often people’s natural reaction is to point at other people as the cause of the failure. If you’re serious about making progress, you have to own the results. You have to ask yourself what you can do differently to change the outcomes that you are getting. You need to get comfortable with being uncomfortable. You need to think big about the aspiration or outcome you are trying to achieve, but you start small as you start to relearn. Starting small creates safety. You get a fast feedback loop, learn quickly, and you feel successful as you try new behaviors. Barry asked Lily and Randy where most people in product roles spend most of their time and they said, “meetings.” They estimated that the effectiveness rate for such meetings was about 50%. As a product manager, Barry says, he would be trying to make that number better, but most people blindly walk into meetings and never make any changes to how meetings are run. Barry gets leadership teams to describe a better outcome and one small thing they can do to make things better. For meetings, one team came up with a simple step: five minutes before the meeting would end, the leader would stop it and ask the team how effective they thought the meeting was and what outcomes they were taking away from the meeting. When a leader starts to demonstrate a new behavior in meetings like pausing five minutes before the end and asking people how effective the meeting was, other people start to take these behaviors back to their teams. Role modeling these new behaviors in your organization can have a systemic impact because people see you trying out these new behaviors and that inspires them to be serious about making their own improvements. Berry went on to say that the belief that you cannot influence these kinds of changes needs to be unlearned. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/learning-to-unlearn-barry-oreilly-on-product-experience/id1447100407?i=1000456659421 Website link: https://www.mindtheproduct.com/learning-to-unlearn-barry-oreilly-on-the-product-experience/ DAVE FARLEY ON ENGINEERING CULTURE BY AT INFOQ The Engineering Culture at InfoQ podcast featured Dave Farley with host Shane Hastie. Shane asked about Dave’s talk about taking back software engineering. Dave says that software engineering is a term that is falling out of favor. People started to think of software development as a craft and of themselves as craftspeople. Working on high performance trading systems, he adopted practices that he considers a genuine engineering discipline and this made a dramatic difference in performance, effectiveness, quality, and speed of development. He says we’ve been too prescriptive in trying to define what software engineering means. An engineering discipline for software need to be general enough to still be true in a hundred years. He says we suffer in our industry from not having very many measuring sticks and we choose technologies, processes, and approaches based on who is the most persuasive person or guru. His talk was about five principles that are likely to be durable, broadly applicable, and broadly acceptable to people. First, we’ve learned that planned approaches don’t work. Working iteratively through a process of discovery is foundational. Second, we’ve discovered from continuous integration and delivery that fast, efficient, high quality feedback has a dramatic impact on our ability to move forward with confidence and quality. Third is being experimental and adopting the scientific method. Fourth is working incrementally, building software from a modular point of view, and growing complex systems from simple systems. Fifth is being empirical and testing what we build against reality, learning from that, and adapting. Shane asked whether these ideas are just common sense. Dave agreed that they are common sense but they are uncommonly practiced. He says that the majority of his own career in software development was built around guesswork. They would guess about what users wanted, guess about whether the software was going to be fast enough, resilient enough, and scalable enough, and guess about whether there were going to be bugs in it. They would guess about these things instead of testing these things as an experiment. He cited Extreme Programming and Continuous Delivery as genuine engineering disciplines. Shane pointed out that this requires a significant level of discipline that is rare in our industry. Dave agreed and gave the example of the team he worked with to build the trading system mentioned earlier. They were not only the best team he worked with, but also the most productive, solving problems in genuinely original ways, and they did it all by consciously adopting these techniques. It wasn’t because they were smarter than other teams, but because of their disciplined, agile approach. Shane asked how we can get a more experimental mindset in software development. Dave says we first need to get more data-driven and figure out useful measures to apply. For example, in high-performance software, we want to know things like how fast, what throughput, what latency, and what percentage of messages need to get through at a particular rate. The difference between an engineer and anyone else is that engineers spend a lot of time thinking about how things can go wrong. He gave the example of how he does Test-Driven Development: before he runs a test he has just written, he will say what error message he expects to get. This is a genuine experiment: he forms a hypothesis and he’s precise about the nature of the failure he is expecting. Shane asked Dave for his opinion about pair-programming. Dave considers pairing one of the most powerful tools an organization has to start becoming a learning organization and he considers pairing a foundational idea for establishing engineering rigor. Shane asked how we can convince the individual hero developer that it is a good idea to work with somebody else. Dave encourages his clients to experiment with pair-programming and you cannot do that for an hour or two. He encourages a minimum of a sprint or two and he combines it with rotating people who are in the pairs (also known as promiscuous pair-programming). In his experience, when you ask people who have never paired before it to pair, the majority do not want to. After they have done it for a reasonable period of time, the majority then want to keep doing it. Often, only a small number of people hate it and will never like it and companies need to make a tough decision about what to do about that. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/dave-farley-on-taking-back-software-engineering/id1161431874?i=1000456425449 Website link: https://soundcloud.com/infoq-engineering-culture/interview-dave-farley JIM MATTIS ON COACHING FOR LEADERS The Coaching For Leaders podcast featured Jim Mattis with host Dave Stachowiak. Dave asked about 1990 when Mattis was in the Saudi Arabian desert, preparing for an invasion that would become the first Gulf War. He employed a technique called the focused telescope. Mattis said that he faced the challenge of information flow. Leaders typically have sufficient information somewhere in their organization, but the pipes of information flow need to be open such that this information is available in time to make decisions. Mattis would take young, capable officers who would go out to units that were executing the mission and those officers would clarify and confirm to the attacking commanders the mission and report back to Mattis. This opened up the information flow in real-time to make better decisions. Dave asked where Mattis got the idea. Mattis said that every time you are promoted in the military you are given a new reading list and he got this idea from the readings. Dave then asked about 2001, when Mattis was in command of the marines in Afghanistan searching for Osama Bin Laden. Mattis said that he had shifted from being under a naval commander to an army commander and he did not spend the time getting to know his new commander. When intelligence came in that Osama Bin Laden was in the Tora Bora region, he knew they needed to stop him from escaping to Pakistan. Mattis had studied the Geronimo campaign of the U.S. cavalry in the late 1800s and saw how they set up communication stations to track activity on the border. He wanted to do the same to block escape routes in Tora Bora. He forgot the inform his boss and his boss did not understand the urgency of the situation or the plans to block Bin Laden’s escape. He says you have to ask yourself three questions everyday: “What do I know?”, “Who needs to know?” and “Have I told them?” Dave then asked about 2003 when Mattis was commanding a division to remove Saddam Hussein from power. One of his colonels was failing to move with haste. Mattis says that the officer, who he admires to this day, had a tempo that was less than needed at the time and Mattis determined that he was asking this officer to do something that was beyond his moral ability to do. Mattis said that war is a harsh auditor of your recruiting, your equipment, your training, and your leadership. He needed everyone in the fight and he knew he had to delegate the decision-making to the lowest competent level but it had to be consistent with his intent which was to move fast enough to confront the enemy with cascading dilemmas to prevent them from digging back in. So he removed that officer from command. Dave then jumped ahead one year to 2004 in Fallujah when four allied contractors were killed and Mattis had a plan to recover the bodies and track down those responsible. The President of the United States made the decision to attack the city instead. Dave asked Mattis what kept him from resigning in this situation. Mattis reminded us that the military has civilian control. When the civilian leadership says to do something, you keep faith with the constitution and get on with it. Mattis had read enough history to know the challenges associated with attacking a city with 300,000 innocent civilians. Mattis’s idea was to work with the other tribes in town that were repulsed by this terrorist activity and to use the spies they had in the city to hunt down the perpetrators. Given the known brutality of urban fighting, this was a better plan, but they were ordered to attack instead. Mattis said he could have resigned but the 19-year-old lance corporals in his army of 23,000 couldn’t quit and he wasn’t going to leave them on the battlefield. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/440-leadership-in-the-midst-of-chaos-with-jim-mattis/id458827716?i=1000456425891 Website link: https://coachingforleaders.com/podcast/leadership-chaos-jim-mattis/ BEN MOSIOR ON AGILE UPRISING The Agile Uprising podcast featured Ben Mosior with host Jay Hrcsko. Ben started out as a sysadmin and started taking more interest in the people side of technology. He now runs a company called Hired Thought where he makes systems more purposeful. Ben came across Wardley Mapping when people he was following in the DevOps community started to reference it. At the time, he was dealing with a difficult decision about whether to spend money that was tied to buying server hardware and thereby shifting attention away from the cloud that had been his focus. He learned that Wardley Mapping was a way to make sense of these kinds of situations and make a good call. He ultimately decided to decline to money and he now had an explicit strategy where before he had none. Wardley Mapping highlighted how much he originally didn’t know what he was doing. Ben describes a Wardley map as being two things: a visual way to represent a system oriented around users and a way to articulate how parts of that system are changing. It is a directed acyclic graph where position has meaning. The x-axis represents evolution and describes how the components of a business, such as activities, practices, data, and knowledge, change over time. They start in the uncharted space where nobody has seen it before, nobody understands it, and it fails much of the time. On the opposite end of the spectrum, there is the industrialized space where everything is known, is ordered, is boring, and failure is surprising. Having a way to express where a business component is between those two extremes informs how to treat that business component. They talked about the y-axis and how it represents the degree to which the business component is visible to the user. Ben says the y-axis is useful for thinking about what parts of the system the user cares most and least about. Mapping is intended to be an extremely collaborative activity. The map helps us share a common model for how we think about a space. Ben referenced George Box’s quote about all models being wrong and the scientist needing to be alert to what is importantly wrong about the model while ignoring those aspects whose approximate nature, or wrongness, makes the model no less useful. A map helps highlight when the model of your system is wrong in a fundamental way. When people look at a map and talk about it, you start to work towards consensus on understanding the system and start running into label conflicts. Producing the map artifact enables us to challenge it, talk to each other, and be transparent about what we think it is. The artifact itself is just one step in a five step process called the strategy cycle.  The five factors in the strategy cycle are purpose, landscape, climate, doctrine, and leadership. Purpose is the game we’re playing. It is why you come to work everyday. The landscape is the map. It represents the competitive landscape. Climate is the rules of the game, the external forces acting on that landscape that we don’t have control over. Doctrine is how we train ourselves, the principles that we choose to apply universally, such as always focusing on user needs. Last is leadership, the decision-making part that integrates all the rest. Ben says that we often jump straight from purpose to leadership and the process of sitting with the context of the other steps helps us make better decisions. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/wardley-mapping-with-ben-mosior-hired-thought/id1163230424?i=1000456388231 Website link: http://agileuprising.libsyn.com/wardley-mapping-with-ben-mosior-hired-thought LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website: 

25. We Were Expecting Robots

Brandi Olson on Agile Uprising, Judy Rees on Engineering Culture by InfoQ, J. J. Sutherland on Agile FM, Angie Jones on Developing Up, and Eric Ries on Unlearn. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. And, if you haven’t done it already, don’t forget to hit the subscribe button, and if you like the show, please tell a friend or co-worker who might be interested. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting November 11, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. BRANDI OLSON ON AGILE UPRISING The Agile Uprising podcast featured Brandi Olson with host Andy Cleff. Andy asked Brandi about what she means by multitasking. At the individual level, she says we use the word multitasking to describe what is happening when we are trying to do more than one thing at the same time. It is a misnomer though because our brains do not actually do more than one thing at the same time. Her bigger interest is in what happens when you have groups of people trying to multitask all day long. She calls this “organizational multitasking.” Say you have a team and they have a backlog. Organizational multitasking happens when somebody tells that team, “You need to get all ten of these things done this week and you need to start them all and I want to see the progress you are making each day.”  The opposite of that, organizational focus, happens when you say, “Work on this thing first before you work on the next thing.” At the team level, she says, there are a number of illusions about how to be more productive and effective. One illusion is that getting started on everything is the way to get it done and if everything is important we have to do it all at the same time. This breaks down because of the reality of how our brains work. Research shows that when a person has to juggle two projects throughout a day, they will spend 40% of their brain capacity and energy on context-switching. For three projects, energy devoted to context-switching jumps to 60%. Not only does this take time away from more productive work, but we don’t even notice the time we lost. A further cost of having entire teams of people running around at 40% brain capacity is that they are less likely to identify the real problems to work on and it feels like they cannot slow down to figure out what the real problems are. Andy asked whether the solution should come up at the individual level where someone starts to say, “No,” or is it something that starts at a leadership layer. Brandi says it is not a problem that can be solved individually. It needs to start with our leaders. Some of the problems that start to show up in these contexts are a failure to solve the right problems, a reduction in quality, an increase in employee turnover, a reduction in equity and diversity, and burnout. These problems typically get addressed by solving the symptoms. Andy asked what she does to help organizations separate the symptoms from the cause. Brandi says she does this by making the costs of multitasking visible. She told the story of a company that surveyed 600 companies and their HR leaders about the biggest threats to their workforce. Over 80% of those leaders said that employee turnover was the biggest threat. The company then surveyed the employees at those same companies and the employees overwhelming named having too much overtime and unrealistic work expectations. Going back to the same HR leaders, a fifth of them wouldn’t be doing anything about their turnover problem in the next year because the leaders had too many competing priorities. The overwhelming illusion that too many leaders buy into is that, while turnover and burnout are problems, we cannot do anything about it because there is too much important work to do. A further illusion is that we can capacity plan by cutting everybody’s time up; we can break up your time among projects and it will all add back up to 100%. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/the-cost-of-organizational-multi-tasking-with-brandi-olson/id1163230424?i=1000453339079 Website link: http://agileuprising.libsyn.com/the-cost-of-organizational-multi-tasking-with-brandi-olson JUDY REES ON ENGINEERING CULTURE BY INFOQ The Engineering Culture by InfoQ podcast featured Judy Rees with host Shane Hastie. Shane asked Judy if it is possible to have an effective remote meeting. She says absolutely and backed it up with an example of one of her own students telling her recently that participants in her remote meeting said that her remote meeting was better than an in-person meeting. Shane asked about the secret sauce of a good remote meeting. Judy says it is probably planning. She also said that when remote, each person brings part of the meeting room with them. She says people don’t realize how important the environment is to conversations. When you put people in a small space, they pay attention to small details and administrative kinds of things. For “blue sky thinking,” take people outside or to a room with a big view. In real world spaces, we already know where to find small rooms and rooms with big views, but online, we need to create equivalent spaces. You need not only to ensure that all participants turn up with a decent headset, cameras turned on, and light on their faces, but also to figure out the activities so that you have enough social time at the beginning, during, or end of the meeting. The beginning and end of the meeting are critical parts of a meeting. Online, we often miss out on these beginnings and endings and it affects the quality of the conversations. She also says that most people find it easier to engage and participate when the meeting is small. This connects with what Courtland Allen said on Software Engineering Daily about communities in the previous fortnight’s review. She says that if you can’t limit the space, you can limit presentation time to 5 to 7 minutes and get then people doing something. She also says to use breakout rooms and use liberating structures like 1-2-4-All (http://www.liberatingstructures.com/1-1-2-4-all/). Knowing Judy’s expertise in Clean Language, Shane asked how might Clean Language be used to enhance remote meetings. Judy says that teaching people on remote teams to ask more non-judgmental questions about what somebody means by what they say can have a profound effect. Because of the missing socialization in remote meetings mentioned earlier and the fact that remote teams often have more cultural differences than co-located teams, misunderstandings are more likely. Therefore, learning to ask questions to clarify in a way that doesn’t sound like an interrogation but helps both parties to get clearer more quickly becomes particularly valuable. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/judy-rees-on-effective-remote-meetings/id1161431874?i=1000450875620 Website link: https://soundcloud.com/infoq-engineering-culture/judy-rees-on-effective-remote-meetings J. J. SUTHERLAND ON AGILE FM The Agile FM podcast featured J. J. Sutherland with host Joe Krebs. J. J. Sutherland is the CEO of Scrum Inc. and the son of Jeff Sutherland, the co-creator of Scrum. J. J.’s new book is called “The Scrum Fieldbook.” Joe asked what made him pick such a title. J. J. said he wanted to write a book about all the places Scrum Inc. has been all over the world and the many different domains far beyond software. He also wanted to show how Scrum Inc. thinks about Scrum and what are the patterns and anti-patterns. He says that Scrum is a universal framework for accelerating human effort with applications in aerospace, banking, and even beer-making. No one does Scrum just to do Scrum. Scrum is designed to produce value, which requires knowing more than just the Scrum guide. It involves understanding why Scrum works the way it does, understanding complex adaptive systems theory, knowing that you need to empower your teams and ensuring your teams are the right size. Scrum is about running experiments and getting feedback from the customer and adapting to that feedback. He sees people spending six months to a year planning how to do Scrum before they even start. Instead, he says to just do something. That is where you’ll get the information to iterate towards the right thing. Joe expressed his appreciation as a Scrum coach for the chapter in the book on the difference between busy and done. When J. J. worked in radio, producers used to talk about how much effort they put into the radio programs and he would have to point out to them that no listener cares how hard you worked on it; they care about what comes out of the box. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/jj-sutherland-agile-fm/id1263932838?i=1000453430262 Website link: https://agile.fm/agilefm/jjsutherland ANGIE JONES ON DEVELOPING UP The Developing Up podcast featured Angie Jones with host Mike Miles. Mike asked Angie what she considers the ultimate goal of code review. Angie says the goal is to ensure everyone is aware of and content with what is being contributed to the code base; it is not a nitpicking session or an opportunity to bash your least favorite developer. Code review is also a good way to catch missed requirements. Angie encourages code reviewers to review the unit tests just as closely as the implementation.  Angie says the best code reviews are those you block out time for and make part of your routine. They aren’t something you skim while you drink a cup of coffee. When she reviews code, she always pulls up the requirement in the spec, doc, or ticket to see that the code under review fulfilled it. She looks for whether the implementation is efficient and at the right level of abstraction. She says that code reviewers have the opportunity to think at a broader level and see opportunities for code reuse. Angie sees code review as a form of mentoring without having an official mentorship relationship. Official forms of mentoring can feel like an obligation for the mentor because they have to set up meetings, learn the mentee’s career goals. Angie says that code review is a more subtle form of mentorship that is just as powerful. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/code-reviews/id1156687172?i=1000452808997 Website link: https://www.developingup.com/episodes/46-dflXzZ1V ERIC RIES ON UNLEARN The Unlearn podcast featured Eric Ries with host Barry O’Reilly. Eric described how he started his company IMVU and how, when wanted to do practices like split testing, he got pushback. People thought of it as a direct marketing technique, not a product development technique. He would argue, “Shouldn’t we use the scientific method to test our hypotheses?” He wanted customers involved from day one, he wanted to ship more frequently than was considered normal at the time. Looking back, he sees how extreme his ideas were at the time and is glad his cofounders didn’t fire him. As the company got more successful, his techniques got more controversial because the company now had more to lose. He said, “When you do things in an unconventional way, every problem the company has gets blamed on the unconventional method.” Barry pointed out that having to constantly explain the value of these unconventional methods likely made his thinking more resilient and could have been the seed for his next step. At one board meeting, he felt like he was going to be fired. He was tempted to apologize and compromise, but made the conscious choice to advocate for what he actually believed despite the potential negative consequences. He rationalized it like this: this is a small business and a small business is like a small town. In a small town, everybody knows everybody and he wanted people to know what he stood for. If people don’t like it this time and they fire him, okay. A day will come, he reasoned, when they are going to be in a situation where they need to get something done fast and will remember him because they know what he stands for. He radically misjudged the situation: the more he stood for those values and explained them, the more they resonated with people. If he hadn’t had the courage to put his career and reputation at risk, he never would have found out who the ideas resonated with. Eric says it wasn’t until later that he understood the importance of iteration happening within the context of a long term vision. Today, people understand Lean Startup as scientific hypotheses, a testing philosophy, small batches, and pivoting or changing strategy without changing vision. They know it is logically incoherent to have a pivot if you have no vision. Companies who were early disciples of Lean Startup, unfortunately, did not understand this and thought they could A/B test their way to success without any kind of vision. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/the-lean-startup-pivot-with-eric-ries/id1460270044?i=1000451993479 LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website: 

24. Fighting Burnout with Yoga Rooms

Esther Derby on Drunken PM, Justin Searls on Maintainable, Lena Ross and Dr. Jen Frahm on Agile Uprising, Dr. Nicole Forsgren on Screaming In The Cloud, and Courtland Allen on Software Engineering Daily. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. And, if you haven’t done it already, don’t forget to hit the subscribe button, and if you like the show, please tell a friend or co-worker who might be interested. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting October 28, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. ESTHER DERBY ON DRUNKEN PM The Drunken PM podcast featured Esther Derby with host Dave Prior. Dave asked about Esther’s new book, “7 Rules for Positive, Productive Change: Micro Shifts, Macro Results” (https://www.amazon.com/Rules-Positive-Productive-Change-Results/dp/1523085797). She says it is a guide for people who need to bring change to their organizations, whether or not they have “change management” in their title. Esther told the story about getting a call from a company that had sent everyone to three days of Agile training, but then mandated that the company-wide process would now be “Agile” and any changes would need to be approved by the software engineering process group. They solidified things when they knew, if not the least, very little. She thinks these kinds of stories keep happening because we are suffering from a hangover of mechanistic thinking where we view our organizations as machines and we can just install a change like swapping out a part. Esther says that often when people try to create change, they don’t think enough about what they want to retain. This reminded me of something Tom DeMarco wrote in his book Slack when talking about vision: “Successful change can only come in the context of a clear understanding of what may never change, what the organization stands for. This is what Peter Drucker calls the organization’s culture. Culture, as he uses the term, is that which cannot, will not, and must not change.” She also says that people forget that they are not working on a blank slate. Whatever they do, they are putting it on top of existing traditions, reward structures, policies, and patterns of relationship, and the new thing is going to interact with that in unpredictable ways. They talked about cognitive empathy and being able to explain something like the Agile Manifesto to somebody who hasn’t experienced traditional project management. Esther talked about a client in the Dominican Republic that mostly hires people straight out of school and is particularly adept at collaboration because they haven’t had years of being rewarded for individual accomplishments take away their natural desire to work collaboratively. She likened this to the traits that are often associated with Millennials and how these are actually good traits to have. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/7-rules-for-positive-productive-change-w-esther-derby/id1121124593?i=1000449914205 Website link: https://soundcloud.com/drunkenpmradio/7-rules-for-positive-productive-change-w-esther-derby JUSTIN SEARLS ON MAINTAINABLE The Maintainable podcast featured Justin Searls with host Robby Russell. Robbie started by asking Justin what he thinks makes for a well-maintained codebase. Justin evaluates codebases as his job, so he has a process he follows. He starts outside-in. He looks at common things like the readme or other documentation and evaluates how easily he can get up-and-running. This is important because it says something about how often they on-board new people and whether they improve this aspect of their process. The second thing he looks at is what dependencies the codebase is using. He checks that dependencies are up-to-date and whether there are many or few dependencies. He tries to identify whether the team tends to rely on third-party libraries frequently or build their own. Next, he evaluates application-specific aspects of the codebase. If it is a web application, for example, he will evaluate the complexity of the routes. He’s checking that things are named clearly and kept small and whether the team prioritizes organization or not. After he feels that he has his bearings, he looks at statistics like churn to identify hotspots like god objects. That’s just what he gets from looking at the code. He says you can learn a lot from how the team communicates too. High-performing teams, he says, describe what their system does in humble, plain language, whereas the more technical and convoluted a team makes their applications sound, the more likely the team is attempting to imbue their application with unearned significance and this ends up creating barriers to understanding. Justin says that, as he has gotten further removed from the details of software delivery, he has begun to empathize with product managers and business managers for whom words like refactoring and technical debt have become four-letter words because all they’ve ever heard these words used for is excuses for why work isn’t getting done. Justin says that many programmers are often thrust into roles of professional responsibility well in advance of their ability to cogently and calmly understand and describe exactly what a system is doing. The combination of a high-pressure environment with a shaky understanding of the fundamentals of the software the engineer just built limits their ability to explain why things are taking longer than expected without resorting to language like technical debt. He calls this “obfuscating the conversation up a layer.” He talked about the challenges he faced when the industry transitioned around 2011 from largely co-located teams to asynchronous GitHub-based workflows and eventually to using tools like Slack for communication. He said that he didn’t realize at first just how much textual communication is read differently from being in a room with somebody. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/justin-searls-learn-to-understand-the-runtime/id1459893010?i=1000453441400 Website link: https://maintainable.fm/episodes/justin-searls-learn-to-understand-the-runtime-C6e05XWb LENA ROSS AND DR. JEN FRAHM ON AGILE UPRISING The Agile Uprising podcast featuring Lena Ross and Dr. Jen Frahm with host Andy Cleff. They started the conversation by talking about John Cutler’s blog post, “The Patient Change Agent” (https://medium.com/hackernoon/the-patient-change-agent-fd8548f04777) that caused Jen to rethink change resilience. Jen was running resilience workshops at a client at the time and was using Lois Kelly’s work on “change muscles” (http://foghound.com/blog/2016/3/29/build-the-change-musclesbuild-the-change-muscles). A particularly fearless change agent in the workshop told her she had it all wrong: she was using resilience from the perspective of “bracing for change” but needed to be working with resilience in the sense of “renewal”. Jen talked about the distinction between the Agile coach and the organizational change agent. The Agile coach is product development team-focused while the organizational change manager works beyond that. She sees many Agile coaches that do not address the impacts of releasing whatever the team is producing to operations. Andy asked his guests how they bring executives on board in supporting Agile transformations. Jen says she sees executives trying to do full Agile transformations company-wide and they are struggling to understand how much involvement they should have. These leaders need to find someone they trust who has the technology domain expertise to help them. Lena added that, in the last two years, she has seen that leaders are starting to understand enterprise agility. The old practices that served them well in the past aren’t cutting it anymore. They are realizing that they need to reach out and ask for help. Andy pointed out that asking for help and admitting they don’t know something requires a great deal of vulnerability from executives and asked Lena and Jen how they, as consultants, bring this about. Jen says you need to start by meeting with executives one-on-one and you need to be able to role model vulnerability in front of them. You use strength-based language to make them feel safe and you bring in threads from the conversations you’ve had with others so that they know they are not alone. She has also found a lot of success by running breakfasts with the executive team after she has already established trust. These breakfasts serve as safe environments where she role models and facilitates conflict and constructive conversations. Andy said it sounds like Jen is building empathy at the leadership layer. Jen agreed that it is empathy, but added that it is invitation-based. She doesn’t tell people that they must have the conversation; she invites them to consider the concepts. She then spoke about recently rethinking the notion of empathy as a result of mindful self-compassion training. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/empathy-and-resilience-in-leadership/id1163230424?i=1000451652567 Website link: http://agileuprising.libsyn.com/empathy-and-resilience-in-leadership DR. NICOLE FORSGREN ON SCREAMING IN THE CLOUD The Screaming In The Cloud podcast featured Dr. Nicole Forsgren with host Corey Quinn. This was the second part of a conversation with Dr. Forsgren. In the first part, they discussed the latest State of DevOps report. This episode focused more on the new cloud-specific section of the State of DevOps report. She quickly summarized what the overall report found about high and low performers and listed several things low performers can do to become high performers: invest in continuous delivery and automation, work in small batches, invest in observability and monitoring, develop a generative culture, and finally, make use of cloud computing.  The big problem with cloud computing, she says, is that so many people keep redefining “cloud” in a million ways. Without a precise definition of what it means to use “the cloud”, there is no way to be able to give a statistically significant answer about whether and by how much it improves an organization’s performance. So she chose to use the NIST definition for cloud computing and its five characteristics. Measured this way, elite performers are twenty-four times more likely to be executing on all five characteristics. Compared to the total number of organizations that say they are using cloud computing, only 29% of them are meeting all five characteristics. Nicole started describing the five characteristics. The first is on demand self-service. You have to be able to automatically provision your compute resources without human interaction. You can’t be putting them behind a “service down” ticket that you wait for someone to approve. The second is broad network access - can you access it from multiple devices? The third is resource pooling - are the provider resources pooled in a multi-tenant model where resources are dynamically assigned on demand? The fourth is rapid elasticity - can you handle a Black Friday situation? The fifth is measured services - systems can automatically control, optimize, and report resource use and that’s all you’re paying for. She notes that these are all architectural outcomes, design outcomes, and automation outcomes. Regardless of whether you are on public cloud, private cloud, or even a mainframe environment, you can still improve your software delivery performance by architecting your infrastructure with these outcomes in mind. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/five-characteristics-that-define-cloud-nicole-forsgren/id1361244178?i=1000452015823 Website link: https://share.transistor.fm/s/3e21ecc7 COURTLAND ALLEN ON SOFTWARE ENGINEERING DAILY The Software Engineering Daily podcast featured Courtland Allen with host Jeff Meyerson. They talked about the changes to Courtland’s Indie Hackers business that occurred over the past three years. The first was that three years ago, there was no Indie Hackers podcast. There was just the website. Today, the podcast is bigger than the website. Also back then, Indie Hackers was its own business and today it is part of Stripe.  Courtland talked about how Indie Hackers went from a media company to a platform and community. The core of any community, he says, is people who are empowered and able to help each other out. Indie Hackers is all about people starting internet businesses and helping each other overcome the challenges of doing so. To start Indie Hackers, Courtland followed the Reddit playbook. He created a forum, made a bunch of fake threads, made a bunch of fake accounts, talked to himself a lot, occasionally trapped a real person into a conversation with three Courtlands, and before long there were two, then three people talking to a bunch of Courtlands. Eventually, it becomes self-sustaining. His recommendation is to shrink time and space around the community so that it feels active and lively. You want to restrict space around your community online for the same reason that if you’re having a party for only ten people, you don’t hold it in an auditorium. Offline communities are usually easy to restrict in both time and space; you have a meeting time and a place. If you’re going to have a poker game on Wednesday night at six, even if nobody is participating in this poker community any other time, if everyone is at the game on Wednesday, it feels like a lively community. To achieve the same feel online, instead of creating a forum or a message board, do something like posing a question every Friday that community members answer. People will observe a thriving community even if it has only fifteen or twenty people. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/indie-hackers-3-years-later-with-courtland-allen/id1019576853?i=1000452268869 Website link: https://softwareengineeringdaily.com/2019/10/04/indie-hackers-3-years-later-with-courtland-allen/ LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website: 

23. Lighting Up the Brain and Joining a Gym

Deborah Hartman Preuss on Engineering Culture by InfoQ, Jessica Kerr on Legacy Code Rocks, Nir Eyal on Product Love, Dave Snowden on The Jim Rutt Show, and Mike Bowler on Legacy Code Rocks. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. And, if you haven’t done it already, don’t forget to hit the subscribe button, and if you like the show, please tell a friend or co-worker who might be interested. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting October 14, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. DEBORAH HARTMANN PREUSS ON ENGINEERING CULTURE BY INFOQ The Engineering Culture by InfoQ podcast featured Deborah Hartmann Preuss with host Shane Hastie. Deborah was once an Agile coach. She wondered why she didn’t have anything in her toolkit to help people with the discomfort they were feeling with the change Agile was bringing. She didn’t find the answer in Agile, but she found it in coaching. Deborah says that one of the important things she does as a coach is to bring balance to the excitement of our dynamic lifestyles by helping us to slow down long enough to hear our own wisdom. Deborah tries to ask the biggest questions she can come up with. Typically that elicits a “Huh! I need to think about that for a minute.” Sometimes she has to say, “Don’t think about it. Feel it.” She sees her skill as being able to see what is in you, reflecting it back, and helping you notice what’s there. She says that when she can see herself clearly, she can stand in front of other people with less fear, more courage, and more love. She says we have good methods to bring, changes to bring, and skills to teach, but if we are stressed out when we’re doing it, that becomes part of our message. She says that for too long we’ve been told, ”Suck it up! Life is hard. You don’t have to love your job. The stress is part of the package.” In contrast, she believes that people who are not constantly stressed out can bring so much more to their work. Creating a joyful workplace starts with authenticity. When you are not trying to conform to somebody’s idea of who you should be, all that extra energy is left over to simply do great stuff. Authenticity both reduces stress and frees your uniqueness. Shane pointed out that authenticity requires vulnerability. Deborah says that is where leadership comes in: to create safety. A leader who doesn’t feel safe will have trouble creating safety for others. When we ask people to be vulnerable, it has to fall into a place of trust. That trust must be built first and that is a leadership skill. Shane asked how one builds that trust. Deborah pointed to the book Liftoff by Larsen and Nies (https://www.amazon.com/Liftoff-Start-Sustain-Successful-Agile/dp/1680501631). We build trust, she says, by talking openly about things and being accountable to one another. She also referenced The Speed of Trust by Stephen M. R. Covey (https://www.amazon.com/SPEED-TRUST-Thing-Changes-Everything/dp/1416549005) for building trust and repairing trust when it is broken. Shane asked about the state of diversity. Deborah said that part of the state of diversity right now is, “Oh look at how diverse we are!” but this is not the same as everyone feeling welcome to contribute their differences. Inclusion is honestly welcoming differences and giving those differences a proper reception. Shane asked about Ten Women Strong and Deborah described how the Ten Women Strong #WomenInAgile program lets women start from a common set of values from Agile. The group helps them to recognize their authenticity, celebrate it, and start designing to turn that into what they need. She described how the program helps women meet their own needs so that they fill the well and have more to give out to others. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/deborah-hartmann-preuss-on-creating-joyful-workplaces/id1161431874?i=1000449085542 Website link: https://soundcloud.com/infoq-engineering-culture/interview-deb-priuss JESSICA KERR ON LEGACY CODE ROCKS The Legacy Code Rocks podcast featured Jessica Kerr with hosts Andrea Goulet and M. Scott Ford. Jessica has been a software developer for twenty years. One of her obsessions is how, as developers, we have a unique power to change our own environment. It gets even more interesting when we change the environment our team works in.  They talked about symmathesy. It starts with systems thinking, where people realized that you can’t reduce a system to its parts, understand the parts, and expect that to extend to an understanding of the system as a whole. You need to understand the relationships between the parts. Anthropologist Nora Bateson took this idea further when she realized that it is not just that the relationships between the parts matter; each part is constantly changing as a result of its relationships to the others. She called this symmathesy. Scott asked how awareness of the symmathesy of software development has changed the way Jessica does her work. Jessica says that if you look at a software team as a socio-technical system of humans and software based on mutual learning, the trickiest part is the line between the humans and software. The interface between the humans and the software is low bandwidth and this has made Jessica appreciate the value of tooling and how tools need to be customized for every different software system and every group of people. Andrea asked how Jessica can explain those benefits to those who are in charge of budgets and in charge of predicting what will be delivered. Jessica says that people are starting to notice developer experience and developer productivity. For example, these topics show up at conferences more today than they used to. Jessica related the symmathesy of software development back to Andrea’s article on technical debt as communication debt. When you have a mental model of the software, that software is alive to you because you can change it. But if you add another person who doesn’t yet have that mental model, that software is dead or legacy to them because, to them, that software is not safe to change. They talked about 10x developers and how much of their productivity comes from being the original author of the system. Building a mental model from a system that somebody else wrote is much more difficult than writing a system yourself.  Andrea pointed out that from the original system author’s perspective, the other engineers seem less capable because they are struggling to understand something that seems obvious to the original author. Jessica says to always replace the word “obvious” with “I can’t explain it, but...” Jessica says she’s learned that whenever she thinks someone else is stupid, chances are they know something she doesn’t, and this is why their actions don’t make sense to her. Jessica is talking about avoiding the fundamental attribution error. She went on to talk about the difficulty of transferring knowledge. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/symmathesy-with-jessica-kerr/id1146634772?i=1000449136678 Website link: http://legacycoderocks.libsyn.com/symmathesy-with-jessica-kerr NIR EYAL ON PRODUCT LOVE The Product Love podcast featured Nir Eyal with host Eric Boduch. Eric asked Nir what inspired him to write his new book Indistractable. Nir says that Indistractable is a pro-human, pro-tech book about being able to control your attention and manage all sorts of distraction. Half the book is about how individuals can become indistractable and the rest is about how to help others or our environments become indistractable. When Nir was researching the book, he was surprised to discover that all of our behaviors are driven by a desire to escape discomfort. He says that if you want to become indistractable, you need to start with mastering your internal triggers.  We also need to be aware that the companies we work for are creating much of the distraction. If a company has the wrong kind of culture, that is, one that is high expectation and low control, it causes psychological discomfort. In these cultures, we strive for control by sending more emails, calling more meetings, and distracting ourselves and others. Another surprise for Nir was learning that technology at work is not the source of distraction. Distraction at work is a symptom of a dysfunctional workplace culture. For example, group chat apps like Slack are considered distracting. If the technology was the culprit, he asks, shouldn’t the people who work at Slack and use it most be the most distracted people? Slack doesn’t have this problem because they have a healthy workplace culture. This is relevant to managers because, unless you have three factors in your workplace, you will always have distraction. The three factors are: 1) an environment that provides psychological safety, 2) a forum for people to air concerns, and 3) leaders who exemplify what it means to be indistractable. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/nir-eyal-joins-product-love-to-talk-about-creating/id1343610309?i=1000449384509 Website link: http://productlove.libsyn.com/nir-eyal-joins-product-love-to-talk-about-creating-better-products-and-meetings DAVE SNOWDEN ON THE JIM RUTT SHOW The Jim Rutt Show featured Dave Snowden with host Jim Rutt. Jim asked Dave to explain Cynefin, the conceptual framework that Dave created to aid in decision-making. Dave says that Cynefin is based on a fundamental divide into ordered systems, complex systems, and chaotic systems. There is a phase shift between these types of systems rather than a gradation. An ordered system has a high enough level of constraint that everything is predictable. An example is such a constraint is how we all drive on the left in the UK and on the right in the US. This is called an “obvious” approach to order. The relationship between cause and effect is obvious. Another type of order is “complicated”, where there is still a right answer and, for experts, it may be obvious but, for the decision-maker, it isn’t. You sense/analyze/respond and you may discover the right answer with less precision. It is the domain of good practice, not best practice. If you over-constrain a system that is not naturally constrainable, sooner or later it fragments into chaos. If you fall into chaos accidentally, you no longer sense/analyze/respond, but instead you act/sense/respond. An example is Clayton Christensen’s notion of competence-induced failure: being so good at the old paradigm that you don’t see the change coming and the change becomes catastrophic for you. A complex system is one that has enabling constraints. Everything is somehow connected to everything else but the connections aren’t fully known. One concept is the dark constraint, referencing dark energy, where we can see the impact of something without knowing where the impact is coming from. You may want to compare this to the notion of symmathesy from Jessica Kerr’s appearance on Legacy Code Rocks. In a complex-adaptive system, the only way to understand it is to probe. One of Dave’s definitions of “complexity“ is: if the evidence supports conflicting hypotheses of action and you can’t resolve those hypotheses within the timeframe for a decision from the evidence, the situation is complex. In Cynefin, you don’t try to resolve it, you construct a safe-to-fail micro-experiment around each coherent hypothesis and you run them in parallel. That, in turn, changes the dynamics of the space and a solution emerges. The final domain is the domain of disorder. This is the state of not knowing which of the other systems you are in. It is a type of inauthenticity. If your natural tendency is to bureaucracy, you are likely to impose order when it is inappropriate. If your natural tendency is towards complexity and emergence, you may choose not to impose order when it would have been more appropriate to impose it. The essence of Cynefin is to say, “context is key.” Dave got fed up with management fads that said things like, “business process reengineering is universal” or “the learning organization is universal.” None of these are universal. They all work within a specific context. So part of the function of Cynefin is to decide what context you are in before you decide what method you will use. They went on to talk about Apex Predator theory, agent-based modeling, “anticipatory triggers”, artificial intelligence, Nicholas Nassim Taleb, and many other topics. I particularly liked what Dave had to say about what people who work on artificial intelligence should be trained in. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/ep11-dave-snowden-and-systems-thinking/id1470622572?i=1000449087845 Website link: https://jimruttshow.blubrry.net/dave-snowden/ MIKE BOWLER ON LEGACY CODE ROCKS The Legacy Code Rocks podcast featured Mike Bowler with hosts Andrea Goulet and M. Scott Ford. Mike has been writing code for thirty-five years. In the late nineties, he got frustrated with watching projects fail. He was working for a big bank and they would celebrate when they shipped something, but they knew it wasn’t what the customer wanted. Looking for something better, he found the XP community. He decided he needed to get better at the “people stuff.” This took him into neuroscience, psychology, hypnosis, neurolinguistic programming, and body language. He talked about Clean Language. Clean Language came originally from therapy. It was modeled on the style of therapy used by a therapist named David Grove, who himself never formalized his process. Clean Language is a set of questions that don’t contaminate the metaphors of the people you are questioning. He used the example of a metaphor of a head “exploding” with ideas to describe how to avoid contaminating a person’s metaphor. They talked about Judy Rees’s Lazy Jedi questions which are named that way because, if you only ask those two questions over and over, it is like you are using Jedi mind tricks. The questions are, “What kind of X is that?” and “Is there anything else about X?” If the metaphor is “my head is exploding with ideas,” the Lazy Jedi questions become: “What kind of exploding is that?” and “Is there anything else about that exploding?” Some people tell Mike that, as a software developer in a highly technical environment, they don’t use many metaphors. Mike begs to differ. He says that the metaphors are so deeply embedded that they don’t notice any more. A bug is a metaphor. A cache is a metaphor. Some metaphors are blatantly obvious, like “the band was on fire,” and some are really subtle, like, “I have a lot of bananas.” You aren’t using the exact definition of the word “lot” but are using it as a metaphor. They went through a clean language exercise in which Mike asked Scott about what he is like when performing at his absolute best and, based on his answers, got deeper and deeper into Scott’s metaphor. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/unconscious-behavior-in-coding-with-mike-bowler/id1146634772?i=1000447835119 Website link: http://legacycoderocks.libsyn.com/unconscious-behavior-in-coding-with-mike-bowler LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website: 

22. Unknown Knowns and Contaminated Metaphors

Zach Stone on Drunken PM, Etienne de Bruin on Programming Leadership, Josh Seiden on The Product Experience, Pooja Agarwal on Coaching For Leaders, and Cate Huston on Distributed, with Matt Mullenweg. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. And, if you haven’t done it already, don’t forget to hit the subscribe button, and if you like the show, please tell a friend or co-worker who might be interested. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting September 30, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. ZACH STONE ON DRUNKEN PM The Drunken PM podcast featured Zach Stone with host Dave Prior. Dave and Zack talked about Motivational Interviewing or MI, a technique for helping a person navigate the process of making changes in their life. They first talked about what doesn’t work. Walking up to a smoker of twenty years and listing to them all the reasons why smoking is bad for them is not going to change their behavior. It is the same thing when you are trying to change the way a person does their work. Listing the reasons you think they should change makes the change all about what you want when it should be all about what they want. The person you want to change is an expert in their own life. A big part of Motivational Interviewing is finding the natural desires, reasons, and needs for why they should change and making them visible. Dave likened the difference between telling people to change and using motivational interviewing to the difference between extrinsic motivation and intrinsic motivation. Zach shared a quote from Lao Tzu: “A leader is best when people barely know they exist. When their work is done, their aim fulfilled, the people will say, ‘We did it ourselves.’” At the core of that quote, he says, is a sentiment around empowerment and autonomy. If we want to create an environment where people feel ownership and create sustainable change, people need to feel like that change came from them and is owned by them. Change is a never-ending process; it is not an event; it is not something that happens overnight. Dave asked, if we’ve been dealing the problem of organizational change for so long, why have we not yet solved it? Zach went all the way back to Theory X and Theory Y and how we are still often stuck in Theory X even today. He pointed out that the habits of how we work become almost like addictions we can’t shake. Dave says he tries to be a Theory Y person, but finds himself falling into Theory X all the time. Zach says that this is “change fatigue”. A big part of motivational interviewing is recognizing that we have within us the “righting reflex”: the reflex to correct and inform and tell people how they should be acting. It is not something that you can really escape; you can just own it, be aware of it, and work around it as much as possible. Zach says organizations have immune systems that fight the change you try to inject into them. The reason MI is so elegant, he says, is because it maximizes the work not done. In MI, you try to pull change by igniting the natural mechanisms that are already there rather than asserting yourself on top of that system. The textbook definition of MI is that it is a collaborative conversation to strengthen a person’s own motivation for and commitment to change. It is both a set of principles and a framework of techniques. The five main tools are open-ended questions, affirmations, reflections, summarizing, and informing. Zach told the story of speaking with a CIO about their technology stack. He shared with him that the developers at that company thought that innovation was stalling and technical debt was piling up. The CIO answered that they needed to develop new features and there was no time to address technical debt. Zach tried to affirm by talking about having seen some great innovation coming from this CIO’s teams and asking how they could keep it going. What became apparent was that the CIO was not going to budge. So he asked an open-ended question: “What do you think will happen if you let your technical debt pile up?” The CIO replied, “It is probably going to slow us down and hurt our ability to recruit top talent.” So Zach used reflection. Zach said, “On one hand, you feel you need to keep moving on developing features even if it means technical debt cleanup takes a backseat. On the other hand, if you do this, it is going to hurt your ability to recruit talent and eventually will slow down feature development.” He let that sit and thanked the CIO for his time because it was clear that the CIO was not ready to make a shift in his thinking. Two and half months went by and Zach leveraged the power of the group of this CIO’s technical leads. At a gathering of these leads where the CIO was present, Zach asked what their number one obstacle was and they all said, “Time.” Hearing it from people he trusted and respected, the CIO said that they would be launching an effort to address the technical debt issue. He used “change talk”: he made a commitment to change in a public forum. The research shows that the more people engage in change talk, the more likely they are to put plans into action. The next day, emails were flying back and forth, meetings were set, mechanisms were getting put in place for the tech leads and their teams to address this issue. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/motivational-interviewing-zach-stone/id1121124593?i=1000447916792 Website link: https://soundcloud.com/drunkenpmradio/motivational-interviewing-zach-stone-august-2019 ETIENNE DE BRUIN ON PROGRAMMING LEADERSHIP The Programming Leadership podcast featured Etienne de Bruin with host Marcus Blankenship. Etienne is the CEO of 7CTOs, a company that puts Chief Technology Officers into a peer mentoring environment to help them learn everything from situational leadership to achieving personal and professional goals. When he started the 7CTOs community, Etienne thought the conversations would focus on the software development lifecycle, technical debt, and managing the CEO’s expectations, but every time the focus went to the people challenges. He attributes the success of 7CTOs to how it addresses problems that require emotional intelligence (EQ) rather than IQ. Etienne told a story about when he first started a startup twelve years ago, he thought he was a fantastic CTO: he knew his stuff and he built the product’s first iteration with his bare hands. He had a reality check when he and his team did a retreat where they attempted to brainstorm ideas. He thought he was succeeding on inclusion and making every voice count from the most junior to the most senior. He was surprised to find that very few were participating. Until that moment, he hadn’t been aware of how fearful everyone was of collaborating with him because he was so blunt in his feedback and he was only happy if the idea was his own. He realized that he wasn’t going to succeed in the next level of his company’s development if he didn’t change. He had to let go of the idea that his employees were just there to execute his ideas and to see them as independent, creative human beings. He read the book Creative Confidence and it showed him that every single person is creative and we just vary in our confidence about our creativity.  Marcus said that if employees are not there just to be extensions of ourselves, what kind of employees should we be looking for. Etienne said that there are two things we want to do when we hire. First, we want the candidate to fulfill the minimum requirements of the job spec. Second, we want the candidate to be set up to succeed inside of the team. Etienne has used personality tests like DISC profiles and enneagrams to get an idea of how well the candidate can meet the second criterion. They got into a discussion about the difference between avoiding emotions and having emotions but realizing you have a choice in how you respond to them. Etienne pointed out that you can rely on other people to help you through your emotions. You can increase your EQ with the help of others. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/putting-the-emotion-into-eq-with-etienne-de-bruin/id1461916939?i=1000447505984 Website link: https://programmingleadership.podbean.com/e/putting-the-emotion-into-eq/ JOSH SEIDEN ON THE PRODUCT EXPERIENCE The Product Experience podcast featured Josh Seiden with hosts Lily Smith and Randy Silver. Lily, referring to Josh’s new book Outcomes Over Output, asked Josh how he defines an outcome. He says it is a change in human behavior that drives business results. One reason that this is a useful definition is that it is specific. When you use outcome in the broad sense, it can be heard as a synonym for result or goal. A second reason is that human behavior is observable, concrete, and action-oriented. This definition for outcome lets you ask the questions, “What are we going to do to deliver these outcomes? How can we change people’s behavior through the systems that we are building?” These questions lead to concrete answers where you can observe the results. The reason Josh says “human behavior” is because he is referring to any actor in the system. In UX design, the actor is usually assumed to be the user. But, in this case, it can be the user, the customer, an internal person (such as someone in customer support), a journalist you want writing about your product, or any person who is participating in the system that is to be built. Lily said that in her own attempts to move more towards outcomes, she has had the problem of having too high-level an outcome. Josh says that the Logic Model framework from the non-profit, social-good sector can help with this. In this framework, high-level measures like profit, cost, net promoter score, or customer retention are called impacts. It is unlikely that an individual team can move such numbers on their own. So you ask what outcomes will create the impact that you seek and you get something that is scoped down enough to be actionable on the team level. Randy asked why it is so hard for organizations to change their thinking about this and stop setting goals around milestones, dates, projects, and outputs. Josh says that you can’t get around the problem of output because making stuff is how you get to the outcome. He gave the example of Scrum. Scrum is built around the sprint. The sprint isn’t complete until you create a finished piece of software you can ship. This is important, but it doesn’t mean that what you created has the effect in the world that you want it to have. Randy asked about the problem of the increase in dependencies and complexity as companies grow. Josh says you have to think about how to increase the independence of the teams. He says you should think of your internal teams (those that are not customer-facing) as having customers. If you are an internal team, you can ask, “What does the customer-facing team that is our customer need and what is the smallest thing I can give them so that they are unblocked and can start serving their customer.” By remodeling this relationship from a dependency to a customer service model, you can string outcomes down the value chain and hopefully reduce dependencies that way. Another alternative is to give teams a shared or aligned outcome. They compared Josh’s terminology with that of Objectives & Key Results (OKR). Josh agreed with Lily that his definition of an outcome matches up with a key result. He used the John Doerr example of how Google once had an objective of solving the problem of the Internet being too slow by making browsing feel more like flipping through a magazine, which became the Google Chrome program. The key result was based on the number of users actively using Chrome. It wasn’t that they shipped it. It wasn’t the number of downloads. When you ensure a KR is not an output but a meaningful result in the world, it drives you to an outcome-centric definition. Josh talked about a section from his book called “the three magic questions.” The first question is, “What are the user and customer behaviors that drive business results?” The next question is, “How do we get people to do more of these things?” The last question is, “How do we know when we’re right?” Lily asked how you build outcomes into your roadmap. Josh told the story from his other book, Sense and Respond, about a large startup in New York whose annual planning process was to produce an outcome-based roadmap. They might say something like, “We want to increase our marketshare in Europe” or “We want to shore up our business with this customer segment.” The product teams listed all the projects they could do, the demand from the market, and the things that need fixing. The product managers would try to reconcile those two things and choose the body of work that aligned with leadership priorities. They would commit to leadership to, say, increase marketshare in Europe by some percentage, but would not sign up for outputs. Instead, they would reserve the right to swap in and out projects based on whether they were moving the needle or not on the outcomes. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/outcomes-over-outputs-josh-seiden-on-product-experience/id1447100407?i=1000445191364 Website link: https://www.mindtheproduct.com/2019/07/outcomes-over-outputs-josh-seiden-on-the-product-experience/ POOJA AGARWAL ON COACHING FOR LEADERS The Coaching For Leaders podcast featured Pooja Agarwal with host Dave Stachowiak. Dave brought up that, in her book, Pooja says that the science of learning sits dormant in academic journals rather than being easily accessible. She says that we are all learners and we are all teachers. Teaching is something we do everyday even without thinking about it. Dave asked about the three stages of learning that Pooja describes in her book. Pooja pointed out that the three stage model is a simplistic model but is a helpful framework. The first stage is encoding or getting things into our heads. The second stage is storage. The third stage, retrieval, is where we pull information out. In higher ed, she says, we often think of retrieval as showing what you know, but we learn when we retrieve. By that act of retrieving, we are helping ourselves remember something in the future. Dave gave an example from a previous episode on delegation. He said that, after delegating a task, leaders often ask, “Do you understand?” A better question would be something like, “What are the key deliverables of what I have delegated to you?” This question gets the employee to articulate it to not only assess where they are in their learning but also to reinforce their learning. Dave asked about the statement in the book to stop reviewing things and instead ask for what was discussed. Pooja said that as leaders we often start meetings with, “Here’s what we did at the last meeting, so here’s what we’re going to accomplish today.” Instead, ask people to take a minute and write down what they can remember from the previous meeting. This engages them in such a way that it helps them to better understand the content of the present meeting.  Apple Podcasts link: https://podcasts.apple.com/ca/podcast/421-help-people-learn-through-powerful-teaching-pooja/id458827716?i=1000445006344 Website link: https://coachingforleaders.com/podcast/learn-through-powerful-teaching-pooja-agarwal/ CATE HUSTON ON DISTRIBUTED, WITH MATT MULLENWEG The “Distributed, with Matt Mullenweg” podcast featured Cate Huston with host Matt Mullenweg. Cate leads the developer experience team at Automattic. This team is concerned with what it means to be a developer at Automattic, including the challenges of distributed, remote development, how developers can learn from each other, and how developers can get the support they need to chart their own career paths. She says a critical part of the developer experience is the connection between the hiring process and the on-boarding process. They are thinking about how to make the hiring process a good experience where the candidate can see if Automattic is the right fit for them and Automattic can see if the candidate is the right fit for the company. They want this to carry through as the new employee joins the team and becomes successful in their new role. Because the Automattic organization is so large and the developer experience team is so small, they look for pivot points to maximize their impact. She gave an example: when a team gets a new lead, that is a pivot point. They support this new lead and help them develop and iterate on their process. Cate’s advice to Automattic job candidates is to be patient because distributed companies take longer to hire and there is a lot of competition for remote jobs. A well-crafted cover letter is a must. When Cate is hiring an engineer, she is looking for two things. The first is the ability to work with the kind of complex, legacy codebase they have. The second is to be able to respond well to feedback because you are expected to grow over time in your career. She talked about self-awareness. As an example of low self-awareness, she talked about how some people need to be seen as being “nice,” regardless of whether it is true or not. The gap between the way somebody talks about themselves and their actions reveals their lack of self-awareness. She listed some things that increase self-awareness: reading a broad variety of fiction, cultivating a broad network of people, and traveling outside your comfort zone. Matt added that you can travel outside your comfort zone without leaving your city by visiting parts of your city you haven’t traveled to before. Cate also recommends shedding defensiveness and getting curious. She also recommends asking for advice. People often don’t give advice when they think you are doing a good job. When she gives feedback to people, she asks them if they felt seen when they received the feedback. Matt tries to remind himself that feedback is a gift. Cate says that if somebody cares about you enough to tell you that they think you should do better, that means they think you can do better. Cate also recommends that we stop giving advice, especially without context or understanding of what someone is trying to achieve. Instead, pause, ask questions, get context, and reflect back to someone what they are saying to you. Last, Cate says to own up and admit what is not going well. She gave an example of her team recently doubling in size. Seeing her job changing, she asked the team what the most useful thing she does for them was and what she should stop doing. Matt asked what else makes a great engineering culture. Here is Cate’s answer: Apple Podcasts link: https://podcasts.apple.com/ca/podcast/automattics-cate-huston-on-building-distributed-engineering/id1463243282?i=1000447512202 Website link: https://distributed.blog/2019/08/22/cate-huston-distributed-engineering/ LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website: 

21. Sinking Cruise Liners and Structural Baggage

20. Multi-vitamins and Two-way Doors

Will Larson on Greater Than Code, Marcus Blankenship on Software Engineering Radio, Sonal Chokshi on Software Engineering Daily, Roman Pichler on Being Human, and Dave Thomas and Andy Hunt on Hanselminutes. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. And, if you haven’t done it already, don’t forget to hit the subscribe button. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting September 2, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. WILL LARSON ON GREATER THAN CODE The Greater Than Code podcast featured Will Larson with hosts Jessica Kerr, Arty Starr, and Rein Henrichs. Will talked about systems thinking, specifically referencing Donella Meadows’ Thinking in Systems: A Primer. As a sixteen-year-old, he was exposed to systems thinking by his economics professor father. They talked about how to bring about change in complex systems and Rein brought up Virginia Satir’s change model.  They talked about various forms of dysfunction, with an example being tasks that are marked as completed by developers without first doing the work of validation. Will’s own example is that executives never miss their goals; they just redefine the goals so that they hit them. There is a certain level of seniority where you can never be held accountable because you are the accountability function. Getting back into the topic of how to change complex systems, Will referenced the book, The First 90 Days as a great explanation of the need to go slow and observe before you try to change things. He says that the “great man theory” has been out of style for decades in the study of history, but is still in style in tech as the most causal way to understand how change works and also the most comforting. Rein talked about how the heroic individual myth is the other side of the coin to the scapegoat. Just as you pile all the blame onto the scapegoat, you pile all the credit onto the hero. He says that cultures that engage in hero myth-building are also likely to engage in scapegoating. Will says he himself has not seen much scapegoating at the companies he works at, likely because those cultures were unwilling to hold folks accountable for their work, but he has seen the hero myth at every company he has worked. Will then spoke about the 10x engineer myth. Will says he meets people who have been in tech for six or seven years who have the idea that they are almost done with their career. It may be due to the “senior engineer after two years” phenomenon where the career path is not well-defined and a lot of companies don’t know how to take advantage of the skills of people with 15 to 20 years of experience. A second reason is that the industry is an overwhelming and draining environment and people choose to opt out of it. As a result, we have very few engineers who have been around long enough to witness the long-term consequences of their brilliant ideas. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/142-modeling-constraints-in-human-systems-with-will-larson/id1163023878?i=1000446345964 Website link: https://www.greaterthancode.com/modeling-constraints-in-human-systems MARCUS BLANKENSHIP ON SOFTWARE ENGINEERING RADIO The Software Engineering Radio podcast featured Marcus Blankenship with host Travis Kimmel. They talked about motivation, specifically motivation of engineering teams. Marcus says that motivation is the desire to get things done and every engineer coming out of school is motivated from day one. If you get one of these people hired onto your team and, two years later, they are demotivated, suffering from PTSD, scared to offer ideas, and figuring they are just a cog in a machine, your problem is your company or your team, not the engineer you hired. Marcus says he is doing secret research on motivation as he is now interviewing candidates for a job and asking them why they are looking to leave their current job. Nobody says, “Pay.” Often the answer is a lack of alignment with their boss or their company, resulting in the engineer losing the desire to contribute because of a relationship problem. These engineers are not stick-in-the-muds that are angry they don’t get to use COBOL anymore. Something happened where instead of having their ideas valued and heard and being part of the discussion, they somehow got disconnected from their boss. In the seventies, Marcus says, researchers discovered a strong correlation between positive employer-employee relationships and the amount of job satisfaction, quality of work, turnover intentions, and amount of promotions. We are thirty-five years into a few thousand scientific studies that continue to prove that the relationship one has with one’s supervisor matters more than any other factor when it comes to job performance and job satisfaction. Marcus says that a supervisor’s one true job is to create a trusting relationship with the people that report to you. Travis shared his own experience in having one-on-ones with his supervisors that felt to him like they were trying to artificial manufacturing a relationship because there was no indication of what the goal of the meeting was.  Marcus says that good one-on-ones are bi-directional. One-on-ones in which the boss just gets status updates from the subordinate and gives new marching orders are often dissatisfying for both parties. Another flawed kind of one-on-one is where it is all about the employee. Such one-on-ones are not effective and neither party likes these either. Marcus suggests that we apply to our one-on-ones the same Agile thinking that we apply to our work. Every month, at one of your one-on-ones, do a retro on the one-on-one. Talk about why you are doing them, what value you’re getting from them, and how to make them better. They talked about psychological safety. Marcus says a lot of managers don’t realize that they are not in a good position to measure psychological safety based on their own gut. He says tools like Claire Lew’s knowyourteam.com, officevibe.com, and other anonymous survey tools can help. When we become a manager or team lead that has you supervising or leading, we forget that we are in a position of power. Travis added that leaders need to be careful about what they say casually so that it doesn’t get taken as a mandate. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/episode-374-marcus-blankenship-on-motivating-programmers/id120906714?i=1000445260176 Website link: https://www.se-radio.net/2019/07/episode-374-marcus-blankenship-on-motivating-programmers/ SONAL CHOKSHI ON SOFTWARE ENGINEERING DAILY The Software Engineering Daily podcast featured a16z podcast host Sonal Chokshi with host Jeff Meyerson. Jeff started out by asking why a VC firm decided to start a podcast. Sonal says that a16z has always had a culture of writing, blogging, and sharing ideas. This led them to develop an editorial operation from which the podcast naturally followed. Jeff asked what lessons from blogging apply to podcasting. Sonal sees podcasting as the next evolution of blogging because of its similar intimacy and a similar feeling of authenticity. The difference, she says, is that podcasting is a community and a movement.  Sonal talked about her favorite a16z episodes, including an episode on emojis. She loved it because everybody understands how to use emojis but there is a lot of deep tech and governance involved in making emojis possible. That episode, she said, encapsulates the whole a16z podcast: the intersection of technology, people, politics, context, culture, and humanity.  Jeff brought up a16z’s connection to Mike Ovitz’s Creative Artists Agency. Having read Ovitz’s book and noticed how it portrays Ovitz as a workaholic, Jeff asked Sonal how she finds balance while drinking from the addicting technological firehose. Sonal says there is a lack of nuance in the debates about screen time and work/life balance. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/a16z-podcasting-with-sonal-chokshi/id1019576853?i=1000446547922 Website link: https://softwareengineeringdaily.com/2019/08/09/a16z-podcasting-with-sonal-chokshi/ ROMAN PICHLER ON BEING HUMAN The Being Human podcast featured Roman Pichler with host Richard Atherton. Richard asked Roman what a product manager is. Roman says a product manager is someone who takes an idea and helps bring it to life, launch it, make it successful, and keep it successful. Richard asked about the distinction between a product manager and Scrum’s notion of product owner. Roman sees the product owner as a product management role, but methodologies like SAFe have redefined the product owner to be a tactical role, misunderstanding the intention behind the role and the practicalities such as answering questions from the dev team, refining backlog items, and answering support and sales questions. He says there is too much focus on the details and this risks losing sight of the big picture. To do a good job for users and for the business, Roman says it is helpful to have people looking after digital assets with the right qualifications, skills, organizational support, authority, and autonomy. He says the term “mini-CEO” appeals to some product people because it indicates that product people need a certain level of authority, but a CEO would have marketing and sales functions under their control and product people do not. Richard asked what talents Roman had to develop to be a great product person. Roman started out as a programmer and began to help business groups come up with new products. What helped him most was to boost his own understanding of how business works and the second most important element was letting go of being interested in how digital products work and focusing instead on who benefits from them. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/72-to-manage-products-is-to-care-with-roman-pichler/id1369745673?i=1000446514943 Website link: http://media.cdn.shoutengine.com/podcasts/4081235a-554f-4a8f-90c2-77dc3b58051f/audio/9b2501e7-e618-46f6-8f41-abd69c871211.mp3 DAVE THOMAS AND ANDY HUNT ON HANSELMINUTES The Hanselminutes podcast featured Dave Thomas and Andy Hunt with host Scott Hanselman. Scott started by asking whether Dave and Andy knew at the time they wrote the Pragmatic Programmer 20 years ago that they were writing what would become a seminal work. Dave said that both of them were stunned by its success. The book was intended as a way to clarify their own thoughts based on their experiences as consultants in which their clients all had the same kinds of problems: inconsistent builds, the shipping of untested code, and impossible-to-change designs. Scott asked about the importance of the name of the book. Andy said that there was a strain of thought at the time the book was written that was dogmatic and they deliberately pushed against such approaches. Dave pointed out that this was harder on their readers because it forced them to figure out for themselves what works for them. They got into a discussion of what kind of educational background one needs to be a successful programmer. Dave revealed that he is currently teaching classes at SMU to, he says, corrupt the youth by teaching them things like functional programming, and because traditional computer science education is poorly serving the industry and the student. People are coming out of university with tens or hundreds of thousands of dollars of debt and, in terms of their value in the industry, they are not much different from people who are coming out of eight-week bootcamps. He teaches third or fourth year undergraduates and graduate students and he has found that none have been shown any form of testing. He would much rather hire someone who had the right attitude, was smart, and who could talk to people and he could show such a person how to code while on the job. Andy added that he gets the feeling that most computer science programs are there to teach you to become a professor of computer science rather than a problem-solver. What Andy says people need to learn, and what university education is not providing, are problem-solving skills. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/pragmatic-programmer-celebrates-20-years-dave-thomas/id117488860?i=1000446461596 Website link: https://hanselminutes.simplecast.com/episodes/the-pragmatic-programmer-celebrates-20-years-with-dave-thomas-and-andy-hunt-VBmLw9lP LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website: 

19. The 10x Engineer Myth

There are so many podcasts today in the technology and leadership categories that it can be hard to find the truly outstanding episodes and the guests that are going to change the way you think. Every two weeks, join Keith McDonald for a short summary of the most fascinating podcast episodes he discovered in the software development, product management, and leadership space. If you want to keep up to date on the latest thinking on leadership, product management, Agile software development, DevOps, and lean thinking, this is the podcast for you.

hubhopper

Technology Leadership Podcast Review

hubhopper