Remote First Increases Throughput at John Lewis & Partners

Last week, John Lewis & Partners announced the effective closure of their head office in Victoria, which means that a lot of staff have had to adjust to working from home.

Our experience has been that John Lewis & Partners has taken to the new remote model extremely well.  For one team, the change has had a positive impact on their ability to deliver. In the first week of the change, they almost doubled their throughput and performed more releases to customers than in any other given week in the last five months. 

This team considers collaboration to be their superpower.  They continue feeding and watering their team spirit in the new context.  There is no single correct way to do this, but here are some of the experiments the teams are trying.

Running a perpetual mass Hangouts to mimic a live office environment where you can hear each other working.  Back in the office, you would be able to simply turn around to a colleague and say, “Can I chat with you for two minutes about X, Y or Z?” and that’d be fine.  Not only that, but due to collocation, others could eavesdrop on the conversation even if they were not directly involved. The team has emulated that by occasionally having meets on Hangouts and keeping Hangouts always on.  This helps the team feel in touch with each other, and conversations can spontaneously spring up. Even though these meetings don’t necessarily involve everyone, team members still benefit from being able to listen in.

Time is set aside each day to do some form of meditation or mindfulness exercise.  This is not a group activity, but team members do this at the same time each day. By synchronising these activities, the opportunities for collaborative working are maximised.  The effect of taking this time is really felt. Afterwards, team members are all very much more relaxed and able to focus.

As part of this transition, we hosted a number of webinars to share good practices for a team working fully remote.  Most of the John Lewis & Partners teams that we work with were already set up to enable home working. However, moving from a few people occasionally working remotely to everyone working remotely all the time is not a trivial transition.  Our webinars are designed for teams that are already comfortable with working remotely. We share tips and practices that will really help them gel and perform in a remote-first environment. 

For example if you want to learn some of the techniques we use to build high-performing remote-first teams watch this webinar.

Part of our mission working with John Lewis & Partners is to enable their Partners.  This means that our consultants transfer the necessary skills and knowledge to the Partners so they can continue to develop new digital services and products for their customers. 

At Equal Experts, we have been building a remote-first mindset for years and have engaged in a number of fully remote deliveries.  That’s why we published and open-sourced our remote delivery playbook  earlier this year. 


To evolve is to survive, and to plan is to succeed, but all too often, plans are static whilst the world is ever changing. In this four part series, we propose a tried and tested approach that introduces quarterly agility into your organisation without losing sight of your long term goals.

Iceberg! Right ahead!

“No plan survives contact with the enemy.” – Helmuth von Moltke the Elder

Here at the Equal Experts Strategic Advisory Practice, we recognise that stability is an illusion, and steady state is a temporary luxury. Any attempts to create and stick to long term plans are inevitably doomed as they fail to adapt to the world around them, or take account of the discoveries made once the journey has begun. 

This doesn’t mean you can’t have long term goals; quite the opposite, but to assume you can decide today all the actions necessary to get there is folly. It is no more realistic than standing in Liverpool, pointing a ship at New York, setting its course, and hoping it will arrive at its destination unharmed with no intervention from the captain. Decisions have to be made, events adapted to, and courses changed.

Instead, you might think of strategy as being a sailing boat in high winds, crewed by a group of people with different but complementary skills, who have the autonomy to make adjustments quickly, in coordination with others, according to the conditions.

After all, sometimes there are icebergs.

Seasons come, seasons go

“In the depth of winter, I finally learned that within me there lay an invincible summer.” – Albert Camus

Of course, we acknowledge that businesses need a plan, but the duration of such plans is shorter than you might think. Consider those 2020 vision documents produced by most organisations, some as long ago as 2015. We have seen very few of those plans that made it past the first year without becoming irrelevant, and not surprisingly, none included the impacts of a global pandemic followed by a recession.

In our experience, the most effective cadence for planning is quarterly. It fits well with company funding cycles, and is short enough to allow course corrections within the financial year. It also fits well with a more fundamental cycle that affects human motivation in a way that few people recognise. There are, of course, the recognised impacts of season – the January blues, flu season, holiday seasons and so on – but there is something more fundamental. 

We humans work in seasons, measuring the end of one and the start of another. Traditionally, we had to align tasks to these seasons to ensure our crops were properly planted, tended and harvested, and our hunting behaviours adapted to the migratory patterns of animals.  Even now, in our sanitised world, we see the seasons as natural start and end points, and yet at work our projects often continue on unbroken throughout the year. As the weeks turn into months, and the end seems far away, it can be hard for us to remain motivated, and productivity starts to fall. People lose focus.

We have found that moving to a quarterly cadence, where outcomes are achieved and teams move on to the next challenge every three months, can avoid this slump. A clear break every three months give teams a fresh boost and renewed focus. This doesn’t mean you have to abandon what you’re doing; just create a clear “cake and candles” moment to celebrate success. Then you can reset direction and go again based on what you’ve learned and what has changed in your business landscape.

Switching to a quarterly cadence means you are discovering all the time and are giving yourself the space to continuously adapt your plans. That’s why we follow an approach we call Continuous Evolution.

Ninety days to done

“Learning is not attained by chance, it must be sought for with ardor and attended to with diligence.” – Abigail Adams

Breaking out of a tightly planned and predictable way of working can be very challenging. Our Continuous Evolution framework helps guide an organisation through the unknown, no matter what factors are driving the need to change, or the kind of transformation required. The aim is to build an agile and iterative strategy, in pursuit of the surest and quickest path to business value. Making well-planned interventions and measuring their impact is the key to creating the right mindset and high performance culture capable of rapidly delivering sustainable change.

Working in 90 day cycles, this three stage framework exists to: 

  1. Shape – Establish the goals & objectives of the organisation, as well as the best ways to measure progress towards them (Objectives & Key Results)
  2. Plan – Visualise how time-bound activities are aligned to the strategic priorities of the organisation, indicating clusters and gaps (Roadmap Radar)
  3. Execute – Gather, prioritise and place ‘bets’ that are designed to realise business value through experimentation, maximising returns whilst minimising the exposure to risk (Bet Canvas)

At the end of each 90 day cycle, leadership should reflect on the progress achieved, and lessons learned.  That allows the organisation to revise to their OKRs and Roadmap Radar as required, before deciding (a) which bets to evolve or stop; and (b) which new bets should be placed during the next cycle.

Stage 1: Shaping the vision

“The only limit to our realization of tomorrow will be our doubts of today. – Franklin D. Roosevelt

There’s a lot more to strategy than simply feeling your way through experimentation, and we have discussed this in previous blog posts. However, there’s also a lot more to strategy than thinking and talking – effective strategy arises from situational awareness and insight, and these can best be discovered through hands-on experience.

Not great fans of reinventing the wheel, we use OKRs (objective and key results) as the first step in the Continuous Delivery framework. However, we did strip that particular wheel back to its basics so that it could be easier for organisations to adopt and adapt it to their own needs. We find that OKRs provide a flexible, collaborative method that ensures activities are aligned to the strategy, across the organisation, whilst optimising the time spent on this activity.

The advantages of the OKR method are:

  • Strategic priorities are discussed and agreed by leadership, including the establishment of long-term goals 
  • It provides assurance that the various aims of the organisation do not conflict with or contradict one another
  • It ensures the goals and objectives of the organisation are clearly understood at all levels, through regular communication 

This transparent and non-hierarchical approach to strategy helps deliver change, by creating a shared understanding of the organisation’s long-term goals, before aligning a set of measurable objectives. Progress towards each objective (and therefore goal) is measured by Key Results, with outcomes reported to the whole business in a regular cadence. 

Stage 2: The Roadmap Radar

“Mann Tracht, Un Gott Lacht” – Anonymous

Literally translated, “Man plans, and God laughs”. It’s an old Yiddish adage and it carries a lot of hard learnt wisdom in its brevity. It sums up the fragility of detailed plans in the face of uncertainty, unpredictability and the unknown. But any venture involving more than a handful of people needs some form of plan if it is to avoid descending into chaos and conflict, and that’s why we’ve created a unique tool that carefully balances the need for direction with the importance of agility and empowerment. 

The Equal Experts Roadmap Radar provides an intuitive view of the goals and objectives of the organisation, with initiatives plotted on the radar to indicate clusters and gaps in effort. It’s simplicity allows everything to be shown on a single picture, and the ease with which it can be changed encourages flexibility to changing circumstances.

The advantages of the Roadmap Radar are:

  • It creates a portfolio of prioritised bets, to help the organisation decide where to go next, with confidence
  • It aligns effort directly to the organisation’s strategic goals, providing teams with a greater sense of purpose and meaning
  • Once misaligned activities are placed into the backlog, multi-disciplinary teams can be more effectively formed by bringing together the right, motivated people.

Once the goals and objectives of the organisation have been affirmed through the OKR process, efforts can be plotted as ‘bets’ against each objective, laid out to indicate a timeline for delivery (in this quarter, in the next quarter, etc).  By visualising the balance of effort, any prioritisation decisions are radically simplified. 

Although the Roadmap Radar shows four quarters, the only certainty is in the first of these. Everything beyond that is conjecture; sound conjecture based hopefully on best available knowledge, but conjecture nonetheless. Each sector represents an objective that can be pursued by a team, independently of the others. This reduces cross-team dependencies, allowing greater empowerment and increasing motivation.

Stage 3: The Bet Canvas

“You will have to experiment and try things out for yourself and you will not be sure of what you are doing. That’s all right, you are feeling your way into the thing.” – Emily Carr

The way we approach the “doing” part of the Continuous Evolution cycle is through the use of highly structured “bets”. These outline how experiments will be designed, how success will be measured, and the challenges and risks that will be faced. Bets are delivery focused, and are guided by continuous feedback loops.

The benefit of the “bet” approach:

  • A bet is a specific idea whose value is tested methodically through experimentation, optimising the return of business value whilst minimising exposure to risk
  • Each Bet Canvas includes a time-bound experiment, with a plan for how evidence of the impact will be gathered and analysed 
  • The progress of each bet can be reported regularly (at least weekly) and allows the riskiest assumptions or least well understood things to be tested quickly

The purpose of each bet is to (dis)prove a hypothesis through experimentation, which in turn links to an objective, which aligns to a strategic goal.  The language of ‘bets’ is intentional – how much time, effort and resource – that could be spent elsewhere – are you willing to commit to the exploration of this idea?  Some ideas require more investment to prove than others, and some are better understood and therefore require less validation. As a result, not all bets are equal.

The Bet Canvas ensures that each bet has a clear and rigorous structure, and can be displayed for all teams to see and add suggestions, comments, and questions.  It also guarantees a consistency of approach, whilst also highlighting unknowns, which allows for easy and regular reporting of progress.

Rinse and Repeat

“Yesterday I was clever, so I wanted to change the world. Today I am wise, so I am changing myself.” – Rumi

As bets conclude value is generated and lessons are learnt. With that increased knowledge and released value, the organisation can enter the next discovery cycle better informed and focused. How many times should an organisation repeat this process until it reaches steady state, and when does business as usual resume? The answer is, when the world stops changing, you can stop discovering, and until then, discovery IS the steady state.

In Part 2 we will discuss the OKR approach in more detail and give you a taste of how we facilitate OKR sessions to get the most out of them.


Part 1 – An agile strategy for an unpredictable world – (you’re here!)
Part 2 – Shaping the vision
Part 3 – The Roadmap Radar – When is a plan not a plan?
Part 4 – The Bet Canvas – Nothing ventured, nothing gained

Strategic Advisory free session

As a technical architect at Equal Experts, I’m fortunate to work with clients at the start of their decision-making process for new, large-scale IT projects. One of the questions I’m often asked is: “Should we buy, or should we build?” Not surprisingly, I have views, and am always happy to share them.

Recently, a client gave me a novel take on this subject that I hadn’t considered before. He likened the costs associated with building software to making a chicken sandwich. Specifically, he told me the story of Andy George, who made a documentary series following his mission to make a chicken sandwich from scratch – and I do mean from scratch. He harvested wheat, ground flour, milked a cow, made cheese and butter, boiled sea water to make salt…you get the idea. At the end of his journey, he’d spent $1,500 and 6 months creating a single chicken sandwich, which he could have bought the same day from a local store, for less than $5.

It’s a fascinating story (you can watch the videos if you have time), but having considered it for a while, I don’t believe it’s a valid comparison.

We don’t need to make our own salt

Here’s the thing. When we build software, we don’t build it from scratch. We assemble all the base ingredients (common services, third-party libraries, databases, etc.), and then we build the important stuff: the business-specific functionality that makes your software different.

Returning to the chicken sandwich analogy, building custom software is like buying the ingredients (bread, mayo, chicken, salt, etc.) and then making the sandwich in the way that you want.

This is the gist of my argument. It’s rarely a question of build or buy; in most cases we build and buy.

If all you need is a cheeseburger, buy a cheeseburger

So, now I’m on a roll with the food analogies, let’s look at one of my own relating to buying commercial off-the-shelf (COTS) software.

When buying a COTS solution (for example, SAP or Salesforce), my view is that it’s like going to McDonald’s for a cheeseburger. The cheeseburger is fine (there’s nothing wrong with it), but you can’t customise it. At best, you might be able to ask for a different type of bun, or to leave out the sauce, but you can’t ask for Brie instead of cheddar, or to add a fried egg. If something isn’t part of the standard offering, then sorry, but you can’t have it.

This is perfectly good if all you want is a cheeseburger, you don’t need your cheeseburger to be different, and the cheeseburger in question fulfils your exact needs.

The same principle applies to software. If a COTS solution does what you need without customisation, and you don’t need it to differentiate your organisation from all the other organisations that are using it, then go the COTS route.

Of course, there are situations where this is the best approach – typically for internal, non-customer-facing systems (e.g. accounting systems).

A few tips for buying software

  • Try before you buy. No matter how slick a software company’s demo is, always try before you commit to anything. Even if the vendor has no official trial offering, negotiate one (six months, if you can).
  • Avoid long-term tie-ins (I recommend no more than one year).
  • Go for a module-based product and only buy what you need.
  • Don’t customise. Use the product out of the box and build additional features around it.
  • Ensure that the product follows your architectural standards and patterns (e.g. integration via RESTful APIs, event handling or scales on load).

Principles for when to build or buy

My key principles for the decision-making process:

  • Build what differentiates you. If something is core to your business and represents who/what you are, don’t rely on someone else to provide it.
  • Software developers can be very keen to develop everything from first principles! But if something isn’t core to your business and it’s not a differentiator, buy it.
  • Do what delivers value the fastest but maintain flexibility so you can make changes as requirements change/grow.
  • If you’re still not sure which way to go, build first, then test and reassess. This will clarify requirements and if it’s not what you want, you’ll have a better idea of what you need to buy.

What is a differentiator?

Gone are the days when software was something in the background that took care of the boring stuff and couldn’t be a differentiator. Now, software solutions are so often the thing that improves business processes, enhances customer experience and ultimately drives revenue generation.

So what qualifies as a differentiator?

  • If something is core to your business (i.e. important enough to be in your business plan or part of your business strategy), then it’s a differentiator.
  • If customers come to (or stay with) you because you do something that your competitors don’t – or you do it better – then it’s a differentiator.
  • If it’s a missing or poorly performing feature that might prompt customers to move to a competitor, then it’s a differentiator.
  • If something generates direct revenue, it’s a differentiator.
  • If the business is willing to change its processes to align with a software product, then it is probably not a differentiator.

Costs (and super powers)

One of the points I stress to clients is that we don’t build software or move to the cloud because it’s cheaper – often, it’s not. We do these things because they provide the freedom to be innovative, fast, and better than our competitors.

Of course, costs must be considered – but so too must value.

Total Cost of Ownership

During budgetary discussions, clients often focus on the cost of buying software licenses and support but neglect many items that impact Total Cost of Ownership (TCO).

I advise considering the future costs associated with:

  • Ongoing maintenance after the initial license period ends.
  • What would the cost be if you need to customise for a specific feature?
  • Upgrades of customised solutions. Once a standard product is customised, it’s often very tricky and thus costly to upgrade.
  • If you can’t make changes to your solution quickly and easily, you’ll be slow to market and risk missing opportunities.
  • Product switching. Committing to a large, upfront license fee can make switching solutions, in the future, prohibitive
  • Contract negotiations. Never underestimate the time and effort it takes to negotiate a contract with a major supplier. Once the lawyers get involved it can really stretch your delivery timelines.

True Value of Ownership

People are generally very familiar with return on investment (ROI) – invest £10m and get £12m back; it’s monetary and, therefore, very straightforward.

But value isn’t always reflected in direct revenue; it’s about other things – customer satisfaction, agility, innovation, etc. This is where building your own software can really come into its own.

In fact – not to be overly dramatic – but I’d argue that building software is a real-life super power. It’s where you can absolutely achieve far more value over buying a solution.

We don’t deliver software like we used to. Continuous Delivery makes the whole process fast and lean. So, when you choose to build:

  • Value is realised sooner. The bones of an idea can become fully-formed reality, incredibly fast – as fast as you want it to be. And of course, the sooner you get your solution to market, the sooner you’re realising value.
  • You only need to build what you need. Often, people buy huge, expensive systems for features they think they need, but actually never use.
  • You only need to build what is valuable.
  • Your only limit is imagination; you’ll never be constrained by someone else’s framework or roadmap.
  • You can build differentiators. If you can buy COTS software that does great things, so can your competitors – any potential differentiators are gone.
  • It’s your Intellectual Property (IP). If you’ve bought a solution and you ask the supplier for a customisation which adds value to their core product, it’s likely that they will offer it to other customers – you have no control over this.
  • Change is easy. As the context surrounding your business changes, your software follows suit.


In my conversations with clients, I completely understand when they say this:

“Of course, you’re going to say ‘build over buy’. You work at Equal Experts. That’s what you do.”

Yes, we’re in the business of building software, but we do this because we think the final solution will make your organisation unique, agile, successful and simply more effective.

Ultimately, this isn’t about diametrically opposing views. As I said way back at the start of this post, it’s not a question of whether to build or buy; almost invariably it’s how to build and buy.

When you consider what you need to build and where best to source standard functionality, it should always be in the context of maximising value – this is where greatness lies.