23. Lighting Up the Brain and Joining a Gym

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 [email protected]. 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 [email protected]. 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: https://www.thekguy.com/ Intro/outro music: "waste time" by Vincent Augustus