All courses / Architecture as Code / Module 5 / Chapter 19
Learning objectives
After the lesson the participant can:
- Define Management as Code and explain the three ways it differs from traditional management documentation.
- Distinguish the use of Issues for decision records from Discussions for strategic deliberation.
- Design a transparent decision workflow with templates, a labelling taxonomy and links to code changes.
- Describe Budgeting as Code and the metrics used to evaluate management effectiveness.
Key concepts
- Management as Code
- The systematic translation of management artefacts, such as policies, playbooks, delegation models, role definitions and decision guardrails, into declarative specifications that tooling can enforce. The artefacts are executable, follow change management discipline and are instrumented with telemetry.
- Issues as transparent decision records
- Structured, permanent and searchable records of how a decision evolved, giving visibility, traceability, accountability through named owners and milestones, and collaborative resolution within one thread.
- Discussions for strategic deliberation
- The forum for exploratory thinking, strategy formulation and community building before work is formalised. Threads allow open ideation and asynchronous participation, and the consensus links to the code change that implements it.
- Budgeting as Code
- A subset of Management as Code in which finance policies, spending limits, cost allocation rules and investment hypotheses are version-controlled. Files define budget envelopes per product, platform or team, and automated tests validate that proposed expenditure stays within budget.
- Management effectiveness metrics
- Measures similar to those of DevOps: lead time for management decisions, change failure rates for policies and mean time to recovery for organisational issues, drawn from management repositories and complemented by surveys.
Interactive exercises
Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.
Interactive exercise 1 · Sort
Issue or Discussion
Sort each piece of management work by the channel the chapter uses for it.
Interactive exercise 2 · Scenario
A critical vulnerability in a public repository
Read the situation and choose what the chapter's reasoning leads to. Each choice gives feedback.
Teaching plan
| 15 min | Teacher defines Management as Code, its principles, and how leadership responsibilities appear at each stage of the DevOps loop. |
| 20 min | Work through three of the chapter's examples: the cloud migration decision as an Issue, the annual technology strategy as a Discussion, and the confidential handling of a vulnerability. |
| 15 min | Teacher covers the five implementation steps, Budgeting as Code, competence management, team-of-teams leadership and the case study of a global software company. |
| 30 min | Exercise in groups: design a transparent decision workflow and one management artefact as code. |
| 10 min | Plenary on cultural implications: the temptation of private channels, and where confidentiality legitimately limits transparency. |
Discussion
- The chapter asks teams to resist resolving complex matters through private channels because it feels faster. What is the cost of that discipline, and when is it worth paying?
- Where should deliberate confidentiality limit transparency in your organisation, and how would you make that boundary explicit?
- What would be lost if culture or competence were codified badly, and how can the review process guard against it?
Written exercise
Exercise · 30 minutes
A transparent decision workflow and a management artefact
Design a transparent decision workflow for your own organisation following the chapter's five steps. Write an issue template with its five prompts: problem statement, business impact, technical context, stakeholder input and success criteria. Define a labelling taxonomy with four groups: strategic themes, affected systems, priority levels and workflow states. State how pull requests are linked to approved issues and how inactive Discussions are handled, using the chapter's 90-day flag as a starting point. Choose two metrics that will show the workflow's value. Then write one management artefact as structured data: either a budget envelope for a team with a limit and an approval rule, or a short competency definition with levels.
Deliverable: An issue template, a four-group label taxonomy, linking and review rules, two impact metrics, and one management artefact in structured form.
Self-test
Choose an answer to see whether it is right, or open the answer below each question.
Which of these is one of the three ways Management as Code differs from traditional management documentation?
Show the answer
C. The artefacts are executable and integrate with operational systems
The three differences are that the artefacts are executable, that management inputs follow the same change management discipline as software features, and that telemetry instruments every directive.In the chapter's implementation steps, after how long without activity does automation flag a Discussion for closure or renewal?
Show the answer
B. 90 days
Step four, scheduled Discussion reviews, has automation flag Discussions with no activity for 90 days, prompting closure or renewal, alongside monthly leadership reviews.How does Management as Code keep leadership in the change management loop without reintroducing bottlenecks?
Show the answer
A. Codified criteria approve low-risk changes and route higher-risk items to leaders
Change requests reference management policies stored as code, enabling automated approval for low-risk changes while routing higher-risk items to the appropriate leaders, with every decision logged.