tl;dr:When Engineering OKRs just mirror the product roadmap, they add no value. Instead, Engineering OKRs should focus on what's special that quarter - process changes, improvements, or critical launches that need extra attention. Regular work belongs in KPIs, not OKRs.
tl;dr:“My work does not reduce to measurable outcomes. Much of what I accomplish as an engineer and as a developer advocate amounts to creating conditions that make it more likely for the company to succeed. I resist and resent most metrics, yet I don’t mind OKRs the way Honeycomb does them.”
tl;dr:“A friend pointed out: The “Important & Urgent” quadrant is hard on our brains. In urgency lies stress. The more time we spend there, the more we need rest. Rest is in “Not Important & Not Urgent” quadrant, like video games. In “Important & Not Urgent,” we do the things that matter, without stressing ourselves out. Here, we write. We create. We grow and improve the world. This is the quadrant of impact.”
tl;dr:Accountability within teams should prioritize behavior over just measurable outcomes. Focusing on behavior is more fundamental and leads to better results in the long run. It requires having courageous conversations, confronting deficiencies, and suggesting paths aligned with collective goals. Blaming individuals after failures is not as effective as addressing behavior proactively.
tl;dr:“Alignment gives us the context to make good decisions in our scope. It also lets us question decisions outside our scope, constructively, because we can notice when we learn something inconsistent with our expectations. That catches discrepancies early, and gets us back on track together.”
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).”