How do you set up a working process for a brand-new team?

Question

Accepted Answer

Start **light and explicit**, then let the team evolve the process from real pain points. The biggest mistake is importing a heavy framework from your last job on day one. A new team needs a few non-negotiable basics, shared agreements, and a fast feedback loop to adjust.

## The minimum viable process

- **Definition of Done** and **Definition of Ready** — so "done" and "ready to start" mean the same thing to everyone.
- A single **source of truth** for work (one board), and a clear intake path so work doesn't arrive through five side channels.
- A **branching and code-review** standard, plus a basic CI pipeline. Quality gates exist from day one, not bolted on later.
- Lightweight **ceremonies**: a short daily sync, a planning cadence, and most importantly a **retrospective** — the engine that improves everything else.

## How I roll it out

1. **Listen first.** Talk to each person; learn their context, strengths, and frustrations before imposing anything.
2. **Co-write a working agreement.** Hours of overlap, how decisions get made, on-call expectations, communication norms. Ownership comes from co-authorship.
3. **Ship something small end-to-end fast.** Nothing builds a process like running it once on a real task and finding the gaps.
4. **Run retros and adjust.** Treat the process itself as a product with a backlog.

## Trade-offs and pitfalls

- **Too much process** kills momentum and signals distrust; **too little** creates chaos and rework. Err on the light side and add only when a real problem demands it.
- Don't confuse **tools with process** — Jira is not a methodology.
- Beware **process by decree**. If the team didn't help shape it, they'll route around it.
- Establish **psychological safety** early; a retro where no one speaks honestly is theater.

## A simple template

- We work in [cadence]. Done means [DoD]. We review every PR within [X hours]. We decide via [DACI/owner]. We retro every [interval].

## Why it matters

A team's process is the operating system everything else runs on. Set it up well and good engineers compound; set it up badly and you spend every sprint fighting friction, ambiguity, and rework. Doing this deliberately — light, explicit, and co-owned — is one of the clearest signals of senior leadership.