Technology Leadership Podcast Review

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

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

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

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

Will Larson on Greater Than Code, Marcus Blankenship on Software Engineering Radio, Sonal Chokshi on Software Engineering Daily, Roman Pichler on Being Human, and Dave Thomas and Andy Hunt on Hanselminutes.

I'd love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email [email protected]. And, if you haven't done it already, don't forget to hit the subscribe button.

This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting September 2, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers.

WILL LARSON ON GREATER THAN CODE

The Greater Than Code podcast featured Will Larson with hosts Jessica Kerr, Arty Starr, and Rein Henrichs. Will talked about systems thinking, specifically referencing Donella Meadows' Thinking in Systems: A Primer. As a sixteen-year-old, he was exposed to systems thinking by his economics professor father. They talked about how to bring about change in complex systems and Rein brought up Virginia Satir's change model.

They talked about various forms of dysfunction, with an example being tasks that are marked as completed by developers without first doing the work of validation. Will's own example is that executives never miss their goals; they just redefine the goals so that they hit them. There is a certain level of seniority where you can never be held accountable because you are the accountability function.

Getting back into the topic of how to change complex systems, Will referenced the book, The First 90 Days as a great explanation of the need to go slow and observe before you try to change things. He says that the "great man theory" has been out of style for decades in the study of history, but is still in style in tech as the most causal way to understand how change works and also the most comforting.

Rein talked about how the heroic individual myth is the other side of the coin to the scapegoat. Just as you pile all the blame onto the scapegoat, you pile all the credit onto the hero. He says that cultures that engage in hero myth-building are also likely to engage in scapegoating.

Will says he himself has not seen much scapegoating at the companies he works at, likely because those cultures were unwilling to hold folks accountable for their work, but he has seen the hero myth at every company he has worked. Will then spoke about the 10x engineer myth.

Will says he meets people who have been in tech for six or seven years who have the idea that they are almost done with their career. It may be due to the "senior engineer after two years" phenomenon where the career path is not well-defined and a lot of companies don't know how to take advantage of the skills of people with 15 to 20 years of experience. A second reason is that the industry is an overwhelming and draining environment and people choose to opt out of it. As a result, we have very few engineers who have been around long enough to witness the long-term consequences of their brilliant ideas.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/142-modeling-constraints-in-human-systems-with-will-larson/id1163023878?i=1000446345964

Website link: https://www.greaterthancode.com/modeling-constraints-in-human-systems

MARCUS BLANKENSHIP ON SOFTWARE ENGINEERING RADIO

The Software Engineering Radio podcast featured Marcus Blankenship with host Travis Kimmel. They talked about motivation, specifically motivation of engineering teams. Marcus says that motivation is the desire to get things done and every engineer coming out of school is motivated from day one. If you get one of these people hired onto your team and, two years later, they are demotivated, suffering from PTSD, scared to offer ideas, and figuring they are just a cog in a machine, your problem is your company or your team, not the engineer you hired.

Marcus says he is doing secret research on motivation as he is now interviewing candidates for a job and asking them why they are looking to leave their current job. Nobody says, "Pay." Often the answer is a lack of alignment with their boss or their company, resulting in the engineer losing the desire to contribute because of a relationship problem.

These engineers are not stick-in-the-muds that are angry they don't get to use COBOL anymore. Something happened where instead of having their ideas valued and heard and being part of the discussion, they somehow got disconnected from their boss.

In the seventies, Marcus says, researchers discovered a strong correlation between positive employer-employee relationships and the amount of job satisfaction, quality of work, turnover intentions, and amount of promotions. We are thirty-five years into a few thousand scientific studies that continue to prove that the relationship one has with one's supervisor matters more than any other factor when it comes to job performance and job satisfaction.

Marcus says that a supervisor's one true job is to create a trusting relationship with the people that report to you. Travis shared his own experience in having one-on-ones with his supervisors that felt to him like they were trying to artificial manufacturing a relationship because there was no indication of what the goal of the meeting was.

Marcus says that good one-on-ones are bi-directional. One-on-ones in which the boss just gets status updates from the subordinate and gives new marching orders are often dissatisfying for both parties. Another flawed kind of one-on-one is where it is all about the employee. Such one-on-ones are not effective and neither party likes these either.

Marcus suggests that we apply to our one-on-ones the same Agile thinking that we apply to our work. Every month, at one of your one-on-ones, do a retro on the one-on-one. Talk about why you are doing them, what value you're getting from them, and how to make them better.

They talked about psychological safety. Marcus says a lot of managers don't realize that they are not in a good position to measure psychological safety based on their own gut. He says tools like Claire Lew's knowyourteam.com, officevibe.com, and other anonymous survey tools can help.

When we become a manager or team lead that has you supervising or leading, we forget that we are in a position of power. Travis added that leaders need to be careful about what they say casually so that it doesn't get taken as a mandate.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/episode-374-marcus-blankenship-on-motivating-programmers/id120906714?i=1000445260176

Website link: https://www.se-radio.net/2019/07/episode-374-marcus-blankenship-on-motivating-programmers/

SONAL CHOKSHI ON SOFTWARE ENGINEERING DAILY

The Software Engineering Daily podcast featured a16z podcast host Sonal Chokshi with host Jeff Meyerson. Jeff started out by asking why a VC firm decided to start a podcast. Sonal says that a16z has always had a culture of writing, blogging, and sharing ideas. This led them to develop an editorial operation from which the podcast naturally followed.

Jeff asked what lessons from blogging apply to podcasting. Sonal sees podcasting as the next evolution of blogging because of its similar intimacy and a similar feeling of authenticity. The difference, she says, is that podcasting is a community and a movement.

Sonal talked about her favorite a16z episodes, including an episode on emojis. She loved it because everybody understands how to use emojis but there is a lot of deep tech and governance involved in making emojis possible. That episode, she said, encapsulates the whole a16z podcast: the intersection of technology, people, politics, context, culture, and humanity.

Jeff brought up a16z's connection to Mike Ovitz's Creative Artists Agency. Having read Ovitz's book and noticed how it portrays Ovitz as a workaholic, Jeff asked Sonal how she finds balance while drinking from the addicting technological firehose. Sonal says there is a lack of nuance in the debates about screen time and work/life balance.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/a16z-podcasting-with-sonal-chokshi/id1019576853?i=1000446547922

Website link: https://softwareengineeringdaily.com/2019/08/09/a16z-podcasting-with-sonal-chokshi/

ROMAN PICHLER ON BEING HUMAN

The Being Human podcast featured Roman Pichler with host Richard Atherton. Richard asked Roman what a product manager is. Roman says a product manager is someone who takes an idea and helps bring it to life, launch it, make it successful, and keep it successful.

Richard asked about the distinction between a product manager and Scrum's notion of product owner. Roman sees the product owner as a product management role, but methodologies like SAFe have redefined the product owner to be a tactical role, misunderstanding the intention behind the role and the practicalities such as answering questions from the dev team, refining backlog items, and answering support and sales questions. He says there is too much focus on the details and this risks losing sight of the big picture.

To do a good job for users and for the business, Roman says it is helpful to have people looking after digital assets with the right qualifications, skills, organizational support, authority, and autonomy.

He says the term "mini-CEO" appeals to some product people because it indicates that product people need a certain level of authority, but a CEO would have marketing and sales functions under their control and product people do not.

Richard asked what talents Roman had to develop to be a great product person. Roman started out as a programmer and began to help business groups come up with new products. What helped him most was to boost his own understanding of how business works and the second most important element was letting go of being interested in how digital products work and focusing instead on who benefits from them.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/72-to-manage-products-is-to-care-with-roman-pichler/id1369745673?i=1000446514943

Website link: http://media.cdn.shoutengine.com/podcasts/4081235a-554f-4a8f-90c2-77dc3b58051f/audio/9b2501e7-e618-46f6-8f41-abd69c871211.mp3

DAVE THOMAS AND ANDY HUNT ON HANSELMINUTES

The Hanselminutes podcast featured Dave Thomas and Andy Hunt with host Scott Hanselman. Scott started by asking whether Dave and Andy knew at the time they wrote the Pragmatic Programmer 20 years ago that they were writing what would become a seminal work. Dave said that both of them were stunned by its success. The book was intended as a way to clarify their own thoughts based on their experiences as consultants in which their clients all had the same kinds of problems: inconsistent builds, the shipping of untested code, and impossible-to-change designs.

Scott asked about the importance of the name of the book. Andy said that there was a strain of thought at the time the book was written that was dogmatic and they deliberately pushed against such approaches. Dave pointed out that this was harder on their readers because it forced them to figure out for themselves what works for them.

They got into a discussion of what kind of educational background one needs to be a successful programmer. Dave revealed that he is currently teaching classes at SMU to, he says, corrupt the youth by teaching them things like functional programming, and because traditional computer science education is poorly serving the industry and the student. People are coming out of university with tens or hundreds of thousands of dollars of debt and, in terms of their value in the industry, they are not much different from people who are coming out of eight-week bootcamps. He teaches third or fourth year undergraduates and graduate students and he has found that none have been shown any form of testing. He would much rather hire someone who had the right attitude, was smart, and who could talk to people and he could show such a person how to code while on the job.

Andy added that he gets the feeling that most computer science programs are there to teach you to become a professor of computer science rather than a problem-solver. What Andy says people need to learn, and what university education is not providing, are problem-solving skills.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/pragmatic-programmer-celebrates-20-years-dave-thomas/id117488860?i=1000446461596

Website link: https://hanselminutes.simplecast.com/episodes/the-pragmatic-programmer-celebrates-20-years-with-dave-thomas-and-andy-hunt-VBmLw9lP

LINKS

Ask questions, make comments, and let your voice be heard by emailing [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

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 [email protected].

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

Dave Thomas and Andy Hunt on The Changelog, Stacey Barr on Coaching For Leaders, Nic Sementa on Drunken PM, Christopher Avery on Agile Uprising, and Steve Poling on Maintainable.

I'd love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email [email protected].

This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting August 5, 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.

DAVE THOMAS AND ANDY HUNT ON THE CHANGELOG

The Changelog podcast featured Dave Thomas and Andy Hunt with host Adam Stacoviak. Dave and Andy were on the show to talk about the 20th anniversary of the book The Pragmatic Programmer and its new edition. Adam asked how the book remains relevant given the short half-lives of most technology books. Dave clarified that the book is not really a technology book but a book about people and people haven't changed that much. The biggest updates to the book were not due to changes in technology but due to changes in the authors' experience and their discovery of better ways of explaining things.

One example was the DRY principle that has come to mean, "Don't cut and paste," while its original meaning was not about code at all but had to do with knowledge. Andy was surprised upon revising the book to realize how much the world has changed in twenty years. Twenty years ago, he says, AOL was carpet-bombing people with CDs, very few of us had to worry about security as it was a struggle enough to get your code to work at all, and unit testing wasn't commonly practiced.

Andy said that they originally had intended to write a little whitepaper describing what they observed going from client to client and seeing the same classes of mistakes over and over. They came up with a set of stories, anecdotes, and metaphors to explain the concepts like "tracer bullet". They intended to hand out this little whitepaper at clients but it just kept growing until it was a book.

Adam asked what has changed in the last twenty years. Andy noticed on reviewing that he found the book more object-oriented than he thought it was. Dave says that people haven't changed, but people's sensibilities have: with the pervasive impact of computer technology on our lives, the responsibility being put on developers to behave ethically has increased dramatically. In his experience, twenty years ago, you wrote boring code that did some business function. Today, we're writing code that can change people's lives. We need to think a lot harder about the impact of the code we write.

Adam asked how we can institutionalize the passing on of knowledge by those who came before. Andy wishes that academia had a greater interest in teaching the history of computing. Dave says this doesn't need to be a separate class. If you want to become an author, you do a lot of reading. Instead of reading books, he says, developers should be reading code and reading a great variety of code. Teaching, he says, should involve learning how people did things in the past, reading their code, and then discussing why they made the choices they did. He gave the example of the C increment and decrement operators. In Bell Labs, the machines had seven addressing modes and two of them were pre- and post- increment address dereference. So the C operators mapped directly to the hardware.

Another example is the famous paper, "GOTO Considered Harmful." Entire languages have been written without GOTO based on the title of that paper. The original letter that the paper came from did not even have this title. The letter was about program-proving and the editors gave a "sexier" title. We carry around these things we have received based on headlines like "GOTO Considered Harmful" and we don't even know why we do it.

Adam asked how the next generation is going to gain a reverence for computing history. Andy suggested that mentors could instill this. Dave pointed out that we now live in an age when you can experience the history first hand. Today, you can emulate a PDP-11/70 in a browser. If you want to look at what Turing did at Bletchley Park, it's there and you can play with it, but people don't. Dave continued on to compare software development to jazz and talked about the importance of knowing the theory

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/the-pragmatic-programmers/id341623264?i=1000444208385

Website link: https://changelog.com/podcast/352

STACEY BARR ON COACHING FOR LEADERS

The Coaching For Leaders podcast featured Stacey Barr with host Dave Stachowiak. Stacey spoke about performance measurement in business and I wish more people understood the things she had to say. Stacey says that humans are not particularly good at judging how things change through time, but performance metrics can do that for us. Performance metric numbers also help us make comparisons a lot more reliably than we can without them. Measurement is about filling the gap in human perception so that we can know with a lot more certainty what's really happening with the results we're trying to achieve in our business.

Dave asked what kinds of mistakes people make around performance measurement. Stacey says that there are a few and the first place you'll see them is in the KPI column of a corporate plan. A common one is initiatives. An initiative usually describes an action or a project that has been chosen to improve performance. For example, if your goal is to improve customer loyalty, you may have an initiative to implement a customer relationship management system. That's not a measure. An initiative is not evidence that you've changed anything for the better.

Next, she talked about milestones. She says that a milestone is about getting something done by a particular point in time. A milestone might be, "We want to meet the medical council requirements for re-accreditation by June of next year." These are commonly mistaken for performance measures but she asks, "Would the achievement of this milestone really change anything?" A whole lot of things may have gotten in the way that made that date no longer an appropriate date or that action no longer an appropriate action. A milestone as performance measure focuses us too much on ticking boxes and expending effort, and that takes us away from what we really need to focus on, which is to influence something to make it better. When a milestone is the performance measure, we're not checking whether the activities are the right activities or the best activities.

She then spoke about customer surveys. A common problem she says is that many will create a customer survey without thinking about the performance measures they need that survey to supply the data for.

She also talked about "management speak" or "business jargon" and mentioned Don Watson's book Death Sentences (https://www.amazon.com/Death-Sentences-Management-Speak-Strangling-Language/dp/1592401406) where he calls these words "weasel words." She says these words sound important, sophisticated, and meaningful, but they are empty of meaning. She went on to give examples: holistic, effective, efficient, accountable, reliable, quality, impact, and sustainability. When you see these weasel words in the names of measures, you've identified a mistake because people won't know what the weasel word truly means, they won't know how to quantify it, and they won't know what data to go after.

She also made a great point about the value of ensuring that we are measuring certain metrics frequently enough. Measuring frequently enough is important because it allows us to distinguish between a pattern of natural variability and changes to that pattern.

Finally, she told a story about presenting some research she was proud of to a committee and not getting the result she expected. I found this story extremely relatable.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/419-performance-measurement-that-gets-results-stacey/id458827716?i=1000444467235

Website link: https://coachingforleaders.com/podcast/performance-measurement-results-stacey-barr/

NIC SEMENTA ON DRUNKEN PM

The Drunken PM podcast featured Nic Sementa with host Dave Prior. Nic is an Agilist whose expertise is in dynamic funnel development (understanding the pieces that make up marketing and sales funnels) and the psychology of the sale. He and his business partner speak about Agile marketing, the conscious communication code, and personal agility.

Dave asked Nic how he learned about the language of persuasion. Nic says he's a firm believer in building on your strengths and considers talking one of his strengths and says his talking skills have gotten him out of fist fights. He talked about subtly taking control of conversation using "pace, pace, lead." He says we're hardwired to either run away or attack back when conflict starts, but what you should do instead is run with your opponent. He says it is like a conversational rope-a-dope. You agree with them, you gain control of the conversation by matching the other person's speed, and then you lead. If they come in fast and fired up, you agree with them while also being fast and fired up, then once they start agreeing with you, you slow down and lead the pace of the conversation.

Dave asked how you avoid getting swept up in your own flight-or-fight reflex. Nic says you have to not take anything personally, not even a personal attack. As soon as you take something personally, you lose your ability to act. Instead, he says, you want to suck all the emotions out of the conversation and deal only with objectivity. He says that once you take away the emotions most people become quite rational. You're not trying to take control of the other person, just their emotions.

Dave asked Nic how he developed these skills and Nic explained that it was part of his upbringing to need to develop these skills. Nic described his childhood family life as a place where "Easter egg hunts can turn into knife fights," so dealing with conflict came naturally to him. Dave asked what he can teach the rest of us who don't have as much experience with conflict. He says you have to remind yourself that you are not a moral authority and therefore your opinion isn't what matters; the objective situation is what matters. We're trained that when something happens, we assume that that something is happening to us. For example, when a TV is louder than we like, we assume that the TV is too loud. He says we should remind ourselves we are not a moral authority with the simple phrase, "than I would like." For example, when you're perceiving a conflict and you are thinking, "Man, this guy is angry and he is loud and the situation is horrible," instead think, "This guy is angrier than I would like, and louder than I would like, and the situation is worse than I would like, but what actually is going on?"

Dave asked about non-violent communication. Nic described it as coming from the writings of Dr. Marshall Rosenberg about people's natural tendency to speak in a way that implies a high level of moral authority, disconnects them from what is actually going on, and puts them in a position where they are judging others on a consistent basis and taking everything personally. Dr. Rosenberg wrote a curriculum to give people tools to combat this tendency. Nic used these tools to deal with the complicated situations in his personal and professional life without changing his own personality. He says you don't have to be an nth-degree yogi who doesn't eat dairy, meat, or sugar and meditates fourteen hours a day to use non-violent communication. You can be a hard-nosed sales dog and use the same tools without dropping your tone to a position of weakness.

Nic says his own epiphany moment for non-violent communication was realizing that it was designed to give you power with people instead of power over people. This connects strongly with the notion of deconstructive criticism in How The Way We Talk Can Change The Way We Work (https://www.amazon.com/How-Talk-Change-Work-Transformation/dp/078796378X) by Kegan and Lahey.

Dave asked Nic how he avoids thinking that he knows what people need. Nic says being objective helps and so does thinking, "Just because you can doesn't mean you should." Nic related a story of a business partner that used to ask Nic everyday, "What is one less thing we could do and still make the same money?" Most people are focused instead on doing more, Nic says, because most people forget the Pareto Principle or 80/20 rule. They also forget the Peter Principle and put themselves above their level of competency.

They ended the conversation with Dave asking Nic for some final tips on communication. Nic says that being able to truly communicate well with your team comes from you understanding that, in addition to the conversations that you have with everybody else, you have another that happens with yourself. One of the most important benefits of telling the people around you why you care about them, why you appreciate them, and what their strengths are, is that, by doing so, you remind yourself.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/the-language-of-persuasion-w-nic-sementa/id1121124593?i=1000443404883

SoundCloud link: https://soundcloud.com/drunkenpmradio/the-language-of-persuasion-w-nic-sementa

CHRISTOPHER AVERY ON AGILE UPRISING

The Agile Uprising podcast featured Christopher Avery with host Brad Stokes. Christopher says that he has been fascinated with the psychology of cause and effect for the past thirty years. That interest produced a pattern called the Responsibility Process that is about processing thoughts about taking and avoiding ownership. We tend to like owning the stuff that we think we caused intentionally and is good and we tend to not like owning the stuff that we don't like and we tend to think such things were caused, not by us, but by something external.

Christopher says that the Responsibility Process is valuable for anyone who wants to live a happier life, be more emotionally free, experience the power of real choices in every situation, and be more effective and valuable.

Christopher asks us to imagine a stack of words and phrases starting at the bottom with the phrase "lay blame," then "justify," "shame," "obligation," and finally, "responsibility." Every time something goes wrong, even if you are just tripping over a crack in the sidewalk, it produces a little bit of angst or anxiety and our mind tries to help us cope by starting at the bottom of the stack and asking, "Who did this to me? Who caused this? Who put the crack in the sidewalk?"

The lay blame state has its own cause-effect logic. It makes us think that we are experiencing the effect and the cause is coming from outside of us. For the anxiety to go away, somebody else has to change. By coincidence, this is practically the same topic that Nic Sementa delved into in the Drunken PM podcast I referenced earlier.

If we recognize that we are in the lay blame state, we may graduate to the justify state. If we transcend that state, we graduate to the shame state where we don't blame somebody else but blame ourselves. This state is full of self-punishment and self-loathing.

If we realize that it is a choice we are making to stay in the shame state, we can graduate to the state of obligation. This is the state of feeling burdened in a process, a flow, or a promise. It is only when we refuse to feel trapped that we can enter the state of responsibility, where you are owning your ability and power to create, choose, and attract.

Christopher says the state of responsibility is always accessible to us. If we practice the responsibility process, we can get to the responsibility state more quickly. Brad pointed out that the obligation state could easily be confused with the responsibility state. Christopher says this is exactly right and before we had the notion of these various states, the word responsibility was used to represent all of them.

Christopher says that, for much of our lives, authorities have been reinforcing the idea that we should beat ourselves up when we make a mistake (shame) and do what we're "supposed" to do even if we despise it (obligation). In obligation, we build up resentment against who or what has us trapped. We resent the mortgage, the kids, the needy elderly parents, and the boss.

If you have been making decisions in your life for more than a few years, he says, then you are the architect of your own life and it is a product of your choices. From there Christopher goes on to say that your life is a product of your filters which may be caused by your environment, parents, church, schools, and neighborhoods. He then asks, "Do you want to defend those filters or examine them?" I see another connection here to the work of Robert Kegan and Lisa Lahey, this time in their book Immunity To Change (https://www.amazon.com/Immunity-Change-Potential-Organization-Leadership/dp/1422117367), which talks about examining the hidden assumptions that prevent us from changing things within ourselves even when we desperately want to change them.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/the-responsibility-process-with-christopher-avery/id1163230424?i=1000443858617

Website link: http://agileuprising.libsyn.com/the-responsibility-process-with-christopher-avery

STEVE POLING ON MAINTAINABLE

The Maintainable podcast featuring Steve Poling with host Robby Russel. Steve and Robby talked about technical debt. Steve says he's been on projects where the tech debt got so bad that they engaged in rewrites, which he calls declaring bankruptcy.

Steve suggests that the enduring popularity of technical debt as a metaphor is because it works to explain the tax on engineering velocity in terms that business people understand. It accumulates, it gets worse, and we want to pay it down.

Robby asked about what processes Steve has used to keep on top of tech debt. Steve started by describing the anti-pattern from the quote above, which reminds me of the Joel Spolsky essay, Things You Should Never Do, Part 1, in which Spolsky spoke about the downsides of rewriting from scratch. Steve says he drank the test-driven development Kool-aid and he now believes that if you do the red-green-refactor of TDD, you can prevent the accumulation of tech debt. Without the refactor step, however, technical debt will continue to accumulate.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/steve-poling-the-real-enemy-is-murphy/id1459893010?i=1000444476559

Website link: https://maintainable.fm/episodes/steve-poling-the-real-enemy-is-murphy-vSKLVY5H

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

Stephane Kasriel on Unlearn, Melissa Perri on Build by Drift, Will Larson on Software Engineering Daily, April Dunford on Product Love, and Claudio Perrone on Agile Atelier.

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

This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting July 22, 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.

STEPHANE KASRIEL ON UNLEARN

The Unlearn podcast featured Stephane Kasriel with host Barry O'Reilly. Barry asked Stephane about what unlearning he has had to do as CEO of Upwork. Stephane said that when Upwork started, they developed software in a waterfall process. Development cycles were long and it was frustrating for people. When the product failed in the field, the level of investment was high and everybody would be pointing fingers at everybody else.

When they switched to an Agile model, there was a lot of unlearning to be done. They stopped trying to specify everything up front and instead tried to build minimum viable products, get feedback from customers, and iterate quickly.

When they went looking for Agile trainers in 2012, it was hard to find anyone willing and able to train Upwork's remote teams. Many trainers at the time told them that being Agile meant being colocated. Today, there are many companies doing distributed Agile development and some best practices have been built up and shared.

I liked what Stephane had to say about company values. He said that what you don't want as a value is one in which you are a good person if you have it and you are a bad person if you don't. You want instead to have values that say, "This company is not for everybody. If you don't believe in these values, there are plenty of companies that more closely match your values and you should go there. But if you want to be here and you want to be successful, you should be excited about this company's values."

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/ceo-school-and-the-future-of-work-with-stephane-kasriel/id1460270044?i=1000443495925

MELISSA PERRI ON BUILD BY DRIFT

The Build by Drift podcast featured Melissa Perri with host Maggie Crowley. Maggie started out by asking Melissa how she defined the build trap she references in her book Escaping The Build Trap (https://www.amazon.com/Escaping-Build-Trap-Effective-Management/dp/149197379X/). Melissa says that the build trap is a situation an organization finds itself in when it gets too concerned with how many features it is shipping and not concerned enough with the value for the customer and the business that those features are producing. She says that these businesses fail to retrospect on the impact that the features they shipped had on customers and the business.

Maggie asked how companies get into the build trap in the first place. Startups, Melissa says, don't typically have this problem, but as they scale and get more money, the distance to customers increases, they talk to customers less, and have more runway. They tend to go into an execution mode where they just keep asking themselves, "What's the next thing we can build?" and forget to go back to their customers and make sure that what they build for them is producing value for them.

Maggie described the challenges Drift faces in having teams that locally optimize for particular features and Melissa says this comes back to how the company thinks about strategy. Small companies don't need a strategic framework but, as you scale, you want all the new teams you are creating to move in the same direction and a strategic framework can help with this.

Maggie asked what Melissa prescribes when she consults with a company that is stuck in the build trap. Melissa instead gave an answer on how she assesses a company before making a prescription. She first looks for how the company sets strategy and how it deploys it. Second, she looks to see if the company has the right people in the right roles. She also looks at whether the company has the right processes to learn from customers and incorporate feedback. Next, she looks at product operations, such as a cadence for revisiting decisions and the right data infrastructure to support decisions. Last, she looks at culture and how people are incentivized.

Maggie asked what Melissa would change first if the company had problems in all of those areas. Melissa says that she starts by making sure the company has good product leaders and product managers who can learn from those leaders. Many companies had product leaders who didn't start in product management themselves and can't train or help the product managers. As Maggie points out in this podcast, this echoes what Marty Cagan said when she had him as a guest in an earlier episode. I referenced that Build by Drift episode in the 14th episode of this podcast, named Safety Is Not A Priority.

Melissa says she spends a lot of time translating what the teams are working on into something that executives can get behind because executives don't care about the list of features that the teams are shipping; they care about what those features are going to do. Melissa says that storytelling in these situations is about relating your story to the goals people care about.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/whats-the-build-trap-what-does-it-mean-for-product-managers/id1445050691?i=1000443704053

Website link: https://share.transistor.fm/s/fbfcff04

WILL LARSON ON SOFTWARE ENGINEERING DAILY

The Software Engineering Daily podcast featured Will Larson with host Jeff Meyerson. Jeff started by asking whether Will thinks Google, where they once had a very flat management hierarchy, could work with no managers today. Will said that today's hyper-scaling companies are so fast-growing that you need people to help manage that growth while dealing with tools and systems that are constantly becoming out of date.

Jeff asked about the psychological ramifications of working in an environment of rapid growth. Will said that the best part of rapid growth is every week you raise your head and look around and see some really smart, talented person who is sitting next to you and wasn't there the week before and can help. During change, he says, you have to stay open. Don't try to control the change but you can help to facilitate it. You should be aware of your needs and take action to ensure those needs are being met so you can be the person you want to be for longer, rather than peaking in your first months in a role.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/elegant-puzzle-with-will-larson/id1019576853?i=1000441481446

Website link: https://softwareengineeringdaily.com/2019/06/14/elegant-puzzle-with-will-larson/

APRIL DUNFORD ON PRODUCT LOVE

The Product Love podcast featured April Dunford with host Eric Boduch. April talked about product positioning. She says that many treat the product positioning exercise as a Mad Libs-style template to be filled in. The actual thinking of how to position your product is often ignored.

She says that the first thing you have to do is get a handle on what the real competitive alternatives to your product are in the minds of your customers. For many startups, their real competitor is Excel, or hiring an intern, or doing it manually. Next, she says, is to look at what you have feature-wise that the competitive alternatives do not. This is usually a giant list of things. As you go down this list, you ask yourself what value for customers each feature enables. She says that an interesting thing happens at this point: the value tends to theme out. There are usually two or three big buckets that three quarters of your features fall into. Those buckets get you to your differentiated value. That, she says, is your secret sauce.

She uses the analogy of building a fishing net specifically for tuna. You have a choice. You can travel to the part of the ocean where you will find tuna and see if your net works or you can go to the part of the ocean where there are all kinds of fish, throw the net in, and see what you pull up. People at startups often think that a certain segment of the market is going to love their product, but they might be surprised to learn that there is a segment that they didn't even think of that is actually dying for their product. You don't want to get the positioning so tight that you exclude those people. You want to keep it loose, cast the net wide, and see what happens.

April says she doesn't believe in product-market fit. She says that nobody has given her a good answer to the question, "How do you know you got product-market fit?" You may have a product that people like, but if you don't know why, you don't know if it's at risk of going away or tapping out its market. She asks, "If I can't measure when I have product-market fit, why am I even trying to get product-market fit?"

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/april-dunford-joins-product-love-to-talk-about-product/id1343610309?i=1000441988263

Website link: https://soundcloud.com/productcraft/april-dunford-joins-product-love-to-talk-about-product-positioning

CLAUDIO PERRONE ON AGILE ATELIER

The Agile Atelier podcast featured Claudio Perrone with host Rahul Bhattacharya. Claudio talked about his Popcorn Flow model. He says that Popcorn Flow is based on a pragmatic anti-fragile philosophy and starts from the idea that inertia is our enemy and provides a set of principles and steps to fight inertia in organizations. I saw Claudio give a presentation on Popcorn Flow at the Agile Testing Days 2017 conference, so I was excited to find him being interviewed on a podcast.

Popcorn Flow applies ideas from The Lean Startup to organizational change. As an entrepreneur, Claudio realized that in entrepreneurship you are dealing with an environment of extreme uncertainty and, as an Agile coach, he saw the same kind of environment of uncertainty in how people react to change. Lean Startup deals with environments of extreme uncertainty by running frequent experiments. Popcorn Flow applies the same approach of frequent experimentation to organizational change.

Popcorn Flow is most known for its decision cycle of seven steps from which the POPCORN acronym is derived:

• Problems & Observations
• Options
• Possible experiments
• Committed
• Ongoing
• Review
• Next

These steps are visualized like a Scrum board or Kanban board. Claudio gave an example of running through the seven steps for the problem of poor quality code:

• Problem: poor quality code
• Options: pair programming, test-driven development
• Possible experiments: pair program for three days and see if the code is better and see if we want to continue with the practice
• Committed: put a review date on the calendar for evaluating the results of the experiment
• Ongoing: Track the experiment as it proceeds
• Review: The experiment is not finished until you review it. Compare the reality against the expectation and discuss what you learned and what are you going to do next.
• Next: The review may indicate that you do not know enough yet, so you may choose to persist, launch a new experiment based on what you learned, or revisit the problem.

I liked what Claudio had to say about Agile: "I felt it was about being humble. If we knew the perfect way of developing software, we would use the perfect way. It is because we don't know that we start with what we have and we continuously inspect and adapt."

Claudio also talked about some of the principles of Popcorn Flow:

1. If change is hard, make it continuous: borrowing ideas from continuous integration and delivery, replace big change programs with small incremental change and do it all the time.
2. Small bets, big payoff (the venture capitalist principle): when you run a lot of experiments, it doesn't matter that you failed. What matters is how much does it cost to fail and how much do you gain when you win.
3. It is not 'fail fast - fail often', it is 'learn fast - learn often': without feedback, your experiments are not small bets and you are not experimenting; you are committing to what should instead be an option.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/episode-9-experimentation-popcorn-flow-claudio-perrone/id1459098259?i=1000443480071

Website link: https://rahul-bhattacharya.com/2019/07/02/episode-9-experimentation-and-popcorn-flow-with-claudio-perrone/

FEEDBACK

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

Allen Holub on Deliver It, Jason Tanner on Drunken PM, Mary and Tom Poppendieck on Unlearn, Saron Yitbarek on Greater Than Code, and Dave Karow and Trevor Stuart on Deliver It.

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

This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting July 8, 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.

ALLEN HOLUB ON DELIVER IT

The Deliver It podcast featured Allen Holub with host Cory Bryan. Cory started out by reviewing an article by Ron Jeffries called "Story Points Revisited." Allen's take is that the negatives around story points are more than just the potential for misuse; he believes story points have no value at all. He says the most important thing is to narrow your stories, not estimate them. He says estimates exist because of fear. The software development process is opaque to certain managers and, as a result, they want estimates to alleviate their fear, but when you are delivering every day, you can eliminate the fear without resorting to estimates.

Cory asked Allen what product owners need to know about Agile architecture. Allen said that one of the mistakes that he sees product owners make a lot is they try to do a miniature up-front design and expect that to be implemented. When this happens, he says there is too much information captured up-front of what is going to be built during the sprint and not enough information captured during the sprint as a side effect of releasing code to users and getting their feedback. This leads to inappropriate architectures because when you do anything up-front, you start doing everything up-front. Your sprint planning starts involving architecture decisions, UI decisions, and UX decisions that may be wrong and you will not know if you are wrong until you release.

In Allen's view, the most important thing a product owner does is answer questions that come up during the course of development. He uses a "two-minute rule": if a question comes up during development, the product owner needs to be able to answer within two minutes.

Allen talked about how the constraints of a bad architecture can prevent you from ever being Agile. He says, "Agile has nothing to do with standup meetings and backlog grooming and all of those. The important thing is to get stuff into your user's hands quickly."

Allen says that the architecture has to be focused on the domain. Where systems that are wrong go wrong is that they don't map to the domain but to the technology. A change at the story level, which is where the majority of changes come from, ends up touching all the modules or layers of your system when your architecture is mapped to your technology instead of your domain.

Allen says that when he does a workshop on Agile architecture, people raise their hands about halfway through and say, "All we're doing is domain analysis!" The fact is, if the domain and code are matched to each other, domain analysis is architecture.

One of the questions Allen asks when he gets a bunch of product owners in a class is, "How many of you talk to multiple customers multiple times a day?" Maybe 5% raise their hands. So he says, "Who in the organization does talk to multiple customers multiple times a day?" This is often met with silence. He asks, "What about Sales? What about Tech Support?" He says that if you can't respond to customer kinds of issues as well as a salesperson or a tech support person could, you don't know the domain well enough to be helpful to the engineering team.

Cory asked Allen what he thought of the distinction between regular stories and "technical" stories. Allen says that there is no such thing as technical stories. A story describes the users of your system performing some kind of domain level work to achieve a useful outcome. Fixing some technical thing like changing the color of a button in no way makes your end users' lives easier; it does not help them do their work.

Allen says that the role of the architect in an Agile environment is very different from what we traditionally think of, just like the role of a manager in an Agile environment. In Agile environments, the job of people who are in a leadership position is to make sure that you can do your job, not to tell you what to do. They communicate a strategic requirement, provide support, and remove the obstacles. The same, he says, applies to Agile architects.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/ep90-agile-architecture-with-allen-holub/id966084649?i=1000441313352

Website link: http://deliveritcast.com/ep90-agile-architecture-with-allen-holub

JASON TANNER ON DRUNKEN PM

The Drunken PM podcast featured Jason Tanner with host Dave Prior. Dave started out by asking Jason why he believes the daily scrum is broken. Jason said that the daily scrum is broken because, first, most developers hate the daily scrum because most daily scrums take the traditional weekly project status review meeting and do it five times a week with the Scrum Master filling the role of the project manager. Second, he says, is that it is being done backwards. The center of attention should not be the Scrum Master, but the team and the sprint backlog.

He says that the purpose of the daily scrum is misunderstood. The three questions don't result in a plan but result in just an exchange of information. For what real daily planning looks like, he uses an analogy of driving down the road and seeing a bunch of plumbers' trucks from the same company parked outside of a McDonald's. Inside, they're planning things like, "We're going to the Johnson's house at noon. Can you come over and meet me because it's going to be a two-man job."

Jason says he hates the three questions. He says the subject of the sentence is not helping us in collective ownership of the sprint backlog. "I have my user story. I have my Jira ticket. I have five team members and we each have a ticket." Shifting the subject of the sentence to "we", he says, changes the behavior dramatically.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/jason-tanner-is-on-a-mission-to-fix-your-daily-scrum/id1121124593?i=1000441958371

Website link: https://soundcloud.com/drunkenpmradio/jason-tanner-is-on-a-mission-to-fix-your-daily-scrum

MARY AND TOM POPPENDIECK ON UNLEARN

The Unlearn podcast featured Mary and Tom Poppendieck with host Barry O'Reilly. Barry asked Mary and Tom what we may need to unlearn since the Agile movement began. Mary says that Agile started as a reaction to what was going on at the time. The vast majority of people doing software engineering today weren't around back then. One of the things Agile has to do is grow up to be not a reaction to bad things that happened in the past, but to be something that talks about, "What does it take to do good software engineering?"

She contrasted the software engineers she speaks to today that expect to be handed a spec with the engineers she worked with early in her career who treated engineering as problem-solving.

Tom talked about how many who are working to make organizations more agile attempt to solve problems with process. This assumes that the organization's problems are process problems but they are actually architectural problems. This includes problems with the architecture of the applications they are evolving, problems with the structure of the organization, and problems with the structure of the relationships between the supporting groups and those who are benefitting from said groups.

Mary talked about how Amazon AWS was one of the early organizations to understand that you need to give teams of smart, creative people problems to solve. As a result of having this insight, they organized the company in such a way as to optimize for this, such as by eliminating a central database which was heresy back in 2005. She called out AWS Lambda in particular because this product did not optimize for short-term shareholder value and would never have been approved at most companies because it reduced what Amazon was charging customers by five times. She attributes this ability to self-disrupt as being essential to Amazon AWS's success.

Tom talked about the fact that when you attempt to scale things up, you reach a point where complexity dominates any future gains and wipes them out. He says you instead need to de-scale: figure out how to do things in little chunks that are independent and don't require coordination. He says that this is how cities have been organized for thousands of years.

Mary said that she has been doing software since 1967 and has never seen anything last two decades and still be current. Agile is two decades old and cannot be current unless it is constantly adapting to what is current today. She brought up continuous delivery as a fundamental change in agile thinking. It changed the way we thought about how we structure organizations and teams and what kinds of responsibilities we should give to them.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/solving-problems-safely-with-mary-and-tom-poppendieck/id1460270044?i=1000442018979

SARON YITBAREK ON GREATER THAN CODE

The Greater Than Code podcast featured Saron Yitbarek with hosts Arty Starr, Rein Henrichs, and Chanté Thurmond. They talked about the annual Codeland conference Saron is running and how it offers free on-site childcare this year. Saron says free on-site childcare at conferences today is where codes of conduct were a few years ago. She says that if her conference wasn't making it easier for parents to attend, it wouldn't be living up to their promise for inclusion.

Chanté asked Saron what she learned in her transition from being a code newbie herself to the present day where she is running two podcasts, a software job, and a conference. Saron said she learned that it is important to be consistent in all your efforts, whether it is community work, your personal projects, or a project at work. Nothing gets built overnight and, for a while, nobody will care what you're doing. If you want to do something great, it takes persistence and it takes you believing in yourself especially when you're not getting external validation.

Arty asked about what expertise in "newbie-ism" might look like. Saron says that it is about being comfortable in a state of frustration. She pointed to a study on the difference between those who finish a computer science degree and those who quit. The study said that those who finished the degree were comfortable being in a state of confusion: they knew that things were not going to make sense for a while and they were ok with that.

A second thing, she says, that helps you become an expert newbie is realizing that almost all problems in coding are solvable. By contrast, in writing, there is no perfect essay. In journalism, there is a search for truth, but is truth attainable? In life sciences, we study nature all around us that we may never fully understand.

She also says to keep your frustration external, avoid internalizing your failures, and she says to distance who you are from your work and the things you produce.

Saron's comment on being comfortable in a state of confusion triggered a Virginia Satir quote from Rein: "Do you know what makes it possible for me to trust the unknown? Because I've got eyes, ears, skin. I can talk, I can move, I can feel, and I can think. And that's not going to change when I go into a new context; I've got that. And then I give myself permission to say all my real yeses and noes, because I've got all those other possibilities, and then I can move anywhere. Why not?"

Rein asked what Saron learned about teaching. Saron says that teaching is storytelling in disguise. She says that if we frame teaching opportunities as storytelling opportunities we can be better teachers. This reminded me of Josh Anderson's comment on the Meta-Cast podcast that I referenced way back in episode 3, "Taking The Blue Pill Back To Sesame Street."

Rein brought up a theory of learning called conversation theory. In conversation theory, teaching happens as a conversation between two cognitive entities. You have to come to agreement and build a bridge with that other cognitive entity. It deconstructs the teacher-learner binary. The teacher themselves has to be a learner too.

Chanté asked about the ethos at Code Newbie for being a learner and a teacher. Saron says they look to the community to pitch in. When someone asks a question, they encourage the community to answer. She contrasted Code Newbie with Stack Overflow. Code Newbie attempts to teach the learner from where they are and avoid the condescension that is common on Stack Overflow.

She said that to create an environment where people are not afraid to ask questions, we have to be unafraid of being vulnerable ourselves. Go first, share your vulnerability, and share what you're struggling with. The moment you start doing that, other people will be much more likely to raise their hands as well.

Chanté asked Saron what resources she recommends for code newbies to learn to code. Saron said that the hard part isn't finding resources but sticking with them when things get tough or boring.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/135-intentional-learning-with-saron-yitbarek/id1163023878?i=1000442022293

Website link: https://www.greaterthancode.com/intentional-learning

DAVE KAROW AND TREVOR STUART ON DELIVER IT

The Deliver It podcast featuring Dave Karow and Trevor Stuart with host Cory Bryan. They talked about running experiments to learn about your customer. Cory asked how people can run such experiments at scale. David pointed out that having a way to run the experiment is one thing, but you also need to be able to rapidly make sense of the results in a repeatable, authoritative way. Trevor says it is all about assumptions, hypotheses, and documentation. Before you even start your experiment, you need to understand why you are running it in the first place. In other words, you need to establish what is going to change as a result of the experiment.

Trevor says that much of the market is already doing experiments and they don't know it. They just call it "using feature flags" and rolling things out incrementally. They just need to move one step further to slice and dice their user populations, roll things out for longer time periods to those users, and bring the resulting data into a form that facilitates decision-making.

David talked about dog-fooding by starting your rollout of new features with your employee population, giving examples from Microsoft, where it takes a few weeks to go from the employee population to the full customer population, and Facebook, where it takes about four hours for the same kind of rollout.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/ep91-product-experiments-with-trevor-and-dave-from-split/id966084649?i=1000442844631

Website link: http://deliveritcast.com/ep91-product-experiments-with-trevor-and-dave-from-split

FEEDBACK

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

Rob Fitzpatrick on The Art of Product, Joshua Kerievsky on Being Human, Marty Cagan on Build by Drift, Jutta Eckstein and John Buck on Agile Uprising, and Jocelyn Goldfein on Simple 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 [email protected].

This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting June 24, 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.

ROB FITZPATRICK ON THE ART OF PRODUCT

The Art of Product podcast featured Rob Fitzpatrick with hosts Ben Orenstein and Derrick Reimer. They talked about Rob's book, The Mom Test. He wrote it for "super-introverted techies" like himself but found it resonated with a wider audience. He explained that one of the reasons he self-published the book is because, when he took it to a publisher, they wanted him to increase the word count simply because they believed, with no evidence, that business books below 50,000 words don't sell.

The hosts asked Rob to describe "The Mom Test" in his own words. He described how, just as you shouldn't ask your mom whether your business is a good idea because she's biased, you need to be careful when asking anyone whether they think your business is a good idea. This, he says, puts the burden on them to tell you the truth. Instead, he says you should put the burden on yourself of coming up with questions that are immune to bias, so immune that even your mom would give you an unbiased answer.

Rob talked about how the value of customer conversations is proportional to how well the problem you are trying to solve is defined. For products like Segway or Uber or a video game, asking customers questions about the problems they want solved is not as effective as it would be when the product is enterprise software.

Derrick talked about how, when The Lean Startup started becoming big, it led him to what he calls "idea nihilism" where he started to believe the idea doesn't matter at all, it is one hundred percent the journey, and the future is unpredictable, so just build something. The next few things he built while in this mindset either did not get off the ground or led him to ask himself why he built a business he hated. Eventually, he concluded that the idea matters a lot.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/90-the-mom-test-with-rob-fitzpatrick/id1243627144?i=1000440137442

Website link: https://artofproductpodcast.com/episode-90

JOSHUA KERIEVSKY ON BEING HUMAN

The Being Human podcast featured Joshua Kerievsky with host Richard Atherton. What I loved about this interview is that Joshua described many of the inspirations behind the Modern Agile principles. The first principle, "make people awesome," was inspired by Kathy Sierra and her focus on making the user awesome. They originally called it "make users awesome" and realized that there is a whole ecosystem besides the end consumers, including colleagues, management, and even shareholders, to make awesome. He clarified that the word "make" is not coercive, but about asking you what you can do to empower others.

Regarding the second principle, "make safety a prerequisite," he talked about being inspired by a story in Charles Duhigg's The Power of Habit about Paul O'Neill and his turnaround of the hundred-year-old Alcoa corporation. Just as Amy Edmondson had connected psychological safety to physical safety in a previous podcast, Joshua connected psychological safety to product safety. He clarified that making safety a prerequisite doesn't mean avoiding risk.

Speaking about the third principle, "experiment and learn rapidly," he told the story of the Gossamer Condor, the human-powered aircraft that was created to win the Kremer prize. The team that built the Condor engineered their work so that they could fail safely. The airplane flew two or three feet from the ground and the materials they used were expected to break and be repaired quickly. This let them do multiple test flights per day while their competitors would go through a waterfall process that led to large times gaps between test flights.

Finally, he described the fourth principle, "deliver value continuously," as finding a way of working where you can get feedback early and learn from it, delivering value each time.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/62-modern-agile-with-joshua-kerievsky/id1369745673?i=1000440221993

Website link: http://media.cdn.shoutengine.com/podcasts/4081235a-554f-4a8f-90c2-77dc3b58051f/audio/303a9472-75ef-4e7f-94e5-414a3018750a.mp3

MARTY CAGAN ON BUILD BY DRIFT

The Build by Drift podcast featured Marty Cagan with host Maggie Crowley. Marty says that when he shows teams the product discovery techniques he described in his book, Inspired,he finds that they understand the value of the techniques but too often they are not allowed to use them. Instead, their leaders hand them a roadmap and tell them to just build features. When he talks to these leaders, he asks, "Why are you doing this? You know this isn't how good companies work." The answer, though not always admitted, is that they don't trust the teams and, as a result, they don't empower them.

They talked about the defining characteristics of an empowered product team. First among them is for the leadership team to give the product team problems to solve rather than features to build. They also need to staff them appropriately because, if they have been running things the old way long enough, they don't have the appropriate staff to run things the new way. For example, they may have somebody called a product manager, but they are really a project manager with a fancy title or a backlog administrator. Or they may have designers who are just adding the company color scheme and logo or engineers who are just writing code.

Maggie asked what a product leader can tell a stakeholder who is used to thinking in tangible features rather than the problem to be solved. Marty says there is nothing wrong with talking about features, but it is when they get etched into a roadmap that we get into trouble because it becomes a commitment and the time spent on the feature could be better spent on figuring out how to solve the problem.

They talked about Objectives and Key Results or OKRs and how they are a complete mess at most companies. The concept is simple and easy if you are already in the empowered team model, but otherwise it is theater because you're still doing roadmaps while simultaneously trying to tell people the problems to solve.

Maggie started describing how they do product discovery and development at Drift and Marty immediately pointed out how the language she used makes the work sound like it occurs in phases as it would in a waterfall project. She explained that they use this notion of phases to communicate out and he pointed out that, even if it is not currently waterfall, there is a slippery slope between speaking about phases and landing in a waterfall mindset.

He talked about three things he cares about that distinguish his process from waterfall: 1) tackling the risks upfront, 2) product managers, designers, and engineers literally coming up with prototypes side-by-side instead of having hand-offs, and 3) iterating towards achieving your KPIs rather than having a phase where you've declared the design done and have started implementing.

Maggie asked him to enumerate what he thinks product leaders should be doing. First, he said that they need to coach their product managers to get them to competence, which he says should take no more than three months. In the case of hiring product managers straight out of school, the product leader needs to commit to multiple-times-a-week or even daily coaching.

Second, he said that product leaders need to take an active role in creating product strategy. This comes back to OKRs where product leaders provide business objectives that product teams translate into problems to solve. The more product teams you have, the less you can expect those teams to be able to see the whole picture on their own, which makes it more important for product leaders to connect the dots for them.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/we-talked-to-product-management-legend-marty-cagan/id1445050691?i=1000440847157

Website link: https://share.transistor.fm/s/da82dbda

JUTTA ECKSTEIN AND JOHN BUCK ON AGILE UPRISING

The Agile Uprising podcast featured Jutta Eckstein and John Buck with host Jay Hrcsko. Jay asked Jutta how she and John came together to produce the ideas described in their book Company-wide Agility with Beyond Budgeting, Open Space & Sociocracy. Jutta and John met at an Agile conference in Atlanta and got the idea to investigate what Sociocracy could bring to Agile. They soon found themselves thinking, "That's not really all of it," and immediately agreed to write a book together about it.

Jay started going through the book, beginning with four problem statements:

1. Existing concepts cannot be directly applied to company strategy, structure, or process in the VUCA (volatility, uncertainty, complexity, ambiguity) world.
2. Companies make decisions from the top down but often people at lower levels who are closer to the realities of the product or market have valuable insights that are currently ignored.
3. There is a collision of values underlying shareholder interests in short-term profits and a focus on the needs of the customers.
4. For a company to be agile, all departments must be agile. However, existing agile systems struggle when applied to non-engineering departments.

Jutta described Beyond Budgeting. She said that it sounds like it only has relevance to the finance department, but there is a close relationship between how companies deal with finance and how they are managed. In contrast to Agile, which originated from the experiences of consultants, she says, Beyond Budgeting originated in the experiences of CFOs. She gave examples of the problems with traditional budgeting: In the first scenario, a company's budget is set annually and, at some point during the year, a project team that had been allocated a certain budget determines that the market has changed and they no longer need a budget as large as they originally thought. She's never seen this situation lead anyone to give the money back. In the second scenario, the market changes such that the budget needed for the company to succeed in the market exceeds the original budget and it's too late for anything to be done. Jay brought up the distinction made in the book about the three distinct uses of budgets: 1. a target, 2. a forecast, and 3. capacity planning, and the fact that these should not be combined.

Next, they discussed Open Space. John talked about the Open Spaces you often see at conferences and how they increase creative thinking and allow people's passions to emerge. In the same way, Organization Open Space, where you can come up with a project, line up some people, and go to work, gives you passion bounded by responsibility that leads to creative companies.

John pointed out that the combination of the three concepts, as he and Jutta developed the book, started to interact and come together in ways that made it greater than the sum of its parts. That's why they gave it a name: BOSSA nova.

Jay brought up how he has already benefitted from what he learned about Sociocracy in the book. He was able to help his colleagues learn about the difference between consent and consensus. The participants in a meeting had been locked in an argument over a maturity model when Jay restated the subject of the disagreement in terms of consent, asking if there was anyone who needed to put a stake in the ground for their position or would they all be willing to let an experiment proceed. This quickly unblocked the stalemate.

John related a similar story about helping a group of professors make some decisions about forming a professional association.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/bossa-nova-with-jutta-eckstein-and-john-buck/id1163230424?i=1000440982639

Website link: http://agileuprising.libsyn.com/bossa-nova-with-jutta-eckstein-and-john-buck

JOCELYN GOLDFEIN ON SIMPLE LEADERSHIP

The Simple Leadership podcast featured Jocelyn Goldfein with host Christian McCarrick. Jocelyn talked about her career, including some time starting her own company, rising in the ranks at VMWare, arriving at Facebook at a critical time in its history, and becoming an angel investor and a venture capitalist.

Christian asked about one of Jocelyn's tweets about motivation as a management superpower. She says that engineers have a lot to offer the discipline of people management because they know how to think about systems problems and most organization problems are systems problems. On the other hand, engineers sometimes lose sight of the fact that human systems are different from programmatic systems in that they have feelings and don't always behave rationally, but people respond to incentives. Explanations of the importance or urgency of a particular effort and attaching a bonus to it are blunt instruments, but praise and encouragement satisfies people's needs and engenders long-term loyalty in a way that other incentives don't.

They talked about one of my favorite blog posts of Jocelyn's on culture. She says that culture is what people do when nobody is looking. It is not people following an order. It is people knowing what to do when they don't have orders. She says that people often think that culture is a set of traits or qualities and that you can interview for those traits to find someone who is a "culture fit." She disagrees with this because companies are different from one another and people are obviously portable between companies.

Christian brought up the example of companies that have posters on their walls describing their culture. To Jocelyn, people are less than 10% influenced by the poster on the wall and more than 90% influenced by what successful, powerful people in the company do. When these are in conflict, you get cynicism.

She talked about how compensation can be a motivator, but she noted that other people cannot judge your success by your compensation because they don't know it, so they look for other indicators like title, scope of responsibility, influence, and confidence. So she says you need to be careful when handing out overt status symbols like titles and promotions because people will emulate the recipients of such symbols. The classic example, she says, is the brilliant jerk. When you elevate the brilliant jerk, you're sending a message that people who succeed in this company and get ahead are jerks. The poster on the wall may not say that, but people will attach more weight to your behavior than what you or the poster say.

Jocelyn talked about the undervaluing of soft skills. Engineers are taught early on that their work is fundamentally solo work and she says that is a lie because, if you want to do anything significant, if you're going to go from rote work to meaningful creative work, the crucial skills are the soft skills we're taught to disdain or neglect.

Regarding recruiting and hiring, she talked about the tendency, at least at Facebook, to treat the phone screen like an on-site interview and create false negative rates that are too high. She did her own test where she brought in for on-site interviews a set of candidates who had previously been rejected at the phone screen stage and found that the same number got hired from her screened-out pool as were hired from the pool of candidates that passed their phone screen.

She talked about the benefits and disadvantages of the centralized hiring model. On the plus side, it reduced silos, made teams friendlier to one another, and made employees become citizens of the company first and citizens of the team second. The downside of the centralized model is that there is no hiring manager taking responsibility, so the responsibility passes to the recruiter. Her preference is a blended model that is mostly centralized but with hiring managers taking responsibility and receiving rewards and praise for taking that responsibility.

I loved what Jocelyn had to say about diversity and inclusion. She said that when we're working at these high-growth companies, we're desperately seeking to hire, we're interviewing everybody, and we're hiring everybody who is above our bar. When we look at the result and it is only 5% or 10% female and single digit percentages black or hispanic, some part of us is thinking that must reflect the inputs and to get a different population I would have to lower my bar and accept people who are failing. But this assumes a few things: that your interview bar is fair and that the population who applies to work at your company is the population who could apply to work at your company. If you really value having a more diverse environment, you will go looking for them. If you just sat there and only looked at applicants, you would never have hired that one signal processing engineer you needed or that one esoteric role that is not there in your applicant pool.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/how-to-improve-your-management-skills-jocelyn-goldfein/id1260241682?i=1000440957474

Website link: http://simpleleadership.libsyn.com/how-to-improve-your-management-skills-with-jocelyn-goldfein

FEEDBACK

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