Das Coisas Nascem As Coisas

Understanding "das coisas nascem as coisas" — A Practical Guide

Most people encounter this phrase in academic or design circles without really knowing what to do with it. It comes up in complex systems work, participatory design processes, and occasionally in organizational strategy discussions. The short version is that it describes a particular way of thinking about causality and emergence — not a tool you download, but a framework you apply. The phrase translates literally as "from things, things are born." It originates from Brazilian philosophical and anthropological thought, notably connected to the work of Deleuze and Guattari as interpreted through Latin American thought. In practice, it describes how outcomes emerge organically from the interactions of existing elements rather than being designed top-down. You don't force a result. You set conditions and let the system generate its own structure. In systems thinking terms, this is close to what we call emergent behavior — properties that arise from the interaction of components but cannot be predicted by examining any single component alone. It's also related to second-order cybernetics, where the observer is part of the system they're observing.

How to actually apply it in your work

I've used this framework in a few different contexts over the years — mostly in organizational change and community-driven product development. Here's the practical part that most guides skip: applying this isn't about sitting back and doing nothing. It's about carefully calibrating the initial conditions so the right kinds of interactions become possible. The process generally looks like this: First, map the existing ecosystem. Identify all the actors, resources, constraints, and relationships already in play. Don't assume you need to create anything new — the phrase itself tells you the raw materials are already there. Second, identify the feedback loops. Where does action A lead back to influence action A? These loops are where the system tends to either stabilize or spiral. Third, find the leverage points — places where a small shift in conditions changes the structure of the system rather than just pushing harder on an existing variable. Fourth, make your intervention minimal. This is the hardest part. You have to resist the urge to design the outcome.

I remember working on a community health initiative a few years back where we kept failing because every new program we introduced just got absorbed into the existing power structures and neutralized. We'd spend months designing interventions, then watch them dissolve within weeks. The breakthrough came when we stopped trying to add new structures and instead changed the information flow between existing actors. Health workers started sharing data directly with each other instead of routing everything through clinic administrators. Within three months, the informal network was generating its own protocols, resource allocations, and priorities. We hadn't designed any of it. That's the difference between intervention and facilitation.

Where this approach actually fails

I want to be clear about the limitations because most people presenting this concept don't. This framework does not work well in high-stakes environments where speed of decision matters — emergency response, military operations, acute crisis management. In those contexts, the emergent approach is too slow and too unpredictable. You need command structures, not enabling conditions. It also breaks down in highly hierarchical organizations where information flows strictly downward. If the people who know the actual problem don't have the authority to act on it, "letting things emerge" just means the same old problems persist with more jargon attached. I've seen this happen in several large institutional settings where leadership would adopt the language of emergence without giving anyone real autonomy. The result was just bureaucratic paralysis dressed in new vocabulary. There's also a specific edge case that caught me off guard once: when the existing ecosystem itself is broken or hostile. If the "things" that are already present are damaged, excluded, or systematically undermined, then "from things, things are born" just means more damage is born. Before applying this framework, you need to assess whether the foundational conditions are healthy enough for organic emergence. In my experience, about 40 percent of projects I've seen attempt this approach were built on ecosystems that needed repair first — and nobody wanted to do the repair work because it wasn't as visually compelling as the emergence part.

Common pitfalls and how to avoid them

The most common mistake is confusing this framework with passivity. Letting things emerge doesn't mean doing nothing. It means doing a different kind of work — work that's harder to measure and less visible. You're still designing, but you're designing the conditions for design rather than designing the outcome directly. The distinction matters a lot. Another trap is assuming that emergent solutions are automatically better than designed ones. They're not. Emergent solutions tend to be more resilient and contextually appropriate, but they also tend to be slower, less predictable, and sometimes inconsistent across different parts of the system. If you need uniformity — say, a safety protocol across multiple facilities — emergence alone won't get you there. When dealing with this approach, keep these specific questions in mind before starting: What existing relationships can I strengthen? What information is currently blocked or distorted? Where are the natural feedback loops that could reinforce the behavior I want? And critically — am I willing to let go of the outcome I originally imagined?

The last one is the real test. Most people who claim to use this framework can't actually let go. They want emergence but on their schedule and within their comfort zone. That's not what the concept means. It means accepting that the result might look nothing like your original plan and having the discipline to work with what actually appears rather than what you wished would appear.

A note on tools and resources

There's no software or product that implements "das coisas nascem as coisas" directly. The closest practical tools are systems mapping software like Kumu or Miro for visualizing feedback loops, participatory workshops for surfacing existing relationships, and iterative prototyping to test conditions without locking in outcomes. Some teams also use agent-based modeling to simulate how different initial conditions might play out over time, though this has its own limitations with complex social systems. If you're looking to learn more, the original philosophical roots are in Deleuze and Guattari's work on rhizomatic thinking, though it's dense. More accessible entries can be found in complexity theory literature — particularly works by Melvin Edwards and the Santa Fe Institute publications on adaptive systems. For applied perspectives, look into participatory design methodologies and the work of Yvonne Rogers on co-production. The phrase itself has been adopted in various Brazilian social movement contexts, particularly around community-based planning and agroecology. If you're working in those spaces, the practical wisdom embedded in decades of field application might teach you more than any theoretical framework alone.