Episoder
-
Chris Ferdinandi on Greater Than Code, Ben Orenstein on Maintainable, Susan Rice on Coaching For Leaders, Courtland Allen on Software Engineering Unlocked, and Matt Stratton on Hired Thought.
I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email [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 March 16, 2020. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers.
CHRIS FERDINANDI ON GREATER THAN CODE
The Greater Than Code podcast featured Chris Ferdinandi with hosts Rein Henrichs and Jacob Stoebel. Chris is a proponent of plain vanilla JavaScript. He says that modern web development has grown so much in scope and complexity that it makes it difficult for beginners to get started and it can negatively impact the performance of the web for users in ways that developers with fast machines don’t always feel.
One of the reasons things are the way they are today, Chris says, is because a lot of backend developers migrated to the front end because that was where the exciting stuff was happening and they brought with them their approaches and best practices.
The front end, however, is a very different medium. In the back end, you have control over how fast the server is, when things run, the operating system, etc. On the front end, you have none of this. People are accessing what we build on a variety of devices that may or may not be able to handle the data we’re sending and may have unpredictable internet connections.
If a file fails to download or the user goes through a train tunnel and we’ve built things in a modern JavaScript-heavy way, the whole house of cards falls apart on these users. Chris would like people not to abandon JavaScript altogether, but to be a little more thoughtful about how we use it.
Modern web development involves a few things: frameworks, package managers, and doing more and more things (such as CSS) in JavaScript. All of this JavaScript has the effect of slowing down performance because 100KB of JavaScript is not the same as 100KB of CSS, a JPEG, or HTML because the browser needs to parse and interpret it.
Because of these performance problems, single page apps have become more popular. But now you’re recreating in JavaScript all the things the browser gave you out of the box like routing, shifting focus, and handling forward and back buttons. You’re solving performance problems created by JavaScript with even more JavaScript, which is the most fragile part of the stack because it doesn’t fail gracefully. If a browser encounters an HTML element it doesn’t recognize, it just treats it as a div and moves on. If you have a CSS property you mis-typed, the browser ignores it. But if you mistype a variable in JavaScript, the whole thing falls apart and anything that comes after that never happens.
For Chris, a better approach to web development is one that is more lean and more narrowly-focused on just the things you need. His first principle is to embrace the platform. For example, a lot of people don’t realize that DOM manipulation that used to be really hard years ago is really easy these days in vanilla JavaScript. Also, many of the things that JavaScript was required for in the past can be done more efficiently today with HTML and CSS.
He also says that we need to remember that the web is for everyone. Because we are often using high-end computers, the latest mobile devices, and fast internet connections, we forget that this is not the experience for a majority of web users. We build things that work fine on our machines but are painfully slow for the people who actually use the things we build.
They ended their discussion with reflections. Chris’s reflection was about learning JavaScript and web development for the first time. He says that people learning shouldn’t be made to feel like they need to dive in to the latest trends, but should instead find a way to learn the fundamentals.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/170-the-case-for-vanilla-javascript-with-chris-ferdinandi/id1163023878?i=1000466076138
Website link: https://www.greaterthancode.com/the-case-for-vanilla-javascript
BEN ORENSTEIN ON MAINTAINABLE
The Maintainable podcast featured Ben Orenstein with host Robby Russell. Ben believes that, in a maintainable codebase, the code should match how you think about the world. When speaking about the domain with your teammates, do you use the same terminology that the code uses? Do you use the term “user” but the code uses the term “customer”?
Getting your terms consistent is a specific case of a more general principle of implicit and explicit knowledge. Maintainable systems have as much knowledge put into them as possible so that they become sources of truth.
Ben’s definition of technical debt is a technical shortcut you took intentionally after weighing it against alternatives and deciding it was worth it in the short team with the eventual intention of eliminating it. He says it is hard to get time on a schedule dedicated to cleaning up technical debt, so it is your professional responsibility to clean it up as you go. Ben says that asking permission to clean up technical debt as you deliver a feature is like asking permission to do your job well.
He says that the idea of “We’ll go fix this later” never happens and, if you don’t believe him, grep your codebase for the string “TODO”.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/ben-orenstein-someday-well-go-clean-that-up-doesnt-work/id1459893010?i=1000466511242
Website link: https://maintainable.fm/episodes/ben-orenstein-someday-well-go-clean-that-up-doesnt-work-_fGCpf6F
SUSAN RICE ON COACHING FOR LEADERS
The Coaching For Leaders podcast featured Susan Rice with host Dave Stachowiak. From the time she was seven, Susan would hear her parents fighting loudly and violently when she was trying to sleep at night. When the fighting got scary and out of control, Susan would step in. Sometimes that meant talking them down and sometimes that meant separating them. The mediation she did with her parents taught her how to interact with parties who were intractably opposed.
This developed in her a lack of discomfort with conflict, disagreement, and argument. She said that this helped her to be willing to stand up and not be conflict-averse. This reminded me of the Buster Benson episode of Lead From The Heart I summarized in my last article.
Dave asked Susan about a section of her book Tough Love in which she described some feedback she received from former congressman Howard Wolpe when she was Assistant Secretary of State. He warned her bluntly that she would fail as Assistant Secretary if she did not correct course and she came to agree with that.
She was only thirty-two at the time and had never held a position like this before. In 1998, six months into her tenure, a series of crises hit. Africa’s “first world war” broke out and, then in August of 1998, Al Qaida attacked the American embassies in Kenya and Tanzania, killing twelve Americans and over two hundred Kenyans and Tanzanians. This was both a horrific loss and a policy blow for those who were working on Africa at the time. Rather than addressing the pain they were all feeling head on, her approach to dealing with it was to charge through it as she did her parent’s divorce. This wasn’t a leadership style that would work in that context and Howard Wolpe gave her the tough love she needed at the time. Over the Christmas holiday, she reflected on what he had told her and realized that he was right. She had to be more patient. She had to be more respectful and solicitous of other people’s views and perspectives.
Dave asked what she did first to make this change in her leadership style. Susan says she started by being more humble. She brought people into decision-making even if their recommendations were not ones that she ultimately accepted. She says, ”You can get a long way leading a team, even if many members of the team don’t actually agree with the direction you’re steering towards, if they feel that their advice, perspective, recommendations have truly been heard and appreciated.”
Dave asked how she ensures in meetings between high ranking officials that everyone is genuinely heard even when she doesn’t agree with everything they are saying. She says it is not just what happens when you’re sitting around the meeting table. It comes down to the preparations going into the discussion: the quality of the paper that lays out the issues and the actions and the coherence of the agenda. Managing the meeting, though, is the hardest part. You have to make sure the options are given due consideration and everybody gets a chance to express their judgment.
Apple Podcasts link: https://podcasts.apple.com/us/podcast/456-how-to-be-diplomatic-with-susan-rice/id458827716?i=1000466472793
Website link: https://coachingforleaders.com/podcast/be-diplomatic-susan-rice/
COURTLAND ALLEN ON SOFTWARE ENGINEERING UNLOCKED
The Software Engineering Unlocked podcast featured Courtland Allen, founder of the Indie Hackers podcast and community with host Dr. Michaela Greiler. Michaela asked Courtland what was different about Indie Hackers compared to the earlier startups he had founded that made for its success. He said that for Indie Hackers, his notion of a business idea changed. Back in 2009, if you asked him about a business idea, he would have described a product idea and wouldn’t have been able to say much about how to get the product in customer’s hands, how much to charge for it, or even who the customer was. With Indie Hackers, he was thinking about all aspects of the business.
She asked whether the original Indie Hackers idea was to build a community. Courtland said that while there was no desire to do a podcast at first, he always had a plan to build a community. He had multiple phases for Indie Hackers to go through to get to where he wanted it to be. Phase one was a blog where people who wanted to earn financial and creative freedom though revenue-generating side projects could go to find interviews Courtland had done with people like themselves. He figured these blog readers would subscribe to his newsletter and from there he would build a community forum where people could help each other. Somewhere along the line, the podcast was added based on community demand.
Michaela asked how Courtland managed to keep Indie Hackers successful as a business when similar communities are struggling. Courtland believes that there are a few principles behind the success of Indie Hackers. The first is that you are much more likely to generate meaningful revenue quickly if you are charging for something that each customer is willing to pay a lot of money for.
Regarding building a successful community, you have to start with your marketing. A community is a chicken-and-egg problem where the whole value of a community is the people inside it, making it really hard to start from nothing. With Indie Hackers, he started with content that brought in the people who could form the community. Courtland had thousands of people coming to the website before he turned it into a community.
Another example is dev.to. Its founder, Ben Halpern, spent years just growing his Twitter account, tweeting funny jokes and helpful tips for developers. When he launched his community, he was able to advertise it from his Twitter account.
A second thing you need to build a community is to seed it with discussions. As Courtland also described in an episode of Software Engineering Daily that I summarized in “Lighting Up The Brain and Joining A Gym”, he started his community by having conversations with fake accounts that were secretly also himself. Ben Halpern kickstarted the dev.to community with discussions with his friends.
Choice of topic is critical too. You want a topic that you can talk about forever. The dev.to community’s topic is software engineering. It is the perfect topic because lots of people are learning and trying to learn from each other and there are countless issues and frameworks to talk about. Similarly, there are countless topics and subtopics around founding companies.
As Courtland also said on Software Engineering Daily, you also need to think about the timing for when people get together and the space your community takes up. If you throw a party in a small room, you only need ten people to make that party feel like a success, but if you throw it in a football stadium, you need forty thousand people for it to feel like a success. It is the same with an online community. If you constrain it by saying something like, “Our community is just one discussion thread every Sunday at 3:00pm,” then even with ten people, that community can feel like it’s thriving.
He talked about how he got advertisers interested in Indie Hackers and how he eventually got Indie Hackers acquired by Stripe and now no longer spends time selling ads. Not much has changed, he says, now that he is an employee of Stripe because Indie Hackers and Stripe were aligned from the beginning.
Michaela asked why he decided, despite his desire to write as little code as possible, to create custom software for the Indie Hackers forum when he could have chosen third-party forum software. Courtland said he wanted Indie Hackers to have a strong brand and it is hard to have a strong brand if the thing you’re building looks like everything else. So he put a lot of time making the community unique. He spent a lot of time on the name of the community and the design of the website, all in support of having a strong brand.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/starting-profitable-business-in-six-weeks-courtland/id1477527378?i=1000465925620
Website link: https://www.software-engineering-unlocked.com/episode-12-profitable-business-courtland-allen/
MATT STRATTON ON HIRED THOUGHT
The Hired Thought podcast featured Matt Stratton with host Ben Mosior. Since his move from Chef to PagerDuty, Matt’s focus has shifted from software delivery and infrastructure code to incidents and outages. Ben brought up Matt’s talk “Fight, Flight, or Freeze — Releasing Organizational Trauma.” Matt’s motivation for creating this talk was his own treatment for PTSD and a discussion with J. Paul Reed where they kept seeing similarities between Matt’s experiences and what companies go through when they experience an incident.
Trauma occurs when our response to something is ineffective. Two people can have a similar experience and it can be traumatic to one person and just a bad day for the other. We respond to perceived trauma physiologically the same way as actual trauma. Events that are reminiscent of trauma that occurred to Matt as a child trigger him to have the same physiological response today.
Organizations do the same thing. An organization that has an outage that is similar to an event that happened before and, say, cost them a million dollars a minute, will react the same way. Just as an adult re-experiencing a childhood trauma because of a triggering event shouldn’t necessarily respond the same way, an organization needs to learn how to respond differently to these similar stimuli.
Matt talked about the window of tolerance beyond which you become activated and have an unhealthy response. He says that it can get spiky or you can get stuck-on or stuck-off. If you are stuck-on, you have anxiety and other symptoms. If you are stuck-off, there is lethargy. In an organization, we can get into a hyper-aroused state fearing any type of change, getting into analysis paralysis, or becoming over-vigilant. None of these states are healthy and they trickle down into the emotional health of employees. The good news is there are things we can do to help the organization be better.
Ben added that a lot of therapy is about building up the language to describe what is happening so that when it happens or when you are reflecting back later, you can share the experience and develop skills to lengthen your window of tolerance.
Matt talked about how in cognitive behavioral therapy we try to identify when a distortion occurs, knowing that the feeling we experience is not something we can change, but our response to it can be changed. In an organization, we can do the same thing.
Matt is striving to excise the word “prevention” from his vocabulary and instead become more resilient when something bad happens. For a person, this can mean that you can have something happen and then you can get back inside your window of tolerance quickly. For an organization, this means that an incident can happen and we can restore service and get on with business.
We need to normalize incident response. It is not an anomaly to have an incident. The irony is that we’ve gotten worse at responding to incidents as we’ve gotten better at distributing on call. Back in his days as a sysadmin, Matt was on call constantly and incident response was business as usual. Today, if you are doing a healthy on call rotation with developers on call in their own domain, you can be on call for a year and experience just two incidents. Then, when you have an incident, you freak out. You don’t want to be trying to remember how to do incident response and you don’t want to think of the response process as an exceptional thing that we only sometimes do.
Ben connected this to the book The Fifth Discipline. He says we always feel like we have to do something in response to something bad happening. The other thing the book points out is that whenever you are doing an intervention, yes, you may have short term actions that buy you time, but at all times, you need to be building capabilities. When you normalize incident response and you regularly show people what it looks like to work together in a high-pressure situation, you learn to respond to incidents in healthy ways.
Matt says we need to run our failure injection exercises and game days like real incidents. This is also an opportunity to train your incident commanders. In these scenarios, we know what’s wrong and we can bail out at any time. Then, when a real incident occurs at 2:00am some morning, the people who did the exercise associate the real incident with the calm exercise they did in the office on an afternoon.
Sometimes there are people who want run an exercise and not tell the incident response team what’s wrong. Matt has to explain to these people that it is not an exercise in troubleshooting or to stress test your people. You don’t need to inject stress into the people who work for you. You want to do the opposite. When we are doing incident response all the time as part of the regular cadence of work, when a real incident occurs, we will associate it with the positive physiology of our response during the exercise.
That means we should treat every incident the same, even false alarms. If you get a few minutes into responding to an incident and realize it is a false alarm, finish it out as an incident. Get on the bridge and do as you would in a real incident.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/6-organizational-resilience/id1479303584?i=1000466488009
Website link: https://hiredthought.com/2020/02/24/6-organizational-resilience/
LINKS
Ask questions, make comments, and let your voice be heard by emailing [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:
-
Jurgen Appelo on Agile Toolkit, Amitai Schleier on Mob Mentality, Colleen Bordeaux on Coaching For Leaders, Scott Hanselman on Hanselminutes, and Buster Benson on Lead From The Heart.
I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email [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 March 2, 2020. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers.
JURGEN APPELO ON AGILE TOOLKIT
The Agile Toolkit podcast featured Jurgen Appelo with host Bob Payne. Jurgen says that companies go through several stages in their lifecycle and investors make investment decisions based on what stage they think a company is in. Some investors, for example, wait until a company has achieved product-market fit before investing. At first, budgets are small because the risks are higher. Then, as more evidence is accumulated and the weaker companies have failed, the remaining companies get the bigger budgets. This is called an innovation funnel.
Seeing how well this works in startup funding, Jurgen started to see the benefit that this could have if adopted inside organizations. Corporations tend to invest in projects by predicting what ideas will succeed. Instead, they could create an ecosystem where all the ideas can participate and they would go through stages like a startup where they need to find product-solution fit, product-market fit, and those that make it to the end get the biggest funding.
They talked about business agility and Jurgen says that it is more important to focus on innovation and you will achieve business agility as part of the package.
Bob pointed out that organizations are setting up skunkworks and innovation labs but, unless they can integrate their innovations with the core business, they will end up like Xerox Parc and other companies will exploit their innovations and disrupt them. Jurgen says that this innovator’s dilemma, as described by Clayton Christensen, requires you to switch to the mindset that your products and services don’t have eternal life. This is normal for any organism, but a species can live forever. The innovator’s dilemma, he says, was solved millions of years ago in nature. We need to borrow this regeneration capability from nature and say that the innovation is not the product or service; it is the system for generating products and services.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/jurgen-appelo-startup-scaleup-screwum-lean-agile-dc-2019/id78532866?i=1000465296924
Website link: https://hwcdn.libsyn.com/p/2/d/3/2d3a6b2936031059/leanAndAgileDC2019_Jurgen_Appelo.mp3?c_id=64647230&cs_id=64647230&expiration=1582618595&hwt=2e7c8bfffbafc47eef3a10950edf34ae
AMITAI SCHLEIER ON MOB MENTALITY
The Mob Mentality podcast featured Amitai Schleier with hosts Chris Lucian and Austin Chadwick. As a technical Agile coach, Amitai likes to sit with programmers and program, sit with testers and test, and sit with managers and manage. He loves to put things in terms of cost and risk and one of his areas of specialty is legacy code.
When Amitai tried to make a career change from being a developer to being a technical Agile coach, he believed that if he could just say the right words in the right order with the right tone of voice, people would have to agree with him and behavior change would occur. This didn’t work. He realized that getting the words right is important, but you need to earn people’s trust first.
He pair-coached with Llewellyn Falco and this taught him about the synergy between mobbing and coaching. One example of that synergy is in how you know whether the coaching is working. You measure by observing whether the new behaviors the coach introduced continue to be practiced when the coach isn’t around. An expensive way to test this is, after a year of coaching them, go away for a year and come back and see what still gets practiced. A cheaper and more Agile way is to have an iteration with a feedback cycle where you visit just long enough for the team to form a new habit and go away long enough to see if the habit sticks.
Chris asked Amitai to talk about teams that he introduced to mobbing. Amitai described a team that had problems working together. Amitai had the program manager say to the team that, in the next iteration, if the team didn’t get fewer stories done, the manager would be disappointed because the team wasn’t trying hard enough to learn something. In practice, teams that start mobbing don’t slow down that much, but they need to hear that they’re allowed to.
As a result of the switch to mobbing, the person who had been keeping decision-making for himself started talking people through what he knew, people who had previously been uninvolved started to engage with the problem-solving process, and the whole team was energized by it. Amitai doesn’t love that he had to force it on them the way he did and prefers to invite people to change their behavior, but sometimes, he says, you have to manufacture the willingness.
Chris asked about the benefits and difficulties of mob programming with legacy code. First, Amitai said, mob programming is more extreme than Extreme Programming. If we were defining XP today, we would skip pairing and go straight to mobbing. Legacy code, or, valuable code we are afraid to change, is a kind of nexus of extremes as well. The cognitive challenges of software development are turned up all the way and mob programming is a great way to deal with these greater cognitive challenges.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/amitai-schleier-on-the-synergy-of-mobbing-and-coaching/id1485950034?i=1000463210922
Website link: https://mobmentalityshow.podbean.com/e/amitai-schleier-on-the-synergy-of-mobbing-and-coaching/
COLLEEN BORDEAUX ON COACHING FOR LEADERS
The Coaching For Leaders podcast featured Colleen Bordeaux with host Dave Stachowiak. Dave started by asking about a quote from Colleen’s book, “Am I Doing This Right?” The Charles Jones quote says, “You are the same today that you’re going to be in five years except for two things: the people with whom you associate and the books you read.” Colleen says that when she looks at the people from whom she has learned the most and the people who helped her become who she is today, she finds that they all credit their success to the relationships they’ve cultivated and the books they’ve read.
They spoke about the health implications of loneliness. Colleen says that our purpose and fulfillment in life and work is connected deeply to the relationships we cultivate and our ability to cultivate relationships is about being able to show up as ourselves.
To Colleen, authenticity means being open to connecting with people and sharing your real experiences, who you are, and the challenges you’ve had so that it gives others permission to do the same. People are craving real human connection and we need to a better job of facilitating it.
When Colleen was most lonely and isolated it was when she was in high school and her older brother became addicted to drugs, putting her family through an upheaval. Her high school and community had a culture of perfectionism and her family struggled not only with her brother’s addiction but also a fear of judgement from other people. Colleen felt she couldn’t share her feelings of loneliness with her friends or teachers because she didn’t know anyone who would receive it without judging her family. As she grew up and her family worked through it, she started to share her feelings and realized that the people in her network had their own struggles in their own families and were also afraid to share.
They talked about how the negative relationships in our lives can make us into destructive thinkers rather than productive thinkers. Colleen described a time when she fell victim to this. She was insecure, negative, gossipy, super-judgmental, and someone who would get jealous or envious when she saw people around her succeeding and happy. The root cause, she says, was that she was not introspective and had no control over her own mindset. She says you have to look at yourself and consider, “Am I a net-positive in the lives of the people who I surround myself with? Am I somebody who encourages, supports, and gives positivity and light to the people around me or am I somebody who is quick to judge, quick to shut down, and somebody who struggles to nip my negative impulses in the bud?” When Colleen helped herself evolve from a crab to a magnanimous thinker, her relationships blossomed.
She told a story about being on a huge project that involved constant travel and little autonomy. Instead of trying to fix the situation, she allowed her negativity to run rampant. She decided the problem was everybody else and the firm itself, so she went looking for a new job. She got an offer and she told one of her mentors. This mentor said, “Colleen, you can go ahead and take this job, but eventually you’re going to end up in the same situation. What are you going to do then?” She says that this hit her like a ton of bricks. Changing her circumstances might momentarily have distracted her, but it was her own thinking that was the real problem. Her mentor’s advice was that running away from things doesn’t move you forward. You are better off staying put, focusing on what you can control, and seeking what truly excites and energizes you to the point where you can’t stop thinking about it and you want to run towards it.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/455-how-to-create-great-relationships-colleen-bordeaux/id458827716?i=1000465792556
Website link: https://coachingforleaders.com/podcast/great-relationships-colleen-bordeaux/
SCOTT HANSELMAN ON HANSELMINUTES
The Hanselminutes podcast featured Scott Hanselman with host Jeff Fritz. For the first time in about 700 episodes, Scott Hanselman was the guest on Hanselminutes. This episode came from an interview he did with the Live Coders who write code live in front of an audience on Twitch.
Jeff asked first about Scott’s longevity. Scott’s blog has been going on for seventeen years and the podcast has been going on for fourteen years. The reason he has been able to do it consistently for that long is because he is not doing it five days a week. Scott says you need to set up systems by which your community can be self-sustaining and not require you to show up every single day.
The next question came from community member roberttables. He asked how Scott delegates responsibilities for aspects of a community when community mentorship is not part of your role. Scott says that one of the things he finds communities don’t do is they don’t express what their long term goals are. He compared it to a couple getting married and having wedding vows but no mission statement. He and his wife wrote a business plan for the community of two that they were creating.
When you put together a community, he says, whether it is a marriage or a community of fifty live coders, you set a tone. You have to make sure that 80 to 90% of the people are 100% behind the goals. Then, if a troll shows up, they are overwhelmed by the positivity of the group. That’s how you scale. It starts with two people agreeing on what they are doing.
As an example of doing this wrong, he talked about how Reddit communities have problems because Reddit wasn’t founded with the agreement that we would all be nice to each other. Now they are trying to retcon niceness into the community. Scott says, “You can’t retcon nice.”
The next question was from rockzombie2, who wanted to know how Scott grew his following. Scott says consistency is king. He asked, “How often have you visited someone’s blog and the very last blog post is a rededication of themselves to blogging?” That’s because people set up failure systems. Instead, it’s got to be something that you can’t ever stop. The interval between blog posts should be large enough that you start to miss it but not so large that coming back to it is a chore.
You also need to have an internal check-in where you ask yourself, “Does this feed my spirit? Is this the thing that makes me happy?” If you feel you need a blog to grow, then that’s the wrong attitude.
Michael Jolley, aka, BaldBeardedBuilder, asked how Scott manages the various kinds of content he produces. Scott says he keeps a backlog of ideas that are so good that they can write themselves. If he gets excited about something, he will both blog about it and reach out to someone related to the thing that has him excited and schedule a podcast.
KymPhillpotts asked about resources for improving interviewing techniques. Scott believes interviewing is similar to improv. Just as you would in improv, you want to use the concept of “Yes, and...” He also recommended listening to early Terry Gross interviews from the mid-nineties. He recommends ignoring the content and instead studying how she conducts the interview. He says that people seem to think that you can just turn on the mic and start interviewing people and it is going to go well. He argues that you need deliberate practice. You need to listen to yourself and watch yourself on video and learn what you need to do better. Being charming is an art. You can practice it and become better at it.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/myself-its-not-weird-at-all/id117488860?i=1000462813484
Website link: https://hanselminutes.simplecast.com/episodes/myself-not-weird-at-all-HZclNwEe
BUSTER BENSON ON LEAD FROM THE HEART
The Lead From The Heart podcast featured Buster Benson with host Mark C. Crowley. Buster has written a book called “Why Are We Yelling? The Art Of Productive Disagreement”. Buster started out by saying that disagreements as battles has been a useful tool for us as a species before we had institutions of reason and science. It was how you claimed your spot on the hill. While “might makes right” continues to be what we fall back to when everything else falls apart, it is no longer the most productive way to think about disagreement. The kinds of problems we face today and the arena that we’re having conversations in have changed. Before, it was about keeping the tribe together. Now, it is about creating relationships and collaborating across tribes. We need to train ourselves to become great collaborators and see disagreement as an opportunity and as a skill we can practice.
Mark brought up a statistic from Buster’s book that says nine in ten of us feel that arguments are almost always an unproductive venture. As a result, we steer clear of them. He asked Buster what he has learned about why having disagreements is so highly supportive of having healthy relationships.
Buster says that if you think about a disagreement as a milestone or landmark of something important that is currently in a stuck state and ask what, long term, is going to best guarantee the success of this relationship, it is about becoming high-functioning in terms of addressing and facing problems and resolving them. This is difficult because avoidance is natural. When you are thrown into an arena where you don’t have the skills to operate in it successfully, you naturally run away.
Buster talked about anxiety debt. These are the things you have not been able to face with confidence and they end up wearing you down, decreasing your happiness, and making you less healthy. Just as there is never an urgent need to clean up tech debt until it threatens the success of your company, anxiety debt in your relationships can be neglected and become harder and harder to address as it accumulates over time.
Mark asked how to get yourself centered so that you can have a disagreement that doesn’t knock you off your foundation. Buster says the first step is get over the misconception that we can change minds. Minds do change, but we don’t change them directly; we change them with our own mind changing. Rather than thinking “I’m going to move your mind from point A to point B”, think of your own mind and the other party’s mind each as a pile of rocks and you each have to contribute your rocks to building a new, third pile that incorporates both perspectives. This third perspective is more inclusive and transcends the problem. You don’t know in advance where the third perspective is and you have to use the other person’s perspective to triangulate it with your own. That means you have to use them as a resource rather than a receptacle of new information.
Mark asked about emotional situations where things are so polarized that each side thinks the other is crazy. Buster says that in these situations, the fact that we think each other is crazy raises the question, “What do I not know about you and what do you not know about me that makes us think each other is crazy?” To resolve this, you can ask questions that you don’t know the answers to. No matter what the other party says, it will give you new information and new insight into things. Mark asked for an example. Buster says that if you are with your polar opposite political opponent, you can ask a set of questions that help you understand how their beliefs arose. These questions take you out of battle stance and help you build a relationship with them.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/buster-benson-mastering-art-productive-disagreement/id1365633369?i=1000464961355
Website link: https://blubrry.com/leadfromtheheartpodcast/55513911/buster-benson-mastering-the-art-of-productive-disagreement/
LINKS
Ask questions, make comments, and let your voice be heard by emailing [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:
-
Mangler du episoder?
-
Dimitar Karaivanov on Agile Atelier, Claire Lew on The Product Experience, Eric Willeke on Agile Amped, Mike Bugembe on The Product Experience, Colleen Esposito on Hired Thought
I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email [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 February 17, 2020. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers.
DIMITAR KARAIVANOV ON AGILE ATELIER
The Agile Atelier podcast featured Dimitar Karaivanov with host Rahul Bhattacharya. Dimitar is an expert on scaling Kanban. Dimitar thinks of Agile as a company sport rather than a team sport. At the team level, scaling is horizontal. The more interesting kind of scaling to Dimitar is vertical scaling. If you have a hundred or a thousand teams, the real challenge is the coordination piece on top of those teams and the strategic piece on top of that. If you don’t have an optimized coordination layer that reduces the number of things the organization is working on, your organization is spread too thin. He explained the importance of teamwork and coordination using the metaphor of a band of musicians.
Scaling Kanban starts with a single team. What Dimitar likes about Kanban is that if you follow the basic rules, it always results in some kind of improvement.
Next, we want to connect the teams to a management layer that performs the coordination activities. People often perceive Kanban as a visual board with some sticky notes on it. Actually, if you go horizontally, then vertically, it is more of an instrumentation facility for your organization. Like a performance profiling tool, you connect Kanban to your organization and it provides entry points with time stamps and starts collecting data. With this profiler, you can dig in and find out what the slowest part of your organization is.
Rahul asked about roles in scaled Kanban. Dimitar says there are only two specialized roles called out in Kanban: the service delivery manager and the service request manager. Because one of the principles of Kanban is to start where you are, you do not have to change a lot about roles when you start using Kanban. The service request manager role just means having someone who is responsible for requesting work, such as product manager. The service delivery manager just needs to be someone who is responsible for ensuring the work gets done. This could be a Scrum Master or maybe just a team lead. If the organization is adopting Kanban as a whole, you will need someone on the strategic level that is connected to the Kanban system and has a say in what gets done and when.
Rahul asked about failures Dimitar has seen. Dimitar has seen problems in which training just the teams and expecting this to lead to business agility failed. Another route to failure was relying on tools to do all of the work of creating agility. He says you need people with personal agility. You need to find these people or stimulate your existing people to grow themselves so that they become agile in their mindset.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/episode-19-scaling-kanban-with-dimitar-karaivanov/id1459098259?i=1000464007645
Website link: https://rahul-bhattacharya.com/2020/01/29/episode-19-scaling-kanban-with-dimitar-karaivanov/
CLAIRE LEW ON THE PRODUCT EXPERIENCE
The Product Experience featured Claire Lew with hosts Randy Silver and Lily Smith. Randy started by asking Claire if she’s ever accidentally been anybody’s worst boss. This was the question that Claire herself had asked at the Business of Software conference in her talk, “The Accidental Bad Manager.” She says that, based on her data, the answer is “probably.” She says that 85% of the time companies are choosing the wrong manager or promoting the wrong people into the role. They’re choosing for a manager those individuals who were showing excellent skills and outcomes as an individual contributor, but those skills don’t transfer over when they become a manager.
Claire cited a Gallup study that found that there are five to seven traits that characterize the best managers and, yet, only one in ten managers possesses these traits inherently. Claire created Know Your Team because she herself had a really bad boss and he had no idea. The first thing that made this boss so bad was that he didn’t follow through on his commitments. Looking back, she sees this as a classic case of failing to build trust because he made promises and didn’t deliver.
When leaders think about trust, oftentimes their minds go to likability, team-building, and images of trust falls and happy hours. None of those things have to do with real trust, which is the ability to show people that you will do what you say.
A second thing that made this boss so bad was that he lacked an ability to communicate and share vision. This is a common problem because most of us get the definition of vision wrong. Claire says that vision is not what you do and it’s not how you do it; it is where you’re going. Vision is the strongest motivating force in a team and the most clarifying force for decision-making. Neither motivation nor decision-making were tenable under her bad boss because the vision wasn’t clear.
Lily asked how Claire designed Know Your Team. Claire says that the number of conceptions of leadership is as large as the number of people who have attempted to define the term. She believes the reason there are so many definitions of leadership and the reason that there is no agreed upon best approach to leadership is because, most of the time, the right thing to do is highly dependent on many factors: your own disposition, the team’s disposition, team dynamics, the market, the task at hand, etc. So the best thing to do is to compile as much data as possible and determine the two or three best things to focus on.
The best managers, she says, tend to focus on three things. First is trust. Second is honesty. Third is being able to create context in a team, that is, being able to understand and share where you are trying to go and what progress is being made along the way.
Lily asked how these areas of focus compare with the traits in the Gallup study Claire mentioned earlier. Claire says that the Gallup study identified temperamental characteristics like positive thinking, good judgment, and empathy, and Claire’s areas of focus represent the skills you can build and the things that you can do to make your team run better. But there are connections between the Gallup characteristics and Claire’s areas of focus: you need empathy to build trust, and you need good judgement to create context.
Randy asks why managers are the last to know that they are bad at this. Claire says the psychological reason is that we create a narrative for ourselves that fits with a coherent positive self-image. More practically, we are complicit in being the last to know for several reasons, including the fact that we don’t create an environment for people to tell us. As a result, people don’t speak up in the workplace and this is because of fear and a sense of futility; they believe that nothing would change. To resolve this, we need to be able to ask for feedback in the right way and we have to act on that feedback.
To ask for feedback in the right way, we need to be vulnerable. Tell people you are struggling. When you go first and you come from a place of vulnerability, you give the other person permission to be vulnerable themselves and you defuse the element of fear.
You also need to be specific. You can’t ask, “How’s it going?” Instead, ask something like, “What is one thing that we could have done better in the past quarter?” or “When is the last time you felt frustrated with your work?” or “Have you observed any micro-managing tendencies from me in the past few months?” or “Have we been all talk and no action on anything lately?”
Next, you need to act on the feedback. If asking questions is all about defusing fear, acting on the feedback is all about defusing futility. When you show people that their feedback is not in vain, that helps people to speak up. Some people think this means having to implement every single piece of feedback. Not at all. Acting on feedback can be as simple as thanking someone for their feedback or explaining why you are not doing something. As leaders, we often explain why we are doing something but we forget to share why we are not doing something.
The best way to modulate and calibrate the other person’s expectations so that they don’t think speaking up is futile is to say, “You’re not likely to see a ton of progress on this in the beginning but I will give you regular updates on the progress.” And then make sure you give those updates.
Another best practice for creating an environment where you are not the last to know is to ask people what their preferences are around feedback. They may want an email, a slack message, or a phone call. Another preference we often forget to ask about is how quickly to give feedback. They may want it right away, or scheduled for the next day or the next week. A third preference is their orientation toward conflict. Do they believe that conflict is healthy and necessary to be productive in a team or do they much prefer a low-conflict environment?
A manager should not just be looking to be a great manager or leader but to be the best manager or leader for each particular person and to know that this is going to require customizing your approach to every individual.
Randy asked what lessons people can learn about leadership if they don’t have direct reports but need to be able to influence without power. Claire says leadership is not about your title or the number of direct reports you have. At its most core form, leadership is about modeling the behavior that you want to be true of your team. Say you are so annoyed that your entire team is always late for meetings and late on deadlines. Instead of thinking you need to speak to someone or to manage up, one effective way of exhibiting leadership is to turn to yourself and ask, “To what degree can I model the behavior I would like to be true of the team?” A second way to exhibit leadership is to consider how you, as a teammate, can create an environment for those around you to do their best work.
Apple Podcasts link:
Website link:
ERIC WILLEKE ON AGILE AMPED
The Agile Amped podcast featured Eric Willeke with host Leslie Morse. The first and most critical thing Eric learned about WIP, or work in process, is to pay attention to how WIP cascades and multiplies in an organization. A single piece of strategic WIP equals hundreds to thousands of pieces of individual WIP. A lot of good work comes from corporate strategies, but there is too much of it.
Eric gave an example of a VP of product management whose work he helped visualize. They discovered that he had 38 initiatives that he had to report on for his eight teams. When you look at that kind of flood, there is little wonder that we are creating an inability to focus and limit work in process.
Eric no longer looks at the executive ranks and says they are to blame. He owns up to it and says that we are all to blame. He now feels empathy for the powerlessness that senior leaders feel in spite of their titles and maybe even because of their titles since those titles carry with them a kind of trap.
Eric has three strategies that he uses at organizations to reduce their WIP problems: 1) Start with alignment. Make sure people understand intent and purpose. Eliminate the excess WIP that comes from the “Am I in the right direction?” question. 2) Practice reduction in depth. According to Michael Porter, the essence of a good strategy is what you’re not doing. Help people learn what is not part of the strategy and generate focus. You may have to repeat yourself because, as Patrick Lencioni says, “You only get one message per quarter and you need to say that message hundreds of times.” 3) Create permission and safety as part of how you decentralize. When you decentralize, people need to have all the permission to take responsibility and the safety to try things, learn, and experience the associated failures that come with learning.
The conversation with leaders to get them to limit WIP is difficult. The leader starts with the best of intentions. If you come in too strongly with a message that they are doing it wrong, you are saying, “You were trying really hard in the best way you know how and you failed.” They didn’t. They were not responsible, necessarily, for all of the different pieces of WIP or how it cascaded, yet they have to take responsibility for helping people set things down.
One leader Eric is working with understands this and uses a quarterly message that says, “You may put things down, but you need to put them down gently.” A lot of people look at WIP and say, “We just need to throw away half the items in process.” But that hurts people, hurts initiatives, and hurts business leaders. So we need to know how to carefully set down the things we’re not going to do yet and bring everybody else along.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/too-much-wip-destroy-your-backlog/id992128516?i=1000463449566
Website link: https://solutionsiq.podbean.com/e/too-much-wip-destroy-your-backlog/
MIKE BUGEMBE ON THE PRODUCT EXPERIENCE
The Product Experience podcast featured Mike Bugembe with hosts Randy Silver and Lily Smith. Mike is the former Chief Analytics Officer for justgiving.com, which uses machine learning to try to increase generosity in the UK. When Mike joined, the company had in excess of ten years of data on people raising and giving money for causes they cared about. They used their technology to get a signal about what people were passionate about and used this to match people to causes.
They started by using a collaborative filter approach like Amazon’s “people who purchased your item also tend to purchase these items”, but charitable giving is so personal that collaborative filtering doesn’t work. Instead, using Nicholas Christakis’ research, they could see that connections between individuals could help them understand the flow of generosity and the flow of the things that are important to people.
Mike says that a lot of large companies talk about the fancy things they do with machine learning and data science like Facebook’s EdgeRank or Amazon’s and Netflix’s recommendation engines, but sometimes there are use cases that are unsexy but deliver a huge amount of value. For example, when people put a fundraising page on JustGiving, they have the option to specify a target. Only 30% of fundraisers were specifying such a target, but Mike found that this behavior led to much more money raised. So Mike created a machine learning system that predicted how much a fundraiser was likely to raise and pre-populated the target field. This was a lot of work to deliver one number on a screen, but this feature delivered an additional 7% on a 400 million pound business.
His approach to understanding where AI can deliver business value is to look at every business as a system of people making decisions, whether it’s marketers, product teams, or users. When you look at a product this way, the machine learning use cases float to the surface. You see where machine learning can make a decision more efficient, more automated, or more predictable. You then add a metric to each decision and see how decisions relate to each other or how they relate to key metrics you are trying to move.
Your data is quite unique to your business and your product. It acts like a fingerprint. One of the risks of data science is that it is an experiment every time you do it. Even if somebody else has done it before, you have no guarantee that when you do it you will get a successful result.
Product management teams that work with data science teams need to be aware that data science is not the same as delivering a feature with a software development team. It is an experiment. You have a question in mind and you have no idea whether or not the research will produce the result you’re expecting.
Lily asked Mike how he recommends people hire a data scientist. Mike says he is very much against the idea of hiring a data scientist just because they have a PhD. That’s a massive risk. You could get a PhD-holding job candidate who only understands regression and is not numerate enough to try a lot of the different algorithms that data scientists use. Mike himself looks for data scientists who have real life experience. This doesn’t mean they’ve worked in a lot of companies before. It means they’ve got things that they’ve produced. You can read and study, he says, but if you’ve never done it, you won’t know the gotchas and foibles that come with working with data.
Randy asked if there any guidelines or cheat sheets for people to educate themselves about bias in data collection, in algorithms, in assumptions, and in interpretation. Mike created a non-technical course for executives, product managers, and founders because they know their business better than the data scientists, in most cases. They add a layer of domain knowledge that helps reduce risk due to bias.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/cracking-data-code-mike-bugembe-on-product-experience/id1447100407?i=1000463981779
Website link: https://www.mindtheproduct.com/cracking-the-data-code-mike-bugembe-on-the-product-experience/
COLLEEN ESPOSITO ON HIRED THOUGHT
The Hired Thought podcast featured Colleen Esposito with host Ben Mosior. Colleen loves helping teams get started, helping them understand that Agile is about uncovering better ways of developing software, and helping them identify what Agile means for them. She also loves helping the managers, directors, and VPs to interact better with the teams so that the teams become empowered.
Colleen is a fan of invitation-based coaching and making sure the people understand the whys behind the change, what it looks like in the anticipated end state, and what steps the team may take to move towards that vision they’ve identified.
Colleen says that the first thing she does when she comes into a brand new organization is she tries to understand the whys behind their decisions. “Why did you choose to use Agile?” If what she hears is, “Twice the work in half the time,” then she knows that she might have to reset expectations.
Before starting an Agile adoption, Colleen gets everyone to think about the answers to some common questions like, “Why are we doing this? What’s in our way? What’s in our favor?” She says that if the leadership makes changes without involvement of the people, they are going to miss out on a valuable perspective.
Colleen says that the people who hire her often think that she is going to come into their organization and make huge, sweeping changes. Instead, in the very beginning, it is often small changes like connecting what a development team is doing with what an operations team is doing.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/5-building-bridges/id1479303584?i=1000464455334
Website link: https://hiredthought.com/2020/02/03/5-building-bridges/
LINKS
Ask questions, make comments, and let your voice be heard by emailing [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:
-
Kevin Callahan on Engineering Culture by InfoQ, Matt Wallaert on The Product Science Podcast, Mirco Hering on Troubleshooting Agile, Ryan Ripley on Agile FM, and Adam Tornhill on Maintainable.
I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email [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 February 3, 2020. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers.
KEVIN CALLAHAN ON ENGINEERING CULTURE BY INFOQ
The Engineering Culture by InfoQ podcast featured Kevin Callahan with host Shane Hastie. Kevin helps people solve complex problems together. Sometimes that looks like Scrum, Kanban, and technical practices, and sometimes that looks like organizational development and strategy.
Shane asked about positive organizational development. Kevin says that positive organizational development is an interconnected body of work with the core idea that true sustained change doesn’t happen when we simply try to fix things that are weak or broken. Positive change suggests that you go to the places that are already good and you amplify them and the places that weren’t working so well cease to be relevant.
Shane asked what this looks like in practice. Kevin says that, because he is actively inviting people into the room and looking to see what the group already knows together, he finds it energizing and refreshing and people lean into it and feel like they belong there.
Shane asked how someone in a position of influence who wanted to create some kind of change in their organization would approach the organization and their people. Kevin likes to start with open questions that get the people to imagine everything was right in the company and ask what people are doing differently, what customers are saying, what quality is like, and what stories people are telling each other when they don’t think anyone is listening.
These positive questions get people to imagine what could be and starts in motion the change effort that makes it possible to achieve the change. You may get answers like “I only want to work four hours a day,” or, “I want six months of paid vacation,” but eventually you may get answers like, “I really wish I had the opportunity to learn more things.”
Shane connected Kevin’s ideas to Dave Snowden’s notion of sense-making and asked how you make sense from non-viable statements like, “I want to work four hours a day,” so that you arrive at more viable questions like, “How do I stay at home more?” Kevin says that instead of reacting to non-viable requests by blowing them off, ask follow up questions to build a bigger narrative. You could ask clean language questions like, “What kind of four hour workday? What would come before your four-hour workday? What would come after?” This builds a bigger narrative that helps you respect something that is valuable to this person while still respecting the organization’s collective needs.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/kevin-callahan-on-positive-organisational-design-complex/id1161431874?i=1000462364585
Website link: https://soundcloud.com/infoq-engineering-culture/kevin-callahan-on-positive-organisational-design-and-complex-systems
MATT WALLAERT ON THE PRODUCT SCIENCE PODCAST
The Product Science Podcast featured Matt Wallaert with host Holly Hester-Reilly. Trained as a behavioral scientist, Matt is Chief Behavioral Officer at Clover. He says he is always fascinated by outliers, those customers that are using his products in unconventional ways. He says that having conversations with these users can sometimes push you in startling directions to build new things or think in different ways.
The behavioral science team is given behavioral outcomes that the company needs to accomplish such as, “everybody needs to get a flu shot,” and figure out what needs to be done to make it happen. They look at two groups of outliers: people who consistently did it and suddenly stopped and those that consistently did not do it and suddenly started. They found that people who get the flu shot for the first time often do so because of the birth of grandchild. This led them to start a flu shot campaign that was personalized to your personal health goal. Instead of saying, “You should get the flu shot for you,” it often said, “You should get it so you don’t get your wife sick, so you don’t get your grandchild sick, or so you don’t get your church congregation sick.”
He contrasted this collectivist form of motivation with products like Spotify that are all about benefitting the user directly. Expanding the set of motivations we examine to include people’s willingness to do things on behalf of another person, on behalf of a culture, or on behalf of an identity, he says, is undeveloped in modern product management.
If there is a number one product hobgoblin of early founders, it is their belief that the pros outweigh the cons. They massively overweight the pros and massively underweight the cons. But lately, there have been a whole host of startups that are not about providing additional value but simply about minimizing costs, and not just economic costs but also mental attention costs.
Finance companies think about their products as “share of wallet”. For, say, American Express, of the financial transactions that a customer performs, they want to know how much of that is going on an American Express card. Their job is to maximize this share of wallet. Similarly, Facebook attempts to maximize share of attention. This is an impoverished view of product-building. Companies like this are leaving off the “I” in ROI.
One of the problems of the “share of attention” view of the world, is that it means everyone is in competition with everyone else. Even products that seem far apart, such as a product in the exercise space and one the video game space, are competing for share of attention. Matt thinks people are going to get smarter about where they spend their attention. A whole new product class will come out around automating the things we don’t care about. The rise and fall of Blue Apron, he says, was a dramatic characterization of the misunderstanding of automation. Blue Apron sold the world on automated food. That is not what Blue Apron is.
They went on to talk about the desire for statistical significance in every experiment and how the context of the experiment drastically affects how much certainty is really needed. He talked about how most quantitative analysts who see an intervention that is measured to work 80% of the time in the sample of the population measured would say, “I got nothing,” and end the experiment. So Matt says, “Let me tell you about this intervention: It is a tiny pill, dissolves in your mouth, has no side effects of any kind, costs a penny to produce, tastes like unicorns and rainbows, and instantly cures all forms of cancer forever. Maybe we should further investigate this intervention.”
He compared his book Start At The End to Thaler and Sunstein’s Nudge. His book is more about how to create a process, a team, and an organization around behavioral science approaches. Instead of running his team as a research organization, he runs it like a factory. This makes it easier for an executive to understand how it all works. He says his book is more a handbook. Half the book is how you go about building the intervention design process and the other half is more advanced topics. He is seeing it being taught in college courses in disparate programs, including business administration, marketing, and implementation science.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/matt-wallaert-hypothesis-great-product-teams-use-behavioral/id1451623431?i=1000462456956
Website link: https://anchor.fm/product-science-podcast/episodes/The-Matt-Wallaert-Hypothesis-Great-Product-Teams-Use-Behavioral-Science-to-Build-Products-That-Create-Change-ea3s54
MIRCO HERING ON TROUBLESHOOTING AGILE
The Troubleshooting Agile podcast featured Mirco Hering with hosts Douglas Squirrel and Jeffrey Fredrick. Mirco is the author of DevOps for the Modern Enterprise. They talked about dogmatism. Marco says that he sees Agile and DevOps as a toolbelt to solve problems in organizations but not everyone he works with thinks this way. One of the Agile coaches he once worked with said on his first day, “You shouldn’t call these user stories. They are PBIs (product backlog items).” Mirco asked, “What value would that provide? Nobody was confused about the term user story. If anything, you are now adding confusion.” He sees this kind of dogmatism in many organizations.
He says that, for him, being pragmatically agile always comes down to identifying the next experiment and having rigorous continuous improvement. Squirrel asked Mirco how one can help companies that aren’t familiar with agile ideas to avoid the dogmatism and make the pragmatic choices that improve their process. Mirco believes it starts with value stream mapping. This gives you a good visual of the overall process and you can identify bottlenecks, quality holes, and things that take too long.
Jeffrey brought up the book Crossing The Chasm and how the early majority change because they don’t want to be left behind and the late majority change because the new behavior is the standard. He asks how, when this is their motivation, do you help the business to get from “we need to be Agile to be Agile” to “having a purpose.” Mirco says that, very early on, you need to ask, “How will we know we’ve been successful?” Mirco sees companies at conferences describe a world where they can do forty deployments a day and have all employees singing and dancing everyday. They are not anywhere close to this ideal. They need to figure out how to see in two months time that they are making progress. They should be able to ask, “What does the business want to do that it can’t do now.”
As a consultant, the very first thing you do is listen. Often they start to tell you some stories. Then you start trying a couple of ideas. You could do a bit of decoupling on the architecture or a bit of Agile coaching on a failing Agile project. You have a large tool belt of tools to choose from.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/devops-for-the-modern-enterprise/id1327456890?i=1000462577701
Website link: https://soundcloud.com/troubleshootingagile/devops-for-the-modern-enterprise
RYAN RIPLEY ON AGILE FM
The Agile FM podcast featured Ryan Ripley with host Joe Krebs. Ryan was on to talk about the book he co-authored with Todd Miller called, “Fixing Your Scrum.” He says that the book came out of a conversation he had with Todd two years ago about the Scrum anti-patterns that they were seeing in the wild over the past twenty years and how the two of them, as consultants, solve them.
Most Scrum books are very theoretical. Ryan and Todd, by contrast, spent only one page on the Scrum framework and jumped right into advanced topics. Joe brought up that Scrum tends to turn into something robotic and oriented around checklists. Joe considers this form of Scrum to be lifeless and low in energy. He finds that nobody leaves the events with a smile on their face and he wonders how the book would help such people.
Ryan says that such mechanical Scrum is very common and it is because the principles and values are lacking. It becomes rote and legalistic. He says that he and Todd don’t care that much about Scrum. Instead, they care about empiricism and want to bring forward transparency, inspection, and adaptation, and use the Scrum values of focus, openness, courage, commitment, and respect to make adaptations to products as needed to deliver the right thing at the right time to the right customer. Without having the values in place, empiricism can’t work. Companies have gone to the mechanical version of Scrum to avoid empiricism.
Empiricism is table stakes now. Twenty years ago, empiricism was a cute idea that people could dismiss because the blue chip companies were fat, happy, and dumb. Their problem was success. Today, no matter what industry you’re in, banking, taxi cabs, or real estate, there is a startup looking to destroy your market. He asks, “Who would have ever thought the taxi cab industry would be upended by Uber and Lyft? Who would have ever thought that the largest real estate company in the world would own zero real estate and be Airbnb?”
Joe asked about the sentence, “The Scrum Master’s work is never done.” Ryan says that the statement comes from the rapid rate of change today. He and Todd believe that the majority of times a Scrum team fails, it is because a Scrum Master is settling. The Scrum Master is tolerating organizational or team impediments.
The reason a Scrum Master’s job is never done is that those impediments morph and change and emerge constantly. Ryan has yet to see a company where nobody leaves, markets don’t shift, and budgets don’t become constrained. As Scrum Masters, our role is to help organizations make sense of the complexity through the use of the Scrum framework and to help teams refocus and reshape what they could and should be doing to serve a customer.
Ryan says nothing about the Scrum Master role is about the Scrum Master. When Ryan transitioned from a project manager to a Scrum Master, this part was difficult for him. Back when Ryan was a project manager, everything was about him: he was the one making the decisions, driving people to a date, or getting in front of boards of directors and making a speech. As a Scrum Master, we are in the back of the room watching the dev teams show off their software. None of this is about the Scrum Master. The job is to serve others.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/ryan-ripley-agile-fm/id1263932838?i=1000462512766
Website link: https://agile.fm/agilefm/ryan-ripely
ADAM TORNHILL ON MAINTAINABLE
The Maintainable podcast featured Adam Tornhill with host Robby Russell. Robby started out by asking Adam about the common traits of a maintainable solution. Adam first likes to see the solution optimized for understanding. Second, he wants to see alignment between the architecture, the team boundaries, and the way the system evolves. Last, he wants the capability to deliver anytime with known quality.
In terms of team boundaries, Adam wants to avoid having multiple teams working in the same parts of the code for different reasons because that has a high correlation to quality issues and makes it hard for individuals to maintain mental models of the system. He says you want clear operational boundaries between teams but then you also want each team’s knowledge boundary to be slightly wider so that you are familiar with other parts of the system and know other teams’ members as people.
Robby asked what about a separation between a team working on new features and another fixing bugs. Adam is not a fan of that form of separation because it cuts out an important feedback loop.
Robby asked what other developers get wrong when discussing technical debt. Adam says that many developers call any code that’s bad technical debt, but to Adam, it is not technical debt unless you have to pay interest on it. With a high degree of technical debt, you tend to see lots of effects on the product roadmap, you get longer and longer lead times, and your end users experience defects that take a long time to fix.
Robby asked about Adam’s book on behavioral code analysis, Software Design X-Rays. In behavioral code analysis, the emphasis is placed more on the organization and the developers building the code than on the code itself. You analyze using measurements from version control data and project management data and it is used to prioritize technical debt or reason about social factors of software development projects.
Some examples are detecting knowledge gaps in the code, code written by developers no longer present, or uncontrolled coordination needs between different developers in the code.
Robby asked what motivated Adam to write the book. Adam says that Software Design X-Rays follows in the tracks of his first book, Your Code As A Crime Scene, which was written to share techniques Adam had been using in his consulting work. The theme for both books is, “How can you make it easier and cheaper to maintain your software?” There are several patterns he uses often. One is the concept of hot spots, which help identify complicated code that we work with often. The data shows that any application can have its hot spots narrowed down to two or three percent of the codebase. This is a positive message that tells us we don’t need to rewrite whole programs but can make big improvements by changing only a small percentage of the product.
Robby asked how to prioritize work on technical debt reduction. Adam says to prioritize the most complex modules using hot spot analysis. With slightly more advanced analysis, you can get hot spots down to the function level and get quick wins within days. For your initial refactorings, you should use techniques like mob refactoring to help spread knowledge of how to attack these kinds of problems and get everyone to align on the approach.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/adam-tornhill-prioritizing-technical-debt-behavioral/id1459893010?i=1000463144606
Website link: https://maintainable.fm/episodes/adam-tornhill-prioritizing-technical-debt-with-behavioral-code-analysis-yigwD2Ga
LINKS
Ask questions, make comments, and let your voice be heard by emailing [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:
-
Johanna Rothman on Programming Leadership, Thomas “Tido” Carriero on Product Love, Adam Davidson on Lead From The Heart, Josh Wills on Software Engineering Daily, and Amitai Schleier on Programming Leadership.
I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email [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 January 20, 2020. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers.
JOHANNA ROTHMAN ON PROGRAMMING LEADERSHIP
The Programming Leadership podcast featured Johanna Rothman with host Marcus Blankenship.
Marcus started out by asking Johanna why it is important to think about managing ourselves. Johanna says that when we don’t manage ourselves, we don’t have the capability to manage other people. For example, if we insist on micro-managing people, they cannot grow and we prevent them from doing their best work.
Marcus asked her what micromanagement has to do with managing ourselves. Johanna says that micromanagement comes from fear. You need to learn to manage yourself to manage this fear and reduce your need to micromanage.
She says the reason the first book is about managing yourself is that if you can avoid doing the things that make people feel badly, you can create an environment where people can excel.
They talked about surveys and Marcus asked Johanna’s opinion on anonymous versus named survey responses. Johanna says that when you have a culture where there is a lot of blaming and micromanagement and little coaching, she would recommend an anonymous survey.
Marcus talked about how technical managers often know how to do the work itself very well and he asked Johanna when this can trip us up. One way it trips us up, she says, is that people on the team don’t get a chance to practice if the manager is writing code instead of managing. Second, when you have not been in the code in a while, you do not know what it looks like anymore.
Marcus asked how managers can get time to think in today’s high time-pressure environments. Johanna says that if you are spending a lot of time in meetings, you should be looking at whether you can delegate any of those meetings to the people doing the work. This delegating is not sloughing off your responsibilities, but making sure you are not part of a team that you are not supposed to be a part of.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/becoming-better-manager-means-starting-yourself-johanna/id1461916939?i=1000460138590
Website link: https://programmingleadership.podbean.com/e/becoming-a-better-manager-means-starting-with-yourself-with-johanna-rothman/
THOMAS “TIDO” CARRIERO ON PRODUCT LOVE
The Product Love podcast featured Thomas “Tido” Carriero with host Eric Boduch. Tido oversees all of engineering, product, and design at Segment. Segment provides customer data infrastructure or CDI, helping companies collect, unify, and connect data about their own interactions with their customers. It gives these companies a unified view of their customer data across all channels.
When he joined Segment, Tido was blown away by how robust the ecosystem was and by the attractive idea of empowering business teams, marketing teams, and product teams by installing application tracking once and being able to turn on integrations with the flick of a switch. Often, he says, a lot of business and marketing and less technical folks are blocked from doing the best job they could do because of tough integration problems that Segment solves.
Segment naturally has a lot of adjacencies. They touch critical customer data and they need to decide whether to use that to empower engineering, marketing, or others. This requires being clear at the beginning of the year that they will pick two or three bets as an organization to focus on.
Eric asked Tido what product leaders often do wrong. Tido says the biggest mistake product leaders make by far is not looking in the mirror and making an honest assessment of where things are. Getting attached to an idea makes it harder to give it a critical look. Often, you’re only a small pivot away from a valuable product. As the leader of an organization, he sees his job as creating a culture where failure is not just okay but celebrated. If people are getting slapped on the hand for failure, they will just get even more committed to their first ideas. Healthy teams that seriously innovate look at the data and are willing to pivot when it tells them unpleasant things.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/thomas-tido-carriero-joins-product-love-to-talk-about/id1343610309?i=1000459980786
Website link: https://www.spreaker.com/user/casted/edited-tido-joins-product-love-mp3
ADAM DAVIDSON ON LEAD FROM THE HEART
The Lead From The Heart podcast featured Adam Davidson with host Mark C. Crowley. Adam Davidson is the creator of the Planet Money podcast and is staff business writer at The New Yorker. He has a new book called The Passion Economy. The theme of the book is that choosing your career used to mean choosing between work that makes your heart sing and work that pays well but disconnects you from your passions, but the new world order demands that we follow our passions and pursue work that leverages both our talents and our interests.
Adam’s grandfather worked his entire career in a ball bearing factory and only made a good living by working double shifts. He believed that people who follow their passions go nowhere in life.
Adam’s father was the opposite. Making money was far less important to him than following his dream of performing as a Broadway actor.
These two men represent the dichotomy of having to choose financial success or your passion but not both.
The people of Adam’s father’s generation and his grandfather’s generation had to choose between a life of passion and a life of financial success, but people today, Adam says, are lucky. They are lucky for the reasons that terrify us. Adam says, “All of these forces that have done so much damage to the stability of the 20th century economy also provide exactly the tools that allow us to figure out what we uniquely love and are good at and find those people, even if they’re thinly spread all over the country or all over the globe, who also crave what it is we can provide and are willing to pay for it.”
Mark summed up the book as being about combining your training and expertise with a personal passion to find your own niche. According to Adam, some people take a total left turn and go into a completely different field later in their lives, but the most successful people he has met combine their passion with the skills they have previously acquired.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/adam-davidson-new-rules-for-thriving-in-twenty-first/id1365633369?i=1000462188105
Website link: https://blubrry.com/leadfromtheheartpodcast/54035306/adam-davidson-the-new-rules-for-thriving-in-the-twenty-first-century/
JOSH WILLS ON SOFTWARE ENGINEERING DAILY
The Software Engineering Daily podcast featured Josh Wills with host Jeff Meyerson. Josh Wills was the director of data engineering at Slack when Slack was building out a solution to scaling its data infrastructure. When the first analysts at Slack were hired, their only option was to spin up their own little databases that had cached copies of Slack’s main transactional database. Eventually, Slack hired data engineers that built systems that could scale up what an analyst could do.
They built up a lot of infrastructure involving Airflow jobs producing Parquet files on S3 that were queryable through tools like Presto and it was, according to Josh, a “ghost city” for a while. All the while, the analytics team was still using the existing infrastructure of ETL jobs running on the transactional database. It wasn’t until Slack started aggressively hiring analysts, data scientists, and engineers from the Googles, Facebooks, and Twitters of the world that they had people who knew how to use the stuff Josh and his team were building.
Jeff asked how the various design philosophies coming from the new hires from Google and Facebook got resolved. Josh said it got resolved by him making all the decisions. There were a million things to do, so the design direction was often the result of whoever was the first mover.
If Josh had it all to do over again, he would do many things differently, but he knows that nobody would appreciate it because they would have never experienced the inferior designs. It is hard to appreciate the pain that something saved you. Most of your good decisions are invisible and taken for granted while your bad decisions cause pain and suffering forever.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/slack-data-platform-with-josh-wills/id1019576853?i=1000462100792
Website link: https://softwareengineeringdaily.com/2020/01/10/slack-data-platform-with-josh-wills/
AMITAI SCHLEIER ON PROGRAMMING LEADERSHIP
The Programming Leadership podcast featured Amitai Schleier with host Marcus Blankenship. Amitai talked to Marcus about his fork of qmail called notqmail. Qmail is a Unix program for running an email server that, unfortunately, hasn’t been updated in twenty years and has a number of rough edges.
Over the last twenty years, Amitai has invested time into softening qmail’s rough edges through improved package management. More recently, Amitai started thinking about getting the people who are working on their own forks of qmail to collaborate on a single fork.
The first step was getting some advice. A key piece of advice came from Llewellyn Falco. Llewellyn said, “Qmail already has a lot of nice seams and interfaces. Without too much more work and risk, you could add a couple more seams so that whatever modernization is required could be done as plugins or extensions. The next problem to think about is egos. Not all ideas are going to win.” He then gave Amitai the best piece of advice: “Whatever you do, offer yourself to other programmers to get their code converted to extensions first. As to which implementation of a particular new feature is to be incorporated, that decision is not your call. Take as extensions as many implementations as people want to give and let users decide.”
Marcus asked about how to influence a group of people on a project without being coercive. Amitai says that he discovered years ago that when a situation is a little confused, his default response is to seek to lower his perceived social status. Otherwise, he cannot influence the way he wants to if he’s a big shot that people are supposed to listen to.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/collaboration-and-notqmail-with-amitai-schleier/id1461916939?i=1000462047766
Website link: https://programmingleadership.podbean.com/e/collaboration-and-notqmail-with-amitai-schleier/
LINKS
Ask questions, make comments, and let your voice be heard by emailing [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:
-
Neil Pasricha on Coaching For Leaders, Corey Quinn on On Call Nightmares, Craig Daniel on Build by Drift, and Bryan Liles on Hanselminutes.
I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email [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 four podcast episodes I found most interesting and wanted to share links to during the two week period starting January 6, 2020. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers.
NEIL PASRICHA ON COACHING FOR LEADERS
The Coaching For Leaders podcast featured Neil Pasricha with host Dave Stachowiak. Neil described his first professional role, working at Proctor & Gamble. He had graduated from Queen’s University in 2002, one of the top business schools in Canada and, at the time, a job at Proctor & Gamble was one of the top marketing jobs you could get. Neil felt like Charlie Bucket winning the golden ticket.
But he was horrible at the job. He had been expecting to spend his days creating PowerPoint presentations and instead was asked to create spreadsheets to analyze trucking, gasoline, and a million other variables to determine how much to increase the price of mascara.
As a high achieving adolescent, he took his failure to be his own fault rather than a factor beyond his control. He worked late, came in on weekends, and started grinding his teeth. A few months in, the company wanted to put him on a performance improvement plan. He couldn’t handle the notion of being fired, so he quit nine months in.
He catastrophized this event. He thought, “If I can’t work here, at the best company, with the most supportive culture, kind people, and a lot of structure, I can’t work anywhere.” He thought, “If I can’t do marketing, my highest mark in business school, I certainly can’t do finance,” and, “If I look for another job, they’re just going to call P&G who will say ‘This guy is horrible.’”
He pictured the worst-case scenario: he thought he would go bankrupt and thought his life was over as a working person. He calls this, “pointing the spotlight at yourself”. High achievers have a tendency to think, “It’s all about me and I’m terrible.”
He was a low-resilience person. He wrote his new book, You Are Awesome, about resilience because he identified himself as lacking it. Like most of us these days, he grew up without famines, wars, and other sources of societal stress. He got the gold stars and participation ribbons and didn’t have the tools to handle failure.
He didn’t see for years that the P&G blow actually was his first lesson in resilience. He says we look at successful people and think their lives were a string of successes, but the most successful people are those that have also seen the most failure.
He cited Cy Young, who has won the most games in baseball ever. He also has the most losses. Nolan Ryan, who has the most strikeouts, also has the most walks.
Dave talked about his first full-time role as director of a center that helped students learn math and reading skills. He was average at the job and the culture wanted people to show a lot of initiative. He struggled, got passed over for promotions, and the feedback he was given was that he wasn’t moving fast enough, wasn’t taking initiative, and wasn’t meeting deadlines. Like Neil, Dave dropped out and started his coaching business.
Neil says that Dave’s and his own feelings of incompetence are a result of the spotlight effect. The spotlight effect is the feeling that we’re being noticed, observed, and judged more than we really are. Nobody at P&G probably even remembers Neil, but the spotlight effect had caused Neil to feel that everybody had watched him fail.
To help reduce this effect, Neil asks himself three questions: 1. “Will this matter on my deathbed?” 2. “Can I do something about this?” And 3. “Is this a story I’m telling myself?” For example, if you fail a biology test, the story you might tell yourself, “I failed my parents.”
Dave asked whether Neil is now comfortable with being uncomfortable. Neil had thought that he had reached a point where he was finally comfortable with being uncomfortable, but when he left Walmart to take his side hustle full-time, he suddenly felt uncomfortable again. He says you have to treat it like yoga. You have to keep learning it until you learn it.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/448-the-value-of-being-uncomfortable-with-neil-pasricha/id458827716?i=1000461086169
Website link: https://coachingforleaders.com/podcast/value-being-uncomfortable-neil-pasricha/
COREY QUINN ON ON CALL NIGHTMARES
The On Call Nightmares podcast featured Corey Quinn with host Jay Gordon. Corey started his on call career in what he called an “abusive” environment. One year in, a new manager was dropped in and the first thing this manager decided was that he wasn’t going to be on call himself. The number of people on call dropped from four to three and then another person left. So Corey was on call 50% of the time and he could never schedule his life around it.
At the end of that time, Corey swore he would never put himself in this situation again. When he started the Duckbill Group, he decided that anything he did would be “business hours only”.
Jay asked Corey what in 2019 most excited him in the world of cloud. Corey said that it was the awareness by the providers that building the fastest, most exciting, far fetched, far flung technologies was not going to be what won them the hearts and minds of their customers. Instead, he saw the large providers speaking to enterprises about migrating from data centers to cloud environments.
They talked about Microsoft’s advantage in selling the cloud to enterprises. Corey says one of Microsoft’s big advantages in cloud is that they have forty years experience apologizing for software failures. Explaining these failures to non-technical audiences is something Microsoft excels at and Google and Amazon have had to learn.
Jay brought up that the embrace of managed Kubernetes was a big trend in 2019. Corey says that his objection to it is that if you run everything on top of Kubernetes, you’ve abstracted away what you’re doing from the cloud providers’ built-in primitives so much that it becomes challenging to do workload attribution of cost. Programmatically figuring out which workload is the expensive one is surprising difficult.
Jay talked about Hashicorp’s rise in 2019, providing tooling around cloud agnosticism. Corey said that one of the best conversations he had on his own podcast, Screaming In The Cloud, this past year was with Hashimoto. Hashimoto argued that Terraform provides workflow portability rather than workload portability and that one is worth pursuing and the other one is not.
Jay said that this was the first year that Amazon talked about multicloud. Corey says they talked about hybrid but still avoided multicloud. Corey believes that every cloud provider hates multicloud until they realize a large customer is going to go with a different provider, then multicloud is wonderful.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/episode-46-year-in-review-corey-quinn-duckbill-group/id1447430839?i=1000460596737
Website link: https://www.podomatic.com/podcasts/oncallnightmares/episodes/2019-12-23T11_00_16-08_00
CRAIG DANIEL ON BUILD BY DRIFT
The Build podcast by Drift featured Craig Daniel with host Maggie Crowley. Their topic was “What does Drift look for when hiring product managers?” Craig says that the product manager role is unique in that you don’t have direct reports but you need to be able to influence the engineering team, the designers, and a slew of stakeholders that includes customers.
Regarding technical skills, Craig says they look for systems thinkers with the ability to break down a problem, articulate their breakdown, look at data and combine that data with qualitative research.
Maggie asked about hiring for associate PM roles and Craig says it goes back to a core principle that a person’s aptitude and attitude outweighs their experience. Craig defines aptitude as a combination of ability to learn and curiosity. These people are those who can grow faster than normal.
Maggie added that these people are paying attention to the world around them, are asking questions of the tools that they’re using, and are not just assuming things are the way they are.
For more experienced hires, Craig is looking for results. Sometimes there are good people who were in bad companies or joined a startup prior to product-market fit that never got off the ground. If they don’t have results, you want to see outputs: shipping things, building partnerships, and media coverage. People who are successful in product are those that can build coalitions, roll up their sleeves, do the hard work, and get stuff done.
Maggie says that PMs can be afraid to be accountable for the end result. It is easy to say, “I wrote my one pager,” “I wrote the spec,” or “We stuck to the timeline.” There are so many excuses that you lose sight of the fact that you need to be accountable for results.
Regarding the interview process, Craig says Drift’s process consists of a design leader interview, a product team interview, an executive interview, and something called, “The Who method.”
Craig himself is looking for fit. This is not culture fit. It means, “What is this person great at, what do they want to do, and what do we have available or can make available?” To get at fit, Craig asks about their superpowers. If they’re at a company with, say, five product managers, what would everyone say they are the best of the five at? What are they worst of the five at?
He also wants examples of truly exceptional work. This tells him what they think exceptional is, what their emotional intelligence is (are they a braggart?), and what their value system is.
Craig says he has made a lot of mistakes over the years hiring PMs and, as a result, has learned to be more systematic about it. You have to have a practical part of the interview where you have the candidate go to the whiteboard, break down a problem, or tell the interviewer about work they’ve done in the past. A particularly good practical problem is to have them talk about a product they use everyday and describe both what’s great about it and what needs to be improved about it.
They talked about the Who method (https://www.amazon.com/gp/product/0345504194). For example, if the candidate tells you they were responsible for a half-a-million user product, the Who method lets you find out how much of that was their responsibility versus something they are just taking credit for. He talked about an aspect of the Who method called the threat of reference check. You ask the candidate, say, who their previous manager was, and then say, “When I call your previous manager, what are they going to say about you?”
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/what-really-matters-when-hiring-a-pm/id1445050691?i=1000461459804
Website link: https://www.spreaker.com/user/casted/what-really-matters-when-hiring-a-pm
BRYAN LILES ON HANSELMINUTES
The Hanselminutes podcast featured Bryan Liles with host Scott Hanselman. Scott started out by asking Bryan what he means by “a complete engineer”. Bryan says he has rules for everything and rule #1 is that there is a competition out there but you are only competing with yourself. You can watch what other people do and you can emulate them, but don’t compare yourself to others.
Regarding being a complete developer, he says you have two aspects of being a developer: 1) writing software for money and 2) providing an impact to the world. That impact may be helping other developers level up, providing a role model, or simply doing no harm.
Growing up, Bryan’s dream was simply to have a better life for himself than his parents had. Now, he wants to show people that his life was not a fluke but is a result of preparing himself for opportunities. The world Bryan wants to live in is one in which we’re trying our best and we’re also looking out for the people that come after us.
Bryan talked about his recent project Octant that is a console for showing what’s going on in your Kubernetes cluster. He says that often we start to make a product and we start listing a bunch of features we want it to have. He says this is like that friend that talks too much and tells boring stories that go on for too long. We all prefer the friend who tells simple stories and it is the same with software products: you need to start off simply and solve one problem at a time.
The interview ended with Bryan’s three pieces of advice that he gives to all black males that he meets. First, he says to ignore the advice that says you have to be the dumbest person in the room. That works when you have privilege and you have a safety net. Instead, be the smartest person in the room, but don’t tell anyone. Second, opportunity is rare, so when it comes, be ready. His third piece of advice is to get used to, but not comfortable, with failure.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/being-a-complete-engineer-and-bryan-liles-rules-to-life/id117488860?i=1000460922091
Website link: https://hanselminutes.simplecast.com/episodes/being-a-complete-engineer-and-bryan-liles-rules-to-life-BiK2k99r
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:
-
Scott Belsky on Product Love, Beth Long on Maintainable, Mark Schell on Agile Uprising, Daniel Mintz on Product Love, and Kelsey Hightower on On Call Nightmares.
I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email [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 December 23, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers.
SCOTT BELSKY ON PRODUCT LOVE
The Product Love podcast featured Scott Belsky with host Eric Boduch. Scott founded Behance in 2005, which he calls a “LinkedIn for the creative world.” They were acquired by Adobe in 2012. He is now Chief Product Officer there. He wrote two books: Making Ideas Happen and The Messy Middle.
Scott founded Behance because his designer and artist friends felt a sense of frustration at how their careers were at the mercy of circumstance. He pitched them on the idea of a social network for creatives and they hated it. So he asked what problem they wanted to solve. Many said that their portfolio sites were always out of date and hard for clients to find, they never got attribution for their work, their potential clients found it hard to look them up if they saw their work for another client, and there was a lack of software that catered to the business aspects of being a professional designer or artist. This was a community of customers who didn’t realize that what they needed is what they didn’t want.
Behance needed to pull their customers through their first mile of doubt. When they put out a beta, they asked customers to put their portfolio on it and the customers said no because they had a portfolio site already. So they asked their customers if they could interview and write a blog post about them and they said yes. So Behance made a blog of leading designers and asked them for portfolio images. Customers agreed and let them put the images in Behance. They found a backdoor way to get some of the most beautiful portfolios into Behance upon launch. People who now looked up their favorite designers found them on Behance and thought, “I should be on there.” This taught Scott the lesson that, while the science of business is scaling, the art of business is the things that don’t scale. The best businesses find the non-scalable things to prime the pump for their products.
Scott says businesses need to nail it before they scale it. In other words, they should aim for high product-market fit with a hundred or so users.
Eric asked where the average product leader struggles in making the transition from being hands-on to more strategic. Scott says a common struggle is not empowering design sufficiently. You want to find the right design leaders and empower them sufficiently at the right point in the process. Great product leaders don’t say much at all. They are conduits that are working behind the scenes to get people aligned and to get designers and engineers working together.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/scott-belsky-joins-product-love-to-talk-about-exploring/id1343610309?i=1000458667222
Website link: https://www.spreaker.com/user/casted/belsky-edited-audio-mp3
BETH LONG ON MAINTAINABLE
The Maintainable podcast featured Beth Long with host Robby Russell. Beth is a software engineer at New Relic. She says that maintainable code is code that prioritizes intelligibility and is oriented to the way humans interact with it. It is simple, clear, and emphasizes readability over conciseness. The infrastructure the code deploys to and the deployment mechanisms themselves should also prioritize intelligibility and clarity to be considered maintainable.
Intelligible code is code that tends to make sense even to those that aren’t intimately familiar with it. This might be someone who hasn’t worked extensively in the codebase or someone who worked in it two months ago and has just now come back to it.
Robby asked about technical debt. Working at New Relic, Beth has had opportunities to talk with Ward Cunningham, the originator of the term. When Ward coined the term, he was working on a financial system and he described technical debt, like financial debt, as something you deliberately take on. You sacrifice some maintainability in the short term and pay it back over time.
Robby asked how developers can bring up maintainability concerns with stakeholders. Stakeholders are often focused on velocity, so they says things like, “Can we have the person who is on call due the sustainability engineering work?” This doesn’t work. What works is giving the team focused, protected time. Developers need to step out of their own experience of the world enough to understand the pain and pressure that their stakeholders live under and make a compelling case to them. Beth has seen it work. She has seen New Relic customers make slide decks to present to stakeholders about the value of doing the work to add observability to their systems and getting executive buy-in as a result.
Robby asked about second system syndrome. She says it comes from the book The Mythical Man-Month and refers to the tendency to replace small, elegant systems that work well with bloated, over-engineered systems. You have a system that works well enough but people want more features and there is a temptation to replace the old system with something new. The old system is full of known flaws and, in the potential new system, the flaws are not yet known and you can pretend they are not there. This is why she recommends against rewrites.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/beth-long-maintainable-code-prioritizes-how-humans/id1459893010?i=1000458429284
Website link: https://maintainable.fm/episodes/beth-long-maintainable-code-prioritizes-how-humans-interact-with-it-XHdDZOQF
MARK SCHELL ON AGILE UPRISING
The Agile Uprising podcast featured Mark Schell with host Andy Cleff. Mark started out working at an organization that had reached CMMI (that is, Capability Maturity Model Integration) level 5 (that is, the highest level: optimizing) but he struggled to see the worth of it. Eventually, a friend of his introduced him to Extreme Programming or XP and this got him energized about Agile.
They got into a discussion about a talk Mark attended at the Philly XP conference that was given by Ryan Lockard. Ryan described the benefits of cleaning up old code. Mark says that the less you clean up after yourself, the more stuff you have to step around. This also means being careful not to add too much complexity, as this makes things more complicated for the user and for the developers.
Andy asked Mark where he starts in such a situation where you inherit a system where there hasn’t been a great deal of taking out the trash. Mark referenced Foot and Yoder’s paper on the big ball of mud. He says you start with the smallest pieces you can find. Don’t be afraid to delete things; that’s what we have code repositories for. If you are using a compiled language and you have tools like Resharper, make use of them. Mark talked about tools like OpenGrok for making code files more searchable.
He says there are going to be cases where you have to take a leap of faith; you have to delete something that you know you may need to revert if you discover a previously unknown use. If you never take that risk and you’re always afraid of that code, you’ll never get to a cleaner state.
Andy asked about how things get this way. Mark says that most developers’ passion is often around the building of new things. Combined with schedule pressure, doing chores like code cleanup becomes a low priority. Mark says that, ideally, it should be baked into the red-green-refactor cycle.
Andy asks how we can push back as craftspeople when the business says, “More, more, more.” Mark says you need to find a way to tie this retirement of complexity to revenue.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/clean-code-refactoring-and-deleting-w-mark-schell/id1163230424?i=1000459008564
Website link: http://agileuprising.libsyn.com/clean-code-refactoring-and-deleting-w-mark-schell
DANIEL MINTZ ON PRODUCT LOVE
The Product Love podcast featured Daniel Mintz with host Eric Boduch. The work Daniel did in politics informed everything he does everyday. It helped him understand how people interact with products, how to scale and grow, how data can inform product decisions, how data can mislead product decisions, and how tools get built. When you’re running a giant volunteer political organization, that’s the lowest-attachment user you can imagine. Your product has to be good at grabbing users and getting them in the door or else it’s not going to work.
Daniel says we often fall into the trap of being data-driven. He thinks of the episode of The Office where Michael Scott drives into the lake because the GPS tells him to turn right. There is a difference between being data-driven and data-informed and when data conflicts with your intuition, your qualitative research, and your experience, you should interrogate that.
Eric asked how Daniel ended up at Looker. Daniel described his first experience with their sales team. After the salesperson struggled to describe what Looker was, he eventually asked Daniel to let him show off Looker by connecting to Daniel’s database and letting Daniel ask Looker any question about his own data.
In ten minutes, the salesperson had shown him things about his data he had never seen before. Seeing Looker in this way, Daniel felt like he did when first encountered the power of SQL, but this time it was something that anybody could use.
Just as any good product manager would try to get to the real problem when a customer comes to them with a solution like, “I want to make this button blue,” when a customer asks a data analyst to show them sales by salesperson by region for the last six months, a good analyst will ask them why. They might say, “I want to see if there is a big difference in how salespeople ramp over different regions.” The analyst might then respond, “What if we narrow that down and only look at people recently hired?” Product managers need to do the same thing when thinking about how they use data. For example, if you are trying to understand where people get stuck in the on-boarding path, then usage data may be useful. If you are trying to understand whether people’s impression of the product has changed over time, net promoter score might be what you need. Start with the question instead of saying, “This is the data I have available and here is what I can make of it.”
Daniel says that good operational metrics are ones that, upon looking at them, you immediately know what you should do in response to them. Alternatively, dashboards of vanity metrics can be disempowering for people: if you are a product manager who isn’t working on a revenue-creating part of the product yet, a dashboard tracking a vanity metric like revenue is not something you can do anything about.
Daniel gave an example of vanity and operational metrics for a company like Uber or Lyft. A vanity metric might be rides taken or cities served. It is the kind of metric that might be valuable to investors, not for the people that work there. An operational metric might be percentage of rides cancelled and that is only operational if you dig a level deeper to find out why they were cancelled.
Eric asked Daniel for his take on net promoter score. From the consumer perspective, Daniel says, NPS is a great innovation because it is so simple and easy to administer that your response rate is going to be higher than any other survey question. Being a single question survey makes it easy to ask in-product rather than in a survey email and thereby increase response rate even further. He says that tracking NPS over time makes it even more useful. When it is used to just ask if something is good or bad, however, it just becomes another vanity metric.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/daniel-mintz-joins-product-love-to-talk-about-data/id1343610309?i=1000459282754
Website link: https://www.spreaker.com/user/casted/daniel-mintz-joins-product-love-to-talk-
KELSEY HIGHTOWER ON ON CALL NIGHTMARES
The On Call Nightmares podcast featured Kelsey Hightower with host Jay Gordon. Kelsey talked about what he calls “learning in public”, in which you share things as you learn them. He says that when you learn in public, you tend to not skip over the interesting bits from zero to getting started. A lot of times, we’re afraid to share that because we want to be seen as experts.
Kelsey talked about his truest introduction to on call. He described how his CTO made it clear just how important their work was to customers. Hearing about the consequences for customers of system downtime put things in perspective for Kelsey. Kelsey says that if you fail to explain it, on call can feel like you’re overtaxing your employees. It is less like on call and more like glorified overtime.
Another lesson Kelsey learned about on call at that company happened when he took on all of the on call work for two months. His goal was to find the patterns and make it go away. Over the two months, he made sure the issues were documented and the documentation was made consistent. The rest of the team saw Kelsey as “taking one for the team”. The team was able to do work in their areas of expertise to improve the on call experience. The number of incidents dropped from 1-2 per week every week to having weeks without any incidents.
They had been in a cycle in which on call pain was spread out enough that nobody did anything about it. Stepping up and showing leadership by doing changed things.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/episode-45-kelsey-hightower-google/id1447430839?i=1000460193573
Website link: https://www.podomatic.com/podcasts/oncallnightmares/episodes/2019-12-19T08_16_15-08_00
LINKS
Ask questions, make comments, and let your voice be heard by emailing [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:
-
Emily Bache on Maintainable, Rod Collins on With Great People, Dominica DeGrandis on Troubleshooting Agile, Ariel Caplan on Greater Than Code, and Dave Aronson on Maintainable.
I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email [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 December 9, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers.
EMILY BACHE ON MAINTAINABLE
The Maintainable podcast featured Emily Bache with host Robby Russell. Robby started out by asking Emily about common traits of maintainable software. She says that maintainable software has a design, is well tested, has names that relate to the domain, has had thought given to having levels of abstraction, and is the kind of code you would like to read.
Robby asked Emily what developers get wrong when talking about technical debt. She says that some developers label as technical debt any code they don’t like or didn’t write themselves. Other developers don’t even admit that there is any such thing. This is problematic because there really is code that is bad, code that most developers would have trouble understanding.
She says that your decisions regarding technical debt have to be driven by the needs of the users of the software. Code you don’t need to change doesn’t need to be improved.
They talked about examples of bad code and Emily mentioned Terry Hughes’ Gilded Rose refactoring kata as an example of horrible code that she uses to educate others. She herself invented a tennis refactoring kata and a Yahtzee refactoring kata that I got to try out myself in her workshop at the Agile Testing Days conference in November.
Robby asked whether these exercises are meant to be done alone or with others. Emily says it is always more fun to code with other people and you learn more. She says coding is a social activity. Very little code today is written by individuals. It is written by teams. Doing exercises like the tennis kata in a group lets you have discussions about design and code smells without it being personal and then you will have practiced such discussions for when it really matters in your production code.
Robby and Emily talked about the individual genius developer and Emily says that while there are definitely still instances of software built by geniuses working alone, the best software today is often built by teams from the start. This led her to talk about mob programming, which she favors because it forces you to explain your ideas in words. You have to become good at communicating, in words, about software design and coding constructs. She says she didn’t have that skill when she started mob programming.
Robby stated that he wasn’t familiar with mob programming. Emily explained that, as in pair programming, you have two people working together at the same machine, but in mob programming you have more than two people and, because of the increased number of people, you need an increase in structure. One piece of structure is that the driver, who is typing at the keyboard, cannot follow their own ideas about what to write. Instead, the navigator, a designated person in the mob, communicates what code should be written. The rest of the mob supports the navigator and the driver and you regularly rotate the roles. For the mob to work, the navigator has to get good at communicating in words, not just with the driver, but also with the rest of the mob so that they can assist and can take over when the navigator rotates to the driver role and the driver returns to the mob. They discussed how often to rotate and Emily says it varies from team to team, but her preference is to rotate every four or five minutes.
As an aside, at the Agile Testing Days conference this past November, I got to experience a mob programming workshop led by Emily in which I got to be a member of the mob and rotate through the roles of navigator and driver and I highly recommend seeking out opportunities to experience this style of work if you get the chance.
They talked about her work as a technical agile coach and how she splits her time among multiple teams at a given engagement, working with each team for two hours every day. These teams would work as a mob on their production code and she would sit in the mob and either take the navigator role, coach the navigator and driver, or simply observe. This allows her to help teams to learn practices like writing tests, doing refactoring, improving their design, breaking their work into small pieces, committing often, writing good messages, and all the stuff you need to do to be agile. They also do one hour coding dojos.
Being a guest in other teams’ codebases, she says, you have to be respectful because even when you see that the code is bad, you don’t know why it got that way. The first thing she does when she joins a new team is ask to see their code, their unit tests, and the code they find most difficult to work with.
Robby asked Emily to reflect on the various projects she has participated in and describe common issues that affect most teams’ code and processes. Emily says she sees a lot teams struggling to meet expectations and not taking enough time to really communicate with each other and improve. Most software developers really want to do a good job and are under a lot of deadline pressure that works against doing a good job. Software development is a marathon and you have to make sure you are learning and your processes are improving as you go.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/emily-bache-its-always-more-fun-to-code-with-others/id1459893010?i=1000457798211
Website link: https://maintainable.fm/episodes/emily-bache-its-always-more-fun-to-code-with-others-PtzH4tY7
ROD COLLINS ON WITH GREAT PEOPLE
The With Great People podcast featured Rod Collins with host Richard Kasperowski. Rod says that, in the 20th century, if you wanted to scope out the future, you looked backwards. You understood your business, product, and market metrics and forecasted from that because, in those days, the past was a proxy for the future. Today, the world is rapidly changing and planning can become a strategic trap. Planning is no longer the foundation of strategy. The basis of strategy today is discovery.
Richard asked why Rod calls himself an information curator and Rod said that no one person can see into the future, but if you have processes that leverage the collective intelligence across experts, non-experts, and what Rod calls unusual suspects, it gets businesses to ask the right questions and find the unknown unknowns.
Rod says that most leadership teams, especially senior leadership teams, don’t spend sufficient time on business strategy. When your challenge in a business environment is discovering the unknown unknowns, you cannot afford to meet only once a year to think about business strategy. Rod had his own leadership teams meet about strategy for a whole day every two weeks.
Rod asks, “How much of a CEO’s time is spent bridging gaps between the various units because they are not getting along?” Meeting for a day every two weeks pays itself back many times because senior leaders are able to handle issues among themselves without involving the CEO. There is esprit de corps, a history that gets created among the leadership team, and the collaborative way of working together becomes the natural way of conducting business.
Rod says that the leadership training of the last five decades is focused on the individual. Most train strategic leaders to hold their hierarchical authoritative power in such a way that it is beneficial, but treat leadership as fundamentally residing within the individual. Rod thinks that part of the transformation of 21st century business is the unit of leadership changing from the individual to the team. Leadership training, as a consequence, needs to happen in the context of full teams.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/rod-collins-innovation-discovery-how-to-do-it-right/id1262784541?i=1000457926652
Website link: https://soundcloud.com/withgreatpeople/episode28
DOMINICA DEGRANDIS ON TROUBLESHOOTING AGILE
The Troubleshooting Agile podcast featured Dominica DeGrandis with hosts Douglas Squirrel and Jeffrey Fredrick. Squirrel and Jeffrey asked Dominica what she means by time theft. She says that time theft is the interruptions and context switching that often comes from conflicting priorities, unknown dependencies, and unplanned work. For example, you may go to work and have back-to-back meetings and cannot get your real work done until you put the kids to bed or on Sunday afternoon. As Squirrel says, “You can’t do your work at work.” It prevents you from getting into the flow state described by Csikszentmihalyi.
If you ask people what prevents them from getting their work done, they often say it is because they are overloaded. She told the story of working with a team of 41 engineers working on 33 projects at the same time, building out six data centers in six countries in six months. They were carrying the duty pager and were interrupted so much that they put two project managers in front of them to protect them from the inbound demand, but their mutual dependencies within the organization interrupted them too.
The project managers put a big Kanban board up and, every time an engineer was interrupted, they put a post-it on the board. In a week, they had 92 interruptions and the majority were due to product managers wanting to know the status of their project. Every day, people were walking past this board and this is how you get visibility on your problem. Making the work visible provoked the necessary conversations to inspire change. The change that occurred was taking one of each specialist, moving them into a different building and asking them their biggest pain points. Because work was being started without finishing previous work, they had a lot of projects at 90%. This isolated team was able to finish 10% of the projects in four weeks.
As a build engineer, Dominica used to rant about teams not having enough automated testing but it got her nowhere, but once she started capturing the data, taking a scientific and systems-thinking approach, and presenting her data-backed case to leadership, the result blew her away. She got budget, she got headcount, and she got empathy.
Jeffrey said that people often find themselves on an us/them divide and this is not what Dominica found once she could present the data to leadership. The problem is that people don’t have the shared information to work from and, in making the work visible, she was generating information that nobody had before.
Squirrel says he worries that people will use the metrics to beat people up. Dominica says this is why we want to focus on business outcomes and not activity metrics. A lot of proxy metrics are captured because it comes with the tool, but these metrics don’t tell you how much business value a team is providing for the company.
Dominica likes to use a balanced set of flow metrics such as cycle time and flow efficiency. Squirrel asked why the business leaders would be interested in such metrics. Dominica gave the example of business leadership thinking they need to hire more developers because the teams they have are not delivering fast enough. If you are measuring flow efficiency, development time is usually a low percentage of flow time, so adding more developers would not help cycle time at all. You need to know where your bottleneck is and measuring flow efficiency helps you make these kinds of business decisions.
Jeffrey asked where someone should start in making work visible and reducing time theft. Dominica starts with the question of what prevents a team from getting work done. Decide on a few small experiments of four to six weeks to address these problems, find that one person on the business side who can be your ally and maybe sponsor these experiments, and address their business pain.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/making-work-visible-with-dominica-degrandis/id1327456890?i=1000458010204
Website link: https://soundcloud.com/troubleshootingagile/making-work-visible-with-dominica-degrandis
ARIEL CAPLAN ON GREATER THAN CODE
The Greater Than Code podcast featured Ariel Caplan with hosts Jamey Hampton, John K Sawers, and Jacob Stoebel. Ariel says his superpower is extreme irritability. He had to learn when to address the things that irritated him and when to let them go. He started a daily writing practice of noting what irritated him that day and also what he liked.
He connected his superpower to accessibility. He says you can develop in yourself a sensitivity to examples of poor accessibility like the use of red and green as the only means to present certain information in a user interface.
Ariel has been working on developing the corporate values for the company he works for. Ariel says that company values are often viewed with skepticism and he gave an example: a company had the values of communication, respect, integrity, and excellence, according to their annual report in 2000. The name of the company was Enron.
John talked about helping his team of about 25 people come up with their team values to use as an interviewing rubric. He liked asking about values in interview questions because there is no wrong answer and, by asking the candidate what a good demonstration of a particular value is, it allows you to evaluate how they think that the value would play out instead of having them guess the magic answer to a tricky interview question.
Jamey added that it is important to revisit your list of core values every so often. His company, Artemis, grew from ten to thirty employees and decided to revisit their values. Some of the values did not change fundamentally, but changed meaningfully in the way they were expressed.
Ariel asked about when is it time to delete a value from your list and Jamey described how the original list of Artemis’ “values” included company goals like “we help indoor growers succeed”. These got removed because they weren’t really values, but they remain corporate goals.
Ariel says he pays attention to who is impacted and has to change their behavior because of a value. He gave as an example the values of grit, determination, and hard work and how this gets abused to put pressure on the front-line workers. Another example is a value like: “we challenge people; we ask questions; etc.” A better value might be “we create an environment where it is safe to ask questions, safe to challenge ideas, and safe to take risks.” The first example puts the pressure on the front-line workers to behave a certain way, while the second puts the pressure on management to create a better environment.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/158-exploring-company-values-with-ariel-caplan/id1163023878?i=1000458078372
Website link: https://www.greaterthancode.com/exploring-company-values
DAVE ARONSON ON MAINTAINABLE
The Maintainable podcast featured Dave Aronson with host Robby Russell. Robby asked Dave what his definition of software quality is. Dave addresses quality for the vast majority of software as a list of six aspects that form the acronym ACRUMEN: appropriate, correct, robust, usable, maintainable, and efficient. The N means nothing.
Appropriate means doing what the stakeholders need it to do, where the term stakeholder refers to users, customers, operations personnel, and others.
Where Appropriate refers to doing the right job, Correct means doing the job right. He uses the analogy of being asked to write a checkers program and, in response, writing the world’s greatest chess program. It can be as correct, robust, usable, maintainable, and efficient as anyone could ever possibly want, but if you wanted a checkers program, you are not going to be happy with it. In ACRUMEN terms, the chess program is not appropriate. Alternatively, a perfectly reasonable checkers program that may even have a few bugs is probably going to suite your needs better than a fantastic chess program.
For Robust, he is mostly referring to security. He uses the CIA triad (confidentiality, integrity, and availability). The program should not reveal information, alter information, or become unavailable when it is not supposed to.
Regarding Usable, Dave says it is not just the end user that needs to find the software usable; things like an API should be usable as well.
In ACRUMEN, Maintainable means easy to change with low fear of error and low chance of error even for a novice programmer new to the project. Fortunately, the vast majority of software engineering advice is aimed squarely at this.
For the last letter in the acronym, E for Efficient, Dave says there are more resources to make efficient use of than CPU cycles. There is, of course, disk space and network bandwidth, but also the user’s patience and brainpower, and the company’s money.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/dave-aronson-putting-the-m-in-acrumen/id1459893010?i=1000455264616
Website link: https://maintainable.fm/episodes/dave-aronson-putting-the-m-in-acrumen-n_6lX9fc
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:
-
Bret Weinstein on The Jim Rutt Show, Barry O’Reilly on The Product Experience, Dave Farley on Engineering Culture at InfoQ, Jim Mattis on Coaching For Leaders, and Ben Mosior on Agile Uprising.
I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email [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 November 25, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers.
BRET WEINSTEIN ON THE JIM RUTT SHOW
The Jim Rutt Show featured Bret Weinstein with host Jim Rutt. Brett talked about the sustainability crisis (not necessarily related to climate) in which we are using resources and creating waste in a way that, mathematically, cannot continue indefinitely. Jim added that half of the mass of large animals on earth are now humans and domestic animals, most of which are cattle. He says this tells us that we are at or beyond the ability of our ecosystem to allow us to carry on the way we have been.
Jim believes that the engine that is driving us toward eco-cide is the pursuit of money-on-money return powered by psychologically-astute advertising that got underway in the 1930s and is now reaching near-perfection with the highly-instrumented attention-hijacking mechanisms of social media. He compared it to the paperclip maximizer idea in artificial general intelligence.
Brett says that the way you can tell that AI algorithms are out-of-control is to look at the behavior of people in the best position to understand the power of these algorithms. Defectors from Facebook or elsewhere describe the extreme measures they go through to retain control of the own lives in the face of algorithms they had a hand in writing.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/ep24-bret-weinstein-on-evolving-culture/id1470622572?i=1000456522456
Website link: https://jimruttshow.blubrry.net/bret-weinstein/
BARRY O’REILLY ON THE PRODUCT EXPERIENCE
The Product Experience podcast featured Barry O’Reilly with hosts Lily Smith and Randy Silver. Lily asked Barry where his notion of “unlearning” came from. Barry said that while writing the book “Lean Enterprise,” he had an “aha” moment in which he realized that, while teaching people new things was tough, what was even harder was getting them to unlearn their existing behavior, especially if it made them successful in the past.
Randy asked Barry what signs indicate when you are unlearning well as opposed to simply getting lucky. Barry says that a lot of people think knowing when to adapt is serendipitous or intuitive to other people, but there is a system you can learn that can make the process intentional and deliberate.
People get stuck. They stick to the sets of behaviors that they know and understand or that feel comfortable to them. When those behaviors aren’t driving the results or outcomes that they are aiming for, often people’s natural reaction is to point at other people as the cause of the failure.
If you’re serious about making progress, you have to own the results. You have to ask yourself what you can do differently to change the outcomes that you are getting. You need to get comfortable with being uncomfortable.
You need to think big about the aspiration or outcome you are trying to achieve, but you start small as you start to relearn. Starting small creates safety. You get a fast feedback loop, learn quickly, and you feel successful as you try new behaviors.
Barry asked Lily and Randy where most people in product roles spend most of their time and they said, “meetings.” They estimated that the effectiveness rate for such meetings was about 50%. As a product manager, Barry says, he would be trying to make that number better, but most people blindly walk into meetings and never make any changes to how meetings are run.
Barry gets leadership teams to describe a better outcome and one small thing they can do to make things better. For meetings, one team came up with a simple step: five minutes before the meeting would end, the leader would stop it and ask the team how effective they thought the meeting was and what outcomes they were taking away from the meeting.
When a leader starts to demonstrate a new behavior in meetings like pausing five minutes before the end and asking people how effective the meeting was, other people start to take these behaviors back to their teams. Role modeling these new behaviors in your organization can have a systemic impact because people see you trying out these new behaviors and that inspires them to be serious about making their own improvements. Berry went on to say that the belief that you cannot influence these kinds of changes needs to be unlearned.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/learning-to-unlearn-barry-oreilly-on-product-experience/id1447100407?i=1000456659421
Website link: https://www.mindtheproduct.com/learning-to-unlearn-barry-oreilly-on-the-product-experience/
DAVE FARLEY ON ENGINEERING CULTURE BY AT INFOQ
The Engineering Culture at InfoQ podcast featured Dave Farley with host Shane Hastie. Shane asked about Dave’s talk about taking back software engineering. Dave says that software engineering is a term that is falling out of favor. People started to think of software development as a craft and of themselves as craftspeople. Working on high performance trading systems, he adopted practices that he considers a genuine engineering discipline and this made a dramatic difference in performance, effectiveness, quality, and speed of development.
He says we’ve been too prescriptive in trying to define what software engineering means. An engineering discipline for software need to be general enough to still be true in a hundred years. He says we suffer in our industry from not having very many measuring sticks and we choose technologies, processes, and approaches based on who is the most persuasive person or guru.
His talk was about five principles that are likely to be durable, broadly applicable, and broadly acceptable to people. First, we’ve learned that planned approaches don’t work. Working iteratively through a process of discovery is foundational. Second, we’ve discovered from continuous integration and delivery that fast, efficient, high quality feedback has a dramatic impact on our ability to move forward with confidence and quality. Third is being experimental and adopting the scientific method. Fourth is working incrementally, building software from a modular point of view, and growing complex systems from simple systems. Fifth is being empirical and testing what we build against reality, learning from that, and adapting.
Shane asked whether these ideas are just common sense. Dave agreed that they are common sense but they are uncommonly practiced. He says that the majority of his own career in software development was built around guesswork. They would guess about what users wanted, guess about whether the software was going to be fast enough, resilient enough, and scalable enough, and guess about whether there were going to be bugs in it. They would guess about these things instead of testing these things as an experiment.
He cited Extreme Programming and Continuous Delivery as genuine engineering disciplines. Shane pointed out that this requires a significant level of discipline that is rare in our industry. Dave agreed and gave the example of the team he worked with to build the trading system mentioned earlier. They were not only the best team he worked with, but also the most productive, solving problems in genuinely original ways, and they did it all by consciously adopting these techniques. It wasn’t because they were smarter than other teams, but because of their disciplined, agile approach.
Shane asked how we can get a more experimental mindset in software development. Dave says we first need to get more data-driven and figure out useful measures to apply. For example, in high-performance software, we want to know things like how fast, what throughput, what latency, and what percentage of messages need to get through at a particular rate. The difference between an engineer and anyone else is that engineers spend a lot of time thinking about how things can go wrong. He gave the example of how he does Test-Driven Development: before he runs a test he has just written, he will say what error message he expects to get. This is a genuine experiment: he forms a hypothesis and he’s precise about the nature of the failure he is expecting.
Shane asked Dave for his opinion about pair-programming. Dave considers pairing one of the most powerful tools an organization has to start becoming a learning organization and he considers pairing a foundational idea for establishing engineering rigor.
Shane asked how we can convince the individual hero developer that it is a good idea to work with somebody else. Dave encourages his clients to experiment with pair-programming and you cannot do that for an hour or two. He encourages a minimum of a sprint or two and he combines it with rotating people who are in the pairs (also known as promiscuous pair-programming). In his experience, when you ask people who have never paired before it to pair, the majority do not want to. After they have done it for a reasonable period of time, the majority then want to keep doing it. Often, only a small number of people hate it and will never like it and companies need to make a tough decision about what to do about that.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/dave-farley-on-taking-back-software-engineering/id1161431874?i=1000456425449
Website link: https://soundcloud.com/infoq-engineering-culture/interview-dave-farley
JIM MATTIS ON COACHING FOR LEADERS
The Coaching For Leaders podcast featured Jim Mattis with host Dave Stachowiak. Dave asked about 1990 when Mattis was in the Saudi Arabian desert, preparing for an invasion that would become the first Gulf War. He employed a technique called the focused telescope. Mattis said that he faced the challenge of information flow. Leaders typically have sufficient information somewhere in their organization, but the pipes of information flow need to be open such that this information is available in time to make decisions. Mattis would take young, capable officers who would go out to units that were executing the mission and those officers would clarify and confirm to the attacking commanders the mission and report back to Mattis. This opened up the information flow in real-time to make better decisions.
Dave asked where Mattis got the idea. Mattis said that every time you are promoted in the military you are given a new reading list and he got this idea from the readings.
Dave then asked about 2001, when Mattis was in command of the marines in Afghanistan searching for Osama Bin Laden. Mattis said that he had shifted from being under a naval commander to an army commander and he did not spend the time getting to know his new commander. When intelligence came in that Osama Bin Laden was in the Tora Bora region, he knew they needed to stop him from escaping to Pakistan. Mattis had studied the Geronimo campaign of the U.S. cavalry in the late 1800s and saw how they set up communication stations to track activity on the border. He wanted to do the same to block escape routes in Tora Bora. He forgot the inform his boss and his boss did not understand the urgency of the situation or the plans to block Bin Laden’s escape. He says you have to ask yourself three questions everyday: “What do I know?”, “Who needs to know?” and “Have I told them?”
Dave then asked about 2003 when Mattis was commanding a division to remove Saddam Hussein from power. One of his colonels was failing to move with haste. Mattis says that the officer, who he admires to this day, had a tempo that was less than needed at the time and Mattis determined that he was asking this officer to do something that was beyond his moral ability to do. Mattis said that war is a harsh auditor of your recruiting, your equipment, your training, and your leadership. He needed everyone in the fight and he knew he had to delegate the decision-making to the lowest competent level but it had to be consistent with his intent which was to move fast enough to confront the enemy with cascading dilemmas to prevent them from digging back in. So he removed that officer from command.
Dave then jumped ahead one year to 2004 in Fallujah when four allied contractors were killed and Mattis had a plan to recover the bodies and track down those responsible. The President of the United States made the decision to attack the city instead. Dave asked Mattis what kept him from resigning in this situation. Mattis reminded us that the military has civilian control. When the civilian leadership says to do something, you keep faith with the constitution and get on with it. Mattis had read enough history to know the challenges associated with attacking a city with 300,000 innocent civilians. Mattis’s idea was to work with the other tribes in town that were repulsed by this terrorist activity and to use the spies they had in the city to hunt down the perpetrators. Given the known brutality of urban fighting, this was a better plan, but they were ordered to attack instead. Mattis said he could have resigned but the 19-year-old lance corporals in his army of 23,000 couldn’t quit and he wasn’t going to leave them on the battlefield.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/440-leadership-in-the-midst-of-chaos-with-jim-mattis/id458827716?i=1000456425891
Website link: https://coachingforleaders.com/podcast/leadership-chaos-jim-mattis/
BEN MOSIOR ON AGILE UPRISING
The Agile Uprising podcast featured Ben Mosior with host Jay Hrcsko. Ben started out as a sysadmin and started taking more interest in the people side of technology. He now runs a company called Hired Thought where he makes systems more purposeful.
Ben came across Wardley Mapping when people he was following in the DevOps community started to reference it. At the time, he was dealing with a difficult decision about whether to spend money that was tied to buying server hardware and thereby shifting attention away from the cloud that had been his focus.
He learned that Wardley Mapping was a way to make sense of these kinds of situations and make a good call. He ultimately decided to decline to money and he now had an explicit strategy where before he had none. Wardley Mapping highlighted how much he originally didn’t know what he was doing.
Ben describes a Wardley map as being two things: a visual way to represent a system oriented around users and a way to articulate how parts of that system are changing.
It is a directed acyclic graph where position has meaning. The x-axis represents evolution and describes how the components of a business, such as activities, practices, data, and knowledge, change over time. They start in the uncharted space where nobody has seen it before, nobody understands it, and it fails much of the time. On the opposite end of the spectrum, there is the industrialized space where everything is known, is ordered, is boring, and failure is surprising. Having a way to express where a business component is between those two extremes informs how to treat that business component.
They talked about the y-axis and how it represents the degree to which the business component is visible to the user. Ben says the y-axis is useful for thinking about what parts of the system the user cares most and least about.
Mapping is intended to be an extremely collaborative activity. The map helps us share a common model for how we think about a space.
Ben referenced George Box’s quote about all models being wrong and the scientist needing to be alert to what is importantly wrong about the model while ignoring those aspects whose approximate nature, or wrongness, makes the model no less useful.
A map helps highlight when the model of your system is wrong in a fundamental way. When people look at a map and talk about it, you start to work towards consensus on understanding the system and start running into label conflicts.
Producing the map artifact enables us to challenge it, talk to each other, and be transparent about what we think it is. The artifact itself is just one step in a five step process called the strategy cycle.
The five factors in the strategy cycle are purpose, landscape, climate, doctrine, and leadership. Purpose is the game we’re playing. It is why you come to work everyday. The landscape is the map. It represents the competitive landscape. Climate is the rules of the game, the external forces acting on that landscape that we don’t have control over. Doctrine is how we train ourselves, the principles that we choose to apply universally, such as always focusing on user needs. Last is leadership, the decision-making part that integrates all the rest.
Ben says that we often jump straight from purpose to leadership and the process of sitting with the context of the other steps helps us make better decisions.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/wardley-mapping-with-ben-mosior-hired-thought/id1163230424?i=1000456388231
Website link: http://agileuprising.libsyn.com/wardley-mapping-with-ben-mosior-hired-thought
LINKS
Ask questions, make comments, and let your voice be heard by emailing [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:
-
Brandi Olson on Agile Uprising, Judy Rees on Engineering Culture by InfoQ, J. J. Sutherland on Agile FM, Angie Jones on Developing Up, and Eric Ries on Unlearn.
I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email [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 November 11, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers.
BRANDI OLSON ON AGILE UPRISING
The Agile Uprising podcast featured Brandi Olson with host Andy Cleff. Andy asked Brandi about what she means by multitasking. At the individual level, she says we use the word multitasking to describe what is happening when we are trying to do more than one thing at the same time. It is a misnomer though because our brains do not actually do more than one thing at the same time.Her bigger interest is in what happens when you have groups of people trying to multitask all day long. She calls this “organizational multitasking.”
Say you have a team and they have a backlog. Organizational multitasking happens when somebody tells that team, “You need to get all ten of these things done this week and you need to start them all and I want to see the progress you are making each day.”
The opposite of that, organizational focus, happens when you say, “Work on this thing first before you work on the next thing.”
At the team level, she says, there are a number of illusions about how to be more productive and effective. One illusion is that getting started on everything is the way to get it done and if everything is important we have to do it all at the same time. This breaks down because of the reality of how our brains work.
Research shows that when a person has to juggle two projects throughout a day, they will spend 40% of their brain capacity and energy on context-switching. For three projects, energy devoted to context-switching jumps to 60%. Not only does this take time away from more productive work, but we don’t even notice the time we lost.
A further cost of having entire teams of people running around at 40% brain capacity is that they are less likely to identify the real problems to work on and it feels like they cannot slow down to figure out what the real problems are.
Andy asked whether the solution should come up at the individual level where someone starts to say, “No,” or is it something that starts at a leadership layer. Brandi says it is not a problem that can be solved individually. It needs to start with our leaders. Some of the problems that start to show up in these contexts are a failure to solve the right problems, a reduction in quality, an increase in employee turnover, a reduction in equity and diversity, and burnout. These problems typically get addressed by solving the symptoms.
Andy asked what she does to help organizations separate the symptoms from the cause. Brandi says she does this by making the costs of multitasking visible. She told the story of a company that surveyed 600 companies and their HR leaders about the biggest threats to their workforce. Over 80% of those leaders said that employee turnover was the biggest threat. The company then surveyed the employees at those same companies and the employees overwhelming named having too much overtime and unrealistic work expectations. Going back to the same HR leaders, a fifth of them wouldn’t be doing anything about their turnover problem in the next year because the leaders had too many competing priorities.
The overwhelming illusion that too many leaders buy into is that, while turnover and burnout are problems, we cannot do anything about it because there is too much important work to do. A further illusion is that we can capacity plan by cutting everybody’s time up; we can break up your time among projects and it will all add back up to 100%.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/the-cost-of-organizational-multi-tasking-with-brandi-olson/id1163230424?i=1000453339079
Website link: http://agileuprising.libsyn.com/the-cost-of-organizational-multi-tasking-with-brandi-olson
JUDY REES ON ENGINEERING CULTURE BY INFOQ
The Engineering Culture by InfoQ podcast featured Judy Rees with host Shane Hastie. Shane asked Judy if it is possible to have an effective remote meeting. She says absolutely and backed it up with an example of one of her own students telling her recently that participants in her remote meeting said that her remote meeting was better than an in-person meeting.
Shane asked about the secret sauce of a good remote meeting. Judy says it is probably planning. She also said that when remote, each person brings part of the meeting room with them.
She says people don’t realize how important the environment is to conversations. When you put people in a small space, they pay attention to small details and administrative kinds of things. For “blue sky thinking,” take people outside or to a room with a big view.
In real world spaces, we already know where to find small rooms and rooms with big views, but online, we need to create equivalent spaces. You need not only to ensure that all participants turn up with a decent headset, cameras turned on, and light on their faces, but also to figure out the activities so that you have enough social time at the beginning, during, or end of the meeting. The beginning and end of the meeting are critical parts of a meeting. Online, we often miss out on these beginnings and endings and it affects the quality of the conversations.
She also says that most people find it easier to engage and participate when the meeting is small. This connects with what Courtland Allen said on Software Engineering Daily about communities in the previous fortnight’s review. She says that if you can’t limit the space, you can limit presentation time to 5 to 7 minutes and get then people doing something. She also says to use breakout rooms and use liberating structures like 1-2-4-All (http://www.liberatingstructures.com/1-1-2-4-all/).
Knowing Judy’s expertise in Clean Language, Shane asked how might Clean Language be used to enhance remote meetings. Judy says that teaching people on remote teams to ask more non-judgmental questions about what somebody means by what they say can have a profound effect. Because of the missing socialization in remote meetings mentioned earlier and the fact that remote teams often have more cultural differences than co-located teams, misunderstandings are more likely. Therefore, learning to ask questions to clarify in a way that doesn’t sound like an interrogation but helps both parties to get clearer more quickly becomes particularly valuable.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/judy-rees-on-effective-remote-meetings/id1161431874?i=1000450875620
Website link: https://soundcloud.com/infoq-engineering-culture/judy-rees-on-effective-remote-meetings
J. J. SUTHERLAND ON AGILE FM
The Agile FM podcast featured J. J. Sutherland with host Joe Krebs. J. J. Sutherland is the CEO of Scrum Inc. and the son of Jeff Sutherland, the co-creator of Scrum. J. J.’s new book is called “The Scrum Fieldbook.” Joe asked what made him pick such a title. J. J. said he wanted to write a book about all the places Scrum Inc. has been all over the world and the many different domains far beyond software. He also wanted to show how Scrum Inc. thinks about Scrum and what are the patterns and anti-patterns.
He says that Scrum is a universal framework for accelerating human effort with applications in aerospace, banking, and even beer-making.
No one does Scrum just to do Scrum. Scrum is designed to produce value, which requires knowing more than just the Scrum guide. It involves understanding why Scrum works the way it does, understanding complex adaptive systems theory, knowing that you need to empower your teams and ensuring your teams are the right size.
Scrum is about running experiments and getting feedback from the customer and adapting to that feedback. He sees people spending six months to a year planning how to do Scrum before they even start. Instead, he says to just do something. That is where you’ll get the information to iterate towards the right thing.
Joe expressed his appreciation as a Scrum coach for the chapter in the book on the difference between busy and done. When J. J. worked in radio, producers used to talk about how much effort they put into the radio programs and he would have to point out to them that no listener cares how hard you worked on it; they care about what comes out of the box.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/jj-sutherland-agile-fm/id1263932838?i=1000453430262
Website link: https://agile.fm/agilefm/jjsutherland
ANGIE JONES ON DEVELOPING UP
The Developing Up podcast featured Angie Jones with host Mike Miles. Mike asked Angie what she considers the ultimate goal of code review. Angie says the goal is to ensure everyone is aware of and content with what is being contributed to the code base; it is not a nitpicking session or an opportunity to bash your least favorite developer.
Code review is also a good way to catch missed requirements. Angie encourages code reviewers to review the unit tests just as closely as the implementation.
Angie says the best code reviews are those you block out time for and make part of your routine. They aren’t something you skim while you drink a cup of coffee. When she reviews code, she always pulls up the requirement in the spec, doc, or ticket to see that the code under review fulfilled it. She looks for whether the implementation is efficient and at the right level of abstraction. She says that code reviewers have the opportunity to think at a broader level and see opportunities for code reuse.
Angie sees code review as a form of mentoring without having an official mentorship relationship. Official forms of mentoring can feel like an obligation for the mentor because they have to set up meetings, learn the mentee’s career goals. Angie says that code review is a more subtle form of mentorship that is just as powerful.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/code-reviews/id1156687172?i=1000452808997
Website link: https://www.developingup.com/episodes/46-dflXzZ1V
ERIC RIES ON UNLEARN
The Unlearn podcast featured Eric Ries with host Barry O’Reilly. Eric described how he started his company IMVU and how, when wanted to do practices like split testing, he got pushback. People thought of it as a direct marketing technique, not a product development technique. He would argue, “Shouldn’t we use the scientific method to test our hypotheses?” He wanted customers involved from day one, he wanted to ship more frequently than was considered normal at the time. Looking back, he sees how extreme his ideas were at the time and is glad his cofounders didn’t fire him.
As the company got more successful, his techniques got more controversial because the company now had more to lose. He said, “When you do things in an unconventional way, every problem the company has gets blamed on the unconventional method.” Barry pointed out that having to constantly explain the value of these unconventional methods likely made his thinking more resilient and could have been the seed for his next step.
At one board meeting, he felt like he was going to be fired. He was tempted to apologize and compromise, but made the conscious choice to advocate for what he actually believed despite the potential negative consequences. He rationalized it like this: this is a small business and a small business is like a small town. In a small town, everybody knows everybody and he wanted people to know what he stood for. If people don’t like it this time and they fire him, okay. A day will come, he reasoned, when they are going to be in a situation where they need to get something done fast and will remember him because they know what he stands for. He radically misjudged the situation: the more he stood for those values and explained them, the more they resonated with people. If he hadn’t had the courage to put his career and reputation at risk, he never would have found out who the ideas resonated with.
Eric says it wasn’t until later that he understood the importance of iteration happening within the context of a long term vision. Today, people understand Lean Startup as scientific hypotheses, a testing philosophy, small batches, and pivoting or changing strategy without changing vision. They know it is logically incoherent to have a pivot if you have no vision. Companies who were early disciples of Lean Startup, unfortunately, did not understand this and thought they could A/B test their way to success without any kind of vision.
Apple Podcasts link: https://podcasts.apple.com/ca/podcast/the-lean-startup-pivot-with-eric-ries/id1460270044?i=1000451993479
LINKS
Ask questions, make comments, and let your voice be heard by emailing [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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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 NextThese 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:
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. 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. 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:
-
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:
-
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:
Existing concepts cannot be directly applied to company strategy, structure, or process in the VUCA (volatility, uncertainty, complexity, ambiguity) world. 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. There is a collision of values underlying shareholder interests in short-term profits and a focus on the needs of the customers. 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:
- Se mer
