Definition of Key Elements
The Better Managed Development (BMD) organization will employ the following elements in a well-managed governance context
Components
A component is a process, tool or named human role that can be dedicated to a specific culturally relevant function. Examples of components include
- A regularly scheduled meeting like Daily Standups or Retrospectives
- A tool like a linter, IDE or Applications Performance Monitoring platform like Splunk or Datadog
- A named role like a Scrum Master, Network Operations Center (NOC) operator
Components have the following characteristics
- Components are specialized in their purpose and function
- Components have distinct identifiers and names
- Components cannot be the products, goods or services that enterprise sells to the end user or customer
- Components emit signals - measurable and observable states that give an indication of how they’re functioning or not. The absence of a signal from a component is itself a signal
- A component that doesn’t emit any signals is likely culturally irrelevant. This could be as a result of irregularity (e.g., a “process” that’s executed as a one-time occurrence isn’t culturally relevant)
Capabilities
A capability is a grouping of related components. This way, an organization can develop a catalog of specific capabilities that are available to be invested toward the delivery of any number of Cultural Outcomes. A culturally effective organization will be able to deliberately itemize and document all its capabilities and their related components in a specific place that is visible to all interested parties.
Examples of Capabilities could include
- “Security” to capture all the people, processes and tools that the organization engages to securely operate and deliver value to their customers
- “Developer Experience” to describe all the people, processes and tools - components - that the enterprise can leverage to provide a smooth and productive work environment for their individual contributors
- “Skillset Engineering” to group all the components that an organization will deploy to match individuals, their skill sets, and the team or organization’s needs.
Capabilities have the following characteristics
- A capability cannot be the products, goods or services that the organization provides its end users or customers
- A capability must be clearly and narrowly defined with little opportunity for confusion or ambiguity
- A capability can share components with another capability. That is, a component can feature within more than one capability e.g. a process that serves multiple purposes.
Signals
Signals refer to discrete points of data that represent a quality or quantity of a component at a given point in time. With Signals, we can then continuously observe the state of components by capturing the signals emitted by the component over a span of time.
Let’s take an Agile process like Retrospectives for example. We can think of a Retrospective as a component/process that has the following properties
- Operation: is the Retrospective process occurring? How frequently? Each occurrence of the retrospective can be thought of as a signal. This signal can thus be captured over a span of time to measure the commitment to the retrospective process
- Positive Feedback: How much positive reflection occurs in the retrospective (a.k.a the “What did we do well?” portion of a standard retrospective)
- Critical Feedback: How much critical feedback arises in the course of the retrospective (a.k.a the “What could we have done better?” portion of a standard retrospective)
With these example signal captured across departments and pivoted along reporting lines, we can observe the quality or effectiveness of the retrospective process across an org.
Signals have the following properties
- A signal can measure only one aspect of a component or capability i.e. should be very narrowly defined
- A signal should be captured only with regard to the leader that’s accountable for the part of the organization that’s producing the signal
- A signal is immutable
- The absence of signal is a signal by itself
- Signals are neutral per se i.e. they should not exhibit any directionality for the purposes of decision-making
Outcomes (Cultural Outcomes)
The Outcome is the topmost unit of organization in the BMD enterprise. An Outcome is a short statement that defines a desirable cultural aim. Examples of cultural outcomes include
- “Employees are encouraged to experiment and innovate”
- “Employees are encouraged to grow professionally”
- “Pull requests are typically reviewed within 24 hours of opening during the business week”
- “Our deployment pipelines maintain a minimal rate of failure”
- “Teams maintain ownership and accountability of specific code repositories as stewards”
- “We will maintain a Mean Time to Restore (MTTR) typically less than an hour”
Outcomes are already a fixture of the healthcare industry, serving as the key tool for observing the impacts that healthcare operations have on different interested parties (patients, medical providers, insurance carriers, regulatory bodies etc.). The Outcome is the simplest way to provide structure and framing for otherwise intangible and nebulous aims and strategic imperatives.
An outcome has the following characteristics
- Outcomes do not have an end date. Thinking of technical Outcomes like “Maintain continuous operational practices related to security”, or non-technical ones like “Individual contributors remain engaged with the company’s mission”, you will see that at no point can an enterprise claim “we have achieved security” or “we have completed developer engagement”. This gives outcomes the unique ability to allow decision makers to maintain a long-term perspective without sacrificing the short- and medium-term needs.
- Outcomes do not have a completion status. Unlike other common units of deliverables like Objectives, Key Results, Milestones, To-dos, tasks etc., Outcomes are not subjected to completion states.
- Outcomes do not have a fixed target that once achieved will result in the “completion” of the Outcome
- All other deliverables in the organization - Objectives, Key Results, Milestones, To-dos, Initiatives - all are subordinate to the Outcome.
- Outcomes exist, whether the enterprise is aware of them or not.
- Outcomes are defined and measured entirely by the signals that are emitted by their associated components
It is important to not conflate Outcomes with other types of deliverables (e.g. Objectives, Milestones etc). Outcomes are necessarily open-ended, narrowly defined and will not ever be “achieved”.
The Outcome therefore, is measured or observe by way of the signals attached to the components and capabiltiies that are attached to the Outcome