Instead of setting rigid goals, the OHL framework defines objectives as puzzles. Teams then form hypotheses on how to solve them and are measured on their learnings through a cycle of three questions: "How well did it work?", "What did you learn?", and "What will you try next?"

Address cultural issues by applying product management principles. Use surveys to gather data and identify pain points, then empower the team to propose solutions. Test these ideas like product features and iterate based on what works, making culture-building a shared, active process.

Teams have a finite capacity for change. Use a 9-box matrix plotting "Cognitive Load" (how hard is the new skill) vs. "Capability" (level of mastery desired). Assign points to each initiative and stick to a quarterly "point budget" (e.g., 16 points) to avoid overloading reps and ensure training sticks.

To move beyond static playbooks, treat your team's ways of working (e.g., meetings, frameworks) as a product. Define the problem they solve, for whom, and what success looks like. This approach allows for public reflection and iterative improvement based on whether the process is achieving its goal.

Not all tasks are equal. Focus on "compounding" activities—small, high-leverage actions like creating templates or establishing processes. These tasks, like compounding interest, deliver growing returns over time and create a bigger impact than completing numerous low-value items, fundamentally shifting how teams approach their work.

Instead of codebases becoming harder to manage over time, use an AI agent to create a "compounding engineering" system. Codify learnings from each feature build—successful plans, bug fixes, tests—back into the agent's prompts and tools, making future development faster and easier.

When facing a major technical unknown or skill gap, don't just push forward. Give the engineering team a dedicated timebox, like a full sprint, to research, prototype, and recommend a path forward. This empowers the team, improves the solution, and provides clear data for build-vs-buy decisions.

Instead of stigmatizing failure, LEGO embeds a formal "After Action Review" (AAR) process into its culture, with reviews happening daily at some level. This structured debrief forces teams to analyze why a project failed and apply those specific learnings across the organization to prevent repeat mistakes.

To prevent engineers from focusing internally on technical purity (e.g., unnecessary refactoring), leaders must consistently frame all work in terms of its value to the customer. Even tech debt should be justified by its external impact, such as improving security or enabling future features.