Remote Operating Model Design Process - Step 2

Part four 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 fourth article in a multi-part series:

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


Step two: agree on design principles

Agree on Design Principles

If you can agree on the principles for operating model design then the task of designing how you will organise to deliver value becomes a lot more simple. remote:af recommends the following design principles as a starting point:

remote:af operating model design principles


In an operating model design process we normally provide a little bit of education around generic operating model design concepts and design principles before asking the group to craft a set of design principles that are unique to their organisation.

Here is an example from Reform Clothing, an Australian scale-up that helps groups build identity through apparel and aims to make a significant impact on the sustainability of the garment industry:


Design sliders

Throughout the design process you’ll run into some challenging questions that don’t have a right or a wrong answer, so it’s useful to have a bit of a think about some of the curlier aspects up front. Once we have an agreed set of design principles we can explore some of the tension through the use of sliders, e.g.:

Enduring teams vs Labour flexibility

A focus on enduring teams usually leads to a higher proportion of permanent labour over contingent (contractor / consultant) labour. This is great for maintaining knowledge and building strong teams but can cause challenges if funding is volatile or trending downwards.

Small teams vs Fewer dependencies

Small teams tend to be more effective but may lead to more complex dependency management if there is not also a focus on engineering the dependencies out of the system through capability development or engineering.

Distributed authority vs Central control

Distributing authority to teams can create autonomous high performing units but requires high calibre talent that has been carefully inducted, clear information flows and decision making frameworks. It can lead to a loss of visibility and control at leadership level and also simply won’t work with some leadership styles.

Shared knowledge vs Feature throughput

By identifying knowledge constraints and resolving them by distributing that knowledge through teams, we can gradually make the system more resilient to key person risk. However, this can come at a cost to short term throughput.


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.