Standardisation vs customisation The Ongoing Tension
In the realm of technology, the debate between standardisation and customisation is perennial. Here are some insights based on different organisational experiences.
The Case for Customisation
At a web agency, innovation was a cornerstone of their identity, appealing to both clients and staff. Teams had the freedom to choose the technology they felt was most suited to the task. However, this liberty came at a cost. Staffing successful projects became challenging as other developers were often unfamiliar with the chosen programming languages, web frameworks, or databases. Additionally, this hindered code review and support for less experienced team members.
A scientific research organisation faced a similar but more extreme challenge. Each project began with the team deciding on the technology stack and architecture from scratch, including version control systems, document sharing tools, knowledge bases, and even email platforms. This process sometimes took weeks, slowing down progress.
The Case for Standardisation
Conversely, a developer tool startup used a monolithic common stack. While this provided consistency, the large codebase and development team left room for the introduction of new tools and design patterns without much discussion. This approach had significant impacts on performance and maintainability.
However, the notion that standardising onto a default stack stifles innovation and exploration is not entirely accurate. The web agency found a middle ground by agreeing on a default stack for new projects but established an exception process for unique client needs. This approach led to faster project completion, better quality, and more support, allowing the team to experiment with solving customer needs rather than struggling with unfamiliar code.
The research organisation also benefited from clearer requirements for specific technologies. They realised that some languages were simply faster, had better memory management, or offered superior tooling for mathematical correctness. By standardising basic tools and systems while leaving room for technological choice, they found a balance.
The startup went a step further by developing guidelines to characterise technical choices based on organisational support. They likened some choices to highways—high throughput, clearly signposted, and smooth—while others were suburban roads, dirt tracks, or kangaroo paths through the scrub. Only certain projects were allowed to venture off the beaten path, while most were expected to use the standardised options.
Finding the Balance
Choosing between standardisation and innovation is not a binary decision. There is nuance and potential to leverage the benefits of both. It requires exploration and a willingness to adapt based on organisational needs. By embracing a balanced approach, organisations can foster innovation while maintaining the efficiency and support that standardisation provides.
The key is to find what works best for your specific context, ensuring that the chosen approach aligns with your goals and operational realities.