emma-sleep--careers

Engineering Principles

Tue, 06 May 2025 14:05:32 GMT

Last update 06/05/2025

A shared definition of what great engineering looks like.

These are the operating principles we believe underpin a high-performing software engineering organization. A shared definition of what great looks like that helps us aim higher, stay aligned, and drive real impact through technical excellence at Emma. Each principle has a set of associated practices that describe its implementation. Those practices are maintained and evolved by our community of Staff+ Software Engineers.

We engineer with people in mind.

We embrace software engineering as a team sport and socio-technological endeavour—where success depends as much on how we work together as on the systems we build. Delivering great software goes beyond writing code; it requires collaboration, communication, and shared purpose. We believe that empowered, cross-functional teams—equipped with the context, agency, and resources they need—are the key to creating value and driving innovation.

We ship with purpose and for impact.

We are empowered engineers, that act with agency and care deeply about the problems we solve and the impact we bring, not just the code we write. We strive to understand our users, our business, and our impact—so we can make smart decisions, challenge assumptions, and prioritize what truly matters. We take ownership from idea to outcome, combining product sense, data, and empathy to deliver real value.

We choose progress over perfection.

Our goal is continuous improvement. Success comes from habits that make us the best at learning, adapting, and delivering value—not chasing unattainable ideals. We measure the impact of our software, embrace mistakes as opportunities, and strive for excellence through iteration. By exploring trade-offs and making pragmatic decisions, we balance quality with momentum and maximize our ability to learn.

We build excellence in.

We provide opinionated, reusable foundations that help teams stay aligned while preserving autonomy. By making secure, cost efficient, high-quality, and compliant services the easiest path, we enable developers to move fast with confidence. Through everything as code, stellar documentation, and developer-centric platforms, we embed excellence into the way we scale.

We release small, we release often.

We act with urgency and embrace small, frequent pull requests and well-tested deployments to deliver value continuously, reduce risk, and accelerate feedback. Thin, vertical slices of functionality are shipped regularly, validated in production, and refined based on real-world insights.

We build it, we own it.

We take full responsibility for the software and data we create—designing, maintaining, observing, and firefighting as needed. Ownership extends across the entire tech stack, and we support each other in making it successful. True autonomy, mastery, and purpose come from being accountable end-to-end. (Credit to Alex Ewelöf for coining the term).

We treat data and interfaces as first-class citizens.

Data, contracts, and UIs are not afterthoughts—they are integral to how we design, build, and evolve software. Defined early and thoughtfully, they drive quality, reduce complexity, align teams, and enable loosely coupled architectures. By investing in clear, stable interfaces, we accelerate delivery, reduce friction, and shorten time to value.

Engineering Principles

By: Carl-Johan Backman

Amazon Web Services EFS to S3 migration for a streamlined architecture and enhanced performance

Mon, 29 Apr 2024 15:34:44 GMT

Last update 29/04/2024

In this article, we share the steps that we took to migrate our storage from Elastic File System to S3 on AWS.

Figure 1. AWS EFS Full architecture diagram

As outlined in our previous article discussing the architecture of Emma Online Store, we utilize AWS (Amazon Web Services) Elastic File System (EFS) as storage to deliver statically generated sites (HTML, CSS and JS files) for all countries. This is accomplished using Nginx as a proxy where requests first reach Cloudflare which forwards them to Nginx and Nginx reads the necessary files from the storage and serves them back to Cloudflare which serves it back to the user, as illustrated in the diagram below. The full article can be found here.

Challenges

Although the architecture that we had in place functioned effectively, we identified several issues that hindered our progress and limited our ability to expand the range of features. This complexity posed a potential challenge to the developer experience. In addition to the impact on the developer experience, we observed a decline in performance during the hit of the first request after each generation. Despite utilising Cloudflare to cache our requests, we consistently cleared the cache following each website generation. The performance dip was attributed to AWS EFS relying on a network file system beneath the surface, resulting in I/O operations when reading a file from a mounted volume in a running Kubernetes pod.

There was also the cost factor to consider since the implemented architecture was becoming more expensive every month since we kept all the generated versions of the site for all countries since the day when the architecture was implemented. There were no deletion policies in place and that resulted in increased storage costs. Due to missing deletion policies, there were a lot of cases where we would serve outdated versions of a specific page to customers that had that page cached in their browser.

Summarising, we faced the following challenges:

Complexity in the architecture that’s hindering progress and developer experience
Performance decline after website generation
Performance issues with AWS EFS
Costs increasing month after month
Outdated content being served to the user

Solution

Considering the previously outlined issues and after conducting research, we opted to transition from AWS EFS to AWS S3. In this transition, our objective was to eliminate AWS EFS and Nginx as a proxy. Instead of transferring the statically generated files to AWS EFS during generation, we utilized the AWS SDK to push the files to AWS S3, where each country has its dedicated bucket.

The AWS S3 bucket is set up for static website hosting with object ownership, providing an exposed host URL. It is configured as private, with inline policy rules granting Cloudflare the necessary permissions to call the exposed host URL. The configuration of bucket policy allows the list of IPs from Cloudflare to access the bucket and the list of IPs can be found here.

Figure 2. S3 bucket policy for Cloudflar

The bucket has also CORS policy set to allow GET, POST and PUT requests. The policy configuration and CORS is like this:

Figure 3. S3 bucket CORS policy

On the Cloudflare side, we configured a CNAME (Canonical Name) record for each domain, directing requests to the exposed host URL of the AWS S3 bucket host that follows this pattern BUCKET_NAMET.s3-website.eu-central-1.amazonaws.com via proxy. This move to AWS S3 reduced one step in the request sequence diagram by removing Nginx, as mentioned, and at the same time, it reduced the risk of a downtime for our online stores since Cloudflare and AWS S3 are taking care of serving the sites instead of our own infrastructure.

Our infrastructure makes sure to update the site after every generation but that will not cause the site to go down at any time. Check out the simplified sequence diagram.

Figure 4. Serve static page sequence diagram

The architecture diagram has changed as well, and the full diagram is shown below.

Figure 5. Updated full architecture diagram

This architectural update posed a challenge in ensuring uninterrupted site availability during the implementation and go-live phases. To address this, we adopted an approach of delivering incremental updates to the production environment to facilitate a smooth transition.

The migration involved several sequential steps, each of which was deployed to production upon completion:

Preparation of the infrastructure, involving the automated creation of AWS S3 buckets with their corresponding policies for all countries.
Implementation of the upload to AWS S3 in conjunction with the existing setup, preparing the site for the impending architecture switch.
Readying the provisioning of Cloudflare CNAME creation through automation for every domain.
Gradual rollout of the updated architecture, serving the site from AWS S3 one country at a time.
Cleanup of obsolete legacy code for both the application and infrastructure.

Improvements

From this move, as mentioned, there were several benefits and we are going to list them below with some figures on how much we improved the performance and reduced the costs, amongst other things.

We got a 20% increase in cached requests by having 2 layers of caching, one cache in S3 bucket and one in Cloudflare. The data is for the month of July 2023.

Figure 6. Cached requests per storage

Table 1. Number of requests that we handled in July 2023

The pipeline execution time was reduced by 40% since we built our docker images in a more optimised way and deployment provisioning takes less time since it spins up less resources.
The page load time performance was improvement by 6% due to 2 layers of cache
The storage costs were reduced by 85% across all our AWS accounts. The graph below shows the trajectory of the costs with AWS EFS that kept increasing and how that changed with the move to AWS S3 where the fluctuation is not that big, and it stays in the same range. It is too soon to see a clear stabilization. We see the spikes in November 2023 and January 2024 due to the amount of traffic that we get in these two months.

Figure 7. AWS storage cost trajectory

As we dive deeper into the architecture of Emma to shed more light on how our systems and services operate, we invite you to join us on this enlightening journey, gaining valuable insights into the intricate workings of Emma's architecture and the innovative solutions that power our innovative systems and services to improve sleep.

Upgrading Our Frontend: Navigating the migration from Nuxt 2 to Nuxt 3 using Nuxt Bridge

Mon, 29 Apr 2024 13:25:22 GMT

Last update 18/06/2024

Switching to a major new release or transitioning to a different framework is often a daunting task. Our attempt to migrate to Nuxt 3 was no exception. Despite the challenges and setbacks, it proved to be a valuable learning experience. This journey revealed both the strengths and weaknesses of our system, driving us to optimise and refine our processes. Here’s a detailed account of our migration story, the obstacles we encountered, and how we persevered to improve our infrastructure.

Although the migration didn’t go as smoothly as we hoped, it was a valuable learning experience. We faced several problems, but we also made important improvements along the way. This journey taught us a lot about our system's strengths and weaknesses, helping us become more resilient and adaptable. We found areas that needed better optimisation and improved our processes. Despite the setbacks, we gained deeper insights into our infrastructure. Below we explain in details what happened, the issues we faced, and how we managed to move forward despite the obstacles.

But let's start from the beginning. Nuxt 2 was becoming increasingly slow and was causing issues during local development. Our development team often found themselves frustrated with the sluggish performance, which was hindering productivity and delaying project timelines.

Additionally, to effectively conduct server-side A/B testing, migrating to Nuxt 3 was almost mandatory. The newer version offered better tools and functionalities for running these tests, which are crucial for optimising our user experience and making data-driven decisions.

Another significant factor was security. With the end of official support for Nuxt 2 scheduled for December 2023, we needed to transition to Nuxt 3 to ensure our platform remained secure and up-to-date with the latest security patches and features. Sticking with Nuxt 2 beyond this point would expose us to potential vulnerabilities, which could compromise our system's integrity and our users data.

Moreover, Nuxt 3 promised enhanced performance, better scalability, and more modern development practices. It was designed to take advantage of the latest improvements in web technology, making it a more future-proof choice for our projects. The improved architecture of Nuxt 3 also meant that we could build more robust and maintainable applications, providing a better overall experience for both our developers and users.

Given all these reasons, migrating to Nuxt 3 was clearly the best path forward for us.

Non-technical challenges faced

Apart from the technical stuff, we faced some other challenges during our migration:

First off, not everyone on the team knew much about Nuxt 3 and the new Composition API. This made it harder to use these new tools well and slowed us down.
We also didn’t have enough people working on the project. Only two engineers were assigned to the project at half capacity, meaning, only 50% of their time would be spent on the topic. So, we were a bit short-handed.
On top of that, we were also moving to our new system while still using our legacy one. Doing both at the same time was tough and stretched us thin.
Lastly, our current codebase wasn’t very stable since the number of new features planned to be implemented to create stability in our product. Fixing it up took extra time and effort before we could even think about moving forward.

All these non-technical challenges made our migration journey a bit bumpy, but we managed to work through them.

Technical Challenges Faced

During our migration process, we encountered several technical difficulties:

Issues with Nuxt Update in the Edge: The latest version of Nuxt, known as the edge version, turned out to be unstable. It frequently caused disruptions and didn’t integrate smoothly with our system. Instead of resolving existing problems, each update often introduced new issues.
Hydration Problems: Hydration, the process of merging server-rendered pages with the Vue.js application on the client side, posed challenges. We faced bugs and inconsistencies, impacting the reliability of our application.
Memory Leaks: Over time, our application began consuming excessive memory, resulting in slow performance and occasional crashes. This issue demanded urgent resolution to maintain system stability.
Rollout Issues: Deploying the new system posed risks due to its instability. Each rollout had the potential to disrupt the system, necessitating a return to the previous version to avoid downtime.
System Instability: Our new system suffered from instability, leading to frequent downtimes and unexpected behaviours that negatively affected user experience.
Lack of Real-Time Monitoring: We lacked adequate tools for real-time monitoring of our system. This deficiency made it challenging to promptly identify and address issues as they arose.
Unstable Development and Staging Environment: The instability extended to our demo environment, impacting our ability to showcase the capabilities of our system reliably to potential clients.
Nuxt Bridge and Nuxt 3 Functionality Issues: Both Nuxt Bridge and Nuxt 3 experienced functionality issues and lacked stability. Nuxt 3, intended to address these issues, remained unstable and incomplete until the end of 2023.

Turning Problems into Improvements

Even though we faced many challenges, the process helped us identify and make several key improvements:

Better architecture with cron jobs: Replacing the old Node.js generator service with Kubernetes cron jobs has made our build and deployment processes more efficient and easier to manage. Stay tuned, there will be a dedicated article for this but for now, make sure to check our other article that describes the architecture of our system.
Update and Remove Unused Modules: Updating our module means we now have the latest security patches, performance enhancements, and features, which will help us make any future implementation or migration attempt much easier.
Enhanced Monitoring: We have implemented better monitoring tools that give us real-time insights into system performance, allowing us to respond to issues more quickly.
Stable Environments: By addressing stability issues, we have made our demo environment more reliable, better showcasing our platform to potential clients.
Better Planning for Future Migrations: The lessons we learned from this migration will help us plan better for future migrations, allowing us to anticipate and address potential challenges more effectively.

Conclusion

Even though our Nuxt Bridge migration did not go the way we wanted, it taught us a lot and made our system better. It showed us how important it is to stick to our plans and give enough resources to the migration process. That's why we're even more committed to our current migration to Nuxt 3. We're making sure to focus on it and assign more people to get it done right. As we get ready for future migrations and updates, the things we learned from this experience will help us make them more successful.

Unveiling the Technological Framework: Emma’s Online Store Architecture

Fri, 05 Apr 2024 15:34:45 GMT

Last update 05/04/2024

In this article, we share how we're running our online stores for all countries in a micro-service based architecture.

Introduction

As highlighted in previous articles on this blog, Emma has undertaken a comprehensive replatforming initiative, transitioning our entire infrastructure from a monolithic architecture to a microservices architecture to accommodate our expanding needs based on the MACH principles. A decision that has been described in detail starting from here. 

In this article, we will explore a segment of the intricate replatforming architecture that guarantees the seamless operation of Emma Sleep. There is a specific focus on our technological framework crafted to unlock multi-billion growth through a state-of-the-art platform with an impeccable customer experience and be the flywheel for a tech-empowered organisation in the realm of sleep solutions. Join us as we uncover the layers of technology that play a pivotal role in our success in providing top-notch products and services in the sleep industry.

As we navigate through our technological architecture, it becomes crucial to comprehend the four distinct domains that shape Emma's technical infrastructure. These domains intricately interconnect to strengthen the foundation we are about to uncover, encapsulating the very essence of Emma Sleep's dedication to revolutionizing the sleep industry. The four domains encompass:

Offline & Marketplaces - Serving as a catalyst for the growth of our sales channels beyond our direct-to-consumer (D2C) business. This domain extends to partnerships in wholesale, various marketplaces, and the establishment of new Emma physical stores.
Operations Core - A dynamic and integral hub that seamlessly links critical aspects of our operations, encompassing transportation, stock, and product catalog management, as well as order management and fulfilment.
Finance Technology - The foundational support powering scalable, flexible, resilient, and reliable processes within our finance and accounting realm.
Online Store - A digital platform where customers can explore our product catalog and conveniently purchase their preferred items online.

Having gained insights into the fundamental aspects of Emma, let us take a detailed exploration of the Online Store's architecture – our customer-facing platform. We will delve into the mechanisms through which we deliver our sites to customers across 30 countries spanning five continents, ensuring robust high availability and scalability.

User Journey

Upon a client's visit to our website in any country, the requests are served through Cloudflare as our delivery network. Cloudflare plays a pivotal role in caching the content delivered to the client. It is worth noting that we deliver static files directly to the end user, plain HTML, CSS, JS, and other assets. The content, fetched from AWS EFS Storage through Nginx serving as proxy. The storage is organised by having a dedicated folder per country.

Figure 1. Serve static page sequence diagram

Even though we serve static sites to our end user, there is a part of the site that is still dynamic. Adding items to cart and placing an order is done through API Calls sent from the frontend to our API Gateway which validates the request and forwards it to CRM (Content Relationship Management) Service and Checkout Service. Checkout Service then forwards the request to Promotion Service and Payment Service to validate any discounts that might have been part of the order and to create a payment based on the payment method that the customer has chosen.

Figure 2. Place an order sequence diagram

Static Site Generation

As previously noted, we provide our customers with a static site. This entails that all the files presented on the browser are created on the server, then transferred to storage from where they are served, rather than being generated at runtime.

We employ two methods for file generation: at specific intervals through a cron job and whenever there is a change in content or product information using an event-based architecture. Both approaches are overseen by the generator service, employing an event consumer for messages and a Node.js cron job. Both the consumer and cron job internally invoke the same component to initiate the generation process. Now, let us explore the architecture of each method based on the diagram below.

Figure 3. Cron Job with worker and scheduler

As depicted in the diagram above, both the cron job and event-based mechanisms are interconnected. During scheduled intervals, the scheduler publishes messages for each country in the queue, assigning specific priority levels. Subsequently, the worker consumes these messages and invokes the generator component to initiate the generation process. In the comprehensive architecture diagram below, for event-based changes in content and product information, the respective services also publish messages in the queue with a higher priority level, effectively overriding the scheduled event.

The generator component programmatically triggers our Nuxt application to generate the site. The Nuxt application is seamlessly linked to all the essential services, ensuring the retrieval of necessary data for the site generation process.

It is worth mentioning that for all the components in the Site Generation block we use a monorepo architecture and they are all deployed together as one service.

Figure 4. Full architecture diagram

Conclusion

We trust that this article provides insight into the intricacies of our daily operations at Emma, shedding light on how we strategize and implement substantial initiatives like the one discussed, ensuring alignment with the latest technological advancements and meeting business demands.

As we are aware, nothing remains static, particularly in the swiftly evolving tech landscape. This is why the architecture described here will inevitably evolve – it must adapt, or it risks stagnation without proper maintenance. Consequently, we anticipate further developments to accommodate technological shifts and meet evolving business needs in the future. Stay tuned for more updates.

Making the bed for a new promotion engine

Fri, 08 Dec 2023 15:34:46 GMT

Last update 08/12/2023

In this article, we share how we swapped one of the most critical components of our checkout experience, the promotion engine, with zero downtime.

At Emma, we decided to rebuild our entire technology landscape from scratch back in 2021. We launched an organization-wide re-platforming initiative to migrate from our Magento monolith to a composable commerce architecture based on the MACH principles. A decision that has been described in detail in a series on the topic.

Throughout the re-platforming, we had to prioritize ruthlessly to meet our ambitious timelines and we faced multiple tough decisions regarding what to build now and what could wait. A prime example being our promotion engine.

The need for a new promotion engine

We are using commercetools to enable our e-commerce, and it comes with a built-in promotion engine that is both powerful and flexible. Despite its capabilities, however, we knew from the outset we would eventually reach its limits due to the scale and the nature of how we do promotions at Emma.

Our forecasts indicated we could leverage commercetools’ promotion engine for 1-2 years, so we decided to take on prudent and deliberate technical debt by deferring the decision to build or integrate a different promotion engine, thus allowing us to allocate capacity to more urgent topics with immediate impact.

Inevitably, the day came when we hit the limits and needed a new promotion engine. The most important pain points we had to address were:

Limited search functionality. Our marketers struggled to effectively manage the campaigns due to limited search functionality that severely impacted the discoverability and governance of the campaigns.
Weak market isolation. Promotions were global, meaning they could not be scoped to specific markets. This was poorly aligned with Emma’s decentralized marketing organization, and led to high business risk as markets could easily interfere with each other.
Inefficient evaluations. Due to global promotions, all promotions rules were evaluated for each cart. For an organization where the vast majority of promotions are market-specific, this implies a lot of unnecessary evaluations.
No support for dynamic bundles. Dynamics bundles are heavily used by our marketing teams, and there was no native support for them, leading to complicated and error-prone workarounds.
Hitting scalability limits. We were rapidly approaching hard limits on the number of campaigns we could run.
No way to enforce compliance. The promotion engine was so flexible that it became error-prone and risky, as there was no way to create constraints to ensure compliance.
Complicated coupon management. Managing coupon campaigns was complex and hard to debug, as coupon codes and campaigns were separate entities. Moreover, bulk generation of coupon codes could not be offered as self-service and instead, the marketeers had to rely on engineers.

After evaluating our options and researching available solutions, we concluded that Talon.One was the best candidate to address the above paint points.

Armed with context and a solution, we bootstrapped a small integration team of senior engineers and got to work.

The starting point: Tightly coupled entities

To understand our journey, we need to first understand where we started. The overall architecture, dependencies, and imperfections that surrounded our promotion logic. A high-level architecture is depicted in the image below.

Figure 1. The high-level architecture before the migration.

There are synchronous consumers, like our storefront, that interact with carts and promotions using a Checkout REST API. Additionally, there are various asynchronous consumers downstream, for example, services responsible for fulfilling the orders and our analytics platform.

In this architecture carts and promotions were tightly coupled in the backend, and this coupling was leaked to synchronous consumers through the Checkout API and to the asynchronous consumers through our OrderCreated schema. Consequently, all consumers were tightly coupled to the backend-specific handling of promotions. A dependency that effectively made it impossible to integrate a new promotion engine without introducing breaking changes for all consumers.

Another limitation in our workflow was stale prices and promotions. They were never updated after a product had been added to the cart. A recalculation of prices happened right before the customer was about to pay, making it a surprise to the customer and thus a poor experience. Finally, the representation of promotions was not consistent for upstream and downstream consumers, leading to business logic being duplicated in multiple places.

The target state: Anything-as-a-promotion-engine

The diagram below shows our target state with the breaking changes highlighted in red. The architecture below loosens the coupling by exposing consistent promotion-agnostic interfaces for both synchronous and asynchronous consumers, and by decoupling carts and promotions in the backend. This architecture not only allowed us to replace our existing promotion engine with Talon.One, but also makes it easier to integrate a different promotion engine in the future, i.e., anything-as-a-promotion-engine.

Figure 2. The high-level architecture after the migration

The building blocks

Promotions API

The first piece of the puzzle was the Promotions API. An API that would act as a middleware between the cart functionality in the backend and any promotion engine. This abstraction layer allows multiple promotion engines to run in parallel and simplifies integrating other promotion engines in the future.

Some might rightfully say that we are treading into YAGNI territory with the above arguments. However, the most important aspect of the Promotions API was immediate risk management. Being able to run our legacy promotion engine alongside Talon.One meant we could apply the strangler pattern to rolling out markets, i.e., doing one market at a time.

Modelling the interface

The schema for the new promotion entity was modeled as having two discount types, discount and discount code. Those types could be associated with two entities, the cart or specific line items. The high-level schema of the new promotions was defined as:

provider - string. The name of the promotion engine, either "Commercetools" or "TalonOne".
discountCodes - an array of DiscountCode objects. These represent discount codes on cart level.
discounts - an array of Discount objects. These represent discounts on cart level.
lineItemPromotions - a map of LineItemPromotion. These represent promotions applied to specific line items.
nonApplicableDiscountCodes - an array of DiscountCodes. The purpose of these are described later.

The detailed schemas of the objects are not relevant for this article, but to give an idea, a discount code looks like:

Figure 3. An example of a discount code representation.

Deciding on service granularity

One architectural decision we faced during the design of the Promotion API was whether to create it as an independent service or as a module in the existing Checkout API. A simplified tradeoff analysis is summarized in the table below.

Reasons to keep as one service

They share code since both interface with our e-commerce backbone, commercetools.
They are part of the same workflow, thus communicate extensively.

Reasons to create a separate service

Promotions are business-critical to Emma and will be managed by a dedicated team in the future.
To be able to deploy independently, without being coupled to the release cycles of the Checkout API.

Checkout API v2

The next building block was the synchronous API. We had to re-design the Checkout API to foster a looser coupling. The initial version was tightly connected to the native commercetools schema, meaning we could not swap commercetools as a promotion engine without the storefront breaking.

We wanted to create an API that maintained consistency irrespective of the promotion engine being used. The objective was to forge an interface that could facilitate the synchronous consumers’ migration to the new API concurrently with the integration of the new promotion engine into the backend. This parallel migration was crucial, given they were carried out by separate teams.

We leveraged the new promotion object described above to associate carts and line items with discounts and discount codes. The representation of a cart in Checkout API v2 is depicted below:

Figure 4. An simplified representation of the cart in Checkout API v2.

As seen in the schema, there is a key called nonApplicableDiscountCodes. It is a list of valid codes (meaning they should not be rejected) that yield a zero-value effect. This could mean, e.g., applying a discount code that requires a minimum cart value before the minimum cart value has been reached. Allowing this behavior was necessary to cater to the requirement that a user should be able to successfully add coupons to an empty cart, e.g., when clicking on a UTM link.

Improving the customer feedback

Additionally, we extended the Checkout API with a warnings object. This addressed our previous limitation that we never provided feedback to the customer if there was a price or discount change. The warning object provides information to the client about any price or discount related change that was not caused by any customer action.

The warnings can stem from price updates on products and shipping, discounts, and discount codes, and they can be associated with both the cart and specific line items. An example of the warnings object can be seen below.

Figure 5. An example of the warnings objects

Now, the final piece of the puzzle was to make the async API, the OrderCreated event schema, consistent with the new promotion object.

Order Schema v2

Like the synchronous API, we also depended on native commercetools fields in our asynchronous interface, i.e., the OrderCreated event schema. We deprecated those fields and extended the schema with the promotion object described above. The updated schema enabled the downstream teams to migrate while the integration team was integrating the new promotion engine.

With the building blocks defined, i.e., the how, we also had to decide on sequencing, the when.

First expand, then migrate, and finally contract

We optimized for short time-to-market. However, we also had to carefully manage risk, given the business-criticality of the checkout. We generally move fast, break things, and fix them later, although when dealing with discounts, prices, and the overall checkout, we had to tread more carefully.

Therefore, we chose to carry out the migration using the parallel change pattern, i.e., in three phases: expand, migrate, and contract. In the first phase, the expansion, we designed and implemented the v2 interfaces for our consumers. Running v1 and v2 in parallel laid the foundation for the migration phase, as all consumers could migrate while the integration team worked on building out the Promotions API and integrating Talon.One.

When the consumers were running on the new versions and Talon.One was integrated, the rollout of markets could begin. We started with small markets, and doing them one by one, before incrementally adding complexity and doing markets in bulk. Finally, we deleted old endpoints, removed access to the old promotion engine, cleaned up some configuration, and decommissioned the old promotion engine.

A high-level roadmap can be seen in the picture below.

Figure 6. The migration roadmap.

Go slow, to go fast

9 months after we set out on the journey described in this post, we migrated our 22nd and ultimate market to Talon.One, and we dismantled the integration team. We are deeply grateful to everyone who made this happen.

This was a significant undertaking that involved around 30 teams and close to 400 users. We managed to replace a key component of our checkout with zero downtime. A testament to the flexibility of composable commerce, and a strong product and engineering organization.

The approach to first re-designing the interfaces to foster loose coupling required significant upfront investment, however, it was key to enable a swift rollout while mitigating risk. We went slow, to go fast.

The Tech Genesis Initiative and Our Onboarding Experience

Thu, 09 Nov 2023 15:34:49 GMT

Last update 09/11/2023

The Tech Genesis Initiative is Emma’s Internship program to internally grow young talented individuals, to provide them with the right resources to develop into strong software engineers, in line with Emma's DNA, and give them real-world professional experience.

The Tech Genesis Initiative is Emma’s Internship program to internally grow young talented individuals, to provide them with the right resources to develop into strong software engineers, in line with Emma's DNA, and give them real-world professional experience. As part of this program, seven passionate and diverse individuals, two from the Frankfurt office and the others from the Lisbon office, joined to make an impact and help Emma grow and disrupt the sleep industry.

Our Company Onboarding

As part of the Genesis team, I, and the other fellow interns joined Emma on the 1st of November 2022 and started our company onboarding journey.

During the first few days, the onboarding took place remotely. We first got introduced to Emma and its products, as well as its multiple roles and teams within the company and their responsibilities. We had various remote sessions with intros to the Emma tech stack before flying out to Frankfurt the following week, to have the rest of the onboarding sessions in person.

The Frankfurt Trip

The trip lasted the whole week, flying in on Monday, November 7th and returning to Portugal (for the people based in Portugal) on Friday, November 11th. After flying in and arriving at our hotel, we got introduced to the tech team members and all had dinner together. The dinner was amazing, we got to know some of our colleagues better, ate lots of tasty food and talked for hours. We decided to extend the night by going to a nearby pub, where we met the company’s CTO in person and talked while we were having drinks. This would go on for the following days of the trip as well. The following days were packed with tech stack intros, for example, Git and Typescript, as well as workshops on Agile frameworks and methodologies and some extra activities, but as an Agile and transparent company, we were given the whole week’s schedule in advance.

Tech Stack Intros

As software engineering interns, we had several introductions to Emma’s tech stack. Specifically, we had an introduction to Git, the workflow of Emma, and the most used commands, followed by a thorough guide to Typescript and why it’s preferred over JavaScript. In addition to Git and Typescript, we also had a meeting on the fundamentals of Vue.js, the framework used for the frontend part of our E-Commerce website, along with Golang, one of the main languages used in the backend.

Agile Methodologies and Frameworks

Along with the tech stack introductions, we also got several sessions on agile methodologies and frameworks, such as Scrum and Kanban. These sessions were in the form of “Agile Games”.

The structure of these agile games was:

Introduce the game and its base rules
Some of the games would consist of various “rounds”. Each round consisted of a “reflection” time and a “planning” time, and the rules could also change.
After the game ends, we would be presented with the definition of the methodologies and frameworks that we used during our game, and how they are used in real-life scenarios.

Props to our Agile Excellence Managers Tayeska and Daniella, who did an amazing job introducing agility to us in an incredibly fun and memorable way, which has made it easier for us to understand and use in real-life situations.

Extra Activities

Despite the goal of this trip being our company onboarding, Emma made sure we made the most out of this business trip. The Engineering Managers had planned for us to spend a day of the week discovering Frankfurt together. A tour guide was hired, who showed us around the city center of Frankfurt and explained its history to us. Following the tour, we went to the top of the Main Tower and saw an amazing view of the city.
Afterward, we went to a surprise escape room game, where one of our Engineering Managers, João, decided to join. Unintendedly, we applied the knowledge we learned during the agile games to be able to escape as fast as possible! It was a fun experience, given that none of us had been to an escape room before.
Another extra activity we had was a session on how to create a mattress, given by our experts here at Emma.
To top everything off, one of our fellow interns, Cvijeta, mentioned how she loves baking! So, we scheduled a last-minute workshop right before going to the airport: How to bake a cake! However, we ended up just making pancakes due to complications.

Conclusions

In conclusion, this onboarding experience was full of knowledge, insights, and a lot of fun. It truly highlighted the culture and DNA of Emma, and I can confidently say it served its purpose.

Nowadays, we are all distributed to our respective teams and are taking up our individual responsibilities, though that hasn’t stopped us from keeping in contact with one another. I cannot wait for the next big Tech Event that awaits us, and the impact the Genesis Team will bring.

Tech Gathering 2022

Thu, 12 Jan 2023 15:34:50 GMT

Last update 12/01/2023

Our Tech Gathering took place in Frankfurt near our main office. Almost 70 people (~80% of the Engineering and Product workforce) showed up for these 2 full days, coming from all of Emma’s offices and Tech Hubs in Lisbon, Frankfurt, Hamburg, Berlin, and Munich as individuals from all over Europe.

I joined Emma in September 2021, and since then, I haven't been able to meet everyone in person, mainly due to COVID restrictions. I also know that most new joiners never met anyone from their team in real life! These past few years have taken a toll on people, remote working is comfortable for most engineers, but meeting in person is still something we treasure, even if it's only once every blue moon.

I want to share my version of this journey of setting up a presential Tech Gathering at Emma.

The organization

We decided to organize our first Tech Gathering at Emma in the first week of May 2022. We started thinking about it around March, and the first decision we made was to choose the overall goal of this event: to promote an atmosphere that encourages bonding between technology team members

The activities

As an agile and transparent company, we shared our plan from the very beginning so people could prepare their travel plans and accommodations. At the same time, we shouted out for volunteers to be part of the organization. Each activity had a group of volunteers responsible for planning, purchasing items, and choosing the time and locations.

We drafted a plan to have 3 main activities over 2 days:

1) Agile Run : understand how the agile mindset can make us better professionals (and individuals).

Don't be fooled by the naming. It is not a marathon or an athletic challenge. We wanted to help people understand some Agile Principles and why we use them. We divided the group into 5 random teams. Each team had 5 games to play in the middle of the forest. It was incredible!

2) Feed the Tech Emmies: an offsite dinner with a lot of food and drinks.
3) Give Back Day: a day to support philanthropic causes and aid the community.

We wanted to give something back to the community. We contacted various organizations, and we learned it was challenging to offer almost 70 people to help around in the city. Fortunately, CleanFFM was incredible and guided us as we collected trash by the river Main near our office.

The group initially planned for the games to be indoors, but when the other group chose the place for Feed the Tech Emmies, they switched the location to the forest surrounding the restaurant. Like this, we could walk to the restaurant after the Agile Run with ease and we would be outdoors in nature.

Yes, we even picked up a broken 65-inch TV and >100 kg of trash! After collecting and deposing the trash, we sat by the river and had a nice picnic on this beautiful early summer day. Some Emmies brought blankets, a sound system, and games. Some played, and others chilled in the sun as they chitchatted with teammates, they met in person for the very first time.

On both days we managed to keep the atmosphere very relaxed. There was genuine curiosity in the air, and people were asking questions and sharing stories with big smiles on their faces. It felt like we were all together for the same reasons.

Learnings

I do take some interesting learnings from this experience. Things went exceptionally well even though we took quite a few risks. Deciding to do most of the activities outdoors was one of those risks (although there were fallback indoor plans). In the end, all went well. Even the weather helped, which was surprising. The weather forecast was constantly changing, it didn't rain until we ended all our activities, as if it was waiting for us to finish first. Organizing an event of this nature is complex. You need all the help you can get, and there are a lot of details you need to plan that take time – start early, a month or even two before you think is reasonable to start planning. Providing an easy-to-read agenda is hard to achieve but is essential for people not to feel lost.

What's the most precious thing I take from this Tech Gathering?

It's not how well you plan things or how much money you spend on them or how fine the weather is. An event is only successful if the people who participate make it a success – it was an enormous success - a big kudos to you all who participated!

I guess it’s in our Emma DNA. We are one team, one dream!

Part 9: The 5 Must Dos most Leaders fail at

Sat, 09 Jul 2022 15:34:51 GMT

Last update 29/07/2022

Learn more about my most important take-aways from this replatforming project at Emma — The Sleep Company.

Ok, that was click-bait. My apologies. And actually, there are seven. ��

But seriously, I think there’s a lot we have learned over the last year, and I hope that the previous blog posts give you inspiration and food for thought. My most important take-aways from 2020 and most of 2021 are:

Create your vision of the target state first. It must be at the beating heart of your organization’s business. And it must be so inspiring and compelling that if someone was to pitch it to you, you’d be switching jobs to be part of the team that builds it.
Plan top-down early and refine. Test and verify bottom-up. Never rely on a sales pitch. Trust your engineers — but also challenge them.
Build an amazing team. Obvious, but really very hard. Never settle for average. Never hire brilliant jerks. Hire for attitude, not experience or skills.
Define an organizational model that can scale as you grow the team. Keep it flat. Rethink roles, reporting lines, strengthen lateral leadership. Offer personal development paths. Minimize team dependencies.
Define solid fundamental engineering principles, a harmonized software development process and tech stack(s).
Embrace the cloud. Go API-first. Rent what others build better. Build what you can do better than others (even if not your ‘core business’)
Be bold! Just because nobody did it yet doesn’t mean it cannot be done.

As this is the end of our first blog post series, I’d like to thank the best team and I’m proud to be part of: The Emma Sleep Tech team! Kudos to all Emmies and our partners for allowing me to tell such an exciting story about what we love to do!

You rock! \o/

Part 8: Changing Business — One night at a time

Fri, 08 Jul 2022 16:23:42 GMT

Last update 29/07/2022

Our system migration is a heavy lift . Learn more how we approached to execute our replatforming.

Everybody that has been working in the context of a larger system upgrade or migration knows that what we’re looking at is a heavy lift! And it doesn’t necessarily get easier if you decide to ‘leave no stone unturned’ and revamp the entire landscape. Surprisingly yet, fast-forwarding like we do brings you one big advantage that more narrow migrations and changes wouldn’t — you don’t need to back-integrate and uphold a lot of legacy systems’ interfaces. And you have the big opportunity to build something very coherent and made mostly of already existing parts (i.e., the selected SaaS). However, this only holds true if replatforming can minimize the duration of running two platforms in parallel by migrating the business swiftly.

Let’s be honest: running an old platform to support your existing business, while designing and building its successor in parallel is insanely expensive and can bleed you dry as a company. The easiest way to deal with that is — not doing it, meaning you close the store for renovation and only work on the new platform. Of course, this isn’t realistic and as Emma’s business is rapidly developing, the very opposite is the case: we need to develop features and improvements on the old platform and simultaneously anticipate those in the new one.

The details of the business in different countries and markets are quite varying, so complexity in terms of features needed also heavily differs. This then also means we don’t know every little detail of functionality yet and need to discover along the way of migrating our business. At Emma we refer to 3 classes of business footprints in a market: 1. Pioneers that are nascent and still need to proof their business case, 2. Emerging that are scaling and 3. Trailblazer that already have scaled and are the most mature. Today Trailblazer countries roughly account for 80% of our business and yield the highest degree of complexity.

Now, when doing a migration from a highly customized legacy system to a new one, a common anti-pattern experienced is to ‘just carry all requirements over’. The systems’ contexts are very different and just because back in the day you’ve decided to solve a specific problem in a certain way, doesn’t mean in a new system environment the same applies. Doing so will easily lead to scope inflation, a (again) suboptimal system design and very long implementation lead times, due to the fact you are replicating a legacy design on top of a new one. Also, there might be integrated solutions on the SaaS platforms or additional purpose-fit services available that could replace your self-built logic. Instead, deeply understanding the business requirements we assessed and put into epics and user stories, we now begin to challenge those requirements with our business stakeholders and re-apply the 6 questions we ask ourselves every iteration (please see part 3 for reference):

Are we working on the right topics?
Are we working on the topics the right way?
Did we really understand the problem domain before jumping into solutions?
Can we solve this more simplistic?
Is this the right scope for a version 1?
What will it take to make the version 1 replace the legacy system entirely?

Using the MoSCoW ( Must Have, Should Have, Could Have, Won’t Have this time ) classification method, this rigid process helps us to minimize the requirements intake and increase speed for a first working version. By this we get early to the point of running the business of a country entirely on the new platform and thus can stop developing features for it on the legacy one.

To be fair, this process is not an easy one, as it involves deprioritizing features and functionalities that will hurt the business directly, sometimes in terms of revenue loss. However, dramatic as those might be regarded in the local perspective of a country, on the global level this still makes sense since it will decrease the time until we can seize parallel development and focus only on the new platform.

Focusing on the global biggest impact levers and minimizing the timeline in mind, we intentionally planned the rollout / migration of our business onto the new platform not as a ‘big bang’ scenario (where you flip the switch for all of business in a single instance) but instead in an incremental way, starting with as little complexity as possible, i.e., Pioneer markets and then unlocking the more complex cases for Emerging and finally Trailblazer markets case by case.

We are thrilled to have successfully rolled out the first Pioneer countries (i.e., Columbia and Chile) by now and prepare now intensively for the higher complexity class of Emerging and Trailblazer markets. As we learn with each country rolled out and having the overall number of >30 ahead of us, we also plan for multiple rollout teams in the project that use the blueprints from the earlier rollouts and replicate efforts in parallel, streamlining the overall endeavor further.

But then again, the whole effort is based on our believe in agility, deeply rooted in Emma’s cultural DNA, iterating on current working hypotheses, and adapting on the feedback gathered. So certainly, we will adapt our approach to the learnings we have on the way. Yet we feel confident we’re doing the right thing and we’re doing it in the right way within our planning horizon at the time of this writing.

Part 7: Emma’s Composable Commerce Architecture (3 of 3): The MAKE Parts

Thu, 07 Jul 2022 16:23:40 GMT

Last update 29/07/2022

The proof-of-concepts conducted with the finalist solution candidates ultimately let us decide for the best systems.

Why did we go with SSG, Typescript, golang and VueJS+NuxtJS?

For the customer-facing storefront we evaluated various tech stacks including the most popular general-purpose web-frontend frameworks and libraries (ReactJS, AngularJS, VueJS) to more purpose specific ones in the E-Commerce domain (Frontastic, VueStorefront).

The frontend in itself should not contain any content or assets, it should be provided by other services such as a headless CMS and a PIM. This will enable a decoupling between content editors and software engineers. The content editors will be able to update the website using the UI provided by the services.

To reach our goals to build a state-of-the-art E-Commerce storefront that is built to be fast, flexible, cost-efficient, and quick to implement, we set a couple of technical characteristics for it to achieve, i.e.:

Delivering a Progressive Web Application (PWA),
Following JAMstack (Javascript, API and Markup) approach to web development (application logic resides on the client side),
Using modern framework(s) with a vivid community and available talent pool,
Supporting Emma’s rapid growth though concurrent development

As the JAMstack name implicates, modern web development today is dominated by Javascript-based tech stacks. In the end we decided for VueJS+NuxtJS in the frontend, developed in Typescript. Below are the individual points of our decision rationale.

Why SSG instead of SSR for the Storefront (high traffic)

As speed metrics such as — First-Paint, First-Contentful-Paint, Time-to-Interactive and Time-to-First-Byte — are crucial in any E-Commerce site, SSG is preferable if feasible for the use case. Due to a manageable number of pages (few products) and not too frequent content updates, SSG’s cons don’t apply in our case.
Cost will be minimal compared to SSR as the static pages can be deployed to static CDN without cost scaling per page visit. A valid argument is that it can be achieved using SSR by caching the pages, but that introduces new complex problems.
Offers less security concerns due to minimal attack surface.
A/B testing will not be as easy as with SSR, but they can be performed by generating multiple versions of the site and use split testing (we will enforce a limit on concurrent A/B due to avoid variation explosion).

Why SSR instead of SSG for lower traffic, dynamic pages?

The customized content needed for each page does not suit the SSG case because there is too much dynamic personalized data involved.
An alternative would be to use SSG with client-side fetching. But would need to fetch all data and therefore the gain is minimal. First Meaningful Paint would be slower.

Why VueJS instead of ReactJS?

More collective knowledge about it than ReactJS at Emma, meaning faster and more reliable implementation.
Easier to transition to without prior knowledge of modern web frameworks.
Superior documentation including best practices that aligns VueJS projects across organizations.
Easier to onboard new team members: For inexperienced developers it’s easier to separate logic from HTML when doing DSL instead of mixing arbitrary JS with HTML thus making the codebase more maintainable.
There is a larger fraction of developers who used ReactJS but would not use again compared to those who used VueJS but would not use it again.
It’s popular — VueJS already has more github stars than ReactJS.
Preference within the team — this is taken into consideration as happy engineers mean better teamwork and product in the end.

Why VueJS instead of Angular?

Angular’s learning curve is steeper.
It’s not as lightweight as VueJS.
Angular is better suited for more complex applications or applications behind a login page.

Why not VueStorefront?

They are in between versions with the VueJS 2-version being tied into the old ways of creating VueJS apps and the new VueJS 3-version not being production-ready yet.
The main reason of going with VueStorefront would be speed of implementation as a lot of the core features are implemented already, but, as the new VueJS 3-version is not ready yet, we can’t rely on their schedule for the missing and broken features.
The initial investment of creating the provided features ourselves in a project we fully control, in our opinion, outweigh the usefulness of the framework. However, we can take inspiration from them on how to manage features, best practices, etc. as the project is Open Source.
They focus on SSR and SSG is still an experimental feature in the stable VueJS 2-version. The main use case would be a shop with a lot of products, showing the ‘classic’ product categories and search feature for them.
They also have an E-Commerce component library which would speed up the initial implementation but since the library is Open Source and decoupled from VueStorefront we can still use it if we want. Also, it would take a while to understand the framework and what are the things we don’t need and how we can strip them away.

Why not Frontastic?

The visual editor is redundant to the CMS. When combined with the headless CMS, if we model the content right, we can do what we need in the CMS. Having both we feel would bring confusion to the editors.
We already have the infrastructure ready to go to be able to manage the complexity surrounding deployments ourselves, which is one of the main things of their offering.
To develop UI components in Frontastic we would need to use their infrastructure for everything. Nothing is done on Emma’s systems, even the repository is owned and provided by Frontastic where we use their built-in file sync to sync with their servers.
Looked to be too new with too many bugs for now. The UI had at the time we tried it breaking bugs and the general feel was that it was barely production ready.
They used SSR and changed per site visit as the price model. For Emma’s business the commercials were not convincing.
It forces us to use ReactJS — no other choices offered.

Why NuxtJS

NuxtJS is by a wide margin the most adopted and mature SSR/SSG framework for VueJS.
NuxtJS can only be compared to the counterpart in ReactJS called NextJS.

NextJS offers some additional features that NuxtJS doesn’t, but both have the features we need and as VueJS was preferred instead of ReactJS we can be confident with NuxtJS.

Why Typescript and golang?

As laid out in part 4, Harmonized Software Development makes a lot of sense and as our general web development approach uses JAMstack, the solution space is predetermined to tech stacks based upon Javascript. Looking at recent developments in the Javascript space, we found that Typescript offers a lot of advantages over pure JS, namely:

Strict typing pulls error-handling from runtime to compile time, meaning early debugging and correction by the original code author.
Object-oriented approach and language features (e.g., interfaces, generics, type annotations).
Improved readability and documentation through strictly typed character.
Compiled (in fact transpiled ) to Javascript (ES-6, ES-5, ES-3, …).
None to insignificant performance compromises compared to Javascript.
Moderate learning curve to adapt from Javascript to Typescript.
Large talent pool of developers available as there are two career development routes available, i.e.: (1) web-developers coming from loose-typed Javascript to Typescript and, (2) application-developers coming from strictly typed languages (e.g., Java) entering the web domain

So, we decided to use Typescript as our primary programming language in the business domains for frontend (client-side) and backend (server-side) of our E-Commerce architecture as its downsides (e.g., being single-threaded) are not relevant in our use cases.

However, for specific workloads in the backend of the Order Management business domain, we chose golang as a second programming language, due to these considerations:

Based on the business forecasts, we expect to process a high volume of events.
We know that the OMS will sit between a lot of other services, and we don’t want to risk bottlenecks due to slow performing microservices.
golang is proven to be fast and has very little resource consumption in Kubernetes deployments.
It’s deployable as serverless functions with almost no code changes.
It’s built with microservices in mind and taking concurrency to the next level.

Final Thoughts

We hope this rather long post gave you a good idea on our thought process when deciding for the cornerstones of Emma’s composable commerce system landscape as of this writing. For sure in the future, we will learn more about the tools we selected, and we might even turn away again from one or the other to head for an even more promising alternative. However, this is exactly the most important part and the beauty of our foundational principles for selection, ensuring flexibility to adapt agile to ever changing business requirement and insights along the way.

Part 6: Emma’s Composable Commerce Architecture (2 of 3): Interfacing with the Enterprise World, raising some eyebrows

Wed, 06 Jul 2022 16:23:39 GMT

Last update 29/07/2022

The proof-of-concepts conducted w ith the finalist solution candidates ultimately let us decide for the best systems.

Why FluentCommerce OMS as Order Management System?

We decided to use FluentCommerce OMS as the default Order Management System for Emma. The decision was taken by the team after extensive research, discussions, and testing because of the good balance it offers in terms of feature coverage, flexibility, extensibility, developer experience, and lowest cost compared to the other solutions. In summary, these are the deciding factors for FluentCommerce OMS:

Best coverage of the main business requirements.
Highly scalable due to microservice-based and cloud-native architecture.
Best configurable — not customizable — system offers high flexibility with changing business requirements.
API-first approach to enable better integration and interfacing with other systems at Emma.
Lower licensing cost compared to competitor solutions.

Why Pulpo WMS as Warehouse Management System?

While researching Warehouse Management Systems we learned that similar to other more conventional areas of ‘enterprise software’ (e.g. ERP, CRM, etc.), this domain is pretty much dominated by legacy third party software companies, running software that was often built in archaic ways — quite the opposite of what we are aiming at for our new tech architecture. Different from the other business domains we had an external specialist consultancy support us in the initial collection of requirements, solution research and evaluation of alternatives. As Emma doesn’t own heavy assets like production facilities or warehouses but partner with specialist 3rd party companies in the respective countries, the topic is almost a ‘greenfield’ — meaning entirely new — for us. In the past, we also did small customizations you can consider WMS-ish built in the legacy E-Commerce backbone, but overall speaking we are not replacing an existing, dedicated system of Emma but extending our reach of tech-driven processes into the domain of our partners’ warehouses with a new one.

Out of the more than 100 different vendors and solutions on the longlist, we condensed a shortlist of only two modern systems qualifying against Emma’s high architectural requirements. Not surprisingly one of those two selected, Pulpo WMS, is developed by a startup company and thus very fresh in the game. Deeply evaluating the two against each other, we eventually decided to go with Pulpo WMS for the following reasons:

Less total but more relevant pre-built feature set for Emma’s specific use cases.
Possibility to flexibly extend the feature set according to Emma’s operational needs, from both sides, Emma and Pulpo.
Approach to go live fast with something small to begin with and adapt is following Emma’s core principles.
Ability of the vendor to implement a first test scenario 6 months (!) faster than the competition.
Overall significant better cost projection (both one-time and recurring) compared to competitor.
Built with modern software engineering principles; almost MACH-compliant system architecture (e.g., API-first).

As the deployment of a WMS, more than most other of our business domains, is very physically impacting operational processes and people at warehouse facilities (and again, these are not Emma but partners) conducting a Proof-of-Concept (PoC) test meant a physical trial at one of our partner’s warehouses. First results look very promising, and we believe this will play a big part in the overall harmonization and streamlining of our operational processes throughout Emma’s value chain.

Why Microsoft Dynamics 365 F&SCM as Finance and Operations Core?

When growing from startup to scale-up, for the longest time you don’t even have an ERP — ‘ Enterprise Resource Planning ’ software. Your business scales and the Excel spreadsheets you started with just keep growing and it might be surprising to see, but you can run a business with this kind of (process-wise) unstructured tooling quite well in the million Euros of revenue. The problems kick in when your business grows in complexity as you expand in more markets, enrich your product categories, establish new legal entities, vertically integrate with partners, etc. It is when the value-driving processes of your operation leave the trivial territory where manual tooling reveals it proneness to error and fragility. Typical symptoms of this are tedious and slow collection of data to answer simple business questions as well errors and incidents piling up and, as there is no better solution available, your imminent reflex is to solve more errors manually with more workforce.

As laid out earlier, our business grew (and still grows) near to exponentially which in turn means that errors correlating with regular business operations (like the afore mentioned coming from manual tooling) also scale similarly and would require the same amount of manual fixing. Yet hiring (and also sourcing) for your teams usually progresses in a linear fashion and pushing your organization into hypergrowth can have fatal consequences, resulting from the fact complexity of organizational collaboration also grows at 2n. Obviously, this is a futile fight and a dead end.

Already almost 2 years ago, we decided to implement an ERP-system and chose a mid-sized system corresponding to the business status quo at the time, i.e. Microsoft Dynamics 365 Business Central. However, only after a year, we learned that we already outgrew the Business Central version of Microsoft Dynamics in terms of business volume. So, back to square 1.

ERP-system integrations are very massive project efforts. At this point we could have gone into ‘ full market research ’-mode, meaning we would collect and refine our business requirements once more and evaluate which of the major ERP-systems of the well-known vendors would be best fitting (a.k.a. searching for the global optimum).

Unfortunately, this domain of ‘ enterprise software ’ is dominated by huge (and I mean HUGE) corporations and there are no modern, disruptive players in the field — at least not for use cases of scale-up companies of our size and complexity (>500mn EUR of rev; business in >30 countries). Evaluating the best fitting solution from these systems with the help of the vendors and their system integration partners can easily take a year — and that is until you know what might fit — implementation takes another 2–3 years.

So, instead we decided to take a very different approach and search for our local optimum . Looking at the solution alternatives we decided to:

‘ Rock the boat ’ as little as possible for users of the existing system and our ERP-developers, meaning we would stay within the same family of solutions of the same vendor (i.e. Microsoft Dynamics 365). This minimizes the retraining efforts and eases migration efforts as, even though there are no simple upgrade paths between such systems, parts of the ecosystem and data structure are reusable.
Purely look at system capabilities from a business requirements point of view, and never — I must repeat to emphasize this — NEVER from the optimal utilization of all integrated modules of such a system. We have very consciously and for good reasons decided for several purpose-fit, openly architected systems in our business domains and the ‘ fully-integrated ’ claim of ERP-system vendors can also be translated into ‘ proprietary monolith lock-in’ . This is also why we don’t call the business domain ‘ERP’ but Emma’s ‘ Finance & Ops Core ’.
Not rely purely on an external workforce for the integration (i.e. consultants) but build an internal team and augment with multiple external partners for special subject matter expertise. All software has operations & maintenance and needs further development over time — an ERP-system is no exception here and if it is managing at least parts of your value chain (why else would you even have it?) you want to be able to do this yourself.
Strongly challenge the scope to implement and really boil it down to the absolute minimal possible feature set to implement. We don’t need perfect on day 1.
Approach it by building a ‘ Minimal-Viable-Product ’ (MVP) first and then iterate and deliver often in the process. We might not need perfect on day 1, but we need version 1 day after tomorrow!
Take care of the project management ourselves. Most integration partners have extensive experience in conducting large, complex, years-long-lasting ERP-system integration projects managed in waterfall-fashion. You will see ‘agile’ statements in pre-sale pitch slides, but there is really no agility at all in such conventional project approaches and usually they revert to old practices almost immediately after contract signature.
True agile approaches are novel in this domain and don’t come with best practices. Be bold, push hard and create best practices!
Ultimately, we decided for Microsoft Dynamics 365 Finance and Supply Chain Management (F&SCM), trained, and extended our teams and recently started into the MVP phase of this integration and migration project.

I won’t lie to you. Our approach raised quite some eyebrows and did not make us popular with integration partners. Nevertheless, we are convinced our approach is the right way to go, incrementally delivering value to our business teams in short intervals, learning and adapting our route while we go.

Watch out for upcoming blog posts covering our learnings, successes and fails on this journey.

Part 5: Emma’s Composable Commerce Architecture (1 of 3): The Cornerstones

Tue, 05 Jul 2022 16:23:38 GMT

Last update 29/07/2022

The proof-of-concepts conducted with the finalist solution candidates ultimately let us decide for the best systems.

The proof-of-concepts conducted with the finalist solution candidates ultimately let us decide for the best systems for Emma’s new E-Commerce platform, i.e.:

For the used SaaS:

commercetools as the E-Commerce Backbone (ECB)
ContentStack as the Content Management System (CMS)
FluentCommerce OMS as the Order Management System (OMS)

Pulpo WMS as the Warehouse Management System (WMS)
Microsoft Dynamics 365 Finance & Supply Chain Management as the Finance & Operations Core (F&O Core)

For the self-developed services, we chose:

Static Site Generation (SSG) using VueJS and NuxtJS (Typescript) for the Storefront pages
Server-Side Rendering (SSR) with VueJS and NuxtJS (Typescript) for the user-specific dynamic pages
NodeJS (Typescript) as the default backend framework
golang for more performance-optimized backends

And finally, this all is based on a new and developer-friendly CI/CD infrastructure comprising of:

GitHub as Source Code Management (SCM)
GitHub Actions as CI
Pulumi as Infrastructure as Code (IaC) — with a Terraform bridge
Docker on managed Kubernetes deployment
all running on Amazon Web Services as cloud hyperscaler

This selection of tools also perfectly plays together with other tech stacks we run beyond E-Commerce, namely non-E-Commerce websites (VueJS & NodeJS), mobile app development in Swift & Kotlin and BI/data related workloads in Python & SQL.

But let’s explain our rationale one level more granular, essentially publishing parts of our Architecture Decision Records in their current version as of the writing of this article.

Why commercetools as E-Commerce Backbone?

We chose commercetools for the Emma E-Commerce backbone™, since it is providing the industry leading headless E-Commerce platform and it is highly flexible and extensible, with excellent developer tooling available.

commercetools was founded in Germany during 2006 and has since then been a pioneer in headless E-Commerce. In fact, it was the first E-Commerce platform to be designed for headless from inception. Today hundreds of small, medium, and large enterprises across the globe run their business through commercetools.

In addition to the benefits of following the MACH principles, commercetools stands out due to the following reasons.

Large feature set

Of the providers offering the same type of platform, commercetools brings the largest feature set off the shelf. It ships with a commerce API of 300+ endpoints with e.g., strong support for identity and access management, built-in functionalities for product information management (PIM), order editing and a powerful promotion engine.

Rich ecosystem

In addition to the feature set, commercetools is surrounded with an ecosystem of excellent developer tooling, most importantly mature support for GraphQL and Terraform. GraphQL solves many of the drawbacks REST APIs have and Terraform is a powerful tool to automate processes and quality assure deployments. Moreover, commercetools has a marketplace with plenty of official 3rd-party integrations.

Industry leading extensibility

To stay future-proof, flexibility and extensibility are key traits to a modern E-Commerce platform and commercetools is leading the pack in this regard. The data model can be extended with custom fields, the APIs can be extended by triggering snippets of custom code without having to build and maintain a microservice for every use case. In addition, commercetools is the only platform that is built truly event-driven. A crucial feature in a distributed and cloud-native tech landscape.

Provider stability

commercetools is the most established provider among those in the headless E-Commerce space. It has the strongest financial backing (recently announced their series-C funding) and has the largest enterprise customer base.

Why ContentStack as Content Management System?

ContentStack was chosen as the headless CMS for all structured content across the organization since it provides a stable and proven CMS with focus on medium to large business and enterprise customers, fitting well with Emma’s future growth plans. The product was originally created in 2014, but was back then part of another company’s portfolio. It was first in 2018, acquired by Germany-based Software AG, that the Company ContentStack officially was created.

Overall ContentStack provides a very wide set of key features and characteristics, i.e.:

Flexible Content Models

ContentStack uses a very powerful, flexible, and extendible content model with multiple variants, making it easy to shape your content in an optimal way for most, if not all, use cases.

Versioning

All content is versioned and using their built-in UI it is very easy for non-technical users revert to any version.

Scheduling and Grouping

Content publishing can be scheduled and grouped thus making it easy to synchronize releases of content.

Collaboration and Workflows

Strong collaboration and workflow features aimed to make content editing in teams frictionless, concurrent, and productive.

Pre-Built Integrations

ContentStack also is part of the MACH Alliance and provides native integration with the commercetools platform.

In case of the CMS the decision between the two finalist PoC solutions was close. In the end ContentStack made the race due to a couple of points that made them stand out:

High customer retention at 98% — companies move to ContentStack, but not away from it.
Price — focusing on business customers, they offer a compelling price model that does scale more reasonably as we rapidly grow.
Offers publishing rules and workflows — makes it possible to have very good control over who and what can be published.
Business customer centric feature roadmap ahead is more suitable to us.

Part 4: The Technical Perspective and How Emma Executes on Innovation

Mon, 04 Jul 2022 16:23:36 GMT

Last update 29/07/2022

Learn more about the key principles for our technical evaluation that we used for our replatforming project at Emma.

After all, we didn’t omit the bottom-up approach entirely. We defined key principles and paradigms of modern, cloud-native software development that the solution candidates would need to follow to match our expectations. Given the fact website delivery performance (e.g. FCP — First-Contentful-Paint , LCP — Largest-Contentful-Paint and others) is critically important for E-Commerce conversion rate and having our globally-spanning, fast-paced business in mind, we wanted to make sure the solutions are able to fulfill our requirements with the least possible effort (esp. in terms of infrastructure). Also, looking into the future, we made sure the technologies we select not only work for E-Commerce today but also can support the challenges of the new and exciting area of Sleep Tech and IoT ahead of us in 2 or 3 years.

To bring together the problem space (our understanding of the business requirements) and the solutions space (the solution candidates), again, we peeked at tech industry analyst Gartner and their recent prediction:

‘By 2023, organizations that have adopted a Composable Commerce approach will outpace the competition by 80% in the speed of new feature implementation.’

— Gartner Research, ‘ Composable Commerce Must Be Adopted for the Future of Applications’ , 2020

According to Sitecore ‘composable commerce is a development approach of selecting best-of-breed commerce components and combining or ‘composing’ them into a custom application built for specific business needs.’. This sounds like a very well-fitting approach for Emma and taking all these perspectives together we defined the following list of key principles for our technical evaluation.

1. Flexibility

At the size of our business and global reach it becomes important that we can use purpose-fit software services flexibly and attach or detach them as needed. With big local differences in certain geographies, it might even make sense to use specially localized solutions for some business domains, even if those would serve redundant needs from a high-level perspective. To support this flexibility of system integrations, an API-first solution design (i.e. all functionality can be triggered and all internal data of a system be consumed using APIs) is key.

Another take on flexibility is how easy or complex it will be to move to another component in terms of technology stacks used, especially programming languages and frameworks. Many of the solution providers provide only proprietary development stacks instead of Open-Source, locking you and your business in.

Therefore, all SaaS solutions (of course there is always one exception — the ERP in our case) and internally developed services MUST be built supporting APIs and using Open-Source tech stacks, while proprietary development stacks explicitly are a MUST NOT.

2. Performance

While monolithic software system designs have the advantage of low complexity, they inherently suffer from bad technical scalability in terms of runtime and persistence distribution because of their centralistic nature. That is where distributed microservices, single-purposed and thus simplistic by design, shine and help to run user-facing workloads closer to the customer / in the CDN and business logic and persistency in message queues, instead of big central databases. Designing this natively on the cloud offers high performance and global distribution with very little infrastructure efforts.

We therefore prefer light-&-lean, microservices-based solutions living distributed on the cloud.

3. Organizational Scalability

Decoupling services horizontally (microservices instead of monolith) and vertically (independently deployable tiers) does not only have technical advantages but also allows to scale-out the work in these different areas to multiple dedicated teams. This enables the organization to parallelize complex software development efforts without tight dependencies, avoiding teams being blocked by other teams.

This is precisely how we want to work.

4. Harmonized Software Development

Decoupling business domains into dedicated teams is a cool thing but if every team follows a different software development process, uses individual CI/CD tools, and builds on different tech stacks, the organization will face highly impactful downsides. It inevitably will lack a common understanding of software quality and will only have very limited opportunity of knowledge sharing across teams and almost no flexibility to move capacities when business priorities are changing.

This is why our project’s Developer Experience workstream defined a new, modern software development process from scratch, defined documentation standards (e.g. C4 architecture model , ADRs , design docs ), evaluated CI/CD tools all engineers use and defined the golden standards and provide blueprints/templates for tech stacks utilized. The SaaS platforms we select would need to accommodate such modern software engineering practices with their tooling.

Also, a factor worth mentioning is talent availability. Some technologies, although maybe technically superior, are especially hard to hire for. We’re in E-Commerce and Sleep Tech, cool stuff but not exotic or extreme like building rocket ships headed to Mars and thus well-known technologies with large available talent pools are our focus.

What a MAtCH!

The technical principles laid out above have a high degree of overlap with the MACH Alliance manifesto — defining a set of 4 basic technical design characteristics (1. Microservices-based, 2. API-first, 3. Cloud-native, 4. Headless). It is no surprise the ultimate selection we took for the SaaS systems to run our business domains as a composable commerce architecture, are solution providers that are members in MACH Alliance.

A sidenote on solution and provider aptitude: While running your small business or startup on a fresh platform of an emerging solution provider or self-hosted Open Source is no problem, moving a considerable-sized business like Emma’s on one is an entirely different thing. Imagine the solution becoming deprecated due to its contributors abandoning it (in case of community-driven Open Source) or the provider company acquired and/or shut down. This is considered a real and critical business risk! That’s why our selection of a solution provider also demands for a certain business stability, especially in terms of funding.

Part 3: Building the new world — with Domain-Driven Design

Sun, 03 Jul 2022 10:28:11 GMT

Last update 01/09/2022

How do a replatforming project? Bottom-up or top-down, inside-out or outside-in? This episode shows you how we did it.

So, what to do? Where to start? You could begin the journey bottom-up or top-down, inside-out or outside-in. There is a multitude of software solutions available for E-Commerce, some modernizing rather old-fashioned tech stacks and architectures but building on decades of experience, some embracing the cloud and applying cutting-edge web-paradigms from scratch. But which one best fits our needs and can run a business with triple-digit million (and possibly soon billions) euro revenues?

We decided to take the top-down plus outside-in approach, i.e., looking at WHAT it is our business needs (outside-in) and designing the architecture before jumping to solutions (top-down). This is more or less what is called ‘domain-driven design’ (DDD) in the tech industry and started off with a simple diagram of all high-level ‘business domains’ (at Gartner coined as PBC — ‘Packaged Business Capabilities’) of our E-Commerce business. We defined a business domain to represent functionality and data specific to the area of business, e.g., the digital storefront, the store management backbone, the order management, the warehouse management, the financial core, etc.

Version 0.1 of our Business Domain Architecture

Coming from that, we set up a project team for re-platforming, comprised of our most senior internal engineers who have been running the business for years, external senior architects and engineers and product managers, to discover what we needed to build. Applying the primary virtue of our overall goals (enable to work concurrently), we set the project team up in multiple work streams, one per business domain plus one for ‘Developer Experience,’ i.e., reinventing the software development process, CI/CD, and infrastructure. This way we created the teams to be decoupled in development, thus minimizing dependencies, yet being closely aligned with each other.

As the timeline for the project would be mid- to long-term (roughly estimated at around 12–18 months), we defined a set of six high-level project steering hygiene questions we would ask ourselves periodically and sequentially every iteration:

Are we working on the right topics?
Are we working on the topics in the right way?
Did we really understand the problem domain before jumping to solutions?
Can we solve this more simplistic?
Is this the right scope for a version 1?
What will it take to make the version 1 replace the legacy system entirely?

It was an effort of almost 3 months to collect and map all the epics and user stories from our business stakeholders to reverse-engineer the business we actually were running on the higher levels, and to depict the outlook of what was coming ahead. However, with that deep understanding of the business we were finally able to evaluate technical solutions. We applied Gartner’s Pace-layered Application Strategy methodology, categorizing systems within the business domains into what are Systems of Record (SoR), System of Differentiation (SoD) and Systems of Innovation (SoI) and strategically decided what to BUY (or these days: RENT as Software-as-a-Service) and what to MAKE (develop ourselves because it yields intellectual value to Emma).

Gartner’s Pace Layered Application Strategy (source: https://cio-wiki.org )

This might sound easier than it is. The complete process of our solutions’ evaluation comprised of extensive market research, collecting dozens of solutions candidates in a longlist and filtering by strategic and architectural selection criteria into a shortlist. Finally, we designed a scoring model to condense down to three solutions per system context to be tested in technical proofs-of-concept (PoCs) — and ran the PoCs to find an ultimate winner.

Having chosen the winning solution, we start building a ‘ Minimal Viable Product ’ (MVP) for each business domain. This is the first iteration (of many) aimed to deliver business value earliest possible and at minimal effort and complexity. It is a standard approach in the Technology Product Management field nowadays, and I encourage everybody to read more about it, e.g. at the Silicon Valley Product Group as the terminology can be misleading and is often misinterpreted.

We’ll pick up how this plays along with our rollout strategy later in ‘ Changing Business — One night at a time .’

Part 2: How to reach business agility in a fast-growing scaleup

Sat, 02 Jul 2022 15:34:48 GMT

Last update 17/01/2023

How do a replatforming project? Bottom-up or top-down, inside-out or outside-in? This episode shows you how we did it.

If you start like Emma did 5 years ago — as a startup — you are in constant ‘survival mode’. You design your IT systems with tools and knowledge available to you to get the business running and growing. You make a lot of decisions that make a lot of sense in the phase you are in. You build your system incrementally, improving what needs to be improved and adding all the things that your growing business needs. In this phase you don’t think about longer-term strategy, about continuous integration and delivery (CI/CD), about architecture patterns or organizational design — you try to keep up with the business and solve the challenges of today and tomorrow. You don’t solve the problems that lie ahead in 1, 3 or 5 years — and that’s good! As said very well and fitting by Donald Knuth:

‘[…] premature optimization is the root of all evil (or at least most of it) in programming.’
— Donald Knuth, Computer Programming as an Art (1974).

However, if your business remains successful, eventually you reach the next phase and become a ‘scale-up’. And now, all the decisions that made sense early as a startup come haunt you as legacy and technical or organizational debt you’ve deliberately built up. When I joined Emma late 2020, we were exactly at that stage: Business was thriving, yet software development was merely reacting, drowning in tickets, and becoming a bottleneck to business development. There were many reasons for that, organizational and processes are part of it but also the technical architecture and infrastructure were big factors.

Remember: Emma is just 6 years old but experienced hypergrowth since its infancy. As the business grew almost exponentially, the organization scaled with it — fortunately linearly. However, what didn’t scale was the technology.

Hypergrowth requires scalability in Business, Organization and Technology

Although running on the (Amazon) cloud, the E-Commerce system used was the legacy version 1 of Magento with many, many customized extensions developed over the years that were implementing ERP-like functionalities, servicing the business as it grew. This, inevitably, accumulated a lot of functionality that doesn’t really provide distinguishing intellectual value to the company, but that, nonetheless, needed to be maintained and operated. At the same time, Emma started to implement a 3rd party ERP-system (Microsoft Dynamics 365 Business Central) to professionalize its operational and financial processes from an end-to-end perspective. I’ll cover the special aspects of repackaging an ERP-system integration in a separate blog post ( see here ).

Looking at it from one level up and depicting the situation like in the illustration below (i.e., categorizing 4 sectors of visible or invisible and positive or negative value contribution), the areas consuming the most capacity were of negative value (‘bug’ and ‘technical debt’) with some also allocated to ‘feature’ work. Obviously, the goal is to focus on both positive value areas and explicitly invest enough in the invisible area of ‘architecture’ to avoid accumulating invisible technical debt in the future.

We are feature+bug+technical debt, but need to be architecture+feature+bug (source: Kruchten, P. 2009)

Reviewing the status quo and anticipating Emma’s highly ambitious business goals, it became apparent that the current technical landscape would not suffice and simple, incremental improvement would not be enough to transform. We needed a radical step ahead — a leap to the next level of technical productivity, enabling global business in 30, 40, 50 or more countries, becoming proactive about business innovation, living on the cloud, and scaling not only technically but even more importantly, organizationally. We needed to enable concurrent business development driven by our country teams — we needed to become Business Agile, thus deprecating the old platform and designing a new, modern one.

Part 1: Intro (in case you don’t know us yet)

Fri, 01 Jul 2022 10:26:39 GMT

Last update 29/07/2022

Say ‘hi’ to Emma! If you don’t know us yet — you should! If you look us up, you’d probably think we’re ‘just another direct-to-consumer mattress company’ but let me assure you: Emma is more!

At Emma, there are 3 main visionary drivers that motivate us:

First, we seek to become the #1 sleep brand — globally. And scaling exponentially in the past 5 years, we are well underway to reach this highly ambitious goal, selling our award-winning products (maybe you even slept on an Emma mattress last night?) to customers in more than 30 countries around the globe. Despite the size of our business (405m EUR rev in 2020; =2.7x of 2019!), Emma remained surprisingly small and efficient (just surpassed the 750-employee count globally).

Secondly, we want to improve people’s sleep and believe we are in the perfect position to do so! With the combination of our in-house sleep research team lead by Dr. Verena Senn (neuroscientist) and understanding of the science behind a good night’s sleep, our proven expertise in designing and producing award-winning mattresses, and the endeavors to go beyond that and explore digital and embedded devices / IoT opportunities, we can make people sleep better — one night at a time.

Thirdly and finally, it’s the team! We are a group of people highly enthusiastic and driven because we love our work and the ones we work with. At Emma, you meet incredibly smart, talented, truly agile (and I don’t mean following SCRUM), and entrepreneurial people, with big ambitions — all following one idea: to collectively succeed! No politics, no bullshit! One team, one dream!

So, that’s us. And given our scaling global footprint, high growth ambitions, and upcoming smart product inventions, we are about to level-up our technology platform to a composable commerce architecture.

That is what this article series is about.

emma-sleep--careers

Engineering Principles

A shared definition of what great engineering looks like. ﻿

A shared definition of what great engineering looks like.

Engineering Principles

Amazon Web Services EFS to S3 migration for a streamlined architecture and enhanced performance

In this article, we share the steps that we took to migrate our storage from Elastic File System to S3 on AWS.

Upgrading Our Frontend: Navigating the migration from Nuxt 2 to Nuxt 3 using Nuxt Bridge

Unveiling the Technological Framework: Emma’s Online Store Architecture

In this article, we share how we're running our online stores for all countries in a micro-service based architecture.

Making the bed for a new promotion engine

In this article, we share how we swapped one of the most critical components of our checkout experience, the promotion engine, with zero downtime.

The Tech Genesis Initiative and Our Onboarding Experience

The Tech Genesis Initiative is Emma’s Internship program to internally grow young talented individuals, to provide them with the right resources to develop into strong software engineers, in line with Emma's DNA, and give them real-world professional experience.

Tech Gathering 2022

Our Tech Gathering took place in Frankfurt near our main office. Almost 70 people (~80% of the Engineering and Product workforce) showed up for these 2 full days, coming from all of Emma’s offices and Tech Hubs in Lisbon, Frankfurt, Hamburg, Berlin, and Munich as individuals from all over Europe.

Part 9: The 5 Must Dos most Leaders fail at

Learn more about my most important take-aways from this replatforming project at Emma — The Sleep Company.

Part 8: Changing Business — One night at a time

Our system migration is a heavy lift . Learn more how we approached to execute our replatforming.

Part 7: Emma’s Composable Commerce Architecture (3 of 3): The MAKE Parts

The proof-of-concepts conducted with the finalist solution candidates ultimately let us decide for the best systems.

Part 6: Emma’s Composable Commerce Architecture (2 of 3): Interfacing with the Enterprise World, raising some eyebrows

The proof-of-concepts conducted w ith the finalist solution candidates ultimately let us decide for the best systems.

Part 5: Emma’s Composable Commerce Architecture (1 of 3): The Cornerstones

Part 4: The Technical Perspective and How Emma Executes on Innovation

Learn more about the key principles for our technical evaluation that we used for our replatforming project at Emma.

Part 3: Building the new world — with Domain-Driven Design

How do a replatforming project? Bottom-up or top-down, inside-out or outside-in? This episode shows you how we did it.

Part 2: How to reach business agility in a fast-growing scaleup

How do a replatforming project? Bottom-up or top-down, inside-out or outside-in? This episode shows you how we did it.

Part 1: Intro (in case you don’t know us yet)

A shared definition of what great engineering looks like.