How service leaders can start digital delivery teams

This is a draft of some guidance about setting up digital delivery teams that I keep getting asked for in Canada. Publishing here to get some counsel, particularly on the applicability to the Canadian context. Publishing it alongside sending it out to some people we’re working with across Canada to get their specific feedback too. With the possibility that we might add it to the CDS Tools and Resources. That it’ll need to be in French, is a given ;)

Major props as usual to the collective efforts and experience that have gone into the GDS Service Manual, the USDS Digital Services Playbook and the 18F Guides.

Successfully transforming service delivery with digital technology requires new ways of thinking and operating. It requires a change in culture, skills and techniques. All of which can be hired for, contracted in, and also learned by existing staff.

Empowering a service owner

Effective service delivery teams are multidisciplinary, compact, co-located, and empowered. They can work together for years on a service, but using compact iterations they are delivering value on a daily basis.

In each of our partnerships there is someone who is responsible for making transformation happen for their service in their department; we typically call this role the ‘service owner’. The service owner has the authority, budget, connections in their department, and capacity to prioritise objectives for delivery teams to use as a framework of things to aim at.

Service owners provide and protect the teams’ agency and autonomy to deliver. Empowering a team is about bringing the right people together, establishing agile delivery principles, giving them a clear thing to aim at (an outcome to achieve, a risk to avoid, an opportunity to take advantage of).

Having done that, service owners then have to step out of the decisions of research, prototyping, testing and deploying, while advocating and path-clearing for the team and their ways of working. That’s a big ask and a big shift for those governing delivery, but it’s what it takes and it’s worth it.

Shape of a digital delivery team

Establishing digital capability in your department to transform services is hard work requiring dedicated teams of specialists. There can be as many delivery teams as you have services, and then depending on the complexity of the products that support those services, the service delivery team can look after all the products or you can create a delivery team to be responsible for each product. How many teams is a thing to be worked out over time based on operational scale, velocity and team well-being.

There’s no magic number in terms of team size. Typically, a productive delivery team is 6–8 people. This is a range that allows for an optimum number of hands, eyes and brains on a delivery without being too diffuse or difficult to coordinate. A small team with a good range of skills and the right mindset can tackle the delivery from inception through to continuous improvement and support after moving in to a live business-as-usual context.

At points over the course of the delivery team numbers and composition are likely to fluctuate — at Discovery research the team tends to be at its smallest; through Alpha prototyping and Beta release it gets bigger, and in Live running it’s at its leanest.

Coordinating human-centred service delivery

A team can be seeded with any two or three digital delivery roles. A valuable early appointment is a product manager. The product manager will represent the users, balance their needs with those of the organisation, plan out how to realise the benefits, and coordinate the team to deliver value to the service users at the earliest opportunity.

As a result of these responsibilities, the product manager will work closely with the service owner, but whereas the service owner is occasionally with the team and in the detail, the product manager is with the team and in the detail day-to-day.

Wherever possible, it’s a good idea to pair a product manager with a delivery manager, who can work alongside the product manager’s lead on ‘what we’re building, why and for whom’ and bring their focus on ‘who’s building it, where, and using what techniques and materials’. It is possible to combine these responsibilities in one role, but not preferable because doing both is demanding and, at times, in tension.

Another important pairing with the product manager is the researcher. Typically there’s at least one and sometimes two on a team. They will plan, facilitate and analyze the many research and testing activities required by the team to fill in the gaps in knowledge, test their hypotheses about what works, and determine whether the things the team have made meet user needs.

Researchers can operate with quantitative and qualitative data, although they often specialize in one of these and may prefer to call on occasional support for the other. Like the product manager, the researcher needs to be an expert on the service’s users but where the product manager has high-level understanding, the researcher helps the designers and developers by being deep in specifics.

These are roles that will be held by people you’ll want to try to keep on the delivery for as long as possible. They are the continuity for the team as it evolves in tandem with the service.

Designing and developing simple and reliable services

Designers and developers turn the challenges they are set by the product manager and the insights they are served by the researchers into things that users interact with to meet their needs. Designers and developers contribute different things but the best teams are those where these two disciplines continuously collaborate together.

Service delivery requires a number of different types of design. It is possible to find designers who can provide more than one type of design expertise, but it is preferable to enable designers to specialise. Service designers architect the different touchpoints of a service, both the current and possible states in the interests of providing the best possible user experience. Interaction designers combine patterns and elements that let people take the actions involved in using the service.

Visual designers create patterns and elements for use by designers and developers to construct the way a service looks on screen. Content designers use words and their positioning to determine how best to explain things and orientate users as they interact with a service.

Software developers also typically specialise in either frontend or backend engineering. Frontend developers build the presentation layer, so that all the elements that a user interacts with behave and interoperate properly across different screen and browser types. Backend developers build the infrastructure so that the service can take and give information in a reliable and secure way time after time across networks.

It is possible to find fullstack developers who combine both types of engineering. Development requires both frontend and backend engineering, and both are difficult. Fullstack developers are typically more experienced and take time to expand their skills after having first aligned to one type of engineering, and are therefore less common.

Although these delivery roles are expressed here in absolute terms, the key is to gradually build the relationships between team members to allow for people to specialise but also collaborate with fluidity across the disciplines. It is good to have content designers writing in code, and developers facilitating interviews with service users. This is what it looks like to be an effective multidisciplinary team.

Value of supporting roles

There are support roles that are satellite to the core team and who occasionally join the delivery at a task-level. There’s absolutely no pejorative to being a support role. Often these will be people who weren’t there every day but, looking back over the course of the delivery, they will have played a formative role many times.

The list of support roles can be long. It ranges from communications, business operations, human resources, through to the chief executive, director-general and ministers. They can be specialist delivery people — like an accessibility or security lead or a technical architect or the officials who write the policies framing the service implementation.

Another important supporting role is that of the service owner, which brings us full circle. This is the person (or exceptional pairing) empowered by the organisation to transform a service by establishing and enabling the service delivery team. If that sounds neat, it’s because it is.

Finding the people

Hiring new people into new teams offers several benefits in terms of being able to bring in the precise skill-sets you need to take a fresh look at services and how they are delivered. If you are trying to break out of the status quo, then it can follow that you bring in people who have no stake in the previous way of doing things, especially where they bring new ways of working ready-to-go.

Finding new people involves hiring in new ways. People are drawn to government work by the opportunity to work on not-for-profit opportunities to deliver public good.

Postings will need to reflect the responsibilities but also the ways of working and the value proposition to prospective candidates. They need to be advertised in channels used by the specialisms you are seeking, rather than expecting people to come to your corporate site. And, candidates will want to check whether you mean what you say before they apply, so it pays to share information about delivery and products in the open through the likes of blogs and code repositories in advance. It can take time to get the word out, and for the word to stick.

In terms of finding these roles from within your existing staff, they could come from a range of places. You can train up existing members of staff who demonstrate the right kind of domain-knowledge. Hiring from within brings with it the advantages of domain knowledge and connections across the organisation.

Start with putting out an open call and a ‘show and tell’ forum, where you can explain what you are setting out to achieve and see who answers the call to get involved. These don’t need to be long term reassignments; they can be temporary (for a period of at least 9–12 months) and those people can then be given the choice to stay on or take their new found skills and techniques back into their previous post.

Setting up digital delivery capability is not about dispensing with the ‘old ways’, it’s about bringing in additional skills, techniques and culture. Many orthodox service roles can easily transfer to new roles providing the people have the right approach to learning, risk-taking, openness and care for others. Business analysts or programme and project managers can convert into product management and delivery management.

The trick is to understand that the new roles are not subsets of the orthodox roles. Some of the skills are transferable but the shift in ways of working is significant. Service owners make that clear, set objectives as such, and provide support through training and time to allow existing people to adapt to new ways of working.

Ideally, a blended team is desirable. Bringing in people with the ready-made skills and combining them with people who have the domain knowledge is likely to be the most efficient and efficacious route to goal. Similarly, ensuring a diversity of walks of life and levels of professional experience are represented in teams brings creativity, mitigates biases and imbues teams and the services they support with resilience.

In the absence of new or converted employees, contractors present a viable short-term option. Wherever possible, combine contractors with employees, preferably in supporting roles, and ensure that the terms include passing on knowledge and skills to the organisation and its employees, as well as delivery of specific outputs.

People make a service

Being the first to form a digital delivery team to support your service is creative, exciting and gratifying work. It’s likely to be your first win. But it’s also hard and takes time. It’s not a one-shot deal. It takes time to get the first iteration of the team and then you have to coach and iterate that team over time.

Forming a team, setting them up for success and seeing them work through challenges and achieve the outcomes, is up there with the most rewarding aspects of the service owner role. It is certainly the most important. There is no service without people.