tl;dr:Jessica explains resiliency in the context of the Southwest Airlines software failure. "When software is brittle, it falls over in production, and that falls to people to fix. While software can be robust to anticipated conditions, only people handle unexpected events. When software can’t even handle stuff that happens all the time, then people suffer the strain."
tl;dr:"A viable system continues to function in a changing environment. We want our companies—and some teams—to be sustainable this way. How does your team contribute? Does your team have all the components of a viable system… and should it?" Jessica discusses the viable systems five subsystems, characteristics of each, and more.
tl;dr:"Add features one at a time — not as a series, but on alternate timelines. With version control, we have this superpower." Jessica believes this is a superior process for learning new frameworks, programming style, and more.
tl;dr:"The purpose of a software team is to provide valued capabilities to customers, internal or external. To do that, our software has to be up, it has to be fast enough, usable enough — a whole slew of properties that don’t show up in JIRA." Jessica discusses 5 key properties - Availability, Security, Flow, Delight and Value - their measures, and questions they prompt.
tl;dr:“To do something together, build shared understanding and then everyone can make compatible decisions. The old style of imposing a single person’s mental model on the group doesn’t work in complexity (and also it’s mean).”
tl;dr:"Repeating the conclusion isn’t useful. The question that reached that conclusion is useful over and over." Yet, Jessica points to the fact that we tend to replicate team structures of successful companies without asking the right questions. Instead of “what do successful teams do?” ask “how did that team that worked well reach its way of working?”
tl;dr:Jessica discusses "participatory sense-making." In software, this is developing a shared mental model of the software we're developing, what it’s going to be, how it works. In humanity, participatory sense-making is our shared reality of made-up concepts i.e. money, economy, justice, etc... "When we’re good at participatory sense-making, we can build conscientiously, instead of reducing everything to numbers."
tl;dr:Jessica argues that software teams reflect a power law distribution, not a normal distribution. Power law distribution are "a learning system" where "every interaction feeds every future interaction," and team members adjust accordingly. Jessica discusses healthy signs of a team functioning in this manner.
tl;dr:"As a software engineer, what is your job? and what is your value?" Jessica makes the point that delivering capabilities is critical to the health of software teams, not just delivering features or code.
tl;dr:Software doesn't fall into either traditional economic bucket of product or service. In economics 101, a product is tangible, and has a one-off capital expenditure e.g. a rug. A service is non-tangible has a recurring cost e.g. cleaning. Software is neither. "Software is not done when it first works," it requires substantial costs to maintain and improve.