P/02  ·  Back to projects

NatWest Group

Insights Engine

Turning engineers into the customer — optimising a software engineering department by redesigning the employee experience.

NatWest Group logo

Client

NatWest Group

Method

Service design

Discipline

Product & platform

Sector

Banking

01 — Background

An engine of insights into the developer experience.

NatWest Group wanted to optimise their software engineering department and improve the employee experience for a substantial community of developers spread across many projects.

Management believed that a robust engine of insights could gather comprehensive data on the employee experience, and that this data could then be used to improve it. The hypotheses were straightforward: a better work environment would raise efficiency, strengthen retention, and contribute to the overall success of the bank.

Having been introduced to service design, they wanted to explore whether it could work as the methodology to carry that ambition forward.

Early research and mapping of the engineering community
Mapping the engineering community

02 — The shift

We treated the engineers as the customer.

03 — Problem

Frustration was costing the bank knowledge.

NatWest's software engineers were dealing with a disordered employee experience, and the resulting frustration was pushing people to leave.

Every departure set projects back and drained knowledge from the community. Weak practices created delays through dependency bottlenecks, and research and insight moved poorly between teams that needed it.

The consequences landed on the things the department was measured by: time-to-market, team morale and staff retention all suffered for the affected teams.

Analysis of pain points across the engineering experience
Pain points across the experience

04 — Solution

Customer journeys turned into data-driven service blueprints.

Taking the engineers as our primary customers, we explored their experience across the whole of their working life at the bank — onboarding, running bespoke projects, day-to-day operations, and the process of leaving the organisation.

Those customer journeys were systematically turned into data-driven models and placed at the front of the service blueprints. The blueprints worked as alignment frameworks, showing how the activities of every team across the organisation connected to each other.

They captured both the visible, customer-facing actions and the backstage processes behind them. Examining the two together is what surfaced the pain points, and the opportunities to improve the contextual encounters that happen at every major and minor juncture of the job.

Journeys mapped

OnboardingBespoke projectsDay-to-day operationsOffboarding
Service blueprint showing frontstage and backstage activity across teams
Service blueprint — frontstage and backstage

05 — Living documents

Blueprints that keep working after the project ends.

In the digital realm the blueprints behaved as living documents, receptive to both qualitative and quantitative information.

That let insight accumulate over time around areas of concern and potential risk. The blueprints then served two purposes at once: repositories of Management Information for evaluating historical performance, and sources of Business Intelligence for planning a more enriching future.

R/01

Management Information

Evaluating how the department has actually performed, on evidence rather than impression.

R/02

Business Intelligence

Strategic planning for what the engineering experience should become next.

06 — Impact

A common language for issues, risks and improvement.

Impact mapping frameworks were built to plan for and assess the hypothetical benefits of any change before committing to it.

Each table carried a clear provenance: from goal, to the people affected, to the impact planned, to the metrics that would measure it, to the change actually delivered. Nothing arrived without a stated reason.

They proved popular with staff and management alike, because both could see the vision and the strategic route to their goals in the same place — and could finally talk about issues, risks and improvements in one shared language.

Provenance chain

GoalPeople affectedImpact plannedMetricsChange delivered
Impact mapping framework linking goals to delivered changes
Impact mapping — goals through to delivered change