Skip to content

SE Ways of Working

The technical modules teach you the tools. This track teaches the other half of the job: how to communicate, report progress, raise a blocker without dumping load on a senior, handle a crisis, run a retro, and behave like someone a team can trust with ownership.

These are SE's real practices — adapted from the protocols Simple Enough's own agents and engineers work under every day, not generic professional-skills advice. Each guide names what it's adapted from, so you can go read the source yourself if you want the full detail.

Format

Each guide is short and practical, not a technical module:

  • When this matters — the situation that calls for it.
  • The practice — the guidance itself, in plain terms.
  • Checklist — a short do-this list you can run through in the moment.
  • Template — a copy-paste starting point, where one fits.
  • Adapted from — the SE source this is drawn from.

No Socratic gate, no Anki deck. Read a guide when you need it — before your first status update, the first time you're stuck, or the first time something breaks.

The guides

  1. Communication & status updates — writing a clear update and matching it to your reader; async vs. sync; the daily/weekly cadence.
  2. Reporting blockers & asking for help — telling a real decision you need from someone else apart from something you should just resolve yourself, without dumping load on a senior.
  3. Crisis & incident response — what to do when something's broken: mitigate first, keep people informed, then run a blameless postmortem.
  4. Retrospectives & continuous improvement — blameless retros, working a problem back to its pattern, and closing the loop on last time's actions.
  5. Professionalism & ownership — verifying your own work before calling it done, being able to say how you verified it, and the small working agreement that keeps a team's trust.

All five guides are live now — find them in the left-hand nav under SE Ways of Working.

Why this exists

A junior who can debug a cluster but can't write a status update, or can't tell the difference between "I should just fix this myself" and "I need to escalate," is going to struggle on a real team long before the technical gaps show up. This track exists so that gap gets closed deliberately, the same way the technical modules close it for Kubernetes or Terraform.