We All Know It

Constant distractions are the number one enemy of productivity. They come in many forms and shapes: Loud open space offices. A smorgasbord of parallel communication channels (emails, chat messages, meetings, …). Or plainly because you are running too many projects, small and large, in parallel. Distractions and context switches drive down productivity, motivation, and composure; to work effectively, one must eliminate distractions and create focus. What sounds like a platitude is actually quite challenging to resolve in practice. Especially, when your stakeholders (maybe including yourself) thirst for output.

Our team, after being strained by a legacy migration world tour, with operations and new product development running in parallel (arguably the new normal?), decided to try doing „Deep Work“* for an uniterrupted two weeks. We would like to show you what we did, what amazing results we achieved, and what we learned.

_{* as in Cal Newport’s „Deep Work“: concentrating on a cognitively demanding work with zero distractions to produce quality work}

The Original Trick: „FedEx Day“ – Zero Distractions, Do What You Like

In short, we took a well-known concept, the FedEx Day, and put it on steroids. The original concept of the FedEx Day:

A FedEx Day is a 24-hour event in which employees deliver innovation to the company they work for. It is called FedEx Day, because you have to deliver overnight, like the parcel delivery company. A FedEx Day is a fixed time box in which people are not disturbed for regular work. Within this time box, employees have total autonomy over the project they are enthusiastic about. They decide for themselves what they will be working on, who they are going to work with, and how they are going to do it.

(SCRUM.org)

In short: let Engineers work on what they feel enthusiastic about that will benefit the company, and don’t disturb them doing so.

The Interhyp Flavour – Not a Day, But a Whole Sprint

Duration

We thought that 24 hours were not quite long enough to really get stuff done, so we decided to stretch it. To several days. No actually… it was a whole two weeks. 😎

Meetings

Also, we cancelled (almost) all meetings. No jour fixes, no daily stand-ups, no weekly check-ins, no refinement, nada.

Which few meetings we kept: For one, the weekly 1-hour Chapter meeting (at Interhyp, we employ a flavour of the Spotify Model, where Chapters are an association of employees with the same specialisation). For the other, as this was the first time doing a FedEx sprint, we held three alignment meetings. At the start, middle, and end of the FedEx Sprint – to commit to projects, inspect whether we needed to adjust stuff, and distribute knowledge.

This made a total of 5 h of meetings in two weeks, or 6 % of Engineers‘ time. Quite an achievement, compared to what is usually 2 – 4 x the amount (12 – 20 h).

Division of Work and Handling Interruptions

All Engineers committed to one, self-chosen focus topic, which they communicated before kicking off the FedEx Sprint. (This wasn’t ideal, as it created a 1-man knowledge island, see more under „Learnings“).

Interruptions are unavoidable. We absorb them by rotating Ops responsibilities. As we are a part Operations, part Engineering team, interruptions are part of our daily reality (imho: every team always has product operations). To resolve these horrible context switches in our daily work, we always designate one out of our six Engineers to do Ops work (i. e. responding to problems of our internal users, fixing security vulnerabilities, implementing patches). This is how we balance Operations (effect on the short term) and actual Product Development (effect on the long term). During the FedEx Sprint, we rotated that Ops Engineer each day, evenly distributed among our Engineers, so that each Engineer had only a single interrupted day per week.

Getting Commitment to NOT Get Interrupted

Our team behaved totally differently than usually, for two weeks. That is something that requires upfront communication to all outside stakeholders. Most of it we could handle via our rotating Ops Engineer. But it was prime to communicate to all other stakeholders that we would be unavailable for two weeks (for Product Development, mind you – Ops we still had going).

The Result: Amazeballs. One Quarter’s Output in Two Weeks

4 New Microservices, 1 Microservice Go Template, and Product Analytics

We were astounded, too. What would have usually taken us almost a quarter was achieved within merely two weeks. We will (or rather, must, because it’s so much stuff) present only bits and pieces below. We will showcase our products in-depth in separate, subsequent blog posts.

A Golang Microservice Template

Boiler plate code to spawn a Go-based Microservice from scratch with one click (including OpenAPI V3 template code, tests and observability, 15-factor compatible).

Four (4!) Go-Based Microservices

Each Microservice taking over specialised DevOps processes (that were previously built into our Jenkins), like GitOps BitBucket repository configuration or Microservices Scaffolding.

Engineering Workflow CLI

A CLI specifically made to minimise Engineers‘ tool switches (e. g. to BitBucket, Jira or Jenkins) and keep the dev workflow within the command line as much as possible.

Matomo

A fully anonymous, Open Source, on-premise usage statistics software for our internal DevOps tooling, including the Interhyp CLI. (We take data privacy very seriously, also for our employees. Hence, we collect zero data about internal user identification and all IPs are cut off after the first two triplets, no backwards inference is possible).

Really, we were taken aback. All of the above are a major step in reworking our tooling to become CI/CD platform and data centre agnostic, empowering Engineers and making our product development more evidence-based. Admittedly, we couldn’t bring all of the above to the maturity level for production use right away; but for most, not much work was left for the first inspect-and-adapt rollout.

Showcase: Engineering Workflow CLI

We want to highlight one of the above products created during our FedEx Sprint. Why? Because it is a prime example of what an undisturbed, free flow of Engineer creativity can produce in barely a few days‘ time. In a way, it is also somewhat of an homage to the topic at hand: distractions. One of the biggest nuisances in our daily Engineering workflow are tool switches (Go to Bitbucket, to clone the repository; to Jira, to create a Story to commit on; into the command line, to create a feature branch; …). What if an Engineer never had to (context) switch to four different tools, just to set up a feature branch?

Introducing: The Interhyp CLI

„Never leave the CLI again“ is its motto. It enables completing all developer workflow steps within a guided CLI, without having to switch to other tools (Jira, Bitbucket, …). It increases productivity by reducing wait times and context switches. Let’s see a demonstration, left: no Interhyp CLI, right: yes Interhyp CLI.

Features:

• Automatic updates via three update channels: dev, next and stable
• Native support for Windows, MacOS and Linux
• Persistent configuration located at $HOME/.interhyp-cli.yaml
• Secure storage of credentials in Windows Keystore or MacOS Keychain
• Completely anonymous usage data is tracked via Matomo (see above) to gather user data and improve the CLI
• (@Interhyp Engineers: search for „interhyp-cli“ in our Bitbucket to get started)

Learnings

How often in life are you allowed to use the word „amazeballs“. Usually, zero times. But this is one of these rare occassions. The gigantic output that was produced within these two weeks far surpassed our expectations. And we enjoyed the heck out of it. Frankly, I was flabbergasted by the impact we unlocked by creating real focus (as in having absolutely no distractions).

The Benefits We Observed

• Enormous motivation boost for the team
• Learning what wasteful activity meetings can be if not done right (i. e. not clear-intentioned, short, spare)
• The impact of focus on product quality
• The reduction in mistakes, which you would usually need to revise later on
• Lowered stress: knowing you have the time to do the work without any interruptions
• How people (stakeholders and other teams) suddenly respected the value of our time

What We Transferred to Our Daily Working Model

First and foremost: Meetings are Lava. Sure, they are necessary when dividing labour. But often, even experienced people treat them with too little care about duration, required attendees, content, and intent. Each meeting is a context switch, each hour spent one less hour spent on something else. An effect that multiplies with the number of meeting attendees. The FedEx sprint has made us aware of the need to reduce meetings wherever possible. If need be, we try to schedule them on Tuesdays or Thursdays (our „meeting days“, where we already have our cross-squad alignment meetings, refinements et cetera).

Second: focus. A hard lesson to learn. Less is more. The fewer the projects in parallel, the higher the output (though, ensure you always have a baseline of sensible work).

What We Would Do Differently Next Time

Next time, we would do things a little different. First, we would do three, rather than two weeks. This would allow us to finish off the created products nicely, with satisfactory code quality and test coverage. Second, we would not want to repeat going solo another time: each topic should be done in pairs. Otherwise, the good old anti-pattern of the one-man knowledge island will hurt you painfully in the long run (not being able to distribute work or fixing issues during absences).** Third and last, we will make so to repeat it regularly, and make it part of our Engineering routine.

_{** when knowledge islands emerge, we break them up by doing knowledge transfer meetings (i. e. explaining a codebase/service), then pair Engineers with follow-up Stories}