Successful tech changes

Have to consider:

  1. Create Business Value
  2. Improve User Experience
  3. Simplify Systems

I recently signed up to a newsletter from The Platform Fix where Steven talked about the "Three Corners of the Platform Success Triangle" but it's wider than that - it applies to every technology project in every part of the business.

Whether it's a VPN technology change, a website revamp or a change to AWS IAM role policies it's the same thing. The most successful changes both long and short team create business value, improve user experience and simplify the tech stack.

Business value is the easiest one, since that's usually why the change was suggested in the first place. The only trick here is to make sure there's actual business value and not just someone's gut feeling that it might be a good thing. I first subscribed to the Platform Fix because of some content Steven and Neil put out about What Kubernetes Really Takes - so it seems like an apt example of a change that often has "gut feel" business value but doesn't stand up to closer scrutiny.

Improved user experience is critical to buy in from the people who matter most—the ones who will be affected by the change. Sometimes it is the business value, that makes it super easy. Other times the change on the face of it will make life harder for users, making it a bigger lift to improve the user experience overall. An example that comes to mind is rolling out MFA—many organisations will jump straight to SMS or TOTP MFA, tick the box and walk away. However with a little more thought about the choices being made, more user friendly (not to mention better for security) factors such as passkeys and magic links can be used which not only improve the user experience but create even more business value.

Finally simplifying systems. It's all too easy when faces with having to make a change to bring in another technology alongside your existing tech stack, bolting it on and calling it a day. The way to improve tech changes, especially in the long term is to ensure that the changes remove, or at the very least don't increase complexity. This isn't always possible and is sometimes easier said than done.

A solid plan and commitment to completely decommission an old system once the new one is up and running is something often forgotten. Those last 20% often take 80% of the effort, and since it's not critical it falls by the wayside. Repeat a couple of times and suddenly there's a sprawl of legacy, barely used relics costing money, time and energy.

Sometimes it's also finding a solution that will solve the new and existing use case by switching technologies completely rather than keeping the old technology and adding another for the new use case—an example would be switching to and authentiction stack that supports MFA natively, rather than adding an MFA provider and having to chain it to your existing IdP.