I was reminded of this after our panel talk @ hashtag#dtxmcr23 yesterday, when someone spoke to me afterwards who’s accountable for the digital workplace strategy at his org.

The great thing about paper, pens, spreadsheets and WhatsApp groups is they’re ultra flexible and the technology works for /you/.

If you have a broken process, invariably, adding more technology makes the situation /worse/. Why? Because you’ve now sealed the process in concrete and making changes is 10x harder (and more expensive). Your users are now beholden to the technology. You’ve probably not made their lives better, or their work more efficient.

Where do you start? I fell in love with Service Design (see comments for Wikipedia link), after seeing folks like Katherine Wastell, Kathryn Grace and Elisse Jones use it at the Co-op. Start by mapping your end to end process – people, systems, tools, workspace – and identify the pain points.

When you do this, more often than not, you find technology is /not/ the answer to the biggest problems.

And if you do choose to add new tech into the mix, you’re doing so with a much better understand of why and what problem it’s going to solve.

To me, that’s the heart of Digital Transformation.

n Agile circles we talk a lot about autonomy, and good teams being autonomous. However, there’s a common misconception. No team is ever fully autonomous. No team lives in a vacuum.

Autonomy needs boundaries to be effective.

Look at a top-flight football team, where high performance is essential. They need to be empowered to self-organise, so they can adapt to what the opposition is doing.

But their autonomy has clear boundaries – how many players you can have on the pitch, the playing area and many other rules. Without them it would be more like the Royal Shrovetide Football game, an early form of football dating back to the 12th century which is basically just a massive fight (the main rule is, somewhat bluntly, no killing).

A team is an example of a complex adaptive system. Every successful complex adaptive system is bound by rules, even in nature. A flock of birds works on 3 simple rules, allowing them to self-organise, avoid crashing into each other and leading to mesmerising patterns like murmurations of starlings.

To enable autonomy, it’s important for teams to have clarity about what they’re responsible for and the boundaries around what they can make decisions on.

Defining boundaries is a delicate act. Overly rigid and you can inadvertently limit the very autonomy you aim to foster. Too much leeway can lead to misalignment and inefficiencies. The goal is to offer enough structure, while preserving the space for creativity.

Like a conductor with an orchestra 🎻: set the tempo 🎵, but let the musicians shine ✨

Your proposition might be bleeding edge, your tech doesn’t need to be. Go with well-known, battle-tested technology.

Both start-ups and established orgs frequently fall into the trap of chasing the latest trends and opting for cutting-edge technology. More often than not, they later find themselves burdened with complex stacks that are not fit for purpose and hard to maintain.

Here’s the thing: unless you’re operating at a mega scale or working in a very specific niche, you can accomplish nearly everything you need with tech that’s been popular for decades. The benefit? They’re well-known, well-supported, and it’s easier to find engineers who are familiar with them.

🚨 The Trade-off Trap 🪤
When assessing new tech, many developers overlook the trade-offs. They get caught up in the allure of the problems the new tech will solve, without understanding the new ones it might introduce.

🚨 The Re-write Trap 🕸️
When the opportunity to re-write something arises, the temptation to choose shiny new tech is strong. However, more often than not, the tech stack wasn’t the core issue. The main reasons are typically out of support frameworks and languages, and an architecture and codebase that have become too complex to maintain. By opting for unfamiliar tech, you risk complicating your re-write even further. 🚧

Common examples 🔍
– Choosing NoSQL databases over traditional relational databases
– Overcommitting to a microservices architecture
– Going all-in with a serverless architecture like AWS Lambda
– Opting for GraphQL over more traditional REST-like APIs
– Dare I even begin when it comes to front end web frameworks 🥺

While all these choices have their merits, they are best suited for specific use cases and you need to know what they are.

Innovation 💡 in your product or service is where your focus should be, not in the technology that supports it. By choosing reliable, common technology, orgs can avoid unnecessary complexity, freeing up more time and resources for what really matters: solving real-world problems and growing their business.