OrchStep for engineering managers

The processes a team depends on rarely live in a document. They live in one senior engineer's head: how a new hire gets set up, what has to be true before a release goes out, who has to say yes for production. It works right up until that person is on vacation, or leaves, and you discover the "process" was a person.

You don't fix that with another wiki page nobody reads. You fix it by making the process executable — a thing people run, not a thing they're supposed to remember.

This post writes two of those rituals — onboarding and a release checklist — as a single OrchStep workflow. It's plain commands with structure, no platform, one binary your team already can install.

Two rituals, one file

onboard is the new-hire setup sequence. release-check is the gate that branches on the target: production demands explicit sign-off, everything else proceeds.

name: team-ops
# The repeatable rituals a team lead owns: onboarding + release checklist.
defaults:
  service: payments
  tier: staging

tasks:
  # `orchstep run onboard --var name=jordan`
  onboard:
    steps:
      - name: accounts
        func: shell
        do: echo "requesting accounts for {{ vars.name }}"
      - name: repos
        func: shell
        do: echo "granting {{ vars.name }} read on {{ vars.service }} repos"
      - name: tools
        func: shell
        do: echo "installing the standard toolchain"
      - name: first_task
        func: shell
        do: echo "assigned a good-first-issue to {{ vars.name }}"

  # `orchstep run release-check --var tier=production`
  release-check:
    steps:
      - name: tests_green
        func: shell
        do: echo "CI green on main"
      - name: changelog
        func: shell
        do: echo "CHANGELOG updated"
      - name: signoff
        if: '{{ eq vars.tier "production" }}'
        then:
          - name: require_approval
            func: shell
            do: echo "production tier - explicit sign-off required"
        else:
          - name: auto
            func: shell
            do: echo "{{ vars.tier }} - proceeding without manual sign-off"
      - name: done
        func: shell
        do: echo "release checklist complete for {{ vars.tier }}"

The release checklist's if:/then:/else: is the part that matters to you. The policy — "production needs a human; staging doesn't" — is written in the workflow, not enforced by hoping someone remembers it in the moment.

The move that makes it real: dry-run as a review artifact

You don't have to run anything to see what a process does. A dry-run resolves the variables, evaluates the branch, and prints the plan:

orchstep run release-check --var tier=production --dry-run

You can see that the production path requires sign-off before anything ships. That output is reviewable in a PR, pasteable into a runbook, and unambiguous in a way a wiki paragraph never is. When the policy changes, the diff is the change.

Onboarding becomes a one-liner anyone on the team can run:

orchstep run onboard --var name=jordan

And when a new lead asks "what processes do we even have?", the answer is a command, not a person:

orchstep menu

What you gained

This isn't a project-management tool and it won't run your standups. What it does is take the operational rituals your team already performs and make them durable — versioned, runnable, and the same whether the person who wrote them is in the room or not. If your team is two people and everyone knows everything, you may not need it yet. The week you hire the third, you will.

Where to go next

• Branching — if/then/elif/else for policy in the workflow
• Variables & Outputs — the scoping model and --var
• Previewing with Dry Run — the reviewable plan
• The Web Dashboard — orchstep serve if you want a clickable view for the team

Pick the one ritual your team most often gets wrong, write it down as a task, and make "run the process" a command anyone can type.