Hollow artifacts

Martin wrote in with some thoughts around the component library work his team has been working on.

He writes:

Thinking and working with components has been a cultural shift, from product owners to designers to developers. The tool we have to manage them is a bit rough, but it’s practical.

This article introduced me to the idea that culture has three layers; artifacts, espoused values and beliefs and basic underlying assumptions.

Companies rush to produce a design system or a component library as a hollow artifact. It’s little wonder they become stale and unused when it’s not a expression of an underlying cultural value.

Yesterday I essentially ascribed the failure of many ‘foundational’ front end efforts to poor project and product management.

But Martin is right. Even if you manage the work well, if the artifacts you produce aren’t a reflection of your product organisation culture, they will struggle to survive. Or you won’t get the value from them that you imagined.

As hands-on designers and developers, we may try to influence product development culture indirectly, in the way we know best - by building something that reflects the values, beliefs and assumptions we want to encourage.

But the thing we’ve built - the artifact - cannot change culture alone. Supporting it requires ongoing effort to influence other people’s assumptions and beliefs, and to be explicit about what those are.

Similar challenges crop up when introducing new architectural patterns, new programming languages, new agile practices and so on. It’s far too easy to lead with the shallow benefits of the artifact itself, and neglect the hidden cultural implications it seeks to introduce.

Can you think of any examples of ‘hollow artifacts’ that were introduced in your organisation? What cultural characteristics were they attempting to impose?

All the best,

– Jim