A simple system for staying aligned without drowning in meetings.
This workflow is designed for teams of 5–10 engineers building complex products that mix software, data, and real-world systems.
1. Direction Layer (Goals or OKR)
Every quarter (or every 6–8 weeks), define:
One Objective
“Improve the reliability of our product in real-world use.”
Three to four Key Results
- KR1: “Reduce system failures by 50%”
- KR2: “Increase successful user actions to 95%”
- KR3: “Ship two real-world pilot deployments”
These are outcomes, not features.
2. Risk Layer (Epics, Big Work Buckets)
💡 Epics are the most important layer. This is the unit of ownership. I propose you spell out “what my organization” want and if we fuck up, the following will happen clearly.
Break the objective into a few Major Initiatives.
Example:
- Data Integrity
- Automation
- User Experience
- Deployment Reliability
Each initiative should answer:
- What risk does this reduce?
- What happens if this fails?
Assign an owner:
- Discuss it with owner (usually an IC) e.g. if you deliver this, you can write this killer line on your resume.
- Suggest such killer lines in Epic itself “Added OTEL and Sentry to gain fine-grained visibility into reliability issues that helped to reduce the error rate from X to Y, and MTTR from X to Y!” etc. Work out this line with them. This way you can align your interest with theirs.
3. Execution Layer (Sprints)
Work in 2-week sprints.
Each sprint has:
- One Sprint Goal (tied to a Key Result)
“Reduce errors in user workflows”
- A small set of tasks that plausibly move that goal
Engineers choose how to achieve the goal.
4. Where Work Lives
| Tool | Purpose |
|---|---|
| Project board | Goals, sprint plans, priorities |
| Code repo | Issues, pull requests, tests |
| Decisions, alignment | |
| Video calls | Unblocking and demos |
Keep strict boundaries:
- Planning lives in the project board
- Execution lives in the repo
- Decisions live in email
5. Weekly Rhythm
No daily standups. Use written updates instead.
| Day | Activity |
|---|---|
| Monday | Sprint planning |
| During week | Build, test, review |
| Friday | Demo and review |
6. Weekly Update Template
Each person writes:
- What goal did I work toward?
- What changed because of my work?
- What is at risk?
- What will I focus on next?
This replaces most meetings.
7. What Not To Do
- Don’t track work in multiple places
- Don’t turn goals into task lists
- Don’t schedule meetings to fix unclear docs
- Don’t hide problems until the sprint ends
8. One Rule to Remember
Goals define direction. Sprints define learning. Code defines reality.
Everything else is just coordination overhead.