Photo by Aaron Jones on Unsplash

What do we need to know to do something well?

There are different types of context we can have for the work we do and the more we have the better decisions we can make.

Daniel Walters
Published in
3 min readJun 22, 2022

--

In a prior post, I wrote about the “That’s not my job!” phenomenon. One of the common scenarios which can lead to a “That’s not my job!” response is when attempting to involve people in activities which may increase the amount of context they will be working with.

  • Get involved with usability testing? “That’s not my job!”
  • Planning our goals together? “That’s not my job!”
  • Giving feedback on a design? “That’s not my job!”
  • Write documentation or a user story? “That’s not my job!” …

A lot of these could be beneficial activities to be involved in for any member of a team as they are activities that can help provide them more context for the work they do. Understand a customer better. See a problem first hand. Think through an issue beyond just what to code.

There are a few different elements of context for the work we do — here are a few elements (I am sure this is not an exhaustive list):

  1. Knowledge of HOW to do the task(s) to be completed.
  2. Understand WHAT the work we are doing is trying to achieve — i.e. what are the desirable effects of the work having been completed.
  3. Agreement on the theory for WHY the tasks we will undertake will achieve what we are trying to achieve.

Traditionally software product development has been heavy on the context that is focused on HOW context. It’s in programmes, initiatives, project plans, task lists, and specifications. It’s a type of information that feels very concrete to us and is a mode we are all used to operating in.

With the growth in the use of OKRs and other more outcome-oriented methods of planning, there’s a shift to have a more balanced amount of HOW and WHAT context. You know the activities you will undertake but you are focused on achieving the WHAT rather than just completing the activities identified. You have measures which will help you know if you are making progress towards that achievement. You will adapt what you do based on progress to achieving the WHAT. This is the superpower of having a WHAT context in addition to a HOW context.

And then there’s what I am focused on exploring this year — the context of combining the WHAT and HOW with a more explicit understanding of the WHY. The WHY might help better understand the relationship between the activities you are doing and WHAT you are seeking to achieve with your work. The WHY may also connect you to the bigger picture of WHAT you are trying to achieve for the organisation as a whole.

Organisations do often attempt to communicate in some manner the WHY context but it’s often not directly linked and whilst it’s impossible to deliver perfect context, current approaches are almost always doomed to be missing enough connections to convey adequate understanding between leaders and those responsible for the action.

The benefits of the third, fuller context type are multifold:

  1. Someone responsible for doing the work can determine where the most impactful intervention point may be.
  2. Executing teams and individuals can make choices that are only possible when the context is known. An example I’ve seen many times worked on something marketing related where knowing a certain impression of the brand was important in addition to increasing traffic very much changes the options you select. Another point of evidence that this is a common issue is how often executives are flummoxed by a choice their teams have made. I’d wager its often the result of a context gap.
  3. Understanding can lead to a strong connection to the purpose of the work, leading to higher engagement.

Across an organisation, when every individual can access these benefits in their everyday work this can be a force multiplier for the organisation. But don’t be surprised if the journey starts with you hearing “That’s not my job!”

--

--

Daniel Walters
Focus on outcomes

An experienced product development professional sharing experiences and lessons from 25+ years in leadership.