Small teams

We structure small teams for our current stage. We are early, highly agile, and intentionally lightweight. We do not adopt team models designed for scale before they are needed.

A team consists of one to four people. Not every initiative requires a formal team. In many cases, progress happens fastest when one or two people work intensely on a clearly defined problem.

This matters because early-stage inference work depends on tight feedback loops. The fewer unnecessary handoffs exist between evidence, reasoning, product decisions, and customer feedback, the faster the system improves.

Each team is accountable for a specific domain, such as product, engineering, inference design, evidence verification, customer workflows, revenue operations, design, or internal systems.

Ownership means understanding the full context of that space, taking initiative without waiting for permission, creating the first iteration, gathering feedback, and improving continuously. Ownership also means being the person or team that protects the health of that space over time.

A lead exists in every team, but leadership at ASUME is about responsibility, not hierarchy. The lead is the person closest to the problem, not necessarily the most senior person in the room.

The lead keeps the learning loop active, ensures clarity, aligns with the rest of ASUME, communicates progress and blockers, and protects the team's focus. The purpose of the lead is not to control the work, but to make sure the work keeps moving with enough context, quality, and accountability.

We do not separate product, engineering, inference, or design from reality. Teams should engage directly with users, customers, evidence, workflows, and the actual situations where ASUME is used.

This is especially important because ASUME is objective-dependent. A workflow that looks correct in theory may fail when used by a revenue team, an agent, or a customer trying to understand why a company matters. Direct contact with users keeps the system connected to real needs and prevents internal assumptions from replacing evidence.

Each team runs a short weekly reflection, typically fifteen to twenty minutes. The focus is on what was learned, what changed, what was shipped or tested, which assumptions were confirmed or rejected, and what the next iteration should be.

The goal is not reporting for its own sake. The goal is to keep the learning loop visible. A team should always know what improved, what remains unclear, and what action will create the next useful piece of evidence.

Owning a space means taking first responsibility for its outcomes.

This includes accuracy in the quality and precision of the work, velocity in how quickly the work iterates and improves, clarity in documentation, decisions, and reasoning, and intelligence in how the system learns from what is built.

For ASUME, ownership also includes evidence discipline. If a team owns an inference, workflow, product surface, or customer output, it must care about the quality of the evidence behind it, the clarity of the assumptions it uses, and the reliability of the output it produces.

Ownership does not mean working alone. It means being the first person or team accountable for making sure the space works, improves, and stays healthy over time.

Even with a small number of people, misalignment can happen. We prevent this through transparency and shared context, not heavy process.

Teams write openly about decisions, designs, inference changes, evidence standards, experiments, and customer learnings. Communication is asynchronous by default so progress does not block on availability. Context is shared so everyone understands what others are building, why it matters, and how it affects the rest of the system.

When work crosses into another space, a short status note is usually enough. We do not rely on formal handoffs or layered processes unless the complexity of the work genuinely requires it.

What keeps teams aligned is clarity, honesty, and a steady rhythm of learning.

At our size, movement between teams happens naturally. As the company evolves, people evolve with it.

People may shift between teams when their strengths are better suited to another space, when a new problem requires a different perspective, when they want to grow in a new direction, or when a project reaches stability and no longer requires the same level of intensity.

These moves are deliberate and purposeful. They are not random, but they are expected as part of a living organization that adapts over time.

ASUME is building a system that learns. The organization must be able to learn as well.