Independent Collaborators
Derek Rosenzweig · Runtime Labs · August 4, 2026
Self-Supervised Work
The future of work is self-supervised.
I hear this in the echoing voice of Yann LeCun while reflecting on the qualities I respect most in the people I work with.
Writing job descriptions forced me to confront a deeper set of questions:
- What kind of people do I want to build this company around?
- What kind of environment will allow them to thrive?
- What is my responsibility for creating the trust, shared context, and structure that allow independent people to work cohesively as a team?
The answer to all three begins with the independent collaborator: someone who forms judgments independently while making their thinking and learning available to others.
The initials are familiar. In most organizations, IC means individual contributor—someone whose primary responsibility is doing the work rather than managing others. But the conventional term says little about how that person thinks, acts, or participates in a team.
An independent collaborator adds two explicit expectations.
Independent means capable of making decisions, identifying useful work, and taking responsibility without waiting for every step to be prescribed.
Collaborator means making that judgment legible to others: sharing context, inviting disagreement, coordinating around dependencies, and returning local learning to the wider group.
The pairing matters. Independence without collaboration becomes isolation. Collaboration without independence becomes dependence on consensus. The goal is to preserve individual judgment while making it useful and responsive to the wider team.
The Company as a Launchpad
This is partly a theory of organizational design and partly a reflection of how I want to work, and who I hope to work with.
My responsibility is to create the conditions in which we can do meaningful work and grow into opportunities larger than the roles we initially joined.
I am focusing on the earliest stage of team formation because that is where we are today: roles are fluid, information travels directly, and a small team must navigate broad, open-ended problems. These principles may endure as the company grows, even as the structures supporting them evolve.
The work itself has no fixed destination. As model capabilities expand, new technical possibilities, product surfaces, and forms of interaction will emerge that we cannot fully anticipate today.
Building around independent collaborators means giving the team meaningful authority over decisions and responsibility for their consequences. Early team members will become more capable of articulating their vision, exercising judgment, leading others, and building systems of their own.
Some will eventually create new teams, products, or organizations within or beyond the company. That will not be understood as a failure in retention, but as evidence that the environment expanded their agency and capabilities.
The strongest companies become launchpads for future founders, leaders, and collaborators. That is the kind of company I hope to build.
From Labels to Feedback
The connection between self-supervised learning and organizational design begins with reducing our reliance on labels.
In supervised learning, a system is trained against answers supplied in advance. In self-supervised learning, the system derives a learning signal from relationships embedded within the data itself. It still has an objective and constraints, but it does not require a person to label every example.
Explicit instructions can provide useful stability, like cognitive training wheels, especially when we are new to a problem. But when every action is prescribed, we have little opportunity to develop the judgment required to move independently.
Collaboration provides a different form of support. Independent collaborators are both students and teachers within the organization. They learn openly from the judgment, experience, and evidence around them while making their own reasoning and discoveries available to others.
To be a better teacher, become a student.
To be a better student, become a teacher.
These are qualities I look for in the initial team: continual learning paired with visible demonstration. The goal is not simply to accumulate individual expertise, but to create an environment in which each person's learning expands the capabilities of the group.
Given a shared mission, access to context, and responsibility for outcomes, we learn from customer behavior, product usage, technical constraints, disagreement, and the consequences of shipped work.
Rather than waiting for each action to be assigned, we develop an internal model of the organization and use it to determine what should happen next.
The analogy fits because both forms of learning reduce dependence on prescribed labels and shift our reliance toward structured feedback from the environment.
Give capable people the authority to test their judgment against reality, and they may discover directions that no planning process could have prescribed in advance.
Lessons From Building Óra
I practiced this posture while building Óra over the past year. The work began with structuring events, conversations, notes, photos, links, and locations into a persistent personal timeline—unglamorous infrastructure in service of memory and planning. Staying close to that system did more than advance a roadmap. It changed what I could see.
As the timeline grew denser, relationships in the event data suggested directions I had not specified in advance: collections that organize context across time, shared timelines that let people contribute to common histories. Those possibilities emerged from sustained engagement with the underlying model, not from a feature brief written at the start. A narrowly defined assignment might have produced the next interface. Proximity to the substrate revealed a broader product surface.
That is the organizational lesson I want to protect as the team forms. People discover possibilities beyond the roadmap when they have direct access to the underlying work, authority to follow what they find, and rapid feedback from reality. My responsibility is to provide those conditions—without becoming the approval layer through which every useful decision must pass.
Building Around Independent Collaborators
Recognizing Independent Collaborators
Independent collaborators are easiest to recognize by how they respond when the problems are open-ended.
They tend to:
- ask questions that improve the definition of the problem;
- form a point of view without pretending certainty;
- notice useful work beyond the literal assignment;
- take responsibility for outcomes, not only deliverables;
- update quickly when evidence contradicts them.
The defining quality is not certainty. It is the ability to generate useful direction under uncertainty and to remain open to correction.
Supporting Independent Collaborators
Autonomy is not the absence of structure. It depends on leading with:
- a clear mission;
- explicit boundaries and decision rights;
- direct access to customers, data, and technical reality;
- clear evaluations anchored to outcomes;
- fast feedback on consequential decisions;
- protection from unnecessary approval chains;
- permission to challenge the framing of an assignment.
The organization should be precise about objectives and constraints while remaining flexible about the path.
Connecting Independent Collaborators
Independent collaborators do not need continuous coordination and meetings.
The working rhythm I want is long periods of focused execution, interrupted by short, prepared moments of synchronization.
Coordination should occur through clear interfaces:
- written records that preserve consequential decisions and learning;
- short demonstrations of real work in progress;
- direct communication across functions;
- shared definitions of priorities, quality, and completion;
- explicit signals when a decision changes assumptions or creates dependencies.
Together, these interfaces form the organization's interconnect. Their purpose is not maximum communication, but reliable transmission of context.
A meeting should update the shared understanding, resolve a dependency, or produce a decision. Otherwise, the work is usually better done independently.
Strong collaborators know what can remain internal and what must be shared. Keep execution local when possible, but share consequential learning across the organization.
My Commitment
This is not a description of a culture I have already implemented or perfected. It is a commitment to the kind of company I want to build and the responsibility I am accepting as the team begins to grow.
I want to work with people who form their own judgment, make that judgment legible to others, and direct their energy toward strengthening both the product and the people around them.
My role is to provide a clear mission, direct access to reality, explicit priorities, and clear boundaries for decision-making. It is also to build strong connections across the team and create enough breathing room to discover what none of us could have specified in advance.
The goal is to protect independent judgment while creating the conditions to strengthen a cohesive team.