This post is part of a series. See the introduction here: New normal, new teams, new goals
We’re restructuring the teams in our product group to reflect the new normal for GOV.UK. This post explains why we’re making changes, what the new teams will do and who will lead them.
Why we’re changing
GOV.UK’s product group is the team of in-house developers, designers, researchers, analysts and people in related product and delivery roles who work together to maintain and improve GOV.UK’s features and functionality.
While we try to keep changes to a minimum and have stable teams working together for as long as possible, we occasionally need to reconfigure the people in our product group to make sure we’re focusing on the right things and to mitigate the effects of Conway’s Law.
For example we created a number of teams last year to focus on addressing product gaps and building tools needed for organisations to join GOV.UK; and in recent months we set up a team focused on getting GOV.UK ready to meet users’ needs during and after the election.
The new normal for GOV.UK means we need to iterate the team structure again.
Optimising for support
Having completed transition and readied the site for the election, the balance of what the GOV.UK product team needs to do has shifted from building a new, single government domain to running and improving the one we’ve built. So we’re optimising our team structure to do that.
In much the same way as we recently reconfigured our content group into 4 theme teams covering the totality of GOV.UK’s content, we’re reconfiguring our product group into teams that divide up ownership of all GOV.UK’s features and software.
By the end of June we’ll have 3 product teams. Each will own a number of applications or products from end-to-end, meaning they’re better able to maintain and improve the applications and formats they’re responsible for. At the size we are now, these will be very busy teams, each covering a large volume of needs, functionality and code.
They are:
- a team which owns and iterates the core publishing tools and formats
- a team which owns and iterates custom and complex formats
- a team which owns and iterates search, navigation and taxonomies
To support this work, a small team of 3 developers and our technical architect will continue to reform the platform architecture. This is vital to reduce the complexity and increase the flexibility of our technology, making it simpler and faster to improve GOV.UK in future. (We know we need to do a better job of explaining this work, and you can expect a blog post on that soon).
Details of the 3 product teams
Core publishing tools and formats
This team will be responsible for supporting the majority of page formats and publishing tools on GOV.UK, and improving GOV.UK’s ability to measure its performance and record user needs. This will help the content community put user needs - and data about how well those needs are being met - at the heart of content design decisions.
The product manager for this team will be Lisa Scott.
Custom publishing tools and formats
This team will be responsible for maintaining and improving the more custom and complex content formats and publishing tools on GOV.UK, eg smart answers, organisation pages and manuals. This includes improving how GOV.UK works as a front door to services and information on other domains, eg service.gov.uk and local government services. The team will lead on making complex, multiple choice and high-volume information simple for users to navigate and understand.
The product manager for this team will be Mark Sheldon.
Search, navigation and taxonomies
This expanded team is in place already, and is responsible for maintaining and improving the user experience of finding content on GOV.UK, and the taxonomies, tagging interfaces and curation tools which underpin them. Its goal is to make it easy for users to find the things they need, and to see how government is structured, now that everything is in one place.
The product manager for this team is Ben Andrews.
Balancing support and improvement
Each of these teams will be balancing a high volume of demand and a number of big problems to solve. They will prioritise the work in this order:
- Running the GOV.UK platform - keeping the site available, accurate, fast, safe and on supported technology, and resolving users’ urgent and important problems (the “must do” requests from end users and government colleagues).
- Improving GOV.UK - working proactively on the high impact changes our users need and which will make GOV.UK work better for everyone.
- Resolving users’ less urgent and less important problems (the queue of “should do” and “could do” requests).
We can’t do everything that’s asked of us all at once, so we’ll continue to differentiate between the things we must work on quickly, and those that can wait. We can then work proactively on the improvements that will deliver the most value to the most users. The final post in this series sets out what our goals are now, and why making time to work on them matters.
We’re also working on definitions to help us prioritise more consistently and decisively, so we can give clear, honest assessments of where requests fall in the overall priority list.
If working like this appeals to you, take a look at Working for GDS – we’re usually in search of talented people to come and join the team.
Lindsey Keighley is the Programme Delivery Manager on GOV.UK
