‍

Engineering managers Peter Paul van de Beek and Peter Brouwers joined us to share some wisdom: how they navigate challenges and continually create a great engineering culture at Bol.com.

Peter Paul has a background as an architect and software engineer, allowing him deep insight into how to lead in tech, and how to scale a massive retail platform. He is amazed by the growth he witnesses. “There is so much IT and tech under the platform,” he says. “To a lot of people it looks like “just a website”. But if you connect it to the sheer volume of packages we deliver, the different algorithms and so forth, it’s awesome to see what we do”.

Peter Brouwers also has a long and insightful history at Bol.com. In 2015 he became an engineering manager. Before that he was involved in IT development and operation. Now he specializes in innovation, working with development teams. He enjoys the tension between innovation and the operation, comprising 700 engineers, 11 million customers, 40,000 sellers, and chains of massive warehouses.

Together with Hackages founder Davy Engone and the audience, Peter Paul and Peter Brouwers had a short chat. Here is what they had to say!

Davy: Firstly, we want to know how you define Bol.com’s engineering culture.

Peter Paul: Our engineering culture builds on the existing Bol.com culture. We’ve been around for over 20 years. But that startup vibe of wanting to move forward, staying innovative, and solving new problems is really part of our culture. We want to do new things on both the tech and commercial operation sides.

Within all our ambitions, we never lose sight of the people. There has to be room for people to evolve themselves, to learn new things, and to explore new opportunities, everywhere across Bol.com. We offer some possibilities there, and our jobs as engineering managers are to help people to see these possibilities and encourage them to explore for themselves.

Peter Brouwers: Fail fast is one of our principles. Well, that depends on what area it’s in (if it’s in the warehouse, it’s a problem). But on the tech side, if you have a block in the webshop for example, you can do AB testing and innovate solutions. What is important is autonomy. We work together with builders to see what should be done, what should be improved, and then the builders and platform teams deliver it to production themselves.

We saw this five years ago, when we wanted to get results on a project. We had ideas but couldn’t lift off. Then we discovered we needed the teams to ask themselves “what do you want to achieve?” Once they defined what they wanted to do, we got traction and soon new results.

‍

Davy: You both joined over eight years ago. So many things happened in the last decade that you had to be really on top of. How did you keep engineers involved on a daily basis? How did the engineering culture adapt, and what is a challenge you faced in the last years?

Peter Paul: With our growth and scaling, a problem that isn’t big in year one is big in year three and starts to affect many customers or partners. Such a problem becomes urgent to solve, and we have to invent new functionalities to do this. Or our data volume will have doubled. How do we deal with that? If traffic doubles (double the orders), when you move to smaller components, you have to speed up traffic by transitioning to microservices.

Every two to three years there are new business and tech problems to solve. My concern is how to support teams to be able to accommodate these rapid changes.

Davy: Each team can handle being a startup within the organization. But how to maintain the unified culture that still fits the overall goal of the organization?

Peter Paul: We first moved to OKRs [Objectives and Key Results]. We had five or six directions (depending on year) given by our board, and within that framework, every product and domain of products must decide what that means for their individual products.

For example, “If having more traffic from sources other than Google is important, then we have to build a better search engine so people can actually find what they’re looking for on our platform”. We come up with several purposes, and then the team working on the search engine has to come up with their own goals and steps to achieve that mission. The goals cascade down the different parts of the organization, and the solutions go up. The minds of engineers are triggered, and we move forward.

Davy: You often see this relation between autonomy and innovation. How do you deal with the difference in mindsets between engineers who want to experiment and ship immediately, and those who want to first perfect it?

Peter Brouwers: Being an Agile company, we want fast feedback from customers and partners. We ship the minimum viable product ASAP and look at the outcome. Then we adapt it. If it needs to be perfect before shipping, that takes too much time before getting our feedback. So we aim to be as fast as possible, within the limits of being safe.

‍

Davy: What kind of activities or processes do you do to maintain your engineering culture?

Peter Paul:  As engineering managers, we constantly work for opportunities to stimulate that culture. In a way, culture comes from the questions you ask and the answers you consistently provide to those questions. You have to get those basics correctly and consistently. And you have to undertake activities that strengthen communities. We host internal talks (by Bol engineers), yearly space summits (a day with activities, internal summits, meetups, and external speakers), and host podcasts. Our goal is to keep the spirit of enterprising alive, of discovering new things and sharing knowledge.

Davy: How do you balance feature delivery versus tech debt? How do you keep the "factory floor" tidy and functioning, while at the same time delivering value to end users?

Peter Brouwers: We see it often: If you want to go fast, you take shortcuts and end up with tech debt. Tech debt is part of the process and partly owned by the product owner.

You have to meet with the product owner to tell them, “this isn’t harming us now, but it will in the future”. If it becomes a bigger problem, it needs to be addressed as an innovation as well. Reliability is one of the key functionalities, and tech debt will block that as well. Address it together with engineers, product owners, and businesspeople to improve it and solve it.

Peter Paul:  You can also see some of the consequences of tech debt coming. For example, depreciation teams can announce it one to two years in advance. My request is to address it ASAP, so we have the freedom to choose multiple options to solve it before it becomes a burden. In the Agile approach, this should happen as soon as possible.

For example, two years ago some software engineers got really bored: Where’s my order? Can you query the database for this? And so on. So we made data available for all users to see, and dashboards for it to be explained. This took the load off the engineers and put it on users, giving engineers room to try out new tech and keep things up to date. 

‍

Davy: How do you keep engineers engaged during the pandemic when working remote?

Peter Browers: In terms of engagement, it’s important to constantly understand what you’re working on. A former CEO said to me, if you’re not able to explain what your contribution to customers or sellers is anymore, come by and let’s have a talk. That’s what we try to explain to the teams as well. Next to that, we check in with some social talk in the pandemic, to find out how people are doing behind their screens.

To maintain our culture, we inspire our teams with stories of what other departments are doing. Last week we had Inspiration Day. A digital platform was created where you can go into different locations and check out presentations or interviews like a physical summit. It was great to see and hear that engagement.

‍

Davy: What would you like to hear during a job interview to say, "wow, this guy matches our business culture"?

Peter Paul: There are a few things that I would be looking for in the interview. We want to see whether you really understand Agile. Anything in your answers that smells like hierarchy, that you love hierarchy or solve problems in a hierarchical way, will disqualify you.

The other thing I’m looking for is the initiative to come up with a new framework, to speed up things in the building pipeline, to speed up code testing. Even if it doesn’t go fluently, you have the persistence to get your team there. You can handle feedback and are an open communicator. You need to be resilient to adapt to new situations.

This helped us especially in the beginning of the pandemic. We had a culture shock, but could easily transition to our new paradigm because our engineers are selected for resilience and capacity to quickly adapt. And you’ve got to code really well, of course.

Peter Brouwers: It’s also really important to have the customer focus, also for the partner or warehouse we’re working with. You have to be able to explain what you’re working on, and give pushback to the party requesting the product, such as “why are we doing this? Does this add the value you’re seeking?” You must be able to add solutions and value.

‍

Davy: Is there someone out there who inspires you in work or life, from whom you would want to hear about engineering culture?

Peter Brouwers: I’m a fan of Formula 1, not just the race, but also what’s going on behind the screen. How do they enable the teams of engineers to bring new features onto the car? If we could do something similar in our company, that would be great.

Peter Paul: I think that even for engineers it’s good to keep this open-mindedness. I would pick someone who could tell me about psychological health and openness and giving good feedback. These skills, the communication skills, ability to receive feedback, and open mind would really allow people to move forward, besides the technical things.

‍

‍

Check out the visual notes of this webinar:

‍