This week’s posts

• Outcome thinking applied to estimation (TLDR; its mostly waste) Most effort estimating software development is waste. Here's why and where our effort is better spent.

• The Principle of Least Astonishment and how it relates to outcomes-thinking Just because it can be done should always be balanced with should it be done. Thinking about what you are trying to achieve holistically can help detect when these are in conflict.

• Adaptively plan to conquer dauntingly ambitious goals. When replacing legacy apps actively used by millions of job seekers, where do you begin? Here's how we used adaptive planning to move even when the path was uncertain.

• How we arrived at focusing on outcomes At SEEK Asia, with the situation we faced, it was obvious we must focus on the outcome to succeed. Here's what happened.

Image of the week

This week’s posts

• Decisions within organisations are influenced by soft and hard incentives part 2 In the follow-up post we walk through various types of incentives at play within organisations and how they influence decisions.

• Two impactful ideas to apply in software product development part 2 I go deeper into the two ideas I shared in an earlier post and the critical components of using each idea in software product development.

• Side-effects of having only team-level goals What happens when there are team-level goals but no organisational-level goals? This post looks into some side effects to be aware of.

• Teams that invest time in a shared vision of the future achieve more What happens when a team is purely reactive and lacks a vision for a better future?

Image of the week

This week’s posts

• How to rally leaders around OKRs: test alignment of existing initiatives I cover a workshop activity I have run many times as a way to show levels of misalignment that already exist in an organisation.

• Walters' Lever of Improvement As an executive, I invest effort where I believe it will have the most leverage for positive impact.

• A leader's prime responsibility is to provide context What is context in software product development and how does it help us build better products?

• The 'soil sample' technique as alternative to firehose drinking If being everywhere is impractical and being hands-off is irresponsible, what is the alternative?

Image of the week

Focus on outcomes

Thinking holistically about customer experience

When you look through verbatims of customer satisfaction or NPS surveys you will notice a wide range of feedback. Some will be what you expect - functionality they like or don’t like - but invariably there’s a wide range of feedback covering all sorts of topics; from performance issues to interactions with the customer service person they weren’t happy …

Read more

4 years ago · 2 likes · Daniel Walters

This week’s posts

• What to consider when deciding to prioritise work This post explores what things to consider that can improve decision quality and guard against bias.

• Writing OKRs: How to write an objective focused on an outcome The best OKRs are those that describe outcomes. This post breaks down the elements of a good outcome-oriented objective.

• Time writing goals together pays for itself We are too busy to do the things that are good for us. What effect does this have on the products we make?

• Writing OKRs pt 2: How to write key results focused on an outcome Writing an OKR focused on an outcome needs to also consider how to approach writing the Key Results portion of an OKR. How in part 2.

Image of the week

h/t to @ant_murphy who tweeted: “Companies celebrating releases like...” 🤣

This week’s posts

• Show the WHY of your WHAT how do we improve upon outcome-oriented goals? Pair them with the logic of why they are your goals!

• Better decisions with line of sight When people can see the direction and understand why it will help the organisation succeed they will have the context needed to make the best possible decisions.

• Dumb stuff I did early in my career Our best learning comes from the mistakes we have made, and I have made more than a few. These mistakes shaped my present-day perspectives on building great products.

• The role of bias in the mediocrity cycle We have natural predilections for the decisions we make which tip the scales towards short-term thinking. Making these decisions repeatedly over time can have a compounding effect, locking what is produced into a never-ending cycle of mediocrity.

Image of the week

This week’s posts

• "Sorry we are too busy to help you" explores why even teams working on the top priority can’t always get the help they need.

• Not all approaches to OKRs are the same (and some are better than others) There are lots of variations of how to do OKRs online. What to be aware of when choosing resources to use.

• Don’t start your OKR journey with an OKR tool It seems logical that capturing and sharing OKRs will take some time so a tool will help, right? The reality is quite different as covered in this post.

• Common problems in OKR reference material continuing the theme of the quality of OKR reference material, here are some specific gaps to look out for.

Image of the week

This week’s posts

• What do we need to know to do something well? There are different types of context we can have for the work we are doing. What are they and what degree of context can optimise our work and why.

• Not all approaches to OKRs are the same (and some are better than others) There are a lot of different places online that document approaches to OKRs. This post covers what to look for to assess which sources will support you in achieving success.

• Don't start your OKR journey with an OKR tool It’s natural to assume a tool will help you have success with OKRs. People experienced with OKRs will tell you otherwise. Here’s why.

• Common problems in OKR reference material As mentioned above there’s a wide range of quality in how OKRs are documented online. What are the issues and why is this?

Image of the week

This week’s posts

• The new orthodoxy is to orient work around outcomes in this post I set the scene for this publication for why I believe approaches to improving clarity for software product development teams will continue to grow.

• "That's not my job!" ever heard this phrase in your workplace? I share some reasons that can lead to this response and what you can do.

• What do we need to know to do something well? explores the context that leaders can provide which will help their teams’ decision-making.

• "Sorry we are too busy to help you" is another phrase that might be heard when attempting to collaborate, even if you are working on the organisation’s top priority! Why does this happen and what can leaders do to help?

This week’s poll

Image of the week