Introducing Build.Better Days

Trainline Team
Trainline’s Blog
Published in
5 min readJun 16, 2017

We’ve been growing at an incredible rate here at Trainline. While it’s been amazing to see the constant stream of fresh, enthusiastic faces, it’s really put our engineering practices — and culture — through its paces.

However, complete autonomy that is easy to manage in small, nimble teams becomes unmanageable across hundreds of hard-working, creative engineers.

Culture first

Once you get past a certain organisational size (normally 50–150) — you really start to feel these “growing pains”, so it’s important to build a strong culture.

Notice the key word there — “build”.

It’s easy to propose a culture, socialising how you want people to “feel free” and “innovate”. But, when it comes down to sacrificing time, money, energy or “all of the above” to make it work — it starts to lose the fight and becomes nothing but a “good idea”.

Good culture is hard. Like anything worth having — it takes real commitment, energy and enthusiasm to make it work.

However, the payoff is worth it — you end up with an army of incredible people, who become far more than the sum of their parts. The organisation takes on a life of its own, life (and business) is good.

Introducing “Build.Better Days”

“Build.Better Days” (or BBD) are one of a series of initiatives that we’ve deployed to help us cultivate a great culture here at the big @TrainlineTeam.

Simply, these are a fortnightly “mini, internal hackathon”. They are a key component of — and our commitment to — “aligned autonomy”.

“Aligned autonomy”?

If there was a bar where great engineering companies hang out — Spotify is certainly one Trainline would like to grab a beer with. We’ve been inspired by much of their work — especially the principle of “aligned autonomy”.

In a nutshell — it could be described as “focused freedom”.

It’s obvious that complete freedom (“yes, trains — BUT — we could build a robot to train my cat army because YOLO”) is damaging to a business/product roadmap — but less known is that it’s equally damaging psychologically. Often, those that can really do anything end up feeling lost and do nothing.

“Aligned autonomy” is about putting a few constraints and a dash of vision to the freedom to help give people a sense of direction.

Let’s get down to how Build.Better Days work.

Freedom first

First and foremost — you’ve got to give the freedom. We’ve got a company-wide, fortnightly meeting in the calendar on Friday that says “Build.Better Day”. That means:

  • Engineers have the time/space to get away from “day to day” development and focus.
  • Engineering teams may not be available or at 100% capacity.
  • There’s going to be a lot of hackers in our “collaboration space” (an open, flexible area of our office).
  • There’s going some stuff to go “oh that’s cool” at by the end of the day.

BBD is about giving people the time and space to innovate, while surrounding them with people with the talent to get it done.

Everyone has a voice

On our internal Wiki — there’s a button that everyone has access to. Clicking this button will open a JIRA “issue collector” that take whatever they put and place it into our BBD backlog for triage.

Everyone can raise ideas, from any team, no questions asked.

Triage of BBD backlog

Every week all of those that have items “to triage” in the BBD backlog get together with a few of the senior/principal engineers to review.

The goal of this session is to really “groom” the items in triage to help make the actual day productive — so we help each other:

  • Build a great user story around the idea.
  • Help with scoping to ensure it’s going to deliver something at the end of the day.
  • Make sure we’re “aligned” — proposed technologies are core to our stack, contribute to our company vision etc.
  • We’re not building robot drill instructors to train cat armies.

We’ll also review items that are “in progress” and clarify “what’s next” to help them move closer to completion.

Pre-day preparation

With a relatively large number of hackers descending on a single space — it’s important to have a basic pre-flight checklist to ensure things are in order:

  • Food requirements (did I mention we order food?)
  • Work space is free, no clashes of meetings.
  • Do we have enough power extension cables, display adapters etc?
  • Usual consumables — whiteboards, pens, post-its, etc.

On the day

We keep the format of the day loose:

  • 09:30 — People gather in the workspace, caffeinate and converse.
  • 10:00 — Recap of “the rules” and pitches from idea creators.
  • 10:30 — Hacking — teams self-organise.
  • 13:00 — Lunch.
  • 13:30 — More hacking!
  • 16:30 — “Show and tell” to the rest of the business.
  • 17:00 — Laptops closed, beers open.

The “rules”

We try very, very hard to keep this list short.

  1. Only work on “triaged” items — this ensures that people are only picking up things that are well-defined and “actionable”. A whole day is short than it sounds!
  2. Every team does a “show and tell” — it’s important that we demonstrate progress to each other. We might get working code, or “we tried, couldn’t get it to work, but learned X for next time”. Both are “success”.
  3. Stay in the BBD space — this is to reduce disruptions for all concerned. It’s easy for non-participants to ask “what are you working on”. Repeated 2–3 times and you’ve lost over an hour of focused development time.
  4. Have fun — it’s still a hackathon. 😊 Progress over stress.

Outcomes

We’ve had 5 BBD’s so far, and we’ve seen a wide range of awesome output — including:

  • Incredible development/improvement of our build/deployment pipelines.
  • Slack bots to help people find their way around the office.
  • Libraries to help engineers “do the right thing” easily — e.g. the “circuit breaker” pattern.
  • Clean-up of legacy code/libraries to both boost performance of our applications and maintain sanity of engineers.
  • Better integration of our deployment pipelines to APM tools such as New Relic.

For me personally, I think the greatest outcome so far is:

People “get it”. They are getting involved and improving things for each other.

To close…

I’m really enjoying seeing Build.Better Days grow and evolve.

It’s (unfortunately) rare to see real commitment to initiatives such as these in our industry (even the famous “20% time” from Google is struggling). BBD has full support from the leadership team, and we work hard to keep the “rules” and bureaucracy minimal.

So, will you take the plunge and give your team the time, space and energy to Build.Better?

Happy hacking!

Links

--

--