Let the Lightning Out of the Bottle | A Sullivan & Stanley Technology Panel Report

Let the Lightning Out of the Bottle. ‘Solutions’ imposed on delivery teams are frustrating business change.

No more second guessing.

No more passive delivery.

Command.

Control.

Fail.

A Sullivan & Stanley Technology Panel Report

2

3

What Are We Saying?

Transformation disappoints and technology makes a great scapegoat.

But the real problem is the thirst for ready made, dialogue-free solutions.

Customers are second guessed and delivery teams forced along pre-determined paths.

Waste, complexity and failure follow.

Tech can deliver value quickly and often. But we have to bid farewell to top-down dictation and passive execution. Let’s get IT and business listening to each other and create genuinely collaborative teams that deliver successful and continuous change.

And let’s build products matched to the needs - and future needs - of customers as they actually are, not as they are imagined to be by one or two individuals.

We’ve drawn up a kind of manifesto for change.

We know that tech can deliver much more than it’s currently allowed to do: it’s time to let the lightning out of the bottle.

Who’s Saying It? We’re senior technology practitioners – coal face types, not career consultants – who’ve individually led many successful, large scale change initiatives.

We got together to synthesise our experiences, pinpoint common elements and summarise the lessons.

Information on the participants can be found on page 23.

“

“We’re talking about user-centricity and it’s got two dimensions. One, how do you get business stakeholders to really engage with technical delivery?

Two, how do we put the external customer at the heart of all we do?”

“

4

5

6

7

One: Fundamentals “There’s rarely conversation about what might actually deliver value for the customer” It seems blindingly obvious to differentiate between problem and remedy. Yet all too often the two are conflated: a solution is assumed rather than explored. Conventional playbooks dictate conventional solutions so tech is usually applied to solving yesterday’s challenges.

“Delivery teams are expected to just follow a lead. That’s a recipe for building stuff with potentially no value because the elements that really make a difference are missing. Technology then gets hit for failure to deliver in terms of time, budget, features, whatever. Yet, these are only symptoms of a much bigger underlying issue – a failure to focus on what customers want and need.”

“You want to do A, B and C? Well, ask ‘what problem do we have that A, B and C are supposed to solve?’. And then the followups: ‘what constraints do we need to consider while thinking of a solution? What range of answers might there be to the problem?’. You use all that to inform development. Principles trump playbooks: have a consistent vision and direction but don’t predetermine the path.”

8

One: Fundamentals - Continued

“Get into the data and define what success looks like” They said…. “‘The technology stack needs to be replaced’. We proved that wasn’t necessary. By being objective and getting into the data. By defining what success looked like and using that to inform the changes we made, rather than defaulting to conventional assumptions.”

They said….. “‘We’re going to rip out our current digital platform’. Instead, we re-factored where possible, used open source capabilities and reduced delivery cost from £250 million to about £70 million.”

They said…. “‘We need to spend £20 to £30 million on rebuilding technology because people aren’t adopting digital’. We said, ‘let’s take a closer look and understand what’s failing and why’. We found 95% of the work was simply about tweaking the customer experience.”

9

“No customer is just your customer” It’s ultimately about the customer, not the product. The technology helps you get the product right and product is what brings them in and what keeps them coming back. “Businesses second guess and, as a result, overthink what the customer wants. They’ve not actually researched what people want or how they think.”

“You might not be in competition with Amazon but Amazon can still kill you.”

Why? “Because people compare services. Even if you’re not competing business wise you are competing experience wise.”

Say you work for an energy company: “your customers aren’t just electricity customers, they’re Amazon customers, Netflix customers, Facebook customers. People are very familiar with good digital experiences and will judge you by those standards. Don’t compare yourself to obvious competitors, compare yourself to the best digital experiences.”

“

“It’s not about a supplier team, or a technology team, or a business team.

It’s about a network of capabilities coming together.”

“

10

11

Two: Product Belongs to the Team “You don’t need to know an industry to be a great product owner” “The fetishization of subject matter expertise makes for unhealthy corporate cultures. It stops organisations looking outwards.” We’re all used to the product owner who’s a subject matter expert. But “they tend to be experts in what worked yesterday so they dictate the team’s path rather than talking things through”.

Good product owners don’t say ‘you have to build in this particular way to align with this particular strategy’. It’s more a case of their framing the commercial context, defining the problem the team has to solve and setting a clear, high level goal such as ‘we want a product to compete with X’.

“The best product owners are servant leaders.” They know how to empower the team, to supply what it needs. “They have to be very, very good at knowing who to speak with and what levers to pull in the organisation.”

12

Two: Product Belongs to the Team - Continued

“A range of capabilities in a single team”

“There’s a lot of protectionism around. Too many business players think they’ll lose ground if technical teams are allowed to participate in decision making.”

But participation is the key. Multi-disciplinary teams where proactive technical and design experts work in partnership with business expertise. “The silos have to go. It’s not about a supplier team, or a technology team, or a management team. It’s about a network of capabilities, a mix of commercial, operational, design and technical people coming together to solve a problem.”

“So we took the barriers away and said ‘you’re not going to have a product owner who’s going to tell you what to do, and you’re not going to have a commercial team writing requirements. You’re one team and you’re going to challenge each other to deliver an effective outcome. Business experts will contribute but not dictate. And the solution won’t belong to the technical lead either. The product belongs to the team’.”

“When recruiting for a project, intentionally look for a proportion of people who haven’t worked in that industry. Bring subject matter experts in as you need them but as a rule of thumb keep them to about 10% of team membership.”

Teams work best when there’s a clear common understanding of the goal. “The first objective is to come up with a narrative, feed that narrative to everybody and repeat it to death. Keep it simple so as to leave people space to think. You can’t overstress the value of crystal clear communication, including metaphor and visualisation, in order to provide clear reference points”.

13

“

“Technology can’t afford to be mysterious. Show that early delivery is possible. Build trust and create engagement.”

“

14

15

Three: Dismantle the Black Box “You book a room and give a live demo” We all talk about transparency but what does it mean in practice? How does the product team win trust and space to operate? By dismantling the ‘black box’ which renders tech opaque to the uninitiated.

“Recognise that this isn’t about a series of one-to-one conversations or monthly committee meetings. You book a room and give a live demo, 5pm every Wednesday. ‘This is where we are, this is what we’ve achieved this past week. Any comments? Criticisms? Ideas?’”.

“Demystification! The benefits are immediate. It builds trust in what delivery teams can do because people see progress with their own eyes.”

Demos allow quick course correction too. “Timely feedback is massively derisking. It doesn’t put all the onus on the team either because the rest of the business understand that they’ve got to reciprocate. Too many clients are actually passive themselves. We need to upskill them on what tech can do and bring them along.”

“Technologists need to be much more proactive. Every person in the delivery team should spend time in the organisation’s key functions. They can learn so much and can offer much more because they see the issues they face. You need strong relationships at every level. There should be a lot of interplay.”

Three: Dismantle the Black Box - Continued

“Early delivery is possible” “We all know how it feels to be

“It goes like this. Here’s the problem

developing a product at speed and

we’re trying to solve. Here are the

then the project gets handed over to

OKRs we’re going to use to measure

a different team. It’s like you’ve hit a

success. Our incentives are linked to

wall.” There has to be continuity. Most

hitting them. And every 90 days we

companies follow waterfall and scrum

reset the targets. As long as you hit

principles to the letter “which makes

them you’re a success. If you deliver a

no sense. You go under the water for

hundred things but miss those targets,

six months before coming out and

then you’ve failed.”

sharing. And rigid adherence to scrum means working on too many things at

“That flips the whole thing on its

the same time so velocity falters.”

head. The team stops thinking about projects and products. They start to

“Scrum line is where you add lean to

think about outcomes and get into

the mix. You develop a specific feature

the data. Every week we see how

of any given application with more

we’re tracking against those targets.

people, so by the time you share it’s

It’s those small nudges, those small

actually working. Scrum line means

tweaks that make the difference. It

delivering piece by piece, which is a

completely empowers the team.”

fundamentally different way of doing agile.”

Organisations

wrap

layers

of

governance and bureaucracy around Early delivery is possible. One of

product teams - programme boards,

Sullivan & Stanley’s core principles is

project boards, work stream meetings.

“delivering value every 90 days. But

“Sending detailed weekly PowerPoint

we don’t see the necessity of waiting

decks to stakeholders creates a nice

even that long to deliver tangible

warm impression of control. But too

output. You can do a 15 day discovery

much control kills progress. It’s about

and in those 15 days come up with

delivery of value, right? Those closest

something useful. It might just be a

to the problem have to be free to take

prototype, it might just be a proof of

real decisions.”

concept but it builds engagement.”

16

17

“You have to custom engineer user experience” “There’s no such a thing as a pure system integration play. I was part of a fifteenhundred person, £2 billion transformation programme where they wanted to buy products and configure them out of the box. It didn’t work. Buying software and customising the heck out of it is where the danger lies. You end up building in complexity. If you want products that will make you best in class you daren’t resort to wholesale buy.”

“There’s always something you have to build, and at minimum, it’ll be the user experience. Custom engineer anything that is a differentiator for you, which is basically any factor that’s going to improve end user satisfaction.”

There has to be glue for the whole project and it’s always the bits that really make the user happy. You build those.

There’s no need to build from beginning to end. I don’t build my own database, I don’t build my own storage. I will buy those because they don’t differentiate a business - some off-the-shelf stuff is designed to be customised in limited ways. It’s buy or build, not buy then build.”

18

19

Parting Thought “Transformation is a flawed concept because it infers an end state. We’re about making change a constant, about reaching a point where the business can continually transform itself.”

In a Nutshell: Recommendations Run a continuous data-driven dialogue with delivery teams in order to closely define issues, constraints and the range of available solutions. ●Define what success must look like by reference to your customers’ expectations. Compare your offering to the best digital experiences regardless of industry rather than to those of obvious competitors.

C ● reate multi-disciplinary teams where IT works in partnership with commercial and operational expertise, where neither business nor tech dictates a solution.

R ● ecognise that subject matter experts are usually people who know what worked yesterday. Appoint non-subject matter product owners who know the organisation and can facilitate the team’s work instead of dictating a path. ●Stage frequent and regular demos of the team’s work to highlight progress, build engagement and get real-time feedback. ●Be flexible about waterfall and scrum techniques: early delivery is possible if teams are incentivised to hit specific targets in short time frames. ●Insert delivery team members’ into key organisational functions in order to get detailed insight into day-to-day needs.

Accept that best-in-class products don’t emerge from wholesale buy.

You can’t buy differentiation, custom design and engineer anything that determines the customer experience.

Please contact Darren Linden, Chief Transformation Officer at Sullivan & Stanley to discuss any of these points further.

20

21

About Sullivan & Stanley Sullivan & Stanley (S&S) is an award-winning consultancy disruptor that deploys teams from its top 5% expert network, The Change Society, to solve the challenges companies face when undertaking change. Founded in 2016, S&S was born as a rebellion against ineffective change management practices.

As a full-service solution, Sullivan & Stanley works closely with its clients to quickly get to the root of their problems, co-creating unique solutions and turning them into 90-day outcomes. S&S believes that it’s time to retire the word transformation because every business should embrace change as a constant.

S&S Technology Panelists 2020

22

Darren Linden

Remi Caron

Chief Transformation Officer, Sullivan & Stanley

With nearly 20 years of experience in digital change, Darren has led large-scale clientside transformation in blue-chip brands including AOL, T-Mobile, O2UK, Sky TV and Barclaycard. Darren is a member of the S&S Leadership Team, shaping its highly differentiating consulting proposition and principles as well as working hands on with our clients and Associates across all sectors.

Aubrey Stearn Aubrey is a hands-on CTO who can generally be found in the start-up or Intrapreneur space, well known in the DevOps community for her brand of engineering she can often be found sharing a stage at London meet-ups and conferences.

Ralf Jeffery Ralf has more than 12 years of agile experience and 30 years overall experience within IT software and digital transformation. Throughout his career, Ralf has delivered innovative customer-centric digital solutions for multiple international blue-chip organisations including WorldPay, VISA, Santander, Coutts, O2, LEGO, as well as early-stage startups.

Reda Hmeid Reda has over 20 years of experience in software engineering and for the last 10 years has been a consultant. As a technology strategist, Reda focuses on delivering technology and change and has recently been instrumental in transformations at HMRC Digital and Thames Water.

Remi is an innovative, accountable handson IT Executive with an accomplished 25+ year career reflecting a track record of taking business to the next level through technical expertise and decisive leadership. Provoking thought-leadership by challenging the beaten path or status quo, improving people and enabling businesses to be more competitive.

Where others see problems, Remi sees opportunities.

Roderick Cain Rod has over 25 years of experience coaching and successful delivery of working software into multiple bluechips.

Having experienced every part of the product life cycle, Rod currently mentors organisations on how to continuously improve in order to implement the best operational processes and procedures to enable smoother delivery and faster time to market.

Sean Reilly Sean is a technology leader with over 20 years of professional experience as a software developer, technical lead, and technical architect. He has worked in a wide range of industries from complex capital goods and e-commerce to telecoms, and nearly everything in between. Currently, Sean is leading engineering at a startup bidding for the fourth UK National Lottery licence.

23

Partner with S&S to help your organisation Rethink > Reorganise > Reinvent Contact us today to help your organisation embed the leadership attributes needed to make change a constant, remove the risk of investments not delivering value and develop the capability to deliver rapid competitive responses to disruption that obsess about the customer.

hello@sullivanstanley.com www.sullivanstanley.com

A Sullivan & Stanley Technology Panel Report