Can you scale without the growing pains?

www.jackparkerphotography.co.uk

Sponsored post by Sophie Davies-Patrick on behalf of MPB 

How do you develop your flourishing former start-up into a serious international player without losing what made you great in the first place? Or in other words: can you scale without getting stale?

There’s more to growth than simply getting bigger.

Your customers will still expect seamless, trustworthy, always-on fulfilment. Meanwhile potential investors are looking for a growth mindset and a predictable return. And your own people want to keep on delivering, while privately worrying whether change might mean leaving behind the things that motivated them in the first place.

If you’re at all successful these questions arise sooner or later. Is it even possible to keep everyone happy? Does it matter, as long as the numbers are good? Can’t we just update the brand, or take a leaf from the LatestIncrediblyCoolThing.co playbook?

Why it matters to me

The company I work for, MPB, has grown into a thriving online platform, with three warehouses full of used photographic equipment in Britain, Europe and North America, all backed by a busy tech and support operation.

It’s still very much a labour of love for its founding photography enthusiasts. But in expanding it has also outgrown its original digital underpinnings. Modern systems and methodologies will let us turn ideas into reality more quickly, more often.

I joined as CTO in April 2020. My prior experience covers organisations from start-ups to multinationals, with businesses in fields ranging from fintech to travel to open-source software.

I found a team at MPB who believed in what they were doing, had a flair for improvising and a refreshing lack of siloed thinking. If something needed doing, someone was always there to do it, whether or not it was part of their remit.

Our people like to socialise out of work, are coders because they love it, and are passionate about solving problems and making the business better — all the things you hope for, and the kind of situation where smaller teams excel. By introducing change we clearly didn’t want to lose any of that.

And we needed buy-in from everyone in the company, not just our own part of it. I heard from peers that we were doing product development really well, but they’d welcome an emphasis on predictability and flow.

As we worked together on our growth strategy, I drew on Jon Smart’s ideas to shape discussions around four ideas: Better, Sooner, Safer and Happier.

  1. Better

We knew we had to focus on things that delivered value to our customers and business. Simple to say, but first we had to agree what “value” meant in practical terms.

Over a series of discussions we produced a prioritisation matrix that let us clearly see how long we were spending to achieve an outcome. If that sounds like old-school “time and motion” it’s actually the reverse.

By being transparent about effort vs outcome we can optimise our workload and ensure we focus on the highest-value work, without feeling we have to say yes to everything — a systemic problem in our industry, which can easily lead to quality issues and to-do lists full of half-completed projects.

Another way we’ve simplified our lives is to integrate third-party services and applications where it makes sense. DIY always looks cheaper on paper but it’s a fallacy. Using external SAAS frees us to focus instead on our own specialties.

  1. Sooner

Flow, predictability and transparency were hugely important to our colleagues in the wider business. We knew from the outset that we’d be embracing Agile but even positive change can unsettle people. We needed to build confidence internally that we could use these tools to deliver and to grow.

So we hired an experienced Scrum Master to work across teams and trained the whole Product & Engineering staff in Agile practices. Even more importantly, we introduced a “pull, not push” system in which engineers take on what they can realistically achieve and avoid over-committing. We maintain limits on work in progress. And we’re encouraging developers to become “T-shaped” (able to adapt to other disciplines), which enables teams to swarm more effectively to close out a sprint.

Bringing our Product and Technology teams under the same leadership has proved to be orders of magnitude better for efficiency. It means healthy tensions can be more easily resolved and there’s no difference of overall focus to distract and derail.

  1. Safer

To make sure we had robust systems that could scale with our company, we had to establish a lot of housekeeping — everything from continuity planning to alerting and from coding standards to comprehensive documentation.

But beyond that there was also the issue of replacing our in-house web platform and its organically grown codebase with a reliable and extensible Service Oriented Architecture.

The new system uses a Continuous Integration/Continuous Deployment system (CI/CD) which will take us from a couple of code drops a month to multiple small drops per day. As soon as code is completed it can be merged, automatically tested and deployed.

We’re upskilling our manual testers to write automated scripts for regression, browser and functional testing, so that if something should fail, it will be much easier and quicker than before to fix it, retest and redeploy.

  1. Happier

For us this was axiomatic. If you want motivated, engaged colleagues who deliver, you need them to feel valued and that their contribution makes a difference.

Our guiding principle (kudos to Daniel Pink’s ‘Drive’) is “You figure out the how.” And hopefully we can watch our colleagues move from “Is this OK?” to “Here’s my plan, is that OK?” and then to “Here’s what I’m going to do”.

As well as the “pull not push” mantra we’re introducing individual training and development pathways and giving delivery teams fewer instructions with greater accountability. All of which aims to preserve the advantages of a smaller operation as we transition to a larger one — which is kind of where we came in.

So, is this actually working?

My arrival at MPB coincided with the Covid-19 pandemic that’s still creating problems around the globe. As well as planning for a future-facing operation, we had to deal with a more immediate change to our ways of working.

Everyone had to deal with the “new normal”, both in and out of work. Everything from ideation sessions to team-building lunches suddenly had to happen in a virtual space.

I think without Covid we might have been able to change more quickly, as there are many conversations that just work better face-to-face. Nevertheless, the team has achieved some big things in a short time.

As much of the world went into lockdown, MPB experienced a surge in demand, while our Berlin operation was ramping up ready to take over the European market post-Brexit. All this meant pressure on warehouse stock.

Against this difficult background our Product & Engineering team did what they do best, pulling together and refactoring our trade-in form to produce a significant uplift and maintain for-sale stock levels.

Under our forthcoming CI/CD pipeline we hope to couple that spirit of “let’s do this” with rapid testing and deployment to create something spectacular.

Our next steps

I’m keen for us to establish a Lean development philosophy and focus on “rightsizing” our code. It’s not always easy for developers to favour a minimum viable product over something designed to be beautifully futureproof. That’s a natural instinct if you take pride in your work. But however elegant a design, larger never equals more serviceable. The earlier you can ship a feature, the more business value you can accrue from it, and you can still work on the rest in the background if it matters. Why hold back the starter until the main course is ready?

While I hope we’ll be hanging on to our team’s problem-smashing, can-do culture, there are some things we can do with a larger organisation that we couldn’t with a smaller one.

Talent is always hard to find in the technology industry. We’ve just published our Career Framework for competencies across Engineering and Product. The idea is to create a more formal career structure, where everyone knows what’s expected of them and what awesome looks like.

Final thoughts

As companies expand things are always going to change. But if I didn’t think we could do it while keeping our core values intact, I wouldn’t be writing this. We’re growing our tech team and replatforming precisely because I want us to spend more of our time delivering great features.

We need happy customers to have a business, and it’s their needs that drive us. But doing that really well, surprising and delighting them with things they didn’t know they wanted — that takes empathy and creativity. We’ll only achieve our best if we can still feel like we’re having fun.

Sophie Davies-Patrick is Chief Technical Officer of MPB, an online platform for photo and video kit, with operations in the UK, US and Europe.

More about MPB here