better-purpose-better outcomes

Would you feel motivated if you didn`t know the purpose of your work?

Despite what feels like an obsessive focus on "high performing teams" in many software development organisations, there also seems to exist behaviours and practices which counter this, where the reason for doing the work is hidden, obstructive to enabling teams to experiment, innovate and learn what's useful & through this deliver value to the customer.

Hackday

A few years ago I was working with a team of software developers in a large organisation. One of the team members looked unhappy, I`ll call him Dave. It was early days in the role for me and I felt I didn't know him well enough to ask if he was ok or perhaps I had a poor grasp of his general demeanour and shouldn't make that assertion. A week later the organisation ran a hack day, he seemed to light up, excited by engaging with others and tackling problems. Critically the hackday for all teams was oriented around a focussed customer problem to solve. This prompted me to look further into motivation and what may have sparked that change and understand if there was something deeper at play beyond the hackday pizza.

Self determination theory

This theory originated from Edward Deci's and Richard Ryan's work on human motivation in the 70s and 80s. It includes a 3 part model composing Autonomy, Competence and Relatedness. These elements when satisfied help drive a sense of purpose with that motivation and engagement.

Thinking about my own experiences with software delivery teams & organisations, there are instances where I have observed “feature factory” type behaviour- an output focussed approach with little in the way of empiricism. Such environments being heavily focussed on build with "delivery" teams operating in absence of clear view on customer problem or opportunity, extending to a lack of product strategy. As a practice this seems counter to motivation, flying in the face of what science tells us. With that I have observed the impact of this type of practice has on people, how they feel about the work itself in absence of purpose.

Output

Many organisations work to an annual project based funding model, resulting in a yearly cash grab to fund work. “Features” may be specified at that point and may drive some individuals annual performance goal setting ( & with it bonuses) on "deliver this thing" this financial year by 'x date`. The focus at that point shifts from the outcome to the output and suits a lot of traditional behaviours and incentive structures. The solution at that point is locked in, early. What if there is a better way of achieving the outcome? How do we really know that feature is the right thing & what our customers need so to discount other options?

What can we do?

Focussing on Deci & Ryan's work and relatedness. How can we help teams focus on WHY- the problem, opportunity space or learning space?

Where are features identified in the system of work?⠀⠀⠀⠀
A lot of organisations use business cases to frame initiatives to obtain funding, often with one named feature or initiative thereby eliminating other options to deliver value (a risky practice in itself). Why not embedd some options here instead of features? If these can be focussed primarily on the outcome to be achieved- what are we trying to achieve and options that may be considered, embedding exploration and experimentation right from the start.

-> Capabilities- focusing on delivering capabilities ensures you are focussing on your customer- what does the customer want to be able to do? Aligning these capabilities to your organisations missions ensures your teams have areas of focus and purpose.

-> Product roadmaps- I've seen success with goal oriented roadmaps, themes and options to explore to deliver value coupled with ways to measure outcomes- OKRs and focussing on meaningful data to measure success.

-> Hypothesis driven development- methods to support experimentation. Develop hypothesis, design what you will do, identify measures & indicators, run, review, learn! How might we deliver value to customers to achieve the desired outcome with minimal effort?

-> Discover together. Consider "discovery" as a whole team activity. Explore context together & start together.

-> Feedback loops- transparent product information, who/ how/when is using the product, how is it performing, what's the customer feedback, analytics. If building mobile apps, how about feeding data from the App Store or google play direct into a slack channel via a ReviewBot to see what your customers are saying about your product? Help inform team decisions and explore.

-> Use real user stories and work from these with your whole team. The value in gathering user stories from your customers is it enables you to understand what they are trying to do so you can consider options to meet their need. If teams retro-fit user story verbatim without actually eliciting the story from the customer, the value is lost, the customer is not there to tell you what they want in their way.

-> Create better ways for the team to engage with customers to research and discovery- user testing, prototyping, call listening, interviews (not letting things like "remote" get in the way). If you are using discovery practices look for opportunities for the team to engage throughout, early at the start and often.

-> If following scrum- how do activities like backlog refinement feel? do they feel like a requirements walkthrough (ie. One person talking through the WHAT, such as tasks to be delivered). How about shifting focus to a collective decision on the product → What we are trying achieve as an outcome & Why we are doing this and explore options.

Give the team ways to think about options to deliver value.