25. We Were Expecting Robots

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