The Unblank Slate: Structured Autonomy
Foundry sets the structure; teams act autonomously within it.
Who this is right for
Structured autonomy thrives as a deployment strategy in organisations that embrace decentralisation, proactive initiatives, and entrepreneurialism. Rather than relying on a masterplan to direct the details, the driving force of a deployment using this approach will be a unifying vision, backed by charismatic leadership, which is able to inspire and structure innovations coming from the grassroots of the organisation.
A new structure for software management
This is the ideal process for a company-wide digital transformation. The aim is to create an architecture that captures the knowledge of the subject-matter experts whose decisions and priorities Foundry is there to support.
Foundry sets the structure; teams act autonomously within it. In practical terms, deployment is led by the pre-existing teams in the organisation, acting within their own departments. This pattern still requires a central support team of developers and Foundry experts, but they’re acting as advisors and consultants.
The idea of structured autonomy runs counter to conventional wisdom for software technology projects. It’s usually the case that developer time is considered too precious not to be controlled centrally. And even if it weren’t, it would be too risky for governance and security to loosen the reins. It’s down to the unique design of Foundry, especially the ontology, that it’s possible to diverge from the orthodoxy without running those risks.
Let leaders lead and experts get to work
In deployment, Foundry is robust and accessible enough that users don’t need to route every request through a central IT bottleneck. This pays dividends in both speed, since the deployment is able to draw on a much wider pool of talent in the organisation, and in quality, because they’re bringing their judgment and experience as much as their time. That means less waiting, greater agency, and more buy-in from the users whose expertise the system is designed to support.
In my experience, the hallmark of a successful Foundry deployment is when professional users can run end-to-end analyses on their own, without outside support. I remember meeting a mechanical engineer who’d only had his intro to the platform a week or two before, and was now excitedly showing us an analysis he had just completed. He’d gone from hunch (that a certain type of component was wearing out sooner than expected), to data analysis (it wasn’t) to institutional knowhow (creating a reusable analysis tool) in the course of a morning. That’s what it means to be data-driven.
The central team role is to step in at critical junctures where the business users need specialist technical, analytical or architectural support, for example in designing a tricky data integration. Crucially, the specialists aren’t there to direct the process or make operational decisions.
The role of the central team
That is the end goal. In the initial phase, the central team will need to engage with the business teams to identify suitable projects, train users and set them on the path. As the first few of these projects deliver results, the central team role shifts toward evangelising and encouraging more teams to take up the challenge, and also to coordinating knowledge exchange. Ultimately, they serve as a center of excellence for Foundry in the business. So there isn’t a single masterplan, but plenty of work remains for the team in fostering collaboration and shepherding teams around the vision behind the deployment.
The central team classically defines a small central ontology, analogous to Master Data Management, which helps keep teams working parallel. As the deployment matures and becomes embedded in the organisation, Foundry, underpinned by the ontology, provides the structure for the individual projects to dovetail without compromising on data lineages, robustness or security.
This post is part of a series:
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.