Orienting to value – every team, every person does it differently. How you orient to value limits how much value you can create. People with a naive orientation can only scratch the surface, cogs in someone else’s machine; those with a refined orientation to value, well, there is no limit to what they can do.
How Teams Orient to Value
Over the years I’ve had the opportunity to work with dozens of teams, helping them improve their ability to create value. All of these teams believe the work they are doing is valuable. How they think about the value of their work limits how valuable their work can be. How they orient to the value of work defines how they think about value.
How teams orient to value limits how much value the teams create.
Here at the start of this article, the above statement is only odd. I will repeat it at the end of the article, and if I’ve spoken to you, you will agree with me that this statement is also powerful. Keep reading, and let’s see how we do.
Every person on each team, and every person each team interacts with orients to value in a different way. Some orientations are weak while others are powerful. My job is to help improve what teams can do, and I use the word orient, instead of align, because how they align – how they orient is where we have to change. Alignment is not a good enough word to make the changes we need to make.
- “Are you aligned to value?” is a closed-ended question, which limits its usefulness in helping teams change. If you’re not aligned, well, get aligned. It oversimplifies.
- “How are you oriented to value?” is an open ended question. It starts a conversation. It starts the process of improving how we orient to value.
In researching messaging systems just after the turn of the 21st century, we discovered that the messaging systems people used were defined by the communities into which they entered. The same is true for value orientations. Individuals may arrive with a particular value orientation, but they cannot advance beyond (and are expected to match) the orientation present in an organization.
Teams form shared identities, defined by their repeated patterns of behavior. When teams see these labels, they immediately know which one best matches the systems, practices, and conversations they are having. When presented with all 5 labels, they may aspire to a different label.
I will discuss each identity from right to left – not because I’m being difficult, rather because it has other meanings. This orientation aligns to some key techniques which help teams do more valuable work. That alignment won’t be relevant in this article, but I appreciate the power of the spatial symmetry and thus is useful for teams who are doing the work.
Doers of Work
People who identify with doing the work measure themselves by (a) measuring how much time they spend working and (b) measuring the quality of the work product. The quality reflections are limited to acceptance criteria – no splinters, no crashing bugs or spelling errors, a continuity of colors and tones. The primary orientation is to the amount of time they spent working.
- A day worker on a ranch
- A call center operator expected to be on the phone 52 minutes out of every hour
- A contract staff-augmentation software development team (billing by the hour or by the week); the way I remember waterfall teams
Some smells which tell me this is the likely thinking pattern in an organization:
- Leaders describing their organization or people based on utilization (% of time worked vs time paid)
- Managers expecting “face time” from their employees, complaining when someone is five minutes late or leaves five minutes early
- Organizational goals focused on reducing team cost, increasing team pricing, decreasing cycle time
Builders of Things
People who identify with building things measure themselves by (a) measuring how much work product they create and (b) measuring how quickly they produce their outputs and (c) measuring the quality of their work product. The primary orientation is either on measuring throughput or on measuring cycle time.
- An operator at a work-station in an assembly line
- A call center operator expected to complete an average of 18 calls every hour
- The most common scrum team pattern I’ve seen across hundreds of teams; internal and external, local, remote, and distributed
Some signals which tell me this is the likely thinking pattern in an organization
- Leaders describing their organization or people based on tickets closed, projects completed; growing their capacity to build more
- Managers expecting ever increasing sprint velocity, ever-decreasing velocity variance
- User story acceptance criteria are defined on behalf of the users, not with the users
- Sprint demos are to the product owner, not to the user
- Organizational goals focused on increasing throughput, increasing predictability of outputs, reducing waste (lean thinking)
Solvers of Problems
People who identify with the immediate purpose of why they are building things measure themselves by (a) assessing if whatever they built solved the problems their users needed to solve (b) measuring how many problems they solve and (c) measuring how quickly they can solve a given user’s problem. The primary measure is consistently on measuring throughput of solved problems.
- A technician repairing malfunctioning equipment
- A call center operator expected to resolve caller issues in a single call whenever possible
- A product team with active instrumentation of product-usage patterns and frequent evaluative research activities
Some signals which tell me this is the likely thinking pattern in an organization
- Leaders describing their organization and people by orienting almost exclusively to addressing the needs of the customers and users
- Managers staffing for or funding continuous user-research, expecting teams to orient to efficacy of solutions, not quantity of work
- Key user stories and acceptance criteria are validated with users prior to development
- Sprint demos regularly elicit feedback from target users and teams incorporate feedback into updates prior to product release
- Organizational goals (still) focus on increasing throughput and predictability of outputs – but also review improvements in the customer’s journey
Makers of Change
People who identify with the objectives of causing change through solving problems measure themselves by (a) determining if observable changes (improvements) result from the work they have done (b) measuring how much improvement was realized, (c) reconciling observable changes with predicted changes to improve future predictions.
- A process engineer changing the layout of a manufacturing line to optimize flow
- A call center operator who’s customers have a longer ‘lifetime’ as customers (or lower churn rate, or request fewer refunds)
- A product team who monitors the effectiveness of their products at driving improvements in the processes and behaviors they intend to improve
Some signals which tell me this is the likely thinking pattern in an organization
- Leaders who primarily talk in terms of the future user-experience or ecosystem improvements they are working to create
- Managers utilizing information radiators about the state of the user experience / ecosystem, tracking improvements & planned improvements
- Teams manage choices about how to solve problems through solution-hypotheses, validate the results of those hypotheses as part of their cadence
- Quantified causal relationships (“If we build these things, we believe it solves that problem resulting in this change of X%”) are integral to planning and prioritization decisions
- Organizational goals are expressed in terms of the observable changes in the user experiences and systems on which they focus (and notably not throughput of work or busyness of people)
Creators of Value
People who identify with the objectives of creating value for their company (while also creating value for their customers) measure themselves by (a) first determining if observable changes result from the work they have done and then measuring the benefits to the company resulting from those changes, and (b) reconciling observable changes and benefits with solution-hypotheses and outcome-hypotheses.
- A process engineer who’s objective is to delivery half a million cars to customers before the end of the year
- A call center operator who’s supported customers spend more in the 3 months following a support call than other existing customers
- A product team who tracks not only the benefits experienced through the customer journey, but also the resulting improvements in competitiveness, revenue, market share, etc. which result
Some signals which tell me this is the likely thinking pattern in an organization
- Leaders who establish direction through a strategy kernel – a diagnosis of the challenge combined with actionable outcomes and wrapped in guiding policy – and then empower their teams to design, devise, and deliver
- Managers who help teams assure coherence to strategic direction, and who invest in continuous improvement for their teams
- Teams utilizing solution hypotheses AND outcome hypotheses to make visible the uncertainties behind their assumptions of causality; both to frame up-front choices and to review and validate results
- Organizational goals have healthy awareness of leading and lagging indicators, how to gain insights from measuring
How Teams Orient to Value
As my friend Will Evans (@semanticwill) just wrote, the wrong orientation is worse than limiting, it can mean failure (or “death” as he puts it).
When the team’s perspective is too narrow, when they operate within unjustifiable constraints, when they are unaware of misalignment to actual (potential) value, they at best get lucky, and at worst fail. Take a moment to see where your team is oriented, and start working to get them to the next-better-orientation.
How teams orient to value limits how much value the teams create.
Helping them develop the increasingly robust and effective orientations to value, where their efforts and energies become less likely to be wasted on “the wrong work” – this is the rewarding work. And remember, you cannot simply declare a new orientation, you have to work with and through the organization around the team to make it possible for them to be effective with their improved orientation.
Published on Java Code Geeks with permission by Scott Sehlhorst, partner at our JCG program. See the original article here: Orienting to Value Opinions expressed by Java Code Geeks contributors are their own. |
