Tech maturity self-assessment

Dimension 1 of 5

Delivery & Flow

How work reaches a customer, and what it costs you to get it there.

About you

Four questions, and they are the only ones that are for us rather than for you. They are what lets your answers join a segment later — skip them and you still get everything above. Region rather than country, because a comparison needs a group large enough that no single company can be picked out of it: we ask at this level and group upwards when we publish. It is the region of the business you are assessing, not where you happen to be sitting.

Industry

People

Region

Your role

Where you stand

Free, and yours whether or not you sign in.

Dimension

Leaders

You

Laggards

Delivery & Flow

—

not yet

—

Architecture & Technical Health

—

not yet

—

Data & Decisions

—

not yet

—

Ways of Working

—

not yet

—

Leadership & Investment

—

not yet

—

Held backThe Leaders and Laggards columns stay hidden until you have finished. A benchmark on screen while you rate yourself changes how you rate yourself — and these numbers are only worth having if they are what you actually think.

Answer something in every dimension to compare against the benchmark.

Your levels, the comparison and your weakest capabilities are free. What needs an account is the written report — how to climb from the rung you are on to the next one, for every answer above.

The written report

How to climb from the rung you are on to the next one, for every answer you gave, with the three weakest first. It is yours to keep, print and forward.

The report is not available from this deployment. Everything above still works — nothing was sent anywhere.

What a level means

The same rungs apply to every capability in the model. They describe what a level costs you or earns you — not which documents you keep. Generally, you never want to sit on L1 as easy to slide downward. L5 is a market level leadership, an almost absolute advantage over peers, generally L3 is a very strong standing organization.

L1Firefighting

Day-to-day changes rapidly on incoming signals, everyone is reactive instead of proactive as no bandwidth left for it. Downward spiral hard to break.

L2Contained

Issues and failures can be put out with known solution but they repeatedly recur. Bleeding is stabilised, but the organisation not yet self-improving if acting on this level.

L3Predictable

Business as usual, operating on this level keeps employee satisfaction and creativity flowing with enough buffer to handle unforeseen issues and occasional stretch challenges.

L4Compounding

Each action taken improves the organisation permanently, regression unlikely to occur until practice followed.

L5Advantage

Impact recognised as competitive advantage on market level. Organisation performs outstandingly even among peers.

The model in full

5 dimensions, 29 capabilities, one scale of 5 impact levels. This is the whole instrument, published — you can read it, argue with it and quote it without answering anything.

Scroll the table sideways for the levels. The first three columns stay put.

				Impact levels
				(1) Firefighting	(2) Contained	(3) Predictable	(4) Compounding	(5) Advantage
Dimension	Sub-dimension	Label	Statement	Day-to-day changes rapidly on incoming signals, everyone is reactive instead of proactive as no bandwidth left for it. Downward spiral hard to break.	Issues and failures can be put out with known solution but they repeatedly recur. Bleeding is stabilised, but the organisation not yet self-improving if acting on this level.	Business as usual, operating on this level keeps employee satisfaction and creativity flowing with enough buffer to handle unforeseen issues and occasional stretch challenges.	Each action taken improves the organisation permanently, regression unlikely to occur until practice followed.	Impact recognised as competitive advantage on market level. Organisation performs outstandingly even among peers.
Delivery & Flowprocess		Delivery & Flow`delivery`	A change we agree on today reaches a customer predictably, without heroics.	Each change to the system risks downtime, delays all dates and estimations with no learning attached while DM requests overwrite daily multiple times any plans.	Contained changes can be released on a regular cadence with release windows, private requests surfaces to the backlog and real bandwidth becomes visible while dates missed with reasoning recorded.	Frequent but batched releases inside teams, items waiting are visible cross-team, backlog has precedence over DMs, yet members still work on tasks without the business goal in precedence.	Team members are autonomous given their business goal to reach, can release minor changes easily, still coordination required for features, bottlenecks dealt with permanently.	Changes released by each member autonomously without risk of downtime, in order to fulfil their business goals, and act on feedback in real time.
Delivery & Flow	Release & deployment	Release & deployment`delivery.release`	Getting a finished change into production is a routine event rather than a decision.	Every change risks the system to fail and go into downtime.	Certain contained changes can be released independently while most wait for a release window.	Release practiced weekly, independent teams and components without causing downtime can be pushed to production with team coordination.	Autonomous teams release and roll back as deemed on their product line, decision owned by product owner, execution steps are automated.	Autonomous engineers release and roll back as deemed independently on their work, no manual step throughout.
Delivery & Flow	Release & deployment	Release cadence`delivery.release.cadence`	We release when the work is ready, not when a release window allows it.	Releases are scheduled events that need people to stay late.	Releases are well practiced but still require a window of feature freeze due to workload.	A weekly or fortnightly release goes out without anyone watching it.	Number of releases can launch in a day without impact to downtime.	Releasing is so unremarkable that nobody can tell you when the last one was.
Delivery & Flow	Release & deployment	Lead time for a one-line change`delivery.release.leadtime`	A one-line change agreed this morning could be in front of a customer today.	Every line change needs multiple hand-overs, reviews and takes days to weeks to get to customer's hands.	Delivery lead and product lead can decide on release packages (feature sets) among themselves.	Line changes categorised by risk and low-risk ones can get to customers in hours to days.	Changes are contained so even senior engineers can release to production without hiccups.	Changes are automatically verified against risk and ownerships, a push gets to customers in minutes with 4-eye principle.
Delivery & Flow	Release & deployment	Undoing a bad release`delivery.release.rollback`	A release that turns out to be wrong can be taken back in minutes, by whoever noticed.	Each failure recovery is manual with downtime incurred on the system.	Recovery is scripted but still executed at least one step or test manually, downtime of the component probable.	Rollbacks are planned checklists executed automatically with successful smoke tests.	Rollbacks only affect the failed component, not complete system.	Rollback is rare and fully automatic whenever noticed.
Delivery & Flow	Flow & predictability	Flow & predictability`delivery.flow`	Work moves through the organisation at a rate we can describe and plan against.	Direct messages take precedence over aligned goals and actions, dates never taken seriously and never adjusted afterward.	Private requests surfaced to the backlog for priority, bandwidth is visible. Most estimates still missed but with recorded reasoning.	Each item is estimated or timeboxed, dependencies visible at least on blocked state and on whom, raising visibility of inter-person or inter-team bottlenecks.	Teams estimate for velocity and plannable workload, not for performance evaluations. Each colleague knows their one goal at any given time, yet backlog is still pruned regularly.	Deadlines focus for regulatory needs, each team member focuses on a clear business goal at a time and results are monitored, actions adjusted real time.
Delivery & Flow	Flow & predictability	Work in progress`delivery.flow.wip`	People finish what they start before picking up the next thing.	Every team member has more than one open ticket, or unknown what they are working on right now, DM requests take precedence.	DMs lead to new items in the backlog, prioritised and pulled in to work in progress when bandwidth becomes available.	One item with no business goal directly attached yet at any moment being worked on, waiting on others forces items to be in blocked with a reasoning on whom it waits.	Strictly one goal per people at any given moment, yet backlog grows more than bandwidth ever can handle requiring regular pruning.	Only one currently open business goal per person is in progress, everything timeboxed and DMs can wait until next window of opportunity, instead of continuous context switching eating into bandwidth.
Delivery & Flow	Flow & predictability	Dates we give outside the team`delivery.flow.commitments`	When we tell the business a date, the business is right to believe it.	No dates ever met, deadlines are merely suggestions nobody takes seriously. Never learn to adjust future estimations.	Most dates are missed with reasoning recorded by the original estimator to learn adjusting new estimations.	Estimations, timeboxes and deadlines are clearly marked with falsifiable conditions, there is a record of changing with reasoning if ever necessary.	Teams estimate their own work and velocity tracked as indicator of bandwidth, not as performance for evaluations.	Deadlines are only for legal and regulatory needs, business goals are continuously monitored and adjusted real-time.
Architecture & Technical Healthtech		Architecture & Technical Health`architecture`	We can change one part of the system without holding our breath.	Production issues can't be replicated easily, code owners are unknown or hard to track down, IT budget is a single line for the CTO.	One static staging environment at least available but not updated with new data. Loss of system triggers alerts while individual errors fly under radar. Services and platforms have active owners. Tech debt only comes up in missed deadlines, never proactively. A few categories of tech spending is followed, monthly active users is best scaling data available.	At least one production-like env for testing actively maintained, manual gates assist mostly automated builds and alerts in place for systemic issues. Components have accountable owners and tech debt is tracked but falls often in priority. Cost followed on at least monthly basis with scaling estimates.	On-demand environments for feature testing, release is a business decision, individual issues visible to accountable owners. Complexity lowered is celebrated without capability loss, component owners actively improve their boundaries. Major architecture decisions track their cost-benefit with granular data.	Autonomous deployments to production, all individual errors automatically accounted for by each line of code's accountable owner. Tech debt is regularly approached, a cost value driver tree is available to drill down for anyone.
Architecture & Technical Health	Foundations	Foundations`architecture.foundations`	The machinery underneath a change — environments, pipelines, signals — is what we build and own, not just survive.	Can't replicate production issues without production, mostly manual actions to publish even the smallest change and if any issues arise, only the users can tell.	One staging environment built once from copying production, deployment is at least a repeatable script and collection of checklists. Total loss of systems will trigger alerts but individual errors remain under radar.	At least one production-like test environment with generated data available for partly automated deployments. Systemic issues don't go unnoticed until user reports come in.	On-demand environment available for feature testing, release to production is a business decisions rather than technical and even individual issues are raised automatically for accountable owner.	Publish to production has zero manual actions after code merged, quality ensured through multiple prod-like stages and any errors immediately known by the team to act upon.
Architecture & Technical Health	Foundations	Environments and test data`architecture.foundations.environments`	There is somewhere other than production that behaves like production.	There is one environment that resembles production, and it is production.	One environment was built once by scripts to copy and anonymise production, it was never synced after.	Environments are rebuilt from the repository and test data is generated, not copied.	On-demand environment from scripts built and torn down as feature testing requires.	Multiple environments closely simulating production, components are tested in production without negative consequences.
Architecture & Technical Health	Foundations	Build, test and deploy automation`architecture.foundations.automation`	Getting from a merged change to a deployable artefact needs nobody's attention.	Most steps are manually executed to create the new artifact, manual bump of versions for the smallest change needed.	Deployment is repeatable script and checklist with improvements and fixes regularly updated.	Manual gates applied during mostly automated process, signage or keyed builds are still manual on scheduled time-window.	Release is a business decision, not a technical one anymore, rollback is a manual trigger but fully scripted to recover.	Zero manual actions from merge to published artifact, new version in hands of a subset of clients, automatic roll-out to all clients or automatic roll-back if regressions detected in time window.
Architecture & Technical Health	Foundations	Knowing something is wrong`architecture.foundations.observability`	We find out that something has broken before a customer tells us.	If our system is down or a user has any error, we only know if the users write to one of our contact addresses.	Total loss of major systems will trigger alerts even if not immediately, occasionnally a review of individual errors conducted.	Systemic issues trigger alerts early, such as downtime is known for on-call personnel, but individual user issues can still go occasionally unnoticed until report.	Individual issues always notify the team with a responsible person acting immediately to reach out.	Any critical errors trigger an alert to our team same time the client sees the error, we have trends and alerts in place to even predict systemic issues and start fixing.
Architecture & Technical Health	Structure & boundaries	Structure & boundaries`architecture.structure`	The shape of the system lets two teams work without waiting for each other.	Hard or impossible to connect code to active accountable owner, tech debt is only in the feelings, undocumented, unaddressed.	Larger boundaries such as services or platforms have always active owners. Tech debt or complexity comes as reaction to failed deadlines only, never proactively.	Components have accountable owners easy to track down for fixing issues, tech debt is part of the backlog management process.	Celebrate complexity lowered without capability lost, component owners proactively improve their boundaries.	Each line of code has accountable owner, easy to connect with and tech debt is quantified, permanent part of scope to pay it down.
Architecture & Technical Health	Structure & boundaries	Service boundaries`architecture.structure.boundaries`	Every substantial component has exactly one team that owns it.	Most code is not owned by a current organisation member or components can't be traced to active maintainer at any given time.	Services and platforms have owners always available and on-call for any issues.	Components have owners and most of the time they are easy to track down and get a hold on if issues arise.	Component owners actively improve their responsibilities, reaching out on problems and putting out best practices.	Every line of code is owned by exactly one accountable person and its is no effort to track down who is it, easy to get a hold off them even if it is not an emergency.
Architecture & Technical Health	Structure & boundaries	Technical debt`architecture.structure.debt`	The shortcuts in the system were taken deliberately, are written down, and have an owner.	Tech debt is talked about with feelings instead of a record, often mentioned rewriting but no known consequences documented.	Tech debt comes only as reaction to failed deadline expectations, initiatives drafted but hardly acted upon.	Tech debt, decisions taken are recorded as part of the backlog but unowned and still can be cut from sprint scope if bandwidth is stretched.	Tech debt payback is uncuttable part of sprint scope and celebrated success when complexity is removed without capability loss.	Tech debt is ledgered, well known, quantified and regularly acted upon by accountable person, resolving them permanently is part of business as usual.
Architecture & Technical Health	Economics	Economics`architecture.economics`	What the system costs to run is a number somebody owns and can change.	IT is a single budget line in the financials and only the CTO has a top line knowledge for hosting and tooling costs.	Only a few categories of tech spending collected in aggregates, monthly active user data is the best granular scaling available.	Irregular variable costs calculated from monthly invoices and usage estimations, CTO and engineering leaders can break down cost structure on demand.	Major architecture decisions clearly tracked to cost-benefit using invoice line items and granular data collected from scaling metrics.	Value driver tree can be pulled up for all hosting, tooling and subscription, per component and per team, as detailed inventory at any moment, with decision deadlines and accountable owner included.
Architecture & Technical Health	Economics	Cost per environment`architecture.economics.runcost`	We can say what one environment costs us per month, and who decides whether it is worth it.	Hosting versus IT costs can be deduced if work put into reviewing the invoices.	Few major tech spending cateogories followed in aggregate only.	Cloud and on-premise hosting provides clear numbers for at least each environment.	Major architecture decisions tracked to invoice line-items and corrected based on cost-benefit values.	Running cost controls on cloud billing, running cost tables on all environment per components is accessible.
Architecture & Technical Health	Economics	Cost of scaling`architecture.economics.scaling`	We can calculate how our infrastructure cost scales with user count and traffic volume.	Usage, bandwidth and related scaling data is unavailable or untracked.	Monthly active user data collected in aggregate chunks, invoices filed without correlation.	Monthly scaling data cross referenced with invoices at least to provide a sense of variable costs.	Granular data collected for both scaling and component throughputs, reporting is batched into monthly chunks.	Granular usage data is cross-referenced with granular costs of hosting and scaled component counts.
Data & Decisionstech		Data & Decisions`data`	A decision we make this quarter rests on figures we all agree are right.	Metrics don't mean the same for different members or teams, business objectives are too vague to connect to metrics and user private data is unknown where stored and untraced who access it.	Common metrics vocabulary, analytics improved proactively, post-mortems start to appear but roadmaps still fit to a single Gantt chart. All data handled the same way as it could be a privacy risk, system level audit logs enabled.	Teams can follow their metrics and structure them to business goals based on their interpretation. Data fields are inventoried and assessed, access trace can be pulled for investigations but not proactive alerting.	Centralised metrics vocabulary and data inventory with regular awareness trainings and updates conducted. Roadmap solidified from bottom-up mitigations, and reacts to falsified assumptions.	Business objectives clearly connected to metrics that are transparent and means the same to all company members. Every data field is catalogued and anomalous access alerts cybersecurity.
Data & Decisions	Trust in the numbers	Trust in the numbers`data.foundations`	The same question asked twice, by two people, gets the same answer.	Metrics named similarly mean widely different things, data access and new instrumentation takes long process to acquire, while business objectives remain too vague.	Common metrics become vocabulary, data governance established, proactive analytics improvements centrally, outputs controlled. High level KPIs start to track but individual performance can't be factored in yet.	Metrics are defined on team level, but can match to business goals based on interpretation. Data can be easily pulled by anyone while a new instrumentation still takes some time to deploy.	Centralised metrics vocabulary in versioned editions, anyone can propose new instrumentation that goes to live in weeks. Metrics clearly feed into KPIs that falsify or support business objectives.	Business objectives clearly broken down to well-defined metrics, no two numbers named same when they are not defined the same way, and a new metric or instrumentations takes no time to be live. Each metric supports clear business goals directly.
Data & Decisions	Trust in the numbers	Agreed definitions`data.foundations.definitions`	Two teams reporting the same metric produce the same number.	Same named metrics defined differently by teams and individuals, e.g. active user means multiple things and result in multiple numbers even pulled at the same time.	Commonly used metrics have a single dictionary available for employees on how to understand them. Pulling data still left to interpretation.	Metrics are uniquely defined on the team level and a basic dictionary is in place to match them to organisation level.	Organisation has centralised metrics and playbooks on how to understand them into versioned editions.	Each metric named and published for all with one definition, resulting in same numbers even if pulled by different teams or people (live single source of truth).
Data & Decisions	Trust in the numbers	Answering a new question`data.foundations.access`	A question nobody has asked before can be answered from data within days.	A new metric introduced means new analytics instrumentation to be deployed over months. A.k.a. company members need long process to get new analytics data available for themselves.	Data governance established to proactivey improve analytics collection while data access still restricted to processed outputs, dashboards and slide decks prepared by a few.	A new question, new compound metric that works from existing data can be asked by anyone and pulled immediately. A.k.a. company members all can access and read existing analytics data.	Anyone can propose new instrumentation and it takes a data governance weeks maximum to get it to production.	A new metric even if instrumentation needed is available in days to pull real data to answer the question. A.k.a. company members can propose and deploy new instrumentation ad-hoc.
Data & Decisions	Trust in the numbers	Clear objectives`data.foundations.okrs`	Our business objectives and key performance indicators are clear for everyone and measurable at any time.	Business objectives are vague, unspecific, such as "increase revenue" or "cut costs".	Revenue and cost targets broken down to a few high level KPIs such as active user count, cart values, but individual performance can't be tracked to factor in.	Business uses OKRs or similar frameworks to clarify goals for its teams, but not yet broken down to how metrics clearly feed into them, leaving space for (mis)interpretation.	Metrics feed into KPIs that show progress on falsifiable objectives on dashboards. KPIs are balanced against purely profit driven numbers.	Everyone individually is clear on business metrics and how they move the business objective for current period.
Data & Decisions	Decisions	Decisions`data.governance`	How a decision gets made is something a newcomer could describe after a month. Decisions based on hard data and evidence, assumptions tested regularly.	No alternatives in the plan, no time budget for delays or wrong assumptions. If any data or delay disproves assumptions, plan can't change, overtime or other drastic solution dropped on the problem.	Roadmap still fits on a gantt chart with risks listed as a side-note, mitigations can't change plans fully. Assumptions still uncovered late in project lifecycle, but early post-mortems appear due to individual initiatives.	Roadmap outlines multiple directions and how early tests could switch between, driven top-down and project deadlines still can move with experimental outcomes.	Roadmap solidified with domain experts bottom-up mitigations, previously failed experiments feed into new hypothesis, post-mortems required and enforced organizationally.	Roadmap contains alternatives, plan Bs and priority driven rather than deadlines. Steering it by early and frequent data avoids surprises, when assumptions tested negative, plans change with no drama.
Data & Decisions	Decisions	How a roadmap decision gets made`data.governance.roadmap`	What we build next is decided against evidence, in a way the people affected can see.	Roadmap is a single timeline of deadlines with guesses and unclear scope definition. What steering decisions is the deadline closing in and moving people around with no basis what helps unblocking. Unsyndicated private email threads contain most decisions.	Roadmap present on a gantt chart lists risks and gaps as a side comment. Mitigations don't count with changing plans.	Roadmap has a few directions outlined depending on early assumptions tested and failed, mitigation options come from top-down.	Roadmap directions outlined and solidified with bottom-up mitigation strategies included from domain experts.	Roadmap consists of well-defined capabilities to deliver by priority order and not deadlines/timeslots. Steering decisions is the expert input from short experiment runs on key falsifiable assumptions. Any change in prio is organisation-wide communicated immediately.
Data & Decisions	Decisions	When evidence contradicts the plan`data.governance.evidence`	A number that disagrees with the plan changes the plan rather than the number.	Underlying assumptions remain untested for long time, when delay or data arrives late, the decision held up however unrealistic it is, forcing overtime or reorganisation of efforts instead of changing priorities or deadlines.	Assumptions uncovered late in project lifecycle leading to knock-on delays on dependencies, first post-mortem documentations emerge on individual efforts.	Each project starts with top key assumptions to be tested as early as possible, project deadlines can move based on outcomes of these experiments.	Previously failed experiments can be revisited if conditions change and new assumptions and hypothesis drawn from outcomes. Post-mortems required to close projects or products and part of their plans.	Assumptions and estimations tested early and frequently, negative outcome is openly documented and syndicated, resulting in priority changes without panic or remorse.
Data & Decisions	Data protection & risk	Data protection & risk`data.protection`	Where customer data is, and who can reach it, is known rather than assumed.	Unknown for the organisation what and where stored about users private data, who exactly accessed what is untracked.	At least all data handled as it could be a privacy risk, organisation border triggers warnings, basic audit logs tell who accessed what systems.	Data fields are inventoried and assessed at important stages but not continuously, sensitive field access is logged and can be tracked when investigation requires it.	Data governance is proactive at cataloguing and risk assessments, regular trainings for employees. Case-by-case alerts for sensitive data access, record level audit stored.	Every field of data is catalogued, risk-assessed and sensitive fields guarded by granular access, suspicious behaviour triggers internal alerts.
Data & Decisions	Data protection & risk	Where customer data lives`data.protection.handling`	We could say today which systems hold customer data and who has access to each.	Fields in databases or files can hold user private data without organisation knowing where to look for them. Duplications are frequent with no reference to master data.	All databases handled as it could hold private data, basic processes in place to support employees at secure storage and sharing inside organisation. Org border triggers warnings for sharing anything.	At major project lifecycle events the data fields are reviewed and risk classified, snapshot of inventory is on file. Duplications happen, but tracked with regular reviews.	Data governance regularly and proactively maintains data inventory and risk classifications, runs regular awareness raising for employees.	No data field exists without a central inventory and classification of user privacy level, review is regular and comprehensive.
Data & Decisions	Data protection & risk	Tracking data access`data.protection.forensics`	We could track who access what data exactly when and for what reasons, we can detect data breaches before leaks happen.	Unauthorised access to data only known by public or user reports after leakage, no trace anywhere what access can reach what data fields.	Basic audit logs avilable for limited time of who accessed what system and when, but no granular information of specific data sets.	Each sensitive or risk-related field access is logged and can be pulled when necessary for investigations to be conclusive.	Case-by-case alerting in place for sensitive data or fields accessed or modified, audit fields present in all tables where matters, created, updated, deleted identities are stored on record level.	Sensitive fields are guarded by granular access schemes (record and field), frequency or other suspicious behaviour triggers active alerts for internal investigations.
Ways of Workingpeople		Ways of Working`ways`	If two named people were away for a month, the work would carry on.	Colleague departure amounts to incidents, no incident is learned from, they recur without documentation and teams don't follow feedback on their shipped changes.	Key employees retained for their knowledge known for the organisation, onboarding is checklisted. Individuals push post-mortems irregularly and product talks to customers unstructured.	Critical employees shadowed regularly, DRP/BCP updated. A new joiner gets premade onboarding packages and pushes value to prod in weeks. Blameless post-mortems championed, user feedbacks aggregated and structured.	Knowledge documentation is part of performance evaluations. A new engineer joins on Monday, pushes to production by Friday. Incident rates are organizational metrics just as user feedbacks.	Departure of a colleague is a no event, SoPs are well documented, recovery is a checklist not a scramble and each shipped change requires metrics and feedbacks before deemed done.
Ways of Working	Knowledge	Knowledge`ways.knowledge`	What the organisation knows outlives the people who learned it.	Named colleagues departure equals an incident, institutational knowledge walks out the door undocumented, new joiners left alone to figure out all by themselves.	Key employees retained based on their knowledge, an onboarding is based on checklists and key contacts.	Critical operations shadowed by multiple colleagues, DRP/BCP regularly updated. A new joiner gets a premade package to onboard with, can push value to production in weeks.	Knowledge documentations are part of business-as-usual and performance discussions. A new engineer joins on Monday pushes value to production by Friday.	Colleagues can outgrow the company without negative side-effects, all standard ops documented with easy to follow hierarchy for new onboarders. New joiners deliver meaningful code in hours to production without an incident.
Ways of Working	Knowledge	Knowledge transfer`ways.knowledge.transfer`	What only one person knows is written down where the next person will find it.	Only named colleagues can unblock a production deployment or a systemic fix, no written documentation about the how.	Key employees and their knowledge is mapped and identified for appropriate retention steps.	Each critical operations has multiple colleagues shadowing regularly limiting probability of loss for organisation. DRP/BCP documentations regularly updated as part of product work.	Knowledge documentations are part of individual performance indicators and outstanding performance celebrated.	Standard operation procedures are documented in an easy to search hierarchy, handbooks describe all process from first code commit to more complex problems solved. Infrastructure is exhaustively documented, DRP/BCP regularly practiced.
Ways of Working	Knowledge	Onboarding`ways.knowledge.onboarding`	A new engineer ships something real in their first fortnight.	No documentation and no task to give to any new onboarding team member, months go by and no-one knows what they delivered.	A checklist of access, device, etc. to provide to new joiners with contacts to key staff to assist.	New engineer gets a package of onboarding documentation including company up-to-date strategy, organised onboarding sessions and can push new value to production in a few weeks.	A new engineer joins on Monday pushes valuable impact to production by Friday with no risk of an incident.	A new engineer joins the morning, in a day they deliver their first meaningful contribution to production.
Ways of Working	Learning	Learning`ways.learning`	The same problem does not arrive twice without somebody noticing that it has.	Incidents present no learning opportunity and they recur, team shipped changes to production without knowing what its feedback is and how it moved the metrics or business goals.	Individuals push for post-mortems but undersupported to find deep root causes. Product owners talk with users unstructured, user research focuses on immediate questions.	Blameless post-mortems allow learning and stop recurring issues by organisation's focus. User feedbacks aggregated and interpreted, user research structured.	Incident rates becomes organizational metric, design runs focus groups with long-term validation before implementation costs locked in.	Changes are not done on production deployment, all follow-ups proactive, granular and documented, post-mortems raise permanent fixes executives care for.
Ways of Working	Learning	What happens after an incident`ways.learning.incidents`	After an incident, the cause identified and resolution gets an owner and a date — not just the symptom.	Post-mortems not documented or run, or irregularly. Incidents are handled on the go with no playbook to reach for.	Post-mortems run on individual efforts by those involved in the fixing, root causes still remain vague and next steps are not owned.	Post-mortems led by executives blamelessly and findings are owned by the organisation.	Incident rates are part of business metrics but individual performance is not tied to them in any capacity.	Incident post-mortems owned and resulting action items followed-up by executives making sure they not repeat ever as part of their KPIs.
Ways of Working	Learning	Finding out whether a change worked`ways.learning.feedback`	We know whether the last thing we shipped did what it was meant to do.	Team who shipped doesn't know the metrics nor feedback directly related to their changes.	Product owners regularly talk with customers in an unstructured manner. Design runs user research for immediate problems at hand.	Aggregate feedbacks are collected and interpreted onto a history of changes. User research is more structured with medium term validations included.	Design focus groups ran for specific hypothesis and experimentation before implementation costs are locked in.	Each shipped change followed up in customer surveys or metrics, defined already in the change, it is not done until feedback verified or disproved at least on assumption in the change.
Leadership & Investmentpeople		Leadership & Investment`leadership`	Technology spend is argued in business terms, not defended as a cost line.	Top-down micromanagement without basis in data or metrics, short term wins every time over next quarter. Tech decisions routinely overruled by non-tech executives and team organised around arbitrary numbers rather than product needs. Product delivery isn't padded for upskilling, seniors utilised maximum on shipping.	Owner acts as investor to initiatives with napkin math, fiscal plans get outdated fast. Tech decisions made by top technologist and respected while in budget, while teams drop working capabilities to focus on shifting priorities. Delivery eats growth opportunities.	Bottom up recommendations adjust budgets, long-term investments avoid direct cash-flow impacts. Team can steer tech decisions bottom-up on a forum, standardised budgets support individual growth with trainings and conferences.	Executives act as investor to initiatives, long-term project budgets well protected. Multi-level budgeting allows low level decision making and self-reorganisation. Workload explicitly supports individual growth plans.	Initiatives decided based on their merit, not source, healthy reinvestment into long term growth. Tech decisions as low as possible, execs remain on policy and teams organise around product. Senior talent under-utilised helping growing others, budgets available for all staff upskilling.
Leadership & Investment	Investment	Investment`leadership.investment`	Money spent on technology is spent against an argument somebody signed.	Tenure and position wins investment debates, always focus to current quarter or immediate short term.	Owner acts as strategic investor armed with napkin math, a yearly fiscal plan organised that is outdated in matter of months.	Costs and budgets adjusted based on data and recommendations traveling upward in hierarchy. Long term investments are separated in budget to avoid cash-flow impacts in short term.	Executives are strategic investors inside the organisation and long term projects are walled by strategic priorities.	Write-ups of detailed business plan above certain budget drives objective decisions. Organisation performance reinvested for long-term operational health.
Leadership & Investment	Investment	How an investment is justified`leadership.investment.case`	A technology investment is argued in terms of what the business gets, with impact quantified.	Executives and owners argue on next actions without data or prognosis available, tenure and hierarchy wins debates.	Owner invests into initiatives with napkin math beyond industry intuition, executives ensure implementation.	Executives and directors make data based recommendations to operation cost and initiative budget adjustments with board/CEO setting final decision.	Executives act as investors of strategic initiatives and sponsor business cases written up by managers.	Data driven structured business case write-ups for any decisions above a certain budget level, below the closest person to the action has autonomy, e.g. dev tooling until certain budget is selected by the developer.
Leadership & Investment	Investment	Beyond the current quarter`leadership.investment.horizon`	Something is funded this year whose return arrives after this year.	No-one has time to think of the next quarter, let alone fiscal year, all of backlog is for immediate fixes and changes, deadlines always loom right ahead.	Once a year there is a fiscal planning for the next year, yet its output is usually out of sync with reality in a few months.	Business-as-usual and long-term investments clearly separated, budget of year long projects don't get drained by overruns or cash flow issues.	Long-term projects strongly protected by strategic priorities, only last resort to touch their budget for unforeseen fiscal events.	Healthy chunk of organizational performance is reinvested into long-term returns, e.g. developer experience tooling, device upgrades, training and conferences, etc.
Leadership & Investment	Ownership & accountability	Ownership & accountability`leadership.ownership`	Decisions have owners, and the owners are close enough to the work to make them.	Technical decisions are not owned by technical staff, their ownership ends on arbitrary dates and project boundaries rather then product usage proven by users.	Tech decisions made by CTO or top of technology organisation adhered to. Team collaboration moves onto more hotter topics as organisation focus shifts, dropping working capabilities sometimes.	Team can steer tech decisions from bottom-up and remain responsible for shipped feature throughout its full lifecycle until usage veins.	Multi-level budgeting allows employees to make decisions on their level, bet on product capabilities and being supported in bottom-up reorganisation along product.	Tech decisions born at the lowest level possible, top-down policy setting only, teams organise around proven product needs and individual staffing moved by professional growth goals.
Leadership & Investment	Ownership & accountability	Who can say no`leadership.ownership.decisions`	A technical decision can be made and closed by the people who will live with it.	Technical decisions routinely overruled by top executives outside of tech line.	Tech decisions stop with the CTO or top leader of the technology organisation with tech background while related decisions still box them in.	Teams have a platform to discuss and steer tech decisions from bottom-up where regularly get answers to their questions to rather top-down decisions still.	Adequate budgeting enables employees to make low-scale, impactful decisions on their level.	Technical decisions pushed down the chain as much as possible, tech executives set policy, not architecture.
Leadership & Investment	Ownership & accountability	Products, not projects`leadership.ownership.teams`	A team stays with what it built after the launch.	Team collaboration ends on preset dates or with executive reorganisations of staff rather than product needs.	Team collaboration on mature product capabilities start to vain as organisation focus shifts, appears in employee's performance as lagging in stale environment.	Team remains responsible of shipped features and components until real usage goes through, size and capability organised around statistics by executives top-down.	Team owns impactful decisions to reinvigorate product capabilities suffering dropping usage, supported at folding it into other team or capability with no adverse effect on individual performance.	Teams organise around product capabilities based on goals and needs proven, staff moves with individual growth goals rather then arbitrary deadlines.
Leadership & Investment	Capability building	Capability building`leadership.capability`	People grow at their jobs because we planned for it.	Product delivery doesn't plan any buffer for imperfect skill levels to deliver, seniors over-utilised, no budget available for outside the job learning opportunities.	Delivery still regularly overruns that eats into growth plans and opportunities, strict budgets available for conferences and trainings for certain profiles.	Standardised buffers set into estimations, best effort opportunities to learn planned after major milestones with set budgets per employee.	Explicit discussion of individual growth plans are part of work, buffers exist on project level to provide opportunity with set budgets for the team.	Senior talent deliberately under-utilised to provide for cross-profile growth, employees and contractors both supported on individual growth with budget.
Leadership & Investment	Capability building	Deliberate upskilling`leadership.capability.growth`	There is time and money budgeted for people to learn the skills we will need next year.	No budget set for conferences, trainings or any outside of daily work for employees.	Set budget for employees to use on conferences and trainings strictly related to their profile.	Set budget for employees to use on conferences and trainings strictly related to their profile, exceptions for adjacent skills can be obtained case by case.	Set budget for teams to use on conferences and trainings as team events.	Employees and contractors have set budgets for both time and cost quarterly to spend on conferences and trainings adjacent to their profile.
Leadership & Investment	Capability building	Opportunity to grow`leadership.capability.opportunity`	There is enough buffer in product work to allow learning on the job for staff.	Product delivery plans assume the best skill always delivering in their lane.	Delivery assumes light buffer, overruns handled by cutting small scope, learning mostly understood during tasks that have to be done nonetheless.	Rule of thumb buffers set into estimations, best effort but easy to cut learning opportunities, mostly planned shortly after major milestones.	At project kick-off or regularly on product work, individual growth plans are discussed explicitly, buffers understood on project level.	Every product delivery counts in individual growth plans and provides for safe on-the-job learning by under-utilising senior talent.