Orientation
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
Engineering
- Andy Hunt - Tech Lead (EL)
- Ben Corlett - Site Reliability Engineer (EL, contractor)
- Jack Joy - Site Reliability Engineer (EL, contractor)
- Jamie Van Dyke - Site Reliability Engineer (contractor)
- Jani Kraner - Front End Developer (CL)
- Malcolm Saunders - Site Reliability Engineer (EL, contractor)
- Nimalan Kirubakaran - Developer (EL)
- Panos Xynos - Site Reliability Engineer (EL, contractor)
- Robert Scott - Site Reliability Engineer (EL)
- Tom Whitwell - Site Reliability Engineer (EL)
Product Management
- Lisa Scott - Senior Product Manager (CL)
Programme Management
- Chris Wells - Programme Manager
Technical Architecture
- Paul Dougan - Technical Architect (CL)
Product
The following blog posts and videos give an overview of why we’re here and what we’ve been doing so far:
- A PaaS for Government - Anna at Velocity Europe (video)
- Building a platform to host digital services - Anna & Carl on the GDS blog
- Looking at open source PaaS technologies - Anna on the GDS Technology blog
- Choosing Cloud Foundry - Anna on the GaaP blog
Repos
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.
Accounts
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.
Events
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 |
|---|
| Resource(s) |
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.