Tech Workplace Dictionary

Specific observable conditions that a change must satisfy to be accepted.

A specific follow-up task assigned to an owner with an expected outcome.

A concise record of an important architecture decision and the reasons behind it.

The documented inputs outputs behaviors and guarantees consumers can rely on from an API.

The proportion of time a system is accessible and able to serve its intended function.

The ability of a newer system version to keep working with older clients data or behavior.

The amount of time attention or working capacity a person or team has available.

Spending disproportionate time debating a simple issue while avoiding harder decisions.

The scope of systems users or functionality that could be affected by a failure or change.

An issue that prevents meaningful progress on a task or outcome.

To attempt an unnecessarily broad or nearly impossible scope all at once.

A change that requires existing consumers to modify how they use a system or interface.

Work performed within or around an existing system and its constraints.

The number of people whose loss would seriously threaten a project's continuity.

A structured examination of a code change by someone other than its author.

The degree to which responsibilities within a component belong together.

The degree to which one component depends on knowledge or behavior of another.

A sequence of processes that moves transforms and validates data from sources to destinations.

Something a task system or team relies on to complete its work.

The transfer of design intent assets behavior and context to the people implementing it.

A shared collection of design principles components patterns and standards for building consistent experiences.

A system whose components coordinate across multiple networked computers.

Using your own product internally to experience it as a real user would.

The one person primarily accountable for moving a specific outcome forward.

A manager responsible for the health effectiveness and delivery environment of an engineering team.

The amount of unreliability permitted while still meeting a service level objective.

A process that extracts data transforms it and loads the result into a target system.

An architecture where components publish and react to events about state changes.

A consistency model where replicas may temporarily differ but converge when updates stop.

A system's ability to continue operating when some components fail.

The gradual addition of features that makes a product more complex than its purpose requires.

A runtime switch that controls whether selected users receive a behavior or feature.

The recommended supported way to complete a common engineering task.

A system's ability to preserve its most important functions when part of it is impaired.

A project built without significant constraints from an existing implementation.

A period reserved for concentrated work with fewer meetings or interruptions.

An urgent narrowly scoped change made to correct a production problem.

The property that repeating the same operation has no additional unintended effect.

An unplanned event that degrades or interrupts a service or business operation.

A professional role focused on direct craft or domain contribution rather than people management.

The principle of granting only the access needed for a task and no more.

Work that appears relatively easy to complete for a useful benefit.

An architecture that divides a system into independently deployable services around capabilities.

An application whose major capabilities are deployed as one integrated unit.

The smallest product version that can test a meaningful assumption with real users.

The ability to understand a system's internal state from the signals it produces.

A rotation where designated people respond to urgent service issues outside normal planned work.

A recurring private meeting between two people often a manager and direct report.

Responsibility for driving an outcome including decisions follow-through and communication.

A well-supported technical path that makes preferred practices easier to adopt.

A retrospective document or meeting that records an incident's impact causes response and follow-up actions.

The work of reducing uncertainty about user problems solutions value and feasibility before or during delivery.

A preliminary model used to explore or test how a product or interaction might work.

A proposal to merge a set of code changes into another branch.

A required set of checks or criteria that must pass before work advances to the next stage.

A change that can deliver a visible useful result in a short time.

A structured investigation into the underlying conditions that produced an unwanted outcome.

A change to internal code structure that preserves its intended external behavior.

A previously working behavior that breaks after a change.

A test that checks existing behavior still works after a change.

The ability of a system to perform correctly and consistently over time.

A document that proposes a substantial change and invites review before a decision.

Reverting a deployment or change to a previously known state.

A documented procedure for diagnosing or handling a recurring operational situation.

A system's ability to handle increasing load without disproportionate cost or redesign.

Uncontrolled expansion of work after a project begins without corresponding tradeoffs.

To reduce the amount of work while preserving the most important outcome.

A classification of how much impact an incident or defect has.

A component whose failure can stop an entire critical system or workflow.

A meeting between an employee and a manager above their direct manager.

A measurement used to evaluate a specific aspect of service performance.

A target level of service performance measured over a defined period.

A small set of checks confirming that critical functionality works well enough for deeper testing.

To continue a discussion outside the current meeting thread or audience.

The future cost created when a team chooses a faster or simpler technical solution today.

A testing model favoring many fast focused tests and fewer broad end-to-end tests.

A structured description of assets attackers trust boundaries threats and mitigations for a system.

Manual repetitive operational work that scales with service growth and creates little lasting value.

A short description of desired value from the perspective of a user or stakeholder.

A weakness that can be exploited to compromise confidentiality integrity or availability.

A simplified representation of a screen's structure content and interaction without final visual detail.

The amount and mix of work assigned to a person team or system.

A chain of seemingly necessary side tasks that delays the original task.

A security approach that continuously verifies access instead of trusting requests based only on network location.