Technology Leadership Podcast Review

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 [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 [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 [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 [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 [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 [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/ [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 customer was. With Indie Hackers, he was thinking about all aspects of the business. She asked whether the original Indie Hackers idea was to build a community. Courtland said that while there was no desire to do a podcast at first, he always had a plan to build a community. He had multiple phases for Indie Hackers to go through to get to where he wanted it to be. Phase one was a blog where people who wanted to earn financial and creative freedom though revenue-generating side projects could go to find interviews Courtland had done with people like themselves. He figured these blog readers would subscribe to his newsletter and from there he would build a community forum where people could help each other. Somewhere along the line, the podcast was added based on community demand. Michaela asked how Courtland managed to keep Indie Hackers successful as a business when similar communities are struggling. Courtland believes that there are a few principles behind the success of Indie Hackers. The first is that you are much more likely to generate meaningful revenue quickly if you are charging for something that each customer is willing to pay a lot of money for. Regarding building a successful community, you have to start with your marketing. A community is a chicken-and-egg problem where the whole value of a community is the people inside it, making it really hard to start from nothing. With Indie Hackers, he started with content that brought in the people who could form the community. Courtland had thousands of people coming to the website before he turned it into a community. Another example is dev.to. Its founder, Ben Halpern, spent years just growing his Twitter account, tweeting funny jokes and helpful tips for developers. When he launched his community, he was able to advertise it from his Twitter account. A second thing you need to build a community is to seed it with discussions. As Courtland also described in an episode of Software Engineering Daily that I summarized in “Lighting Up The Brain and Joining A Gym”, he started his community by having conversations with fake accounts that were secretly also himself. Ben Halpern kickstarted the dev.to community with discussions with his friends. Choice of topic is critical too. You want a topic that you can talk about forever. The dev.to community’s topic is software engineering. It is the perfect topic because lots of people are learning and trying to learn from each other and there are countless issues and frameworks to talk about. Similarly, there are countless topics and subtopics around founding companies. As Courtland also said on Software Engineering Daily, you also need to think about the timing for when people get together and the space your community takes up. If you throw a party in a small room, you only need ten people to make that party feel like a success, but if you throw it in a football stadium, you need forty thousand people for it to feel like a success. It is the same with an online community. If you constrain it by saying something like, “Our community is just one discussion thread every Sunday at 3:00pm,” then even with ten people, that community can feel like it’s thriving. He talked about how he got advertisers interested in Indie Hackers and how he eventually got Indie Hackers acquired by Stripe and now no longer spends time selling ads. Not much has changed, he says, now that he is an employee of Stripe because Indie Hackers and Stripe were aligned from the beginning. Michaela asked why he decided, despite his desire to write as little code as possible, to create custom software for the Indie Hackers forum when he could have chosen third-party forum software. Courtland said he wanted Indie Hackers to have a strong brand and it is hard to have a strong brand if the thing you’re building looks like everything else. So he put a lot of time making the community unique. He spent a lot of time on the name of the community and the design of the website, all in support of having a strong brand. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/starting-profitable-business-in-six-weeks-courtland/id1477527378?i=1000465925620 [https://podcasts.apple.com/ca/podcast/starting-profitable-business-in-six-weeks-courtland/id1477527378?i=1000465925620] Website link: https://www.software-engineering-unlocked.com/episode-12-profitable-business-courtland-allen/ [https://www.software-engineering-unlocked.com/episode-12-profitable-business-courtland-allen/] MATT STRATTON ON HIRED THOUGHT The Hired Thought podcast featured Matt Stratton with host Ben Mosior. Since his move from Chef to PagerDuty, Matt’s focus has shifted from software delivery and infrastructure code to incidents and outages. Ben brought up Matt’s talk “Fight, Flight, or Freeze — Releasing Organizational Trauma.” Matt’s motivation for creating this talk was his own treatment for PTSD and a discussion with J. Paul Reed where they kept seeing similarities between Matt’s experiences and what companies go through when they experience an incident. Trauma occurs when our response to something is ineffective. Two people can have a similar experience and it can be traumatic to one person and just a bad day for the other. We respond to perceived trauma physiologically the same way as actual trauma. Events that are reminiscent of trauma that occurred to Matt as a child trigger him to have the same physiological response today. Organizations do the same thing. An organization that has an outage that is similar to an event that happened before and, say, cost them a million dollars a minute, will react the same way. Just as an adult re-experiencing a childhood trauma because of a triggering event shouldn’t necessarily respond the same way, an organization needs to learn how to respond differently to these similar stimuli. Matt talked about the window of tolerance beyond which you become activated and have an unhealthy response. He says that it can get spiky or you can get stuck-on or stuck-off. If you are stuck-on, you have anxiety and other symptoms. If you are stuck-off, there is lethargy. In an organization, we can get into a hyper-aroused state fearing any type of change, getting into analysis paralysis, or becoming over-vigilant. None of these states are healthy and they trickle down into the emotional health of employees. The good news is there are things we can do to help the organization be better. Ben added that a lot of therapy is about building up the language to describe what is happening so that when it happens or when you are reflecting back later, you can share the experience and develop skills to lengthen your window of tolerance. Matt talked about how in cognitive behavioral therapy we try to identify when a distortion occurs, knowing that the feeling we experience is not something we can change, but our response to it can be changed. In an organization, we can do the same thing. Matt is striving to excise the word “prevention” from his vocabulary and instead become more resilient when something bad happens. For a person, this can mean that you can have something happen and then you can get back inside your window of tolerance quickly. For an organization, this means that an incident can happen and we can restore service and get on with business. We need to normalize incident response. It is not an anomaly to have an incident. The irony is that we’ve gotten worse at responding to incidents as we’ve gotten better at distributing on call. Back in his days as a sysadmin, Matt was on call constantly and incident response was business as usual. Today, if you are doing a healthy on call rotation with developers on call in their own domain, you can be on call for a year and experience just two incidents. Then, when you have an incident, you freak out. You don’t want to be trying to remember how to do incident response and you don’t want to think of the response process as an exceptional thing that we only sometimes do. Ben connected this to the book The Fifth Discipline. He says we always feel like we have to do something in response to something bad happening. The other thing the book points out is that whenever you are doing an intervention, yes, you may have short term actions that buy you time, but at all times, you need to be building capabilities. When you normalize incident response and you regularly show people what it looks like to work together in a high-pressure situation, you learn to respond to incidents in healthy ways. Matt says we need to run our failure injection exercises and game days like real incidents. This is also an opportunity to train your incident commanders. In these scenarios, we know what’s wrong and we can bail out at any time. Then, when a real incident occurs at 2:00am some morning, the people who did the exercise associate the real incident with the calm exercise they did in the office on an afternoon. Sometimes there are people who want run an exercise and not tell the incident response team what’s wrong. Matt has to explain to these people that it is not an exercise in troubleshooting or to stress test your people. You don’t need to inject stress into the people who work for you. You want to do the opposite. When we are doing incident response all the time as part of the regular cadence of work, when a real incident occurs, we will associate it with the positive physiology of our response during the exercise. That means we should treat every incident the same, even false alarms. If you get a few minutes into responding to an incident and realize it is a false alarm, finish it out as an incident. Get on the bridge and do as you would in a real incident. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/6-organizational-resilience/id1479303584?i=1000466488009 [https://podcasts.apple.com/ca/podcast/6-organizational-resilience/id1479303584?i=1000466488009] Website link: https://hiredthought.com/2020/02/24/6-organizational-resilience/ [https://hiredthought.com/2020/02/24/6-organizational-resilience/] LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com [podcast@thekguy.com]. Twitter: https://twitter.com/thekguy [https://twitter.com/thekguy] LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ [https://www.linkedin.com/in/keithmmcdonald/] Facebook: https://www.facebook.com/thekguypage [https://www.facebook.com/thekguypage] Instagram: https://www.instagram.com/the_k_guy/ [https://www.instagram.com/the_k_guy/] YouTube: https://www.youtube.com/c/TheKGuy [https://www.youtube.com/c/TheKGuy] Website:

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 [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 [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 [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 [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/ [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 [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/ [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 [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 [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 [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/ [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 [podcast@thekguy.com]. Twitter: https://twitter.com/thekguy [https://twitter.com/thekguy] LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ [https://www.linkedin.com/in/keithmmcdonald/] Facebook: https://www.facebook.com/thekguypage [https://www.facebook.com/thekguypage] Instagram: https://www.instagram.com/the_k_guy/ [https://www.instagram.com/the_k_guy/] YouTube: https://www.youtube.com/c/TheKGuy [https://www.youtube.com/c/TheKGuy] Website:

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 [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 [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/ [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’t have direct reports but need to be able to influence without power. Claire says leadership is not about your title or the number of direct reports you have. At its most core form, leadership is about modeling the behavior that you want to be true of your team. Say you are so annoyed that your entire team is always late for meetings and late on deadlines. Instead of thinking you need to speak to someone or to manage up, one effective way of exhibiting leadership is to turn to yourself and ask, “To what degree can I model the behavior I would like to be true of the team?” A second way to exhibit leadership is to consider how you, as a teammate, can create an environment for those around you to do their best work. Apple Podcasts link: Website link: ERIC WILLEKE ON AGILE AMPED The Agile Amped podcast featured Eric Willeke with host Leslie Morse. The first and most critical thing Eric learned about WIP, or work in process, is to pay attention to how WIP cascades and multiplies in an organization. A single piece of strategic WIP equals hundreds to thousands of pieces of individual WIP. A lot of good work comes from corporate strategies, but there is too much of it. Eric gave an example of a VP of product management whose work he helped visualize. They discovered that he had 38 initiatives that he had to report on for his eight teams. When you look at that kind of flood, there is little wonder that we are creating an inability to focus and limit work in process. Eric no longer looks at the executive ranks and says they are to blame. He owns up to it and says that we are all to blame. He now feels empathy for the powerlessness that senior leaders feel in spite of their titles and maybe even because of their titles since those titles carry with them a kind of trap. Eric has three strategies that he uses at organizations to reduce their WIP problems: 1) Start with alignment. Make sure people understand intent and purpose. Eliminate the excess WIP that comes from the “Am I in the right direction?” question. 2) Practice reduction in depth. According to Michael Porter, the essence of a good strategy is what you’re not doing. Help people learn what is not part of the strategy and generate focus. You may have to repeat yourself because, as Patrick Lencioni says, “You only get one message per quarter and you need to say that message hundreds of times.” 3) Create permission and safety as part of how you decentralize. When you decentralize, people need to have all the permission to take responsibility and the safety to try things, learn, and experience the associated failures that come with learning. The conversation with leaders to get them to limit WIP is difficult. The leader starts with the best of intentions. If you come in too strongly with a message that they are doing it wrong, you are saying, “You were trying really hard in the best way you know how and you failed.” They didn’t. They were not responsible, necessarily, for all of the different pieces of WIP or how it cascaded, yet they have to take responsibility for helping people set things down. One leader Eric is working with understands this and uses a quarterly message that says, “You may put things down, but you need to put them down gently.” A lot of people look at WIP and say, “We just need to throw away half the items in process.” But that hurts people, hurts initiatives, and hurts business leaders. So we need to know how to carefully set down the things we’re not going to do yet and bring everybody else along. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/too-much-wip-destroy-your-backlog/id992128516?i=1000463449566 [https://podcasts.apple.com/ca/podcast/too-much-wip-destroy-your-backlog/id992128516?i=1000463449566] Website link: https://solutionsiq.podbean.com/e/too-much-wip-destroy-your-backlog/ [https://solutionsiq.podbean.com/e/too-much-wip-destroy-your-backlog/] MIKE BUGEMBE ON THE PRODUCT EXPERIENCE The Product Experience podcast featured Mike Bugembe with hosts Randy Silver and Lily Smith. Mike is the former Chief Analytics Officer for justgiving.com, which uses machine learning to try to increase generosity in the UK. When Mike joined, the company had in excess of ten years of data on people raising and giving money for causes they cared about. They used their technology to get a signal about what people were passionate about and used this to match people to causes. They started by using a collaborative filter approach like Amazon’s “people who purchased your item also tend to purchase these items”, but charitable giving is so personal that collaborative filtering doesn’t work. Instead, using Nicholas Christakis’ research, they could see that connections between individuals could help them understand the flow of generosity and the flow of the things that are important to people. Mike says that a lot of large companies talk about the fancy things they do with machine learning and data science like Facebook’s EdgeRank or Amazon’s and Netflix’s recommendation engines, but sometimes there are use cases that are unsexy but deliver a huge amount of value. For example, when people put a fundraising page on JustGiving, they have the option to specify a target. Only 30% of fundraisers were specifying such a target, but Mike found that this behavior led to much more money raised. So Mike created a machine learning system that predicted how much a fundraiser was likely to raise and pre-populated the target field. This was a lot of work to deliver one number on a screen, but this feature delivered an additional 7% on a 400 million pound business. His approach to understanding where AI can deliver business value is to look at every business as a system of people making decisions, whether it’s marketers, product teams, or users. When you look at a product this way, the machine learning use cases float to the surface. You see where machine learning can make a decision more efficient, more automated, or more predictable. You then add a metric to each decision and see how decisions relate to each other or how they relate to key metrics you are trying to move. Your data is quite unique to your business and your product. It acts like a fingerprint. One of the risks of data science is that it is an experiment every time you do it. Even if somebody else has done it before, you have no guarantee that when you do it you will get a successful result. Product management teams that work with data science teams need to be aware that data science is not the same as delivering a feature with a software development team. It is an experiment. You have a question in mind and you have no idea whether or not the research will produce the result you’re expecting. Lily asked Mike how he recommends people hire a data scientist. Mike says he is very much against the idea of hiring a data scientist just because they have a PhD. That’s a massive risk. You could get a PhD-holding job candidate who only understands regression and is not numerate enough to try a lot of the different algorithms that data scientists use. Mike himself looks for data scientists who have real life experience. This doesn’t mean they’ve worked in a lot of companies before. It means they’ve got things that they’ve produced. You can read and study, he says, but if you’ve never done it, you won’t know the gotchas and foibles that come with working with data. Randy asked if there any guidelines or cheat sheets for people to educate themselves about bias in data collection, in algorithms, in assumptions, and in interpretation. Mike created a non-technical course for executives, product managers, and founders because they know their business better than the data scientists, in most cases. They add a layer of domain knowledge that helps reduce risk due to bias. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/cracking-data-code-mike-bugembe-on-product-experience/id1447100407?i=1000463981779 [https://podcasts.apple.com/ca/podcast/cracking-data-code-mike-bugembe-on-product-experience/id1447100407?i=1000463981779] Website link: https://www.mindtheproduct.com/cracking-the-data-code-mike-bugembe-on-the-product-experience/ [https://www.mindtheproduct.com/cracking-the-data-code-mike-bugembe-on-the-product-experience/] COLLEEN ESPOSITO ON HIRED THOUGHT The Hired Thought podcast featured Colleen Esposito with host Ben Mosior. Colleen loves helping teams get started, helping them understand that Agile is about uncovering better ways of developing software, and helping them identify what Agile means for them. She also loves helping the managers, directors, and VPs to interact better with the teams so that the teams become empowered. Colleen is a fan of invitation-based coaching and making sure the people understand the whys behind the change, what it looks like in the anticipated end state, and what steps the team may take to move towards that vision they’ve identified. Colleen says that the first thing she does when she comes into a brand new organization is she tries to understand the whys behind their decisions. “Why did you choose to use Agile?” If what she hears is, “Twice the work in half the time,” then she knows that she might have to reset expectations. Before starting an Agile adoption, Colleen gets everyone to think about the answers to some common questions like, “Why are we doing this? What’s in our way? What’s in our favor?” She says that if the leadership makes changes without involvement of the people, they are going to miss out on a valuable perspective. Colleen says that the people who hire her often think that she is going to come into their organization and make huge, sweeping changes. Instead, in the very beginning, it is often small changes like connecting what a development team is doing with what an operations team is doing. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/5-building-bridges/id1479303584?i=1000464455334 [https://podcasts.apple.com/ca/podcast/5-building-bridges/id1479303584?i=1000464455334] Website link: https://hiredthought.com/2020/02/03/5-building-bridges/ [https://hiredthought.com/2020/02/03/5-building-bridges/] LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com [podcast@thekguy.com]. Twitter: https://twitter.com/thekguy [https://twitter.com/thekguy] LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ [https://www.linkedin.com/in/keithmmcdonald/] Facebook: https://www.facebook.com/thekguypage [https://www.facebook.com/thekguypage] Instagram: https://www.instagram.com/the_k_guy/ [https://www.instagram.com/the_k_guy/] YouTube: https://www.youtube.com/c/TheKGuy [https://www.youtube.com/c/TheKGuy] Website:

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 [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 [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 [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 [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 [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 [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 [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 [https://podcasts.apple.com/ca/podcast/ryan-ripley-agile-fm/id1263932838?i=1000462512766] Website link: https://agile.fm/agilefm/ryan-ripely [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 [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 [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 [podcast@thekguy.com]. Twitter: https://twitter.com/thekguy [https://twitter.com/thekguy] LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ [https://www.linkedin.com/in/keithmmcdonald/] Facebook: https://www.facebook.com/thekguypage [https://www.facebook.com/thekguypage] Instagram: https://www.instagram.com/the_k_guy/ [https://www.instagram.com/the_k_guy/] YouTube: https://www.youtube.com/c/TheKGuy [https://www.youtube.com/c/TheKGuy] Website:

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 [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 [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/ [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 [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 [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 [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/ [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 [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/ [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 [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/ [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 [podcast@thekguy.com]. Twitter: https://twitter.com/thekguy [https://twitter.com/thekguy] LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ [https://www.linkedin.com/in/keithmmcdonald/] Facebook: https://www.facebook.com/thekguypage [https://www.facebook.com/thekguypage] Instagram: https://www.instagram.com/the_k_guy/ [https://www.instagram.com/the_k_guy/] YouTube: https://www.youtube.com/c/TheKGuy [https://www.youtube.com/c/TheKGuy] Website: