2 Weeks in the Life of an E-commerce Tech Team

Before discussing what it’s like to work in e-commerce there is a point worth addressing. 

How do you actually spell it?

The true answer is no one knows (some people might argue this isn’t true at all). In my opinion, it should be just like email is to mail - commerce to ecommerce. Alas, spell checkers refuse to agree with me on this, industry experts commenting on Linkedin continue to muddy the waters even further with their own variations and as is normal with this subject, here we go before the article has even started and wasted a full paragraph discussing this trivial yet belligerent issue.

Get on with it, Tom!

Sorry, yes here we go. Ecommerce can be loosely defined as selling online. Given the penetration of digital activity in virtually everything in life, almost any kind of trader is in some way also in the e-commerce business.

From a Techerds point of view, we can keep this more narrow. Most of the techerds community are looking for a route into technology. In this case, we’re reviewing a subset of technology, so we’ll focus on large enterprises that have websites with products for sale. These are not the majority of e-commerce players but they capture the majority of money made in e-commerce. This point is important because an e-commerce business that makes lots of money is an e-commerce business that invests heavily in its technology team (I hope your ears pricked on that point).

#1 Team Structure

Typically an e-commerce team will have a team structure matching the below diagram. Consider this to be a loosely adhered to ratio. For example, in our diagram, we have 3 developers and 1 tester. We would likely reach 5 or 6 developers before adding another tester. Some businesses will have multiples of this number, the important point to note is this is a ratio.

#2 Sprints

The team will usually work on projects broken down into chunks of time such as 2 weeks. This will most likely be referred to as a Sprint.

#3 Feature lifecycle

A feature that eventually gets worked on during the sprint goes through a little journey before reaching the developers.

#4 Sprint Goal

By the time a new Sprint has started, there should be a number of tickets that have a combined complexity or time estimate matching the capabilities of the team undertaking them. This can be referred to as the sprint goal. Over the course of many sprints, the team will become more in tune with what they are able to complete as well as hopefully more productive which tends to lead to completing more of the work taken into a sprint (less unfinished tickets) as well as gradually increasing the number of tickets they complete over the duration of a sprint. This process is mostly maintained and optimised via the sprint planning, refinement and the retrospective sessions shown above. All three of these meetings lead to the final conclusion ahead of a sprint starting with what tickets will be brought into a new sprint.

#5 Features

Most of the features that make it into a sprint will be backend or frontend. Put in simple terms, the backend does the calculation and the frontend makes it look pretty. This description has become a little outdated due to advances in some frontend technologies but can be considered broadly reflective of reality. In e-commerce, the frontend tasks will constantly focus on the product pages, category pages and checkout. The backend tickets will be concerned with tweaking or changing the data passed to the frontend or making the page loads and response times faster. Usually, the content pages will be powered with a CMS (content management system) which non-technical teams can administer.

#6  Unplanned Tasks

Every so often an ad-hoc task will arise that hasn’t been planned for but must be completed urgently. I can promise you that 90% of the time this will be for the marketing team who didn’t think to tell the technology team they were planning to run some promotion. In order to achieve this, a ticket intended for the current sprint may have to be removed. This should be a relatively stress-free exercise but it’s important to note that not everything goes to plan and teams must be nimble enough to handle this type of thing. 

#7 Priority 1s

Not dissimilar to our example of the marketing team making life difficult for the technology team, sometimes the technology team is firmly to blame (blaming is rarely conducive to fixing issues). For example, an inadequately tested piece of code reaches the production environment and we have a critical issue preventing customers from purchasing on the site. In this scenario, all suitable members of the team must be diverted to resolve this as it’s potentially stopping the company from making any money. This will undoubtedly have a knock-on effect on the success of the sprint. The time and place for attempting to prevent this from happening again are in the sprint retrospective. Here, with cool heads and after some time has passed to reflect, the team can attempt to identify changes to their process that must be implemented if they are going to avoid this happening again. However, critical issues will always be with you and are very difficult to completely remove.