Annual Day Team Lead Briefing

Deck: annual-day-high-performance-culture-v4.pptx

Purpose: Prepare selected team leads and senior developers to participate in specific exercises and short field-note segments during the June 25 annual-day session.

Overall Story

The session is built around one connected loop:

Customer signal -> Product bet -> Growth experiment -> Platform leverage -> Engineering execution -> Secure reliable release -> Evidence -> Refinement

Every team lead should reinforce this idea. The goal is not to teach isolated concepts. The goal is to help the team see how product thinking, growth engineering, platform engineering, quality, security, reliability, and ownership work together.

Named Participant Roles

Use these named participants for the June 25 session:

We are leaving the third senior developer / AI accountability slot open for now. If needed, you can either cover it yourself during the DevSecOps section or ask Thinesh to briefly connect platform guardrails with AI/security later.

Gunjan: Product Bet Exercise

Where It Fits

Slide 13: Exercise: turn a request into a product bet.

What They Facilitate

The group receives a request:

Build a manager dashboard.

They must convert it into:

• User.
• Problem.
• Outcome.
• Metric.
• Smallest experiment.

What To Prepare

Gunjan should prepare one real or realistic example from Simpro where a request came as a solution instead of a problem.

Gunjan should be ready to say:

Many times we receive the solution first: dashboard, report, export, integration, alert. Our job is not to reject the request. Our job is to uncover the problem behind it so we build the right thing.

Facilitator Script

We are going to practice slowing down before we build. The request is "Build a manager dashboard." Do not start with widgets or screens. First identify the user, the decision they need to make, the pain they have today, and what measurable improvement would prove value.

Good Example Answer

Managers struggle to identify staffing risks before weekly planning. We believe a focused capacity dashboard can reduce planning time from two hours to thirty minutes for pilot managers. Before building the full dashboard, we will prototype the top three decisions managers need to make and test it with five managers.

Debrief Questions

• What changed when we started with the problem instead of the screen?
• What assumption would we need to validate before full build?
• What would be the smallest useful experiment?

Output

Each group shares one product bet in this format:

We believe change will improve metric for user group because evidence.

Heads-Up Message For Gunjan

Gunjan, I would like you to facilitate the Product Bet exercise. Please prepare one example where a stakeholder/customer request came as a solution, such as a dashboard, report, export, alert, or integration. Your role is to help the group slow down and convert the request into user, problem, outcome, metric, and smallest experiment. Please keep it practical and use one real work pattern if possible.

Santosh: Growth Engineering Exercise

Where It Fits

Slides 14-15: Growth engineering loop and growth metrics + engineering health.

What They Facilitate

They help the audience connect product bets to measurable experiments.

What To Prepare

Santosh should prepare one example of a feature where success was unclear after release because metrics were missing.

Santosh should be ready to say:

If we launch and cannot measure whether behavior changed, we have shipped output but not created learning.

Facilitator Script

Growth engineering is not only marketing. It is product, engineering, data, and experimentation. Pick the product bet from the previous exercise. Now define the experiment and the evidence.

Exercise Prompt

For the manager dashboard example, define:

• Product metric: time saved, adoption, weekly usage, decision accuracy, reduced escalations.
• Engineering health metric: page load time, error rate, deployment confidence, support tickets, recovery path.
• Decision rule: scale, refine, or stop.

Good Example Answer

We will pilot the dashboard with five managers for two planning cycles. Product metric: 70% of pilot managers can identify top staffing risks within five minutes. Engineering health metric: dashboard loads under two seconds and creates no increase in support tickets. Decision: scale if both product and engineering metrics pass; refine if users need different metrics; stop if the workflow does not influence planning decisions.

Debrief Questions

• What product metric proves value?
• What engineering metric protects trust?
• What would make us stop or refine the idea?

Output

Each group shares:

• One product metric.
• One engineering health metric.
• One scale/refine/stop rule.

Heads-Up Message For Santosh

Santosh, I would like you to facilitate the Growth Engineering exercise. Please prepare one example where we built or released something but did not have a clear success metric afterward. Your role is to connect product bets to measurable experiments: product metric, engineering health metric, and scale/refine/stop rule. Please emphasize that growth engineering is product + engineering + data + experimentation, not just marketing.

Thinesh: Platform Friction Discussion

Where It Fits

Slide 16: Platform engineering makes growth experiments cheaper, safer, and repeatable.

What They Facilitate

They help the group identify repeated friction that should become reusable platform capability.

What To Prepare

Thinesh should prepare 2-3 real examples of repeated friction:

• Environment setup.
• Manual deployment.
• Missing logs.
• Inconsistent configuration.
• Access delays.
• Test data setup.
• No feature flags.
• No standard rollback path.
• Cost visibility gaps.

Suggested Talking Points

• Platform engineering is not a new bureaucracy.
• Platform is how we stop solving the same problem in every project.
• The platform should create golden paths that teams want to use.
• The first platform bets should come from repeated pain, not abstract ambition.

Facilitator Script

If every experiment requires custom setup, manual release, unclear logs, and late security review, experimentation becomes expensive. Platform work should reduce that friction. Let us identify one repeated friction we can remove.

Audience Question

What is one repeated friction every project pays for today?

Good Example Answer

Every new feature needs manual environment coordination and inconsistent logging. A reusable environment template and logging convention would reduce setup time and improve supportability.

Output

One platform candidate:

We should build/reuse capability because it reduces repeated friction and improves flow/trust/cost.

Heads-Up Message For Thinesh

Thinesh, I would like you to lead the platform friction discussion. Please prepare 2-3 examples of repeated friction we pay for across projects: environment setup, deployment, logging, access, test data, rollback, dashboards, cost visibility, or feature flags. Your role is to help the team see platform engineering as leverage, not bureaucracy. The key message is: build once, reuse often, measure always.

Raghu: Foundations And Build-Right Discussion

Where It Fits

Slides 17-18: Foundations for scale and build-right stack.

What They Facilitate

They help the team understand that quality is built into the workflow, not inspected at the end.

What To Prepare

Raghu should prepare one example where a defect or rework could have been prevented by earlier clarification, risk discussion, acceptance examples, testability, or observability.

Suggested Talking Points

• QA is not the department of late surprises.
• Quality starts with problem clarity and acceptance examples.
• Developers own testability.
• Stakeholders own clarity.
• Operations owns production signals.
• Performance, security, and observability must be designed into important flows.

Facilitator Script

When quality is late, everything becomes expensive. Let us identify where quality enters our workflow today and where it should enter earlier.

Audience Question

Where do we usually discover quality too late?

Good Example Answer

We often discover edge cases during QA because acceptance examples are too thin. For the next 30 days, every story should include three risk scenarios before development starts.

Output

One Definition of Done improvement:

For important work, done includes test/risk/observability/security/performance check.

Heads-Up Message For Raghu

Raghu, I would like you to lead the foundations/build-right discussion from the QA and quality angle. Please prepare one example where a defect, rework, or late surprise could have been prevented by earlier risk discussion, better acceptance examples, testability, or observability. Your key message is: QA is not the department of late surprises; quality is built into the workflow.

Uddipta: Engineering Discipline Field Note

Where It Fits

Slide 18 or Slide 23.

Duration

5-7 minutes.

What To Prepare

One real practice that improves speed and safety.

Suggested topics:

• Small PRs.
• Simple design.
• CI discipline.
• Code review quality.
• Testable code.
• Avoiding cleverness.
• Refactoring when it reduces cognitive load.

Suggested Script

One practice that helps us move faster safely is small PRs with clear intent. It reduces review time, makes testing easier, and lowers release risk. One behavior we should stop normalizing is large changes with unclear context. They look fast while being written, but they slow everyone during review, QA, and release.

Question To Ask Team

What makes code review slow for us today: size, unclear intent, missing tests, or hidden design decisions?

Heads-Up Message For Uddipta

Uddipta, I would like you to give a 5-7 minute field note on engineering discipline. Please prepare one real practice that makes us faster and safer, such as small PRs, simple design, CI discipline, better code review, or testable code. Also name one behavior we should stop normalizing, such as large unclear PRs, hidden design decisions, or code without enough test/context. Keep it practical and grounded in daily development.

Taladhwaja: Quality And DORA Field Note

Where It Fits

Slide 20: DORA metrics.

Duration

5-7 minutes.

What To Prepare

One example where flow or quality was affected by system constraints.

Suggested topics:

• Long lead time due to review delays.
• Change failure due to weak tests.
• Recovery delay due to missing logs.
• Deployment fear due to large batch size.

Suggested Script

DORA metrics should not be used to blame people. They help us see where the system is slow or fragile. If lead time is high, maybe reviews are slow, stories are too large, or environments are painful. If change failure is high, maybe tests or release checks are weak. The question is not "who caused it?" The question is "what constraint is visible?"

Question To Ask Team

Which DORA signal would help us most right now: lead time, deployment frequency, change failure, or recovery time?

Heads-Up Message For Taladhwaja

Taladhwaja, I would like you to give a 5-7 minute field note on quality and DORA. Please prepare one example where flow or quality was affected by a system constraint: review delay, weak tests, missing logs, risky deployment, large batch size, or slow recovery. Your key message is that DORA metrics are not for blaming people; they help us see where the system is slow or fragile.

Main Workshop: Product Incident Game

Where It Fits

Slide 24.

Who Should Facilitate

Main facilitator plus Gunjan and Santosh. If possible, ask Raghu to observe quality/risk answers and Thinesh to observe platform/operations answers.

Scenario

We shipped the requested feature. Users are confused. Performance is slow. Sales demo in two hours.

Group Roles

• Product/stakeholder: Was this the right problem?
• UX/design: Could users understand the flow?
• Developer: What complexity did we hide?
• QA: Which risk did we miss?
• IT/Ops: Can we observe and recover?
• Security: Any trust or data concern?

Instructions

Each group has 8-10 minutes to answer:

• What is the immediate mitigation?
• What evidence is missing?
• What did our system miss?
• What improvement should prevent repeat?

Good Answer

First reduce customer impact. Use feature flag, rollback, or mitigation. Communicate clearly to sales/support. Then review whether the feature solved the right problem. Add performance, usability, and risk checks to Definition of Done. Convert the incident into one product learning and one engineering improvement.

Debrief Questions

• Where would confusion happen in our real workflow?
• Which role would notice the issue first?
• What signal should have appeared earlier?
• What system improvement would prevent repeat?

Commitment Exercise

Where It Fits

Slide 25.

Who Should Facilitate

Gunjan, Santosh, Thinesh, Raghu, Uddipta, and Taladhwaja should each help one group produce a concrete 30-day commitment.

Instructions

Each team chooses:

• One behavior to start.
• One behavior to stop.
• One metric to watch.
• One experiment to run.
• One owner.
• One review date: July 25.

Good Examples

• Start: Every feature begins with problem, user, outcome, metric.
• Stop: Large PRs without review context.
• Measure: Activation plus lead time.
• Experiment: 30 days of smaller PRs and weekly evidence review.
• Owner: Team lead or nominated owner.
• Review: July 25.

Message To Send Team Leads Before The Session

Hi team,

For the June 25 annual-day session, I want you to participate as field facilitators, not as formal presenters. The goal is to make the session practical and grounded in our real work.

Please prepare a 5-7 minute contribution around your assigned topic:

• One real example from our work.
• One practice we should strengthen.
• One behavior we should stop normalizing.
• One question you want the team to reflect on.

The session theme is:

Customer signal -> product bet -> growth experiment -> platform leverage -> engineering execution -> secure reliable release -> evidence -> refinement.

Please keep your part crisp, practical, and connected to this loop. Avoid theory-only content. Use examples from real delivery, quality, platform, support, or stakeholder situations.

We are not trying to blame anyone. We are trying to build a shared operating language for how Simpro can become a high-performance product-engineering team.

Individual Heads-Up Summary

Gunjan

Topic: Product Bet Exercise.

Prepare:

• One example where a request came as a solution.
• How to convert it into user, problem, outcome, metric, and smallest experiment.
• One question: "What changed when we started with the problem instead of the screen?"

Santosh

Topic: Growth Engineering Exercise.

Prepare:

• One example where success was unclear because metrics were missing.
• One product metric and one engineering health metric.
• One question: "What would make us scale, refine, or stop this idea?"

Thinesh

Topic: Platform Friction Discussion.

Prepare:

• 2-3 examples of repeated delivery/platform friction.
• One platform candidate that could reduce repeated work.
• One question: "What friction should become reusable platform capability?"

Raghu

Topic: Foundations And Build-Right Discussion.

Prepare:

• One example of late defect/rework that could have been prevented earlier.
• One Definition of Done improvement.
• One question: "Where do we usually discover quality too late?"

Uddipta

Topic: Engineering Discipline Field Note.

Prepare:

• One engineering practice that improves speed and safety.
• One behavior to stop normalizing.
• One question: "What makes code review slow for us today?"

Taladhwaja

Topic: Quality And DORA Field Note.

Prepare:

• One example where system constraints affected quality or flow.
• Explain DORA as a conversation tool, not a blame tool.
• One question: "Which DORA signal would help us most right now?"