What I learnt leading empowered teams at scale in Teacher Services

I've spent the last 18 months leading Teacher Services.

Teacher Services is one of DfE's largest digital portfolios. We have long-lived service teams that are empowered to decide how to achieve their objectives. We've grown quickly and have been changing how we work together as we scale. We're moving from building great services as individual teams, to making decisions about the journey for teachers across their careers. We're also changing our role in DfE. You can see our service line here.

We've achieved a lot. As I leave the department, I wanted to reflect on 4 things I've learnt.

1. Strategy needs to be specific

The Teacher Services leadership team knew that as the services matured, we'd need to join-up more. We also knew we shared problems across the service-line. Everyone agreed to "join-up" more, but no-one grabbed the concept and applied it. This was partly because we didn't initially explain the detail.

As leaders who sat across the entire service line, we agreed to focus on 3 specific problems:

• Communicating with users across the service line coherently
• Tracking people from their first contact with our services until they leave the profession
• Simplifying the routes into teaching.

Our Lead Content Designer led on communicating with users. She worked with two service teams to encourage newly qualified teachers to look for jobs immediately after achieving Qualified Teacher Status. The successful campaign led to further experiments around how to increase conversion in this part of the journey.

Our Principal Technical Architect led on improving how we track people as they interact with our different services. Eventually we built a service that will integrate with GOV.UK One Login and all our services. Once implemented, we will be able to better track people, provide them with a more personalised experience and reduce their administrative burden.

Policy colleagues reduced complexity around routes into teacher training.

'Joining up' was successful where we had well-defined problems, teams that understood the urgency and potential impact across the service line. Where we lacked one or more of these, progress was slow.

2. Dependencies don't need to stop delivery

We broke our service line down into individual service teams because of the scale.

Once services were built, we needed to move out of our self-created silos and think like a service line. It was no longer enough to just deliver quickly, we also needed to consider competing priorities. This was challenging given people naturally prioritised their own service outcomes.

We made sure everyone understood the objectives of each service, and how they contributed to the overall objective of an excellent teacher for every child. Our Senior Leadership Team built collaboration and trust, and we felt the benefits of working together. We introduced a "transfer window" where people could ask to move teams for a new challenge. When people moved, they brought a new perspective to their new team. They often suggested how their new and old teams might work together whilst minimising dependencies.

We maintained our own DevOps team and used an application programming interface(API)-centric model to reduce technical dependencies.

This combination meant we minimised how much dependencies slowed down delivery.

3. Change happens at the speed of trust

I needed to make sure my peers, superiors, and teams trusted me, and each other. This wasn't always easy.

We found that the more teams were protected, the more they disconnected from broader DfE. Communication was harder, and misunderstandings more common.

We built trust by celebrating small, tangible successes, and sharing the credit.

I felt we had a responsibility to help DfE continually improve. We worked with the cyber security team to improve the Authority to Operate (AtO) process. This is an annual process where cyber security colleagues visit delivery teams to review and approve services. Together, we developed a new model that focused on principles that delivery teams could use every day.

Where we lacked trust, we created friction and frustration instead of positive change.

One senior stakeholder had a reputation for not "getting" digital. They were rumoured to have called user researchers elsewhere "charlatans". Before a high stakes meeting, a colleague challenged me to speak to the stakeholder using their language.

I took the challenge and talked of the importance of "being able to learn from our mistakes and correct them in weeks not years" instead of "being agile". I talked about "the risk of not knowing how people might react" instead of "user research being important".

Speaking like them meant we could work together closely, and they trusted me more. This helped me clear the path for successful delivery.

4. Change is hard, but so is maintaining delivery

I consistently underestimated the time and energy needed just to maintain delivery.

We faced increased pressures on budgets and headcount, which led to high staff turnover. We also faced commercial, legal and tax challenges. Working through these took time and effort but led to service teams achieving some impressive outcomes.

For example, our Initial Teacher Training Recruitment Services have helped provide more than 1,000 extra initial teacher training candidates. The Teaching Vacancies service is saving schools more money than ever. We've enabled over 200,000 people to start either the Early Careers Framework or National Professional Qualifications.

It's been great to enable this, but it has been at the expense of other changes that would have moved us towards our service line vision faster.

Final thoughts