Collective Attention as a Service: A Postmortem of Ize 👀

Ize was a meditation on a question: Software has severely fragmented our collective attention, but could it also knit it back together?

I spent a year pursuing this question, draining my bank account and sanity in the process. The result was a coordination tool that fell in the awkward space between a SaaS product and a conceptual art piece. It was more successful as the latter than the former.

Ize channels collective attention so we can build something bigger that’s than the sum of its parts. I saw it as meaning infrastructure for the metacrisis. To investors, I gave a more prosaic description:.

Ize is a platform for distributed teamwork automation. It allows teams and AI agents to learn, decide, and act together across web2/web3 identities and tools. Think Zapier for distributed teams.

You can check out the demo to get a feel for how it worked.

Ize wasn't successful, but it was interesting. Ize took a first principles approach to collective cognition and ended up with a piece of software that is quite unlike anything else. It was purely bottoms-up rather than admin-controlled. It was oriented around process rather than teams. It was framed around embracing complexity and change rather than trying to wish it away.

This post will explore what motivated Ize's design, why it didn't work, and what the next generation of coordination tools can learn from the Ize experiment.

The problem: Fragmented attention

Your experience of being alive consists of nothing other than the sum of everything to which you pay attention. - Oliver Burkeman, Four Thousand Weeks

Modern work is characterized by burnout and dysfunction. This is something we have come to expect, but it is surprising.

Surprising because humans have been working in groups for thousands of years. One might say that the critical factor that has made humanity successful as a species is our ability to work in groups. So what's changed?

There are many answers to this question - Dunbar's number, the fragmentation of a postmodern world, the logic of late-stage capitalism, our inability to string together meaning in the midst of rapid change and intersecting crises.

Though the most decisive factor in the dysfunction of modern organizations is the internet. On one hand, the internet is a boon to collaboration as it gives us the ability to generate and distribute an infinite stream of information across the boundaries of time and space. But this superpower is also the root of our coordination challenges.

The human brain has hard limits on the amount of information it can integrate in a given day. There are only so many messages we can respond to, so many alerts we can handle, so many articles we can read. If you've ever been a member of a Discord Server or Slack channel, you know this firsthand. We alternate between burnout and apathy - at first gritting our teeth against the endless stream of notifications and then giving up and hoping for the best.

There is a profound loss in this state of affairs, both individually and collectively. Our attention is spread thin, breaking our ability to effectively contribute and get the support we need. We are burnt out and bottlenecked, our energy scattered in a flurry of irrelevant notifications.

The ineffectiveness we feel individually translates to ineffectiveness for the collective. Any social challenge you might conceivably care about - whether that's climate change, building new kinds of power structures, or simply deciding which bugs to fix - is bottlenecked by our ability to coordinate effectively.

Focusing collective attention

The core problem of modern work is an attention mismatch: our mental bandwidth is finite, yet the demands on it are practically infinite.

Attention isn’t just a private flicker inside one skull; it’s also the wiring of our collective brain. In the same way a brain thinks by sending electrical signals between neurons, a collective brain thinks via individuals directing attention to each other. Comments on a doc, emoji reactions, quick polls, green-lights for an action, idea bursts in chat - each tiny hand-off routes attention through the collective cortex.

To stay sane—and effective— we need to direct attention with intent. Two qualities matter. First, precision: the right people should be looped in at the right moment. Second, efficiency: contributing a thought or decision should cost as little cognitive effort as possible.

Get those two pieces right and even sprawling groups—start-ups, activist coalitions, whole democracies—can move as one. When it clicks, the group drops into “collective flow,” the state Mihaly Csikszentmihalyi describes as full investment of psychic energy in a goal where skills meet opportunity. The question, then, is how to design our tools and norms so that flow becomes the rule rather than the rare exception.

The center does not hold

The synaptic connections of the collective mind form a highly connected network; the richer the connections, the more “thought” can move at once. The goal isn’t just to share information, but to push as much meaningful information as possible through the network before it clogs.

Though, curiously, the default way that organizations think about directing attention is the top-down hierarchical pyramid: the boss articulates vision, tiers cascade tasks downward, middle managers heroically triage. The org chart itself becomes a bottleneck; every message queues up behind the same overstretched hubs, burning managers out and leaving contributors idle.

Real-world collaboration looks more like a highly connected mesh. Remote work blurs team boundaries, projects spin up cross-functionally, external partners hop in and out. The formal hierarchy mostly persists for accountability, not for the day-to-day flow of attention.

Confusing those two functions—accountability versus attention—starves the network. Cultural norms, approval chains, and implicitly feudal tools all reinforce the pyramid, throttling throughput just when complexity demands the opposite.

Designing for a bottom-up, self-organizing mesh isn’t idealism; it’s descriptive. Attention already routes wherever it must to get work done. Our job is to lay process-rails that make those routes reliable, transparent, and low-friction:

• Process as scaffolding. Clear rituals let anyone request attention, delegate authority, or surface context without waiting for a top-down green-light.

• Dynamic membership. People (and AI agents) can join, leave, or fork a working group as conditions change.

• Instant accountability. Decisions and responsibilities are logged in the open, so trust derives from visibility rather than gatekeeping.

When process plays that role, a team’s collective mind can keep pace with the landscape it inhabits—high throughput without the choke-points.

Bottoms-up process as code

There is rich practice tradition in designing bottoms-up, self-organizing process - Laloux's Teal organizations, Enspiral, Sociocracy 3.0, Holocracy. The trouble is that these approaches come at the cost of time and cognitive load: months of workshops, thick handbooks, a consultant on retainer. The very act of teaching self-management soaks up the attention it was meant to free.

We can see a way out of this dilemma by recognizing that software is exceptional at one thing - process. Code is great at rules and repetition; in theory it can shoulder the ritual work—who needs to weigh in, how proposals move, when a decision locks. While software is the root of our collective attention problem, maybe it could also be the solution.

In the past decade, there have been several notable attempts at software to facilitate self-managing organizations - starting with Loomio in 2011 and then DAOs (decentralized autonomous organizations) more recently.

These tools can be invaluable in certain contexts, but they don't adequately address the core problem of collective coordination - the limits of our attention.

• Coordinating action between tools: Any given coordination tool is going to be used in parallel with a dozen other SaaS applications. These other tools include chat applications, video call software, tools for hosting/deploying code, internal wikis, publishing tools, and expense management. Coordination happens not in any one of these tools individually, but, rather, in the relationships between these tools. If a coordination tool doesn't understand how collective process flows between these tools, we must instead rely on humans to hold these relationships in their head. We're increasing attentional overhead.

• Aligning group membership: Current coordination tools don't have a way of defining how multiple types of online identities can participate together in a single collective process. Collaboration crosses the boundaries of groups, and some groups are defined by a list of emails, others by a Slack channel, and others by an NFT. The lack of attentional pathways for connecting organizations limits how organizations think together. In an increasingly interconnected world, this is a potentially catastrophic technical limitation. As Richard Bartlett, co-founder of Loomio put it: "I spent a decade and a million bucks to conclude the only really critical gap in collective organising software is to synchronise group membership across multiple platforms."

• Rigidity: Coordination tools are often highly rigid in the kinds of collective process they can express. Collective coordination is an infinite design space - it can include sentiment analysis, collaborative storytelling, real-time canvas-based idea exploration, nonviolent communication conflict resolution, etc. But our coordination tools are often structured as simple “propose > discuss > decide” workflows. If a tool can't capture the shape of how people actually want to coordinate, they won't use that tool.

• Poor UX: Contributors fall on a wide spectrum of technical sophistication. If a tool doesn't cater to the bottom quartile of technical sophistication in an organization, it's not going to be effective.

The result of these limitations is that many coordination tools flounder with low participation rates, effectively turning these tools into collective coordination theater. In the absence of tools that can express the true shape of coordination, we resort to the lowest common denominator of coordination tech - email chains, interminable video calls, Google Docs that few read.

Some imagine that AI agents solve our coordination challenges or will allow us to the need for coordination entirely, but this is not true. While AI reduces some coordination costs (e.g. synthesizing information, automating actions), AI also increases the need for systems that structure how AI agents coordinate with humans and other agents.

For a coordination tool to effectively harness collective attention, we need a tool that recognizes the ephemeral, emergent, cross-tool, cross-functional nature of collaboration. We need a tool that connects diverse stakeholders and AI agents into a coherent process. We want tool that is composable, expressive, and meets users where they are.

Enter Ize 👀

Ize directs collective attention to get things done. The name Ize is a play on both eyes (i.e. attention 👀) and the suffix "-ize", meaning the process of getting something done.

The design challenge of Ize was to thread the needle by both acknowledging the intrinsic fragmentation and change of modern work while also respecting our attentional limits. These goals are at tension with each other. We want to enable complex types of coordination while keeping a delightfully simple user experience.

Ize's approach centers around collaborative process, or flows. A flow defines and automates how a group of people (and AI agents) take some kind of collective action together.

You can think of flows as the attentional scaffolding for the collective brain. Flows define how collective attention is requested from the group, how that attention is aggregated into a meaningful result, and how that result leads to an action.

Ize flows are defined by the Ize process language - a declarative, modular language that ties together:

• Participants: A single flow can tie together stakeholders across teams, organizations, online identities (e.g. Slack, Ethereum addresses, Telegram, email etc.) and AI agents.

• Deliberative modes: Users can build, compose, and evolve bespoke collective processes tailored to their local context and goals. This may include decision-making frameworks (majority voting, rank voting, quadratic voting, etc.), AI-assisted dialog facilitation, sentiment analysis, etc.

• 3rd party tools: Flows can automate action in external tools based on deliberative outcomes - disbursing funding, calendar management, pull requests, etc.

This flexibility allows for an infinite creativity in the kinds of collective processes that can be expressed. For example, flows can facilitate how:

• A sub-DAO allocates and disburses budget amongst competing priorities.

• An AI agent gets buy-in from an engineering team before creating tasks in Asana.

• Two start-ups align on the go-to-market strategy of a partnership through an LLM facilitated dialog.

Everything that happens in Ize happens through flows. In most SaaS apps, the organizing principle is the “organization”, a view that embeds rigid hierarchy into our tooling. In Ize, the organizing principle is the flow. Anyone can create a flow about anything. What gives a flow legitimacy and salience is whether others choose to use that flow.

The process to change a flow happens, itself, through collaborative flows. There is no built-in concept of an admin. It’s flows all the way down 🐢. The flow-centric design of Ize recognizes the bottoms-up nature of coordination, while also giving users full flexibility to design coordination and power structures suited to their local context. Some situations call for a direct democracy, others a do-acracy, and yet others a benevolent dictatorship.

Flows dramatically reduce the attentional cost of facilitating complex online process. Flows accomplish this by:

• Defining specifically who can request a group’s attention and specifically who will receive that request.

• Cutting through ambiguity by explicitly defining what information is being requested of a group and how that information will be used.

• Automating the labor intensive process of aggregating and synthesizing perspectives.

• Providing affordances for how action can be taken in an organization that routes around organizational bottlenecks.

• Eliminating the gap between deliberation and execution by automatically executing actions in 3rd party tools.

Flows also cut the attentional load of participating in complex online process. While a flow may be complex, the end user experience of participating is very simple. A participant is presented with some context and a question to answer - a free text response, a vote, or an approval

This simplicity opens up new possibilities for how Ize can be natively integrated into other tools. Users could trigger and participate in flows directly from their preferred chat application (e.g. Slack, Telegram, etc). Ize is designed to meet people where they are rather than forcing them to monitor yet another SaaS app. The vision of Ize is to give users full control over how they want to interact with a collective process. For example, if someone feels most comfortable participating via SMS or a voice note, that should be possible.

Check out this demo to get a feel for how it works.

🪦 RIP Ize

Ize didn't pan out. 1 year and a half dozen iterations, but no traction. A eulogy:

The long tail <> UX dilemma

On a high-level, the collective processes across organizations are very similar. They make decisions, solicit feedback, prioritize amongst options, delegate responsibility, etc.

But the details of how this works vary considerably. For example, organizations have very different needs in terms of how they define group membership, how they want to make decisions, and the tools and chat platforms they would want a tool like Ize to be integrated with. In other words, there's a long tail of needs that significantly affect how useful a tool like Ize can be.

On one level, this is precisely the problem that Ize was designed to solve. As a highly configurable language for defining process, Ize could allow groups to define countless permutations of collaborative processes specifically suited to one’s needs.

Though building for the long tail while also maintaining excellent UX is extraordinarily difficult.

To illustrate the point, consider Ize's Telegram integration

• A core piece of functionality in Ize is surfacing the flows that a user has permission to respond to. If a flow's permission is set to a Telegram group, then we'd like to be able to quickly check which user's a part of that Telegram group so we can allow them to respond to the flow. But Telegram's API doesn't allow you to retrieve the list of user's that are part of a Telegram group. It only allows you to check whether a particular user is part of a particular group. This makes it difficult to have an up-to-date cache of the relevant flows for a given user.

• While an Ize poll is highly configurable (e.g. single select, select X top options, rank top X options), Telegram's native polling feature is more limited. So instead of being able to respond natively within Telegram, Ize would often need to direct the user to respond in the Ize app instead.

• One of the most important collective processes is deciding who should be part of a group. Ideally, we'd like to have a flow where Telegram chat users can approve to add a new member to the Telegram chat. Telegram does not support adding new users via their API.

You can design around these challenges, but keep in mind that every tool you integrate with is going to have its own quirks. It is extremely difficult to maintain consistent, high-quality UX around these idiosyncrasies.

Betting on the wrong horse

I thought the long-tail problem could be tractable if I just started with the right initial user. This is akin to Amazon starting with books before expanding to additional product categories. The idea was that I'd start with a highly motivated user persona, then build up the momentum and funding to tackle the countless edge cases of the long-tail.

The two most highly motivated users for Ize were DAOs, cooperatives, and activist organizations. Each of these groups operate in an environment of deep fragmentation, rapid change, and decentralization. The level of organizational incoherence that these organizations deal with makes them naturally very interested in tools to wrangle that complexity.

I decided to start with DAOs as the early user because they're motivated to solve their own problem, and they often have robust grant programs that fund speculative coordination tools like Ize. At the time, the primary need in DAOs was a way to create more nimble teams, or subDAOs, to solve specific problems. SubDAOs are squarely in Ize's wheel house.

So I lined up a handful of DAO partnerships with initial use cases and started to build. I focused on building features that were suited to the DAO ecosystem - integrating with various blockchains, Hats Protocol, and Telegram.

But by the time an early version of Ize was ready to go, the DAO landscape had changed. The DAOs I had lined up as partners had either folded, severely downsized, or radically changed their priorities. In the crypto ecosystem as a whole, there was a growing sentiment that DAOs don't work. L2s closed off funding for governance research and VCs began to see DAOs as a backwater. The real energy in crypto moved ever more into pure speculation and away from the idealistic experimentation of DAO governance.

By the time I fully came to terms with the changing environment, it was too late. I had been building a user that was now an endangered species. For the DAOs that remained, subDAOs were no longer the pressing problem. They were fighting for survival.

To be clear, I think DAOs can be effective. There are incredible teams like Hats Protocol building tooling that will enable much more flexible and efficient DAOs. But the energy and capital isn’t there right now to support a budding, speculative project like Ize.

I could have done a better job at recognizing this shift earlier and pivoting, though I'm not sure a pivot would be successful. I put feelers out for pivoting to activist networks or tools for democracy, but I was broke and didn't see a way forward for those user segments to pay the bills.

The cynicism around DAOs is part of a broader, deeper cynicism around both technology and democracy. The wave of techno-optimism and low interest rates that fueled the 2010s is long gone. And the belief that coordination tools are important can seem almost naive with the rise of fascism and a perceived scarcity economy. I'd counter that coordination tools are both more important than ever. But maybe I am of a different time - perhaps of the past, perhaps the future.

Trust networks are a different animal

Coordination tools are most often discussed in the context of low-trust networks. That includes DAOs, democracies, social media platforms. In these contexts, you really need code to structure how people who don't know each other can trust the process rather than needing to trust each other.

But I didn't build Ize for low-trust networks. I built it for companies, non-profits, and activist networks.

Trust networks are fundamentally different in that they are built on relationships and accountability. When you have organizations built on accountable relationships, you don't need explicit processes as much. Coordination can be looser with accountability as the backstop if anything goes off the rails.

Trust networks could theoretically benefit greatly from process. As we discussed above, explicit process funnels attention efficiently to make organizations more scalable, sane, and humane. Most trust networks say they want process to wrangle in the chaos of online collaboration. The problem is that process seems to be at odds with the default way most people want to operate. We are relational creatures. We don't want another tool to learn. We want direct relationships with other people, even if that's "not efficient".

Perhaps the way forward is more about culture than it is code. Changing culture is slow and high effort, but it might be the best option we have.

Art projects vs. science projects

The design challenge of Ize was to enable infinitely customizable collective process while maintaining delightfully simple UX, but I wasn't fully successful. The UX of flows was simple considering the configurability and complexity, but it wasn’t simple enough for the median user.

Ize was perhaps an over-ambitious design challenge for a solo-founder with no budget. With enough budget and runway, I think it’s possible that Ize would land on the right form factor. Perhaps Ize would be successful if it had much narrower scope. But answering a narrow question isn’t what I was interested in.

I wanted to explore the ragged edges of this a giant, messy question: Software has severely fragmented our collective attention, but could it also knit it back together? I wanted to take a first-principles approach to this question and build a coherent vision of a new way forward.

There are two kinds of software projects - science projects and art projects. Science projects have a well-defined problem with measurable results like "can we increase the click-through rate on this ad by 5 percent?" Art projects are open-ended explorations of an idea or simply a vague intuition.

Ize was an art project. More like a vision-quest if I'm being honest. As a solo-founder, this quest depleted my personal energy and savings, but it was an immensely rewarding experience nevertheless.

The end result was a novel piece of software - one that is possibly too strange to be commercially successful but hopefully one that can serve as inspiration for future projects.

Speculative futures

With more runway, there’s a few different directions I could have taken Ize.

Relational ambient tech

No, relational ambient tech is not a new micro-genre (yet). Relational ambient is the human-centered approach to coordination in trust networks.

Relational meaning that human relationships are the real fuel of trust networks is relationships. Relationships are slow to build, and culture is slow to change, but relationships and culture are far more durable and flexible than any code you could ever write. Relational tools view human relationships as primary and tooling as secondary. Relational tools foster human connection and support sensemaking that crosses the boundaries of offline and online spaces.

Ambient meaning tech that blends into the background rather than constantly demanding the attention of users. Amber’s case’s Calm Technology is doing excellent work in fostering this type of human-computer interaction. Ize tried to blend into the background by integrating natively into chat applications, but it didn’t go far enough.

What might be effective here is closer to an AI-agent that's akin to the best manager you've ever had but with omniscience and no need to sleep. This agent would operate in the background, determining what is truly worthy of a user’s attention. It would do the heavy lifting of collective attention - aggregating context, synthesizing perspectives, facilitating dialogs, delegating permissions, and making connections between relevant parts of an organization. Instead of another web app to click through or notifications to read, the UX here might be a voice conversation or canvas.

Sensemaking for AI agents

Ize's system of "configurable collective process as code" is probably more relevant for purely AI agents rather than humans. Explicit, machine-readable process would enable agents representing different people, organizations, or interests to define how they work together to achieve a given goal.

This type of system could be used as a proxy or parallel process for human coordination. It could also enable new modes of AI safety by having agents evaluate intent and approve actions for other agents.

Tools for democracy

Democracies, as low-trust networks, urgently need better tools for coordinating sensemaking and action at scale. They need tools that can facilitate multi-step sensemaking processes across organizational boundaries for users of varying technical sophistication. In other words, they need something that rhymes with Ize.

However, the privacy, data sovereignty, identity, and sales challenges of building for governments are immense; The implementation and UX for this kind of tool would need to be considerably different from what Ize. There are teams doing outstanding work here - Polis, Decidim, Jigsaw, CrownShy, among many others.

Conclusion

I’ll probably work on one of these ideas next. But in the meantime, I'm going to rest.

I’ve learned so much from this journey, and I hope you learned something through this postmortem.

Thank you to my friends and family, investors, the Metagov community, Sensemaking Scenius, ETH PDX, RnDAO, Nathan Schneider, Liz Barry, Amber Case, Richard Bartlett, Bijan Khezri, Glenn Poppe, Artem Zhiganov, Max Einhorn, Daniel Friedman, and so many others for your support during this journey.

And if you've made it thus far, thank you for your attention.