Technology Leadership Podcast Review

Keith McDonald: tech blogger and podcaster

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 summaries 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.

  1. 03/16/2020

    Making The World's Best Pencil

    Chris Ferdinandi on Greater Than Code, Ben Orenstein on Maintainable, Susan Rice on Coaching For Leaders, Courtland Allen on Software Engineering Unlocked, and Matt Stratton on Hired Thought. 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 16, 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. CHRIS FERDINANDI ON GREATER THAN CODE The Greater Than Code podcast featured Chris Ferdinandi with hosts Rein Henrichs and Jacob Stoebel. Chris is a proponent of plain vanilla JavaScript. He says that modern web development has grown so much in scope and complexity that it makes it difficult for beginners to get started and it can negatively impact the performance of the web for users in ways that developers with fast machines don't always feel. One of the reasons things are the way they are today, Chris says, is because a lot of backend developers migrated to the front end because that was where the exciting stuff was happening and they brought with them their approaches and best practices. The front end, however, is a very different medium. In the back end, you have control over how fast the server is, when things run, the operating system, etc. On the front end, you have none of this. People are accessing what we build on a variety of devices that may or may not be able to handle the data we're sending and may have unpredictable internet connections. If a file fails to download or the user goes through a train tunnel and we've built things in a modern JavaScript-heavy way, the whole house of cards falls apart on these users. Chris would like people not to abandon JavaScript altogether, but to be a little more thoughtful about how we use it. Modern web development involves a few things: frameworks, package managers, and doing more and more things (such as CSS) in JavaScript. All of this JavaScript has the effect of slowing down performance because 100KB of JavaScript is not the same as 100KB of CSS, a JPEG, or HTML because the browser needs to parse and interpret it. Because of these performance problems, single page apps have become more popular. But now you're recreating in JavaScript all the things the browser gave you out of the box like routing, shifting focus, and handling forward and back buttons. You're solving performance problems created by JavaScript with even more JavaScript, which is the most fragile part of the stack because it doesn't fail gracefully. If a browser encounters an HTML element it doesn't recognize, it just treats it as a div and moves on. If you have a CSS property you mis-typed, the browser ignores it. But if you mistype a variable in JavaScript, the whole thing falls apart and anything that comes after that never happens.  For Chris, a better approach to web development is one that is more lean and more narrowly-focused on just the things you need. His first principle is to embrace the platform. For example, a lot of people don't realize that DOM manipulation that used to be really hard years ago is really easy these days in vanilla JavaScript. Also, many of the things that JavaScript was required for in the past can be done more efficiently today with HTML and CSS. He also says that we need to remember that the web is for everyone. Because we are often using high-end computers, the latest mobile devices, and fast internet connections, we forget that this is not the experience for a majority of web users. We build things that work fine on our machines but are painfully slow for the people who actually use the things we build. They ended their discussion with reflections. Chris's reflection was about learning JavaScript and web development for the first time. He says that people learning shouldn't be made to feel like they need to dive in to the latest trends, but should instead find a way to learn the fundamentals. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/170-the-case-for-vanilla-javascript-with-chris-ferdinandi/id1163023878?i=1000466076138 Website link: https://www.greaterthancode.com/the-case-for-vanilla-javascript BEN ORENSTEIN ON MAINTAINABLE The Maintainable podcast featured Ben Orenstein with host Robby Russell. Ben believes that, in a maintainable codebase, the code should match how you think about the world. When speaking about the domain with your teammates, do you use the same terminology that the code uses? Do you use the term "user" but the code uses the term "customer"? Getting your terms consistent is a specific case of a more general principle of implicit and explicit knowledge. Maintainable systems have as much knowledge put into them as possible so that they become sources of truth. Ben's definition of technical debt is a technical shortcut you took intentionally after weighing it against alternatives and deciding it was worth it in the short team with the eventual intention of eliminating it. He says it is hard to get time on a schedule dedicated to cleaning up technical debt, so it is your professional responsibility to clean it up as you go. Ben says that asking permission to clean up technical debt as you deliver a feature is like asking permission to do your job well. He says that the idea of "We'll go fix this later" never happens and, if you don't believe him, grep your codebase for the string "TODO". Apple Podcasts link: https://podcasts.apple.com/ca/podcast/ben-orenstein-someday-well-go-clean-that-up-doesnt-work/id1459893010?i=1000466511242 Website link: https://maintainable.fm/episodes/ben-orenstein-someday-well-go-clean-that-up-doesnt-work-_fGCpf6F SUSAN RICE ON COACHING FOR LEADERS The Coaching For Leaders podcast featured Susan Rice with host Dave Stachowiak. From the time she was seven, Susan would hear her parents fighting loudly and violently when she was trying to sleep at night. When the fighting got scary and out of control, Susan would step in. Sometimes that meant talking them down and sometimes that meant separating them. The mediation she did with her parents taught her how to interact with parties who were intractably opposed. This developed in her a lack of discomfort with conflict, disagreement, and argument. She said that this helped her to be willing to stand up and not be conflict-averse. This reminded me of the Buster Benson episode of Lead From The Heart I summarized in my last article. Dave asked Susan about a section of her book Tough Love in which she described some feedback she received from former congressman Howard Wolpe when she was Assistant Secretary of State. He warned her bluntly that she would fail as Assistant Secretary if she did not correct course and she came to agree with that. She was only thirty-two at the time and had never held a position like this before. In 1998, six months into her tenure, a series of crises hit. Africa's "first world war" broke out and, then in August of 1998, Al Qaida attacked the American embassies in Kenya and Tanzania, killing twelve Americans and over two hundred Kenyans and Tanzanians. This was both a horrific loss and a policy blow for those who were working on Africa at the time. Rather than addressing the pain they were all feeling head on, her approach to dealing with it was to charge through it as she did her parent's divorce. This wasn't a leadership style that would work in that context and Howard Wolpe gave her the tough love she needed at the time. Over the Christmas holiday, she reflected on what he had told her and realized that he was right. She had to be more patient. She had to be more respectful and solicitous of other people's views and perspectives. Dave asked what she did first to make this change in her leadership style. Susan says she started by being more humble. She brought people into decision-making even if their recommendations were not ones that she ultimately accepted. She says, "You can get a long way leading a team, even if many members of the team don't actually agree with the direction you're steering towards, if they feel that their advice, perspective, recommendations have truly been heard and appreciated." Dave asked how she ensures in meetings between high ranking officials that everyone is genuinely heard even when she doesn't agree with everything they are saying. She says it is not just what happens when you're sitting around the meeting table. It comes down to the preparations going into the discussion: the quality of the paper that lays out the issues and the actions and the coherence of the agenda. Managing the meeting, though, is the hardest part. You have to make sure the options are given due consideration and everybody gets a chance to express their judgment. Apple Podcasts link: https://podcasts.apple.com/us/podcast/456-how-to-be-diplomatic-with-susan-rice/id458827716?i=1000466472793 Website link: https://coachingforleaders.com/podcast/be-diplomatic-susan-rice/ COURTLAND ALLEN ON SOFTWARE ENGINEERING UNLOCKED The Software Engineering Unlocked podcast featured Courtland Allen, founder of the Indie Hackers podcast and community with host Dr. Michaela Greiler. Michaela asked Courtland what was different about Indie Hackers compared to the earlier startups he had founded that made for its success. He said that for Indie Hackers, his notion of a business idea changed. Back in 2009, if you asked him about a business idea, he would have described a product idea and wouldn't have been able to say much about how to get the product in customer's hands, how much to charge for it, or even who the c

  2. 03/02/2020

    A Bucket Full Of Crabs

    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-relationshi

  3. 02/17/2020

    Waiting For The Dinosaurs To Leave

    Dimitar Karaivanov on Agile Atelier, Claire Lew on The Product Experience, Eric Willeke on Agile Amped, Mike Bugembe on The Product Experience, Colleen Esposito on Hired Thought 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 17, 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. DIMITAR KARAIVANOV ON AGILE ATELIER The Agile Atelier podcast featured Dimitar Karaivanov with host Rahul Bhattacharya. Dimitar is an expert on scaling Kanban. Dimitar thinks of Agile as a company sport rather than a team sport. At the team level, scaling is horizontal. The more interesting kind of scaling to Dimitar is vertical scaling. If you have a hundred or a thousand teams, the real challenge is the coordination piece on top of those teams and the strategic piece on top of that. If you don't have an optimized coordination layer that reduces the number of things the organization is working on, your organization is spread too thin. He explained the importance of teamwork and coordination using the metaphor of a band of musicians. Scaling Kanban starts with a single team. What Dimitar likes about Kanban is that if you follow the basic rules, it always results in some kind of improvement. Next, we want to connect the teams to a management layer that performs the coordination activities. People often perceive Kanban as a visual board with some sticky notes on it. Actually, if you go horizontally, then vertically, it is more of an instrumentation facility for your organization. Like a performance profiling tool, you connect Kanban to your organization and it provides entry points with time stamps and starts collecting data. With this profiler, you can dig in and find out what the slowest part of your organization is. Rahul asked about roles in scaled Kanban. Dimitar says there are only two specialized roles called out in Kanban: the service delivery manager and the service request manager. Because one of the principles of Kanban is to start where you are, you do not have to change a lot about roles when you start using Kanban. The service request manager role just means having someone who is responsible for requesting work, such as product manager. The service delivery manager just needs to be someone who is responsible for ensuring the work gets done. This could be a Scrum Master or maybe just a team lead. If the organization is adopting Kanban as a whole, you will need someone on the strategic level that is connected to the Kanban system and has a say in what gets done and when. Rahul asked about failures Dimitar has seen. Dimitar has seen problems in which training just the teams and expecting this to lead to business agility failed. Another route to failure was relying on tools to do all of the work of creating agility. He says you need people with personal agility. You need to find these people or stimulate your existing people to grow themselves so that they become agile in their mindset. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/episode-19-scaling-kanban-with-dimitar-karaivanov/id1459098259?i=1000464007645 Website link: https://rahul-bhattacharya.com/2020/01/29/episode-19-scaling-kanban-with-dimitar-karaivanov/ CLAIRE LEW ON THE PRODUCT EXPERIENCE The Product Experience featured Claire Lew with hosts Randy Silver and Lily Smith. Randy started by asking Claire if she's ever accidentally been anybody's worst boss. This was the question that Claire herself had asked at the Business of Software conference in her talk, "The Accidental Bad Manager." She says that, based on her data, the answer is "probably." She says that 85% of the time companies are choosing the wrong manager or promoting the wrong people into the role. They're choosing for a manager those individuals who were showing excellent skills and outcomes as an individual contributor, but those skills don't transfer over when they become a manager. Claire cited a Gallup study that found that there are five to seven traits that characterize the best managers and, yet, only one in ten managers possesses these traits inherently. Claire created Know Your Team because she herself had a really bad boss and he had no idea. The first thing that made this boss so bad was that he didn't follow through on his commitments. Looking back, she sees this as a classic case of failing to build trust because he made promises and didn't deliver. When leaders think about trust, oftentimes their minds go to likability, team-building, and images of trust falls and happy hours. None of those things have to do with real trust, which is the ability to show people that you will do what you say. A second thing that made this boss so bad was that he lacked an ability to communicate and share vision. This is a common problem because most of us get the definition of vision wrong. Claire says that vision is not what you do and it's not how you do it; it is where you're going. Vision is the strongest motivating force in a team and the most clarifying force for decision-making. Neither motivation nor decision-making were tenable under her bad boss because the vision wasn't clear. Lily asked how Claire designed Know Your Team. Claire says that the number of conceptions of leadership is as large as the number of people who have attempted to define the term. She believes the reason there are so many definitions of leadership and the reason that there is no agreed upon best approach to leadership is because, most of the time, the right thing to do is highly dependent on many factors: your own disposition, the team's disposition, team dynamics, the market, the task at hand, etc. So the best thing to do is to compile as much data as possible and determine the two or three best things to focus on. The best managers, she says, tend to focus on three things. First is trust. Second is honesty. Third is being able to create context in a team, that is, being able to understand and share where you are trying to go and what progress is being made along the way. Lily asked how these areas of focus compare with the traits in the Gallup study Claire mentioned earlier. Claire says that the Gallup study identified temperamental characteristics like positive thinking, good judgment, and empathy, and Claire's areas of focus represent the skills you can build and the things that you can do to make your team run better. But there are connections between the Gallup characteristics and Claire's areas of focus: you need empathy to build trust, and you need good judgement to create context. Randy asks why managers are the last to know that they are bad at this. Claire says the psychological reason is that we create a narrative for ourselves that fits with a coherent positive self-image. More practically, we are complicit in being the last to know for several reasons, including the fact that we don't create an environment for people to tell us. As a result, people don't speak up in the workplace and this is because of fear and a sense of futility; they believe that nothing would change. To resolve this, we need to be able to ask for feedback in the right way and we have to act on that feedback. To ask for feedback in the right way, we need to be vulnerable. Tell people you are struggling. When you go first and you come from a place of vulnerability, you give the other person permission to be vulnerable themselves and you defuse the element of fear. You also need to be specific. You can't ask, "How's it going?" Instead, ask something like, "What is one thing that we could have done better in the past quarter?" or "When is the last time you felt frustrated with your work?" or "Have you observed any micro-managing tendencies from me in the past few months?" or "Have we been all talk and no action on anything lately?" Next, you need to act on the feedback. If asking questions is all about defusing fear, acting on the feedback is all about defusing futility. When you show people that their feedback is not in vain, that helps people to speak up. Some people think this means having to implement every single piece of feedback. Not at all. Acting on feedback can be as simple as thanking someone for their feedback or explaining why you are not doing something. As leaders, we often explain why we are doing something but we forget to share why we are not doing something. The best way to modulate and calibrate the other person's expectations so that they don't think speaking up is futile is to say, "You're not likely to see a ton of progress on this in the beginning but I will give you regular updates on the progress." And then make sure you give those updates. Another best practice for creating an environment where you are not the last to know is to ask people what their preferences are around feedback. They may want an email, a slack message, or a phone call. Another preference we often forget to ask about is how quickly to give feedback. They may want it right away, or scheduled for the next day or the next week. A third preference is their orientation toward conflict. Do they believe that conflict is healthy and necessary to be productive in a team or do they much prefer a low-conflict environment? A manager should not just be looking to be a great manager or leader but to be the best manager or leader for each particular person and to know that this is going to require customizing your approach to every individual. Randy asked what lessons people can learn about leadership if they don

  4. 02/03/2020

    100 Steps To Product Delivery Nirvana

    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

  5. 01/20/2020

    An Honest Look In The Mirror

    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 qma

  6. 01/06/2020

    A Cumulative Pile of Successes

    Neil Pasricha on Coaching For Leaders, Corey Quinn on On Call Nightmares, 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 four 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 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

  7. 12/23/2019

    Sitting In A Room Full Of Mousetraps

    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

  8. 12/09/2019

    Patience and Brainpower

    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,

See All (33)

About

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 summaries 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.

Information