According to the parable in Matthew’s gospel, “no-one pours new wine into old wineskins – otherwise, the wine would burst the wine-skins, and both would be ruined.” So, coming into FreeAgent as an intern, I wondered – would FreeAgent prefer the new wine in the new skins or the old wine in the old skins? Would they satisfy the stereotype of the tech start-up, move fast and break things, trip over themselves in the rush to adopt the latest technology? Or would they satisfy the stereotype of the banking group subsidiary, play it safe, allow their ancient systems to gather dust? As I discovered, FreeAgent doesn’t satisfy either stereotype. In fact, FreeAgent blends old and new, balancing the advantages and disadvantages of each. And preferably without ruining any wine or wine-skins.

So how do you balance old against new? Well, there’s a pretty obvious advantage to using new tools – sometimes, the newest tools are the best tools. After all, a new tool would never have been invented if there hadn’t been somebody, somewhere, who thought it would be better than whatever came before. Second, tech is a fast-moving industry – if you don’t keep up, you could be left behind. That means less testing, a smaller community to help you when you get stuck, fewer security updates and a smaller talent pool to hire from. And, of course, from time to time somebody scores a direct hit with a shooting star and invents something totally new, something beyond a mere efficiency improvement, something that opens up whole new possibilities.

But that doesn’t mean it’s all on the side of the newcomers. For a start, adopting new tech usually has a cost – you might need to re-train to use the new tech effectively, or repeat a load of old work. You can avoid all that by simply sticking with what you’ve got. Furthermore, if you use the same tool for a long time, you can build up your expertise – FreeAgent, for example, has a lot of industry-leading talent in the Ruby programming language, because they’ve been working with it for a long time and nurturing their team’s skills. Lastly, if something’s old, that means it has a track record. You can check that it lives up to its promises. With the newest tools, you might not have that luxury: adopting something before it’s really proven in the field is a gamble.

What does this all mean in practice? Quite a lot, actually! There are any number of examples I could point to where FreeAgent is currently managing this balancing act. I’ve picked a comparison I thought particularly illuminating, comparing a case where we stuck with the old against a case where we adopted something new.

At FreeAgent, I learned to work using the Lean-Agile method. Lean-Agile is a way of organising work, and is a fusion of multiple pre-existing methods. The Lean method was invented in Toyota in the 1950s, and is now standard across industries as diverse as manufacturing, healthcare and software development. Agile, on the other hand, is mainly used in software engineering. Although the term “agile” was only coined in 2001, similar methods had been in use in the industry for almost half a century previously. In the mix go a few other long-established software-engineering paradigms, and out comes Lean-Agile. The method prioritises making as short as possible the loop from identifying business requirements to making functional software to testing the results. Lean-Agile is now ubiquitous in software engineering.

So it’s not surprising that FreeAgent uses Lean-Agile. But why? Aren’t there other approaches? (There are – lots!) But using Lean-Agile is a clear win for sticking with what you know. It’s so ubiquitous that a new engineer can pretty much jump straight in and already understand how to work effectively. I saw this myself when a new engineer joined the team at the same time as me – within a week, not only were they fluent in the system, they were helping to improve it! Best of all, it just works. And we know that because the methodology is about as old as software engineering itself. Lean-Agile didn’t become standard by accident. Companies tried it, it worked, and so it spread. The risk and cost of trying something left-of-field just isn’t worth it.

In contrast, while I was there, FreeAgent tried something radically new. For 12 weeks, nobody at the company worked more than four days a week, although we were all guaranteed the same weekly pay. This experiment clearly cost the company a lot of money, and wasn’t without risk – fewer workers online at any one time meant fewer people available to respond to an emergency.

Nonetheless, FreeAgent decided it was a good trade-off. Why? For a start, some of the risks of new ideas were relatively manageable. Other companies, especially in tech, have tried four-day working weeks before, and some said it worked well for them. If it worked well for them, that makes us more confident it could work for us, too. Plus, there’s good evidence that working four days a week makes you significantly more productive. Finally, in a tight labour market for software engineers, offering four-day contracts at a competitive wage could make FreeAgent more attractive to potential recruits. So, in line with FreeAgent’s modus operandi, we tried it out. We’ve measured the results. In time, we’ll get the verdict on how well it worked. And if it worked for us, you can be sure that we’ll be open to four-day contracts in the future.

That’s just one of many examples I saw at FreeAgent where we managed the trade-offs between old and new. Thanks to my time at the company this summer, I’m now better at judging when to prefer the old wine, when to prefer the new skins, and how not to ruin either.