Day 1: Oxbows, Rivers, and Estuaries: How to Navigate the Currents of Change (Without Burning Out)

— Thank you and huge thanks to Lou and Patrick for the invitation to the conference

• As part of Rosenfeld conferences, there are speaker cohorts, and had chance to look into different talks given today and you are in for a treat

— Let’s jump in

• Today I want to tackle problems integrative roles, like us service designers, have in beautiful mess of making the stuff we make

— Recent trend in my writing and research, and I have become more interested in integrative roles with time

• Got more and more involved with glue type roles, i.e. system thinkers

— Examples of roles include service design, software architects, platform product managers, human resources, etc.

• I’m interested in specific challenges roles have in organizations

— What are these common challenges?

• Constant boundary spanning happening, as we are integrating across domains, contexts, different levels of abstraction
  • We are often holding a lot of complexity in our heads: We often move from delivering message in three bullets to delivering massive service blueprint or customer journey
• In context of navigating org power dynamics [emergent and official], fluid boundaries are everywhere
  • Involves emotional labor, energy management, and cognitive load

— Also topical challenges on top of these roles

• In news, see themes in company messaging, and pressure for efficiency, cost-savings

— Simplification can border on over-simplification: efficiency, remove bureaucracy, and removing complexity

• Especially relevant for our integrative type roles

— Throw in pressure to adopt new tech, and you have potent mix, in addition to normal type roles

 

— Topic for today is noticing that integrators are questioning their current playbooks for change. Questions include:

• Should I just become a product manager, since they have the power?
• Should I jump ship to another company?
• Does it matter what we call our integrative role?
• Should we democratize service design? Is that the right approach?
• Should we have an organic transformation path?
• Is playing the long game the right thing?

— If you have these questions on your mind, they are pretty common for integrative type roles like UXR, and product management

— Topic here is how to navigate currents of change, and if changing the playbook is needed

 

— WIll start with three quick stories, I’ve observed out in the field, to help us frame the underlying challenge

 

— I do a fair amount of consulting, and found my self jumping between two companies

• Company one, the speedboat, was product-led, had independent teams with dedicated UXR roles and all kinds of SaaS tools to grasp insights for customers
  • But in terms of service design, people didn’t understand it
• Company two, was a metaphorical tanker, where delivering anything was difficult
  • Teams couldn’t contact customers directly, struggled to get insights, and were polar opposite of company one
  • However, had world-class service design team, and impressive in context of slower

— Maturity is not linear in companies

• Each company had lot to learn from each other [both the speedboat and the tanker had need to learn from each other]

 

— The next lesson involved an incredibly funny meeting I attended, which drew out similarities between integrative roles

• Different reps from org where attending this meeting
  • Tech org spoke about outputs of meeting through event storming, org design — I felt it was like a customer journey map
  • Customer Experience team talked about onboarding customers, customer success— I felt like they had a map too
  • Product design, talked about health of workflows— also a map
  • Product management spoke about trees of value and capabilities — also a service design map
• Lesson 2: In average company, people are circling around similar topics in different ways
  • It’s a battle of models but the models have more similarities than differences

 

— Another lesson is common pattern seen across industry

• With low interest rates, there was a push for multi-product teams, and teams were growing, but stretched thin

— Customers felt pain with decline in dedicated surface-area across company, and we hit limit of that approach

• In US, SaaS is seeing a shift to end-to-end view, teams are thinking more holistically, and they need to do more service design as they rethink things
  • Layoffs created opportunity for thinking more end-to-end

 

— See common themes across the industry, with company-wide and discipline-wide dynamics, and more nuanced maturity

 

— This sets stage for our “currents of change” metaphor

 

— I’m interested in metaphors, which are always inaccurate, but sometimes helpful

• We can experience currents of change in individual companies, countries, and economics
  • We need to move both fast and slow, in deep and shallow areas, in order to navigate currents

— Need to dive in to currents we are experiencing

 

— I’ll use three metaphors for navigating change

• Rivers
• Oxbow Lakes
• Estuaries

 

— Rivers are great metaphor for how we navigate our career, our orgs, and our lives

• We are always reading the river, to figure out what to do next
• We can’t really shape entire river, just our position in it
• We never navigate the river entirely by ourselves, but with other travelers

— Idea of WORMS, from kayaking and rafting, works as tool for navigating the metaphorical river. WORMS stands for the following:

• Water
• Obstacles
• Route
• Markers
• Safety

 

— Water: Where is the water and energy, information, power flowing in your org?

• Where is it pushing back?
• And is the water changing directions?

 

— Obstacles: What is causing the water to go in certain directions?

• Note which ones are present and hazards and opportunities presented by the obstacles

 

— Route: Your particular route down river, and what are the backup plans if the environment changes

 

— Markers: How do you remember the route as we move forward in the river

• How do we push against the myopia of our immediate surroundings?

 

— Safety: Where are the exit ramps in our route, and how do we stay safe in the changing environments?

— An example of safety is when rafting, you can tap your head to signal things are okay

• Do you have special signal to indicate safety in an organizational environment?

 

— Other examples from rafting, include types of currents

• Trough : A current that is deep in middle
• Crowned Road: A current deep on the outside

— We need to understand momentum in org, so we can make choice to either go with main current, or hang-in eddies where you are less noticed or do more thoughtful work

 

— Also need to think about banks of river, as you read them

• Sometimes you have a leader so focused on scanning river, they don’t observe the surroundings at all
• But surroundings provide key information

— For example if there is a steep bank, river is deep, and a shallow bank river indicates the river is shallow

• You need to always think of surrounding conditions on river

 

— Ferry Gliding as metaphor for navigating a river

• Don’t paddle straight into dangerous river to cross it. Use opposing force of river to cross the river
  • If in a company, there might be big shift to adopt Product Management and being product-led, but if you angle your metaphorical boat properly, you can move into new areas of company

 

— Other metaphors include:

• Sometime ‘V’ of current extends away, and a sign you can follow current there,
  • Analogous to department where you should run away, are like upstream Vs, to go around a particular person

— Eddies are where you can take break, and take a breather, which is similar to cases where people can be aggressive on change, and risk pushing beyond sustainable wins

• Trouble happens when you lose energy, and don’t allow yourself a chance to rest and recover

 

— Review of WORMS for getting down the river of change

• Water: Where is the water flowing? Where is it pushing back or changing directions?
• Obstacles: What is causing the water to go in those directions? What hazards do the obstacles present?
• Route: What route am I going to choose? f I miss my first choice route, what’s my back up plan and how will I get there?
• Markers: How will I remember my route? What markers should I watch out for?
• Safety: Are there bigger upstream or downstream hazards to consider? Where are points of safety where I can exit or rest, like eddies?

— Let’s zoom back out to look for other metaphors

— Favorite organizational change metaphors is an oxbow lake

• Oxbow lakes are lakes that form along a river, where enough erosion takes place in a river to cut away a lake

— Sometime people are eager to get seat at table and pull org in one direction— but, going back to metaphor, if there is a sudden flood, that flood cuts the oxbow lake away

• Leaders can push so hard to raise visibility of product management, design, and miss flood of what is about to happen and get segmented off from the rest of the org, in a new configuration

— Avoid being an oxbow lake, and always scan where erosion is happening and where potential motion or flood will shape river to your advantage or disadvantage

 

— Finally I’ll end with estuaries, which are where river meets sea or ocean

• Metaphor for how we collaborate in companies

— Estuaries, have tons of boundary conditions

• Estuaries are very dynamic like the Chesapeake Bay or San Francisco Bay, as salt water and fresh water interact in various ways

— Why helpful as metaphor?

• Biodiversity and dynamism come when different perspective, skills, and experience mix
  • Can feel chaotic, and easier to silo off, but the overlaps is where creativity happens
• Also though estuaries are highly adaptable to circumstances in water flow, highly sensitive to industrial waste
  • If you are creating a hotbed of creativity, need to protect, as it is both resilient and sensitive to changes

— Final set of takeaways

• Look for unlikely partners, going back to estuaries metaphor
  • The decisions with most relevance for Service Design, are happening on real or virtual white board among engineers trying to figure out a customer domain
    • Critical architecture decision to impact how teams work, people collaborate, data you have, etc.
  • I often see meetings happening, but no service designer is present
• Often no Service Design present in meetings
  • Awareness issue, but people aren’t comfortable operating on edges

 

— If you enjoy mess of complexity, you often get burnt out and myopic. You tend to focus on what’s in front of us:

• But there are many layers of currents happening on river, so step back and look at big picture of what’s going on

— Design leader should attend other industry events, and know the financial picture of org for example

• Explore currents facing company at higher resolution when you can

— Challenge perceptions of progress

• A design leader complained to me about loss of status relative to ten years
  • But when was last time they were working with modern tools in a team, working in a modern way?
• You can hit situation where disciplines seems to be figured out and finished, but expanding view out can help you recognize the situation is not static, and evolving
  • Considering tools like Team Topologies or Domain Driven Design for engineering, can help calibrate perceptions of progress

— One final thing:

• Impossible to survive in industry by pushing against the current of change all the time
  • You can swim upstream and against the tide, but you will not be in a position of leverage where current does the work for you
• Have level of patient opportunism if you are in integrative roles
• Most of time you should have a current at your back, or leverage it to get place where you need to be
  • Don’t constantly angle against current as you will burn out, and won’t achieve your mission

— With that, thank you. I look forward to the rest of the talks today, and how change works across different view

 

Questions

1. Interest in battle of models. Why so much with bringing models to table, and how to resolve battle?
   1. Models are sense-making tools, and will look same over time
   2. Coming up with one pre-eminent model for company is a recipe for disaster
      1. Philosophy to embrace models and attend event-storming exercise from engineers
      2. Look at commonalities and let engineers do their thing, and understand logic behind engineering decisions
         1. Same things with product — need to know why each discipline has model that it does
         2. Find commonalities and common themes and metrics— otherwise finance team will send all crazy