Podcasts about links ask

Optimal performance in sports requires careful attention to nutrition. Why should optimal performance on grueling tests be any different?  Amy and Mike invited dietitian nutritionist Hannah Byrne to recommend what to eat and not eat for test day. What are five things you will learn in this episode? What dietary considerations are important in the weeks leading up to a big test? What should test takers eat on the morning of a big test? How can diet and nutrition help test takers to excel? What snacks should test takers either add or avoid? Is caffeine a good or bad idea on test day? MEET OUR GUEST Hannah Byrne is a Registered Dietitian Nutritionist. She completed her Bachelor of Science in Dietetics with a specialization in Health Promotion at Michigan State University and her Master of Science in Dietetics at D'Youville College.  Hannah is the owner of Hannah Byrne Nutrition, where she meets with clients individually to counsel them on medical nutrition therapy. The goal of her practice is to help clients achieve their health and wellness goals while also realizing that eating healthy is not only optimal for living their best life, but also can be really simple and fun. Find Hannah at https://www.hannahbyrnenutrition.com/. LINKS Ask the NTPA Experts: What to Eat on Test Day? Brain Food: Go Nuts for High Scores Build Your Willpower to Improve Your Scores RELATED EPISODES HELPING TEENS GET THE SLEEP THEY NEED USING MINDFULNESS FOR TEST AND SCHOOL SUCCESS HOW TEST PREP AND SPORTS ARE SIMILAR ABOUT THIS PODCAST Tests and the Rest is THE college admissions industry podcast. Explore all of our episodes on the show page.

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

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

In the world of specialty coffee we still have a lot of work to do when it comes to creating a context where women are given the same bias-free consideration as their male counterparts. As a result, having the confidence necessary to thrive and advance in the cafe can be hard to come by. In today's episode we will be exploring how women can cultivate confidence in business and how those who run businesses can empower the women in their organizations. To that end I am so excited to welcome to the show, Katherine Knapke!  Katherine Knapke is the Chief Operating Officer at the American Negotiation Institute. Katherine is passionate about using her experience as a Psychiatric Nurse trained in Therapeutic Crisis Intervention (TCI) and as a Certified Mediator to address the psychological, emotional, and societal concerns that impact women in the workplace. Her goal is to use her expertise to help women develop the skills and confidence they need to get more of what they want and deserve in the workplace.  Katherine also uses her healthcare experience to lead our work within hospital systems and in public health departments. Lives depend on the crucial conversations that happen in healthcare every day. She helps healthcare professionals manage conflict in order to improve communication, persuasion, and patient care.  Katherine is the host of our newest women’s focused negotiation podcast, Ask With Confidence, designed to empower women and to help them gain the confidence they need when engaging in difficult conversations. Some of what we will cover: The power of asking Why women don't need to be like men Structuring meetings for inclusion Competence vs confidence Overcoming over-apologizing A frame-work for negotiation and difficult conversations   Links: Ask with Confidence Podcast Negotiate Anything Guides IWCA #Shestheroaster   Related Episodes: 131 : The Strong Women of Coffee w/ Laura Gonzalez 125 : Confidence in Conflict w/ Kwame Christian 104 : How to Deliver Difficult Feedback w/ Tom Henschel 052 : Solving Coworker Conflict w/ Tom Henschel 014 : A Barista's Guide to Advancing 015 : What to do if you Don't Advance w/ Anne Nylander Shift Break: Career Advice from Joe Marocco   The BEST in commercial coffee equipment www.prima-coffee.com/keys   Want the best plant based beverage for your coffee drinks?  www.pacificfoods.com/food-service    

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

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

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

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

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

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

Episode 38 is another conversation focusing on homeschooling, this time with curator of Ask a Homeschool Mom, Kari Vanhoozer. We had a fun discussion about her choice to homeschool - or, rather, unschool - and how that works into their families life before talking about her website and the importance of having resources that can help homeschool parents navigate the legal systems, and give advice on developing a homeschool program. The Links Ask a Homeschool Mom Ask a Homeschool Mom on Pinterest Music from the Show: Nick Piccone - You's and I's Creedence Clearwater Revival - It Came Out of the Sky Shocking Blue - Acka Raga Elmer Gantry's Velvet Opera - Ride a Hustler's Dream If you're enjoying the show, you can show your support by becoming a patron on Patreon and get access to bonus shows, seeds, and merchandise (and if you don't like Patreon, you can sign up to support the show on BitBacker!) You can also do your Amazon shopping through our Amazon link. Please subscribe and leave a review on the Apple iTunes Store (or on any podcatcher, though iTunes is the most important). You can also like us on facebook and share the show from there. We are on Twitter as @HSandHSpod, and sometimes even on Instagram, too. And don't forget to join the The Homesteaded Homeschool Forum to be a part of the conversation.And don't forget to pay Nicky P. a visit either at Sounds Like Liberty, or on bandcamp, and pick up a subscription to the Freedom Song 365 project. Link to show notes for episode 37 with Catherine Bleish.

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

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

Karen Catlin on Retaining WIT, Jonathan Cutrell on Maintainable, Dr. Aneika L. Simmons on Hanselminutes, Sarah Wells on Engineering Culture by InfoQ, and Dave Thomas and Andy Hunt on Tech Done Right by Table XI. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. And, if you haven’t done it already, don’t forget to hit the subscribe button, and if you like the show, please tell a friend or co-worker who might be interested. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting September 16, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. KAREN CATLIN ON RETAINING WIT The Retaining WIT podcast featured Karen Catlin with hosts Jossie Haines and Jordanna Kwok. Karen, who is a leadership coach and diversity advocate, got interested in tech when she saw an issue of Money magazine with a cover story about successful women with computer science backgrounds and her father pointed out the connection between a career in software and Karen’s love of crafting, puzzle-solving, and mathematics. She started her career in 1985, which was a peak year for women in Computer Science. In that year, 37% of the Computer Science degrees went to women. It dropped to a low of 17% but has started to go up again in recent years. Karen started a coaching practice because she wanted to help women who wanted to grow their careers and stay in tech. She soon realized that, even if she could be the most amazing coach on the planet, her clients would still be facing an uphill battle because they were working in companies that were not the meritocracies they claimed to be. This led Karen to explore an idea: “Instead of trying to fix the women, let’s start fixing the men.” She says there is a role for every man who is working in tech to create a more inclusive workplace on his work team and at his company. Karen says that mentoring programs are a great opportunity for people to pass on advice to someone who hasn’t had the same amount of experience, but there is a trap: studies have shown that most of us mentor people who remind us of our younger self. Karen’s advice is, if you’re doing mentoring, mentor someone who doesn’t look like you. Don’t have a mini-me protégé. Another piece of advice from Karen is to pay attention in meetings. Look out for interruptions. There is research showing that men interrupt women much more than the reverse and that women who are getting interrupted tend to step back and not participate in the rest of the meeting or future meetings. So, when you see people getting interrupted, say something like, “Jordanna was making a great point. I’d like to hear more about that.” Another thing to watch for is what Karen calls “bro-propriation”: a woman says something in a meeting that falls flat and then, later on in the same meeting, a man says the same thing and gets all the credit. An ally can say something like, “Hey, I see that you agree with the point that May was making earlier.” Discussing hiring, Karen says she used to grab old job descriptions and add new requirements to them, reasoning that all the old requirements are still relevant. She says that you should instead try to get your job description down to just five requirements. Research has shown that women apply for jobs when they have all the skills listed in the job description while men apply even if they have little more than half of the listed skills. Karen also says to have objective criteria to use for every single candidate. Ideally, use the same interview questions. She told a story about moving to Silicon Valley with her partner Tim and applying to work at the same company in the same software engineering role. The two of them had interviews the same day. Driving home at the end of the day, Tim related to Karen that his interviews were among the most difficult he had ever had while her own experience was that the interviews had all been easy. The interviewers had dumbed down the questions when interviewing her. They were both offered jobs, but she decided not to take her offer because the company didn’t respect her enough to ask her the same difficult questions they had asked men applying for the same position. She then spoke about the importance of public speaking in gaining visibility and how it can help with both recruiting in the case of giving external talks and with getting your ideas considered.  Apple Podcasts link: https://podcasts.apple.com/ca/podcast/karen-catlin-on-being-better-allies/id1458996260?i=1000440710563 Website link: https://www.retainingwit.com/karen-catlin JONATHAN CUTRELL ON MAINTAINABLE The Maintainable podcast featured Jonathan Cutrell with host Robby Russell. Jonathan is the host of the Developer Tea podcast and is a senior engineer at Clearbit. Robby asked Jonathan what he thinks are the characteristics of a healthy and maintainable codebase. Jonathan says testing and having a consistent way of testing is critical to maintainability. He also looks at the size of each concept the code expresses to see if it can fit in a person’s head. Robby asked how Jonathan’s teams have achieved consistent testing. Jonathan says that human beings are pretty good at being about 90% consistent, which is almost worse than being 0% consistent. He says to take the load off the human engineer and, for those times when you still need to put the load on them, have a way to proceduralize things such as by having a checklist or template. Robby asked what Jonathan thinks developers often get wrong when they talk about technical debt. Jonathan says that debt is an easy term to throw around because, in the financial sense, it is a very clear concept. Technical debt does not have so clear a definition. You need to evaluate what your team cares about and what has been costly from a business perspective. Some things that we may think are debt are just emotionally difficult to accept: code that we wish was different but isn’t actually causing any real problems or even forecasted to cause problems. One factor that Jonathan thinks should be consistently considered technical debt is code that is staying around but for which you don’t have any kind of validation.  I liked Jonathan’s metaphor for attempting to refactor code that is not under a lot of churn. Picking up code that isn’t changing much and improving its design, he says is like paying off low-interest mortgage debt. There are probably better places to expend our effort. Developers tend to treat decisions around technical debt like one would treat the decision to clean up your house. You have the sense of ownership over your home and, regardless of whether there is risk of future problems, we feel the need to clean things up. They talked about why Jonathan started the Developer Tea podcast. Jonathan wanted a podcast that he could listen to on an afternoon walk for five to ten minutes and learn something new. Most podcasts at the time were much longer and more entertainment-driven, and he wanted something that focused on the more human aspects of the job in a short, inspirational form. He says that the podcast has been one of the most rewarding things he has done in his career. The most rewarding experiences have been when people send him emails about how an episode or series of episodes have shifted the way they think about a topic or even about how they think about their career. They talked about whether there is a correlation between healthy code and healthy teams. Jonathan says there is data around teams in general that says teams that good relationships with their manager and the people they work with have the highest performance and the lowest turnover. These good team dynamics have visible effects on the code. Strong teams, Jonathan says, eradicate fear. These fears are things like fearing that someone is going to judge you poorly when they look at your code. Second, the best teams also know how to come up with the best ideas, which involves one or more team members being able to give up their own idea without attaching a sense of failure to letting that idea go. Third, members of strong teams recognize the humanity of everyone on their team. Robby asked what developers get wrong when evaluating their peers. Jonathan says that people, in general, tend to see everyone around them as inadequate as a way to containerize the rest of the world. This bias helps us to make decisions without being riddled with anxiety about them. The downside of this shows up when we are tasked with evaluating another person. This feeling that everyone else is inadequate combines in a bad way with our natural loss aversion when we try to make sense of things. Most failures are the result of factors that could not be controlled or predicted. With hindsight, when a project is late, we try to think of why it was late and we often come up with a reason, rightly or wrongly. We don’t often come to the conclusion that the project failed because something random happened. As a result, performance reviews tend towards the negative side unless we actively bias away from that. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/jonathan-cutrell-healthy-teams-know-how-to-eradicate-fear/id1459893010?i=1000447238745 Website link: https://maintainable.fm/episodes/jonathan-cutrell-healthy-teams-know-how-to-eradicate-fear-LgRTt32R DR. ANEIKA L. SIMMONS ON HANSELMINUTES The Hanselminutes podcast featured Dr. Aneika L. Simmons with host Scott Hanselman. Scott asked Aneika about the talk she gave with her husband Anjuan, “Managing The Burnout Burndown” at the Lead Dev conference: https://www.youtube.com/watch?v=e2dgOfedI3A. She talked about burnout having multiple dimensions including emotional exhaustion and depersonalization. When you are burned out, the people you work with start to lose, in your eyes, their personhood. Scott asked about how having a culture that depersonalized employees, such as by referring to them as “resources”, might lead to burnout. Aneika talked about how having a culture that values the highly-engaged software developer counter-intuitively increases rather than decreases burnout. She talked about managing burnout with the help of your relationships. When Aneika is looking burned out, Anjuan will often say, “Aneika, let’s go for a walk.” She talked about the American notion of the “protestant work ethic” and how the work itself is valued and makes the worker feel important and gives them a sense of meaning. Those that are not working are made to feel like they are not contributing. Scott connected this to how many Americans do not take all of their vacation days. Aneika talked about the difficulty of achieving work-life balance when pleasing your boss means disappointing your family and vice versa and she described how stress is the cause of many illnesses, telling her own story about getting a sore jaw while working on her dissertation because the stress caused her to start grinding her teeth. Aneika suggested building relationships with your boss and your team so that they see you as a person and not just as a contributor. When they see you as a person, they are less likely to attempt to make you feel small when you need to take time for yourself. Here's Aneika on the relationship between engagement and burnout. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/managing-the-burnout-burndown-with-dr-aneika-simmons/id117488860?i=1000447003518 Website link: https://hanselminutes.simplecast.com/episodes/managing-the-burnout-burndown-with-dr-aneika-simmons-1caMsclq SARAH WELLS ON ENGINEERING CULTURE BY INFOQ The Engineering Culture by InfoQ podcast featured Sarah Wells with host Shane Hastie. Sarah is the technical director of operations and reliability at The Financial Times. When Sarah joined FT in 2011, the company was full of smart people, but they were hampered by a frustrating set of processes. During the last eight years, they adopted a DevOps culture with a focus on automation. When she joined, it took an average of 120 days to provision a new server. They stopped tracking the improvement when they got it down to minutes. They moved from 12 releases a year to many thousand releases a year. This required pushing decision-making down to the individuals making the changes. Shane asked about how to achieve a culture of safety and experimentation. Sarah says it has to come down from the top. You cannot have a CIO or CTO is saying, “What went wrong? Who did this?” You optimize for the speed of release and for speed of fixing. You do incident reviews, but their goal is to improve things for next time, not lay blame. If you drop a database in production as a developer, that is not your fault. The fault is that it is too easy to do that. Shane asked what a culture of experimentation looks like at “the coal face.” Sarah referenced Linda Rising in saying that it is not an experiment if there is not a hypothesis and if it can’t fail. As soon as something costs a certain amount of money, very few organizations are willing to write it off, so if you’re going to experiment, it has to be something cheap and quick. Sarah gave an example of an experiment to test a design change in which they would show the star-rating on the list of film reviews. The thinking was that this would increase engagement. The experiment showed that engagement went down instead because people were less likely to click to see the full review once they had the star-rating. Shane asked about how Sarah limits the blast radius of changes. Sarah says that by releasing small amounts of code frequently and having an architecture like micro-services to keep components extremely decoupled, you are better able to understand the code you are releasing and the change is localized and less likely to affect distant parts of the product. You can also design your website to have graceful degradation when a particular service is not returning results. Shane asked about Sarah’s preference to buy rather than build. Sarah referenced Simon Wardley’s value-chain mapping and establishing the core thing a business does. For FT, the core business is news, so something like doing their own container orchestration is not part of that. Originally, they did their own container orchestration, but once Kubernetes was available, they moved to it. In discussing the sunk cost fallacy, Sarah says you always have to fight to invest in the technical stuff, so you need a good relationship between the tech leads and the product people to explain the benefits of particular technical decisions. You also need to accept that things change and you won’t always get it right. The flip side of moving fast is that sometimes you get it wrong. She related a quote from Jeff Bezos in a letter to shareholders about one-way door and two-way door decisions. For decisions that are likely a one-way door, invest time in getting them right, but for most decisions, you should just decide, commit, and revisit. Shane asked how the listeners who are working on monoliths that release once a month can get to where FT is at today. Sarah says that you need a continuous delivery pipeline so it takes no time at all to get a release out. The second thing is architectural changes. Get to zero-downtime deployments. The cultural aspects are things like process. Reduce anything that requires permission from an external team. It has to be possible for a team to just get going. She referenced Accelerate by Forsgren about the research that says not to have change approval boards. Architects get embedded in the individual teams instead. You want your engineers to be T-shaped, having one specialty but also having some skill in all areas. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/sarah-wells-on-fts-transition-to-devops/id1161431874?i=1000446732957 Website link: https://soundcloud.com/infoq-engineering-culture/sarah-wells-on-fts-transition-to-devops DAVE THOMAS AND ANDY HUNT ON TECH DONE RIGHT The Tech Done Right podcast featured Dave Thomas and Andy Hunt with host Noel Rappin. I realize that this is the third time in as many weeks that I have included a podcast episode featuring Dave and Andy talking about the 20th anniversary of The Pragmatic Programmer, but they keep saying different and interesting things on each podcast they visit that I keep wanting to share it. In this podcast, Dave described what being pragmatic means to him. He says that being pragmatic means doing what works, but nobody knows what works. The cool thing about software, which is also the scary thing about software, is that we are constantly reinventing the entire field. Every project is new: it has new circumstances, new technologies, and new requirements. When you don't know what to do, being pragmatic means exploring as much as you can to find out what works, having in place a system of feedback to tell you whether it is working or not, and taking steps that are reversible so that, if you make a mistake, you can go back and fix it. This, Dave says, is the essence of the book. Noel added a fourth variable, the team, that is different every time, and asked what the pragmatic approach is for how a team works. Dave says that a team is a voluntary collection of individuals. You don’t have a team that you put people into; you start with a group of people and try to turn them into a team. The book dedicates a chapter to teams that echos the previous chapters on individuals because teams need to know all the things that individuals need to know: they need to realize that they are going to make mistakes, they need to figure out when they’ve made a mistake, and they need to know how to fix those mistakes and minimize them in the future. As a programmer, your job is not to write perfect code; your job is to create something that does what the customer wants. If there are bugs along the way, that is not an exception; it just the way it is. The same applies to teams. When teams adopt that approach, they lose the incentive to blame people for things and they take on collective ownership. Andy says that the one thing that is unique to teams is an underlying trust of each other member of the team. You are much better off with relatively small, stable teams. Every time you add someone to or remove someone from a team, it is a new team and you need to start over building relationships, building trust, and learning to work with each other. Noel asked how they would compare The Pragmatic Programmer with the Agile Manifesto since they were involved in the creation of both. Dave suggested thinking of Agile methodologies like XP as a roadmap and The Pragmatic Programmer as your car. Noel said that, in re-reading The Pragmatic Programmer, he was struck by the emphasis on taking small steps and “not getting in front of your headlights”. Andy says that is critical idea because we fall into the trap of taking on too much at once all the time. Small steps, Dave added, also mean you can more easily undo and you are less likely to fall victim to the sunk cost fallacy because your sunk costs are smaller. Noel asked if the way in which developers learn has changed in the last twenty years. In reference to books versus StackOverflow searches and watching videos, Dave made the point that the distinguishing aspect of a book is that the content is curated; putting it together was difficult; it took a long time for the author to organize their thinking to make it clear and approachable and to produce something authoritative and easy to read as a whole. Noel asked Dave about the pragmatic value of automated testing. Dave says that when he gets too comfortable doing something, he tries to stop using it so that he doesn’t get stuck in a rut and so that he doesn’t start to believe something religiously simply because he has been doing it a long time. He had been telling people for years that it is good to test and he had never done the experiment of not testing. He decided not to test for a period and was surprised by the result. He kept an eye on bug rates and it was just as buggy as ever, his productivity went up a little bit, and his designs were just as flexible as before. His explanation is that, having done the requisite ten thousand hours, it is now so ingrained that he doesn’t have to test to get the benefits of testing. He still feels that tests are useful when working with others and as a regression barrier. He sees his experiment with not testing as another example that nothing is sacred: if you’re truly being pragmatic, you should always be experimenting. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/episode-68-pragmatic-programmer-at-20-dave-thomas-andy/id1195695341?i=1000446898661 Website link: https://www.techdoneright.io/68 LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website:

Martin Thompson on Arrested DevOps, Dr. Carola Lilienthal on Legacy Code Rocks, Jeff Gothelf on Agile Atelier, Safi Bahcall on Coaching For Leaders, and Mike Burrows on A Geek Leader.  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. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting August 19, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. MARTIN THOMPSON ON ARRESTED DEVOPS The Arrested DevOps podcast featured Martin Thompson with host Jessica Kerr. Martin and Jessica talked about the parallels between optimizing the performance of software systems and doing the same for human systems. Using ideas from queuing theory, they discussed the notion of adding small amounts of slack to a system to make it drastically more responsive. Martin connected Amdahl’s Law to the more general Universal Scalability Law, which is more comprehensive because it takes into account coherence cost, which is the time needed to reach agreement between parties working together. He added that Brook’s Law from The Mythical Man Month is the Universal Scalability Law by a different name. They talked about the difference between parallelism and concurrency. Parallelism, Martin says, is doing multiple things at the same time. Concurrency means dealing with multiple things at the same time, a definition Martin says he stole from Rob Pike. He further decomposed the universal scalability law into its parameters. One parameter represents whether you can subdivide the work (the contention penalty) and the other represents the time to reach agreement (the coherence penalty). If your team can reach agreement faster, they can get better throughput because they can have more parallelism with less concurrency. They got into a discussion of the importance of feedback in information theory. Sending information and not confirming reception is a naïve approach and this has been understood for a long time and yet software is still built that ignores this. Two phase commit is an example. If you study the two phase commit protocol in any detail, Martin says, you realize it is fundamentally broken, yet corporations don’t want to say that. They talked about how to design distributed applications in the presence of partial failures. Martin says to make your communications idempotent, give each message a sequence number, and use this sequence number to identify and ignore replayed messages. According to Martin, designing your systems this way is just good hygiene and professionalism. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/protocols-and-sympathy-with-martin-thompson/id773888088?i=1000444947737 Website link: https://www.arresteddevops.com/protocols/ DR. CAROLA LILIENTHAL ON LEGACY CODE ROCKS The Legacy Code Rocks podcast featuring Dr. Carola Lilienthal with hosts Andrea Goulet and Scott Ford. They talked about Domain-Driven Design. Carola said her company read Eric Evans’ book and immediately took to it. Talking to users, writing software in the user's domain, and using a common vocabulary fit with what they were already doing so they adopted it easily. They talked about Carola’s modularity maturity index. It consists of three areas of sustainability: 1) modularity, 2) hierarchy, and 3) pattern consistency.  Andrea brought up the fact that larger codebases aren’t necessarily more difficult to change as Carola found in her research. Carola says that, based on the three hundred systems she’s studied, systems under a million lines of code are often in a worse state than larger systems. Around a million lines of code, she says, something happens: either people start structuring the system and putting in guard rails that keep the product maintainable or the system doesn’t grow any more. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/sustainable-software-architecture-dr-carola-lilienthal/id1146634772?i=1000443349633 Website link: http://legacycoderocks.libsyn.com/sustainable-software-architecture-with-dr-carola-lilienthal JEFF GOTHELF ON AGILE ATELIER The Agile Atelier podcast featured Jeff Gothelf with host Rahul Bhattacharya. Rahul and Jeff talked about the intersection of Agile, Lean, and Design Thinking to find commonalities. They examined customer-centricity, measuring success, continuous testing, and the importance of having a hypothesis. Jeff had been working as a designer on waterfall projects for the first decade of his career and, on a good day, only saw 50% of his work get implemented. Ten years into his career, Jeff got exposed to Agile software development and it forced him to revisit his design process and his process for doing product development as a whole. Because Jeff was in a leadership position and had a boss that understood the new methodology, Jeff got the chance to run process experiments to learn what the best collaboration model was for him and his team. This became the basis of his book, Lean UX. Rahul asked Jeff how he would define Design Thinking. Jeff described Design Thinking as applying the designer’s toolkit to solve business problems. This includes empathizing with customers, brainstorming ideas, prototyping, testing ideas with customers, and iterating.  Rahul asked if there is a specific situation in which to apply Design Thinking. Jeff says that he has yet to find a client or an industry where customer-centricity, continuous learning, risk mitigation, experimentation, and iteration don’t make sense. Even when working with people at GE who make locomotives and working with organizations that make room-sized air conditioning units that sit on top of skyscrapers, Jeff was able to successfully introduce them to ideas like talking to customers, identifying risks, and continuously improving their product. Rahul asked how the principles of Design Thinking fit with the Agile principles. Jeff says that everybody thinks that Agile is its own thing, Design Thinking is its own thing, Lean Manufacturing and Lean Startup are their own thing. The tactical execution of those methodologies might be different, but at their core, Jeff says these methods all share the same principles.  They are all customer-centric. They all measure success as an outcome, as a change in customer behavior. They all focus on testing your ideas quickly and moving off of bad ideas quickly. And they all focus on continuously improving and iterating the thing you are making as you continue to invest in it. They then got into a discussion about the importance of measuring the impact on the user of the product you are building. Jeff says that, unfortunately, shipping the thing is still one of the major definitions of success for most organizations. But in a world of continuous software when you can push a software update five times a minute like Amazon does, delivering the thing is a non-event and it should be a non-event. We shouldn’t celebrate it. What we should celebrate is the change in customer behavior that tells us that we’ve delivered value. These are things like showing up at the website, engaging with the app, buying the product, telling your friends, whatever it is we care about for our product. This line of thought led to the quote above. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/episode-11-intersection-agile-lean-design-thinking/id1459098259?i=1000445718430 Website link: https://rahul-bhattacharya.com/2019/07/30/episode-11-the-intersection-of-agile-lean-and-design-thinking-with-jeff-gothelf/ SAFI BAHCALL ON COACHING FOR LEADERS The Coaching For Leaders podcast featured Safi Bahcall (author of the book Loonshots) with host Dave Stachowiak. They talked about what science has to say about the best ways to nurture new ideas. They started out with a discussion of children’s books and Safi’s first example of a loonshot was Dr. Seuss. He had just been rejected by every publisher he took his first story to when he ran into a friend in the street. This friend asked Dr. Seuss about what he had under his arm and when he found out it was a manuscript for a children’s story that Dr. Seuss was taking home to burn, the friend revealed that he had just taken a job at a publisher across the street and asked Dr. Seuss if he would like to come into the publisher’s office. The Cat In The Hat was born. Safi used the story of the moon landing as an illustration of the difference between a moonshot and a loonshot. A moonshot was Kennedy’s speech announcing that the United States would put a man on the moon by the end of the decade. A loonshot was forty years earlier when Robert Goddard suggested getting to the moon with liquid-fueled jet propulsion and was ridiculed by many, including the New York Times. The reason it is important to understand the difference is because Goddard’s ideas, though neglected by the Americans, were embraced by Nazi Germany. German scientists used Goddard’s ideas to build jet engines and planes that flew 100 mph faster than any Allied plane. The mistake of neglecting Goddard’s ideas was fatal. Companies often ask Safi how they can innovate and create new products while continuing to keep their original product or service competitive. He thinks about these situations using three metaphors: the ice cube, garden hoe, and heart. He starts by thinking about the artists who create new product ideas and soldiers to execute on turning those ideas into real products in the marketplace. The ice cube is a rigid phase that suits the soldiers and a melted ice cube is a fluid phase that suits the artists. Understanding the problem starts with the ‘beautiful baby’ problem. The artist sees their new idea as a beautiful baby. The soldiers look at the same thing and see a shriveled up raisin. They’re both right. The garden hoe comes from understanding that the failure point in most innovation is rarely in the supply of new ideas, it is in the transfer between artists and soldiers. Great leaders are those who think of themselves as gardeners managing the transfer between the artists and soldiers. The heart is about loving your artists and soldiers equally. When we lionize the artists as the media often do, we demotivate the soldiers. I liked what Safi had to say about the problem with following the standard advice about active listening. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/418-the-way-to-nurture-new-ideas-with-safi-bahcall/id458827716?i=1000443895174 Website link: https://coachingforleaders.com/podcast/nurture-new-ideas-safi-bahcall/ MIKE BURROWS ON A GEEK LEADER The A Geek Leader podcast featured Mike Burrows with host John Rouda. Mike talked about his career leading up to the writing of AgendaShift. He described the goal of AgendaShift as trying to introduce agility not by prescribing a set of practices or rolling out a framework but by getting agreement on outcomes and working out different ways of achieving them in an hypothesis-driven way. He then mentioned his newer book that he was working on at the time the podcast aired and has just come out this month, Right to Left. Right to Left is about working backwards from outcomes. John asked what the shift was that led to this outcome-focused approach. Mike said that while working in the government digital space in the UK, he witnessed rapid change. Instead of one supplier creating documentation for a new system, a second supplier building it, and a third supplier supporting it, and the whole thing being an expensive mess that disappoints its end users, he says they now have a system where projects will be halted if they are not serious about engaging with users, doing user research, understanding needs, and working iteratively to deliver evolving services. He says that if it can happen in the government space, it can happen anywhere. John asked about what a new manager coming from an individual contributor role would need to learn for dealing with the people side of managing projects. Mike recommended tempering any temptation to micro-manage. On his first day taking over a management position at UBS, he had people lining up at his desk looking to be micro-managed because that is how his predecessor worked. He told them that if this is how it is going to work, it is going to make him miserable and it is going to make them miserable and he encouraged them to self-organize. Mike’s second recommendation is to learn to value and respect people who come from other disciplines than technology, as he says in the above quote. John asked Mike to describe AgendaShift. Mike says that the best two words that describe it come from Daniel Mezick: it is an engagement model. Much like Daniel’s OpenSpace Agility, AgendaShift describes how change agents can engage with their organizations. In the Lean/Agile space, pushing Agile on people is self-defeating and creates more problems than it solves. Instead, facilitate outcomes that the people of the organization can agree on and start solving problems. AgendaShift starts with discovery. There are workshop tools to creating a high-level plan. Then they use an assessment tool for identifying opportunities to increase transparency, get workloads under control, or to engage better with customers. They identify obstacles and the outcomes hiding behind those obstacles. They use a “clean language”-based game to model a landscape of obstacles and outcomes and get people to think about the journey, their priorities, and what the key landmarks along the way will be. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/agl-081-agendashift-with-mike-burrows/id1043194456?i=1000424584602 Website link:https://www.ageekleader.com/agl-081-agendashift-with-mike-burrows/ LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website:

We're discussing alternative names, pseudoscience and more in this episode! Links: Ask a mortician- https://www.youtube.com/channel/UCi5iiEyLwSLvlqnMi02u5gQ Signal Boost- https://geekandsundry.com/shows/signal-boost/ Inc. magazines article on Gravity Payments- https://www.inc.com/magazine/201511/paul-keegan/does-more-pay-mean-more-growth.html . . . . #aka #alias # name #nickname #add #adhd #medication #life #prescription #doctor #compliance #genevaconvention #art #literature #assume #blackbox #neuroscientist #mania #bipolar #trueself #risk #cure #rabies #fear #mentalillness #abstract #obsurity #love #treatment #social #bed #rot #depression #sexy #hyperbole #80s #hollywood #split #beat #crazy #media #inhibition #impulse #zombie #broadway #existential #creativity #adrenaline #evolution #rage #identity #gift #poor #society #pyramid #youtube #deathpositive #funeral #cotton #grave #secrets #grief #taboo #garyvee #manifestation #theology #ritual #science #ghosts #superman #nobel #advice HookSounds.com --- Support this podcast: https://anchor.fm/magnificent-whiskers/support

We discussed our extremely comprehensive and detailed job covering the SES NY conference. We then had a 15 minute conversation about paid links based on some recent blog posts by Googles Matt Cutts. We had a brief conversation on Ask.coms new algorithm, Edison. Followed by yellow Google ads, a Google.com update, support for sitemaps autodiscovery, the DoubleClick acquisition and much more.