engineering

Our Engineering team’s priorities

Co-op

In February, we published a post explaining how and why we’ve restructured. It focused on our colleagues whose expertise lay within Design, Product, Delivery, SEO and CRO who we now call the Co-op Experience team.  

Earlier this year, the Experience team moved into Co-op’s Digital Technology function. Engineering is one of the disciplines that sits within Digital Technology. Experience and Engineering often work together in multidisciplinary teams to bring the right combination of expertise together, at the right time, to create value for Co-op customers, colleagues and the business through our products and services. 

Alongside this, Engineering has its own specific aims that ultimately support an improved, seamless customer experience. 

Here are our priorities for the next year. 

Make it easier for engineers to get on with it 

Many organisations that build web and cloud-based products and services have internal platform teams focused on improving engineering productivity. Co-op is no exception. We’ve recently brought an Engineering Productivity team together – a team of engineers who protect the rest of our engineers’ time by removing challenges that get in the way of us delivering value for customers and colleagues. They’ll do this by identifying where we’re duplicating effort across the engineering community and as far as possible, they will create standardised approaches.  

Our Engineering Productivity team will harvest, build and curate a collection of engineering resources that help to accelerate the creation of new products and services. These will sit alongside the existing Experience Library and Front-end Toolkit already curated by other parts of Co-op Technology.   

Examples from the Engineering Productivity team’s roadmap include: 

  • common build pipelines so we can remove maintenance responsibilities from engineers, and make it easier to spin up new teams 
  • identifying useful common components, such as automated security testing in the build pipeline, and productionising them to make them available to all engineers across the estate 
  • how we bake standards into artefacts so that teams spend less time checking compliance 

We believe that by reducing the cognitive load for engineers, they’ll be able to focus on solving new problems rather than spending time on problems that have already been solved elsewhere. 

Developing ‘product mindsets’   

It doesn’t matter which multidisciplinary team our engineers are part of, or whether they’re responsible for foundational platforms, business platforms or products, everyone needs a product mindset. We want to develop and embed this thinking more. Here’s why.  

Since the early days of Co-op Digital, our engineers have been working closely with Design, User Research, Delivery and Product as part of multi-disciplinary teams. Together, we have been focused on delivering customer value through early delivery, rapid feedback loops, and test-and-learn to create effective, usable products and services that perform well. Because we’ve approached things with the same ‘product mindset’, we’ve met the needs of both internal colleagues and external customers. We’re looking to apply this mindset across our wider technology estate. 

We consider platforms to be like inward-facing products and a good example of this is the Co-op’s Food E-commerce business area, which has become particularly important since the start of the pandemic. Within it, is our On-demand groceries service which lives on the coop.co.uk platform, as well as convenience and delivery options to order Co-op products through Deliveroo and Amazon. We have multiple product teams around the Food E-commerce space providing value directly to our customers. These product teams draw on services provided by a set of platforms teams which do things such as integrating external marketplaces and courier apps; doing the background work in terms of search functionality and data loading; or providing standard e-commerce functions such as baskets and product information. These platform teams, such as our Unified Commerce Platform, focus on the needs of their own internal customers, such as the Online Shop team, and evolve their own roadmaps to meet the needs of those internal customers. 

The Co-op Food E-commerce business is just one example of how we are adapting the way we work to put our customers, whether external or internal, at the centre of our engineering delivery.   

Continue to support engineers in a very varied landscape 

Co-op was founded in 1844 so it is a really old business. We have many business areas, and there are multiple products and services within each of them. Those products and services have been created at different times – some with the foresight that the internet era is here to stay, others not so much. This means that our engineers can find themselves working across a large and varied portfolio containing a variety of challenges from early-stage discovery work on greenfield products through to heavy lifting work on some of the more established systems which power our £10 billion turnover retail food business.   

We try to ensure that our engineers have a broad toolkit of technologies, techniques and practices which they can draw on to do the most effective engineering they can on the systems they are working on. Some techniques such as test-driven development are very much core practices, whereas the use of other techniques will vary based on the context. Teams might use a mix of ensemble programming, pair programming or pull requests based on things like the system they are working on; the makeup of the team, and the work they’re doing.  

Our teams can adapt their ways of working over time as the team context changes. As long as they conform to our software development standards they can work in a way that is most effective for their context. 

One of our priorities is to equip our engineers with a broad toolkit of techniques and practices that they can choose from to address the specific challenges they are facing. They can improve their toolkit through our Engineering Community of Practice sessions, code club or video club. 

Increase pastoral support 

We’ve recently made changes to alter the Engineering team’s structure. We’ve moved away from a set-up where almost everyone had line manager responsibilities towards a more simplified structure. We’ve done this because we found that those people were effectively doing 2 jobs: engineer and line manager. This isn’t necessarily the direction that everyone wants to go in and although managing others helps grow people skills, changing context is hard. So, we’ve introduced Engineering Managers. Their role is 100% focused on people, their development and helping them map their careers. It means one-to-ones are now more productive because line managers (now Engineering Managers) are no longer juggling 2 jobs. 

Danielle Haugedal-Wilson

Head of Engineering

We’re hiring talented and enthusiastic people with all levels of experience. Read more information on our jobs page.

Hello from Engineering

@ruby_gem

I’m Gemma Cameron, the Engineering Practice Lead. I look after the Engineering Practice and Community; making sure we have great engineers at Co-op. We’re going to be sharing more content about the products and services we’re working on throughout 2022, but from more of a technical angle. They’ll be a little different to what we’ve previously shared on the Co-op Digital blog, but just as insightful. All of our Engineering blog posts will be tagged in the engineering category, so you can easily find them too.

Engineers play a huge part in our Technology team.

Our community is made up of Quality Analysts, Frontend, Software and Platform Engineers who work remotely from all over the UK (or in our Manchester / Eastleigh offices if they chose to). We work collaboratively in multi-disciplinary, agile product teams and currently have around 60 engineers across 15 different teams.

In our Mega CoP, we have an update from our Head of Engineering Danielle Haugedal-Wilson, lots of breaks for cups of tea, breakout sessions, lightning talks, and group chats. The group chats are a recent addition from us all working remotely. With small groups of 6 or so engineers, which changes every month, we get to know each other and what we’re working on. This helps us connect across the community on a more personal level, and helps put names to faces. We do this over Microsoft Teams and tend to use Slack more for chatting asynchronously.

Looking back on 2021

As the year closes, we celebrated our last Engineering Community of Practice get-together on 17 December. We wore our festive hats, we had a panto, a brew and a natter, some coding fun and even poetry! All entirely remote.

Join us at Co-op

We’re currently hiring Engineering Managers to join our community, so if you’re an experienced engineer who wants to concentrate on career coaching (line management), recruitment and technical training of teams, click here to find out more and apply. This is an engineering leadership role where you’ll also be involved in shaping and setting the strategy and direction for Engineering at our Co-op.

We’re growing our Engineering community in 2022, and are looking to hire over 50 new colleagues from apprentice up to leadership level. If you’re interested in working with us, head over to our Work With Us page to see what’s available right now, or fill in this form to register your interest and we’ll let you know when new roles are advertised.

Introducing our software development standards

Co-op2 Comments

There are many software engineers across Co-op Digital – they’re responsible for building our products and services. Because they’re all great and eager to build things well, it’s easy to assume that everyone will build things in the ‘right’ way.

However, that’s a risky assumption and it’s not always the case. Instead of leaving it to chance, Ian Waghorne, Andrew Liddell and myself started to create software development standards and pin down Co-op Digital’s previously unwritten guidelines.

Our aim was to come up with a set of software development standards that:

  • could be used across Co-op Digital
  • take into account the uniqueness of Co-op products, services and platforms
  • could potentially be used throughout the Co-op Group

The benefit of having a set of standards is to make sure engineers don’t move too far off track and build things in a way that their stakeholders aren’t comfortable with.

We started small and got feedback quickly

The 3 of us quickly compiled a set of standards. They were short notes, just enough to get feedback. When we shared them with the other engineers intense discussion followed and the feedback was that we’d been too prescriptive.

At Co-op we have many different services at various stages of their life cycle, each with different contexts. The feedback had told us that (fairly obviously) one size wouldn’t fit all – or rather, a set of standards with narrow and rigid boundaries wouldn’t fit all. The engineers working on certain services needed more flexibility to get the job done effectively.

Balancing flexibility with governance

The main challenge was making sure the standards were flexible and worked for our engineers but still met our wider stakeholders’ needs. What we needed was just enough governance to allow us to keep working quickly, while providing a good level of reassurance that we were not exposing the Co-op to an uncomfortable level of risk. We coined the term ‘outer governance’ to help us frame this.

Striving for clear, concise standards

We think that figuring out whether your product or service meets each of the standards should be through a conversation both within a development team and between the team and other stakeholders. To help facilitate the conversation, we thought carefully about how to word the standards so there’s less room for misinterpretation.

So, each standard contains:

  • a ‘motivation’ to explain why this aspect is important
  • a brief explanation of the standard with an example
  • a few questions to help teams assess the state of their product or service

Standards can be quite abstract and we felt that including the questions would help people really consider how each standard applies to their work.

Software standards could help us assess the condition of a service

In software development, teams often build up levels of ‘technical debt’. Technical debt happens when we choose a lower-quality solution in order to deliver sooner and get quicker feedback on whether something works. You could think of it as the equivalent of a business borrowing money to get its product to market sooner. Although taking on an amount of technical debt is a common practice in the technical world, we need to be sensible because it means we’re taking on more risk. Like any debt, technical debt needs to be incurred intentionally, managed carefully and, most importantly, paid off at some point.

Quite rightly, stakeholders want to know about the level of risk involved in a project but in most cases, they’re not digital experts. We believe that software standards can be used to provide a consistent view on the technical debt being carried by a service. By rating each standard for a given service we can provide a view of technical debt at a level that stakeholders can understand.

Rick Healy and I have been working on how we can represent this in a clear and simple way. Our next step is to try it out on some of our services and see what it tells us and if it’s helpful for those services’ stakeholders.

Screen Shot 2018-06-25 at 10.09.57 The Assessment Wheel

Engineers, we’d like your feedback

You can read our software development standards.

This is just the first version and we’ll be iterating them as our teams use them. We’re keen to hear feedback from internal and external digital teams and in particular engineers so let us know what you think below.

Andy Longshaw
Principal Software Engineer and Tech Lead on Co-op Guardian

Lesson learnt: test in context as soon as possible

Co-op2 Comments

I’m holding my hands up and admitting my team recently made a mistake. We’re guilty of using high-tech laptops to build software intended to run on far less powerful devices.

Testing in context is something all digital teams should do automatically. But while chatting to a couple of other software engineers, I learnt that forgetting to do this is a common developer sin. Or at least, it’s more common than it should be.

I hope that by writing this post it’ll help keep it in the forefront of people’s minds.

What we were working on

I’m part of the Membership team. Recently, we wanted to find out if members would find it useful to check their rewards balance at the start of a shopping trip, so we’ve been building a prototype that members can use in stores.

Where we fell down

The prototype we were building was difficult to run on the device we’d be testing it on, ie, the small Android tablets in stores. The tablets weren’t chosen for their performance, they were chosen so we can keep the cost down while we’re still experimenting. To make the prototype run faster, we’d been using the browser on my laptop while we we doing the development work and showing demos to the team. In other words, we’d prioritised speed over accuracy.

A few days after spinning up the prototype, we tried it on one of the tablets. It didn’t work in the same way. We’d wanted to get it into the hands of real users as soon as possible so we could check our assumptions and find out how well it met user needs so by this point we’d booked in some user testing in store. Unfortunately, we couldn’t fix it in time.

Not a disaster, just a delay

Working in an agile way allows us to overlook relatively small things and make little mistakes like this. The beauty of agile means we’re never going to spend an outrageous amount of time or money correcting mega problems. For our team, we had to delay the user testing which was frustrating (we should’ve known better), but it wasn’t a disaster.

Easy to fix

We spent a day accounting for the differences between the Android tablet and the browser on my machine. We used a service called ngrok.io so the tablet could use the website running on my laptop and we could develop against the low-powered device. This way we could test over a representative 3G network. It’s what we should have done all along.

But easy to avoid too

As I said, testing prototypes in context or in an environment as close to reality as possible is basic but sometimes, for whatever reason, there’ll be occasions when we trip up.

To avoid this:

  • keep in mind the device, or types of devices, your users will be using your product or service on, both before and after you begin building (this is the big one, obviously)
  • involve your quality assurance testers (QAs) as early and as frequently as possible
  • run the software on realistic devices as early and as often as possible…
  • …but never assume that emulating a device in a browser will be exactly the same as it would on a device

We’ve learnt our lesson. Let this be a reminder to you!

Paul D’Ambra
Software engineer

Adam Westbrook: life as a platform engineer at Co-op Digital

Co-op

(Transcript) Adam Westbrook: So I’m a platform engineer here at Co-op Digital. I’ve been here 3, 4 months now. Day-to-day we sort of work with the development teams and the service teams and stuff like that: building out new infrastructure projects, working with the development teams on new products for membership.

There’s lots of opportunities for engineers around here to work with big engineering teams and stuff like that but there’s no other kind of companies around here they’re owned by their members and doing stuff that Co-op does for local causes and so it’s not just a normal big engineering team at a big company. You’re contributing to something a bit more.

It’s really good having everyone on one very open floor, we’re all working together, we’re able to proof of concept new products really quickly and just the of level of communication up here is really good, everyone can speak to each other, everyone knows each other everyone’s close and it’s just a really sort of good environment to get stuff done in.

So I think the thing that most enjoy about working here is being able to work with the other engineers and the other parts of Co-op Digital to really sort of push out new products and projects and things like that, really quickly. It’s a really great team here. The work that we do is really good and as such a focus on people working together and collaboratively and sort of learning and developing from each other and that’s often really difficult to come by. And just the culture here is really good that promoting that.

Adam Westbrook
Platform engineer

Life as a software engineer in Co-op Digital

Co-op

Software Engineer Nancy Richardson shares her thoughts about working in the Digital team.

(Transcript) Nancy Richardson: What I love about working here at Co-op Digital is I feel that at the end of the day that I’m making a difference. The products that we have are very well thought out and I’m also excited about the future as I’ve heard of some of the things that Co-op could be working on in say five years from now. Also I enjoy the diversity of the people I work with, we’re all different ages, different backgrounds.

I was attracted to the role because of its full stack and polyglot approach. This makes the work very varied, you could be working in the front end, back end, or on DevOps, and every sprint could be focusing on a different area of the stack, so this makes it very interesting. And I come from a Ruby background but now i’m learning Java which is really different from ruby but I feel very supported.

I’m learning from my colleagues on the job and there are also code show and tells. There’s even dedicated learning time. I think now is a really good time to join the Co-op because Co-op Digital is starting to expand so you have more influence in helping develop our standards, our ways of working, our teams stack and our practices.

Nancy Richardson
Software Engineer (Membership)

We’re looking for engineers at the moment. If you’re interested take a look at our Work with us page.

 

Simon Stead: life as a software engineer at Co-op Digital

Co-op


(Transcript) Simon Stead: My name is Simon. I’m a software engineer and I work on the Digital team that works with Food in Co-op.

So I already knew a few people who worked at the Co-op from my last job and they told me how fantastic it was to work here, how nice everyone was so I thought I’d apply and then I managed to get in.

We’re working on a multidisciplinary team so there’s me, some other software engineers, but it’s lots of user researchers, interaction designers, content designers, delivery managers, everyone is just pooling all of their resources and sharing all of the work and just getting your hands dirty at the same time.

So we’ll all be sat on the same table and I don’t often feel like a software developer because we’re all just trying to solve a common problem together. If that’s data, if that’s design, if that’s dev, if that’s user research we all pitch in and do a lot of the same stuff together.

I think the best thing I like about working at Co-op is that I can just try new things all the time, I get so many new opportunities and I get to engage with so many different people, be that people in Co-op Digital in the Food business, different stakeholders, area managers, store managers, whoever they may be.

I’m autistic, I’ve got Asperger’s syndrome and so one of the really nice things about working at Co-op and Digital is that I know I’ve got a wealth of support behind me so if there’s any problems I’m having I know I can talk to whoever I need to to solve that. If I need flexible working hours or anything like that it’s just all available here.

So we work over here at Federation and we also work over in Angel Square but Federation, the open space, the air, the light, the colour, the beanbags, everything just makes it such a nice open place to work and I feel like that really gets reflected in the digital products and services that we build.

Working at Co-op, I always thought I’d be the kind of person who would just like hop from job to job and never really stick to one place but I honestly can’t see any reason that I’ll be leaving anytime soon.

Simon Stead
Software engineer

We’re hiring software engineers. Find out more and apply.

What it’s like working in Digital Engineering

Co-op1 Comment

Gemma Cameron, our Principal Software Engineer speaks about what it’s like to work in Co-op Digital and Digital Engineering.

(Transcript) Gemma: I love the variety of projects that we have going on and all the people that are working on them. So we’ve got not just amazing engineers, we’ve also have got some really great product owners, delivery managers, really amazing BAs and the designers are just incredible and we’ve got all the user experience team.

We’ve got some great people working on really innovative cool projects and, you know, what comes out of it is actually doing something good.

I’m supported in all the community stuff that I do outside of work. So I get to you know, Co-op are helping out with Hack Manchester so we support and sponsor Hack Manchester, I also get to run events here, we are sponsoring the Liverpool Girl Geeks Academy, so it’s great getting girls who are like 12-14 to get to some experience programming.

We sponsor events, we attend events, so we were at the Manchester Digital Skills Festival not so long ago and that’s great meeting some of the new graduates and people are looking for work and getting to tell them about the story of what we do here, that we’re bringing brilliant people in who are really good at collaboration, who really care about software quality and you know we’re doing all the good things like test-driven development.

We’re building these great teams but we don’t expect everybody to know all the tools that we’re using or the languages that we’re using. So we have got some people who showing all these great people and behavioural qualities, but they’re not so good on Java and we’re giving them time and space and we’re coming up with a syllabus to give them that training.

The same with test-driven development and looking at all that quality. We have community of practice and we get together as a group of engineers and work out what our, sort of, level of quality should be. I also want to try and see if I can get involved in some of the projects from inception so actually working together with people and talking to them about what their needs are, going to have discovery phase and creating like little alphas that would be awesome because I’ve worked in a start ups before and I enjoyed doing that experience and it would be nice to do it for a more worthwhile cause.

Gemma Cameron
Principal Software Engineer

We’re looking for software engineers right now. Join us.

Making better, joined-up decisions with the engineering community

Co-op

This month, it’s 3 months since we set up our engineering community for software engineers, platform engineers, service managers and quality analysts at the Co-op. It’s early days but it’s already helping move Co-op engineering in the right direction.

Getting together with people who do similar jobs helps us all be more joined up which is really important, especially in a place as big as the Co-op. Without a community, we’d be working in isolation because our day jobs are within Co-op Digital, Co-op Legal Services or Funeralcare.

When we began meeting regularly, we identified the areas we need to work together to develop, including how we support training and development and coming up with development standards.

Picture of our Engineering community of practice

We’ve created infrastructure standards

I was really pleased to see that practices such as Continuous Delivery and Infrastructure as Code were already well established when I joined Co-op Digital 6 months ago. However teams were working in isolation at that point. Lots of them had similar problems and were tackling them in different ways. This meant that getting some of the services we were launching to a point where they were secure, reliable and supported was trickier than it needed to be because there was quite a bit of rework involved.

To make things simpler, we spent time during our community of practice meet-ups to create shared standards for our platform infrastructure. There’s still plenty to do and these things are never really finished of course, but we’re now in a much better shape and future projects will follow a much easier path. Most importantly, teams are more empowered to get on with stuff and do their job.

We’re also working on standards for how we’ll support cloud infrastructure across several teams. This work will sit with our Digital Operations team which is forming steadily.

Making better technology decisions

Out of that also came a clear need to provide better support around making technology decisions. We want teams to be empowered, but at the same time there’s always going to be a limit on how many different technologies we can support and maintain. Our approach has been to try and provide really great guidance so teams can make decisions in context rather than needing meetings to make decisions. It’s all still quite early days so again we’ll hopefully come back again soon and update on how it’s getting on.

We’ve been hiring

C6VVNKlWgAMmd3r

We’ve worked with some great external companies while we’ve been adding gradually to our in-house expertise but we’re at a stage now where we’re looking to bring in a significant number of software and platform engineers. The Co-op Digital team and the wider engineering community of practice is looking forward to new talent joining us. From there, the culture of the team will grow and strengthen.

If you’re interested, take a look at our Work with us page for the roles we currently have open. We’ll be recruiting for engineers for the Funeralcare team shortly.

In the meantime, sign up to the blog and follow Co-op Digital on Twitter.

Rob Bowley
Head of Engineering