By Keith McDonald: tech blogger and podcaster
5
11 ratings
The podcast currently has 33 episodes available.
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:
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:
The podcast currently has 33 episodes available.