Processes: A Living Rhythm with Formal Points

The final track of the "How to bring order to a project" series — processes. It came last not because it matters least, but because it leans on everything before it: without observability, status updates degrade into retelling feelings — you can only say "we're fine" while looking at metrics; without reliable deployment, a regular release cadence simply won't happen — every rollout stays manual work everyone wants to postpone.

And straight to the main prejudice. Process is not a boring, faceless instrument of corporate management. A living process changes — it adapts to the team, drops what's useless, grows what's needed: that's how it should be. But for all its liveliness, it defines formal points and artifacts: the task is filed, the decision is written down, the status is spoken out loud. These points pin the work down and keep it from getting lost.

Yes, in the moment it's faster to DM someone than to file a ticket. But the DM is only faster today: a month later that agreement exists nowhere — not in the plan, not in the history, not in the other person's head. A formal point feels like a detour, but over the distance it shortens the path to a delivered result. That's the whole bet: a good process is not more paperwork — it's fewer decisions on the fly and less lost work.

The task lifecycle: one explicit path

Every task in a team should travel one route everyone knows. Ours looked like this:

Discussion
    ↓
Architecture discussion (when the task calls for it)
    ↓
Decision on paper — an RFC or ADR
    ↓
Decision review
    ↓
Planning in the tracker
    ↓
Development: code → merge request → review → deploy
    ↓
Watching production
    ↓
Documentation update

Looks like bureaucracy — in reality, for a small team most steps take minutes: an "architecture discussion" is five minutes at a whiteboard, a "decision on paper" is half a page. And "development" is a single step even though it contains code, MR, review and deploy: once the infrastructure track is done, that's one well-worn conveyor, not four separate events.

The point of the ladder isn't meetings — it's this: no step gets skipped silently. You may consciously decide "no RFC needed here" — you may not fail to notice that a decision was never written down. Two rules from practice:

• major architecture changes never skip the RFC step — ever;
• work is not done until the documentation is updated. Not "I'll write it later" — not done.

Planning: sprints or kanban is the wrong question

The right question is: what's the nature of your work?

• Building a feature with a deadline you can plan out — take sprints: a fixed window, a clear scope, and at the end you can see whether you hit it.
• Handling a flow of tasks — support, testing, bugfixes, small improvements — take kanban: tasks stream through columns, throughput matters, not "did we make it by Friday."

Both live peacefully in one team: feature work in sprints, the flow on a kanban board. It's all individual; the tool serves the work, not the other way around. Only two things are universal: a short cycle (a week or two — beyond that plans lie) and a visible backlog — anyone on the team can open it and see what's next.

Status updates and dailies: not optional

The most underrated part of process — and the one where I hold my firmest position: status updates are mandatory, always. Even if the team is two people. Even as plain text in chat. Always.

Without regular sync the same thing happens every time — I've watched it more than once: people don't know about each other's problems, don't know whom to go to, quietly stall for weeks — and everything falls apart. Not because anyone works badly, but because nobody sees the whole picture.

The working mechanics:

• A status — always. Short and regular: what I did, what's next, what's blocking me. For a two-person team three lines of text are enough — but every day.
• The daily is for discussion, not for reporting to the boss: you hear about a neighbor's problem — you say "I've had something similar, come over."
• Problems get solved after, in the right circle. Something half-hour-sized surfaces on the daily — we don't solve it with everyone: we note it, and after the call exactly the two or three people who need it gather. The daily stays short; the problem gets a real deep-dive.

It's the cheapest process of all — ten minutes a day — with the highest return: it's the only one that keeps a finger on the pulse.

Release cadence: predictable and boring

This section is suspiciously short — because releases are a science of their own: windows, frequency, staging, rollbacks, the fear of Friday deploys. It deserves — and will get — a separate article.

For this track one principle is enough: a release should be boring. A clear scheme (mine: candidate tag → staging, release tag → production), identical for every service, with a notification in the channel. If the team's pulse rises before a release, that's not a cadence — it's an arrhythmia, and you fix it in the infrastructure track, not with courage.

Incidents: blameless reviews

When production goes down — and it goes down for everyone — process beats heroism. The minimal skeleton:

• pin the timeline: when it started, what coincided (most often — a deploy);
• fix first, analyze after — not the other way around;
• a review with no blame and one action item: not "we'll be more careful," but a concrete change — an alert, a CI check, a checklist line;
• the postmortem goes into a registry; before the next review, first search the history for a similar case.

How to set this up in a small team with one or two people — the minimal artifacts and where to grow from there — will also become a separate article, with a real incident walkthrough.

The meeting audit

The final step of the track is the most enjoyable: open the calendar and honestly answer, for every recurring meeting, what it produces. The rule is simple: a meeting either produces decisions, or syncs people, or dies. "It's historical" is not a third option — it's a diagnosis from the architecture track.

What survives the audit almost always: the daily (it syncs — see above) and incident reviews (they produce decisions). What dies first: the weekly hour-long "all-hands sync" where everyone waits for their minute and stays silent for the other fifty-nine.

The series is complete

With this article, the "How to bring order to a project" map is closed — all six tracks now have their articles:

⬜ → ✅ The state snapshot — a week of fixing nothing

⬜ → ✅ Observability — turn on the lights

⬜ → ✅ Infrastructure and deployment — order by iteration

⬜ → ✅ Architecture — write it down first

⬜ → ✅ People — bus factor and expectations

⬜ → ✅ Processes — you are here

A reminder of what "order has arrived" feels like: deploying is not scary, a new person is useful in their first week, an incident is a procedure rather than a panic, and "why is it like this here?" has a written answer. You'll never reach perfection — it's enough that every week feels a little calmer than the last.

The series is finished; the topics aren't: separate articles on release cadence, small-team incident handling and hiring are coming. Stay around.

---

Originally published at mind.mansur.expert.