Two delivery check-ins
Morning Standup and Afternoon Catchup are each scheduled for one hour on most working days.
What we have now
A large recurring meeting system spanning frontline operations, sales, leadership, Tech & Product, and whole-company alignment.
The current system creates regular touchpoints, but Tech & Product carries a particularly heavy coordination load.
Long planning sessions
Sprint Planning lasts three hours and includes estimation, prioritisation, and story clarification.
Four-hour onsite
Dev Onsite combines product decisions, product grooming, and technical deep dives.
Business direction
Business WHY and WHAT each run for four hours in the business week. Product/Dev Onsite and the retrospective occur in the alternate week.
Baseline meeting load
The core Tech & Product sessions total approximately 26 hours per regular attendee every two-week sprint, before Product Sync, company demo, and individual 1-on-1 time.
Current recurring meeting inventory
Meeting durations are one hour unless shown otherwise. The Admin Whole Team meeting runs every day, including weekends.
| Area | Meeting | Current schedule | Primary purpose |
|---|---|---|---|
| Admin | Whole Team | Daily, 15:00–16:00 | Shift handover, service updates, open cases, and coverage. |
| Admin | Team Lead | Mon & Thu, 13:00 | Balance staffing/workload and escalate cross-shift issues. |
| Admin | Supervisor | Monday, 14:00 | Review performance, policies, resources, and weekly priorities. |
| Admin | QC | Mon–Thu, 10:00 | Validate findings and assign coaching, corrections, or SOP changes. |
| Sales | Sales Team | Daily, 09:30, unless on-site | Priorities, follow-ups, deal blockers, and support needs. |
| Marketing | None | No recurring meeting | Add only if a recurring coordination or decision need appears. |
| Business | Business WHY? | Week 1 Tuesday, 14:00–18:00 | Evidence, performance, customer feedback, causes, and risks. |
| Business | Business WHAT? | Week 1 Friday, 14:00–18:00 | Priorities, trade-offs, owners, success measures, and commitments. |
| Tech & Product | Sprint Planning | Week 1 Monday, 09:00–12:00 | Estimation, prioritisation, and clarification before commitment. |
| Tech & Product | Morning Standup | Working days, 09:00 | Coordinate daily delivery and surface blockers. |
| Tech & Product | Afternoon Catchup | Working days, 16:00 | Handle changes, blockers, and handoffs. |
| Tech & Product | Dev Onsite | Week 2 Tuesday, 14:00–18:00 | Product decisions/grooming plus technical deep dives. |
| Tech & Product | Sprint Retrospective | Week 2 Friday, 16:00–18:00 | Sprint summary, causes, and improvement actions. |
| Tech & Product | 1-on-1s | Week 2 Tuesday, from 10:00 | Feedback, support, workload, growth, and private concerns. |
| Company | Demo & Sharing | Week 2 Thursday, 14:00 | Share changes, learning, feedback, and follow-up questions. |
Current attendance pattern
Business WHY and WHAT normally include C-level executives, the Tech Director, Data Analyst, Business Analyst, Operations Manager, and Marketing Director. Tech & Product sessions include the delivery team plus the CTO. These groups share leaders, but the business sessions and Product/Dev Onsite sessions are intentionally placed in alternate weeks, so there is no direct leadership scheduling conflict between them.
What is not working
The problem is not simply the number of meetings. It is duplicated purpose, weak boundaries, centralised decision authority, and work entering delivery before it is ready.
The calendar consumes focus while still allowing uncertainty to reach Sprint Planning and implementation.
Daily coordination is too expensive
Nine one-hour standups and eight one-hour catchups consume 17 hours per person per fortnight. Detailed discussions can turn both sessions into broad status meetings.
Planning repeats refinement
Three-hour Sprint Planning includes routine clarification and point estimation, even though Dev Onsite already includes product grooming and technical discussion.
One onsite tries to answer incompatible questions
The four-hour Dev Onsite mixes “what and why” product decisions with “how” technical refinement. Product uncertainty can absorb the time intended for engineering.
Product accountability is leaking into engineering
Developers are being asked not only for feasibility input, but also to help design the product, prepare or support product presentations, and answer product questions that should already have a clear product owner. This reduces delivery capacity and makes accountability unclear.
Product decision authority is concentrated in the CTO
Under the reported current process, every meaningful product decision requires CTO approval. The CEO, PO, BA, and developers must persuade one person before a decision can move. This makes the CTO a de facto product executive while creating a queue around individual approval.
Readiness is implied, not proven
A story can appear to be ready because it was discussed. Missing rules, acceptance criteria, dependencies, or estimates then emerge during planning or coding.
Long sessions use broad attendance
Four-hour meetings do not consistently separate topics, required roles, and decision outputs, so people may attend large portions that do not require them.
Current core time cost
| Meeting group | Sessions per fortnight | Current duration | Hours |
|---|---|---|---|
| Morning Standup | 9 | 60 minutes | 9 |
| Afternoon Catchup | 8 | 60 minutes | 8 |
| Sprint Planning | 1 | 3 hours | 3 |
| Dev Onsite | 1 | 4 hours | 4 |
| Sprint Retrospective | 1 | 2 hours | 2 |
| Core total | 20 sessions | — | 26 hours |
This baseline excludes the newly proposed daily Product Sync, company demo, and individual 1-on-1 time so the before/after comparison remains like-for-like.
Deeper root cause: a central product-approval bottleneck
The meeting problem is partly a governance problem. Product discussions expand because decision rights are not delegated: proposals travel upward for CTO approval, and meetings become opportunities to convince the approver rather than forums where an accountable owner decides within clear guardrails.
| Current dynamic | Operational consequence |
|---|---|
| Nearly every product decision needs CTO approval | Decision lead time depends on one person’s availability and attention. |
| CEO, PO, BA, and developers all make separate cases to the CTO | Evidence and debate are repeated; ownership becomes persuasion rather than accountable decision-making. |
| The CTO settles product behaviour as well as technical direction | Product and technology authority blur; engineering inherits unresolved product work. |
| PO/PM authority is unclear or reversible | Teams wait for final approval, avoid autonomous decisions, or reopen previously discussed choices. |
| Escalation is the default instead of the exception | Product Sync, onsite, and ad hoc conversations all compete for the same approver. |
Diagnosis
The current CTO role appears to contain substantial CPO responsibility. A title change alone will not solve the problem: product decision rights must be delegated, and technical authority must be reassigned explicitly.
How to optimise
Create a two-week operating rhythm with strict timeboxes, explicit meeting contracts, and two story-readiness gates.
The proposed model reduces time by clarifying where each decision belongs—not by removing necessary collaboration.
Timebox coordination
Standup and Catchup become 30 minutes. Detailed discussion moves to a smaller follow-up.
Separate product and technical work
Product Onsite settles what and why; Dev Onsite settles how, risk, dependencies, splitting, and estimates.
Prepare one sprint ahead
Week 2 refinement prepares the following sprint, so new direction does not routinely interrupt work already committed.
Match attendance to agenda
Timed topics identify required participants and expected decisions so specialists attend only relevant portions.
Restore product ownership
Product owns product definition, design coordination, product narratives, and answers to product questions. Engineering contributes feasibility and technical evidence without becoming the substitute product function.
Protect engineering capacity
Developer involvement in product work is intentional, timeboxed, and limited to the technical perspective required for a decision.
Restore clear product and engineering ownership
Cross-functional collaboration remains essential. The change is that collaboration should not transfer accountability. Engineering should challenge assumptions, expose constraints, and explain technical implications; it should not be the default owner for unfinished product work.
| Work | Primary owner | Engineering contribution | Boundary |
|---|---|---|---|
| Product definition and priorities | Product decision owner, supported by PM/TPM and BA | Feasibility, cost, risk, dependency, and delivery impact | Engineering does not decide missing product behaviour by default. |
| Product design and user flows | Product/design owner | Technical constraints, implementation options, accessibility/performance input | Developers may advise, but should not become the product designer because ownership is absent. |
| Product questions | Named product owner, PM/TPM, or BA | Answer technical questions and clarify implemented behaviour | Business/product questions route to product ownership before reaching the whole development team. |
| Product presentations | Product or business presenter | Technical facts, demo support, and engineering Q&A when needed | Developers do not routinely build the product narrative or carry the presentation. |
| Technical approach and estimates | Tech Director/engineering team | Own the approach, decomposition, risk, dependencies, and estimates | Product supplies clear requirements and stays available for scoped clarification. |
Practical escalation rule
When engineering receives a product-design request or a product question without a clear owner or documented answer, route it to the named product owner. Engineering can provide bounded technical input, but the product owner records the decision and updates the story.
Recommended organisational change: formalise a CPO role
If the current CTO’s primary authority and day-to-day work are product vision, product approval, scope decisions, and product narrative, formally redesignating that role as Chief Product Officer (CPO) would make the real accountability visible. The reorganisation should be based on the work the person owns—not used as a cosmetic title change.
Critical safeguard
A CPO reorganisation must create a separate, explicit technical authority. The company should appoint a CTO, Head of Engineering, or empowered Tech Director to own architecture, engineering quality, security, reliability, technical risk, and engineering capability. Otherwise the boundary moves on paper while the organisation retains the same ambiguity.
| Decision area | Accountable role | Required input | Escalate only when |
|---|---|---|---|
| Company strategy, budget, and enterprise-level trade-offs | CEO / executive team | CPO, technical leader, finance/data, relevant functions | The decision changes company strategy, material budget, legal exposure, or cross-functional commitments. |
| Product vision, portfolio, positioning, and product principles | CPO | CEO, PO/PM, BA, customers/data, technical leader | It conflicts with company strategy or exceeds agreed investment/risk guardrails. |
| Routine feature scope, user flow, acceptance criteria, and prioritisation within an approved product direction | PO/PM or named Product Owner | BA, design, QA, engineering feasibility input | It crosses product guardrails, creates material commercial risk, or requires a portfolio trade-off. |
| Technical architecture, security, reliability, and engineering standards | CTO, Head of Engineering, or empowered Tech Director | Engineering team; CPO/PO for product constraints | It requires exceptional investment, changes company risk, or materially alters product strategy. |
| Story decomposition, implementation approach, and estimates | Engineering team under the technical leader | PO/PM and BA for requirement clarification; QA for testability | A product trade-off or unresolved business rule prevents a technical decision. |
The goal is not to remove the CPO from important decisions. It is to stop requiring personal approval for every routine choice. PO/PM roles need real authority inside documented product, budget, risk, and brand guardrails.
Decision-making policy
- Every product decision has one named accountable decision owner; contributors advise but do not share or dilute accountability.
- Routine decisions are made at the lowest competent level, usually the PO/PM, within explicit guardrails.
- The CPO decides portfolio, product-principle, and exceptional trade-off questions—not every story detail.
- The technical leader owns technical decisions and can reject unsafe or infeasible approaches without taking ownership of the product decision.
- Escalations include the decision required, options, evidence, recommendation, owner, and deadline. They are not open-ended persuasion sessions.
- Once decided, the outcome and rationale are documented. Reopening requires new evidence or a changed constraint.
The proposed two-week rhythm
Sprint commitment + business direction
Select ready work, then align leadership around performance and priorities.
- Monday · 1-hour Sprint Planning
- Tuesday · Business WHY?
- Friday · Business WHAT?
Product + technical refinement
Prepare future stories, share progress, and improve the operating process.
- Tuesday AM · Product Onsite
- Tuesday PM · Dev Onsite + 1-on-1s
- Thursday / Friday · Demo + Retro
Optimised Tech & Product meeting contracts
| Meeting | Proposed schedule | Core participants | Required output |
|---|---|---|---|
| Sprint Planning | Week 1 Monday, 09:00–10:00 | Delegated PO/PM or CPO, technical leader, engineers, QA/release | Sprint goal/capacity confirmed; ready stories selected and sequenced. No routine grooming or estimation. |
| Morning Standup | Working days, 09:00–09:30, except planning Monday | Delivery team and technical leader; product joins only when needed | Daily alignment; blockers/dependencies surfaced; detailed follow-ups assigned. |
| Product Sync | Working days, 10:00–10:30 | CPO or delegated PO/PM, PM/TPM, Business Analyst; others as needed | Immediate product alignment, blocker resolution, delegated decisions, and tracked escalations. |
| Afternoon Catchup | Working days, 16:00–16:30, except onsite and retro days | Delivery team and technical leader; product joins for a specific blocker | Material changes, urgent blockers, and handoffs handled; detailed topics taken offline. |
| Product Onsite | Week 2 Tuesday, 10:00–12:00 | CPO or delegated product decision owner, PM/TPM, BA, QA/release; technical leader for feasibility | Scope, rules, flows, and acceptance criteria resolved; qualified stories marked Product Ready. |
| Dev Onsite | Week 2 Tuesday, 14:00–16:00 | Technical leader, engineers, QA/release; PO/PM and BA for scoped clarification | Approach, story splitting, dependencies, risks, and estimates completed; stories marked Ready for Sprint. |
| 1-on-1s | Week 2 Tuesday, from 16:00; 30 minutes each | Individual and direct manager | Feedback, support, workload, growth, private concerns, and private follow-ups. |
| Sprint Retrospective | Week 2 Friday, 16:00–18:00 | Delivery team and technical leader; product representative for shared delivery issues | Delivery causes understood; a small number of owned improvements selected; prior actions reviewed. |
Detailed Week 1 calendar
| Day | Morning | Afternoon |
|---|---|---|
| Monday | 09:00–10:00 Sprint Planning 10:00–10:30 Product Sync | 16:00–16:30 Catchup |
| Tuesday | 09:00–09:30 Standup 10:00–10:30 Product Sync | 14:00–18:00 Business WHY? 16:00 team-led Catchup for available delivery staff |
| Wednesday | 09:00–09:30 Standup 10:00–10:30 Product Sync | 16:00–16:30 Catchup |
| Thursday | 09:00–09:30 Standup 10:00–10:30 Product Sync | 16:00–16:30 Catchup |
| Friday | 09:00–09:30 Standup 10:00–10:30 Product Sync | 14:00–18:00 Business WHAT? 16:00 team-led Catchup for available delivery staff |
Detailed Week 2 calendar
| Day | Morning | Afternoon / evening |
|---|---|---|
| Monday | 09:00–09:30 Standup 10:00–10:30 Product Sync | 16:00–16:30 Catchup |
| Tuesday | 09:00–09:30 Standup 10:00–12:00 Product Onsite | 14:00–16:00 Dev Onsite 16:00 onward 1-on-1s · no Catchup |
| Wednesday | 09:00–09:30 Standup 10:00–10:30 Product Sync | 16:00–16:30 Catchup |
| Thursday | 09:00–09:30 Standup 10:00–10:30 Product Sync | 14:00–15:00 Demo & Sharing 16:00–16:30 Catchup |
| Friday | 09:00–09:30 Standup 10:00–10:30 Product Sync | 16:00–18:00 Sprint Retrospective · no Catchup |
Product Onsite absorbs the daily Product Sync on Week 2 Tuesday. Week 2 refinement prepares stories for the following Sprint Planning session.
Separate the decision flow
Product Onsite
Scope, business rules, flows, acceptance criteria, examples, and edge cases.
Dev Onsite
Technical approach, splitting, dependencies, risks, testability, and point estimates.
Sprint Planning
Goal, capacity, priority, selection, sequencing, and immediate next steps.
Enforce story readiness
Product Ready
- User, problem, intended outcome, scope, and exclusions are clear.
- Rules, flows, and relevant designs are documented.
- Acceptance criteria cover important examples and edge cases.
- No unresolved product decision blocks technical refinement.
Ready for Sprint
- All Product Ready conditions are met.
- A feasible implementation/testing approach is understood.
- The work is appropriately split, sized, and estimated.
- Blocking dependencies are resolved or explicitly managed.
- No known question prevents implementation or testing.
- Only Product Ready stories enter Dev Onsite product-story refinement.
- Only Ready for Sprint stories can be selected for planned implementation.
- Engineers must not invent missing product behaviour; questions return to the product owner and update the story.
- Attendance or discussion does not automatically make a story ready.
- Material scope changes trigger a new readiness check.
- Leadership urgency does not silently bypass the gates. Incidents and timeboxed discovery use explicit expedited paths.
Use agendas to protect the boundaries
| Session | Time | Agenda item | Output |
|---|---|---|---|
| Sprint Planning | 10 min | Goal, availability, capacity | Shared planning constraints |
| 40 min | Select and sequence ready stories | Proposed sprint scope | |
| 10 min | Confirm dependencies and next steps | Committed scope and owners | |
| Product Onsite | 30 min | Resolve priority product decisions | Recorded scope/behaviour decisions |
| 75 min | Groom candidate stories | Rules, flows, criteria, examples, designs | |
| 15 min | Readiness review with engineering input | Product Ready stories or named actions | |
| Dev Onsite | 60 min | Refine Product Ready stories | Approach, splitting, estimates, dependencies, risks |
| 60 min | Technical stories and deep dives | Architecture, reliability, debt, or investigation decisions |
Estimated time impact
On a like-for-like basis, shortening daily coordination and reducing planning creates the main saving. Splitting the onsite does not increase the combined four-hour refinement allocation; it makes the time purposeful.
| Meeting group | Current | Proposed | Change |
|---|---|---|---|
| Morning Standups | 9 hours | 4.5 hours | −4.5 hours |
| Afternoon Catchups | 8 hours | 4 hours | −4 hours |
| Sprint Planning | 3 hours | 1 hour | −2 hours |
| Combined refinement/onsite | 4 hours | 4 hours | Same allocation; clearer split |
| Sprint Retrospective | 2 hours | 2 hours | No change |
| Core total per regular attendee | 26 hours | 15.5 hours | −10.5 hours (about 40%) |
How to measure success
Run the proposed system for four to six sprints. Measure both efficiency and delivery quality so reduced meeting time does not hide new coordination failures.
Success means less time in broad recurring meetings and fewer readiness problems reaching planning or implementation.
Meeting cost
Total attendee-hours fall, not just calendar duration.
Outcome quality
Meetings reliably produce their stated decisions, actions, or coordination outcome.
Planning readiness
Clarification and re-estimation during Sprint Planning become exceptions.
Delivery clarity
Implementation is rarely blocked by missing product behaviour or unresolved dependencies.
Focused attendance
Long sessions use agenda-level attendance and detailed follow-ups use smaller groups.
Improvement follow-through
Retrospective actions are completed by the next review rather than repeatedly reopened.
Role clarity
Engineering time spent substituting for product ownership trends down while required feasibility input remains available.
Product responsiveness
Product questions receive an owned, documented answer before they block refinement or delivery.
Meeting cost = meeting duration × attendee count + preparation timeRecommended scorecard
| Measure | How to capture it | Suggested success signal after trial | Owner |
|---|---|---|---|
| Core meeting hours per regular attendee | Calendar duration for the five core sessions | At or below 15.5 hours per fortnight | Tech Director |
| Total attendee-hours | Duration × actual attendees for every recurring meeting | 30%+ reduction without worse delivery signals | PM/TPM |
| Timebox adherence | Actual end time vs scheduled end time | 90%+ of standups/catchups finish within 30 minutes | Meeting facilitator |
| Outcome achieved | Yes/no check against the stated meeting output | 85%+ of recurring meetings achieve their outcome | Meeting owner |
| Planning clarification | Count stories requiring material clarification or re-estimation in planning | Near zero; remove any affected story from selection | Product + Tech leads |
| Planning rejection rate | Stories removed because readiness criteria are unmet | Declining trend after the first two sprints | PM/TPM |
| Implementation blocked by product gaps | Count blocked stories where expected behaviour was missing | Downward trend; target zero recurring causes | QA/release + Tech Director |
| Engineering time spent on product substitution | Estimate hours spent creating product design/narrative, preparing product presentations, or answering unowned product questions | Downward trend; exceptions are explicit, timeboxed, and approved | Tech Director + PM/TPM |
| Unowned product questions | Count questions reaching engineering without a named product owner or documented decision path | Near zero; every question has an owner and response date | PM/TPM + Business Analyst |
| Routine product decision lead time | Median working time from a decision request to a documented answer | Two working days or less for routine decisions | PO/PM |
| Product approval concentration | Percentage of routine product decisions escalated to the current CTO or proposed CPO for direct approval | Under 20% after guardrails stabilise; exceptions documented | CPO + PO/PM |
| Decision ownership completeness | Percentage of product decisions with a named accountable owner, date, and recorded rationale | 100% for material decisions | PM/TPM + BA |
| Decision reopening rate | Decisions reopened without new evidence or a changed constraint | Downward trend; repeated causes reviewed monthly | CPO |
| Focused follow-ups | Count deep-dive topics moved out of daily meetings and attendee count for each | Daily timebox maintained; follow-ups limited to required people | Daily facilitator |
| Retrospective action completion | Actions closed before the next retrospective | 80%+ completed or explicitly superseded | Action owners |
| Team pulse | Fortnightly 1–5 rating: “meetings help me progress work” | Stable or improving while attendee-hours fall | Engineering manager |
Suggested percentages are trial targets, not historical baselines. Capture one sprint of baseline data where possible and adjust targets if the initial measurement shows a materially different starting point.
Review cadence
Before trial
Publish meeting contracts, readiness criteria, owners, and templates. Capture baseline calendar hours.
Every sprint
Collect timebox, attendee-hour, readiness, blocker, and action-completion data.
Midpoint
After two or three sprints, fix only clear implementation problems; avoid redesigning the whole model.
Final review
After four to six sprints, compare against baseline and decide what to keep, narrow, adjust, or remove.
Decision rule
Adopt the model permanently when meeting time and attendee-hours fall, readiness problems in planning/implementation trend down, meeting outcomes remain strong, and the team pulse does not deteriorate. If time falls but blockers rise, restore the missing coordination through focused changes—not automatically by returning every meeting to its former length.
Recommendation and rollout
Approve one consistent operating model, trial it visibly, and make the owners accountable for both the time saved and the delivery outcome.
Approve the proposed model for the next 4–6 sprints.
The trial should start with a published calendar, explicit meeting contracts, Product Ready and Ready for Sprint workflow states, and a shared scorecard.
- 30-minute Morning Standup and Afternoon Catchup
- Week 1 business direction; Week 2 product/technical refinement
- Product Onsite in the morning; Dev Onsite in the afternoon
- Formal CPO accountability for product, with a separate empowered technical leader
- Delegated PO/PM decision rights within explicit guardrails
- One-hour Sprint Planning from Ready for Sprint stories only
- Four-to-six-sprint measurement period with a documented final decision
Accountability
The CPO should own product governance, product guardrails, and the delegation of routine decisions. The PO/PM and Business Analyst own preparation, documented decisions, and Product Ready evidence. A separate CTO, Head of Engineering, or empowered Tech Director owns the technical organisation and Ready for Sprint evidence. QA/release tests whether acceptance criteria and delivery behaviour are clear; each meeting owner records outcomes and attendee data.
Operating principle
Clarity before commitment.
Product owns clarity. Engineering owns technical readiness. Sprint Planning selects work that has passed both gates. No meeting creates an automatic commitment merely because the topic was discussed.