Marking the occasion
Why IT can’t catch a break, transgressing against software etiquette, and what the greeting card industry can teach us about deploying Foundry
With any creative project, there’s a certain horror at the sight of a blank page. To fill that gap, in art there’s a constant demand for supports like paint by numbers, tracing paper, and templates.
In personal life, too, you get products like greeting cards. To the recipient, there’s almost always a touch of disappointment in an unoriginal card or a ready-made message. Why then do senders opt for them—just the fright of not knowing where to begin?
My theory is that beyond the undeniable convenience, greeting cards serve what is effectively a compliance function. They are a guaranteed safe way of expressing a sentiment, and as with so many compliance functions, the cost of losing some originality is acceptable.
Fear of the faux pas
Handwriting a personal note is more earnest, but it’s easier to stumble into a faux pas.
A pre-printed card, even with the exact same message, comes with the imprint of a social arbiter—a literal hallmark.
In deploying Foundry I have encountered the same fear of transgressing against the accepted standard, leading to the question ‘what is the safe option? What is everyone else doing?’
The greeting card industry caters to a mass market of standardised occasions. They employ scores of writers, churning out a seemingly endless variety of cards, but ultimately cater to a limited number of standardised occasions. However lovely Grandma is, she’s exactly as 80 on her 80th birthday as anyone else’s grandma would be.
The trouble with templates
For parts of your business that are like everyone else’s—payroll, expenses, email—the only rational thing is to just pick a card off the rack.
But as you get closer to the heart of your business, the chances of finding an appropriate card gets slimmer. As I touched upon in the previous post, the business that you’re deploying Foundry to is anything but standardised.
Received wisdom holds that a “blank page” approach to software is unworkable because of the skills required and the need to ensure security and integrity through robust governance. Enterprise IT departments have found themselves in the unenviable position of having to procure an appropriate greeting card from the market for every occasion the business wants to mark.
The task of servicing the few important occasions that the business absolutely needs to mark but can’t find a card for—that is, any and all development projects the business is forced to undertake internally—falls to a tightly guarded core team of specialists. This model does manage risk, but what might be an acceptable loss of originality in a birthday card translates to a chronic bottleneck on the creative impulses of the business.
How Foundry breaks the bottleneck
Foundry has upset this established order. Because of its novel way of embedding security and governance within the data—in the ontology—organisations now enjoy a freedom of action that would have been irresponsible before.
In my experience, IT organisations have a tendency to evaluate Foundry as a tool for them to build services for the rest of the business. This is a mistake. The power of Foundry lies in its ability to break the bottleneck and enable large swathes of the business to self-service a wide range of their data and development needs.
A few examples:
A mechanical engineer who self-services a technically non-trivial analytic question to make quick data-driven decisions in their own area of expertise
A customer success team lead who builds a simple app to manage a specific, once-off task-force
Business analysts who can replace their finely tuned, but insecure and cumbersome, Excel/email workflows with Foundry-based tools and sustainably scale their work to a wider audience
These are all individual occasions, calling for ad-hoc solutions that may never be used again. Like a greeting card publisher, the IT leader is in the awkward position of either over-investing resources into a one-off solution, or trying to persuade the user to settle for something more generic (or generalisable), which means forgoing the creativity and ingenuity that inspired the request in the first place.
Where this leaves IT organisations
Does this mean that Foundry will displace the central IT organisation? No, on the contrary. Once the barrage of user requests—and the frustration of having to reject so many of them—relents, the team can dedicate their attention to managing the Foundry system overall and ensuring safe and sound flow of data within the business. Instead of solving individual problems, they can solve classes of problems. Focus on enabling the users, not delivering finished solutions for them.
It gets IT out of the role of draughtsmen and designers working to someone else’s brief, into a role as masters and teachers. What can initially be interpreted as a loss of status easily proves to be fulcrum for much larger leverage. The first step? Daring colleagues to commit pen to paper.
Martin Seebach is an independent data architect and consultant with a long history working for Palantir. Details on his practice and how to get in touch at seebach.tech.
Co-author Erik Winther Paisley is a researcher and anthropologist of technology. Details on his research offering at ewpaisley.com.
Foundry® is a trademark of Palantir Technologies Inc.