Skip to main content

This is for internal use by the PaaS team. Public-facing documentation is located at


Some key information to help new starters to find their way.

Team members

We are a multidisciplinary team responsible for the developement and maintenance of GOV.UK PaaS.

  • EL - Engineering Lead Support responsiblities
  • CL - Comms Lead Support responsibilities

Delivery Management

  • Emma Pearce - Delivery Manager (CL)
  • Kam Nijjar - Associate Delivery Manager (CL)


  • Andy Hunt - Tech Lead (EL)
  • Ben Corlett - Site Reliability Engineer (contractor)
  • Cat Garcia - Site Reliability Engineer (EL)
  • Jack Joy - Site Reliability Engineer (contractor)
  • Jani Kraner - Front End Developer (CL)
  • Lee Porte - Lead Site Reliability Engineer
  • Malcolm Saunders - Site Reliability Engineer (contractor)
  • Nimalan Kirubakaran - Developer
  • Panos Xynos - Site Reliability Engineer (contractor)
  • Robert Scott - Site Reliability Engineer (EL)
  • Sebastian Schmieschek - Tech Lead (EL)
  • Tom Whitwell - Site Reliability Engineer (EL)
  • Will Pearson - Site Reliability Engineer (EL)

Product Management

  • Lisa Scott - Senior Product Manager (CL)

Technical Architecture

  • Paul Dougan - Technical Architect (CL)

Technical Writing

  • Claire McNally - Technical Writer


The following blog posts and videos give an overview of why we’re here and what we’ve been doing so far:


These are the key repos that we use. There will be many others, which these depend on, but this list should be enough to get you started.


You will need accounts to a number of tools/services that we use such as GitHub and Pivotal Tracker. Government Digital Service staff can see a full list and their respective URLs in the following spreadsheet:

Buddys for new engineers

If you’re a new developer or SRE you’ll be paired with a buddy for the first few days. They’ll help you get set up, explain the GOV.UK PaaS product in more detail and help you get started implementing your first stories.


These are key events that happen each fortnightly sprint. You’ll get calendar invites that detail the actual times and locations.

  • Stand-up is at 10:00 every morning. We’ll talk briefly about progress, blockers, and pair rotation. Please be on time and keep it succinct. There is time for more detailed conversations immediately afterwards.
  • Planning is at the beginning of a sprint. Most of the stories will already be prioritised in the backlog and we don’t do sizing. We’ll talk about what’s coming up and anything that we’ve missed.
  • Retrospective is at the end of a sprint. It’s an opportunity to talk about what went well and what we can improve as a team. We use this trello board to suggest things to talk about and record actions.
  • Knowledge share is at the end of a sprint. It is to share what we’ve learned during the sprint, including technical detail. During the sprint, try to record things you want to hear more about or talk about in this trello board and one or two people present each, preferably with a demo.

Late for Standup

Scary. Turning up late for the standup? How could such a thing happen.

Missing standup, or being late, means you will miss out on updates on:

  • Team News (who is where today)
  • Product News (any significant developments worth knowing about)
  • Context on Work in Progress

The last one is especially important, as the standup is a valuable way to crowdsource ideas on problems that people may be having with a story, and if you are not there, you can’t help.

Learning our technologies

We use a number of technologies and you may find it easier to learn about each one on its own, rather than in our environment, where they all interact with each other.

Here are some recommended exercises and documentation that will help you become familiar with each one.

What Get started Learn the concepts
Cloud Foundry, as a user Our getting started guide Considerations for application developers
Concourse, the CI server we use for deployment Concourse tutorials Concepts
BOSH. It deploys Cloud Foundry and other things. A guide to using BOSH What problems does BOSH solve?
Cloud Foundry, for those managing it Cloud Foundry presentation, written by the team, an older presentation from before the move to Diego archecture
Terraform The terraform intro The intro also covers key concepts.

Communicating with Hand Signals

We use hand signals at our meetings to help make them more productive and accessible for every person on the team. You can find out more about how this works in practice by reading our blog post.

Inclusive language

Diversity is important to us, as is inclusivity. To help create such an atmosphere we avoid the use of certain words.

Avoid gender-specific words

Gender-specific words like these can act to exclude other groups of people:

  • guys
  • gents
  • chap
  • man
  • he
  • girls

There is a great write up on the word guys by Julia Evans that helps explain why it isn’t quite gender neutral.

Words such as everyone, folks or team can be more inclusive. The first rule of devops club by Bridget Kromhout is a great reference.

Avoid assuming expertise

Some words assume expertise and can belittle others contributions:

  • just
  • obviously
  • trivial

For example, using the word obviously can be a form of Hindsight Bias: some people reading this may know it, but others may not. Not so obvious right?

If this language is used widely it can stop people contributing to discussions. It can make asking questions scary. This is bad.

Another problem with these set of words is that it can lead to underestimation of effort by the team when effort is played down.

Avoid treating people as resources

Anti People

Classic Management 1.0 speak, reducing people to Resources. We should not be doing this.

Our thoughts shape our language, but our language also shapes our thoughts. The zeroth step in creating humane workplaces is to start talking about the people not resources.

Esther Derby