Working with Sergey
Sergey is a platform/backend architect in CET, working 08:00–18:00. He is a visual, text-first thinker: written words and diagrams stick, spoken words do not. English is not his first language — plain English beats idiomatic English.
Full agreement: references/norms.md. Read it before answering anything not covered by the tables below.
Two modes
| Mode |
Trigger |
Action |
| Answer |
"How do I reach him?", "Can I book 09:30?", "Is email fine?" |
Answer from the norms and name the rule you applied. |
| Review |
Someone shows a draft DM, invite, announcement, proposal, estimate or PR |
Run the checklist below. Report each violation with the rule it breaks and the fix. |
In Review mode, report violations even when the draft is otherwise good. Silence reads as approval.
Channel ladder
| Priority |
Channel |
When |
| P0 business-critical |
Messenger DM or phone call |
Any hour, including the coding block. During unplanned absence he may be genuinely unreachable |
| Urgent |
Messenger DM, or a phone call if he gave you permission |
08:00–18:00 CET |
| Must actually happen |
Calendar event or tracked task |
Scheduled |
| FYI / discussion |
Written thread |
Best effort |
| — |
Email |
No SLA. Treated as noise. Never use for anything that must be read. |
Phone is an urgent channel for permitted callers. Permission is given by Sergey personally — never assumed, never requested in a thread, and having his number is not the same as having it. A call carries attention, not content: whoever called writes the outcome into the thread the same day.
Response and acknowledgement
| Item |
Rule |
| P0 |
Answered immediately, any hour |
| Urgent |
Within 30 min in the morning (08:00–12:00); within 2 h in the afternoon |
| Normal |
Within 4 working hours |
| Acknowledgement |
Runs both ways: he reacts to what he reads, and expects the same within 4 working hours. Where reactions do not exist (GitHub, Jira, email), a one-word ack reply. Ack means read, not agreed. Stated as an expectation — deliberately not a checklist item. |
08:00–12:00 is his collaboration window. Architecture, design, decisions, proposals and hard reviews belong here. This is the best time to reach him.
12:00–18:00 is coding. Only P0 makes him stop. Light syncs may be scheduled here; ad-hoc pings may not. An urgent message still gets an answer within 2 h — answering is not the same as being interrupted.
Review checklist
Run every item. Each failure is a finding.
- Channel — urgent content sent by email, or P0 sent to a thread instead of a DM/call?
- Timing — a complex, architecture or decision meeting booked into the afternoon? A hard question saved for late afternoon that should have gone to the morning? (An urgent DM in the afternoon is fine — it gets a 2 h answer. Do not flag it.)
- Agenda — a new or ad-hoc meeting invite without a written agenda sent ≥24h ahead? Longer than 30 min without justification? (Recurring ceremonies — standup, status, retro, planning — are exempt. Do not flag them.)
- Language — idioms, slang, regional dialect, sarcasm, or long compound sentences? Rewrite in plain English.
- Form — a decision or architecture explained only in prose, with no diagram or table?
- Proposal — missing the problem statement, fewer than two options, no trade-offs, or no text diagram?
- Ack request — announcement that needs confirmed readership but does not ask for a reaction?
- Autonomy — announcing an architecture, contract or public-interface change as done, when it needed approval first?
- Estimate — a T-shirt size with no proposed deadline, a deadline with no size, or a slip that was visible at a checkpoint and went unreported? (Both are required. A proposed date is correct, not a violation.)
- PR — implementation before test, red gates, non-conventional commit, or a merge to
main with no review?
- Absence — going away without ≥1 working day of notice, handover, and a calendar block?
- Lock-in — does the design tie a unit to one provider's proprietary service without naming the migration cost? Does it grant trust by network location instead of authenticating every call?
- Ceremony — does it propose a new meeting, status report or manual approval where a written artefact or an AI loop would do the same job? (Existing recurring ceremonies are not findings.)
Common mistakes
- Treating the phone call as the record. It is not. Write the outcome down.
- Reading "always available for business-critical" as "always available". Only P0 crosses into the afternoon coding block.
- Saving the hard conversation until the afternoon because the morning felt too early. It is the exact inversion of how he works.
- Sending a well-written email. It will be missed, and that is not a failure of attention.
- Asking for a decision with one option. One option is not a choice — it is a request for approval you already assumed — and it gets refused.
- Calling him because you have his number. Permission comes from Sergey personally; the number alone is not permission.
- Staying blocked for a day out of politeness. A 30-second question is asked immediately; the one-day rule is for problems you were meant to attempt yourself.
1---2name: working-with-sergey3description: Use when someone asks how to work with Sergey Bershadsky, when onboarding a new collaborator onto his team, when drafting or reviewing a message, announcement, meeting invite, proposal, estimate or pull request aimed at him, or when someone went silent, skipped an acknowledgement, sent something urgent by email, or booked a complex meeting into his afternoon.4---56# Working with Sergey78Sergey is a platform/backend architect in **CET**, working **08:00–18:00**. He is a visual, text-first thinker: written words and diagrams stick, spoken words do not. English is not his first language — plain English beats idiomatic English.910Full agreement: `references/norms.md`. Read it before answering anything not covered by the tables below.1112## Two modes1314| Mode | Trigger | Action |15|---|---|---|16| **Answer** | "How do I reach him?", "Can I book 09:30?", "Is email fine?" | Answer from the norms and name the rule you applied. |17| **Review** | Someone shows a draft DM, invite, announcement, proposal, estimate or PR | Run the checklist below. Report each violation with the rule it breaks and the fix. |1819In Review mode, report violations even when the draft is otherwise good. Silence reads as approval.2021## Channel ladder2223| Priority | Channel | When |24|---|---|---|25| P0 business-critical | Messenger DM **or phone call** | Any hour, including the coding block. During unplanned absence he may be genuinely unreachable |26| Urgent | Messenger DM, or **a phone call if he gave you permission** | 08:00–18:00 CET |27| Must actually happen | Calendar event or tracked task | Scheduled |28| FYI / discussion | Written thread | Best effort |29| — | **Email** | No SLA. Treated as noise. Never use for anything that must be read. |3031**Phone is an urgent channel for permitted callers.** Permission is given by Sergey personally — never assumed, never requested in a thread, and having his number is not the same as having it. A call carries attention, not content: whoever called writes the outcome into the thread the same day.3233## Response and acknowledgement3435| Item | Rule |36|---|---|37| P0 | Answered immediately, any hour |38| Urgent | Within 30 min in the morning (08:00–12:00); within 2 h in the afternoon |39| Normal | Within 4 working hours |40| Acknowledgement | Runs **both ways**: he reacts to what he reads, and expects the same within **4 working hours**. Where reactions do not exist (GitHub, Jira, email), a one-word `ack` reply. Ack means *read*, not *agreed*. Stated as an expectation — deliberately **not** a checklist item. |4142**08:00–12:00 is his collaboration window.** Architecture, design, decisions, proposals and hard reviews belong here. This is the best time to reach him.4344**12:00–18:00 is coding.** Only P0 makes him stop. Light syncs may be *scheduled* here; ad-hoc pings may not. An urgent message still gets an answer within 2 h — answering is not the same as being interrupted.4546## Review checklist4748Run every item. Each failure is a finding.49501. **Channel** — urgent content sent by email, or P0 sent to a thread instead of a DM/call?512. **Timing** — a complex, architecture or decision meeting booked into the afternoon? A hard question saved for late afternoon that should have gone to the morning? (An urgent DM in the afternoon is *fine* — it gets a 2 h answer. Do not flag it.)523. **Agenda** — a new or ad-hoc meeting invite without a written agenda sent ≥24h ahead? Longer than 30 min without justification? (Recurring ceremonies — standup, status, retro, planning — are exempt. Do not flag them.)534. **Language** — idioms, slang, regional dialect, sarcasm, or long compound sentences? Rewrite in plain English.545. **Form** — a decision or architecture explained only in prose, with no diagram or table?556. **Proposal** — missing the problem statement, fewer than two options, no trade-offs, or no text diagram?567. **Ack request** — announcement that needs confirmed readership but does not ask for a reaction?578. **Autonomy** — announcing an architecture, contract or public-interface change as done, when it needed approval first?589. **Estimate** — a T-shirt size with no proposed deadline, a deadline with no size, or a slip that was visible at a checkpoint and went unreported? (Both are required. A proposed date is *correct*, not a violation.)5910. **PR** — implementation before test, red gates, non-conventional commit, or a merge to `main` with no review?6011. **Absence** — going away without ≥1 working day of notice, handover, and a calendar block?6112. **Lock-in** — does the design tie a unit to one provider's proprietary service without naming the migration cost? Does it grant trust by network location instead of authenticating every call?6213. **Ceremony** — does it propose a *new* meeting, status report or manual approval where a written artefact or an AI loop would do the same job? (Existing recurring ceremonies are not findings.)6364## Common mistakes6566- Treating the phone call as the record. It is not. Write the outcome down.67- Reading "always available for business-critical" as "always available". Only P0 crosses into the afternoon coding block.68- Saving the hard conversation until the afternoon because the morning felt too early. It is the exact inversion of how he works.69- Sending a well-written email. It will be missed, and that is not a failure of attention.70- Asking for a decision with one option. One option is not a choice — it is a request for approval you already assumed — and it gets refused.71- Calling him because you have his number. Permission comes from Sergey personally; the number alone is not permission.72- Staying blocked for a day out of politeness. A 30-second question is asked immediately; the one-day rule is for problems you were meant to attempt yourself.
sergio-bershadsky