Preface
There is a scene that repeats almost without variation. An organization (a small business, a city government, a whole division of a large company) decides to take the leap: at last, technology; at last, artificial intelligence. There is enthusiasm, there is budget, and sometimes there is even a good vendor. A few months later, the enthusiasm has cooled, the budget is spent, and the system that was going to change everything is still there, switched on, with no one using it. Nobody wanted it to end that way. It was not bad luck or clumsiness on anyone’s part. It was a misunderstanding about what kind of problem was being solved.
This book is about that misunderstanding and about how to avoid it. It holds a single idea, carried through to its consequences: transforming an organization with technology, and today with artificial intelligence, is first of all a human problem, and only afterwards a technical one. Most AI projects fail not because of the technology, but because no one read the organization before installing it. Whoever treats the problem as technical fails in an almost predictable way. Whoever learns to read the human fabric and to build the system with the same hand occupies an uncommon position and, to say it from the start, a very rewarding one to inhabit. The pages that follow explain why, and how.
Why this book: the point of the reflection
It is easy to talk about technology adoption in the cold language of productivity: rates, efficiencies, return on investment, competitive advantage. All of that is true, and this book does not dodge it. There are pages devoted to the economic gap, measurable and ever wider, that artificial intelligence is opening between the organizations that absorb it and those that stand watching. The economic dimension is real and serious; ignoring it would be naive. But staying only there means missing what matters most.
Behind every “project that did not pay off” there are people. There is the employee who learned to do the job one way and is told, overnight, that from now on it will be done another, and who suspects, not without reason, that the underlying plan is to make them redundant. There is the small-business owner who bet years of savings on a system she was promised and cannot understand why her own people avoid it. There is the public servant who genuinely wanted to serve residents better and ended up with a digital procedure slower than the paper one. Technology never touches only technology. It touches the way people spend their days, earn their living and feel (or stop feeling) that they are good for something. Designing those systems badly is not an abstract technical error: it makes the lives of those who spend their working day with them a little poorer.
Artificial intelligence raises the stakes, because it lands exactly where human judgment used to be: the decision, the criterion, the craft. That is why it stirs so much hope and so much fear at once, and why it deserves something better than fashionable enthusiasm or reflexive rejection. It deserves someone willing to ask, case by case: does this amplify what this person knows how to do, or replace them without replacing what they contributed? Does it make them more capable, or merely more dispensable? A model does not answer that question. It is answered by someone who sat down to understand the real work of real people and who takes responsibility for the answer.
There is also a simpler, more personal reason, and I prefer to say it plainly. Solving a real problem, one that was making someone’s life harder and stopped doing so after the intervention, is one of the most human and most satisfying experiences I know. It is not about “putting a model into production”. It is about easing a task, freeing up an hour, making a decision a little fairer because it now rests on data that does not lie. That is, for me, the ultimate point of this craft, and the reason it is worth doing well before doing fast. That is why the bridge this book describes is, besides a scarce market position, a way of working that refuses to treat people as a detail to be sorted out after the technology. People first. Technique, with all its rigor, is there to serve them, not the other way around.
Where one starts from
This book takes no starting point for granted, because there is not just one, and every reader will recognize themselves in one of them. Some organizations feel they have almost nothing, although pure zero hardly exists anymore: there is always a jealously guarded spreadsheet, the tax system, or a chat group that works, in fact, as the real operating system. What they lack is not technology but design, and their challenge is to build a first backbone without crushing the informal arrangements that were working. Others live in islands: systems bought over the years that do not talk to one another, with each area owning its own version of the truth. There the challenge is to integrate. And there are mature but fragmented organizations, with solid systems, ordered data and capable teams, whose challenge is to orchestrate what they already own without getting stuck in the inertia of “we have always done it this way”.
At none of those points is the decisive question technical. It is not “what do I buy?” or “which model do I use?”. It is always the same sociotechnical question: what do these people do, why do they do it this way, and what will really change in their work if this moves? The principle is the same across the whole spectrum; what changes is where the emphasis falls. The thesis chapter develops each of those starting points, and the method this book proposes adapts to all three.
There is a second axis, as important as the first: not only where one starts from, but where one leaps to. Technology adoption is not a switch but a ladder climbed step by step. At the bottom is everyday office work: the spreadsheet, the document, the email. Higher up are the systems that order the operation, such as an ERP that integrates administration or a CRM that gathers the customer relationship in one place. Next comes predictive artificial intelligence, which uses accumulated data to anticipate demand, a customer’s churn or a risk, instead of merely recording the past. And on today’s step is what has come to be called the agentic revolution: software that no longer only suggests but executes tasks end to end, pushing a new wave of productivity built on automating digital work.
On every step the temptation is the same: to believe the leap can be bought. It cannot. And the higher the step, the higher the risk of climbing it without first reading the human fabric. The promise of productivity is real; so is the condition for collecting it: that each step be climbed on top of an organization someone took the trouble to understand. Nor is it a one-way ladder. In SMEs, recent qualitative evidence (Amanollahnejad et al., 2026) describes adoption as recursive and episodic, with partial, reversible progress; that is why the maturity snapshot has to be repeated, and sustained with sociotechnical hygiene so it does not unravel.
What this book is
It is not a tool manual or a catalogue of success stories. It is the ordered, argued exposition of a paradigm. It brings together a central thesis, the sociotechnical bridge; the method that puts it into practice by articulating four disciplines (sociology of organizations, software engineering, data engineering, and AI architecture and governance); the vocabulary with which that method thinks; the academic foundations that hold it up; and its concrete applications to small business and to the State. It is one idea, unfolded carefully to the end.
It is also a living book. It is under construction and gains depth with each revision: some chapters are already developed in detail, with their apparatus of citations, while others are still working versions that will be expanded. Each chapter honestly declares its degree of maturity. It is published in the open, under an open license for copying and distribution, because its value lies in being improved in plain sight rather than in pretending to be finished. A book that argues one must read people could not, itself, hide from the reader.
Who it is for
For whoever decides on technology in an organization and suspects, deep down, that the problem was not in the tool. For the technical professional who senses that the best system they ever built goes unused for reasons that appear nowhere in the code. For the public servant, the small-business owner, the sociology or engineering student looking for a framework that does not separate people from data as if they were two worlds. And for whoever wants to examine the soundness of a way of thinking rather than a résumé: the book is, also, that way of thinking put to the test.
The promise: rigor, not hype
A single rule governs these pages: every claim that carries data carries its source, and only what could be verified is published. Where a number is an estimate or a design decision, it is said in so many words. There are no filler figures and no “studies say” without a reference. The sources are gathered, in author-date style, in the Bibliography. This is not academic pedantry but a matter of respect. The cost of a single invented citation is the credibility of everything else, and someone who writes about trust cannot afford to betray it in a footnote. That is why rigor is part of the argument.
How to read it
It can be read straight through, since the order of the parts follows the reasoning, or you can enter wherever your own problem presses hardest. Either way, it helps to know that the book is not a catalogue of loose ideas. The same tensions return in different chapters, each time in more detail, as in a spiral. The adoption ladder, for instance, first appears as an intuition in the thesis, later as vocabulary, and finally as IMIA levels. Each pass adds a layer without repeating the same sentence.
A thread to follow the argument
Throughout the book you will meet Distribuidora Norte, a fictional food-and-beverage SME, rebuilt from field patterns rather than from a real client. It first appears with a query assistant that no one ended up using; then it asks for a customer churn model; later it returns with delivery spreadsheets, a pilot that left a scar, and the question of whether it is ready to automate further. You do not need to memorize every detail. The thread is there to show how the same method changes shape depending on what the organization has, or has not, learned along the way.
Routes depending on where you read from
If you decide in an SME (owner, manager, board): start with The bridge thesis, then go on to The four links and The bridge applied to SMEs. IMIA and Value metrics are worth reading before signing a technology budget. The academic foundations (Part III) can wait: they reinforce the thesis, but do not replace it.
If you work in the public sector (official, systems area, modernization): the thesis, the diagnostic method and The bridge applied to the public sector form the core. IMIA and value metrics help make the promise of “digital maturity” falsifiable before procurement.
If you build (development, data, architecture): read the thesis for the human frame, Concepts of our own as working vocabulary, and Reflective practice as a field mirror. If you want the foundation, Part III explains where each piece of the method comes from.
Linear reading (recommended the first time):
- The sociotechnical problem — the thesis and its proof. If there is time for only one chapter, let it be this one.
- The method — four links, vocabulary, diagnosis, hygiene and adoption.
- Foundations — eight currents and the agentic extension.
- Applications — SME, State, IMIA, value dashboard.
- Synthesis — the full arc reunited and “so what”.
The search box (the / key) runs across the whole book and jumps to the exact passage.
Previous/next navigation follows the thread of the argument.
On the origin
This paradigm was not built in the abstract, at a clean desk. It came out of an integration uncommon in the market: the sociology of organizations combined with more than a decade of software and data engineering in production and regulated environments, where systems have to truly work and be accountable. That biography explains where the framework comes from, but it is not its subject: the book sets out the paradigm, not its author. To learn about the practice behind it, see About the author or visit gonzaloflores.dev. The paradigm’s validation rests on two planes, the academic foundations it cites and the practice it was born from (systems in production, MCP servers, the IMIA maturity model), and not on a personal track record.
What follows is the thread of the argument, from the beginning. If all goes well, by the end of the book the scene from the first paragraph, the switched-on system no one uses, will have stopped looking like bad luck and become what it always was: a problem that could have been read in time.