103 lines
2.8 KiB
Markdown
103 lines
2.8 KiB
Markdown
Duration: 30--40 minutes
|
|
|
|
## Definition
|
|
|
|
A project meeting is a coordination mechanism for decisions, blockers,
|
|
alignment, and delivery. A meeting is not progress by itself.
|
|
|
|
**Follow-up** converts discussion into owned actions and decisions.
|
|
|
|
## Simple Mental Model
|
|
|
|
> **A useful project meeting changes something.**
|
|
|
|
At the end you should know what was decided, who owns what, by when,
|
|
what is blocked, and what needs escalation.
|
|
|
|
## How It Works
|
|
|
|
Do not automatically create a recurring meeting for every project.
|
|
|
|
A useful review agenda:
|
|
|
|
1. Outcome / health
|
|
2. Last and next milestone
|
|
3. Risks/blockers
|
|
4. Scope changes
|
|
5. Decisions required
|
|
6. Actions, owners, dates
|
|
|
|
Distinguish:
|
|
|
|
**Decision:** We will use Option B.
|
|
|
|
**Action:** Alex updates the architecture by Friday.
|
|
|
|
Avoid "team to investigate." Give actions one owner and a date.
|
|
|
|
Use asynchronous status for routine information. Use meetings when
|
|
synchronous coordination adds value.
|
|
|
|
## Example
|
|
|
|
A weekly 60-minute meeting with eight people mostly consists of everyone
|
|
describing what they did. Replace the reporting portion asynchronously
|
|
and use synchronous time for two blockers and one scope decision.
|
|
|
|
## How It Fits Into the Bigger Picture
|
|
|
|
Status reporting communicates project state. Meetings resolve what
|
|
cannot efficiently be resolved asynchronously. [[Ownership and
|
|
Delegation]] determines who follows through afterward.
|
|
|
|
## My Company / Real-World Context
|
|
|
|
Cross-functional work with Product, DevOps, Security, IT, and vendors
|
|
can create meeting overload. Your project owner should drive normal
|
|
project follow-up. You join when your authority, escalation, or judgment
|
|
is required.
|
|
|
|
## CTO Perspective
|
|
|
|
If every project requires you in every meeting, **you are the system**.
|
|
A scalable leader designs ownership and information flow so their
|
|
presence is needed only where it adds value.
|
|
|
|
### Questions to Ask
|
|
|
|
- Does this require a meeting?
|
|
- What decision must be made?
|
|
- Who actually needs to attend?
|
|
- What is blocked?
|
|
- Who owns each action?
|
|
- By when?
|
|
- Can the owner follow this without me?
|
|
|
|
## Meeting Scenario
|
|
|
|
**Situation:** An owner includes you in a weekly execution meeting where
|
|
most discussion is detailed implementation.
|
|
|
|
**Possible response:**
|
|
|
|
> I don't need to be in the detailed execution meeting unless there's a
|
|
> decision, priority conflict, or escalation requiring me. Keep the
|
|
> project status current and bring me in when one of those conditions
|
|
> appears.
|
|
|
|
## Key Takeaways
|
|
|
|
- Meetings are tools, not evidence of progress.
|
|
- Use synchronous time for decisions, blockers, and coordination.
|
|
- Actions need owners and dates.
|
|
- Capture decisions separately.
|
|
- Prefer asynchronous status where possible.
|
|
- Project owners should drive normal follow-up.
|
|
|
|
## Related Concepts
|
|
|
|
- [[Status Reporting]]
|
|
- [[Ownership and Delegation]]
|
|
- [[Decision Log]]
|
|
- [[Project Health]]
|