Building a team and culture to manage the transition to a modern commerce architecture
I spoke on a panel at the Internet Retailing Expo at Excel today, and thought I’d document the chat. I’ve been on a few stages in my time, not least because I co-founded a MICE aggregation website called Meetingsreview which has since become Meetingspotlight.com. I also put out the first ever live webcast from a car show back in the early 90s. Events aren’t scary, they’re rapid.
For any of you out there that shy away from speaking on stages I strongly suggest you stop being silly, get up and do it. If you’re in your comfort zone you’re not stretching. Even my dog knows it’s good to stretch.
Chris, River Island’s been in retail for 74 years. How have things changed in that time?
Given I’ve not been Head of Development for all of those 74 years, I’ll try my best to recall the journey:
- It was in the 1940s that Bernard Lewis sold his first yam in a dis-used air raid shelter. At that point I’m sure the technology was pen and paper
- By the 1950s I believe he and his brothers were operating 9 or so ‘Lewis Separates’, above ground with the same trusty pens and paper
- In the 1960s a younger, hipper crowd mobilised, and the company responded by rebranding into Chelsea Girl to attract them
- By the 1980s men were buying clothes so we launched ‘Concept Man’ to sit alongside ‘Chelsea Girl’. River Island started using Fujitsu’s ‘VME’ (Virtual Machine Environment) mainframe for its heavy lifting, and Excel for the flourishes around the sides
- ‘River Island’ didn’t exist until the merging of the men and women’s wear in the 1990s, to provide a more uniform brand offering. Still though, at this time things hadn’t changed much since the 1940s
- In the 2000s the Internet was becoming a thing. River Island spent £13M on an Oracle solution to replace the VME mainframe module-by-module, but it was soon realised that River Island wasn’t like everyone else, and given we’d been successful for as long as we had being that way we saw no reason to ‘fit in’ to the commerce suite we’d bought into. We bought the codebase and set to building all the modules in it we needed to provide the business with the flexibility it needed.
That Oracle solution served us well. With batch jobs running all night, every night. The architectural approach was monolithic and the development methodology was “JFDI”, and at the time it worked. When the Internet started to happen, and our Flash website cost more to build than it brought in, we realised we needed to reinvent once more, only for the first time in our history it would be a technically creative reinvention rather than an aesthetically creative one.
So in the mid 20teens we spent several million pounds each year for several years enabling ourselves; getting ready for the future. Microservices was the name, future-innovation enabling ‘backbones’ was the game. We began with an orders backbone, a singular service able to be subscribed to or interrogated via APIs, and more followed.
Wishing to stand out from the crowd, River Island needs to be flexible enough to create services and user experiences that make the buyer’s journey simple, quick, and inspirational.
We’re still moving towards this flexibility; coaxing a 74 year old business that’s lasted this long without being told what to do by a bunch of nerds as smoothly as possible as it operates through this, the UK’s ‘fifth’ remarkable economic downturn.
In recent years we all spoke of microservices or SaaS. Today River Island stares out into the future, using MACH branded compasses to help us on our journey to Nirvana:
- MACH is a CommerceTools concept which stands for “Microservices-based, API-first, Cloud-native, and Headless”
There are others in this room with Composable Commerce branded compasses, and indeed product minded people carrying ‘Unified Commerce’ branded compasses. We’re all going in the same direction, only with ever so slightly different frameworks:
- Composable Commerce is the Gartners definition, recommends that we all strangle our monoliths under three headings: Customer Journey, Business Capabilities and Tech stack
- Connected/Unified Commerce which suggests a drive towards a seamless shopping experience across channels and devices
Ultimately we’re chasing down the same flexibility we know has always worked for River Island, within the IT department.
How does changing structures affect the team and culture? How has the modern commerce architecture changed your enterprise?
For the past 7 or so years we’ve spent several million developing serverless solutions to enable future innovation. We learned — from when we took over the Oracle codebase — that building our architecture simply to suit business requirements wasn’t what the business needed from tech. Once we realised this and we took ourselves seriously we decided upon our backbone approach of exposing data freely starting with orders, product, customer, inventory, etc. We partnered with Amazon, becoming among the first people to really use serverless in anger, and we hung our hat on GoLang.
We figured out what our teams should do, so ran business facing teams to service business departments and customer facing teams to service customer journeys. Our teams were able to ‘build it ship it own it’, and then we set to changing the management style to afford greater autonomy with a view to that facilitating greater innovation.
Business is more engaged with the teams that service them, although there’s more to do there because I sometimes believe we over communicate to the business, which has small consequences that themselves reap larger repercussions. For example, sprint reviews rarely enjoy the presence of people from the business. Not because they’re disinterested, but because we liaise with them in a layer outside of the team. As with all aspects of technology, small things add up if not nipped in the bud early.
BUILDING YOUR TEAM:
What considerations do you both take when building your team and why?
Attitude and aptitude. If we must look at skills, and often we do — due to our lean nature — we’ll look at skills and a distant fourth would be experience. Primary for anyone we hire is curiosity and drive. If you have that but don’t know Go yet we’ll take you. Only at very niche times do we care for specific industry experience.
Benefits of upskilling vs hiring freshly trained staff? Chris I know you think upskilling is hugely important…
Upskilling is important, but I’d probably use the word ‘growth’. If you hire curious, driven people you’re hiring people that want to get better. Individual contributors want to feel that they’re getting better.
At River Island we’re finalising a pretty comprehensive view of career paths to help the Gen Z people know where they’re driving towards, and we associate those paths to competency levels across a range of skills. If anyone out there wishes to pitch their skill testing platform to me, that is the final puzzle piece to place.
Plenty of people believe in “fresh blood” over promoting from within, and to the people working under that style of leadership, I suggest you get in touch. At River Island my right hand man began as a developer at River Island. He left and came back. My Principals were both developers at River Island. We don’t hold onto people forever, we’re not big enough to be able to move people around like that, but we do our very best with the opportunities we can provide.
How do you strike the balance between third party vendors and an in-house tech team?
If it’s unique to River Island we’ll build it ourselves. If it’s a commodity we’ll buy it. Regardless of the approach however, we’ll make sure it’s looked after by the team already charged with servicing specific customer journey points or business capabilities. If it’s an entirely new technology to us we’ll partner with someone to have them steer us or build it for us, but always with oversight of the solution they’re delivering.
CREATING THE CULTURE WITHIN TEAM
What mindset do you want to cultivate within your teams? How do you go about doing this?
Empower them. Although… you can’t empower someone, you can only relinquish power; you step back, give people space to grow into and encourage them into it. You give people problems, not solutions. You wait for them to give you solutions.
People are hesitant sometimes, so I tell them to stop typing for a minute and realise that have the same power as me, so in certain moments they should raise their heads out of their teams and think “OK, so if I was in charge what would I do?”. By giving people that space they often appreciate my role a little more because with freedom comes having think more widely about a problem, and the more you learn the less you know. Consequently, I find the more empowered a team is the more understanding they are of changes I try to implement.
How do you install that growth mindset within your team? How do you consider the problem?
You hire for a growth mindset. There’s no room for people that hold you back with their attitude. Hire for attitude and ability to learn.
Are you agile in the way you work? How do you cultivate that more?
We’re as agile as life allows us to be. We’re each of us able to adapt, but if you don’t carry an umbrella on a sunny day you’ll get wet if it suddenly rains. In our business facing teams we’re servicing the needs of business, and although they change they don’t often change overnight. That said, our approach to the problems in hand is indeed with agility in mind, and certainly our compostable components and general architecture speaks to that agility.
How do you ensure that you don’t get isolated silos of knowledge within your teams?
Generally speaking, we move developers around for growth, which isn’t made easy given the sense of team spirit everyone has. They like and often want to stay in their teams. At the same time, next year we’re looking at making our more matured backbones open for development by teams that didn’t build them. Open-sourcing internally if you will. To achieve that we’re creating strategy docs, roadmap views of each backbone, that kind of thing.
Are there any decisions that you would go back in time and change during the process of building your team? What lessons have you learnt?
I think we’d give some teams more power. Personally, I’d like to see more decisions coming from inside the team, and less asks being made of — essentially — stakeholders. So if anything, I’d give teams more power, more trust, and of course to be able to do that I need stakeholders to step back, affording teams more trust. To achieve that retrospectively I need to encourage greater engagement and understanding of the direction of travel, and of the metrics being influenced.
