# Operating cadence Пн–Пт, що масштабується 30→300

> День-за-днем операційний ритм — план у понеділок, midweek-чек у середу, ретро в четвер, owner review у пʼятницю — що тримається від 30 до 300 людей без перетворення на meeting-театр.

- Автор: Ярослав Максимович (Founder & CEO, AI Advisory Board)
- Опубліковано: 2026-06-04
- Оновлено: 2026-10-26
- Джерело: https://aiadvisoryboard.me/uk/blog/ops-cadence-monday-to-friday

Якщо ви власник, який читає 5 апдейтів на день і все одно почувається сліпим — проблема не в апдейтах. Проблема в тому, що компанія працює в event-driven режимі: кожна пожежа породжує зустріч, тиждень не має передбачуваної форми. Виправлення — ритм Пн–Пт, який ви здатні захистити і на 30, і на 300 людях.

## TL;DR

- Operating cadence — це фіксований тижневий ритм: понеділок-план, midweek-чек у середу, ретро в четвер, owner review у пʼятницю. Ті ж дні, ті ж питання, щотижня.
- Cadence бʼє event-driven хаос, бо перетворює сюрпризи з "інцидентів" на "scheduled signal" — зазвичай у межах одного тижня.
- На 300 людях cadence лишається. Артефакти змінюють форму — ритм ні.

## Чому event-driven ламається на 30+?

На десяти ви чуєте все, проходячи повз столи. На тридцяти — це ламається. На 80 — засновник стає bottleneck кожного рішення, бо нічого не має запланованого слота.

Event-driven означає: щось трапилось, хтось пише в Slack, призначається зустріч, ухвалюється рішення, через два тижні ніхто не памʼятає, що саме. Тиждень не має форми. Кожен день — те саме гасіння.

> **Визначення:** Operating cadence — фіксований тижневий ритм планування, чекінгу, ретро і review з однаковими днями та однаковими питаннями. Протилежність event-driven.

Виправлення — не "менше зустрічей". Виправлення — чотири правильні зустрічі в правильні дні, навколо яких укладається все інше.

## Як виглядає ритм Пн–Пт?

Пʼять днів. Чотири якорі. Решта — виконання.

### Понеділок — Plan

Кожна команда пише Plan тижня в трьох пунктах до 11:00 локального часу. Три пункти, не десять. Засновник читає всі до обіду. Час на team lead: до 15 хвилин.

### Середа — Midweek check

Короткий письмовий чекін: чи на курсі по трьох пунктах? Який ранній Gap? Без зустрічі. Async. 5 хвилин писати, 5 читати.

### Четвер — Retro

Кожна команда — 20-хвилинне ретро по Gaps минулого тижня. Одна класифікація на Gap. Одна системна правка на команду на тиждень.

### Пʼятниця — Owner review

Засновник — 30-хвилинний solo-огляд тижня: чи компанія влучила в Plan? Де Gap? Яке рішення треба ухвалити до понеділка? Вихід — однасторінкове memo, не зустріч.

```
Cadence Пн–Пт (вкладіть у спільний календар):

ПН 09:00–11:00 — Team leads пишуть Week Plan (3 пункти, async)
ПН 11:00–12:00 — Засновник читає всі Plans (без зустрічі)
СР 14:00–14:30 — Async midweek check (5 хв письма на лід)
ЧТ 15:00–15:20 — Team retro (по команді, 20 хв)
ПТ 14:00–14:30 — Owner review (solo, письмове memo)
ПТ 17:00       — Memo опубліковано в leadership-каналі

Правило: будь-яка неавральна зустріч має пояснити, чому її тема не вмістилася в один із якорів.
```

Це весь cadence. Менше трьох годин структурованого ops-часу на team lead на тиждень. Дисципліна — тримати якорі сакральними навіть коли компанія горить.

> **Tool tip (AIAdvisoryBoard.me):** Понеділковий Plan і пʼятничне Review — це точка, де петля Plan → Fact → Gap живе або помирає. Більшість власників ставлять cadence і за місяць помічають, що дві-три команди хронічно не влучають у Plan або хронічно переобіцяють. Саме цей сигнал показує 7-денна діагностика — автоматично, по всій компанії, до того як ви додаєте dashboard або AI. Без cadence і baseline будь-який куплений dashboard — декорація. Деталі: https://aiadvisoryboard.me/?lang=en.

## Чому це масштабується від 30 до 300?

Артефакти стискаються, ритм — ні.

На 30 людях пʼятничне memo — одна сторінка, засновник пише сам. На 100 — memo все ще одна сторінка, але збирається з пʼяти team-level. На 300 — все ще одна сторінка, але Heads-of синтезують свої організації в по одному пункту.

> **Визначення:** Cadence invariance — властивість, за якої ритм (Пн-план, Ср-чек, Чт-ретро, Пт-review) лишається ідентичним між розмірами компанії, тоді як артефакти і власники зміщуються.

Помилка, яку засновники роблять на 100 людях — вигадують новий cadence. Додають OKR-чекіни, quarterly business reviews, monthly all-hands, weekly leadership syncs — і простий тижневий ритм ховається під церемоніями. Правильно — тримати чотири якорі, дозволяючи іншим ритуалам прилаштовуватись.

## Що ламається, коли пропускаєте якір?

Кожен пропущений якір створює передбачуваний failure mode.

> **Визначення:** Anchor failure mode — операційна дисфункція, що зʼявляється, коли один із чотирьох якорів cadence стабільно пропускається.

- **Немає Понеділкового Plan** → тиждень без зобовʼязання. Команди реагують на найгучніше повідомлення в Slack.
- **Немає Середового Check** → пʼятничні сюрпризи. Gap зʼявляється тільки коли вже зашкодив.
- **Немає Четвергового Retro** → та сама класифікація Gap повторюється щотижня. Немає навчання.
- **Немає Пʼятничного Review** → у власника немає інтегрованого погляду на тиждень. Рішення переобговорюються в понеділок.

Я бачив компанії, що пропускали середовий чек "бо здається зайвим". За чотири тижні — знову пʼятничні сюрпризи. Чек — найдешевша страховка в cadence.

## Як захищати cadence, коли компанія горить?

Це справжній тест. Будь-який ритм працює в спокійний тиждень. Чотири якорі мають вижити в crisis-week — інакше вони не compounding.

Три правила оборони:

1. **Cadence не рухається через індивідуальні пожежі.** Production outage обробляється в incident-каналі — він не відміняє пʼятничне Review.
2. **Засновник видимо моделює cadence.** Якщо засновник двічі пропускає memo — cadence закінчився.
3. **Agenda фіксована, контент змінний.** План crisis-тижня може бути "стабілізувати платформу, тримати лінію, без нових ставок" — але це все одно три пункти в понеділок.

## Manager scan (приклад 2-хвилинного дайджеста)

Реальний Plan → Fact → Gap дайджест з пʼятничного review сервісної компанії на 140 людей у "fire week":

- **Engineering** — Plan: відвантажити payment-fix, тримати лінію. Fact: відвантажили fix, два нових бага. Gap: QUALITY_REWORK.
- **Customer success** — Plan: ескалації після outage. Fact: оброблено + 4 churn-ризики. Gap: DEPENDENCY_FAIL (eng-fix пізно).
- **Sales** — Plan: пауза outbound, тримати inbound. Fact: тримали. Gap: SCOPE_CHANGE (свідомо).
- **Marketing** — Plan: пауза запуску, incident-комунікації. Fact: комуси відвантажили, запуск зсунули. Gap: SCOPE_CHANGE (свідомо).
- **Ops** — Plan: координація з вендором. Fact: готово. Gap: немає.
- **Finance** — Plan: invoice recon. Fact: готово. Gap: немає.
- **People** — Plan: 3 оффери. Fact: 2 accept, 1 decline. Gap: ESTIMATION_MISS (comp-band не той).
- **Product** — Plan: без нової роботи. Fact: тримали. Gap: немає.

У crisis-тижні дайджест усе одно вийшов. Власник знає: payment-fix приніс нові баги (пріоритет наступного тижня), 4 churn-ризики треба до понеділка, comp-band треба правити. Три рішення, записані до вихідних.

## Micro-case (що змінюється за 7-14 днів)

Софтверна компанія на 75 людей встановила cadence Пн–Пт холодно — без інших змін. Тиждень 1 був важкий: ліди забували Plan, середовий чек сприймали як опціональний, пʼятничне memo засновник писав 2 години. До тижня 2 Plan були щільні (3 пункти, до 15 хв на лід), memo — 35 хв. До дня 14 засновник сказав, що найкорисніший артефакт — четвергове ретро: пʼять команд незалежно зафлагали той самий dependency-failure патерн, який став одним архітектурним рішенням. Загальний meeting-час впав приблизно на третину, бо event-driven зустрічі перестали бронюватись, коли їхня тема вже мала слот у cadence.

> **Note on this case:** This example is illustrative — based on typical patterns we observe with companies of 30-500 employees, not a single named client. Specific numbers are rounded approximations of common ranges, not guarantees.

> **Tool tip (AIAdvisoryBoard.me):** Коли cadence крутиться, наступне питання — які команди стабільно влучають у Plan, а які дрейфують. Саме це міряє діагностика Plan → Fact → Gap у межах тижня — автоматично, з сигналу, який cadence уже виробляє. Засновники типово виявляють, що одна-дві команди тихо переобіцяють кожен понеділок і тихо недодають кожну пʼятницю. Cadence робить патерн видимим, діагностика — числовим. https://aiadvisoryboard.me/?lang=en.

## FAQ

**Чому понеділок, а не неділя чи вівторок?**
Понеділок зранку — команда свіжа, тиждень без зобовʼязань. Недільний Plan заходить у вихідні. Вівторковий — понеділок у смітник. Дедлайн 11:00 у понеділок дає час подумати і обмежує тяганину.

**Хіба середовий чек не зайвий, якщо вже є щоденні standup?**
Daily standup — усний статус. Середовий чек — письмовий, персистентний, привʼязаний до Plan сигнал, що засновник читає за 5 хв. Різні цілі. Якщо треба вирізати — вирізайте standup, не чек.

**Що якщо команда повністю async / в різних таймзонах?**
Cadence уже async-friendly — синхронне лише четвергове ретро, а 20 хв на команду переживають більшість таймзон. Plan, чек і memo — письмові.

**Як вкладаються OKR?**
OKR — квартальний намір. Тижневий cadence — ритм виконання, що доставляє OKR. Понеділковий Plan має явно повʼязувати кожен пункт з OKR; пʼятничне Review — звітувати по тих самих.

**На якому розмірі cadence ламається?**
Не ламається — артефакти стискаються. На 300 людях Heads-of пишуть Plan і memo, не окремі ліди. Засновник читає 8 Plan-summary, не 40. Ритм ідентичний.

## Висновок

Cadence Пн–Пт — найдешевша і найбільш-пропущена операційна дисципліна в SMB. Чотири якорі. Ті ж дні щотижня. Захищаєте їх у пожежу — вони compounding. Пропускаєте — за місяць повертаєтесь у event-driven хаос.

Спочатку ставите cadence. Потім ставите вимірювання поверх. AI-агенти — пізніше, коли ритм доведений.

Якщо хочете систему, яка щодня показує Plan → Fact → Gap по всій компанії автоматично — подивіться, як працює 7-денна діагностика: https://aiadvisoryboard.me/?lang=en.

---

Цитуючи, посилайтесь на https://aiadvisoryboard.me/uk/blog/ops-cadence-monday-to-friday. Більше статей: https://aiadvisoryboard.me/uk/blog