“Tech Radars: the best thing since sliced bread!” Okay, that might be an over-exaggeration, but they are on the rise, and for a good reason. A Tech Radar gives a clear overview of your technologies and their status. At Picnic, it is essential for several internal and external use cases. Internally, it helps facilitate communication across our teams, enabling us to more easily communicate the current and future status of a technology and brainstorm about it. Externally, it can assist with recruitment — new hires know what they are signing up for. Our colleague, Philip Leonard, has written extensively about our tech radar in this post: Picnic Tech Radars.  

Due to our rapid growth both as a business and as a tech team, it is crucial that we keep our technology up to date in order to fit our ever-expanding use cases. This means we continuously review our tech stack through our Tech Radar. Hardly anything within our tech stack is more than 2 years old! Proposing to adopt a technology is only the beginning, though. There is another side to this, which is the procedure of implementing it. It goes beyond simply selecting the vendor you like and purchasing its off-the-shelf products.

In this blog post, I’ll dive into the mind of an Analyst in Picnic’s Tech team, and will outline the steps required to select the most suitable vendors for Picnic. I will start by examining the most common trigger for this process — our rapid growth — and then decide whether to buy or build a solution. I will then go through our scalable approach to evaluate these options and implement the most desirable. Finally, I will share Picnic’s stance on creating and maintaining partnerships.

Growth

Five years ago Picnic had just 35 employees and delivered groceries to a few thousand households per week in a handful of Dutch cities. Now, we have 200+ people in the Tech team alone, and more than 10,000 employees across Picnic as a whole. We complete over 250,000 deliveries per week across 3 countries. In such a rapidly changing environment, it is crucial that our systems are able to cope. We need to adjust and review our capabilities constantly to achieve three goals:

1. Make our systems scalable
2. Ensure a good UX for our end users
3. Maintain a high development speed

Over the years, we have often outgrown the capacity that our partners provide for us. An example of this is our Continuous Integration (CI) system. This is a solution that automatically checks whether a piece of code can be integrated into the master code safely. This is bundled in a build. CI allows several software developers to work together on a project with limited problems of duplicate or conflicting work. Sounds awesome right? That’s because it is! What was less awesome though, was that the queues of builds would fill up rapidly during the day. As a consequence, the build time was ever-increasing. It was time for a change. After an extensive investigation and migration, we partnered up with TeamCity Cloud. We were able to decrease the average build time across all builds from 25 minutes to just under 10 minutes! More importantly, with this new setup, we are comfortable we can scale far beyond our current size once again.

Build or buy?

So, we know we need to introduce a new technology — what next? Well, first let’s answer the question: “build or buy?”. We are not the first to write a blog about this, so we will highlight our perspective and experience on the matter, rather than going through the entire decision-making process.

At Picnic, we think of ourselves as “Tech’s answer to groceries”. This means that our entire business is based on creating a unique proposition: a smooth order and an efficient, affordable last-mile delivery strategy. As such, we work on projects and initiatives that improve or expand this unique proposition. For the build vs. buy debate, we ask ourselves two questions:

• Does it contribute significantly to our unique proposition?
• Can we really do it better than what is available?

I can dive a little deeper into this in the following three examples:

1. Our Warehouse Management System
   This system instructs our workers on the warehouse floor what products to pick for our customers and where to find them. It is thus essential to our unique way of working and delivering to our customers. Therefore, this system should fit in seamlessly with our other systems. While there are solutions available for this purpose on the market, they do not perform well for our specific use case. As such we built our own solution — a team of 15 currently maintains and improves it.
2. Our HR management system
   In this system, we incorporate employees’ information to make sure we can pay them and much more. This does not directly contribute to smooth ordering or the supply chain. As such, the answer to the first question is no. There are furthermore several companies that offer such a solution that does the job very well. As such, we bought an external system.
3. Our incident management tooling
   This is a challenge we are currently working on. It is critical that we quickly update our customers when unforeseen events arise. So, for the first question, the answer is a yes. Can we do it better than we could with tools that are currently available on the market? We don’t know yet. Currently, we use a self-built solution that has held up until now: Mr. Murphy (yes, in reference to Murphy’s law — it’s quite fitting). However, the cracks are starting to show, and we are currently evaluating whether to put in the effort to upgrade it to a level we are happy with. In parallel, we are looking at potential external solutions. The final verdict on whether to build or buy is not yet out.

Scalable Framework

Recently, we designed an approach that facilitates the process of vendor selection. It consists of a set of best practices and guidelines, as well as a checklist and toolkit. This is especially useful in a project such as vendor selection where you have many balls to juggle. Let’s say you are running on schedule for a large project, but midway through something turns up you forgot to take into account. Now you are behind schedule. That is obviously not what you want. The framework we developed solves this for both large and small projects. You can just copy and paste a default project plan, adjust it to your situation, and check off every item on the list.

It includes the following:

• Involve key (technology) stakeholders
• Set up requirements and success criteria in a collaborative effort
• Evaluate and trial the options in a fair and transparent manner
• Involve business, security, legal, and procurement teams, and build momentum
• Implement the solution

With this framework, every member of the tech team can start such a project and lead it to a successful conclusion. Through this, we hope to scale into the future while keeping a slim organization around this process. As analysts in Tech, we aim to be in an advisory and supportive role for these projects, rather than being on the frontlines.

Partnership

We have a trigger for a new technology. We have evaluated build vs. buy. And we have found a great solution. It seems like we are done, right? Well, not if we decided to buy. We also need to find an effective partnership. While the previous paragraph focuses on the process, we also need to consider who we will work with — we’re building a new long-term relationship, so we’d better make it a love story.

For a strong relationship, you need an initial spark, but also interest in each other after that. In our vendor selection, we do something similar — we look at the current product, but also the future roadmap. What innovations does this partner bring to the table and how can we benefit from that?

All relationships take work, and the same goes for our partnerships — both parties can help each other out, though. We give them feedback and incentivize them to continuously improve. However, sometimes we change the way of working with their solution based on features or changes that our partners introduce.

Takeaways

Growing is hard! Scaling up exponentially is our ambition, our goal, and so far also a reality. It comes with its own unique set of challenges. Among these is the constant need to reevaluate our partnerships and ensure they can grow with us, or replace them if required. Hopefully, this post gave you some insights into how we tackle this challenge. What are the key takeaways?

• Be critical of the process, analysis, and conclusions. Through doing this we improved the process and came to the insights shared in this blog post.
• Ensure you foster a collaborative effort between different teams. We want solutions that the intended users want to adopt, and for this, you need to involve multiple teams. It is important to keep the momentum going by setting clear deadlines and lines of communication.
• Evaluate how you want to tackle your partnerships. Do you grow and work together, or is there little to be gained from a stronger collaboration?

These three learnings were important in setting up this framework, with the main purpose to keep our tech radar up to date and ensure any changes in the radar are implemented properly.

Interested in joining our team and working on awesome projects like these? Check out our current Tech Analyst vacancies.