Simpro Knowledge Base Home

Simpro Knowledge Base Home visual map

Purpose

This wiki exists to tune the team toward a culture that is high-performing, curious, resilient, secure, product-minded, and accountable.

The goal is not to make people follow more ceremonies. The goal is to help teams understand value, make better decisions, learn faster, and own outcomes.

What We Are Building

We want teams that:

Understand the business and customer value behind the work.
Take ownership instead of waiting for instructions.
Use engineering discipline as a speed multiplier.
Learn continuously from users, incidents, metrics, research, competitors, open source, and experiments.
Use AI as an amplifier while protecting quality, security, and human understanding.
Balance innovation with reliability, privacy, safety, and cost.
Communicate clearly across engineering, product, design, operations, marketing, and sales.
Measure progress by outcomes, not activity.

Core Belief

High performance is a system. It is not a motivational speech, a tool purchase, or a process framework.

It emerges from:

Clear strategy and context.
Small empowered teams.
Strong engineering fundamentals.
Fast feedback loops.
Psychological safety with high accountability.
Reliable operations.
Customer discovery.
Visible metrics.
Learning rituals.
Leaders who model the behavior they expect.

Knowledge Domains

Domain	What Good Looks Like
Engineering	Small changes, clean architecture, test automation, code review, continuous delivery, measurable quality
Product	Clear outcomes, customer discovery, problem framing, prioritization by value and risk
Design	Human-centered research, prototype-first thinking, usability, accessibility, coherent experiences
AI	Practical copilots, local and edge inference where useful, governed AI agents, secure RAG, measurable productivity
DevSecOps	Security integrated into delivery, supply-chain visibility, automated checks, threat modeling, zero trust habits
SRE	SLOs, error budgets, observability, incident response, blameless postmortems, reliability ownership
Platform Engineering	Golden paths, self-service delivery, service ownership, secure defaults, reusable environments
Growth Engineering	Product instrumentation, activation metrics, experiments, adoption loops, responsible growth
Leadership	Context over control, coaching, clarity, decision discipline, change adoption
Go-to-market	Customer insight, positioning, revenue learning, product-led and sales-led coordination
Learning	Daily reading, demos, research notes, GitHub scanning, design/architecture trend reviews

Suggested Weekly Rhythm

Cadence	Ritual	Output
Daily	15-minute learning scan	One useful link, experiment, or insight per person or team
Twice weekly	Product/engineering sync	Decisions, risks, blockers, customer insight
Weekly	Tech radar review	Adopt, trial, assess, hold decisions
Weekly	Customer/discovery review	Opportunity tree, customer quotes, assumptions
Weekly	Reliability/security review	Incidents, SLOs, vulnerabilities, risky changes
Fortnightly	Demo day	Working software, learnings, data, tradeoffs
Monthly	Architecture council	Decisions, standards, platform debt, emerging trends
Quarterly	Strategy and operating review	Outcomes, bets, team topology, capability gaps

First 30 Days

Ask each team to read Operating Principles and Team Culture Playbook.
Identify each team's top three customer/business outcomes.
Define or refresh each team's service ownership map.
Pick one engineering baseline to improve: CI, test reliability, deployment frequency, incident response, observability, or code review quality.
Start the daily research ritual in Learning System.
Prepare the June 25 annual-day sessions in Annual Day Interactive Sessions.

Simpro Field Guide

Developer Help Pack

Gamified Learning Pack

Simpro Platform And Growth Engineering Pack

Team Reference Guide

How To Explain This Page

Use this page as a reference conversation, not as a checklist to read aloud. Start by explaining why the topic matters, then connect it to current team work, and finally ask what behavior should change.

The most useful way to teach this material is to move from concept to example. Explain the principle, show how it appears in daily work, ask the team where it is currently strong or weak, and finish with one small action.

Guidelines For Teams

Connect the topic to a current project, customer problem, incident, or decision.
Translate concepts into visible behaviors.
Keep the guidance lightweight enough to use weekly.
Capture decisions, examples, and improvements back into the wiki.
Review the page again after a project, incident, or retrospective to update what the team has learned.

Reflection Questions

What part of this topic is already working well for us?
What part is still mostly theory?
What is one behavior we can change in the next 30 days?