Context
The business
A regulated digital-finance company (lending, payments or device financing). Money moves, personal data is held and regulators ask for evidence.
Architecture · Reference operating model
The CTO operating model.
How he would structure, govern and run a technology organisation: who owns what, who decides, how work flows, how it is measured, and how a high-performance culture is built from mechanisms rather than slogans.
HypotheticalA reference model for a regulated digital-finance business. It describes no real organisation. Numbers are labelled Illustrative or Proposed.
Start from the assumptions, not the org chart.
An operating model is only right for a context. These are the assumptions behind this one, so they can be challenged.
Default
The stage
A scaling company: several squads, a first platform team, a security function and a data capability. The chart also shows the founding and multi-product variants.
Reality
The constraints
A competitive talent market, a finite budget, real vendor dependencies and a board that wants both growth and control.
What the model is designed to achieve
Predictable delivery
Small, frequent, safe changes, with clear ownership of every service.
Safe by default
Security, reliability and compliance built into the paved road.
Fast, clear decisions
Decisions made by the people with context, written down, and reversible where possible.
People who grow
A high bar, a clear ladder and a sustainable pace.
Structure and responsibilities.
Five functions under the CTO, with Product as a peer. Each box states what it owns, what it deliberately does not own, and who it works with.
Illustrative: roughly 25 to 80 in technology. The default model in this page. Squads aligned to domains, a platform team providing the paved road, security with independence, a data function, and a small architecture team. Product becomes a peer function with a standing partnership.
Peer, dotted line
Select any box for responsibilities, boundaries and interfaces. Scroll sideways on small screens.
Role
CTO
Sets technology strategy and is accountable to the CEO and board for what the technology organisation delivers: product delivery, reliability, security posture, cost and talent.
Owns
- Technology strategy, roadmap and budget
- Organisation design and senior hiring
- Architecture direction and the decision-rights model
- Strategic vendor and platform choices
- Engineering culture and the quality bar
Does not own
- Product priorities (Product decides what to build)
- Risk appetite (CEO and board set it)
- Day-to-day delivery choices inside a squad
Works with
- CEO and board
- Product leadership
- CFO (budget, unit economics)
- Risk and compliance
- Regulators, through the right owners
Typical roles
- CTO
Decision rights.
Who decides, who recommends, who is consulted and who can veto. Exactly one decider per row, and every decision sorted by how hard it is to reverse.
| Decision | Door | CEO / Board | CTO | Product | Engineering | Architecture | Security | Data & AI | Risk & Compliance | Squad |
|---|---|---|---|---|---|---|---|---|---|---|
| Technology strategy and annual budget | Two-way | D Decides | R Recommends | C Consulted | C Consulted | C Consulted | C Consulted | C Consulted | C Consulted | I Informed |
| Product priorities: what to build next | Two-way | C Consulted | C Consulted | D Decides | C Consulted | I Informed | C Consulted | C Consulted | C Consulted | C Consulted |
| Design inside a squad's own domain (libraries, internal structure) | Two-way | · Not involved | I Informed | I Informed | I Informed | C Consulted | C Consulted | · Not involved | · Not involved | D Decides |
| Hard-to-reverse technical choice (primary datastore, cloud provider, core platform) | One-way | I Informed | D Decides | C Consulted | C Consulted | R Recommends | V Veto on a guardrail | C Consulted | C Consulted | C Consulted |
| Build or buy for a regulated capability (KYC, payments, ledger) | One-way | C Consulted | D Decides | C Consulted | C Consulted | R Recommends | V Veto on a guardrail | C Consulted | V Veto on a guardrail | C Consulted |
| Routine production release | Two-way | · Not involved | I Informed | I Informed | I Informed | · Not involved | I Informed | · Not involved | · Not involved | D Decides |
| Emergency change or rollback during an incident | Two-way | · Not involved | I Informed | I Informed | I Informed | · Not involved | C Consulted | · Not involved | · Not involved | D Decides |
| Security exception inside risk appetite (time-boxed) | Two-way | I Informed | C Consulted | I Informed | C Consulted | · Not involved | D Decides | · Not involved | C Consulted | R Recommends |
| Risk acceptance beyond agreed appetite | Gated | D Decides | C Consulted | I Informed | I Informed | · Not involved | R Recommends | · Not involved | C Consulted | · Not involved |
| Credit, fraud or AI model go-live | Gated | I Informed | C Consulted | C Consulted | C Consulted | · Not involved | C Consulted | R Recommends | D Decides | · Not involved |
| Data access policy exception | Gated | · Not involved | I Informed | · Not involved | · Not involved | · Not involved | V Veto on a guardrail | D Decides | C Consulted | · Not involved |
| Capacity share for reliability and technical debt (within an agreed envelope) | Two-way | I Informed | D Decides | C Consulted | R Recommends | C Consulted | C Consulted | C Consulted | · Not involved | C Consulted |
| Senior hire (lead and above) | One-way | C Consulted | D Decides | C Consulted | R Recommends | · Not involved | · Not involved | · Not involved | · Not involved | · Not involved |
| Retiring a production system | One-way | I Informed | D Decides | C Consulted | C Consulted | R Recommends | C Consulted | C Consulted | C Consulted | R Recommends |
- DDecides (exactly one per row)
- RRecommends
- CConsulted before the decision
- VVeto on a defined guardrail (must explain in writing)
- IInformed after
How decisions are made
- Decide at the lowest level that has the context and the accountability.
- Sort decisions by reversibility. Two-way doors are made quickly by the people doing the work. One-way doors get a written proposal, a short review and a named decider.
- Disagree and commit. Once a decision is recorded, everyone executes it, and the decision is revisited only on new evidence.
- Escalate fast. A decision stuck for more than two working days (Proposed) goes to the next level with both positions written down.
- Every decision with lasting consequence is written down: what, why, who decided, what would change our mind.
Engineering standards.
Standards are delivered as code: templates, pipelines and checks that make the right way the easy way. A standard that exists only as a document is a wish.
| Standard | What it means | How it is enforced |
|---|---|---|
| Small changes, trunk-based | Short-lived branches, small pull requests merged to a protected main many times a day. | Branch protection, PR size nudges in CI |
| Review with teeth where it matters | Code owners review every change. Money, authentication, cryptography and data-access paths need a second senior reviewer. | CODEOWNERS, protected paths |
| Tests are part of the change | New behaviour ships with tests. Money logic has golden-file and property-based tests. Contract tests guard every provider and internal API. | CI gates, coverage on changed lines, contract test suite |
| Security gates in the pipeline | Secret scanning, static analysis, dependency and container scanning on every build. New high-severity findings block the merge. | Blocking pipeline stages, SBOM per build |
| Contract-first APIs and idempotent money endpoints | APIs are designed from a written contract, versioned, and backward compatible. Every state-changing money endpoint accepts an idempotency key. | OpenAPI linting, contract tests, endpoint checklist |
| Observable by default | Every service ships request metrics, structured logs with a correlation ID, traces and an SLO before it takes customer traffic. | Service template, production readiness review |
| Infrastructure as code only | No manual changes in production. Environments are declared, reviewed and reproducible. | Drift detection, policy-as-code, restricted console access |
| Safe data changes | Schema changes follow expand-and-contract so they are backward compatible. Personal data is tagged and never written to logs. | Migration linting, log scanning, data classification tags |
| Decisions and runbooks are written | Significant decisions get an ADR. Every alert has a runbook. Every service has a named owning team. | Service catalogue completeness check |
| Production readiness before launch | A short checklist covers SLOs, alerts, runbooks, rollback, capacity, security review and data protection before first customer traffic. | Readiness review recorded in the service catalogue |
| Definition of done includes operating it | Done means shipped, observable, documented for on-call, and reversible. Not merged. | Team working agreement, sampled in retros |
Delivery methodology.
Principles over ceremony. Squads own the whole flow from shaping to operating, and the pipeline provides the evidence regulators and risk teams need.
Step 1 of 7
Discover and shape
Product, design and the tech lead frame the problem, explore options and set a small, bounded bet with a clear outcome. Technical risks are surfaced here, not at the end.
Operating principles
- No single methodology is sacred. Squads choose practices from a small menu, but the outcomes (flow, quality, predictability) are common.
- Regulated change is handled by evidence, not queues. Standard changes that pass the pipeline are pre-approved. Unusual or high-risk changes get a lightweight review. Emergency changes are allowed with after-the-fact review.
- Roadmaps commit to outcomes for the current quarter and to options beyond it. Dates are promised only where the uncertainty is low.
- Measure flow, not busyness. Lead time, deployment frequency, change failure rate and time to restore tell the truth. Velocity points and lines of code do not.
The rhythm of the organisation
| When | What | Purpose | Owner |
|---|---|---|---|
| Daily | Squad stand-up or written update | Unblock work and share what changed. | Squad |
| Weekly | Architecture forum (45 minutes, decisions only) | Decide one-way-door proposals within a working week. | Architecture |
| Weekly | Reliability review | SLO burn, incidents, alert quality and on-call load. | SRE |
| Weekly | Security triage | New findings, exceptions and vulnerability SLA breaches. | Security |
| Every two weeks | Squad planning, demo and retrospective | Plan thin slices, show working software, improve the way of working. | Squad trio |
| Monthly | Technology leadership review | KPIs, risk register, cost, hiring and people health. | CTO |
| Monthly | Product and engineering roadmap sync | Trade-offs, dependencies and capacity. | Product and Engineering |
| Quarterly | OKR planning and review | Set and score outcome goals; agree the capacity envelope. | CTO and Product |
| Quarterly | Recovery exercise and tabletop | Prove failover, restores and incident response work. | SRE and Security |
| Quarterly | Risk committee report | Independent view of technology and security risk. | Security and GRC |
| Yearly | Strategy, budget and penetration test | Reset direction, fund it, test it independently. | CTO |
KPIs and OKRs.
Two different tools. KPIs say whether the engine is healthy. OKRs say what we are changing this quarter.
KPIs
Standing health measures that are always on. They tell us whether the engine is healthy. They change slowly and they are reviewed monthly.
OKRs
A small set of outcome goals for a quarter that change something: an Objective that inspires and Key Results that can be measured. They are reviewed in the month and scored at the end.
KPI families Proposed KPIs
Definitions only. No values appear because there is no real company data. Each family notes how it is commonly misused, which is where good measurement design shows.
Delivery
- Deployment frequency. How often changes reach production.
- Lead time for changes. Commit to production.
- Change failure rate. Share of changes needing remediation.
- Time to restore. How fast service returns after a failure.
Watch for: Frequency gamed by trivial deploys. Always read it with change failure rate.
Reliability
- SLO attainment on critical journeys. Onboarding, decision, payment, repayment.
- Incidents by severity. Trend and repeat causes.
- Time to detect and to resolve. MTTD and MTTR.
Watch for: Counting incidents can punish honest reporting. Track learning actions closed, not only counts.
Quality
- Escaped defects. Issues found by customers rather than by us.
- Flaky test rate. Trust in the pipeline.
- Rework share. Capacity spent redoing work.
Watch for: Coverage percentages can be gamed. Prefer escaped defects.
Security
- Vulnerability SLA compliance. Critical issues closed within the agreed time.
- MFA and privileged access coverage. No exceptions without expiry.
- Access review completion. Done on time, with removals.
Watch for: Open-finding counts reward not looking. Measure time to remediate.
Cost and efficiency
- Cloud cost per transaction or per active loan. Unit economics, not just the bill.
- Vendor spend against plan. With renewal calendar.
Watch for: Cutting cost can hide risk. Pair with reliability and security.
People and culture
- Regretted attrition. Losing people we wanted to keep.
- Time to first production deploy for new hires. Onboarding quality.
- Engagement pulse and on-call load. Sustainable pace.
Watch for: Do not use survey scores to rank managers. Use them to find problems.
A quarter of OKRs Illustrative
Objective
Make money movement boringly reliable
- Scheduled-collection success rate: [baseline] to [target]
- Reconciliation breaks older than two working days: [baseline] to [target]
- Complete a Tier 0 failover exercise with ledger integrity verified: pass
Objective
Ship faster without shipping riskier
- Lead time for changes: [baseline] to [target]
- Change failure rate stays at or below [baseline]
- Share of services on the paved-road pipeline: [baseline] to 100 percent
Objective
Build a team people want to join and stay in
- Time to first production deploy for new engineers: [baseline] to [target]
- Regretted attrition at or below [target]
- Every service has a named owner and a healthy on-call rota
How OKRs are run
- Three to five objectives per level. If everything is a priority, nothing is.
- Key results measure outcomes, not output. "Launch X" is a task, not a result.
- Targets come from baselines measured in the first 30 days. The brackets above are deliberate: no numbers are invented.
- Aim for ambitious. Scoring around 70 percent means the goal was set about right.
- OKRs are separate from individual performance reviews, so people set honest goals.
- Cascade by alignment, not by copying: company outcomes, technology outcomes, then team outcomes that contribute to them.
Architecture governance.
Light, fast and written down. The aim is coherent technical direction without a committee that slows every team.
Step 1 of 6
Propose
Anyone writes a short proposal: context, options, recommendation, what would change our mind. A template makes this a page, not a project.
The mechanisms
Architecture decision records
Short, versioned and stored next to the code. Status: proposed, accepted, superseded. The history is the memory of the organisation.
Architecture forum
Weekly, 45 minutes, open attendance, decision-only. Proposals are read beforehand. If a proposal needs a workshop, it is run separately.
Technology radar
Adopt, trial, assess, hold, reviewed quarterly. It tells teams what is safe to use without asking.
Reference architectures and templates
Paved roads for the common cases: a service, a data pipeline, a provider adapter. Deviation is allowed with a recorded reason.
Exceptions register
Every deviation has an owner, a reason and an expiry date. Expired exceptions come back to the forum.
Fitness functions
Automated checks for module boundaries, dependency rules, latency budgets and data-classification rules, run on every build.
Incident management.
Clear severity, clear roles, fast declaration and honest learning. The aim is to restore service first and understand it second.
| Severity | What it means | Response |
|---|---|---|
| SEV1 Critical | Customer funds or personal data at risk, or a core journey (onboarding, decision, payment, repayment) is unavailable for most customers. | Immediate page. Incident commander and communications lead assigned. Executive sponsor informed. Legal and Compliance join at declaration. Regular status updates. |
| SEV2 Major | Significant degradation of a core journey, a major provider path down, or a serious security finding without confirmed exposure. | Page the owning squad. Incident commander assigned. Customer-support briefing. Updates at an agreed interval. |
| SEV3 Minor | Limited impact or a workaround exists. A non-critical feature is affected. | Handled in working hours by the owning squad. Tracked and reviewed weekly. |
| SEV4 Low | No customer impact. Early warning, noise or a latent defect. | Ticketed and prioritised like any other work. |
Roles
Incident commander
Runs the response and makes decisions. Does not debug. Authority comes from the role, not from seniority.
Operations lead
Directs the technical investigation and mitigation.
Communications lead
Owns updates to customers, support, executives and, with Legal, regulators.
Scribe
Keeps the timeline. It becomes the raw material for the review.
Executive sponsor
Clears obstacles and makes business trade-offs for SEV1 events.
Lifecycle
Step 1 of 7
Detect
Symptom-based alerts on customer journeys, plus reports from support, merchants and providers.
Principles
- Blameless is not consequence-free. We separate learning from performance management, and we still hold people accountable for repeated disregard of agreed practice.
- Error budgets are policy. When a critical journey exhausts its budget, feature work on that service pauses in favour of reliability until it recovers. The CTO and Product agree this in advance.
- Security incidents and data events follow the same structure with Security leading, Legal and the data protection officer engaged at declaration, and regulatory clocks tracked explicitly.
- Exercises are part of the system: a quarterly game day or tabletop proves that the plan works and that people know their roles.
Security governance.
Security is a partner to delivery with the standing to say no, and a view of the truth that does not depend on the people it is checking.
Independence
The head of security has a line to the CEO or risk committee so that technology risk can be challenged without conflict with delivery.
Risk appetite and acceptance
The board states appetite in plain terms. Risks within appetite are accepted by the security lead with expiry dates. Risks beyond appetite are accepted only by the CEO.
Secure by default
Secure templates, pipeline gates, managed identity and secrets mean the safe way is the easy way. Security engineers build the paved road.
Security champions
Each squad has a trained champion who raises the baseline and is the first point of contact. Champions are recognised in levelling.
Assurance
Independent penetration testing yearly and after major change. Control testing is automated where possible and evidence is collected continuously.
Third-party risk
Vendors are tiered by data and criticality. Higher tiers need due diligence, contractual controls, monitoring and an exit plan.
Access governance
Quarterly review of privileged access (monthly for the most sensitive). Just-in-time elevation. Joiner, mover and leaver is automated with HR.
Reporting
A quarterly report to the risk committee and board: top risks, trend lines, exceptions, incidents and the state of the controls, in decision-ready language.
Three lines of assurance
First line
Squads and platform teams
Own and operate the controls in the course of delivery.
Second line
Security, GRC, Risk and Compliance
Set standards, monitor and challenge, advise and report independently.
Third line
Internal audit and external assurance
Give independent assurance to the board that the system works as described.
Product and engineering collaboration.
The partnership that decides whether a technology organisation feels fast or slow. It is written down as working agreements, not left to goodwill.
Trio ownership
Every squad is led by a trio of product manager, designer and tech lead who share one outcome goal. Disagreements are resolved by evidence first.
One backlog, no side doors
All work, including reliability, security and debt, is visible in one prioritised backlog. Requests do not bypass it.
Outcomes over output
Squads are measured against outcomes (for example payment success rate) and not against the number of features shipped.
Roadmap in horizons
Now (committed), next (probable) and later (options). Dates are promised for now only.
Engineers in discovery
Tech leads and engineers join customer research and shaping, so options are shaped by what is feasible and risky from the start.
Escalation path
If the trio cannot agree, both positions go to the CTO and Product lead in writing and are decided within two working days (Proposed).
Capacity: a negotiated envelope Proposed
Majority of capacity
Product outcomes
New value for customers and the business.
A protected share
Reliability and technical debt
Paying down risk and keeping the platform healthy. Tied to error budgets.
A planned share
Enablement and compliance
Platform improvements, regulatory change, security work.
Proposed starting point: agree the envelope with Product each quarter, using the data (error budget burn, lead time, incident load) and not opinion. Percentages are deliberately not fixed here because the right split depends on the company's stage and risk.
What each side can expect
Product can expect from Engineering
- Honest estimates and early warning of risk
- Options with trade-offs, not only a yes or no
- Predictable delivery of what was committed
- Operating what we build
Engineering can expect from Product
- A clear problem and outcome, not a feature list
- Protection of the agreed reliability and debt capacity
- Prompt decisions and prioritisation
- Shared accountability for outcomes, including when they miss
A high-performance culture, by mechanism.
Culture is what a team does when nobody is watching, and it follows what the system rewards. So each value here is paired with the mechanism that makes it true and the signal that shows whether it is working.
| Value | Mechanism that makes it true | Signal it is working |
|---|---|---|
| Ownership | You build it, you run it. A service catalogue with a named owner for every service and an on-call rota. | No orphaned services; incidents are owned in minutes. |
| High bar | Structured interviews with scorecards, a work sample, a bar-raiser from outside the hiring team, and a published level framework with calibrated promotions. | Offer acceptance and 12-month retention of new hires; quality of promotion cases. |
| Quality | Production readiness reviews, blameless post-incident reviews, error budgets and a Definition of Done that includes operating it. | Escaped defects and repeat incidents trend down. |
| Learning | ADRs and open design reviews, internal guilds, a learning budget, and incident reviews shared company-wide. | People cite decision records; the same mistake does not recur. |
| Transparency | Internal roadmap, KPI dashboards visible to everyone, and decisions written down with the reasons. | Fewer surprises in leadership reviews; questions answered by reading. |
| Psychological safety with accountability | Blameless reviews, regular one-to-ones, direct feedback training, and clear handling of repeated disregard of practice. | People raise problems early; incident reports are filed quickly. |
| Sustainable pace | On-call load limits, fair rotation, time off after major incidents, and burnout signals reviewed monthly. | On-call load is evenly spread; engagement pulse is stable. |
| Fast start | Onboarding plan with a buddy, a working environment on day one and a first production deploy in the first week. | Time to first production deploy for new hires. |
| Fairness and inclusion | Structured hiring, published pay bands, calibrated reviews and a mentoring programme. | Pay, promotion and attrition patterns reviewed for disparities. |
Rolling it out.
Change the model gradually and visibly. Introduce decision rights and incident management first, since they remove the most friction. Avoid reorganising and re-platforming in the same quarter.
Days 1 to 30
Listen and baseline
- Interview leaders and engineers; map the real structure and decisions
- Measure the four delivery metrics and incident history
- Inventory services, owners and on-call
- Fix the worst pain: unclear ownership, missing runbooks, no incident process
Days 31 to 60
Write the rules down
- Publish decision rights and the severity model
- Stand up the incident process and the architecture forum
- Agree the security line of reporting and risk appetite with the CEO
- Draft standards as templates and pipeline checks
Days 61 to 90
Start the cadence
- Run the first OKR cycle from measured baselines
- Hold the first game day and the first blameless review
- Launch the level framework and hiring scorecards
- Report the first KPI pack to the leadership team
See this model applied to a concrete platform in the Digital Device Financing Platform case study, or return to all architecture work.