Cookies 🍪

This site uses cookies that need consent.

Project Managing a Monorepo

Interview with Ian Arrowsmith Project Manager and Will Stenner, Senior Front End Web Developer

When does the story start? Moving the tech stack and taking a different approach to website builds…

IA It started a couple of years ago, we'd finished a version of adapatavist.com and then we were asked to deliver a site for two other The Adaptavist Group (TAG) brands in fairly quick succession. We did a component based approach at first, and then we had discussions (as a team) around the idea of taking it further. There’s a bit more of a need when a client like Adaptavist says they want to have a new website and they want it yesterday, and they want it to have all these features. It's hard to deliver as quickly as they would want…

Typically, how quickly do people think a website can be built?

IA Yes, that’s a good question!  When you've got tools available like Squarespace or WordPress you can pretty much as a marketer build a site within a few weeks – if you want something simple. So people sometimes have it in their head that it's only a couple of weeks, but that's for whatever they can achieve using their own methods – rather than what we would be able to deliver with our specialist skills and experience behind it. 

...people think it's only couple of weeks (to build a website)...based on what they can achieve using their own methods – rather than what we would deliver with our specialist skills and experience...

Even if you replicate an existing site?

IA Yeah, but even when you do that, there's still a lot of stuff you have to do that's unique to that site. When we started to talk more about doing Scriptrunner, working with the team there and looking at what they wanted, that helped us to solidify the approach.

Now that you’ve rolled out a monrepo approach over many projects, is there still a feeling of learning every time another site is put out? 

WS Yeah, definitely! This approach is quite nice as those learnings can be directly applied to the single source of truth now. Previously your learnings wouldn't be wasted, but you could only apply them on the next project. Now, I can see if something doesn't work and go back and fix it – and it's not a massive job. I don't have to fix 3 different projects. If you find a problem with one, you can pre-empt that problem across multiple sites.

Does that mean you're now a Monopo expert?!

WS I wouldn't go that far! We've learned tons about this approach. Whenever something’s bespoke, there’s always learning for everyone. Any dev team that’s using new technologies – they’ll tell you – they’re not an expert, they’re having to learn as well. But yes, we are much closer to being experts!

Ian, does this mean that you manage the project differently than you would normally?

IA I manage every project differently, each one requires a different approach based on the client needs. A neat way to think about it is the monorepo is the broad programme of work, and each website is a project within that programme. I try to make sure we make progress on the programme of work with each project. 

I manage every project differently...each one requires a different approach based on the client needs. 

Are you trying to advance all projects at the same time? Or are you trying to control the advancement of individual projects?

IA I’m trying to advance the overall program of work which will be for the benefit of the collective of customers. But the individual customer just wants their website, so I try to ‘thread the needle’ of benefiting all the customers, but help one customer at the same time.

So you look at a particular project and see where learning can be gained across all the projects? 

IA Yeah, I’ll look to find the advancements we can make in one project which will then benefit the next project. For example, with the Scriptrunner site, we started off doing a design system and components in line with their budget and their timeline aspirations. Then with TAG we changed the structure of the project a bit. 

So from the dev PoV, what does a ‘program of works’ look like to you?

WS What's quite interesting is I've always just worked off one Jira board where all our tasks are. We had to make a different board and maintain it for just the monorepo, then there were the separate boards for the different sites. We’ve never worked like that in the past.

Why did you start to work like that? 

IA We needed to recognise more of the research tasks or structural tasks that weren't necessarily to the immediate benefit of the brand team, but were still worthy of us doing. 

So that's more than a new tool, and a new way of managing it. And can that be a bit unsettling because you have the new bespoke tech as well…?

WS As a developer, I absolutely love the thought of that new approach…monorepo is not really client specific – everyone's gonna benefit from it. And with the Jira boards, it’s making it easier to manage. It’s very logical, it makes loads of sense – I can get on board with that one!

IA You could make one mega board, which captures everything in one view rather than having 5 different views. And that's something I'd like to get closer to at some point because it's easier to think about each initiative and how it all links together.

Are there things you're expecting to still learn?

IA I think there's more stuff we need to do on the design front because we haven't got that as integrated into the project as we'd like to. Will’s recently implemented Storybook…so there’s learning on that front and there'll be other stuff as well. Like, how we handle deployments, or how we scale things further. I'm also conscious about communicating benefits back to the clients. 

So in terms of Retrospectives, do you try to do more of them?

IA It depends. Where a project moves quite quickly we’ll do them at specific points, but it’s hard to make time for doing more, and they may not be effective. On another project, we suspected we weren't working as efficiently as we could, so we had a retro to take a moment and see what we could do to improve, and that helped. But often it’s about moving forward rather than looking back.

You’ve mentioned how many new elements there were to begin with, and that the effects on the team were hard. How do you keep motivation, energy…?

WS I think we've got a really good solid squad with a really light-hearted mentality. People aren't precious, we're happy to be told if something’s not right. Ian’s obviously the one who has to manage the client, which is the hardest part, probably. So as a team of developers it was stressful because everything was taking longer than expected, but we were able to still smile – I think you have to find the funny side of things. Ian did a good job of keeping us more relaxed; stressed people don’t do good work.

IA Yeah, you have to establish your safe environment, make sure everyone feels comfortable addressing things, and that's partly what you try and do in the retro anyway, like there’s no point having a retro if people aren't going to say things. You sometimes have to be comfortable addressing issues with people. So that's part of the safe environment, but then you also need to be equipped to make decisions that will pivot the situation. Like; ‘How do we resolve this to improve it?’ Also, something I try to do but it's not always easy. You have to try and be an energy bringer – be a radiator, not a drain!

You have to try and be an energy bringer – be a radiator, not a drain!

Let's chat

If you fancy a chat about anything to do with digital marketing, contact us and one of us will be in touch. We're ready, are you?

Contact Us
contact Brew Digital

Stay up to date

Sign up to get the latest content from Brew Digital delivered straight to your inbox.