Sebastian is responsible for Tech and Product on the AboutYou management board. Here, he talks to Alexander Graf of Spryker about what it actually means to be “a tech-driven company” now that so many retail outfits are calling themselves just that. He also gives an insight into how to build a shop system of the size of AboutYou and about what marks out good code.
“It is absolutely crucial that our people understand what they are building.“
Alex: To start off with, tell me about how you guys went about setting up AboutYou.
Sebastian: We’re a greenfield start up, so we started with nothing, nada, zilch. That meant our first focus was developing the products we needed, fast. We started with the shop and built a back-end system in parallel to do order handling; this system is able to send, process, and interpret article data and stocks. We also created a purchasing management system with which can visualise and then optimise our purchasing processes.
From Day One, our aim was to self-build everything that optimises processes and so gives us an edge — i.e. pretty much the whole infrastructure. We started with a team of 10 in IT, and now we’re up to around 100 tech staff. That means that almost all of our core competencies are in house. We develop in teams using agile methodology, giving us short integration timescales and allowing us to concentrate on creating the best products for our customers.
Alex: But how did you know which competencies you were going to need? And building everything from scratch yourself is biting off a lot in one go (we had that discussion when setting up Spryker): your own PIM system, your own shop… To what degree is your infrastructure really unique?
Sebastian: All of the things that the end user sees — the shop, the mobile app, etc. — have to be within our control. Even just to be able to optimise the user experience for our customers, we need to be able to develop these user interfaces ourselves. In terms of back-end systems, we thought about what we would need — purchasing interfaces, inventory management, other internal processes; around 8–10 systems in total — and, although the customer doesn’t see them, we developed them internally, too.
Alex: Do you have a proprietary mobile system, too?
Sebastian: Of course: desktop, mobile site, and mobile app are our customer interfaces. Our check-out system, too, is a self-built product, because that is part of the user experience as well.
Alex: Your co-founder, Tarek Müller, says that there are two units that drive the business: marketing (his area) and IT (your area); the rest — purchasing, finance, etc. — follows on. Is that, in the simplest of terms, the secret of your success?
Sebastian: We believe very strongly that that is the case. All three areas — Operations & Finance, Marketing & Brands, Tech & Product — need people who feel responsible for them, and in our case, that means Hannes Wiese, Tarek Müller, and myself.
Our total staff is now over 300, so one third of our workforce is truly tech-focussed. The other two thirds are split between marketing and operations, but we have techies there, too: attribution, web tracking, analytics, etc. Marketing makes the decisions about what we should be doing, and then we in IT think about how it is going to be done.
This is an important point because we have a very harmonious systems landscape and we cannot allow areas of it to become silos in which things become very dependent on the technological competencies of single people. If that kind of fracturing takes place, you end up with system that you can’t maintain further down the line.
Alex: What is your own relationship to the tech stacks? And how much PHP do you use?
Sebastian: Well, the important thing is not really the programming language we use, but rather the architecture. Nevertheless, we do you use a lot of PHP, if for no other reason than that there are lots of PHP developers out there; also, we like to have as many people speaking the same language as possible. That way, everyone in the department can get to grips with every part of the product if necessary, allowing us to set up and change teams quickly; and when we onboard people, they are ready to start work in three or four days — which is why we try and keep our source code as easy to understand as possible.
Alex: That’s easier said than done, though, isn’t it? At Spryker, we are providing a framework, so we obviously spend an awful lot of time making sure that our code is solid and clean. You guys have day-to-day operations to deal with, though. How do you make sure your code stays to true to your principles?
Sebastian: It’s simple: we’re very strict. We have really comprehensive guidelines which start by outlining our philosophy about writing software. What do we mean when we say “good code”? What are our expectations in terms of maintenance and quality? We try to pass this on to new team members from the first day of onboarding, and we’re quite restrictive about how code should look.
Our definitions of good code aren’t necessarily what you’d find in a standard software development manual, either. For example, we think it’s very important to be able to define separate units of code so that everyone can see what each and every piece of it is doing. Our code has to be as simple as possible; its function should be obvious to avoid everyone having to keep going back to the documentation every time they look at it; it needs to be easily navigable. That means that any complexity there is must be limited to specific capsules of code to the greatest possible extent.
Not that we have a board signing off every line of new code before it goes live: speed is very important to us. What we do have, though, are classic review meetings for code feedback. In every unit, we have a tech lead — so that’s a total of six — and one, two or three lead developers within every unit.
Alex: Does your approach make things more difficult for self-taught TYPO3 & WordPress types when they start with you?
Sebastian: No, I don’t think that’s the case. The goal is for everyone to be able to understand our code quickly, whatever their professional background. Our code isn’t rocket science: it’s quite accessible, in fact. Our motto is that easy source code is good source code.
Alex: There’s this theory going round that everyone needs to completely rebuild every five years in any case, because neither you nor I know how wholesale and retail will look even in the near future. Have you had to rebuild yet? Or did you create such a solid foundation at the start that you’ve been building on it ever since?
Sebastian: We’ve had to do complete rebuilds, mainly in the light of things we’ve learned: processes, article data, merchant integration… At the beginning, we were focussed very strongly on micro-services. That wasn’t necessarily wrong, either. What we soon realised was that we’d carved up some of the applications in the wrong way, though, leaving us with process chains which had to go through three or four micro-services in order to get a finished product at the end.
We realised that we had to monitor every single step in the process, and this monitoring alone was fiendishly complex because, for every single alteration to every product, you had to search and then adapt each and every individual system.
The second thing we learned was about scalability. Two years ago, we got “crazy Christmas” and did a huge amount of business over the holidays. This rush showed up some shop-side potential for improvement in terms of real-time availability and handling. So we redesigned the whole system from scratch, using a small team and shipping the whole thing with a big bang — and replacing the old system with it. It was a good decision.
Alex: How do you organise your IT people? Before About You, you built up an agency in Darmstadt; then you came up to Hamburg and had 10 people in a room to start with. Now, at that size, you can probably just shout across the office; today, though, you’ve got six units and a whole army of developers. How do you manage them? And where does the impetus come from? Does Marketing say what it needs and then let you make it?
Sebastian: We work with a unit structure because our aim is to be flexible, and because we have 12–15 teams working agile at any one time, it works. The problem is that it is very difficult to predict focal issues: what will be at the top of the agenda in terms of personalisation in, say, one month’s time? That has a lot of effect on how we organise teams.
So we decided to run on units which each cover a specific topic area. These areas could be something like “Devices” or “Mobile”, or “Back-end processes” generally; “Check-out/payment/processing” would be another example. Within each unit, we then have a tech lead and a product lead. The latter is the leadership personality who sets lists of priorities and interacts with stakeholders — of which each unit has many: purchasing, marketing, management (i.e. us). We work with the product lead on the priorities, and then discuss things with the tech lead.
The tech lead is then responsible for implementing what is decided in accordance with our code principles; the aim is to build in such a way as we (hopefully) won’t have to bin the result a few months down the line. One rung below unit-level are the circles, which are comparable to teams. They work on areas like the desktop page, or — even more specifically — buying processes or inspiration on the desktop page. They are usually scrum-size, and as far as we are concerned, it’s smart to keep dev teams small. Otherwise, you can soon fall victim to Brooke’s Law: i.e. if you order a pizza from a pizzeria and it takes 15 minutes, you can’t get it any faster by getting another three pizza chefs on the job. In fact, that will make it take even longer.
That’s a slightly simplistic comparison, for sure, but the speed of a development project does not correlate to the number of bodies you throw at the job. So it’s about smaller, more flexible teams; the number of people we have in each team is not fixed, though, and depends on the unit. And every nine months, we carry out a big retrospective, looking at the focus topics for each unit and then redrawing the circles to cover these areas. Depending on the requirements, we can end up with everything from two to five circles.
Alex: Once you’ve done that work, is there any way you could take specific packages like “Desktop” or “Mobile”, or perhaps whole products like your Edited project, and transfer them to other sites away from Hamburg?
Sebastian: We don’t think so. Yes, there are discrete packages of work that can be split off from a development point of view; but if something is developed that works well in one area, the likelihood is that we will end up applying it throughout the whole product. For that reason alone, I would always prefer to up the number of developers I have here than to open a new office somewhere. It’s easy to underestimate the importance of personal communication, too, but I think its decisive. In environments in which not all products have to be linked up with each other — e.g. WordPress — it’s probably best to work with a range of teams worldwide. At AboutYou, though, that wouldn’t work.
Alex: So as an online pure-play, you guys build your business proposition around marketing and product data as core competencies. The rest — to put no too fine a point on it — all comes under “Other” and Hannes can take care of it. Looking at analogue companies, though, it’s IT that is the annoyingly pricey cost centre taken care of by the person with the “Other” brief. The IT teams aren’t small by any means, but they don’t lead. Their role is simply to make sure that everything goes online for as small a budget as possible.
Do you think legacy organisations can simply adopt the kind of flexible organisational structure that you guys have, or do they have to start afresh? AboutYou is part of the Otto Group, which is based on an established model from the analogue world: is that something you talk about with other parts of the Group?
Sebastian: I think it varies from company to company. One of the biggest drivers is the size of the tech team: at my former company, CreativeTask, where we had 10–15 people, I could literally go walkabout and “shout across the office”, as you put it earlier. In a company with 50–200 staff, though, you need different processes in order to work efficiently; and if you’ve got 200 tech employees within an even larger organisation, then you need yet another set of processes.
So if you’re asking me, there is no one single way of doing things that can be stamped onto every company. What there is, though, is a set of core disciplines that each company needs to retain mastery of in order to succeed. One these disciplines is organisational structure. It makes sense for us to work in small teams who deal with specific lists of priorities; that gives us a really granular handle on things.
Alex: But don’t lots of issues affect more than one area? Or how many can you actually resolve completely at a circle level? And how often do you release the results? How do you evaluate them?
Sebastian: Almost all of the topics — personalisation, article data, search, business intelligence — affect more than one circle. It’s about breaking down complex issues into modular assignments and then coordinating these packages across the circles. We don’t usually have a big board somewhere with everything pinned on it, but our job is definitely to keep an overview.
Alex: When I was still at Otto, we used to have one of those massive tracking boards for each of the major relaunches (there was one every three to four years). I used to be afraid of making feature requests because the answer was always: “We go live in three quarters!” There was no team spirit. So you use small teams and work in small iterations…
Sebastian: Yes, but I can’t tell you if that is applicable to organisations many times our size — and that is at the core of what we’ve learned at AboutYou over the last three years. The next issue is cycles: we’ve shortened ours from three-four months down to micro-releases on an almost daily basis.
Another thing that is very important is the overall environment, because software development is not just coding. It’s also a matter of server architecture, interface documentation, deployment and testing. If the whole package isn’t working, that can stop development projects dead in their tracks. It’s also crucial for everyone to have access to the most up-to-date data sets; no-one anywhere in the process should have to use old data.
And yet another important point: requirements management. We are focussing on optimising the way requirements are written: there is a big difference between how requests for front-end interfaces are formulated and how back-end process requests need to be written. The latter, especially, need to be crafted in such a way as the developer can understand the whole process. There is a clear link between how the ticket is written and how fast or how well the requirement gets implemented.
In view of that, we’ve set up a process management department, and as well as making sure that Kanban and scrum development principles are kept to within each of the individual circles, it is also responsible for overseeing how requests are written and presented. This department does testing, too, by giving Circle A one version and Circle B another, and looking to see whether there is a notable differential in speed or quality. The result for us has been that this is a really effective control — and why wouldn’t it be? After all, tickets tell the developers what to do. If they’re too imprecise, the developers will lose a lot of time trying to understand them or trying to implement all of the possible cases.
Alex: Where do most of your tickets come from? Marketing? Purchasing? And do you hold up the best-written requests as examples for everyone to follow?
Sebastian: It depends on the system. For the purchasing interfaces, the people who work with it are the stakeholders and so they’re also the people who generate the most tickets. If we’re talking back end, though, or components such as desktop and mobile, then the impetus is more likely to come from the tech area of the business itself, and so 80–90% of what we develop actually comes from the product sphere.
In terms of the tickets, we’ve moved away from having the originator of the idea formulate them. In most cases, the process is now that the person who has the idea makes a feature request which is then translated into a ticket by the product lead before it goes into the circle and is made part of a story. We train people by sitting down, having the stories pitched to us, and then asking: “If I were being asked to develop on this, would I understand it? Would I be able to get straight to work on it if I had only been here for a week or so?” By looking at things through that lens, we can give feedback on comprehensibility. It is absolutely crucial that our people understand what they are building.
Alex: How did you get to this approach? Is it the result of trial and error, or have you discussed the issues with other companies?
Sebastian: Looking into other companies and finding out how they do things — especially over in the US — has always been important in our development, and will remain so. Nevertheless, the litmus test is what happens within our company after every sprint, every iteration: regardless of what we’ve seen elsewhere, that is where we find out what worked well and what didn’t work for us. On that basis, we adapt our processes. As a general rule in IT, there is never that one-size-fits-all solution. Each and every company is different.
Alex: Looking at you guys, I get the feeling that pretty much every ticket goes through you at some point; I also get the feeling that Tarek Himself still spends his evenings lovingly optimising the AboutYou Facebook profile. And while I think that level of involvement from management is honourable, isn’t there a certain business size when you should be at a point where you can, say, go on holiday for three months — without the quality of the code or the turnover falling off…
Sebastian: I’m still deep into all the key areas, granted, but it’s definitely not the case that the whole thing would collapse like a house of cards if I did go off for a few months. We’ve built an excellent management team which is very hands on in all processes; we write the coding guidelines together, we brainstorm improvements together.
It is important that I’m still involved in things, that I understand the whole area so that I can set incentives — that is one of my key management duties. After all, I’m more or less the only one who has an overview of all the different team, of what they are working on and how they are working on it. That means that I can see where it makes sense to optimise on a broad level and where it would be better to optimise a single team. If I weren’t there, things would keep ticking along nicely, but then somebody else would have to take on this particular aspect of management work.
Alex: And I take it you get a lot of visitors from the Otto Group coming around and asking themselves just how you manage to pull it off?
Sebastian: It’s not like there are loads of people milling around all the time, but sure, we get quite a lot of interest.
Alex: I hear that Salesforce has set up its own visitors’ department that organises two groups tours daily. I think people would be queueing up if you did the same…
Sebastian: We take tours of the Otto Group, too, though. It’s a big company with a lot of know-how, so it’s not a one-way-street. And we’re not a zoo either. When Otto people are here, we talk to each other as partners, as equals