Startup operating systems

A startup operating system is a small set of agreements that keeps work moving: what matters now, who owns recurring work, how issues reach a decision, and when the team checks whether its approach still works. It can live in a shared document and task list. The useful test: can a colleague find an owner, raise a problem and understand what happens next?

Start with the work the business must keep doing

Keep a brief note of recurring work that must continue: delivering to customers, responding to problems, handling payments and keeping essential records. For this overview, name the person responsible for each area. The supporting article on founder responsibility mapping covers the detailed method.

Connect current goals to operating choices

A business plan sets direction, but the team needs a shorter view of what its current goals require. Write down the outcomes that matter over the next planning period and the operating commitments that protect them. If a team aims to improve delivery reliability, for example, it may need someone to check outstanding customer promises and escalate dates at risk.

For each commitment, specify a trigger, owner and visible result. “Watch delivery” is hard to act on. “Check open orders on Tuesday and flag any promised date at risk to the delivery owner” gives the team a usable action. The day and tool are choices for that team, not a standard every startup must follow.

Keep detailed priority selection in planning. The operating system explains how agreed work is carried out and how the team notices when reality differs from the plan.

Agree how work and decisions move

Write a short route for routine work: where a request arrives, who takes it, what approval is needed, and where completion is recorded. Add a stop point for exceptions. A customer request outside an agreed offer, for instance, should reach someone with authority before it becomes a promise.

Distinguish the person moving an issue forward from the person authorised to decide it. They may be the same founder, but the distinction helps when an issue crosses responsibilities. Identify who should contribute information and who needs to hear the outcome. For consequential decisions, keep a brief record of the choice and its effect on current work.

Define what merits immediate contact, what can wait for the next review and which channel to use. An “urgent” label without an owner or a response route gives the team little direction.

Make agreements usable by everyone

Working agreements are shared norms for how a team works, communicates and collaborates. Agree practical expectations, such as where to find current information and when a message needs a response, so people do not infer each other’s habits. The aim is to make collaboration easier, not to prescribe one style for everyone.

Invite the team to suggest changes when an agreement gets in the way. A collaborative document gives everyone a place to contribute and check the agreed version. Atlassian recommends sharing the document and the purpose of the discussion with team members beforehand; revisiting the agreements can also help when new people join or work scenarios change.

Choose a rhythm the work can support

Agree a review rhythm that suits the work and gives the team a chance to share progress, surface blockers and resolve issues that need joint judgement. The right approach depends on the team’s needs and may change when circumstances do.

Keep the information small enough to maintain. A useful review can focus on current commitments, changes, decisions needed and the person responsible for each next action. Record the date and meaning of any measure used. Avoid recreating information already held in a working system merely to fill a report.

Keep the system current

Review the operating map when work changes: a founder delegates a responsibility, a new customer type creates an exception, or a recurring task repeatedly stalls. Ask whether the named owner can still act, whether an approval step is needed and whether an old step can be removed.

Start with a short record of responsibilities, escalation and the review rhythm. Use it on real work, note where people still have to guess, and correct those points. Add detail where it helps someone complete or escalate a task.

Standardise repeatable work

For recurring tasks, document the steps in a form people can find and follow. Checklists, step-by-step guides and templates make routine work more consistent and reduce avoidable mistakes. Keep instructions focused on the task rather than adding process detail nobody needs to complete it.

When a routine changes, update its instructions and tell the people using them where the current version lives. Consistency matters only while the steps remain useful: review them for unnecessary approvals, delays, duplicated data entry or other wasted effort, and remove steps that do not serve the work.

Use evidence to review the system

Choose a small number of measures that help reveal whether a routine is working. Depending on the business and industry, useful measures can include average time to complete a key task, customer satisfaction, or the rate of errors and rework. A faster process is not an improvement if it damages the customer experience or creates more corrections.

Look at measures over time and use them to identify where a routine may need attention, rather than treating a single result as a verdict. Record what each measure means so the team interprets it consistently. Productivity is about turning time, money and staff into goods or services efficiently, not simply asking people to work longer hours.

Measures to Evaluate Your Operating System