Marley Spoon: A Look into Their Stack and Team Structure

Over the past eleven months, more than 1,600 startups from around the world have built their infrastructure on DigitalOcean through Hatch, our global incubator program designed to help startups as they scale. Launched in 2016, the goal of the program is to help support the next generation of startups get their products off the ground.

Marley Spoon, a subscription meal kit company based in Berlin and Hatch startup, sees infrastructure as an integral part of every engineer’s workflow. “We are trying to build a team where people don’t feel responsible just for a small bit, but we want to build a team where people feel responsible for the whole architecture,” says Stefano Zanella, Head of Software Engineering at Marley Spoon. “In order to do this, we believe that people need to know how the system works.”

In this interview, Zanella gives us a glimpse into Marley Spoon’s unique engineering team structure, and the technologies they use to power both their customer-facing platform and the internal-facing production and distribution platform. The following has been transcribed from our Deep End podcast, and adapted for this blog post.

DigitalOcean: How do you model your engineering teams?

Stefano Zanella: Our teams are shaped around user flows to some extent. We have currently four teams: three teams are product teams—they are related to the product itself—and one team actually takes care of the platform for the infrastructure.

The [first] three teams, we shape them around the user flow. So, we have a team that takes care of the new customers. We call it the acquisition team because they focus mostly on marketing, but they also provide data insights, manage the customer experience for new customers, shorten the subscription flow, and so on.

Then we have a team that focuses on the recurring customers. It’s the team that takes care of the functionality like adding to an order, posing new subscriptions, keeping a delivery, changing your address, changing the time that you want your box at home, etc.

And then the third team actually takes care of what we call the “back office” in the sense that we do it in our own production centers; we have warehouses all across the world. We have a tool that tracks how many orders need to be done, when, where, and [by] which warehouse. We have them organize the batches because we work a lot with shippers and we try to be just in time, because of course the food is fresh and we want to keep it just like that. So this team takes care of all the production-related issues.

And how do you organize these teams? Do you have teams with maybe product managers, designers, engineers in the same group? Or [do] you isolate teams depending on their skill set or area of expertise?

The interesting thing about Marley Spoon is that the situation is always changing. We are very proud of the fact that we believe in owning the process and changing the process and structure as we see fit.

When we started we had an engineering team and a product team. Then, at some point, we realized that the communication structure wasn’t working well enough for us to be productive and effective enough. So we actually put the product managers inside the [engineering] teams. Then, we [also] figured out that the relationship with the designers wasn’t good enough, so we put the designers inside the team as well.

For a certain period of time, we had teams [that] were functional from my point of view, and now since we are growing a lot, the team is growing, and we have different needs. We are [now] focusing on product managers aligning with the rest of the business, rather than with engineers because the relationship with engineers is really good right now. We moved the product team outside of the teams again, so they are their own team because we want them to also work as a team, not just be disconnected. We assign specific product managers to specific departments and then internally, the team shuffles the work to the engineering team. But it’s a situation that can change every time, because it really depends on where we see the problems.

Going down the technology side of things, what’s your stack and architecture right now? Or maybe you want to talk about how Marley Spoon evolved?

Well, actually let me answer the last part of your question, because I think it’s really interesting speaking about the engineers. So, we do believe that the main role of an engineer is not writing code, but it's actually running the system.

And in order to do this, we believe that people need to know how the system works. They need to have a feeling of how the whole system is working. From that point of view, we don’t see all of the teams related to technology, for example. We use a workflow based on the Kanban workflow. Since it’s based on Kanban, every time somebody runs out of work, they are free to pick new work from the backlog. And the product managers manage the backlog, which means that whoever is free should pick stuff from the top because that’s the most important thing to do.

We don’t have this clear distinction between backend and frontend developers. We do have people that are more skilled at frontend or backend, but we try to broaden their scope of action all the time. So, from that point of view, we try to help each other a lot because we believe that’s the best way to grow.

Getting back to the stack question, what are the technologies you have in your architecture?

So, mainly we are a Ruby-based company. We use Rails mainly for our web apps. We have a couple of projects that are pure Ruby because they are projects for background processing. We started them in Ruby, but we are considering switching to a different technology.

We are currently in the process of upgrading the stack because we were using Backbone as a library and Coffeescript as a language because that was what was coming out with default Rails 4. Now we are slowly moving toward React because we see a lot of traction outside and inside the team as well. So, we would like to give it a try.

We hope that will also help us shape and improve our relationship with the designers, for example. Then we have a small a command line tool, for our Kanban board because we wrote it ourselves. We wrote our own Kanban board because we like to have a tool that can evolve in the process. And we wrote a very little command line tool so that you can create tickets and move tickets around from the command line.

Tune into the full interview on our podcast, or learn more about our Hatch program today.

Hollie Haggans heads up Global Partnerships for DigitalOcean’s Hatch program. She is passionate about startups and cold brew coffee. Get in touch with questions at hatch@digitalocean.com.