Why we’re not ‘future proofing’ tech stacks – they’re a work in progress

There’s a lot that goes into building and integrating new technology that delivers value on a global scale. As those in tech and product development are more than aware, developing a tech stack that not only integrates with existing platforms but also allows for the flexibility that will be needed in the future, is no easy task.

While each scenario will be different, in my experience there are several ways to help make the process smoother, overcome the inevitable challenges and get past those potential obstacles. So, how can you implement a tech stack that is as effective as can be that also critically continually evolves to meet the needs of the end user?

Setting yourself up for success

I cannot stress enough the importance of focusing on the problems you’re solving, rather than being fixated on the ideal solutions.

Creating solutions or products that people love for the long-term is a journey, that requires constantly questioning the ‘what’ and ‘how’ of each solution, while grounding yourself and your teams in a foundational understanding of ‘why’ each problem exists and its importance to the people you’re ultimately building for. And as obvious as it may sound, accept that you’re never going to get it ‘right’ first time. Any worthwhile solution is a journey, which is why you need to bake-in user feedback from the outset, applying these common foundations first to global user requirements, and then refining and expanding on them locally where needed.

It’s worth just reiterating the user feedback point. Choose what works best for your end users, whether that be discussions, wireframes, mock-ups, live demos, hands on pilots or low risk production tests. Involving business stakeholders and customers is vital – of course, to achieve those incremental gains and improvements, you really have to be open and receptive to feedback. That doesn’t mean actioning precisely the feedback that you receive or building a stack of endless requirements, but rather taking everything in its totality and together deciding on your priority areas to concentrate on – those that will bring the biggest impact and value to address your core problems – and then consciously designing solutions that best-fit with the product you’re producing and the environment your customers and users operate in. It’s also worth noting that great concepts like the minimum viable product (MVP) will vary considerably between B2B and B2C customers, so learn your users and stakeholders, and calibrate around what works.

The art of communication

There will inevitably be ‘technical debt’ (also known as ‘code debt’) that you will have to factor in and, frankly, accept – in other words there will be fixes and bugs to deal with throughout, in exchange for immediate functional results. There are well documented benefits of ‘slowing down to speed up’ and you shouldn’t shy away from explaining these, as otherwise you will end up having to ‘pay-down’ a greater debt the further into the future you go. This ‘tech debt’ should always be part of the planning, prioritisation, and dialogue with your customer, especially as your tech stack begins to age. Also, don’t forget to celebrate wins and key milestones, especially the not so obvious changes such as fewer downtimes, or breakthroughs in development, for example.

The other key point to bear in mind is the importance of communicating changes to stakeholders. It can be challenging to explain technical concepts, which is why you need to be adept at simplifying and avoiding technobabble. Some may well be comfortable with the more technical aspects while others won’t, so you need to cater for these two very different audiences.

I’m a strong believer in getting early wins under you belt – not only help people see the value you’re adding, but crucially to build your credibility as a trusted partner. And back to my point earlier, this should be a gradual process, so start with small changes and iterations that address specific pain points rather than trying to make a big statement too soon.

People respond to familiarity so make sure they’re comfortable and have time to get used to and assimilate the changes. Ideally, you want people to experience the positive impact of the changes in palatable servings, rather than a complete disruption and upheaval of what they had previously. It can be a bit of a delicate juggling act but it’s often important to plan towards introducing new technologies and user experiences in incremental waves to get the best overall momentum.

So, in summary, my three key takeaways to consider when embarking on the building, development and/or integration of a tech stack for the long-run:

• Adopt a learning mindset – you must get feedback from stakeholders, which will either highlight the need for change or reinforce current designs and implementations. You’ll never get it right straight away, so accept that good enough is well enough and don’t let perfect get in the way of good enough!
• Communicate with clarity – keep in mind that not everyone will understand technical concepts. Cut through the jargon, speak their language, and make sure you explain the reasons for the new technologies and importantly how it will improve their working lives.
• Small is beautiful – don’t go for the ‘too ambitious too quickly’ approach, but rather build and release gradually and help people see the value of those all-important early wins, while giving your stakeholders value early and often. Lay those solid foundations and build up momentum, so that more disruptive changes become more of a matter of fact.

As you may have gathered, I’m not a fan of using the phrase ‘future proofing’ when talking about your tech stack, because really it’s always a work in progress – it’s better to do it in manageable stages, based on continual learning and improving on existing technologies. As long as your technology continues to evolve with user problems, then for me – it’s the right technology.

Matt Hillier, VP Product at CloudPay