At Trainline Europe it was decided early on to trust employees. Once you’re in, you’re in entirely. We are not going to give you gradual access to the code, partial access to some systems, editing rights on a case-to-case basis. As much as possible, everyone can use anything, right from the start.
This has many concrete advantages. It lets people be creative: when you don’t have to ask for permission, many creative experimentations and solutions are possible. It reduces friction and paperwork: when the administrator of a system leaves for vacation, work can still be done without waiting for their return to perform the required tasks. It gives greater responsibility to people: when you are given the rights to a system, you tend to be responsible with it.
Let me give you some examples.
C’mon newcomer. Follow me.
On your first day at Trainline Europe, we’ll spend a few hours giving you access to every system.
Are you a Customer WOW Engineer, supporting our customers? You get access to OTRS, our tool for answering customer support emails, of course. But also to GitLab, the tool used by developers to write and host the code for all our software. You’ll be able to see our issues boards and comment on our code or mock-ups. We’ll even train you for this. You can use this knowledge to better respond (“Yes, we have an open issue about unsellable tickets to Eu-La-Mouillette right now”), and report problems to developers.
Are you a software developer? You’ll get access to GitLab, but also to OTRS, our tool for answering customer support emails. You can use it to handle job applications, but also to answer real customer questions. We’ll even train you for this. Seeing real issues first-hand that customer face will help you to have a better sense of what to do to improve our product, or the tools used by WOW Engineers. You’ll also get rights to deploy software into production, from day one. What better way to on-board new developers than to make them push their own improvements into production?
You’ll also get access to our blog. You can write anything, and you have access to the “Publish” button. Want to talk about something great around you? Just sign-in and start writing a blog post. Of course you should probably get it proof-read by someone else, and ask for the person managing the editorial timeline for the right moment to publish a new article. But you won’t get stuck because “Sorry, the person with publishing rights is in Antarctica for three weeks”.
We use Slack for internal discussions. Many things happen there: work, notifications, random chatter… feel like an emoji is missing? Add it yourself right away. This is how the conventions for deploying our software emerged organically, using one custom emoji per project. Want to coordinate the work on a new feature? Just create a new public channel. Nobody will restrict this – and if the channel remains empty, there is still the possibility to archive it later.
Something is missing on our servers? You need a new package, or changing some settings? The Ansible recipes for configuring our servers are accessible – so that everyone can read, understand and improve the recipes.
Speaking for myself
A few years ago, we migrated from GitHub (a source-control website) to GitLab, a free alternative. Although GitLab is now a pillar of our development process, the beginnings were rough, with some features not working as well as we’d hoped.
After complaining for a few hours about this, I started editing GitLab source code and improving the major pain points. Once the changes were ready, I asked our CTO if he could deploy them. He answered by giving me administrative access to the machine running GitLab. Wow, that was more than I asked for.
I deployed the code, it worked well, solved our issues, and even got merged in the official project. Yay! With these rights, I started to feel responsible for it. I started upgrading GitLab regularly, following progress of new features, and making other improvements. I became the de-facto GitLab maintainer – just because someone, at some point, gave me full rights.
This wasn’t planned, but giving the rights was surely a productivity boost for us. And it worked the same way for many other people working on different topics: one day, someone gave them full rights.
Rewriting our software pipeline
Earlier this year we wrote about how we transitioned from one software pipeline to a new one, based on GitLab. This gave us a significant productivity boost: we run tests quicker and earlier than before, changes get accepted faster, and idea-to-production cycle is reduced.
This project started partly because transitioning a project to this new improved system didn’t require any permissions. Our old system wasn’t configured to give access to everyone – which means few people knew how to configure it, or could make changes. The new one can be used safely by anyone, without requiring specific permissions – and that’s how it started.
This doesn’t mean we compromise anything on security; quite the contrary. Access to production servers are restricted to a limited number of people. We use configuration templates, to keep away production credentials from the public recipes that configure our servers. We also peer-review all changes to new code or configuration. And as we use versioned configuration systems, we always know who did what.
But apart from this, once you’re in, we trust you. To not only to do the right things, but to use these rights to do amazing things.
This is why when we set up new software, we usually give admin rights to as many people as possible.
- It allows people to solve real organization issues in a spontaneous way.
- It removes single-points-of-failure, so that we can work even when the system administrator is not there.
- It gives responsibility to the people, which they then may use for amazing things that weren’t even planned.
Give them access, and you’ll see what people can really do.