Will replatforming your technology stack solve your productivity problems? The answer is probably yes. But, of course, it depends on many factors.
In our last blog, we discussed issues that indicate your platform may need attention. One of the most important issues is simple and very obvious. The inability to deliver features fast enough.
Productivity can decrease for a variety of reasons. Poor team dynamics, lack of leadership, and focus on the wrong aspects of the job. But often it’s in the tools. And if the issue is about building and releasing software, replatforming can be a way to push developer performance to higher levels.
When rebuilding the platform doesn’t work
But leaders and their teams often view platform reengineering projects as large, comprehensive, complex, and painful undertakings. And it’s possible. You may be adding complexity rather than removing it. You can keep repeating the same mistakes, cramming in the same stuff, and stacking new components and features on top of what’s already there.
We’ve seen enough examples of this before. A major replatforming project failed due to lack of initial vision. They asked the wrong questions, didn’t consider the larger goal, and added features they didn’t need. The list goes on.
Not only does this make the resulting stack more complex than it needs to be, it slows down the entire project and adds to the overall feel of failure. Basically you end up in the same place you were before and can’t even get there any faster. It may be a new stack, but it has just as many problems as the old stack, and there are no more paths to productivity. Additionally, it will continue to take new engineers months to understand the architecture before they can be productive.
How to understand correctly
Replatforming done right is a great opportunity to improve your product. What is needed is a healthy dose of introspection. In my opinion, this is the most important part of the process. There is no room for “this is how we’ve always done it.” It requires a cold, hard look at the end-to-end architecture.
Ask yourself what you will use from your old platform. What is that precious part? What have we maintained since we built it? Evaluate what you need to bring and what you should leave behind. This can be a brutal process and requires an honest and objective look at every aspect of your existing platform.
On the technical side, we focus on removing time-consuming processes and standardizing them as much as possible. For example, a component library replaces the need to manually manage hundreds of individual components. A single change to a basic component can save you hours, days, or even weeks.
On the product side, are you wasting your time maintaining parts of your site that get little or no traffic? Evaluate your apps to see which features are worth keeping, or which are missing. Data is your guide here. And it’s not just product insights. Data can tell you how well your services and platforms are performing from a technical perspective. Armed with these insights, you can make informed decisions that not only improve results but also help your team focus on real problems and opportunities. A platform can understand this and respond accordingly.
Always ask yourself what you want to achieve. Perhaps it will maintain or improve the reliability of your production environment, make your production environment smoother, ship new code faster, and speed up your experimentation cycles. Probably everyone. We worked with a client and found that it took him one day to develop a feature, and it took him seven days to deploy it in production. Obviously, shipping a product shouldn’t take longer than building it, so this was a major red flag that something was wrong with the platform.
This also raises an interesting point about cognition and productivity. In this client’s case, the team was busy and working hard, but it felt like they were walking through molasses, expending energy in invisible places. Or something valuable. The logical perception at the time was that they were not productive, but this had nothing to do with effort. Because they didn’t have the tools to provide it. To obtain functionality over the line in an efficient manner.
A modern technology stack solves this problem. Testing is automated and you don’t have to spend weeks on manual QA, which greatly reduces time to production. With access to easy-to-use tools and an easy-to-understand architecture, a new team member should be able to deliver code to production in a day.
I’ve seen other examples of wasted effort. One client was working on his two week release cycle. This meant that by the time we were ready to deliver, a lot of other things had changed and we either faced an integration nightmare or had to start all over again. Either way, a lot of productivity is wasted.
Get ready, set your vision, and grow
We have participated in many replatforming projects over the years. What are the key factors that distinguish winners? It’s all in the vision. Someone who takes the time to self-reflect and follow a few simple steps at critical early stages.
plan well
Establish key principles. These will give you a blueprint to check as you go along. Never ask if a project is on schedule. Ask them if they are true to their principles. This is a much more effective way to measure success.
act methodically
You don’t have to change everything overnight. In fact, it’s best not to. The most impactful changes will be gradual. Let’s get a little bit right and move on.
Use of data
Don’t make arbitrary decisions when you have valuable data at hand. As we’ve discussed, it’s important to maintain and build on the value of your platform. Data helps you identify what to focus on and delivers important first wins.
One thing that can’t be reiterated enough is that replatforming doesn’t mean building the same thing with a different technology. This is much bigger than this, an opportunity to embark on a journey that will enable us to grow our team and the wider business. Just plan your vision and innovation will follow.
If you would like to discuss any of the points raised in this article, please contact us. We look forward to hearing from you.
