Ceremonies

AI-First IT Operating Model

Ceremonies are not here to manage people.

Their purpose is to manage priorities, quality, reliability, knowledge, adoption and continuous improvement.

Daily Operations Sync

As needed · Around 15 minutes

A fast sync across the team.

Remove blockers, incidents and ambiguity.

The System Owner can adjust the duration and cadence as needed so the sync stays short and useful.

Detailed tasks and Jira tickets are not discussed here.

Owner System Owner

Required questions

  • 1 What is blocking the business today?
  • 2 What incident or risk appeared since the last sync?
  • 3 What decision do we need to make today?
  • 4 Where do we risk a delay or ownership ambiguity?

Outputs

  • list of blockers
  • assigned owner for each blocker
  • decision list
  • escalation list

Business Prioritization

Once a week · 45 minutes

Identify the company's most important problems.

Decide where the Product Builder's capacity should go.


Required questions

  • 1 What new problems have appeared?
  • 2 Which problems have the biggest business impact?
  • 3 Where is the company losing time?
  • 4 What can be automated?
  • 5 What can be removed altogether?
  • 6 Which 3–5 priorities will we focus on next week?

Outputs

  • prioritized list of problems
  • list of new initiatives
  • priority decisions
  • list of rejected requests

Work Preparation

As needed · 30–45 minutes

Ensure work for a Product Engineer has a clear business reason, priority, and expected outcome.

Capture acceptance criteria, effort estimate, and known risks.

Protect business value, budget, quality, and operational stability.


Required questions

  • 1 Why are we doing this work?
  • 2 What business outcome do we expect?
  • 3 What are the acceptance criteria?
  • 4 What is the estimate and the main risks?

Outputs

  • Jira ticket ready for implementation

Weekly Delivery Planning

Once a week · 30–45 minutes

A classic IT team works in a weekly delivery cycle.

The goal is not to follow Scrum rituals, but to ensure short-term predictability, focus, quality, and transparent commitment.

At the start of the week the team selects a limited number of priorities from Ready for Delivery based on available capacity.

The team commits to delivering the selected items unless an incident, blocker, or business-priority change occurs.

Commitment is not a promise to deliver at any cost. It is a commitment to protect quality, communicate risks early, and keep work status up to date.

We do not rely on story points or a dogmatic sprint scope. Incidents and support have explicit capacity reserved.

External work is planned and evaluated in hourly ranges.

Owner System Owner

Required questions

  • 1 What are we committing to deliver this week?
  • 2 How much capacity is reserved for support and incidents?
  • 3 What is risky?
  • 4 What requires a decision or collaboration?
  • 5 What stays in Ready for Delivery and why?
  • 6 What moves to next week and why?

Outputs

  • Weekly Commitment
  • list of priorities for the week
  • reserved support and incident capacity
  • list of risks and decisions
  • list of items carried into next week with explanation

Strategic Product Review

Once a month · 60–90 minutes

Answer the question: Are we building the right things?

Whether a ticket works is not the point.

Whether a release is ready is not the point.

Owner CEO
Participants CEO CTO + Product Builder

Required questions

  • 1 Which company problems are costing us the most time or money today?
  • 2 What have we learned since the last review?
  • 3 What new opportunities have emerged?
  • 4 Which processes can be removed or automated?
  • 5 What are the Product Builder's Top 3 priorities?
  • 6 What decision do we need from the CEO?

Outputs

  • strategic priorities
  • CEO decisions
  • new Product Builder initiatives
  • terminated initiatives

Product Delivery Review

Once a week · 45 minutes

Check whether what we delivered actually works.

Owner System Owner

Required questions

  • 1 What has been released?
  • 2 Does it work?
  • 3 What feedback have we received?
  • 4 What incidents occurred?
  • 5 What changes do we need to make?
  • 6 What releases are coming next?

Outputs

  • list of verified releases
  • list of problems
  • list of follow-up tasks
  • improvement ideas

Reliability Review

Once a week · 45 minutes

Managing system quality and reliability.

Owner System Owner

Required questions

  • 1 What incidents occurred?
  • 2 What were the root causes?
  • 3 What have we learned?
  • 4 Is monitoring working correctly?
  • 5 Are there blind spots in monitoring?
  • 6 Are the tests sufficient?
  • 7 Which technical debt poses the biggest risk?

Outputs

  • incident list
  • root cause analyses
  • preventive actions
  • risk list
  • action plan

Operations Review

Once a week · 30 minutes

Reviewing the company's IT environment.


Required questions

  • 1 Are backups working?
  • 2 Has restore testing been completed?
  • 3 Is the infrastructure stable?
  • 4 Are licenses under control?
  • 5 Are there any security risks?
  • 6 Are all critical services available?

Outputs

  • infrastructure status
  • risk list
  • security measures
  • corrective action plan

Business Systems Review

Once a week · 30 minutes

Ensure business systems work properly from the users' perspective.


Required questions

  • 1 What problems are users trying to solve?
  • 2 Which questions keep repeating?
  • 3 Which processes do users not understand?
  • 4 What documentation is missing?
  • 5 Which parts of support can be automated?
  • 6 What feedback do users have?

Outputs

  • list of user issues
  • automation ideas
  • documentation requests
  • process change proposals

Release Readiness Review

As needed before a release · 15–30 minutes

Decide whether a change is ready for production release.

Owner System Owner

Required questions

  • 1 Have the tests been completed?
  • 2 Is monitoring ready?
  • 3 Is there a rollback plan?
  • 4 Is the documentation ready?
  • 5 Have the users been informed?
  • 6 Is the release risk acceptable?

Outputs

  • GO / NO GO decision
  • list of open risks
  • release checklist
  • rollback plan

AI Engineering Session

Every 14 days · 60 minutes

Sharing AI experience and continuously increasing productivity.

CTO & Product Builder joins only when he can bring or gain new know-how, or when strategic AI input is needed.

Participants Whole team

Required questions

  • 1 What have you automated?
  • 2 Where have you saved time?
  • 3 Which AI workflow works best?
  • 4 What new tools have you discovered?
  • 5 What can be automated next?
  • 6 What knowledge should we share?

Outputs

  • shared AI workflows
  • new automations
  • recommended tools
  • list of experiments
  • next improvement plan

Rule for all ceremonies

Every ceremony must end with:

  1. A decision
  2. An assigned owner
  3. A due date
  4. A record in Business As Code / Knowledge Base, or in Jira for tasks

If no decision or action step is produced, the ceremony probably did not need to happen.