Language and Method
The most novel outputs that Cosmos produced are a language to facilitate collaboration and an abstract method for solving problems. The Method and Language are tools that emerged organically as Cosmos developed — they were born out of the necessity to operate and scale a technical services business. They were nurtured by a discipline in engineering, a passion for designing systems, and a curiosity to understand the world around us.
The Language and Method have both had a significant impact on the people that were exposed to them. Former Cosmonauts report that the tools have changed the way they think about work and organization — the Language and Method have permeated their thinking and they continue to apply them in both their personal and professional lives. We incubated several companies and taught the Language and Method to the initial staff. Years later, the companies continue to apply these principles while evolving them to suit their needs.
These tools are powerful because they are precise, they are portable, and they are extendable. A team that has a shared understanding of the Language and Method can easily collaborate because their understanding of work can be unambiguously communicated, and this communication can take place over many mediums like voice, documents, and through project management tools. Furthermore, the Language and Method can easily adapt to a team’s domain-specific needs by incorporating new terms and concepts.
In the sections below you can learn more about the Language and the Method. It is documented here in a static form, but it comes alive when it’s wielded by a team of people who believe in its value. We are immensely proud of this work!
As a remote-first company operating across multiple time zones, Cosmos needed a way to facilitate collaboration both synchronously (working together on a call) and asynchronously (working independently and sharing work with others). We considered using project management tools to organize our work, but felt that they lacked expressiveness and—crucially—the ability for real-time collaboration. So, we chose to collaborate using Google Docs.
We created a Google Doc for every single call within Cosmos, giving us a shared place to collaborate in real time. When we performed asynchronous work we also created a Google Doc, then shared that work with collaborators. As time went on a language began to take shape within our documents. Instead of being formless walls of text we saw that structures and formats emerged, as well as conventions for expressing content.
Due to our backgrounds in computer science and software engineering, we care deeply about things like naming, clear and consistent organization, the single-responsibility principle, and refactoring systems to meet evolving needs. So the language may have emerged organically, but we refined it with a great deal of intention.
This led to a dynamic, shared, and ever-evolving language that enabled us to collaborate with very little friction. When working asynchronously Cosmonauts could expect to receive a document with familiar formatting and clear expectations for how they could contribute. Similarly, reviews were expressed in a way that was familiar to colleagues. It was supercharged when working synchronously—we had teams of people working in the same document at the same time, forming ideas, integrating thoughts, transforming them into new ideas, and accomplishing our shared goals.
The language is what tied us together as a team. We all read, wrote and spoke it. But most importantly, we were all invested in its continued evolution and improvement.
The following terms define the core of the language:
Something that exists and that a System can interact with.
A Resource that is a Collection of Related Resources. A Resource can exist in multiple Systems simultaneously.
A useful term for the System that encompasses the Resources under consideration.
- Example | A Kitchen is an Environment in which Actions like Cook Dinner and Wash Dishes are performed, but it can also be considered as a Room within the House, and in that sense it’s considered as a System
- Example | A Refrigerator is an Environment in which Resources like Food, and Water are stored. But it is also a Resource of the Cooking system, and a Resource within the Kitchen’s Environment.
A Resource that performs Actions.
The type of Interaction
An Action performed by an Actor that produces a Collection of Effects.
States of Interactions
Interactions can exist in the following states. The state can be concisely expressed using the relevant emoji.
- ➡️ Not Started — The work has not been started.
- 🔄 Started — The work has been started.
- ⏸️ Paused — The work has been stopped but is expected to resume.
- ✅ Completed — The work has been completed and is not expected to be resumed.
- ❌ Discarded — The work is not completed, has been stopped, and is not expected to be resumed.
If an interaction is written without an emoji prefix then it is implicitly assumed to be in the Completed state.
A change to a Resource.
Cosmos did a lot of work on certification systems, so we’ll use one as an example to demonstrate these concepts. Imagine that you own a bicycle, but it hasn’t been used in a few years so you’re not sure if it’s safe to ride. You want to get confidence that it is safe, so you’ll get the bicycle’s safety certified by an expert bicycle mechanic.
It all starts with you, an Actor, deciding to perform an Action. You, the bicycle owner, want to determine that the bicycle is safe to ride. We write this as follows:
Bicycle Owner: Determine that Bicycle is Safe to Ride
You take your bicycle to a bicycle shop to contact their services. Specifically:
Bicycle Mechanic: Certify Safety of Bicycle
The Bicycle Mechanic will start by asking you questions about how you’ll use the bicycle. Will you be riding on paved roads, gravel roads, in the mountains, or some combination? Will you be carrying loads, like groceries or children? Will you be riding at night? These questions help define the Environment that you’ll be using the bicycle within.
Using a bicycle in the mountains is a very different Environment from using it in the city to go grocery shopping. In the context of the Cosmos Language, we’re looking at two different Systems in which the bicycle is used. Here are some examples to show the different Actions in each:
⛰️ Mountain Bicycling
- Navigate Banked Turn
- Jump over Log
- Mount Bicycle to Car
🏘️ City Bicycling
- Navigate Turn across Traffic
- Brake for Stop Sign
- Lock Bicycle on Rack
A System is something that organizes a bunch of related concepts. As seen in the mountain versus city example, those concepts can be Actions. But they can also be things like the pedals, the brakes, the wheels, or the handlebars. The general term that we use for any thing or concept is Resource. A bicycle is a Resource, and so are its wheels, its tires, and everything else on it. And, so are the Actions associated with it.
The difference between an Environment and a System is just one of perspective. When you’re thinking about the different ways in which you can use your bike, you’re thinking about Systems like Mountain Bicycling and City Bicycling. Then, when you move your perspective into the City Bicycling System, you now find yourself within that Environment. In the context of City Bicycling, you’re considering things like cars, stop signs, and bike lanes. In a sense, you’re inside the System.
But let’s get back to the Bicycle Mechanic and finish this safety certification. They take a look at each System in the bicycle and evaluate it for its safety—the Braking System, the Suspension System, the Cargo System. Again, these are just organizations of related concepts. The Braking System includes the brake levers, the cables, and the calipers that rub against the wheel to create the stopping friction. And it’s Systems all the way down—they’ll look at the Cable System to ensure they’re correctly installed, free of wear, and properly calibrated.
After their inspection, the Bicycle Mechanic comes to a series of conclusions about the safety of the bicycle. Thus, an Interaction has occurred—the mechanic has finished performing the Action of Certify Safety of Bicycle and has produced a collection of Effects based on what they’ve found. Whereas the Action is abstract (the mechanic could certify the safety of many bicycles in a day), the Interaction is very specific (it’s about the mechanic certifying the safety of your bicycle). The Effects of the Interaction are specific to the Interaction. Here’s the outcome for this case:
Bicycle Mechanic: Certify Safety of Bicycle
- Effect | The bicycle is safe to ride in the city
- Effect | The bicycle is not safe to ride in the mountains
To further illustrate Interactions and Effects, let’s imagine you contract the mechanic to make it suitable for the mountains:
Bicycle Mechanic: Configure Bicycle for Mountain Bicycling
- Effect | The brakes are capable of stopping the bicycle on steep descents
- Effect | The suspension can handle short drops
- Effect | The handlebars enable precise maneuverability
These concepts of Resource, System, Environment, Actor, Action, Interaction, and Effect can be used to describe anything. We have found them to be a powerful tool for designing and defining systems that we use in our personal and professional lives. We hope that they’ll be useful for you as well!
Cosmos’s primary business was to integrate into companies, perform research to understand how they operate and what problems they’re experiencing, then design, develop, and deliver software that enabled them to achieve their goals. Being software engineers, we were very thoughtful and intentional about precisely how we performed this work.
As Cosmos matured, various activities forced the evolution and refinement of our method. One example is performance reviews—when reviewing the performance of the first staff member in a particular role (e.g. Product Manager), we broke down the role into its component workflows and gave feedback and growth suggestions for each. This gave us an immensely valuable structure for considering the work we performed.
Over time, abstract workflows emerged for solving problems and performing work. One was the Plan and Execute workflow, which considered work in the highest-level categories of either planning our next steps or executing those next steps. Another was Research, Define, Design, Develop, Deliver, Measure, which was more focused on understanding problems and then integrating solutions to solve them.
In short, the Cosmos Method encompasses a variety of abstract and concrete workflows to perform work and solve problems. And it is imbued with the philosophy of always seeking to improve and refine the processes we use to do work.
Cosmos used many terms in its everyday usage of the Method. These terms don’t (yet) include definitions, so we recommend you read the usage section to reach a better understanding of how these terms are used in practice.
We organized these terms into 6 categories:
- Planning — Systems for agreeing on a scope’s goals, defining work to achieve those goals, and managing the performance of that work over time.
- Discussion — Systems that facilitate the exchange of information between actors.
- Decision Making — Systems for agreeing upon a course of action.
- Work — Systems that enable actors to perform activities and organize the resources related to activities.
- Collaboration — Systems that improve the working relationships between actors while prioritizing the growth and well-being of those actors.
- General — A collection of abstract concepts that can be used throughout the Method.
- Next Steps
- Work Horizon
We defined the following Work Types within this category:
- Tentative Decision
- Scope of Work
We identified the following Phases in this category:
We defined the following Work Types within this category:
- Statement of Work
- Test Plan
- Delivery Plan
- Rollback Plan
- Performance Review
It helps to look at practical examples when seeking to understand these terms. To that end, we wrote out the following usages of the Method:
Exploration is at the heart of the Cosmos Method because it’s the first step you take when you need to learn more about a given subject. Not sure what work to do next? Perform an exploration to get a clear view of the state of the project and understand the different ways you can go. Not sure what choice to make across a set of actions? Perform an exploration to explore each approach and weigh them against one another.
Explorations are an abstract concept that are useful at every level of work, from big picture strategy down to specific tactical choices.
Explorations can be big or small, but regardless of size they all have attributes in common.
Every exploration begins with a Background that sets the context for the content to follow. The act of writing a background is invaluable because it immerses the writer into the problem space that they’re exploring. What’s important to know, and why? What similar work has been done, and how is it related? How does this relate to work that can come next? Capturing these ideas in writing helps ensure that the scope of the work is understood and that the necessary information is all gathered in one place. And, a background is incredibly useful when someone else comes in to review the work (including the person who did the work coming back in the future!).
The next part to define are Goals, Considerations, and Constraints. Goals are outcomes that you hope to achieve after completing the exploration. Considerations are things that are worth noting because they could affect how we think about solutions. And Constraints are like considerations but stronger — they are statements that must be satisfied.
The work itself is then integrated into a Notes section, which is freeform and can contain whatever is useful for the writer. This is their scratchpad to explore ideas, record notes, and start to structure their understanding. This section often includes Approaches, each of which outlines a way to advance the work. An approach can have Pros and Cons associated with it, as well as Positions that one or more actors share.
Explorations are typically completed by writing a Summary of the outcome. This is a structured section that communicates the learnings from the exploration. It should structure the content in a way that makes it easy to read and understand. Ideally, it should communicate decisions about actions, or proposals about which actions should be taken. These actions are defined as Next Steps to be taken.
At the highest level, all work is done within a Plan and Execute cycle. You plan the work that you intend to do, then execute that work. Cosmos operated on weekly planning cycles, which means that each week we planned the work for the following week, then execute upon that plan. This process is very effective for small teams (2 to 6 people) because it provides a weekly opportunity to reflect on the current state of the project, align on clear short-term goals, then allocate work to achieve those goals.
The workflow Plan Scope describes the work done to create a plan for a specific scope of work. It revolves around a Plan, which is a single, persistent document that serves as the center of all work done on that scope. Within a planning cycle, any actor can refer to the plan to see what their responsibilities are, as well as the responsibilities of others. It also serves as a repository for resources related to that scope like workflows, role assignments, decisions, and notable discussions.
Here is the workflow to Plan Scope:
Step | Prepare Plan
The manager of the scope works independently to prepare the plan document for review. Their goal is to get the plan to a state where the team can come in, review it, and agree on the next week’s plan. This is accomplished through the following steps:
- Step | Summarize State of Scope
- This is effectively a Background about the scope. It communicates its current state, things that can or will affect it, and anything else that is notable. This section is critical for ensuring that you know where you are now so that you can plot a realistic path about where to go next.
- Step | Set Goals
- The intention is to achieve each Goal prior to the next plan. In other words, the goals describe the planned future state of the project by the time the next plan is being prepared.
- Step | Create Topics and Highlights
- During the planning session the team will discuss Topics and Highlights as a group. Highlights are used to communicate information that does not necessarily require discussion, like to note an accomplishment, upcoming deadline, or consideration. Topics are used to prompt discussion about actions to take. They are written in a highly actionable form so that the team’s time together is used efficiently. They are often in the form of Proposals that propose an action, Questions that seek information or guidance, or Requests that prompt specific action.
- Step | Draft Priorities
- A goal of planning is to allocate discrete work to team members that they should achieve before the next planning session. When planning a scope, the manager typically doesn’t have all the required information to decide what all that work is — they often need insight from the team about how long certain tasks will take, or they might not have technical knowledge about what work should be done when. So, they create draft Priorities that reflect their understanding. These priorities are specific tasks that work toward the stated goals.
Step | Review Plan
The next step is for the team to review the plan. Team members read through the plan and integrate thoughts as they go. They might integrate a Question about a Proposal that they don’t understand, or might even add an alternative Approach that could be considered instead. They might integrate a Position to state their view about a topic, or a +1 to indicate that they share a stated position. They also might integrate a +1 to show their support for an approach.
After this asynchronous review is complete the team comes together to do the following:
- Step | Discuss Topics
- The manager of the scope conducts the discussions to ensure that the team’s time is being used effectively. The goal is to reach decisions and actions. Often, this can mean creating Next Steps to allocate to advance a scope because it’s more efficient to have one or two people continue the work than to absorb the entire team’s time.
- Step | Prioritize Work
- After all of the topics have been discussed, the emergent work is integrated into the draft Priorities and the team collaborates to set the overall priority of each Next Step. This priority is created without considering what work the team thinks they can achieve before the next planning session.
- Step | Allocate Work
- With the Priorities set, it’s then time to allocate work to actors with the expectation that they will complete it prior to the next planning session. If an actor exhausts all of their allocated work, then they can refer to the priorities to see what to do next.
Step | Commit Plan
Now that the priorities are set and work has been allocated, the plan can be finalized. This is done by integrating updates into various resources that reflect the state of the project.
The Priorities clearly communicate the responsibilities of each actor during the next planning cycle, as well as the work that they can perform next in the event that they complete all of their allocated tasks.
The Timeline shows work that has been allocated to a specific planning period. When looking into the past, the timeline shows the status of work—it shows the work that was actually done (including new work that emerged) as well as work that was planned but not completed. When looking at the present, the timeline shows the work in the current planning period. The timeline is typically not populated for future planning periods, but it’s possible that it could be if there is a high degree of confidence in when work will be completed and a high degree of understanding about what work comes next.
The Work Horizon is a slice of the timeline that shows the previous planning period and the current planning period. It’s a useful tool to see the scope’s recent history at a glance. It’s especially useful in planning because it indicates what work was planned but not completed in the previous planning period, and how any potential emergent work could have impacted that.
The Roadmap reflects a prioritized sequence of scopes that the team intends to work on over the upcoming planning cycles. It’s very accurate in the short term (e.g. in the next planning cycle) and gets a little fuzzier in the medium and long term. The roadmap answers the question of “What work do we plan to do next?” across short, medium, and long-term horizons.
Any work, no matter its size or shape, requires a starting point. Most of Cosmos’s work aimed to solve business and industry problems for clients and partners. Those problems ranged from answering questions, understanding industries, reducing friction in business processes, designing new businesses, and implementing or inventing technology.
The solution to any problem is a function of its problem definition. Discovery is a methodology for researching and defining problems, then creating a Roadmap to solve them.
Here is the workflow to Perform Discovery:
Step | Research
The first step is to understand the problem space. This means collaborating with subject matter experts to understand the areas that need exploring: industry news, publications, business processes, technology systems, and any other related resources. It also means interviewing the various actors that are involved in the problem space or have expertise on the problem spaces.
The result is a Synthesis that summarizes the problem space, the central challenges, and the current state of the problem space. It describes the Actors in the space, the Roles they perform, and the Workflows executed in those performances. It also considers any other essential Resources.
Step | Identify Goals
Goals are the measurable outcomes expected to result from a given solution. In aggregate, they measure aspects of the desired future state of the problem space after any given solution is implemented. Goals enable the exploration of Approaches to solve the problem.
Step | Scope Work
With the current state of the problem defined (Synthesis) and the desired future state of the problem defined (Goals) all that remains is defining the work to achieve them. A Roadmap is a prioritized list of Scopes of Work that upon completion will achieve the measures defined by the goals.
Roadmaps may range in their scope and level: from performing additional research to producing prototypes, and from designing and implementing new systems to executing brand new business strategies.
The term “Work” has different meanings depending on its form of speech, like verb or noun. In its verb form it is an action to carry out, like Paint Canvas or Shovel Driveway. In its noun form it is the output of an activity, like Painting (“Work of Art”) or Cleared Driveway.
The success and efficiency of any work is a function of how well it is scoped. Before work can begin, it must have a Scope. Scope is a description of the work in terms it can be understood and executed. Scope involves the naming of work, the hierarchy of the work, and how its related outputs and activities are encoded within it. We define Scopes of Work as work that is structured with these considerations.
The efficiency and success of the execution of a Scope of Work are a function of its structure and its relationship to the Goals that the work aims to achieve. Cosmos placed a great deal of effort on optimally structuring Scopes of Work.
Goals may be implicit or explicit. For example, Shovel Driveway may have an implicit goal of minimizing the time spent shoveling while in pursuit of the explicit goal of creating a Cleared Driveway.
Scoping is the process of evaluating a set of Goals, defining Actions to achieve those goals, then naming, structuring, and sequencing the actions so that they can be executed. It is an iterative process of refinement that often generates a hierarchy of actions. The depth of this hierarchy is determined by the problem space and goals of the work.
Example Scope | Assemble Desk
We want to assemble a desk, and in doing so we have the following Goals:
- Goal | Desk is assembled
- Goal | Cleanup time is minimized
- Goal | Assembly time is minimized
Let’s define a scope to achieve those goals:
- Assemble Desk
- Open Packaging
- Read Instructions
- Validate All Tools Exist
- Read Tool Requirements
- Locate Required Tools
- Validate All Parts Exist
- Read Parts Manifest
- Locate Parts in Manifest
- Prepare to Assemble Desk
- Gather Required Tools
- Gather Required Parts
- Prepare Assembly Area
- Assemble Desk
- Follow Instructions
- Place Packaging to Discard in Designated Location
- Dispose of Packaging
In this scope we have several scopes defined in pursuit of our goals. The goal of Assembly time is minimized is supported by the scope to Validate All Parts Exist and to Validate All Tools Exist before starting assembly. The goal of Cleanup time is minimized is supported by the scope to Place Packaging to Discard in Designated Location.
Example Scope | Set Up New Office
Scopes may have deeper hierarchies as the range in breadth or complexity. What if our previous example were part of a broader scope? The following scope does not included all tiers or branches in the hierarchy, but aims to show how simple scopes comprise and form them:
- There is a place to sit and work
- There is a place for guests to sit and visit
- The space feels personal
- The space is inspiring
- Create Work Area
- Create Desk
- Choose Desk
- Purchase Desk
- Assemble Desk
- Create Seat
- Choose Seat
- Purchase Seat
- Assemble Seat
- Put Up Wall Art
- Choose Art
- Purchase Art
- Install Art
- Set Up Guest Area
In this broader scope, we see how the previous scope to Assemble Desk is just part of a broader scope to Create Work Area, and even then is part of a larger scope to Set Up New Office.