Standardisation or Innovation?
A recent book club discussion took the group into the familiar pros and cons of standardising an organisation’s technology stack or choosing specific tools for specific jobs. I’ll share some examples we discussed.
At a web agency, innovation was a key element of their positioning, both to clients and staff. As such, the freedom for teams to choose the technology they felt was most suited to the task was the default. But this space to experiment and explore came at a cost. The agency couldn’t easily staff up a successful project as other developers didn’t always know the programming language, web frameworks, or database chosen. For the same reason, developers couldn’t review code across projects to ensure quality and support less experienced members of the team.
At a scientific research organisation, they had a similar challenge. Except they were more extreme. Each project would begin with the team sitting down to determine the technology stack and architecture from first principles as well as what version control system, document sharing tool, knowledge base, and even email platform to use. Sometimes this took weeks.
A developer tool startup used a monolithic common stack. But their codebase and development team were so large there was significant scope for tools to be added or expanded without discussion. And for different design patterns to become prevalent in parts of the app. This had significant impacts on performance and maintainability.
But standardising onto a default stack with change control processes stifles innovation and exploration! Or does it?
The web agency agreed on a default stack for new projects, but established an exception process for when a client’s idea truly needed something different. Their new projects got shipped a lot faster, with better quality and support, and then the team got to really experiment by solving customer needs as they came up rather than struggling with unfamiliar code.
The research organisation had much clearer requirements for specific technologies to meet the differing needs of their academics. Some languages simply are faster, have better memory management, or have better tooling for mathematical correctness. But they didn’t need to choose between Gitlab, BitBucket or GitHub each time they started a new project. Let alone deciding between Microsoft Office and Google Docs. They began to standardise the basic tools and systems while leaving scope for technological choice.
The startup went further and developed a series of guidelines. They characterised technical choices by how supported they would be organisationally. Some choices were highways: high throughput, clearly signposted, and smooth. Others were suburban roads, dirt tracks, or kangaroo paths through the scrub. Only certain kinds of projects were allowed to venture off the beaten path. Most were expected to use highways or suburban roads.
Choosing between standardisation and innovation is not a binary selection. There’s nuance and opportunity to see the benefits of both. You may just need to explore a little to find what works best for your organisational needs.