Meet our engineering team

Days of the future past

In today’s episode

This episode is the first of a series discussing the challenges facing our engineering organization. The series will detail how we adopted agile ways of working, in order to respond faster to business change.
This episode focuses on the state of our engineering organization before the COVID-19 crisis and the beginning of our migration. It highlights the challenges we, as an organization, were facing at this time.

Disclaimer
I Love My Local Farmer is a fictional company inspired by customer interactions with AWS Solutions Architects. Any stories told in this blog are not related to a specific customer. Similarities with any real companies, people, or situations are purely coincidental. Stories in this blog represent the views of the authors and are not endorsed by AWS.

Backs to the wall

My name is Inès Abderrahmane. I am the co-founder and Chief Technology Officer of I Love My Local Farmer. Together with Firmine Yzidee, our Chief Executive Officer, and Jean Dupont, our Chief Operating Officer, we started this adventure more than 10 years ago. I am always amazed to see how our personal interest for fresh and local produce resonated with customer needs and allowed us to grow into a healthy business.

For those of you who saw our Launch post, you know that 2020 has been a tough challenge for us due to the COVID-19 crisis. Our business was running smoothly until then and we were not prepared for lockdown. When it started to spread across Italy, France, Spain and Germany, we were not ready to enable our colleagues to work from home. Enabling them to work from home was an issue, but we quickly realized it was not the most critical one. Our business model relied on customers ordering fresh, local produce on our platform and picking up their orders from local farms. If customers could not pick up their order at farms anymore, who would order on our platform? Our business model was at risk, and our backs were against the wall.

To overcome these two major challenges, we had to reinvent ourselves quickly both from a technical and a business perspective. We had identified that our engineering organization did things well but speed was an issue. Over time, each team had optimized its processes to be good at what it was responsible for. Unfortunately, nobody was responsible for overall optimization. Thus, we fell in a local optimum with quarterly releases and 6-months minimum project timelines.

In the rest of this post, I will present the engineering organization as it was before the COVID-19 crisis: who its stakeholders were, how it was structured, what the team goals were, the challenges faced by each team, and who we partner with internally.

Our stakeholders

Before the beginning of our journey, the customers of the engineering organization were other departments of the company. We referred to them as our stakeholders.

Our main stakeholders are the Business-to-Customer (B2C) Sales team, the Business-to-Business (B2B) Sales team and the Customer Services team. They all owned a part our e-commerce platform. The B2C Sales team was accountable for converting a customer visit on our site into a sale. They optimized the purchase funnel so that the customer would order the largest basket possible from the nearest farm. The B2B Sales team was accountable for onboarding new farmers to our marketplace. They supported farmers so that they made large sales on our marketplace with minimal effort. The Customer Service team was accountable for providing a smooth experience for the customer — from checkout all the way to picking up their order from the farm. They focused on notifying farmers of upcoming orders, as well as ensuring that customers received all the information they needed to pick up their orders. Finally, they handled customer complaints and worked together with farmers to resolve order issues.

We also worked closely with the Marketing team. They owned our corporate website, our online ad campaigns, our e-mailing campaigns and our presence on social networks. In addition, they were responsible for tracking how well they led customers to our marketplace.

Finance and HR departments were also our stakeholders. We must admit they probably did not get as much love as they should from us. We mainly left them in the hands of SAP and Office 365 consultants.

Pre COVID-19, each of our stakeholders focused mostly on their own goals, without much communication between them. We regularly received conflicting change requests from different teams. As a result, dealing with contradictory requirements and ensuring that everyone remained aligned was a major pain point for our engineering team.

Our engineering organization

Our team organizational structure was typical of what you would see in the beginning of the 2010s. It was composed of a Product Management team, a Development team and an IT Operations team.

Product Management

The Product Management team was our primary interface with our stakeholders. They received stakeholder change requests, elicited requirements, and managed the roadmap. They ran buy-or-build analyses with the Development team and the IT operations team. All together, they analyzed change requests according to three criteria:

1. Differentiation: do we need to differentiate from our competitors here?
2. Time-to-Market: how quick do we need to be production ready?
3. Cost: how much does it cost and is it relevant regarding the business criticality?

Depending on the results of the buy-or-build analysis, product managers engaged either the Development team or the IT Operations team to work on a project.

Our Product Management team was responsible for the roadmap and the respect of the timeline. They excelled in these exercises. They knew how to push the engineering team to meet the deadline. They were also hard negotiators to avoid any requirement changes when a project was engaged. Our stakeholders complained that our Product Managers were somewhat inflexible. As we had a 6-month minimum timeline for each project, it was hard for the business to react quickly to unexpected market changes.

Development

The development team was responsible for the customization of our Magento e-commerce platform and all our in-house applications. The work was organized around product line: purchase funnel, product catalog, farmer suggestion/curation, farmer stock management, etc. The team received detailed requirements from product managers, and was organized into two sub-teams.

On one side was our software development team. They were organized in small developer units of about 4 people each. Each unit worked with one product manager at a time. They implemented feature requests in new software releases. Once a release was good to go, they transferred it to our software testing team for validation. They performed well at developing a lot of features to fulfil hard deadlines, but it sometimes led to low quality releases and a lot of back-and-forth with the software testing team. They also struggled to reproduce deployments from development environments in test and production environments.

On the other side was our quality assurance team. They were responsible for validating the quality of each release. They received the requirements from product managers and wrote test plans to validate the releases. During the validation phase, for each issue they discovered, they would file a bug report with all the reproduction steps and transfer it to the development team for correction. They had a 6th sense for detecting bugs. However, they were a bottleneck because of large manual test plans that delayed releases.

We had one major release per quarter. It contained new features or major changes to existing features. We also had one minor release each month. It contained non-critical bug fixes as well as minor changes. Finally, for critical bugs, we had hotfix releases.

IT Operations

The IT Operations teams were accountable for managing Commercial-Off-The-Shelf (COTS) software and Software-as-a-Service applications. They also managed our infrastructure and IT support for all employees. They were split in three sub-teams: the infrastructure team, the IT Support team and the COTS/SaaS team.

The infrastructure team was an in-house team. They managed our network, compute and storage infrastructure in our datacenters and offices. This included installing our hardware, managing our Active Directory infrastructure, and provisioning our development, test and production environments. They managed and closely monitored all our environments — from test to production — while also managing deployment of software to production environments. Deployments to dev and test environments were managed by the development team. The infrastructure team were good at provisioning and managing our infrastructure, but they struggled to anticipate hardware and software failures. They were overwhelmed by the heavy lifting tasks of patching, upgrading our servers and keeping the lights on, and did not have enough time to spend on proactive actions that would have prevented these failures.

The IT support team is our first line of contact when employees need our help, be it ordering new hardware or troubleshooting an issue on their Desktop PC. They directly handle Level 0 and Level 1 support requests. For Level 2 and Level 3 support requests, they route the requests to either the COTS/SaaS team, the infrastructure team, or the development team based on predefined escalation procedures. The COTS/SaaS team manages our Office 365 subscription, our Help Desk SaaS subscription and all the licenses of the COTS software we use like the SAP ones. They worked a lot for the Finance and HR teams. Both the IT support and COTS/SaaS teams are outsourced.

Our main partner: the security organization

I cannot end this story without discussing our trusted advisors: the security organization led by my dear colleague, Qiao Lǐ, Chief Information Security Officer. They backed us for all things related to security. My engineering organization worked closely with them on three topics: security assurance, security engineering and end-user security. They defined what we must do in order to meet compliance expectations and successfully pass internal and external audits. They were accountable for ensuring the safety of customer data and managing the security architecture of our solutions. They also administered the security of our internal IT systems so that our own data was kept secure.

However, even though they were proficient at their jobs, we as the engineering team typically consulted them too late in our engineering process. More often than one would expect, we had to perform major refactoring because we did not harden our implementation enough in the beginning of development.

Our organizational challenges at a glance

Before the crisis, we had already identified a few challenges in front of us. Our release cadence was too slow. It was impacting our time-to-market and even more our time-to-feedback.

There were several reasons for this. As you may have spotted, our organization was quite vertical and siloed. Our teams were performing very well in their own specific areas. Unfortunately, nobody was responsible for the overall user experience from either a business or technical perspective. Moreover, the communication between our stakeholders and our organization was low and restricted to the Product Management team, leading to a lot of misunderstanding and back-and-forth communication.

Having our backs to the wall forced us to evolve, so we evolved. We already had ideas for some improvements such as leveraging Agile methodologies or investigating solutions to make deployments more replicable in order to speed up our development life cycle. But, they were only parts of the transformation we are going through.

In the next episode, we will highlight where we took inspiration for modernizing our organization.