Will replatforming your tech stack solve your productivity issues? The answer is very likely yes. But, of course, it depends on many factors.
In a previous blog, we talked about the issues that signal your platform might need some attention. One of the top ones is simple and pretty obvious: not being able to get features out fast enough.
Productivity can take a hit for a raft of different reasons. Poor team dynamics, lack of leadership, focusing on the wrong aspects of the job. But a lot of the time it’s the tools. And if your issue is around building and releasing software, then replatforming could well be the vehicle to get your developers performing at a higher level.
When replatforming goes wrong
Often though, leaders – as well as their teams – see platform reengineering projects as massive, all-encompassing, complex and painful undertakings. And they can be. They can add complexity rather than remove it. They can replay the same mistakes, pack in the same clutter, pile new components and features on top of existing ones.
We’ve seen enough examples of this in our time. Big replatforming projects that have failed because of a lack of vision at the outset. They’ve asked the wrong questions, haven’t considered the larger objectives, added functionality that’s not necessary. The list goes on.
Not only does this make the resulting stack more complex than it needs to be, but it also slows the whole project down, adding to the overall air of failure. Essentially, you end up in the same place you were before, and you haven’t even got there fast. It might be a new stack, but it’s got just as many problems as the old one, and you’re no further down the path to greater productivity. Plus, going forward it’s still going to take a new engineer months to understand your architecture before they can start being productive.
How to get it right
Replatforming done right is a golden opportunity to refine your product. What’s called for is a healthy dose of introspection – in my view, the most important part of the process. There’s no room for, “We’ve always done it like this.” A cold, hard look at the end-to-end architecture is needed.
Ask yourself: what do we use from the old platform? What are the valuable parts of it? What have we maintained just because we built it? Assess what you need to bring over, and what would be better left behind. It can be a brutal process, and it requires an honest and objective look at all aspects of your existing platform.
On the technical side, focus on removing the time-consuming processes and standardising where possible. Component libraries, for instance, replacing the need to manually maintain hundreds of components individually. One change to the base component saves hours, days or even weeks.
On the product side, are you spending time maintaining parts of your site that get little or no traffic? Assess your apps and see what functionality is worth maintaining, or what’s missing. Your data’s your guide here. And it’s not just product insight. Your data can tell you how well your services and platforms are performing from a technical standpoint too. Armed with these insights you can make informed decisions that won’t just improve outcomes but will make it easier for teams to focus on the real problems or opportunities. If it’s the platform, you’ll know and can respond.
Always ask yourself what you want to achieve. Chances are it’s going to be maintaining or improving production reliability, making production smoother, shipping new code quicker, or speeding up experimentation cycles. Maybe all of them. Working with one client, we found it was taking a day to develop a feature and then seven days to get it into production. Clearly, it shouldn’t take longer to ship a product than build it, so this was a major red flag that there were issues with the platform.
This also raises an interesting point about perception and productivity. In this client’s case, the teams were busy – they were working hard – but it was like they were wading through treacle, expending energy where it wasn’t visible. Or valuable. The logical perception then was that they weren’t productive, but this wasn’t related to effort – it was because they didn’t have the tools to deliver. To get features over the line in an efficient way.
A modern tech stack would solve this – testing is automated, which hugely accelerates time to production because you’re not spending weeks on manual QA. With access to tools that are easy to pick up and an architecture that’s easy to understand, even a new team member should be able to deliver code to production in a single day.
We’ve seen other examples of wasted effort. One client was working to two-week release cycles. This meant by the time they were ready to deliver, so many other things had changed that they either faced an integration nightmare or they just had to begin again. Either way, a lot of wasted productivity.
Get ready, set your vision, and grow
We’ve been part of many platform reengineering projects over the years. What’s the key factor that sets the winners apart? It’s all in the vision. Those that take the time to introspect and follow some simple steps in those crucial early stages.
Plan well
Establish your key principles. These will provide a blueprint to check against as you progress. Never ask if you’re on schedule with the project – ask if you’re being true to your principles. It’s a much more effective way to measure success.
Be methodical
You don’t need to change everything overnight. In fact, it’s best you don’t. The most impactful changes are made step by step. Get one bit right and move on.
Use data
Don’t make arbitrary decisions when you have valuable data at hand. As we’ve discussed, it’s about keeping the value you have in your platform and then building on that. Data will help you identify what you should be focusing on, and provide you with those crucial first wins.
One of the points we can’t reiterate enough is that replatforming doesn’t mean building the same thing in a different technology. It’s much larger than this – an opportunity to embark on a journey that will allow your team and the wider business to grow. Just plan your vision, and innovation will follow.
Please contact us should you wish to discuss any of the points raised in this article, as we’d love to hear from you.