Simpro Knowledge Base

Annual Day Speech Draft V6 - EVOLVE 2026

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

Tone: serious, practical, optimistic, lightly humorous. This is written as a facilitator script, not a word-for-word speech to read mechanically. Use it as your safe runway: slow down, pause, ask questions, invite examples, and let the room think.

Suggested duration: 75-100 minutes depending on how much discussion you allow.

Session Rhythm

  • Opening and why now: 10-12 minutes.
  • Culture, ownership, team leads: 15-18 minutes.
  • Product and growth: 15-20 minutes.
  • Platform, engineering, security: 18-22 minutes.
  • Everyone's role and incident exercise: 15-20 minutes.
  • Commitment and close: 8-10 minutes.

Opening Setup

Before starting, set the expectation:

Today is not a lecture. I will speak, but I also want you to think. Some questions will not have a single perfect answer. That is the point. A high-performance team is not a team that always knows the answer immediately. It is a team that learns faster and hides less.

Optional warm line:

Also, if at any point you feel I am attacking your favorite process, please relax. I am probably attacking all of our favorite processes equally.

Slide 1 - EVOLVE 2026

Good morning everyone.

This image gives us today's theme: EVOLVE 2026 - building the next chapter together.

It has five simple words: innovate, collaborate, automate, grow, achieve. These words look good on a poster, but today I want us to treat them as working words.

Innovate does not mean random ideas every week. It means solving real problems in better ways.

Collaborate does not mean more meetings. It means fewer handoff losses and more shared understanding.

Automate does not mean replacing people. It means removing repeated friction so people can use their judgment where it matters.

Grow does not mean only revenue. It means growing capability, confidence, engineering maturity, customer value, and leadership depth.

Achieve does not mean looking busy. It means producing outcomes we can be proud of.

The phrase at the bottom is important: building the next chapter together. Not "management will build it." Not "developers will somehow build it." Not "QA will catch it later." Together.

Small story:

In software, every company eventually learns one lesson: tools can be bought, but habits have to be built. You can buy a cloud account, an AI tool, a CI/CD platform, a project management tool, and still move slowly if the habits are weak. Today is about those habits.

Pause:

So when I say EVOLVE, I do not mean changing everything. I mean keeping what is strong, removing what slows us down, and building the habits that make Simpro stronger.

Slide 2 - Why Now

Why are we talking about this now?

Because small teams today can do work that earlier needed much larger organizations. AI, cloud, open source, automation, and modern engineering platforms have reduced the cost of building serious products.

Ten or fifteen years ago, if a small company wanted enterprise-grade infrastructure, analytics, deployment automation, global hosting, and AI capability, it needed large budgets and large teams. Today, many of those capabilities are available almost immediately.

But there is a catch.

The bottleneck has shifted.

The problem is no longer only "Do we have access to technology?" The bigger question is:

  • Do we have clarity?
  • Do we have ownership?
  • Do we have quality discipline?
  • Do we learn from users?
  • Do we make decisions based on evidence?
  • Do we build systems that can be changed safely?

AI is a perfect example. AI is an amplifier. If our engineering habits are strong, AI can help us move faster. If our habits are weak, AI can help us create confusion faster, with better grammar.

Planned humor:

Earlier, bad code at least looked suspicious. Now bad code may arrive with a confident explanation and a very polite tone.

Serious point:

AI does not remove accountability. It increases the need for it. When tools become more powerful, judgment becomes more important.

Question to room:

Where do you think AI or automation can help us most immediately: coding, testing, documentation, operations, customer insight, or platform setup?

Best possible direction:

The best opportunities are repeated work with visible inputs and verifiable outputs: build failures, test generation, documentation updates, environment setup, log analysis, release notes, support-ticket clustering.

Slide 3 - Future Landscape

The future is not only software. It is software plus AI, hardware, devices, operations, security, data, and trust.

We will see:

  • AI-native development.
  • Multi-agent systems.
  • Physical AI.
  • Edge and local models.
  • Preemptive cybersecurity.
  • Digital provenance.

But we should be careful. Future trends are useful when they help us ask better questions. They become dangerous when we chase them without foundations.

Small story:

Many companies adopt technology the way people buy gym equipment in January. The purchase is exciting. The delivery is exciting. The first week is exciting. Then slowly the equipment becomes a very expensive clothes hanger.

The same thing happens in technology. A tool does not create transformation by itself. The team has to change the way it works.

So for Simpro, future-readiness means:

  • We scan trends.
  • We understand what matters.
  • We experiment safely.
  • We standardize what works.
  • We ignore what is noise.

Question:

What trend here feels most relevant to our work in the next 12 months?

Best possible answer:

AI-assisted development and secure automation are likely immediate. Edge/local AI, physical AI, and digital provenance may become relevant depending on product direction and customer problems.

Gartner's 2026 trends point to one message: AI needs foundations, orchestration, and trust.

The winning companies will not be the ones who say "AI" in every sentence. The winning companies will be the ones who have:

  • Clean data.
  • Secure systems.
  • Reliable platforms.
  • Good architecture.
  • Skilled teams.
  • Clear governance.
  • Fast learning loops.

This is important for us because it tells us not to panic. We do not have to chase everything.

Our strategy should be:

Build foundations that make future adoption easier.

For example:

  • If we want AI coding assistance, we need good code structure, tests, and review.
  • If we want AI operations support, we need logs, metrics, traces, and runbooks.
  • If we want growth engineering, we need product instrumentation and clean events.
  • If we want secure AI usage, we need data boundaries and governance.

Reflection:

Which foundation would unlock the most speed for us: platform, data, testing, security, observability, or product clarity?

Let people answer. Capture two or three themes.

Slide 5 - Executive Summary

The goal is not more process. The goal is a stronger operating system.

This sentence matters. Many companies respond to problems by adding process. A defect happens: add a form. A release fails: add an approval meeting. A requirement is unclear: add one more status call.

Sometimes process helps. But process without purpose becomes theater.

Our operating system should answer:

  • How do we decide what matters?
  • How do we convert customer signal into product work?
  • How do we build with quality?
  • How do we release safely?
  • How do we learn from evidence?
  • How do we improve the system?

The four ideas on the slide:

  1. Small team advantage.
  2. Culture as multiplier.
  3. Growth engineering as the connector.
  4. Team leads running the weekly loop.

Planned humor:

A process is useful when it helps good people do good work more consistently. It is not useful when it only helps us create beautiful evidence that we were confused in a very organized way.

Serious line:

We are not here to become busy. We are here to become effective.

Slide 6 - Story Spine

This is the song of the session.

Customer signal becomes a product bet.

The product bet becomes a growth experiment.

Engineering makes it real.

Security and reliability protect trust.

Evidence teaches us what to improve.

Then the loop begins again.

This is why I do not want us to think in disconnected departments.

Product without engineering becomes imagination.

Engineering without product becomes activity.

Security without delivery becomes a gate.

Delivery without security becomes risk.

Metrics without learning become decoration.

And meetings without decisions become... well, we all know what they become.

Pause for humor.

I will not name them. They know who they are.

Main point:

High-performance culture means the loop is healthy. Information moves. Decisions happen. Work gets smaller. Quality improves. Customers feel value. The team learns.

Question:

In our current work, where does this loop slow down most: signal, decision, engineering, release, measurement, or learning?

Best possible answer:

The answer may differ by team, but the improvement should be specific. "Communication" is too broad. "Requirements change after development starts because we did not validate the user problem" is useful.

Slide 7 - Culture Shift

This is the transformation: from ticket execution to outcome ownership.

An average team says:

Tell me what to build.

A high-performance team asks:

What problem are we solving, for whom, and how will we know it worked?

This does not mean developers must become product managers, QA must become sales, or IT must become design. It means each person understands how their work connects to value.

Example:

A ticket says: "Add export button."

Task mindset: "Where should the button go?"

Outcome mindset:

  • Who needs the export?
  • What decision will they make with it?
  • How large can the data be?
  • Does it contain sensitive information?
  • Should it be async?
  • Should it be audited?
  • How do we know it helped?

Same ticket. Very different thinking.

Question:

What is one example where a small clarification before coding could save a lot of rework?

Let one or two people respond.

Slide 8 - Agile As Behavior

Agile is not standup, sprint, Jira, and a few ceremonies wearing a badge.

The human side of Agile is values under pressure:

  • Commitment.
  • Focus.
  • Openness.
  • Respect.
  • Courage.

The real test is not whether we can say these words. The real test is what happens when:

  • The release is late.
  • A customer is unhappy.
  • A requirement is unclear.
  • A defect appears at the worst possible time.
  • Someone junior spots a risk.
  • Someone senior is wrong.

Agile works when truth moves quickly through the team.

Planned humor:

A standup where everyone says "yesterday I worked on my task, today I will continue, no blockers" is not Agile. It is a daily weather report from a very calm planet.

What we need is useful truth:

  • What changed?
  • What is risky?
  • What is stuck?
  • What decision is needed?
  • What should we learn?

Question:

What is one ceremony we already have that could become more valuable with better questions?

Best possible answer:

Standups, retrospectives, planning, demos, and reviews all become better when focused on flow, risk, decisions, and learning instead of status narration.

Slide 9 - Ownership

High performance needs psychological safety and accountability together.

Safety without accountability becomes comfort zone. People are nice, but follow-through is weak.

Accountability without safety becomes anxiety zone. People hide risk because they fear the reaction.

Low safety and low accountability becomes apathy zone. Nobody wants that.

The target is the learning zone: high standards without fear.

This means:

  • We can challenge ideas.
  • We can admit uncertainty.
  • We can surface bad news early.
  • We can ask for help.
  • We can still hold each other to commitments.

Important distinction:

Psychological safety does not mean "no pressure." It means "no fear of humiliation when speaking truth."

Accountability does not mean blame. It means ownership of action and outcome.

Question:

Which is more dangerous for us: people hiding problems, or people raising problems without ownership?

Best possible answer:

Both are dangerous. The ideal is: raise the problem early, bring context, propose options, and help solve it.

Slide 10 - Accountability Ladder

Ownership is a ladder.

At the bottom: "I was told."

Then: "I did my task."

Then: "I found the risk."

Then: "I proposed options."

Then: "I owned the outcome."

At the top: "I improved the system."

The highest level is important. If we solve the same problem five times, we have not solved it. We have only become experienced at suffering.

Examples:

  • A build fails repeatedly. Owning the outcome means fixing the flaky test or improving CI, not just rerunning.
  • A requirement keeps changing. Owning the outcome means improving discovery or acceptance criteria, not only complaining.
  • A deployment is scary. Owning the outcome means adding rollback, health checks, and observability.

Reflection:

Under pressure, where do we usually operate on this ladder?

Invite silent reflection first. Then ask for one example.

Slide 11 - Team Lead Loop

Team leads convert big intention into weekly behavior.

The loop is:

Context -> Commitment -> Action -> Evidence -> Refinement.

Context: why does this matter?

Commitment: what outcome are we choosing?

Action: what will we do this week?

Evidence: what changed?

Refinement: what should improve next?

This is how we avoid vague improvement.

Weak version:

We should improve quality.

Strong version:

This sprint, we will reduce escaped defects in this flow by adding three risk-based tests, reviewing unclear acceptance criteria before development, and checking production logs after release.

Invite Santosh here if useful:

Santosh, from a team-lead perspective, what is one place where weekly evidence would help us more than weekly status?

Best possible answer direction:

Evidence can be cycle time, defect pattern, rework reason, customer feedback, test stability, deployment issue, or blocked decision.

Slide 12 - Product Mindset

Building the right product means balancing three questions:

  • Desirable for users.
  • Viable for business.
  • Feasible with technology.

If we ignore desirability, we build things people do not use.

If we ignore viability, we build things that do not support the business.

If we ignore feasibility, we create promises that engineering and operations cannot sustain.

Product mindset is not only for product owners. Developers and QA often see feasibility and quality risks early. Operations sees support pain. Sales and stakeholders hear customer language. Everyone has part of the truth.

Story:

Many failed features do not fail because the team lacked effort. They fail because the team answered the wrong question very efficiently.

Question:

What is more dangerous: building the wrong thing perfectly, or building the right thing badly?

Best possible answer:

Both hurt. The discipline is to discover the right thing and build it with enough quality to create trust.

Slide 13 - Workshop: Product Bet

Exercise: turn a request into a product bet.

Request: "Build a manager dashboard."

That sounds clear, but it is not yet clear enough.

Ask:

  • Which manager?
  • What decision are they trying to make?
  • What problem are they facing today?
  • What outcome do we expect?
  • What metric proves improvement?
  • What is the smallest experiment?

Invite Gunjan here:

Gunjan, can you take this request and help convert it from "dashboard" into user, problem, outcome, metric, and smallest experiment?

Best possible answer example:

For operations managers who cannot quickly see delayed work, we believe a daily exception view will reduce manual follow-up time by 30%. We will test with one workflow, one team, and measure time saved plus usage.

Debrief:

The best answer starts with a human problem, not a screen.

Slide 14 - Growth Engineering

Growth engineering turns product thinking into measured learning.

It does not mean marketing tricks. It means connecting product usage, customer behavior, experiments, and engineering capability.

The loop:

  • Signal.
  • Hypothesis.
  • Experiment.
  • Release.
  • Measure.
  • Learn.

Example:

Signal: new users drop after setup.

Hypothesis: setup is too confusing.

Experiment: guided onboarding for one persona.

Measure: activation rate, time to first value, support tickets.

Learn: keep, change, or stop.

Planned humor:

Without measurement, every feature becomes a success in the meeting where it was approved.

Question:

What is one customer behavior we should measure better?

Best possible answer:

Activation, repeated usage, task completion, drop-off, feature adoption, support friction, or time to value.

Slide 15 - Measurement Bridge

Growth metrics and engineering metrics must talk to each other.

Product signals:

  • Activation.
  • Retention.
  • Adoption.
  • Conversion.
  • Support friction.

Engineering health:

  • Lead time.
  • Deployment frequency.
  • Change failure.
  • Recovery time.
  • Defect pattern.
  • Performance.
  • Reliability.

If product metrics improve but engineering health collapses, we are borrowing from the future.

If engineering metrics look good but customers do not receive value, we are optimizing the factory without checking whether anyone wants the product.

Question:

Which metric would help us have better conversations between product and engineering?

Best possible answer:

A paired metric: for example activation rate plus lead time, adoption plus defect rate, support tickets plus release changes, or conversion plus performance.

Slide 16 - Platform + Growth Strategy

Platform engineering makes growth experiments cheaper, safer, and repeatable.

If every team repeatedly solves setup, CI/CD, environments, deployment, security, logging, dashboards, and rollback from scratch, we are wasting energy.

Platform engineering gives golden paths:

  • Service templates.
  • CI/CD templates.
  • Environment setup.
  • Observability standards.
  • Security defaults.
  • Deployment and rollback patterns.
  • Developer self-service.

Growth engineering asks better product questions. Platform engineering makes answering those questions cheaper and safer.

Invite Thinesh here:

Thinesh, from a platform point of view, what is one repeated friction that we should convert into a reusable golden path?

Best possible answer direction:

Local setup, CI/CD, container templates, Kubernetes deployment, logging, monitoring, secrets, feature flags, or release notes.

Slide 17 - Foundations

Market leaders are not built only on big ideas. They are built on basics done consistently.

The basics:

  • Product clarity.
  • Quality.
  • Security.
  • Performance.
  • Reliability.
  • Cost control.
  • Observability.
  • Learning.

These are not boring. These are what allow speed.

Think of it like a building. The foundation is not the most glamorous part, but nobody wants an innovative 12th floor on a weak base.

Planned humor:

"Move fast and break things" sounds exciting until the thing broken is production, trust, or the monthly cloud bill.

Question:

Which foundation is strongest today, and which one needs the most attention?

Use quick hands or call for two answers.

Slide 18 - Engineering Excellence

Build it right means quality is stacked into the workflow.

Not at the end. Not after QA receives a surprise package. Not after production teaches us in public.

The stack:

  • Simple maintainable design.
  • Code review.
  • Tests.
  • CI/CD.
  • Performance and reliability.
  • Security and privacy.
  • Usability and accessibility.
  • Customer promise.

Invite Uddipta here:

Uddipta, from a senior developer perspective, what is one engineering habit that gives us speed later even if it feels slower today?

Best possible answer direction:

Small PRs, readable code, tests around risk, refactoring before complexity spreads, clear interfaces, reviewing assumptions, CI discipline.

Invite Raghu here or on next slide:

Raghu, from a QA perspective, where can quality move earlier instead of waiting at the end?

Best possible answer direction:

Acceptance criteria review, risk-based tests, exploratory testing earlier, testability discussion, automation for repeated checks, production feedback.

Slide 19 - Industry Practice

Fast release cultures reduce batch size, automate safety, and learn from production.

Companies like Flickr, Amazon, Netflix, and Etsy shaped many modern practices. We should not copy them blindly. We are not them. But we can learn the values behind their practices.

The values:

  • Smaller changes.
  • More automation.
  • Clear ownership.
  • Observability.
  • Fast rollback.
  • Learning from incidents.
  • Continuous improvement.

The lesson is not "deploy 100 times tomorrow." Please do not leave this room and frighten everyone.

The lesson is:

Smaller, safer, more observable changes beat large risky releases.

Question:

What prevents us from making smaller releases today?

Best possible answer:

Dependencies, manual testing, unclear requirements, environment friction, large batch planning, lack of feature flags, weak rollback, or approval bottlenecks.

Slide 20 - DORA Metrics

DORA metrics are a dashboard for conversation, not a stick for punishment.

Lead time: are we waiting too much?

Deployment frequency: can we release safely?

Change failure: are changes hurting users?

Recovery time: can we restore trust fast?

If a number is bad, the question is not "who is bad?"

The question is:

What system constraint is visible?

Examples:

  • Long lead time may show unclear requirements, review bottlenecks, or batch size.
  • Low deployment frequency may show release fear or manual process.
  • High change failure may show weak testing or poor risk detection.
  • Slow recovery may show weak observability or rollback.

Question:

Which DORA metric would be most useful for us to start discussing without blame?

Slide 21 - DevSecOps

DevSecOps means trust is designed, checked, released, and operated continuously.

Security is not a final inspection. It is part of design, code, build, test, release, and operations.

Planned humor:

Security at the end is like wearing a seatbelt after the accident. It may show good intention, but the timing is questionable.

What matters:

  • Threat thinking.
  • Code review.
  • Dependency scanning.
  • Secrets scanning.
  • Access control.
  • Secure configuration.
  • Logging and monitoring.
  • Certificate and key management.
  • Rollback and incident response.
  • AI data boundaries.

Invite Taladhwaja here:

Taladhwaja, from a senior engineering perspective, where do you think AI can help us in delivery, and where must human accountability stay strong?

Best possible answer direction:

AI can help with review, tests, documentation, log explanation, refactoring plans, and research. Humans must own architecture, security, production risk, customer impact, and final judgment.

Slide 22 - Everyone's Role

A product culture has no spectators.

Developer: simplicity, review, tests, observability.

QA: risk lens, exploratory testing, quality coaching.

IT admin: access, environments, resilience, automation.

Operations: flow, incidents, support signals.

Stakeholder: problem clarity, fast feedback, tradeoffs.

Team lead: context, commitments, evidence, refinement.

If value is shared, ownership must be shared.

Question:

Which role-to-role handoff creates the most delay or misunderstanding today?

Best possible answer:

The useful answer names a specific handoff: product to development, development to QA, QA to release, release to operations, support to product, stakeholder feedback to team planning.

Slide 23 - Workshop: Product Incident

Exercise: diagnose a product incident without blame.

Scenario:

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

Ask teams to discuss for 5-7 minutes:

  • Product: was this the right problem?
  • UX: could users understand the flow?
  • Dev: what complexity did we hide?
  • QA: which risk did we miss?
  • Ops: can we observe and recover?
  • Security: any trust or data concern?

Best possible response:

  1. Reduce immediate impact.
  2. Communicate clearly.
  3. Understand user pain.
  4. Inspect technical cause.
  5. Decide rollback/fix/workaround.
  6. Capture learning.
  7. Improve the system.

Debrief line:

Blame asks who to punish. Learning asks what to improve.

Slide 24 - Commitment

The session should end with a 30-day experiment.

Not a giant transformation program. Not a 40-page document. One practical operating experiment.

Ask each team to define:

  • Start: one behavior.
  • Stop: one habit.
  • Measure: one signal.
  • Experiment: one trial.
  • Review: one date.

Examples:

  • Start reviewing acceptance criteria before development.
  • Stop large PRs without reviewable boundaries.
  • Measure lead time from ready to production.
  • Experiment with one reusable service template.
  • Review on July 25.

Strong close for this slide:

One owner. One metric. One review date. Keep it small enough to actually happen.

Slide 25 - Close

High performance is not a slogan.

It is the habit of turning truth into improvement.

That is the line I want us to remember.

Truth about customer problems.

Truth about engineering quality.

Truth about security and reliability.

Truth about what is slow.

Truth about what is working.

Truth about what we need to learn.

Then improvement: not blame, not excuses, not ceremony for ceremony's sake. Improvement.

The rhythm is:

Context -> Commitment -> Action -> Evidence -> Refinement.

This is how Simpro evolves.

We innovate with purpose.

We collaborate with clarity.

We automate repeated friction.

We grow capability and customer value.

We achieve outcomes, not only activity.

Thank you. Let us build the next chapter together.

Facilitator Notes

Use these as optional participation points:

  • Gunjan: Slide 13, product-bet exercise. Prepare one real or realistic example where a request came as a solution instead of a problem.
  • Santosh: Slide 11, team-lead loop. Prepare one example of weekly evidence that would help more than status.
  • Thinesh: Slide 16, platform/growth strategy. Prepare one repeated developer friction that should become a golden path.
  • Raghu: Slide 18 or Slide 20, quality/DORA. Prepare one example of moving quality earlier.
  • Uddipta: Slide 18, engineering excellence. Prepare one habit like small PRs, simple design, CI, or code review that creates speed later.
  • Taladhwaja: Slide 21, DevSecOps/AI accountability. Prepare one example of AI helping delivery while human judgment remains essential.

Timing Tips

  • If short on time, reduce discussion on Slides 3, 4, 15, and 20.
  • Do not skip Slide 13, Slide 16, Slide 18, Slide 23, or Slide 24. These create participation and memory.
  • Keep humor light. Use it to relax the room, then return to the serious point.
  • Avoid reading every word on the slides. The slide is the anchor; your story is the bridge.