Here’s a word that’s been used in so many different contexts that its primary meaning is in danger of becoming secondary. The characteristics of a physical snowflake – unique, delicate, brittle, intricate, etc. – have made it the go-to metaphoric label for all sorts of things many, probably mostly, negative.
Snowflake as office speak is highlighting those same characteristics but primarily focussed on uniqueness:
- “This is going to end up as a snowflake server” = “that server is going to be a one-off”
- “What they are designing is a snowflake solution” = “that solution is going to be a unique design”
Like it’s usage in other contexts the snowflake label isn’t, generally, a positive thing and is often used as a derogatory label. This is certainly true in my own work context of IT solutions.
(This post is not about snowflake the data platform, if that’s what you were expecting.)
The term snowflake was first used to describe IT servers in the book The Visible Ops Handbook which was published in 2005, so this isn’t a new idea. It’s also not the only metaphor that people have used for this phenomena, another popular one is the idea of cattle v pets. This is how Martin Fowler describes the idea:
it can be finicky business to keep a production server running. you have to ensure the operating system and any other dependent software is properly patched to keep it up to date. hosted applications need to be upgraded regularly. configuration changes are regularly needed to tweak the environment so that it runs efficiently and communicates properly with other systems. this requires some mix of command-line invocations, jumping between gui screens, and editing text files.
the result is a unique snowflake – good for a ski resort, bad for a data center.
Martin Fowler: Snowflake Servers – DZone DevOps
From this initial scope the label has moved beyond servers to all areas of technology. It’s become so ubiquitous that it’s reaching a point of concept entropy.
I work within a product focussed organisation and success, for us, is partially measured by people deploying and using our product as it was designed. What we do is quite complex, there are hundreds of ways of doing similar things, so we constrain what people do to reduce the complexity. What we don’t want are thousands of things that are similar, but different, snowflakes. From this standardisation mindset a snowflake is a problem, it requires extra work, and not just when it’s deployed, for the whole of its life it will be a special case. Operational teams want things to be in a “known good” state, they desire uniformity even if standardisation is suboptimal.
There was a time when people would just call something like this “non-standard”, or “unique”, but the snowflake label appears to have overtaken that.
In reality, though, difference is not only good, it’s essential. The trick is to have uniqueness where it adds value, and to standardise where it doesn’t. Standardisation is great at reducing cost, but it can also significantly reduce value if it’s incorrectly applied. The real value in standardisation, done well, is in removing the nugatory effort that is so prevalent in many organisations, releasing people to focus on the value adding uniqueness.
As a rule, I’m not a fan of labels. Labels have a habit of sticking around long beyond their usefulness. Even when they are removed they often leave behind a sticky residue. I see the same happening with the snowflake label.
I do regard it as a bit of a shame that we have chosen to use one of nature’s spectacularly intricate and beautiful phenomena and turn it into a negative label. Snowflakes are amazing, and not just at the ski resort.
Header Image: This is Buttermere looking back towards Buttermere village on one of those still autumnal days.
Graham Chastney 