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:

seebach.tech

The Unblank Slate: Architects of Legacy

Foundry is uniquely suited to enable established players to unlock the value they hold in their legacies: their people as well as their technology and data…

Read more

2 years ago · Martin Seebach and Erik Winther Paisley

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.

I spent more than ten years with Palantir as an architect and software engineer, much of which was spent working with big, established organisations. Companies with legacies, both technical and institutional, and a tremendous power to innovate once given the tools to do their jobs.

The experience I had deploying Foundry was unlike conventional software projects. “Legacy organisations” have been through other digital transitions: The last thing they need is another layer of complexity on top of what they already had, but the idea of wiping the slate clean—acting like a startup—would never be in question.

Instead, we learned to deploy Foundry with the players inside the company, bring them onboard as co-creators, and take them through a process that was fundamentally unlike conventional software projects. Foundry gives you a freer hand to create architectures that release more value from the organisation without sacrificing safety or control.

The value of a legacy

Enterprise-scale organisations have an enormous resource in their deep ranks of workers who aren’t developers or programmers, but have vast practical and professional experience with the operation of the business. Over the years, they build banks of highly valuable proprietary knowledge that isn’t accessible to outsiders, whether competitors, consultants, or start-ups.

I’ve seen plenty of these organisations struggle with outdated technology, feeling the pressure to innovate. What I haven’t seen is one that didn’t know or understand this. It isn’t about lethargy or nostalgia for decades-old systems. Instead, they’re painfully aware that they can’t simply disrupt workflows that—for better or worse—do work, without losing irreplaceable institutional knowledge.

With Foundry, much of the value of the deployment stems from the ability to incorporate context-specific, bounded knowledge far more directly than other solutions.

Operational users, as they are referred to in Palantir, have often already been performing many of the functions they would need Foundry for—integrating, collaborating and governing data—just without the proper tools. Implementing Foundry should port their skills and knowledge over, just as it does the data and applications they use.

Reference Architectures

When I say architectures, I’m not simply referring to the architectures of systems and data. In the context of Foundry, it pays to think of architecture as spanning both the human and the technical sides of the equation. Once in operation, a Foundry deployment is a system that connects not just data and systems, but also users and developers as nodes in the architecture.

Foundry users are not simply end-users, working with a system from the outside, the way they’re usually plotted in architecture diagrams. Foundry is designed so that the ontology isn’t a brittle artefact that must be shielded from users. And equally, Foundry accessible enough that they don’t need to be shielded from making technical decisions, either.

In my experience, the most successful implementations are the ones that think of people and data together. Depending on the vision and ambition behind the choice of Foundry, and where the organisation adopting it is in their digital journey, there are different routes you can take to get there.

I’d like to use this series to share the four main patterns I’ve seen and helped implement, and discuss why you’d favour one or the other. With Foundry, it’s never a case of one-size fits all, but we can still talk about basic scenarios and how to approach them.

Structured autonomy

Subject-matter experts lead the process, nurturing and deploying Foundry from within their own departments. They receive training and guidance from a support team, but they work autonomously within the bounds Foundry set.

Right for: Organisations that are comfortable with decentralisation, or seeking wholesale digital transformation,  and an ideal fit for ones that embrace proactive initiatives and entrepreneurialism.

seebach.tech

The Unblank Slate: Structured Autonomy

Who this is right for…

Read more

2 years ago · Martin Seebach and Erik Winther Paisley

Task force deployment

A core team of developers and key subject-matter experts own the process from analysing the problem, integrating the relevant data to building the solution which is then rolled out to the rest of the organisation.

Right for: Organisations with a specific, well-defined problem in mind; also ideal way of piloting Foundry before deploying companywide.

Ecosystem

This process is led by partnering teams in separate organisations, working together to create a common ontology without compromising on data lineages or security

Right for: Integrated supply chains, distribution changes, inter-agency cooperation.

From scratch

Finally, we’ll talk about deployment from scratch: How best to implement Foundry when you do have a blank slate, and what the ideal pattern is for using it as the foundation for a new data and user structure.

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.

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.

seebach.tech

Planning your deployment of Foundry

Whether you’re just getting started or you’re a few use cases in and want to take Foundry to the next level, I have often been asked what the best practices for deploying Foundry are. I can’t deny that my answer has sometimes been functionally equivalent to the meme about how to draw an owl…

Read more

2 years ago · 5 likes · Martin Seebach and Erik Winther Paisley

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.

I could tell you that it should be well-proportioned and detailed, with clean lines and so on, but advice at that level of abstraction doesn’t get you any closer to a finished result. The point of this post is that a definitive plan does not exist. I’d be selling snake oil if I told you there’s one way to do it. 

As with drawing, memory and imagination can only get you so far. It’s well known that even fairly minor projects have a way of going over schedule, budget, and underwhelming once delivered. My argument is that this happens because too much time is spent planning and anticipating instead of doing and dealing. 

You just need to draw the damned owl. 

If a successful Foundry deployment is your owl, the people, processes and technology of the organisation is your pen and paper. In practice, you will always end up working piecemeal, guided by operational users at their desk, to map these elements to your intended outcomes.

Each piece—staff, ways of working, data and existing software suite—is specific to your organisation. And nothing will be more unique than your goals. These allow us to draw the circles to give the owl its outline and proportions. But for what comes after, my advice is simply to get to it.

There are three broad principles to guide the strokes:

1. Work in short, iterative steps. In my experience, organisations willing to take a bottom-up, iterative approach to deployment get further faster. They don’t expect to get everything right from the beginning, but they also never assume that their central teams—or expensive consultants—will have all the answers.

2. Cast a wide net. Successful Foundry deployments involve a much wider set of client-side employees than you’d typically see in an enterprise IT project. In my experience, Foundry enables a very wide range of personas to contribute actively, and they can be productively included early in the project.

3. Make close allies. Far beyond the elusive knowledge-worker, almost everyone in the organisation uses data in some capacity. The real milestones are the points where lasting contributions are being made and shared by users who never thought they’d be able to use a tool like Foundry, let alone help deploy it. They will be your most eager advocates.

The art of deploying Foundry isn’t about perfect planning, but making continuous progress. You can’t let the fear of making a mistake get in the way of what is ultimately a creative process, with constant adjustments and refinements along the way. You simply need to put pen to paper—and trust that with the right people, tools and visions, your owl will come to life.

Subscribe now

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.

At Palantir, Shyam kept an open line of communications with the company through emails, all-hands, and informal sessions. He could be blunt and hyperbolic1, but he was also the first to insist that he was not always right, and he would encourage staff to be quite blunt in telling him so.

My colleagues and I would need a moment to process his messages and discuss, sometimes in exasperation and sometimes in confusion, but I always appreciated his candor. However frustrating his messages could be, we never doubted that we had access to his unfiltered thoughts and ideas for the business. Bloodless corporate memos were not Shyam’s style, to say the least.

This is Founder Mode. Shyam’s messages filtered through the business and became actionable in our day-to-day work. We rarely encountered deployment challenges where we couldn’t deduce what Shyam would expect us to do.

I recall one time where we heard that a client that was engaged through a services partner was unhappy with their implementation project. We booked a meeting with the partner, flew over, and ignored their evident resentfulness at our comparatively junior status. The project was indeed a terrible mess. Could we meet the client? No, that was supposedly impossible. We pointedly ignored that and called around. The next day we were welcomed in by the client, with a rather stiff-faced manager from the partner in tow, and got to work fixing the project.

Here we were—two junior engineers who had just spent thousands of dollars on travel and jeopardised a partnership so that we could get to the fire. No reviews or approvals (or indeed much of a plan), but absolute certainty that this was what Shyam would want us to do. Without direct instructions, we understood that we had a clear mandate to get to the client’s problem and then solve it. We did both.

Palantir had less than 2,000 employees at the time, yet we were running a global operation. For all the shade Paul Graham throws at delegation in the essay, I think Palantir delegated extremely well, and the shared clarity on direction is what enabled that. Running in Founder Mode allowed us to achieve levels of delegation companies ten times the size don’t have.

But crucially—and the point I really want to make here—this clarity was paired with agency and accountability. We were empowered to make bold decisions and deploy considerable resources in pursuit of the strategy—to shoot for the moon. It was also clear to your peers, to Shyam, and to yourself if you weren’t delivering.

To me, this is what accountability is all about. Are you delivering on the strategic objectives of the business? The alternative ends up as box ticking—KPIs, internal compliance2, revenue, meetings, accounted for by quarter. 

My former colleagues reading this will have rolled their eyes at my rose-tinted account more than once by now, but I’m sure they’ll agree that it captures our “X-factor”. The combination of high agency and high accountability was key to the value we would bring to the “normal” companies that became our clients.

Key to the success of Founder Mode companies is the understanding that accountability and agency go hand in hand. 

Lessons for Manager Mode companies

It’s true that agency without accountability descend into tyranny—or chaos. Yet this understanding has manifested a cultural fear of power itself. Accountability without agency is mindless compliance culture—you can’t meaningfully be accountable if you can’t influence outcomes. Take one away and the other withers.

In Manager Mode, fear of power wears down agency. Once this happens, accountability duly follows suit—and is reduced, in many cases, to zero. A leader might say “the buck stops with me” (and mean it), but what good does it do if the buck never gets to them, or never starts moving in the first place?

We need to unlearn some of this fear to ward off stagnation in our institutions. It’s easy to agree in general terms that we need more accountability, but to be meaningfully accountable, people need to be trusted with real agency—or power.

It’s unlikely that there’s a way for mature companies to switch to Founder Mode, but they can still learn from the conspicuous absence of management as a stand-alone discipline in start-ups. Things are managed, but not by designated managers.

The lesson for companies in Manager Mode, or companies that are outgrowing Founder Mode, is that management isn’t a generic activity that can be divorced from the substance of what is being managed.

Only managers who understand what their reports do, often from having done it themselves, can be trusted with the power to enable their reports and hold them accountable. To credibly urge someone towards excellence, a manager needs to understand what great looks like. 

Equally, to shield them from misguided accountability, the manager must be able to look at the ground truth behind the KPIs. There’s a huge difference in holding someone accountable for having shot for the moon and missed, versus just not doing their job very well.

You absolutely need people to shoot for the moon (and many lesser efforts below that), but a manager whose perspective is limited to tests passing and Jira-tickets resolved doesn’t have the agency to inspire their team to do it.

Subscribe now

Thank you to several former colleagues who stopped rolling their eyes for long enough to give me invaluable feedback on drafts of this post.

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.

Through these projects, I got to meet a whole host of people with genuine passion for the work they did—often in organisations that themselves work behind the scenes to keep the world running smoothly in ways that are easy to take for granted as an outsider. 

As a data architect, your work brings you right to the core of the organisation. My backstage passes taught me a lot about how the many ways large organisations navigate complexity, but also showed me how they can struggle with the tools at their disposal. 

The usual Foundry client isn’t starting from scratch and they aren’t lacking in ambition. They know that data integration is essential, and they’ve put time and resources into exploring the options on the market. By the time we got involved, they had often built out an elaborate internal structure of tools and modules that never quite delivered for the business.

And there’s no lack of products on the market. In any typical large organisation you might find a set up consisting of interlocking data lakes, warehouses, dashboarding and reporting software, specialist point solutions and many more, augmented by a ‘last mile’ thicket of spreadsheets and powerpoints.

These tools each have their strengths, but they also have an inherent affinity to one part or function of the business. A tool that's powerful in the hands of IT will often feel overwhelming or inaccessible for a business user, while a 'user-friendly' business tool can be limiting for a software engineer. There’s inevitably a high degree of friction, bottlenecks and incompatibilities.

Organisations can and do make it work, even to great effect, but the process of joining up a multiplicity of tools is in every case a massive commitment on the part of the IT organisation. They find themselves tied to an open-ended software development project that’s always playing catch-up with user requests. It isn’t a satisfying way to work, no matter how passionate you are.

What struck me about Foundry was how it managed to change that dynamic. It’s a testament to Foundry’s technical capabilities that you’re able to bring IT pros, business analysts, and generalists onto a common platform that caters to such different expectations and skill sets. 

It’s always been one of the most rewarding aspects of working with Foundry—seeing an IT project succeed by letting end-users play to their strengths. Shifting the variety of tools onto the platform also had the effect of giving colleagues a common language, and freed up their hands to be far more self-reliant—and bold—than they’d been in the past.

To answer my own question, that’s why I like working with Foundry. And why I’ve set up my own consulting practice in the field.

This is exactly what my practice will focus on: leveraging the unique capabilities of Foundry to fulfil the promise of technology by taking a hard turn away from sprawling, ever-larger IT-centred projects, and putting initiative back into the hands of the grassroots, the countless professionals in every industry with all impossibly and wonderfully varied needs and abilities.

I’ll be sharing a series of posts over the next weeks to explore how I have come to understand this can be achieved, and other topics that have come up in conversations and on projects over the years. I hope you’ll subscribe and read along. 

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.

A Backdrop of Technology

Technology that works has a tendency to just seep into the background. If you have a reasonably modern smartphone, you use quite a lot of advanced AI technology every time you take a photo. The mechanics of pointing the camera at a subject (more often than not, a cat) and pushing the button, remain the same, but the process is completely different, not even the optics are really comparable to those in a film camera anymore. But the results, especially in challenging conditions, are incomparable – it’s almost impossible to take a photo that’s out of focus, incorrectly lit, has motion blurring or any of the other ailments the average holiday snaps from the film-age would suffer from. Few people think much about it, if anything, there’s a challenge of dealing with an archive of photos numbering in the thousands: It’s just what cameras do.

Another example is driverless cars. Replacing drivers with AIs remains frustratingly over-promised and under-delivered: But new cars have adaptive cruise control, automatic braking, lane assist and sensors to aid in parking. All are the spoils, the “peace dividend”, of decades of work towards driverless cars, and more likely than not, employ a fair bit of AI to deploy, but we don’t really think of them as such, we don’t really marvel at driving an 80% self-driving car, nor do most drivers even reflect much on how much better this is than just a decade ago. It’s just what cars do.

Into the Shadows

In a recent leaked memo from Google, the author laments that the firm has no moat around their LLM models. They had, as had OpenAI, assumed that being one of a few organisations in the world controlling the immense data centre resources required to train and run the largest LLMs such as Bard and GPT, they would be able to control the market, at least for a while.

No such luck: Meta’s LLaMA model leaked to the public, and in a matter of weeks, it was modified, hacked and tuned to run on consumer grade gear, and an explosion in applications appeared.

I’m quite sceptical that the outcome of the LLM-revolution will look very much like ChatGPT does today. Outside of a handful of specific situations, speaking to a computer does not seem like a terribly useful interface.

However, the awesome power demonstrated by LLMs will make its way into an immense range of applications. This is another important point the memo makes: A relatively small model, trained on a modest data set of high quality for a specific purpose is more powerful than a huge, general purpose model applied to the same purpose.

Expect to see a lot of interesting developments in the near future. But equally expect, ironically, to not see them.

“I think there’s a world market for maybe five computers”, the president of IBM, Thomas Watson, famously said in 1943 – today we’re looking at closer to five computers per person.

If we could travel back 80 years and show the world of today to Turing and Watson, what would they think? Yes, almost every human is carrying a (really quite capable) internet-connected computer in their pocket, and are able to pull up an effectively infinite wealth of information and communicate with anyone anywhere – this is certainly impressive, and unlikely to be predictable from a 1940s vantage point.

Missing Progress

But they are also very likely to be stumped by the degree to which society is just fundamentally unchanged. Previous technological revolutions profoundly altered the fabric of society, to an extent that it can be difficult to even imagine life before, and rarely taking more than a few decades to do so. The mechanisation of agriculture changed society from one where almost everyone was employed in food production to one where less than 5% is.

My father grew up on a farm in a village. In his childhood home, the family was occupied tending to the land and the animals, and even employed farm hands. Today, all the land around the village, which previously required 5-7 farms with families and helpers to manage, is tended by one person and his machines. The rest of the farm houses are homes, workshops and light industry. None are occupied in food production.

The Revolution that Wasn’t

Where’s the equivalent for the computer revolution? Yes, we can work from home and it is significantly more feasible to operate a distributed business. With email and calendars on smartphones, many fewer secretaries are needed. But consult any statistical series documenting any significant parameter of society, and you’ll be hard pressed to point to where computers changed everything.

So what happened? Why has the revolution been so muted when the technology is so awesome?

There are two key factors that contribute to this: First, computers are the first technology that is truly general purpose; second, the opportunity-space is simply too vast – innovation is born of constraint, not possibility.

The Curse of General Purpose

Computers increase the productivity of a large number of tasks – but they also increase the productivity of drag and bureaucracy.

Take forms, the quintessential artefact of bureaucracy: Before computers, bureaucrats had to sit behind a desk and process physical forms. Forms would be pre-printed, and costly to update. They would be limited by the size of the sheet of paper and even the cost of mailing it around. The number of copies is restricted by how many layers a typewriter can punch through, and this again limits how many steps approval can require.

Rejection to change some detail entails restarting the whole process, with the full typing of the whole form.

Today, digital forms are effectively free to set up and email to thousands of people. They are endless in their demand for detail, and approvers can send them back for the tiniest of discrepancies. And submissions are often copied into dozens of mailboxes, all of which have a vague remit to direct attention to something or other, or kindly request some explanation or elaboration.

The Curse of Opportunity

Efficiency, and to a large extent progress, is the child of necessity, not boundless possibilities. Technology, and specifically computers, offer way too much opportunity.

The steam engine, driver of a much larger revolution than computers, makes a wheel turn with great force. That’s it. When building the technologies and businesses that would underpin the industrial revolution, inventors and entrepreneurs had one question, and one question only, to answer: What can I do with a turning wheel?

Their counterparts today are faced with machines that can do almost anything, and so end up spread too thin.

Less is More

Much can be learned from those 19th century innovators.

The organisations that deploy technology successfully typically do so with great focus; they effectively restrict the scope of opportunity and direct their attention to a narrow window at the pinnacle of the business’ core competency.

A successful software project begins and ends with a clear understanding of the problem that is being solved, and its relevance to the specific competitive advantages and market position faced by the business, and combines it with confident leadership to shield the project from undue temptations to expand the scope in irrelevant directions.