Footasylum Tech

I’ve read a lot of the other posts in this ‘How I got here’ series and based on those I’d say my route so far has been the more linear and academic way in. I’m actually still a student – I’m studying software engineering at Liverpool John Moores – and I’m spending my third year at Footasylum Tech before I graduate (fingers crossed😬) at the end of my fourth year.

Following my instincts

As far as I know, it’s very rare for someone of school age to know what they want to do when they’re a ‘grown up’, so I found the best thing to do was to go with my instinct. When it came to college enrollment day, I was about to sign up for graphic design, English and psychology A Levels but none of those things felt quite right.

I changed my mind on the day and enrolled on a BTech in IT. I chose based on what I’d enjoyed studying up to that point.

At college, I did work experience with a company that created virtual reality games and loved it. From there I decided I’d like to go to university and at that point I knew software engineering would be a good fit for me.

All my worries 😔

The reason I made some of the ‘life path’ decisions I did was because those routes felt safer. For example, I chose a BTech partly because I just did not want to go through A Level revision and exams. I hated that anxiety-inducing pressure during my GCSEs. In fact, I very nearly didn’t bother with a placement year. Everyone always says how good learning on the job is, but the thought of applying, interviewing, coding tests and then being rejected was sort of crippling.

But I made myself go to a careers fair. There were tonnes of stalls but I didn’t speak much to anyone, just wandered around. When I came to the Footasylum stand, I met Sarah Weeks and David Nottage and we chatted. I tried to figure out why chatting to them seemed easier than the people at other stalls and put it down to the fact they weren’t loads older than me. And, they weren’t in suits. They said they were there looking to speak to people who’d already graduated but they asked for my CV anyway.

A surprise ‘chat’ and my cautious approach

I was mid interviews/coding exams for a few other places and they were going about as well as I’d expected when Andy Norton, the Software engineering manager, asked if I’d like to meet for a ‘chat’. “Come in trainers if you want – this isn’t a formal thing,” he said. So I went to head office to meet him and the team with no pressure on myself and that age-old thing your parents say ringing in my head: “think of this as really good interview practice.”

For the first time in my experience of interviews, I didn’t feel like anyone was trying to trip me up. Instead, Andy asked about what I’m working on in uni and what I’m interested in. It didn’t feel like he expected me to know loads about a) the workplace and team culture and b) coding, seeing as I’d barely started studying it! He was looking for my potential, not my current knowledge.

When I left, my attitude had flipped: this wasn’t just ‘really good interview practice’ – I really wanted this placement.

At 5pm on a Friday in October 2019, I got the call saying 🎉I’d secured the placement for May 2020.🎊 When the pressure was off to find a placement, I settled into my course and the rest of my second year flew by.

Work stuff I’m proud of 💪

I started on the UNLCKD team (during lockdown). From my first day, I felt like one of the team – nobody treated me as less experienced. I was welcomed with (virtual) open arms. Principal developer Ian Parr is my go-to person if I need help – he’s there as much or as little as I need. He doesn’t rush me with tasks, instead he gives me space to learn.

My first task was to “become an expert on the third-party software we use to manage loyalty.” Being new and eager to impress I think I took this to the extreme – I know about everything from every attribute the software stores, to how we set up the full loyalty program.

I also created a ‘test harness’ as in, a test site. I’ve started to learn C# which makes a change from java that I was using at uni. I’m feeling so much better with API work now too. I’ve recently realised I really enjoy front end development and testing. I’ve learnt the importance of test driven development, loads about Microsoft Azure, I’ve created my own datalake events and I’ve even managed to do some of these things without asking for help.

But there's other stuff I’m proud of too

There have been many times where the worry has returned – including in the weeks leading up to the placement. Since starting, I’ve had times when I’ve got really upset with myself for not understanding something immediately (hi there, APIs, I’m looking at you). My team know how much pressure I sometimes put on myself and it turns out that imposter syndrome is not an uncommon thing.

💗 My confidence has grown a mega amount and that’s largely down to my team encouraging me and amplifying even small achievements. I’ve spoken at our weekly huddles in front of the whole Tech team, and I’ve talked stakeholders through a prototype. (My nerves made me prepare so ridiculously thoroughly!)

I’ve learnt that in the majority of cases, people see that you’re doing your best and they’re kind. I went on the brilliant Upfront course about public speaking and how to present yourself and it highlighted that nobody is born confident, you have to learn.

Watch this space 👀

I’ve thought loads about where I might be in the longer term and I think I’ll always make that decision based on what I enjoy and what I’m interested in. That could be something creative like virtual reality games, but I’m also really interested in how we use tech for social good.

Anything after uni still feels like a long way off but I’ll be going into my final year with solid foundations both in terms of coding skills, what good team culture looks like as well as a quiet confidence. I’ve got this opportunity at Footasylum Tech to thank for that.

Abbie Knowles Software engineer

We’ve recently started using Basecamp’s ‘shape up’ approach to move UNLCKD, our loyalty scheme, forward. The approach recommends working in 6-week cycles because, as Basecamp say, that’s “long enough to build something meaningful… and short enough that everyone can feel the deadline looming from the start, so they use the time wisely.”

This post is about how working in this way has helped us (the digital team), communicate clearly and concisely with our stakeholders to improve their understanding of the product and the way we work. This has built trust and has meant we’ve had the space to focus more deeply and make progress.

A tricky project to inherit

We’ve posted before about the history of UNLCKD but TL;DR: the piece of work came from a business need before the digital team was in place. There was no discovery, and knowledge and dependencies were distributed across multiple people, teams, systems and suppliers. Inheriting the project was tricky for the digital team because picking something up at this stage and modifying it to meet user needs as well as business needs is far from ideal. It couldn’t be a pure agile delivery job. We needed a way of working that allowed us to deliver and improve UNLCKD’s value while managing a relationship with stakeholders who are not familiar with agile ways of working and who may be bought in to the product we are tasked with changing.

The big question: how could we pull each team and every stakeholder in the same direction? The answer: we borrowed elements from ‘shape up’ to create a delivery approach suited to our situation.

How the ‘shape up’ approach has helped us make progress

We discovered the real gold lay in how this way of working brought stakeholders along with us and kept them super engaged throughout.

Here’s why.

1. Smarter communication reduces the load on stakeholders and gives us more ‘deep thinking’ time

The approach helped us think hard about communication. As a result we’ve been very strategic about how and what we’ve communicated with stakeholders and at what point. The first change we made was to switch to asynchronous communication – this is when you send a message without expecting an immediate response. So, emails lend themselves well to asynchronous comms but a flurry of Slack messages do not.

We believe that async communication has transformed our delivery approach and our reputation with stakeholders because it has allowed them to get on with their day-to-day jobs and has given them the peace of mind that we are getting on with ours. How do they know we are? Because we’re updating them regularly (without overloading them) and they can read about our progress when it suits them.

Our investment in longer form writing has meant we get the maximum shared understanding in the minimum time. For anyone wanting more detail, more often, we also spun up a wiki to record more day-to-day detail and decision making, and shared this with everyone, along with a glossary for any technical phrases. We also ask for a single hour of stakeholders’ time at the end of each 6-week cycle for a show and tell and Q&A session.

We’ve reduced the cognitive load for stakeholders – and for us – by making things predictable. Routine is comforting for humans so it makes sense that stakeholders tend to feel safer if they know how and when they’ll receive updates. Sharing what’s important at set intervals has provided more space for us to concentrate and focus more deeply. We’ve suddenly gained 6 weeks to work without interruption. After each 6-week cycle, we have a 2 week ‘cool down’ period. Those 10 days have allowed us to fix tech debt so it doesn’t accumulate too wildly, reflect on what we’ve done and the way we’ve done it during the cycle and plan and prioritise very deliberately, without huge time pressure, what we’ll include in the next scope of work.

2. Setting expectations helps build trust

At the beginning of our 6-week cycles, we agree on the scope of work along with success measures and an owner. We name the cycle (always a bird) so it is memorable and is a thing in its own right.

Then we email the scope of work to the people who need to know. We include a TL:DR summary and a ‘Luxurious Detail Version’ which is more in depth – this way busy people can get what they need as a headline and read the details when they have time. We tell them roughly when to expect demos and we set a date for the end of cycle show and tell and Q&A session.

We have a 30-minute max check-in with stakeholders each week. We send them (plus the wider business) a newsletter update every 2 weeks (again, with a TL:DR summary as well as a more in depth version) with honest commentary on small failures, links to online work and our even more detailed wiki. This is all leading to the show and tell and Q&A session at the end of the cycle.

This is our third cycle and it feels as though everyone – and I mean stakeholders too – has settled into this routine. We all know what to expect. There’s something powerful about laying out the way we will work over a short period. It shows we are in control, organised and reduces (the appearance of!) chaos. Setting realistic expectations – and updating them if needs be – is important. This way there are no big shocks because we all get into the habit of knowing what to expect, at what point.

Trust and better relationships stem from here.

3. Working in the open invites more constructive feedback

The show and tell and Q&A session comes at the end of each cycle. We work as a team on a 45-minute presentation with the emphasis on show not tell. This forms part of the 1 hour we ask stakeholders to commit to every 6 weeks.

We show what we’ve done, we talk through what hasn’t gone to plan, we work hard to explain why. We agree to be honest and this gives stakeholders the opportunity to meet our honesty with theirs. We follow up with written notes and an online survey in case feeding back in front of others doesn’t feel right. We take note of any concerns, we record the session, update the wiki, and we go again.

That 1 hour video call is important – especially while we’re all working remotely. Seeing each other, putting faces and human voices to the work being presented or critiqued is a necessary (occasional) connection. It helps create empathy between people who may sometimes think of themselves as having opposing priorities. Having that engagement beyond a name on an email changes your experience of them and how understanding you are of each other.

Thumbs up all round 👍

Here's a photo of the team, taken at one of our remote meet-ups.

The feedback has been very positive on our progress and also on the way we’re working.

Our key stakeholder said that they ‘wished other teams worked this way’ and that we ‘smashed it with a great presentation’ after every single cycle. That’s a great outcome and we’ll continue working in this way. We’re at week number 2 on cycle Bullfinch. Next up: cycle Flamingo.

Andy Tabberer Delivery manager

I’ve been working with Footasylum for around 4 years now but like some of the others who are now in the Tech team, I didn’t join in a tech role. I actually started in the warehouse.

I left school at 16. I didn’t go to college or university. I went straight into ‘unskilled’ work. I worked in various warehouses, and just before I joined Footasylum I was picking and packing goods for a massive company. The work was ok, it was what I expected: I went in, had a laugh and joke, I met my target for the day and I went home. It was that, on repeat, for 8 – sometimes 12 – hours a day.

After 2 years working there my mental health began to fail. I don’t know why but I began to experience anxiety attacks (super embarrassing at the time). As a society, we have a much better understanding and are generally more sympathetic to mental health issues today, but at the time, this particular workplace showed zero compassion.

The lack of understanding led to increased anxiety and I got trapped in a vicious circle.

Until I was asked to leave because of it.

Fighting for better standards 💪

The next part of my ‘how I got here’ story spanned around a year. I took my former employer to court because I believed I’d been dismissed unfairly.

I won the tribunal on all counts.

It was the hardest thing I’ve done, partly because ➡️I represented myself.⬅️ I stood in opposition to specialist employment solicitors from a big company, and I made a stand against insensitive, outdated attitudes to mental health. I sincerely hope that the case set a new precedent for the way staff would be treated in the future. During that time, it became very clear to me how much I value being valued – as a human being and not just as a cog in a much bigger machine.

Not long after that ordeal, I joined the Footasylum warehouse.

In demand and happy to help 🌟

I wasn’t working in the Footasylum warehouse for long before I was asked to join the quality control team, and it wasn’t long after that that I got promoted again to the admin person on the internet department, then team leader and finally supervisor. Hard work doesn’t go unnoticed.

At this point I was fixing the printers pretty regularly and picked up other techy tasks that it wasn’t really anybody’s job to do and I landed an interview with the IT support team. I’d always tinkered with PCs and my enthusiasm must have gone down well because I was actually offered the job mid-way through the interview.

😎 That felt so good.

A passing comment turned into an opportunity

Since I’d started in IT support I had much more visibility of what the Tech team was working on. I liked the idea that there was now this team who were dedicated to improving systems that would help colleagues in our stores. I got chatting to IT Director Paul Martin at the Christmas do and asked how software engineers become software engineers and I said that it sounded like a rewarding job.

A week later, Paul emailed me and asked if I’d be interested in learning to code at Code Nation. The training would be funded by Footasylum.

Of course, I jumped at the chance. But it wasn't just the free training and the opportunity for 12 months on-the-job learning that sold it to me. I liked the fact that I'd expressed an interest in something, someone had listened, and they'd taken a leap of faith in me. I felt a long way away from being that cog in a machine in the other warehouse.

Change in culture

I'd got used to the warehouse culture. You came in, you did your job, you left. There wasn't much variation on that and there wasn't much need for collaboration either. There was always a high turnover of staff too which meant that relationships were kind of fleeting and there wasn’t time to establish deep trust. All of this is fine but it's just very different to working in a tech team.

In Footasylum Tech, the flexibility really struck me. I can do the school run without eyebrows being raised. I can take a last minute week off without a grumble and (at a safe distance) spend it with my Nan who got coronavirus. Here, the assumption is that I’m committed to my team and doing the best job I can at all times. That level of trust makes it impossible to have a bad attitude and not return the favour when it comes to flexibility. If a little more is needed, I’m happy to give it. There’s a lot of give and take – it comes down to having mutual respect.

3 months training , 12 months learning on the job

The 3 months of 9-5pm at Code Nation was a general introduction to front-end, back-end and how everything fits together – it helped me connect the puzzle parts. We mainly worked on learning javascript.

After that, I continued my learning in the Footasylum Retail team. We’re responsible for the till systems in store and we’re working on various new features. For example, at the moment colleagues can only sign on to tills as a cashier or a manager which isn’t great for security or accountability. We’re figuring out a way that each person will have their own sign in.

Support when I need it

I have Ian Wells as my mentor and we spend Tuesday afternoons improving my java skills. I’m actually working towards my Oracle Certified Associate (OCA) certification (again, paid for by Footasylum).

For more day-to-day challenges I pair with Ian and principal engineer Chris Reason. Most recently we’ve worked together on building various cloud-based apps like logic apps, APIs and function apps to query, map, rebuild and upload items to Azure cosmos databases.

I’m nearly at the end of my year-long apprenticeship. I'm now in a 'skilled' job, I have great prospects, and even though I'm still training, I'm earning more money than before. I’ve learnt loads, but there’s still so much to get my head round. The attitude to learning here is great though. There’s none of that senior school mockery for wanting to learn – learning and asking questions is encouraged because the Tech team wants each colleague to grow.

I love that. ❤️

Adam Emmott Software engineer

I was tempted to open this post by saying that my way into the tech industry was unusual but what I’ve learnt from reading other people’s stories is that a ‘standard way in’ does not exist. Footasylum Tech is made up of people with very different CVs. I hope that’s encouraging for anyone thinking of applying for a role here.

The demise of my rockstar ambitions 🎸

At school, I was good at science – I took after my dad who has a PHD in microbiology. But I was more into playing in bands – also like my dad whose band went on a european tour back in the day. It wasn’t until I read Stephen Hawking’s Brief History of Time in the first year of college that I realised that I was more passionate about science and the challenge of studying it, than playing music.

I picked up physics in my second year of college and got my AS level. From there, I did a foundation year to bridge some gaps before studying for an undergraduate degree in Acoustics at Salford University. It was the perfect mix of physical science and music.

Jobs. But not dream jobs

I worked for an environmental consultancy when I graduated and after that I took a role in the same sort of area but for a company who dealt with the manufacturing side of things.

At this point my son arrived. A few weeks into his life we were told he needed major surgery. The lack of kindness and understanding shown to me by my workplace made a very anxious and difficult time even more stressful.

Although I’ll never forget that company’s poor treatment of me and my family, it gave me the drive I needed to make changes. My frustration strengthened my ambition, gave my career more direction and shaped my idea of what healthy work culture looks like.

Determination, initiative and clear priorities

Because my background is in a technical discipline, it wasn’t such a stretch to imagine getting into a career in IT. After spending my 9-5 with the company I desperately wanted to leave, I spent my evenings looking at job adverts for the roles I wanted.

I scraped information from job specs to learn about the industry, and I noted the skills that employers were looking for most often (at this point, C# and C++ as well as python were frequently sought after programming languages). I started to teach myself with a Raspberry Pi. I spent an hour or so every other night following online tutorials and getting stuck into Hello World projects.

After about 6 months I started applying for a variety of junior roles, from web development to security and games development. When I started applying, I knew I was a long shot. I got interviews at IBM, SG Gaming and then – after 18 months of self-led study and loads of applications – someone took a chance on me.

Cosatto. A local shop for baby stuff with an online presence.

You only need one chance

Changing career was a massive risk for me and my family – but knowing that made me determined to succeed. During my interview, I showed Cosatto a simple website I’d built in python. They asked me to “go away and host it on AWS and come and show us again in a week.” I had no idea how to do that or what it really meant but I smiled and told them “no problem.” I read guides, scrambled around and after signing up to AWS I had to rewrite my python site in the Django framework just to be able to host it. Eventually I nailed it.

I got the job. From that point on, I was away...

Blagging it. Training on the job 😬

I worked alongside an IT manager and a software developer and I dipped into both disciplines. I had 6 months to move the intranet from vb.net to C# so I taught myself Visual Studio, entity framework, Angular JS, SQL, Windows Servers and IIS Hosting. When the developer left, I picked up his work with the custom software – I was thrown in at the deep-end but solving problems and learning on the job was something I was used to at this point.

Joining Footasylum Tech

I joined the Platform team around a year ago as a software developer. Back then, the job advert I answered was for a .net developer but we tend to get rid of the specifics in titles now because it feels a little limiting.

At the beginning of this year I moved across into a DevOps position – a role that combines software development and IT operations. The focus of my role changes from writing code, to looking at how we write code, how we release it and how we get feedback from our systems. Part of my enthusiasm for the discipline comes from it being quite scientific – we have a hypothesis, we run an experiment, get results and then analyse them. This process helps us make sure what we build and how we build it delivers value.

Big up DevOps 💪

My goal is to strengthen the DevOps community here at Footasylum. I’ve been inspired by conferences and posts on how companies of all sizes are organising and communicating within the discipline.

We’re also getting the DevOps community of practice back on track because – as I know very well from being a lone ranger in other jobs – it’s essential to have the opportunity to support and be supported by people doing similar things.

Good culture sets us up for success

I report in to Andy Norton who has been the right amount of supportive and available without being suffocating. Within Footasylum Tech, I feel safe to ask anything and that no question is daft. I also feel that we all have permission to fail because there's value in failing – it's all part of the personal development process.

I still think about the toxic place I worked at when my son was born – mostly because working here has amplified the difference in attitudes and priorities. We put people above the work here and that's refreshing.

Long may that continue.

Jonathan Evason DevOps engineer

‘UNLCKD’ is Footasylum’s loyalty scheme. It’s a live product and customers can access it from their online account or under the padlock icon in the Footasylum app.

This post is about the history of UNLCKD – why and how it came to be, the challenges we’ve faced and our decision to scrap the first version that was built in favour of buying a solution.

The business challenge

Back in August 2018, the business realised it had gaps in how much it knew and understood about our customers. A significant number of people were signed up to the mailing list and our open rates were in line with industry standards – in other words, our customers were pretty engaged. However, the business realised that if we knew more about our customers, we could make better-informed decisions both for them and the business.

The business had hunches about the answers to the questions it had about customers, but it needed data to build a more accurate picture of their needs, desires and demographics.

A quick and easy solution?

To bridge the gap in our knowledge, Footasylum launched a loyalty scheme – something where we could thank returning customers with points that could be converted to money off future purchases, plus some money-can’t-buy benefits. The assumption – as with most similar schemes – was that these rewards would encourage customers to tell us about themselves so we could tailor the Footasylum experience to them.

Progress started on UNLCKD and August 2018. There was a h-u-g-e marketing plan in place which meant that the launch date was fixed and the app came into existence through waterfall delivery. When it launched, customers could sign up for an account, see their points, redeem vouchers and enter competitions.

Not quite on track

Unfortunately, take-up was slower than the business had anticipated. Training was offered to colleagues in stores to help them remember to prompt customers to download the Footasylum app in stores – which often had limited wifi coverage – and then use UNLCKD from there.

Soon enough, flaws in several of the user journeys began to show.

How much of our original data problem were we solving?

The scheme was helping the business understand customers online and in-store shopping habits, true. But there were questions around how reliable it was. Bottom line: what was being collected wasn’t robust enough for us to go on to deduce meaningful insights in customer behaviour and consequently make decisions that were informed by it.

Retrospectively service mapping to understand the problems

Digital teams use service maps right from the alpha stage of a project – it’s best practice. Service maps depict each interaction a user has with a service both on and offline – from a customer’s first step when they google ‘Footasylum loyalty scheme’ (or similar), to when they sign up, all the way through to when a customer redeems their points against a purchase. They also map out if there are any loop-backs, for example, when a user forgets their password and resets it.

There are many benefits to service mapping but one is to identify where the problem areas are. That’s exactly what we needed.

So, instead of service mapping alongside the development of UNLCKD, we did it retrospectively in September 2019. By this time, we’d built a team who were more familiar with practices that are used in Digital disciplines – service mapping is an example. Here's a photo of some of us on a Zoom call.

The courage and integrity to make changes

The mapping showed the disparity between what the original purpose of the loyalty scheme was and what it could actually do. UNLCKD over-promised and under-delivered. We took our findings to the senior team. Since then, we’ve made huge changes to the tech, the product and the design. We’ve scrapped much of what we had before. And we’re still working through many of the remaining problems.

Our aim since has been to simplify everything and make it work.

Decisions, decisions: to buy or to build

When we inherited the product, we were dealing with a lot of legacy code and technical debt. It had been built in an uncollaborative, waterfall way and a complete reset was needed. We had to make a decision about whether we should build something else ourselves, or, whether there was something already on the market we could buy and integrate.

We looked for a partner who:

• offers ongoing collaboration
• mirrors our ways of working
• upholds robust data standards (cleansing, processes and governance)
• offers good value for money
• is API-driven for successful integration
• offers a customisable product that allows flexibility to make changes
• openly shares comprehensive technical documentation
• offers support post-launch as well as during integration

The decision to buy was made collaboratively. From our initial research we knew there were partners out there that could meet our needs so we put forward our recommendation to buy to the senior team. They approved and the procurement process went ahead.

Our chosen supplier Talon.One provides a promotions engine which creates rules, manages account creation and loyalty point allocation.

More recent work

For the last 5 months, we’ve been mapping out the service so we can integrate with Talon.One; building APIs, and creating designs for new user journeys. We already have a much more usable, robust product.

We’re currently facing the challenge of communicating well with our stakeholders. It’s essential we present and explain research and design to them often so that as the subject matter experts, they can raise concerns immediately and help shape the work. We’ve been using Basecamp 6-week cycles and asynchronous communication methods and found them really helpful – we’ll talk about this in a post soon.

Chloe Barton Product manager

I’ve been working with Footasylum in some capacity for 5 years now but my role has changed a lot. Earlier this year I became Footasylum’s first cyber security analyst.

Juggling studies and store work

I took a job as a Christmas temp in the Bradford store in 2015. I was studying at Leeds Beckett University and took what I thought would be a temporary role as a sales assistant during my first Christmas as an undergraduate. As it turned out, my contract got extended and I worked in store during term time for the next 2 years. When I graduated, I accepted a full-time supervisor position which meant I became more involved in the day-to-day running of the store.

From stores to IT support

Shortly afterwards, I was accepted into the Footasylum Leadership Academy – an internal programme designed to develop management skills and overall retail knowledge by giving potential leaders experience across a range of our stores and departments.

During my time in the academy I worked alongside different departments learning about what they do and why they're important within the business as a whole. When I spent time in the IT department, I felt like I was revisiting and using some of what I'd learnt at university – it's the first time I'd felt like that since I graduated. I'd studied Computer Forensic and Security. My course choice was partly influenced by american crime show NCIS because I thought working in digital forensics and supporting the police would be pretty cool. Although IT support perhaps wasn’t a natural progression from the degree, it was a closer fit than retail management. 😆

I didn’t have IT experience and the first I heard about the role was through one of the talent managers who must have been looking for internal candidates and recognised some potential in my CV. From there I agreed to meet delivery manager John and Head of Delivery Kim who chatted through the role and filled me in on the discovery they were doing into the IT we had in the stores, and how we might be able to improve things for our store colleagues.

My role in the Retail IT support team would be to respond to problems reported by store colleagues, for example, I was contacted by store colleagues when tills crashed or a back office computer was faulty. I already knew how systems worked because of my time in stores. I fed all this back to John and Kim so they understood the problems I was hearing about and therefore had a better chance of fixing them.

Side-stepping to cyber security

The way the office is organised meant that from my desk in IT Support, I could hear the security team chatting. The stuff I overheard about the problems they were solving sounded interesting but a position never came up so I didn’t think there was a way for me to move across. That’s how I’d always assumed people got jobs – someone leaves or a position is advertised, and someone takes it. But one day I was approached by Jason McCreery, Head of Infrastructure and Support. He told me there was a position coming up on the security team and asked if this was something I'd be interested in moving into because of my background.

The importance of cyber security

So, since March I’ve been working as a cyber security analyst. People tend to think cyber security is very technical, has a lot to do with looking at code and protecting companies from hackers.

But that’s just a small part of it.

It’s much more about raising awareness of why good security is important – both within the company but also in people’s personal lives. My role is mostly centred around working through cyber security policies and making sure they are communicated to colleagues in stores and in head office. I’ve been sharing best practices for keeping personal and company information safe, and putting procedures in place so that teams know what to do if security is jeopardised. Educating teams is a huge part of my role.

Making progress

I’ve been really enjoying the work, and the engagement we’ve started getting has spurred me on. Colleagues around the business are starting to forward on emails they suspect might be spam or phishing which shows that they’re either more aware of possible problems or have begun to care more about working together.

We’ve worked really well with the communications and support teams to make sure we get our message out there – after all, there’s little point having policies or setting out procedures if the wider company doesn’t know they exist. I’m proud of our collaboration with comms.

Team culture

I felt I fit into the IT team straight away. It feels like everyone is self-motivated to do a good job here which is why managers tend to be quite hands-off. Individuals have the freedom to self-organise. I report to the Head of Security, Ravinder Jamgotre. We have a more official team meeting at the beginning of each week to prioritise and a catch up at the end of each week to reflect. Ravi is around throughout the week too if I need him.

My favourite thing about Footasylum is that you don’t have to have a certain skill to get into an area you want to explore. Attitude is more important so if you care and you’re committed, you can move around because people are willing to give you a chance. It feels supportive. I’m glad I’ve stuck around for so many different roles.

Haleena Hussain Cyber security analyst

The title of this post says I’m a delivery manager – that’s true but that only became my role very recently. When I started at Footasylum Tech in November 2018, I joined as a product manager although actually, I was learning on the job. I’ve really valued having the freedom to learn, explore and change direction within the company.

A long history with Footasylum

I was a supervisor in the Preston store for around 4 years. I had a reasonable amount of responsibility – colleague rotas and training, cashing up, and the authority to make certain decisions. In other words: I was very familiar with how the in-store part of the business worked. And also, critically, which parts didn’t work very well. I knew about the situations in daily store life where the team had invented work-arounds to avoid stuff like tech melt-downs or long-winded processes.

At the time, the things the team had to tread carefully around were annoying but we’d just accepted that deliveries would not show up on the scanners and that we’d have to tick off each item on a piece of paper before manually entering that into some software. It was just a thing that happened. Fast-forward to now I’m behind the scenes trying my hardest to fix those things so that colleagues don’t have to waste time fighting with legacy tech – they can spend more time helping customers and providing a better level of service.

Wanted. A product manager for head office

I spotted the job advert for a product manager in the newsletter that went out to store colleagues. I wasn’t very familiar with what a product manager was. The ad mentioned user stories and writing test plans which I didn’t have a clue about, but the overall gist of it was: come and help solve problems for store colleagues by designing the right stuff. I knew about all the problems – I lived them every day. The advert specified that the candidate must have store experience so I figured that very few people would have knowledge of – and even fewer would have experience in – that discipline. I’d worked briefly as a front-end developer (I got made redundant and that was partly how I came into my supervisor role) so I did have some experience in the tech industry.

Anyway, I applied. I got an interview. The stores had recently got some new till software and I was asked what was the one thing I’d have done differently when launching it. I said that I would not have launched it during the busy Christmas period. There must have been something in the way I said that that conveyed that I knew just how stressful decisions like that can be.

I started as a product manager 6 weeks later.

Joining at the right time

When I first joined I was based in our head office. Departments sat separately. We didn’t have multi-disciplinary teams at that point. There was a backlog of features that each department wanted. My main responsibility was improving the till systems.

Soon afterwards, Footasylum Tech hired more digital experts and all the above started to change. There was a shift towards experts from different disciplines working together on a single scope of work. Head of Delivery Kim Morley joined and threw out the backlog of desired features and we started a discovery in retail so that we could look at improving the till system in the context of the bigger picture. You can read more about the major changes that followed .

Asking questions to make sure we’re working deliberately and sensibly

My confidence to push back, disagree and challenge has grown such a lot. Asking questions has become very much part of my work. It helps me check in with what’s realistic, what we’re prioritising and whether those priorities have changed, whether the effort something takes would outweigh the value to the user. It helps me make sure we are working with integrity rather than simply following instructions. Working alongside Kim taught me that. It was honestly the best education I’ve had. Here's me, product manager Emma Wailes and Kim.

Lesson learnt: working in the open builds trust

Service mapping and writing weeknotes have been 2 essential processes that have allowed our team to move quickly and efficiently. And both were new to me.

During the retail discovery we invited store colleagues in to help us map their daily processes so we could see the bigger picture and we could see where things were broken. Thankfully I’d done a Co-op Digital masterclass on service design the weekend before which really helped me understand and get the most out of the sessions.

Our service map was on the wall over at head office so that everyone could see. It sparked the attention of our CEO Clare Nesbitt and she asked for time with us to be taken through so she could better understand our work as well as the problems in stores. This is a brilliant example of how working openly means we can.

Also during the discovery Kim suggested I start to send weeknotes to keep relevant people around the business informed. Weeknotes reflect the agile way of working – a little update, often.

Opportunity to try on a different hat

We recently piloted an app we designed to make stock checking more efficient. We identified a colleague need and designed something to meet that need without having to deal with legacy systems. While working on that service, I realised my interest lay in delivery management rather than the specifics of product management and luckily I was able to make the move. It feels good to work at a place where I can pursue my interests and be given the space to learn and grow.

John Sylvester Delivery manager

We’re piloting an app which aims to make it more efficient for our colleagues on the shop floor to find out what stock is available on site, and for our colleagues in the stockroom to get products into customers' hands more quickly.

We’re starting small: store colleagues in 5 of our stores will have access to the app for 2 weeks.

A note to our store colleagues in pilot stores

We’re doing this piece of work to test our app designs, and to see how well they meet your needs. We are not testing you or your ability to use the app. If you are confused or you’re finding something difficult, it’s our job to fix our designs – it is not down to you to change your behaviour.

Be brutally honest with your feedback as this will help us find out what we need to fix – there will be no hurt feelings on our part.

How things work at the moment

The Footasylum Tech team has spent time with our colleagues in stores and we’ve worked with them to map out exactly what’s involved in their daily processes. From this work, we identified pain points together – things that could be more efficient for colleagues, customers and ultimately be of value to the business. One of the areas we identified was the process of checking what stock is available in their store’s stockroom.

There are many slight variations on this but here’s how the stock checking process tends to work at the moment:

1. A customer comes in.
2. They find a product.
3. They find or wait for a colleague on the shop floor.
4. They ask the colleague whether we have the product in stock in a certain size.
5. The colleague radios colleagues in the stockroom to find out (unless they can locate a scanner – if they can, they can use it to check if it’s in stock but there is little trust in how accurate scanners are).
6. A colleague in the stockroom searches for the item.
7. They then report back on the availability through radio to the colleague on the shop floor.
8. The shop floor colleague relays the information to the customer.

What we’re trying to improve

We initially heard that using radios to communicate between the shop floor and stockroom isn’t particularly efficient. When multiple radios are added there’s interference not only between shop floor and storeroom, but some shopping centres end up using the same channels too. This means at times, Footasylum colleagues have to wait for a gap to communicate with their store colleagues – and the more people out shopping, the worse the delay is. Not great for busy days.

Quick research: timing the process

We timed a range of colleague ‘shouts’ from shop floor to the stockroom to see how much of a problem this is. We timed the shouts at different times of day, and on different days of the week, in 3 stores.

The infographic shows the length of time between a customer requesting a shoe, and it is handed over to them. The pale green lines show the length of time it took to confirm the product and size was in stock. The green line shows the length of time between a colleague confirming the product is in stock and it arriving on the shop floor with the customer.

We found that checking stock availability accounted for at least a third of a customer’s wait time. We then compared this to some other retailers to see if they were encountering the same issue. We also looked at what tech they were using to check stock.

But why bother speeding this up though?

Five minutes might not seem like an unreasonable amount of time to wait for the privilege of buying new trainers. True. But we know the process could be much more efficient too.

We believe that if we can improve the selling process for our colleagues so they quickly have the information customers ask them for, we will:

1. Improve the chances of customers choosing to spend their money with us.
2. Free up colleagues’ time so they are available to help more customers.
3. Help colleagues appear more approachable – they’ll no longer be glued to their radios.

The questions we’re trying to answer during the pilot

This is a pilot. The reason we’re testing the app in only 5 stores is that we don’t yet know how well our designs will work. It is much easier, cheaper and less confusing for colleagues if we start small, test in a few stores, listen to and analyse feedback and make improvements based on it, rather than trying to retrospectively fix a load of problems after a huge rollout.

We’re trying to find out:

1. If the app can improve the time and accuracy of checking stock from the shop floor (and if so, can we move towards removing the existing scanners and radios?)
2. How we can collect and use data to ensure we have the right stock availability in store for our customers.
3. What’s missing from the app. We’re testing what we’ve created and will compare it to the existing radio process.

We’ll use 3 research methods

Over the 2-week pilot, we’re using 3 ways to find answers to our questions. The mix of methods will give us a combination of qualitative information (opinions and observations) and quantitative information (data) – a balance of the 2 will help us make better-informed decisions about how to improve and iterate.

1. Diary studies

We’re asking 20 colleagues to use the Indeemo app to take pictures and record the screen of the device whilst they perform specific tasks and make notes about the new processes. From this, we will hope to find out how intuitive the app is, what problems colleagues are finding, and what the radio helps them do that we may need to incorporate into the app. The best bit about diary studies is that the colleagues involved in the pilot don’t feel as if they’re being watched and will record their actual actions and not just what they remember about them.

2. Interviews

These will be adhoc with colleagues throughout the trial period to find out what problems they’re having on a regular basis if using the app has improved their experience.

3. Data

As colleagues use the app, we’ll collect data, for example, what’s in or out of stock, if the app crashes, and how long it takes for the item to show up on the app.

Where we’ll go from there

After the 2 weeks pilot we’ll have a wealth of research to analyse. The team will iterate and improve the service and get it back in front of store colleagues as soon as we can.

We’ll blog when we have updates.

Emma Wailes Product manager

My route into becoming a software engineer wasn’t something you could have predicted 5 years ago by looking at my CV.

A textiles specialist with an interest in innovation

I’d worked for Footasylum for around 2 years as an assistant garment technologist before I joined Footasylum Tech. I was based in our head office in Rochdale and my job was to assess the quality and design of samples that were sent to us from our factories in Turkey and China. I’d look at samples and recommend changes on things like fit, colour and style features.

I have a degree in Textile design for Fashion and Interiors and an MA in Textiles for Fashion so on paper, this was exactly the kind of role I was destined to be doing. However, the modules I chose throughout both degrees leaned heavily towards stuff like tech-forward and responsive fabrics, laser cutting and 3D printing. These topics aren’t traditional textile design – they’re innovative, experimental and progressive much like the technology industry, so perhaps my switch from textiles to coding isn’t actually such a leap.

Time to go

Various things had been making me feel anxious at work which made it difficult for me to enjoy and take pride in it. I knew I didn’t want to feel this way about my worklife. My dissatisfaction had been building for a while but it came to a head in September 2019 prompting me to do what I’d been thinking of doing for a while: I handed my notice in.

Self-motivation, determination and a slice of luck

At this point I’d been studying Code Academy courses and YouTube tutorials about HTML, CSS and Javascript programming languages in the evenings. I’d been doing this for a few months because my friend – who was originally a fashion merchandiser – was learning to code and said I should consider going into coding as a future career option.

When I handed my notice in, I was part way through applying to a full-time coding course. It was a bit of a risk because at that point I hadn’t been offered a place anywhere. But my god I was determined that I would be! And I was.

A week before the date I was due to leave Footasylum, Sarah, a colleague in HR (who has since got into coding), heard that I was leaving to do a coding course. She told me that Footasylum Tech would sponsor me through a 3-month course at Code Nation. I jumped at the chance – I’d have a job with mentors and a supportive team waiting for me once I’d completed it.

There were 6 weeks before the course started so I spent them with our IT retail support team. I began to learn about systems and I rang up stores each week to seek out problems instead of waiting to be told about them. Store colleagues felt they were being heard which was great for our relationship.

Starting a new career remotely

I joined Footasylum as an apprentice software engineer at the end of March 2020. Lockdown was in full swing. It’s not the ideal way to start an entirely new career but we adapted in-person introductions to remote ones, and so far we’ve been able to work around major obstacles.

I’m one of 4 people within the core Product Information Management (PIM) team. We’re creating a centralised management system – one source of truth – that contains consistent, enriched product information to support different areas within the business, such as eCommerce and Marketplace. It’s a classic ‘digital transformation’ project where we’re aiming to bring together all sorts of information from various systems that don’t tend to speak to each other so it’s getting information is simpler and there’s less chance of error for our internal users.

The course is over, the learning isn’t

Every Thursday, me and Sarah Weeks (another apprentice developer) spend all day being mentored by senior developer, Ian Wells. We follow a loose sort of syllabus – subjects like TDD (Test Driven Development), SOLID principles, and OOP (Object Oriented Programming), but if something comes up in our teams during the rest of the week, we can talk through it. We’re also big fans of the online kata coding challenges at Code Wars.

The PIM team’s Principal software engineer, Chris Wilson, made me his understudy so although the project only involves a limited amount of coding, Chris involves me in everything to do with the code base or technical aspects. Currently we are focusing on setting up and testing code, that will integrate product information coming from one system into the PIM. This has really helped me to sharpen my skills within javascript and improved my confidence using unit tests within code.

The relationship between work culture and personal confidence

I’m relatively new to tech but I’m not new to the world of work. I would love to see all workplaces adopt the ‘prime directive’ – the idea that a team:

“truly believes that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

From what I’ve seen, cultures where trust (rather than blame) is the default, help individuals grow and workplaces get the most out of their colleagues. The fear of being blamed cripples productivity and progress for the workplace but I’ve also seen it crush individuals’ confidence.

In my new team, I feel safe to ask questions. I don’t fear looking ‘silly’. Tech and design people love solving a good old complex problem so if something goes wrong, their mentality is to ask how we're going to fix it. It’s never to ask whose fault it is. I put this down to a flatter team structure where there’s no jostling for stardom – everyone’s expertise are integral to team success.

I’m happy to say that my confidence is on the up, I’m looking forward to completing the apprenticeship, maintaining a healthy work life balance and helping to solve some big problems. Bring it on.

Ruth Clare Software engineer

My route into software development was a winding one – it certainly wasn’t something I’d had my heart set on doing when I was growing up. But sometimes, you have to figure out what you don’t want to spend your 9-5 doing to find out what you’ll find both challenging and rewarding.

This post is about feeling settled and excited in my role as a software engineer.

Stops along the scenic route

I have a design background. I studied the thought process of Design at Goldsmiths which touched on a really wide mix of areas such as politics and sociology. It was a fascinating way of looking at the world and its systems and one of the main things I took away from it was to always ask: why? It’s a lesson that’s stayed with me. My degree wasn’t a direct way into a specific career though and while I liked Design, to me it always felt like something was missing.

🍹 Bar work followed uni – I came out of my shell a bit.

🌍 Travelling followed bar work – I didn’t want to head home to Chester.

I think after being in London for 3 years for university and then seeing a bit of the world, going home felt like a wakeup call and I told myself I’d only go back if I had a real reason to be there.

Enter Northcoders bootcamp.

Learning to code

I’d been thinking about learning to code for a while and I’d done an introduction to programming course with Northcoders before I went travelling. Without getting a feel for it, signing up for the 9 to 5, every day for 12-weeks bootcamp would have felt like an expensive and time-consuming risk. Luckily, the introduction helped me realise that I liked the idea of learning a tangible skill which – by the end of the longer course – I’d be able to use to tackle problems and build something, perhaps that I had designed.

For me, being creative within the rules of code felt more focused than the abstract design stuff that I’d done my degree in where there wasn’t always a right answer.

Presenting my work, presenting myself

So I completed the Northcoders Javascript bootcamp . I enjoyed the 50 hours of prep work leading up to the interview because it was already pushing me to commit to myself and the course. I enjoyed the 6:30am commutes to Manchester that I dedicated to extra coding time. These were massive indicators I’d made the right decision.

In the last 3 weeks of the course we worked in small teams on projects that built our confidence and challenged our abilities and approaches with new concepts, no longer heavily reliant on the tutors. We presented on our last day to students from the rest of the bootcamp and potential employers were invited too – Andy Norton, the dev manager at Footasylum Tech came along.

At that point, Footasylum Tech wasn’t hiring and honestly, even if it was, I wanted to do my research and find the right place to start my dev career. I’d been out of university for a while and although at this point I’d figured out what I wanted to do, I wanted to find the right role at the right place rather than take the first job at the first place that offered me one.

I’d taken a plunge, invested in myself and retrained. Now I wanted to make sure I’d be around people who’d also invest in me and my progression.

Feels for Footasylum

I applied for roles elsewhere but there was something about the Footasylum interview that made the combination of people who interviewed me (Kim Morley, Ian Wells and Andy Norton) – and their attitudes – really appealing to me.

They made it clear that they had read my CV, they knew about my experience (and lack of experience!), and that wasn’t what mattered at this point. There was no tech test, they just wanted to find out what I’m like and what my attitude to learning and collaborating is – essentially whether they thought I’d be a good cultural fit.

They thought I was. And I thought they were for me too.

The environment was what I’d wanted: open, honest, no need to pretend I knew more than I did.

Experiencing 2 teams

I joined in November 2019. I was part of the Retail Store team – just in time for the busiest period: Christmas. I was apprehensive about the demands on us and whether the team would be available to support me during such a hectic time. I shouldn’t have worried. They helped me find my feet in the company and in my first tech role.

At the end of January this year I moved over to work on a new stock runner retail app alongside Equal Experts. Here's me, Richard Rauser and David Moore (both Equal Experts) and Emma Wailes from FA in the office.

It meant I was switching my focus from an established code base to being part of an app developing from inception. I also went from using Javascript on the bootcamp to learning Java in the retail team and then going over to native iOS and Swift for the app. My Footasylum mentor Ian Wells advised me on the power of being almost language agnostic with the ability to adapt approaches and processes across languages.

Mentors and supportive culture

I have monthly check-ins with Andy Norton, and I’ve closely paired with Richard Rauser and other Equal Expert developers which has really helped with my progress learning Swift. I’ve been so impressed with how closely the devs and greater app team work. Working on my own stories I am given the room to puzzle over the task, but I am always able to ask for help when needed – even throughout lockdown I’ve felt supported.

It’s a luxury to be in this position but honestly, the support I’ve received is what I’d expected after the first interview.

Developing leaders not just developers

Footasylum has been keen for me to get involved with meetups in the North West too. There have been some amazing ones for females in tech, for example, Thoughtworks hosted an Assenty event to showcase female tech founders which was inspirational. The company also sent me on Lauren Currie’s public speaking course – 3 days later I was presenting our app to the wider Footasylum teams and stakeholders. Here's a photo from my presentation.

In the next year, I’d like to find a mentor from somewhere else in Footasylum Tech and improve my understanding of the wider department.

Hannah Williams Software engineer