Digital transformation at Wellcome Collection

Digital transformation is fundamentally about people, culture, processes and how we can use technology to place our users first and deliver services that are useful, fun or empowering.

But how do you create an environment where you can foster a culture that makes it possible to design, build and produce the things that matter to your users?

‘Developing mouse embryo days 1–4’ by Dr M. Zernicka-Goetz, Gurdon Institute. Credit: Dr M. Zernicka-Goetz, Gurdon Institute. CC0

In this article I will try to outline how we (Wellcome Collection’s digital department) have tried to create such a culture and the processes we’ve adopted to support that culture. I realise that much of this will feel very, familiar to many but I suspect for others not so much; as ever this is our experience — I hope it is helpful but I’m not suggesting those experiences apply to everyone.

During 2016, as part of a wider review of Wellcome Library, we developed a series of ‘Tent Poles’ — principles that we held to be true and on which we would hang our work and working practice. It is probably worth noting that the Tent Poles were written with the library in mind, not only digital, they are:

We embrace openness, accessibility, diversity and inclusion

• We design services to be inclusive and accessible to all.
• We respect lived experience of health and illness and seek to expand the diversity of voices represented in and around the collections.​
• We are committed to widening access to our content as far as possible, whilst behaving lawfully, ethically and responsibly.
• A plurality of voices helps great ideas to thrive.​

We embrace consistency not uniformity

• We are consistent and coherent with everything we offer, the approaches we adopt and the way we work.
• We respect variety and diversity but we start by considering what is common before we look at what is different.
• This enables everyone to understand our core purpose and place in the world.
• In addition, it improves the comprehension and usability of our services and makes us more efficient.

We embrace an agile and iterative approach

• We believe in continuous improvement and foster an experiment-friendly culture.
• We ask ourselves: “what was the outcome?”, “what did we learn?” and “what will we change?” not “what did we launch?” and “what was the output?”
• We make decisions based on evidence where the question is not: “this or that?” but “how do we test both?”
• We make progress by taking a thousand little steps, not one or two giant leaps. We reward people not for grand initiatives but for the outcome they achieve.
• Teams have the tools, environment and support to make it easy to get stuff done.

We embrace decisions based on an understanding of our audiences

• Understanding our users is at the heart of everything we do.
• We spend time understanding what they do, what they want to do, what they can’t do, and we test our ideas with them.
• We consider those who use Wellcome Collection today and those who might.
• Our users decide what is good.

We embrace the benefits of working with others

• We create and foster communities and networks.
• We work with others to share knowledge and resources and extend our own reach and impact.
• We learn from others to broaden our perspective; to challenge and refresh our working methods; and to bring new ideas and new audiences to what we do.
• We generously share with others both to minimise duplication of effort and to contribute to a thriving ecosystem.

These Tent Poles draw on the work of others and, in part, reflect the values one might normally attribute to agile or lean teams but applied more widely beyond the working of an individual team. This is intentional because we want a culture that is focused on the needs of our users, an open culture that encourages learning and continuous improvement and processes that derisk the work by taking small, purposeful and repeatable steps. In practice this means that we:

• plan against objectives and outcomes on a quarterly basis rather than around projects;
• define our work and make commitments (in the quarterly plans) via a series of objectives and key results rather than proposals and specifications;
• provide stability by budgeting on a team basis every 12 months but allow for flex on a quarterly basis based on the momentum of the different teams;
• organise delivery around long term product teams where the teams are loosely coupled, with long term commitments and measured via a small number of KPIs;
• we care about velocity against KPIs not targets;
• treat every release as an MVP — a point where our current, best understanding of our users and their needs allows us to iterate the site design or content;
• user research and interface testing is an ongoing activity and, along with analytics, is the way we orientate our designs and backlog (we run weekly user research and UX testing sessions);
• make small changes to practices and procedures as well as digital products and services based on actively reviewing what’s working and what’s not;
• are open about what we do and how effective we are — everything is open and we hold regular updates to discuss our work.

At the heart of this approach is the idea that teams, not individuals, are responsible for delivery and that teams work most effectively in stable (but not static) environments where they can work together to uncover the best solution. And that teams get good by repeatedly taking small purposeful steps and in so doing can improve the overall user experience more quickly with less risk than via large leaps. Or as others have put it: “Slow is smooth, smooth is fast”.

What does this look like in practice?

As I’ve mentioned we structure the delivery of our work around teams rather than around projects, applications or individual objectives; this means our departmental planning focuses on a small number of artefacts and regular key events:

Roadmap — we maintain a high-level roadmap of objectives and key results (not a roadmap of features) for the UX, data platform and digitisation work. The roadmap is intended to help everyone understand the department’s overall development priorities and help align design and development activities. So rather than setting out work packages by estimated delivery dates it sets out a broadly prioritised list of objectives broken down into: Previous quarters, Current quarter, Next, Future, Later and Ideas. We hope to meet our current quarterly objectives but are less certain and specific as we look forward beyond the current quarter.

Extract of the Digital Engagement Roadmap

Quarterly plans — every 90 days each team (editorial content, digitisation, photography, digital experience and platform development) sets out their planned work for the quarter. Again we don’t define the features but Objectives and Key Results. The team manager is responsible for defining the team’s OKRs but the team is responsible for determining the work within those OKRs i.e. the whole team creates the backlog for the quarter by scoping what they’ll do to meet the key results.

At the end of the quarter we review the key results and progress against KPIs and then rip up the quarterly plan and backlog.

We don’t automatically carry work forward from one quarter to the next. If something’s still important it will covered by an OKR in the new quarter but we don’t assume it should — after all we might have learnt something new or the environment might have changed and our previous assumptions and hypotheses might now be wrong.

We’ve found that quarterly plans have a couple of other benefits: Firstly the cadence helps encourage a regular exercise of review and evaluation and this in turn provides a useful release valve — it helps stop teams getting caught up in a ‘death march’ where they feel obligated to keep going even when they know they should change tack or stop.

Budgeting — In my experience, with digital, you can’t assume that you can make a large upfront investment and then move into ‘maintenance mode’. Digital just doesn’t work that way because people’s expectations change, what’s possible changes and technology changes. Of course these aren’t independent issues, changing technology has an affect on people’s expectations but it also means that software effectively decays over time — as someone once said (sorry I can’t remember who) “software is like fish, data is like wine”.

Periodic capital investments mean you can’t take advantage of new technology nor quickly address emerging user challenges. Which means you can’t easily deliver value to the user nor the organisation in a timely fashion. Which is why we set team budgets on an annual basis, and this allows us to define our roadmap and make commitments about overall velocity. However, the quarterly planning cycle allows us flex budgets based on the momentum of the team and their ability to effectively increase (or decrease) their velocity.

Internally we are also transparent about our budgets and costs — for example development teams are fully sighted on the cost of our infrastructure. This is (I think) both motivational and respectful of the teams. It encourages the teams to consider the financial impact of their development choices and where appropriate prioritise (automated) ways of efficiently managing those infrastructure costs.

Transparency — throughout the year we organise a series of different ways to help everyone better understand what is happening across the department and what’s planned. This ranges from fortnightly demos by product teams through to quarterly departmental meetings where all the teams talk about what they’ve achieved and learnt in the previous quarter and what they plan to do in the next. And finally we hold quarterly Showcases, open to everyone at Wellcome, where we talk about one area of work in more detail. Progress against our KPIs are reported on a monthly basis.

Infrastructure and deployments — underpinning these procedural elements is a infrastructure that allows us to easily make and deploy changes. We are currently making around 20 deployments a day without any disruption or downtime. But the ability to make changes applies not only to our applications but also to the infrastructure itself which is managed as code and fully reproducible allowing full Blue-Green deployments.

Screenshot of the infrastructure monitoring dashboard showing a service mid-deployment

What about projects?

You will notice that we don’t organise our work into projects, we don’t write proposals for committees or project boards to evaluate and approve (or not), we don’t have project teams.

In my experience, for digital at least, projects are at best an unhelpful organising principle and at worse they can become an anti pattern.

Before I explain why it might be worth stepping back and reminding ourselves what a project is, according to Wikipedia a project is:

“…a concrete and organized effort motivated by a perceived opportunity when facing a problem, a need, a desire or a source of discomfort… Each project has a beginning and an end, and as such is considered a closed dynamic system.”

In my experience this typically means that someone writes up a proposal, business case or something similar promising something if they are given the money, a team of people and the time to do it. Typically the deliverable, the available time and money are fixed and praise is heaped upon those project managers who ‘deliver on time and on budget’ i.e. there is a focus on the output not the outcome. Projects are also set into an environment where they compete against other ideas, other projects with a committee of some sort deciding what to fund and therefore which ideas are best.

With digital at least, this has a tendency to breed bad behaviour. Teams are rewarded for exaggerating the benefits and cutting corners; the effort of getting a project approved means Project Managers, stakeholders and teams are less likely to admit they made a mistake and closedown an unsuccessful project, and project boards are asked to guess which ideas are best without any actual data. This in turn favours those Project Managers who are confident, eloquent and most likely to take risks and that’s not good for team diversity.

Treating digital in the same way one treats capital projects also tends to impact the user experience and overall quality of the product. Towards the end of a digital project, especially if the project is overrunning, there is a strong motivation within teams to lower quality, ignore user research and reduce scope to avoid submitting another business case. Ironically of course it is often this work that makes all the difference to the user.

Organisationally, approaching digital as a series of discrete projects is often horribly inefficient because there is a strong motivation to do something new instead of building on what’s there. This is understandable, often the (by now) legacy code is old and difficult to maintain — it hasn’t kept pace with changes in technology, there might be nobody left at the company who is familiar with the code base and the shortcuts taken to get the project shipped last time means nobody wants to touch it now.

That’s why we don’t do projects. Instead we take small, informed steps set within a stable environment where teams are empowered to discover the right path. In our experience this gives better results for the end user and to the organisation because you don’t get good at something by jumping from one thing to the next erratically but by remembering slow is smooth, smooth is fast.

—

Thanks to Jonathan Tweed, Hannah Brown, Jenn Phillips-Bacher and Robert Kenny for reviewing drafts of this post.