The Pleo Blog

Get started
Engineering Efficiency Week - June 2020

Building software comes with many challenges. 

One of them is making sure to strike a balance between the excitement of building exciting new features and taking care of TTT: Tedious Technical Tasks.

If we only focus on those new features, we start accumulating cruft in our code. Cruft is designer-speak for stuff that’s left over, useless, or getting in the way. It’s a problem that’s often referred to as Technical Debt

Cruft makes it harder to build simple things, plus it can also bring instability to a system. We want to invest energy into making it easier and smoother to build new features. These are investments that pay off big in the long term.

So, we get efficient 

In order to simplify the delicate balancing act between features and those maintenance tasks, we've created Engineering Efficiency Weeks (EEW) at Pleo, where every engineer focuses their energy on building things to help developers be more efficient in the future.

In June the team gathered for Engineering Efficiency Week, where the main focus was to address the growing size of one of our micro-services.

A micro-service is an application within Pleo that performs a specific task. For example, expense management or card transaction processing.

A micro-service works best when focusing on a niche responsibility, as opposed to being in charge of doing everything.

This isn’t always easy to achieve. A common tendency is to "just add one more small thing" to a service, which makes it bigger and less manageable over time. 

For us, this has led to one of our micro-services growing into a bit of a jack-of-all-trades, handling many different responsibilities around many different business flows. It also requires multiple teams to share ownership – not ideal.

As part of this EEW, a team of three engineers picked up the task of moving one of these responsibilities (processing card transactions) into a brand new micro-service.

This requires a lot of careful planning and cross-team expertise. It’s not something a single engineer should take on, but it is perfect EEW material.

We've also been able to make improvements to our core infrastructure: a team of 4 developers, together with the site-reliability team, worked on migrating services from our self-managed Kubernetes cluster to EKS (Amazon's managed Kubernetes service). This greatly eases cluster management, and improves the security and availability of our services. Collaboration for this project was key: our site-reliability engineers have the know-how around Kubernetes and Terraform, while the developers understand the services, and were thus able to quickly assess that each service migration went successfully.

But it's not only our back-end services and infrastructure that we got to work on. We were also busy improving the user interface of our app.

We did a long-overdue codebase cleanup removing thousands of lines of unused code, making our app run smoother and faster. 

A few months back we started a project of building a design system - a set of tools that will help us keep Pleo experiences coherent and accessible. This week we finally got to try out this new system! Bonus points to you if you noticed the typography and whitespace across our web app as more consistent and harmonious. 🤓

We also got a chance to implement some big changes to how the core of our web experience works - how we download data from the servers and display it on the screen. We see this as an efficiency booster in the future, making it much easier to add new features and maintain a top quality user experience as our app grows.

What it means for you (and us)

The impact on how Pleo technically works is big. 

A separate, clean micro-service is much easier to build upon or to scale, if it becomes a bottleneck. It also enables us to define tighter security rules, and monitor that the micro-service is functioning as it should.

For Pleo users, this means even more stable operation, stronger security, and quicker feature turnaround.

There are other internal benefits to this approach.

One of them is that our product teams are centred around specific product areas. The teams include designers, product managers and engineers. These vertical structures are great to ensure autonomy and high velocity when shipping features. 

However, it means that a back-end engineer in a certain team won't have many opportunities to interact with a back-end engineer in another team. Engineering Efficiency Weeks allows all engineers of a given speciality to work together on a project. This helps with knowledge-sharing, as they'll figure out techniques and best practices together, while working on something concrete. 

It also helps create links between engineers and ensure we have the opportunity to work with different people. Some people even try totally different roles depending on their focus – a lot of fun and a big chance to develop their skills.

What the future holds

We're already seeing great results from reworking the length and frequency of our EEWs.

The enhancement projects we've been able to undertake have a wider scope and are more impactful. Synchronizing the timing of our efficiency sprints with quarters has also simplified how designers and product managers can manage their commitments and roadmap.

We’re already counting down the days to the next EEW – thanks for taking the time to read about this one!

Pleo blog banner
Pleo Engineering Team

Pleo Engineering Team

Building stuff & shipping code