Engineering Principles at Workleap

At Workleap, we are building a family of software products that work together to shape the employee experience. As we scaled, aiming to add more products to our portfolio, we came to realize that our org structure was becoming a blocker to reach that goal. That’s why, about a year ago, we underwent an organizational transformation, which would take us from a product structure to a functional one.

Since engineering teams for each product were previously mostly isolated from each other, engineering practices, tech stack and software architecture evolved differently over time. We felt it was necessary to unite our engineering practices if we were to really reap the benefits of this new structure.

Among the first things we did towards that goal of a unified engineering was to define our principles.

What are principles?

For us, an engineering principle is a rule that needs to be kept in mind when making an engineering decision. I say rule because we chose to write our principles in their purest form, to avoid any ambiguity. Like every rule, they are meant to be bent. We expect that in some context, some of those principles won’t apply, and even that some might conflict with one another. We trust teams to use their judgment when this happens. Our goal, through those principles, is to provide guidance and empower them to make better aligned decisions, in complete autonomy.

How did we come up with those principles?

We chose principles that were most relevant to our context. For instance, we are set to build a portfolio of complementary products, in that sense, interoperability is a very important concept in our context, but it might not be in yours. We also aligned our principles with our core beliefs, like the importance of high-trust and aligned autonomy for a software company like ours, and the critical role engineering plays in the user experience of our products.

Workleap’s Engineering Principles

1. Build for interoperability

We enable an ecosystem of complementary products by slicing our features in smaller independent blocks and making those blocks available to other products.

2. Embrace modular design

We deliver more value by defining clear domain boundaries. Those boundaries enable our product teams to work in parallel and makes the maintenance of our products easier.

Don’t over design, be coherent with the problem complexity. Domain boundaries should only be defined when a product has more than one bounded context.

3. Promote reusable solutions

We focus on our core business and create a better cohesion between our products by reusing existing solutions (internal or external).

Look for generalization opportunities, design extension points in code that can be used by other products, think about reusability for classes, components, services, and modules on all level.

4. Expect failure

We prepare for the worst by knowing that even with the best intentions, failure will eventually happen.

Make sure critical paths have redundancy, anticipate problems, have mitigation solutions ready and handle failure gracefully.

5. Involve security from the start

We make our products more secure by integrating security concerns from the ground up. Security is a race that can only be won if we start early.

Design with security in mind and test for security from the beginning.

6. UX is full stack

We care about UI concerns at every level because this is how our users will experience our products.

A great UX involves good design choices but also good performance, uptime and stability.

7. Design for scalability

We design our products to scale horizontally because increasing computing performance is limited.

It’s easier to design for scalability upfront, think about how the data can be sharded, slice the system in smaller and more resource-efficient parts that can be easily distributed.

8. Minimize lead time to production

We build smaller and independent increments to continually deliver value to our customers and quickly fix bugs in production.

Optimize branching strategy, build small and independent increments, automate all the processes from code to production.

9. Build it, ship it, run it, watch it

We hold teams accountable for what they shipped for as long as it remains in production.

Our teams are autonomous and can take their own decisions according to our principles as long as they own up if a problem occurs with their work.

Does any principle resonate with you? What are your organization’s engineering principles? Let us know in the comments.

Also, take a look at our open positions. Workleap is always on the lookout for new team players, and we might just have the right opportunity for you!