the cooperation problem
On the fluid nature of human cooperation, the distance between work and the people who care about it, and why Balladic refuses to impose a shape.
The thing about cooperation is that no two instances of it look the same. Two people renovating a kitchen operate on gut feeling and shared glances, a film crew of forty synchronizes through hierarchy, shorthand and a healthy fear of overtime, a four-person dev team runs on pull requests and the vague hope that everyone read the spec. Each a form of cooperation that wouldn’t survive the other’s process.
shape and frame
What you notice, when you watch long enough, is that the shape always follows the contours of the work and the people doing it. A designer doesn’t work in tickets, a strategist doesn’t think in sprints, a client doesn’t care about your column names. The cooperation finds its own form, and when that form is imposed from the outside, the actual work starts routing around it - through DMs, email threads and “quick calls” that should have been tasks.
Most project management tools begin from the opposite assumption, that there is a correct shape, a universal one, and that the tool’s job is to provide the frame. This is understandable - you can’t build software for something you haven’t defined - but it produces a strange effect where the tool starts generating its own kind of work. Standups, status updates, weekly reports. Rituals that exist to manage the distance between the work and the people who care about it.
the distance
Consider how this distance operates in practice. A developer finishes a feature, a project manager writes a summary, the client reads it and asks a question, the PM relays the question, the developer answers, the PM relays the answer. Each step is a translation, each translation loses fidelity, and the entire chain exists because the tool kept the client at arm’s length from the work in the first place. The reporting costs the same energy as the work itself, and nobody questions it because everyone assumes it’s just how things are.
fluidity as design
The question at the root of Balladic was what happens when you refuse to impose a shape - when the platform stays adaptive enough to let structure emerge from what the team actually does, so a client sees the work without someone having to package it for them, and automation handles the ceremony while humans focus on the judgment calls.
This is where column effects came from, triggering when work moves through stages, and why augments exist to snap onto a project when it needs them and stay absent when it doesn’t, and why the feed ranks by urgency and context rather than chronology, since what happened last is rarely what matters most. The pieces have all existed before; what changes is the composition, and the underlying bet that a tool which stays quiet and adapts will serve more shapes of cooperation than one that prescribes a single way of working.
honesty
We use Balladic to build Balladic, which is the only honest way I know to test whether a tool actually supports work or merely organizes the appearance of it. If the distance grows between what’s happening and what’s visible, we feel it immediately, and that feedback loop has shaped every decision about what the platform does and - more often - what it refuses to do.
Build it for yourself, then see if it holds when others bring their own shape.
