Words of WisDOM
Insights on leadership, product excellence, and continuous improvement.
Empowered Product Teams
The Engineers' Cheat Sheet for moving from "mercenaries" to "missionaries". Inspired by Marty Cagan.
Product Thinking Don’t just ship code – solve problems.
- Understand the "why" behind features; be a missionary, not a mercenary.
- Link every line of code to user and business value.
- Ask: “What outcome does this drive?”
Active Discovery Participate early – Delivery and Discovery happen in Parallel.
- Use spikes, prototypes, and tests; and identify and address risks early.
- Help validate value, usability, and feasibility.
- Treat throwaway code in discovery as a smart investment; aim for 10-20 ideas a week.
Collaboration (PM + UX + Eng) Product innovation happens when everyone is aligned.
- Shape solutions together from day one.
- Respect each other’s craft—and overlap intentionally.
- Communicate openly through design and scope changes—Story Boards are great.
Outcome Execution Success is solving customer problems, not delivering features.
- Avoid traditional Roadmaps—which quickly become commitment traps.
- Priorities made up of a combination of High Integrity Commitments & Outcome Based Planning.
- Use outcome-focused objectives to guide priority—OKRs are great if everyone is involved in setting them.
Aspire to Product Leadership Don’t wait to be asked – lead from your lane.
- Volunteer for undefined problems.
- Suggest better approaches.
- Coach others to think beyond delivery.
Be Strategically Aware Vision inspires, strategy focuses.
- Know the Product Vision (destination), Strategy (route to vision via outcomes), and Customer.
- Filter ideas through strategic fit.
- Anticipate tech needs before they become urgent.
Process Fluency and Flexibility Use Agile & Lean to enable – not constrain.
- Advocate for meaningful rituals (retros, risk reviews, CI, etc.).
- Adjust the process when it’s broken.
- Push for clarity when working with ambiguity, but be comfortable with it.
Champion User Empathy Fall in love with the problem, not the solution.
- Observe users, listen to support, ask for and understand feedback.
- Advocate for performance, clarity, and simplicity.
- Design for edge cases, empty states, and real-world use.
Elevate the Team and the Culture Make your team stronger than you.
- Share context, knowledge, and wins; durable teams outperform ad hoc teams.
- Help shape a culture of ownership, curiosity, and outcomes.
- Use Google Aristotle as a framework—Psychological Safety, Dependability, Clear Roles & Goals, Meaning and Impact.
Team of Teams Avoid command-and-control.
An Empowered Model fits the Team of Teams concept, where teams are encouraged to communicate together to get things done which are aligned with the organization-wide Product Vision—rather than through an escalated channel. I liken this to the concept that a CEO cannot afford to spend their day authorising every single request... so they empower the teams to make them wherever possible!
Doing is Easy; Being is Hard
Truly being Agile or Lean is to embrace discomfort, question norms, and commit to a journey of ongoing growth.
Doing Agile vs. Being Agile
Implementing Agile practices—especially through frameworks like Scrum—often starts with the mechanics: daily standups, sprint planning, retrospectives, and so on. Teams quickly adopt these rituals and begin working in sprints. On the surface, it may look like transformation is happening.
But these practices, in isolation, only reveal what’s broken in your system. They expose bottlenecks, misalignments, poor communication, and unclear goals. They don’t automatically fix them.
Being Agile is about embracing change, fostering transparency, collaborating deeply, and continuously reflecting and adapting. It requires trust, empowerment, and a willingness to evolve—not just follow a framework. Agile becomes a mindset, not just a checklist.
And perhaps most importantly, teams often forget that Agility is a journey. There’s no endpoint, no final destination where you’re “done.” Being Agile means continuously improving, experimenting, and evolving. It’s a mindset of perpetual growth and adaptation.
Doing Lean vs. Being Lean
Lean, like Agile, has tools and practices that are easy to implement at face value. The Kanban board is a classic example: we set up columns—<To Do>, <Doing>, and <Done>—and begin moving tasks across the board. Immediately, we gain visibility into our workflow.
But that’s just the surface. Visualising your work doesn’t eliminate waste. It simply makes it visible.
Being Lean means going further—questioning every step in your process, identifying inefficiencies, and removing anything that doesn’t add value. It requires discipline, systems thinking, and a relentless focus on delivering customer value.
Even that simplest Kanban board should evolve quickly. If it survives multiple cycles without iteration, improvement, or a rethink, you’re likely missing opportunities to enhance flow and reduce waste. Being Lean means committing to continuous improvement (Kaizen). It’s about fostering a culture where everyone feels responsible for efficiency, where feedback loops are constant, and where small, incremental changes lead to big results over time.
Blending the Best of All Worlds
In practice, the most effective teams don’t rigidly follow just one framework. Instead, they take a pragmatic approach, borrowing from Agile, Lean, design thinking, and continuous improvement philosophies.
- From Agile: Empowered teams, iterative development, and customer-centricity.
- From Lean: Clarity of purpose, focus on value, and process efficiency.
- From Design Thinking: Empathy, rapid prototyping, and problem framing.
- From Continuous Improvement: A culture of reflection, learning, and adaptation.
The goal is not to follow a methodology perfectly. The goal is to build a culture that encourages experimentation, values feedback, and seeks better ways of working every day.
Final Thought: The Harder Path is the Right One
Doing Agile or Lean is easy. You can implement the practices, go through the motions, and check the boxes.
But to truly be Agile or Lean is to embrace discomfort, question norms, and commit to a journey of ongoing growth. It’s harder—but it’s also where the real transformation happens.
High Performing Teams
Lessons from Google’s Project Aristotle on what actually makes a team effective.
Google’s Project Aristotle found that what really mattered was less about who is on the team, and more about how the team worked together. Surprisingly, variables like colocation, consensus-driven decision making, extroversion, seniority, and team size were not significantly connected with team effectiveness.
Psychological Safety
What do we want?
Teams and individuals to have the belief that they are safe from being seen as ignorant, incompetent, negative or disruptive, and can take risks and experiment.
Keeping it real
“This is your safe space”… is something to reiterate during meetings particularly if people aren’t responding or appear to be keeping quiet.
Dependability
What do we want?
Trust! Everyone feels they can rely on their team members.
How can we create an environment where they do?
- Clarify roles and responsibilities of team members.
- Hold each other accountable and always look at ways to help people improve.
- Coach individuals that might have suffered in the past and remind the team about the psychological safety.
- Learn about “Conscientiousness” as it’s the leading predicter of success.
Keeping it real
Perception management is key. Coaching the team helps build confidence and change negative perceptions held about individuals who may have suffered from past incidents.
Structure & Clarity
What do we want?
Everyone understands their job expectations and the process for meeting these expectations, as well as how their performance contributes to the effectiveness of the team.
How can we create an environment where they do?
- Regularly communicate team goals.
- Use OKRs that are aligned with the Company Strategy.
- Demonstrate how roles fit within the team and the organisation.
- Ensure products/services/outputs are prioritized and fit within the company strategy.
Keeping it real: OKRs at a glance
- Objectives are ambitious and may feel somewhat uncomfortable.
- Key results are measurable and easy to grade (0 – 1.0).
- OKRs are public so everyone can see what others are working on.
- The “sweet spot” for a grade is 60% – 70%; if you consistently attain 100%, you aren’t thinking big enough.
- OKRs are not synonymous with employee evaluations or a shared to-do list.
Meaning
What do we want?
Everyone feels that the work they do has meaning to themselves and the company. Motivation and enthusiasm TRUMP skills and experience.
How can we create an environment where they do?
- Remember everyone will have slightly differing meanings; it is a personal attribute.
- Be a model of enthusiasm and motivation—be engaging!
- CONSTANTLY feedback the wins, no matter how small (Kudos, spot prizes, etc.).
- Don’t let any good bit of work go unrecognized.
Keeping it real
Understand your people using models like SCARF (Status, Continuity, Autonomy, Relatedness, Fairness). Think of it as the brain's graphic equalizer! For example: reduce your own Status to raise someone else’s.
Impact
What do we want?
Everyone should feel the result of their effort is making a difference to the team and the company.
How can we create an environment where they do?
- Reflect on the work the team is doing and how it impacts users, clients and the business.
- Regularly show how the team’s output is positively affecting the company and the customers.
- Use Customer Journey Maps to provide the team with real insight into what users feel.
Keeping it real
Use Customer Journey Mapping. Engineers often think they know what is important; journey maps often show that things you don't think are important are critical to the customer.