In January 2022, MirrorWeb’s product and engineering teams shifted their way of working. They adopted the Shape Up methodology, a product development process popularized by software titan Basecamp. Following the conclusion of MirrorWeb’s first six-week cycle, we caught up with Jamie Hoyle and Mark Johnson, SVPs of Product and Engineering respectively, to learn more about how Shape Up has been working for MirrorWeb.
MW - Good afternoon guys. For those that aren’t familiar, how would you summarize the Shape Up ethos?
J - It’s about giving small teams of two or three developers/designers a scope that is rigid enough to give them some direction about what they should build, but loose enough to ensure that they have autonomy and the power of decision-making and creativity.
It’s also about giving them a set time (six weeks) to go away and export an idea, without interruption, and come out of it with a product. So it focuses teams over a short period of time and makes sure that they have the headspace and the freedom to be able to build something great.
M - Shape Up allows everyone in the company to be involved in the decision-making process. Your most senior stakeholders sit down together, read through the pitches and have a discussion about what we should work on. They sit as a democracy and decide.
Anyone can pitch in at the ‘betting table’. C-level positions can get to choose what the engineering team will be working on with the next cycle. So it really involves and invests in the whole company.
MW - What was it that prompted MirrorWeb to adopt the methodology?
M - I think it was a couple of different things.
We noticed that there was a big impact from the lockdown process and our teams going remote. At first, we jumped in and we were incredibly productive, but the longer the lockdown went on, the more distant everyone became from each other. Eventually, everyone was working on more siloed projects, and those projects ended up going on for quite a considerable length of time. Shape Up helps utilize a process to rectify this, as well as reinforcing our product cycle and making sure that we're building the right things.
From an engineering perspective, it helps to give developers a goal as a team dedicated to something. So they're working on a project, they know the next thing they’ll be looking at, and there’s more structure around it.
J - Absolutely. From a business perspective, we, like most companies, are juggling lots of different priorities. We could go in any one of ten different directions at any given time. So we put this process in that allows people to have a real meaningful impact on the business. For the pitches that we've heard today, we’ve had Maggie (Head of Customer Success and Sales) and Mason (Lead Customer Success Engineer) come in and give feedback to our CEO, our directors, our co-founders in a way that isn’t possible in the vast majority of businesses. So we’re letting our team know that they truly matter, which I think is really quite powerful.
MW - Had either of you experienced the methodology before professionally, or had you just heard about its benefits?
M - We’ve dabbled previously. Over the last four years we've done a couple of Shape Up-esque cycles, but we've never really dived in and done it in a fully-fledged way. I think I’ve been talking about it since I started, so it’s taken some time to get to this point. It's not a very common thing. And especially in the UK, it's not a very widely used methodology. It's relatively new.
One of the key things I always think about when you're looking at building efficiently and making sure you achieve your goals; you've got to look at your team, and you've got to understand what makes them tick, how they work well together and what works for them. I think with a company of our size and what we want to build and the personalities within the engineering team that we have, it just fits what Shape Up does and what it gives us. I'm not sure we would have been able to do it three years ago. I don’t think we’d have had the right makeup.
MW - Was there much resistance from leadership or the engineering/product teams, as can often be the case with new ways of working?
J - I've been pleasantly surprised at how quickly we've been able to adopt it. We've got some very passionate people here at MirrorWeb, some very passionate founders that care about what we do and what we build. We put together these pitches for the first cycle, and we’ve had full buy in from the rest of our senior leadership team.
M - From an engineering team perspective, we’ve had absolutely no resistance. Everyone's been positive about the change and has been fully on board. Part of what we're trying to do with these changes is really give all our team a chance to experience different areas. We swap the teams around and also who's working on what, so it gives people an opportunity to work in different areas, diversify their skillset, and get a real understanding of what they enjoy and what they want to do going forward.
J - It comes back to the idea of ownership. I used to be an engineer and you can go work for a large firm and build a cog. You can go and build a part of an API somewhere and maintain that for the next couple of years. I think the difference at MirrorWeb is that rather than building a cog, we're saying, “you go away and build the machine”
MW - Having completed the first cycle, what are your initial views on how Shape Up is working for MirrorWeb?
J - I think from a product perspective, we’ve had a spectacularly successful first cycle. We went with three pitches, of which two were successful and one failed.
But when we say failed, what we mean is that we didn't meet all of the objectives that we wanted to in that cycle. We still did some really good work; it was really productive, we learnt an awful lot about our system, but we didn't complete everything we set out to achieve. That’s absolutely fine. Failure is something that happens and we'd rather own up to that and learn for next time rather than brush it under the carpet, as you might do with Agile. I think this first cycle has really laid the groundwork.
M - We have retros at the end of each assignment. We were discussing how it went and a team member said they felt like they’d done six month’s work within six weeks. And that same engineer said that they felt they weren’t as productive as they could have been. So when you look at it like that, it’s a good sign.
MW - That's a dramatic impact. Why do you think it's had such an effect?
M - For me it’s two things, and one of them is the product side. Jamie has been dedicated to speaking to clients and working out what we need from a product perspective, and understanding what some of the different problems are and what the solutions could be for those problems. When your focus is on building, you're in the trenches. So this process is incredibly valuable to us as an engineering team; the context is there, and that's very important.
The other factor is the lack of context switching, being dedicated completely for six weeks to something. We will protect the team from distractions. The wider team does a fantastic job of handling what's going on on a day-to-day basis and making sure that nothing hits those feature teams.
It's a generic phrase, but if you take an engineer off and change context for an hour, you've lost a day. If you take someone off for a day, you've lost a week. Obviously it depends on what type of work you're doing, but if you're designing a new system and you're doing deep technical work, switching context takes its toll.
MW - Could you give me some more info on what the two week cool down period entails?
M - The idea of Shape Up is that the focus is on this six week cycle. You want to make sure that the team’s optimal workload and their optimal performance is within that time period, and that they’re as happy and refreshed and energized to do that work as possible.
The cool-down period is the polar opposite to that. It’s time for them to digest what they've done in the previous cycle, to have more headspace. It’s a period of tackling unscoped, lighter work, for them to be able to hit that refresh, wind down from that intense work period and wind back up ready for the next cycle. It's one of the big changes from Agile. Most sprints in general are two weeks after two weeks after two weeks. And that works well for a period of time, but it’s relentless.
In software development as an industry, there's been a tendency to treat engineers as cogs in a machine - throw input in, expect output out, and it's a real churn. That’s not the environment we want to create at MirrorWeb. That's not what we want for our engineers. We want to invest in them. We want them to grow with us. We want to have happy, skilled engineers working for a team that enjoy the work that they're doing; they're interested in it and they're engaged in developing new ideas.
J - We’ve both experienced environments where that's not the case. We’ve both gone through burnout. It's not a good situation to be in, and it's not uncommon at all. We don't want to encourage that type of behaviour as a company.
The environment that we want to build here is where you have engineers that want to stay and want to stay for a long time, because they like the environment, because they like the work they do, because they're compensated fairly, because they get the benefits that they need.
MW - With any new workflows, you inevitably encounter some teething problems. Do any spring to mind?
J - Absolutely. I think in terms of the retros that we had, we've sat down and discussed this very, very candidly. Our scoping needs refinement. It's the first time I've done anything like this. So sometimes we’ll need to give more information, sometimes a little less, so it just needs some fine tuning from a process perspective.
M - Also, understanding how to work best within our teams. We need to define how we do this each cycle, as the teams change. And I think our engineers need to understand what it is that they need to work efficiently as an individual, so that they can express it with the team.
J - It’s really interesting because for the engineering team at MirrorWeb, we have no requirement as to office presence. You can work from where you want, you can work when you want. As long as you’re productive and your team is happy, we don't mind. But what I've found really fascinating is that we’ve seen engineers coming back.
M - Yes. More of the team members are coming back more frequently. And you can't beat that. We’re a remote team, we work well remotely, but sometimes coming in and having that face-to-face contact is priceless.
MW - So it’s a learning curve for everybody, including yourselves.?
M - I think for myself and Phil (Co-founder, Chief Technology Officer) in particular. Phil and I used to be in the thick of things, very much in the middle of what's going on. Then on the first day when we set the cycles off and the engineering teams all went off to do what they were doing, the DevOps team knew what they were doing, Support’s ticking over, CSE was going well, and Phil and I weren’t too sure what to do.
So it’s about understanding what's required from us. Our roles have changed as a result of this, and we're not needed on a daily basis for all of the team. We still need to be available for them if they have feedback or questions, but what we do has certainly changed.
J - What we've done with this first cycle is that if teams have an issue, they come to us and they put something in our calendars and we resolve it. We want to give them that headspace they need to go away and build something.
M - We're not going to poke them; “How's it going? What are you doing? What's going on today? What progress have you made?” No, no, no. You've been given a project. You've been given a problem. We trust you to deliver this.
J - We’ve got a great team. They’re here for a reason, we pay them for a reason. We trust them.
MW - The pitching process is very democratic. Have you had any suggestions from the team that have surprised you?
J - Not necessarily pitches directly, but what’s been really interesting from my perspective is the level of engagement that I have with our Sales team.
We've had a pitch that Maggie, our Head of CS and Sales, has led. But so much of that pitch and so much of that context didn't just come from Maggie. It also came from our SDRs, who were contributing and wanted to make sure there was a solution in place. And that's fantastic to me, that's music to my ears.
M - Leading an engineering team, I want to make sure that we're building things that have value, and that’s it. For the vast majority of engineers, the reason they get into it is because they like solving problems. Not all engineers like writing code, they like solving the problem.
So if we know that we're delivering value, we’re happy. I've not been surprised by the pitches that have come in, but I think it's a process that is going to grow out, and more and more people are going to get involved. I'm just happy that people are getting involved, because I know that by the time it hits the Engineering team, these are things that add value.
MW - I can imagine it's interesting and perhaps even insightful to hear pitches from those that work in different areas of the business?
J - We're all here because we want to give value to our customers. That’s it, that’s the raison d'être. If we don’t, we go out of business. We have to be customer-obsessed, so the more opportunities we have to learn from customers, and the more opportunities that we have to interface across the business, the better.
MW - Is there anything that you’d like to add?
M - I just want to emphasise how our Engineering Team works and how we're trying to share those skills.
Our Support Engineers’ day-to-day is working on support in the front end, but we're trying to upskill them and give them opportunities to grow. One of our Support Engineers is going to the DevOps side of things, while one is going into Customer Success Engineering. Three of our QA engineers are looking to expand into different levels within the engineering team. Our Customer Success Engineers are going to be joining the feature teams over the next couple of months.
We're really invested in making sure that people get the opportunity to grow, both in a career sense and as a person, while they’re with us. It's a core focus of what we're doing. Shape Up only makes up one aspect of our team. It’s a very core principle that we work around and it's intrinsic to what we do, but it doesn't make a whole engineering team.
We’re made up of a number of different teams that all contribute to this shared goal, that are all part of this process. Whether they're doing Shape Up on the day-to-day, or whether they're outside of that doing business as usual work, we're investing in them.
