05.15.19
Peter Mounce is a build and release engineer at Improbable. He likes making computers do the boring repetitive stuff so people don’t have to.
At Improbable, we aim to continuously improve. Though this happens to all areas of the business (finance, people-operations, talent, marketing; really, honest), I want to focus on how we apply that to our engineering practice and its surroundings.
Broadly speaking, our engineering velocity (EV) team has two closely linked objectives:
That's great bizbabble, Pete, but what do you actually do?
At parties, when I'm asked what I do, I answer: “I'm a cross between a software plumber, an engineering lubricant and a guidance counsellor. I ask questions a lot.”
To be clear, in EV we're trying to improve the relationship that our engineers have with their developer experience here at Improbable. We want them to be happy here for a long time. Like all relationships, it tends to not fall apart because of some big thing - you wouldn't have gotten together if there was a big obvious problem. Relationships fail because of an accumulation of frustrations and disappointments that remain unaddressed. Our aim is to head that stuff off before it becomes serious.
To deal with this, we have a set of written principles within EV; here's the core of them:
Learn how to enable better engineering practices in games development. Also, perhaps most importantly,
Always be curious.
On that last one, we're learning all the time. While as engineers we can be to some extent our own customers, we definitely don't know everything about everything. So, we need to be learning all the time.
Well, we think of it as a pipeline. You know, like e-commerce funnels, HTTP request processing pipelines, or continuous delivery pipelines. Here's how I imagine it:
That’s the map of where we might apply ourselves. We want to apply effort as far to the entry-point of the pipeline (diagram above) as possible since success there probably magnifies earlier and over time. For example, let’s say we improve how an engineer on-boards through a consistent workflow for making a change, or a common place to find documentation or by automating workstation setup. Well, that engineer has now “levelled up” earlier in their career and we get compound interest with a higher base for the duration they’re at Improbable.
Software is delivered by a set of people, with processes, sets of tools and sets of infrastructure. We're instrumenting these things - that is, adding telemetry to them - so we can do continuous data-driven improvement. We try to make the pipelines publish metrics, then brainstorm (with our customers) what we think might reduce friction in the pipeline, then we do the first bit, see if the metrics improve and by how much, and then iterate. Then we train our customers to self-service this optimisation. No magic there, really.
Improbable has concentrated several highly experienced engineers into the EV team; as such, we are able to apply that experience consistently and coherently. It helps that we force ourselves to be our own customer - no cheating.
We regularly have engineers from other teams rotate through the EV team so we're able to act as an ad-hoc academy. It's synergistic - we're learning and interacting with our internal customers hands-on, and they're learning about our tooling, approach, and opportunities to apply those things “back home” in their original team.
One thing we started doing is easing how engineers onboard into being on-call by exposing them to operations tooling earlier. Our continuous integration ships structured build-logs, metrics and traces to the same stack as our production workloads do, so now the barrier to onboarding into on-call is reduced because engineers are already day-to-day familiar with that set of tools and techniques. More about that in this post.
What are “things”? Nothing is really off the table. Here are some examples of “things”, big and small:
We hope you've gained something from learning how we keep our engineering teams happy and confidently productive.
That said, if you have any silver bullets for how to reliably have people learn from your mistakes ahead of learning from their own, we'd love to hear from you. We're learning all the time too.