Remote Operating Model Design Process - Step 4

Part six in a series of blogs describing how to design operating models where location is irrelevant and your teams can design their work around their lives rather than the other way around.

This is the sixth article in a multi-part series:

Part one | Part two:Step 1Step 2 | Step 3Step 4Steps 5 & 6Step 7


Step four: design the flow of work

Informed by the goal of the system, the principles and constraints, we use an iterative and collaborative Design Studio to model the teams that we will need to deliver value to our customers. There’s a bit of magic in this process that’s beyond a blog but in essence we are looking at a range of things:

  • The starting point(s) for design - the nine primes referenced in anti-patterns in Operating Model Design
  • The source of demand and the destination (e.g. to the customer, an external stakeholder, or to another internal process)
  • Whether we are testing what happens when we relax certain constraints
  • The team archetypes that we need to deliver value to customers (mission, product and operations)
remote:af team types, evolution and interactions
  • The interactions between teams as value flows through the organisation:
  • How they handle communication and priority of impediments to flow of value (within the team, within the organisation, and with 3rd parties)
  • The six C’s that Tony Ponton developed building on work done on Australia’s first major financial services agile transformation back in 2008: Customer, Clarity of purpose, required Capabilities, rough Cost, approximate Capacity (for existing operating models), and relevant Codified processes, policies and procedures.
customer, clarity, capability, cost, capacity and codify
Tony Ponton's '6 Cs'
  • Any platforms which are critical to the flow of value.
  • Any formal communities (e.g. guilds / proto-guilds / communities of practice) that are required for consistency of practice or development pathways are important.

The remote:af Operating Model Design pattern uses hexagons to represent teams as they both cover the six Cs and also constrain the design somewhat. I’m fond of hexagons because they play such an interesting role in nature, they feature a lot in Cynefin’s library of complex facilitation methods and also because of Ben Gracewood’s marvellous Agile Australia presentation: Scaling without Rules. They naturally map to the six Cs and they create a natural affordance to control the number of dependencies between teams.

However, you could equally use patterns like those in Matthew Skelton and Manuel Pais’s book Team Topologies which provides an excellent reference for interaction design that focuses on reducing the cognitive load between teams and on deliberate design interventions for target architecture, or something more free-form in nature.

Team Topologies Team Types and Interaction Modes

We review and iterate our designs until we land on a model to take into detailed design:

  • Does it enable us to effectively deliver our strategic objectives?
  • Does it meet our design principles?
  • Does it break any constraints? (and is that really a problem?)

Importantly the model should be recognisable, it ideally shouldn’t be radically different from your existing operating model unless there is a specific driver for seismic change.


Continue to:

hangout at
our virtual
water cooler
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
REGISTER

“Remote AF”, “RAF” and associated trade marks are trade marks of Remote Agility Framework Pty Ltd used under licence by Remote AF Co Pty Ltd.
© Remote Agility Framework Pty Ltd. Used under licence by Remote AF Co Pty Ltd.