The technology function's OS: the library that works for you
A common course delivers a lesson; a strong course delivers infrastructure. This lesson joins the module's choreographies into a living system, your technology function's OS, which improves itself with every good delivery.
Look at your screen right now. There's a prompt saved in a notes app that always works to triage a new ticket. There's a postmortem document you duplicate every incident and tweak by hand. There's that script you put together to sweep for technical debt and almost never run because you forgot where you saved it. Each piece works on its own. The problem is they're scattered, spread out, dependent on your memory. This lesson is the moment to bring it all together in one place, with a name and an order, and turn that pile of good hacks into a system that works for you.
Look at your legal work today: a saved prompt that does the first read of a contract and points to risky clauses, an opinion template you duplicate and tweak by hand for every case, a due diligence checklist you built and forgot which folder it's in. Each piece works on its own, but they're scattered, spread out, dependent on your memory in a field where a wrong citation costs a lot. This lesson is the moment to bring it all together in one place, with a name and an order, turning it into a legal system that works for you instead of a pile of good hacks.
Look at your way of working today: a saved prompt that writes a job description that attracts good candidates, an interview script you reuse and tweak by hand for every role, an onboarding checklist you built and forgot which folder it's in. Each piece works on its own, but they're scattered, dependent on your memory, and every hire you rebuild it in a rush. This lesson is the moment to bring it all together in one place, with a name and an order, turning it into an HR system that works for you instead of a pile of good hacks.
Look at your product flow today: a prompt that turns raw user feedback into discovery insight, a PRD template you duplicate and adapt by hand for every feature, a prioritization ritual you built and barely use because nobody remembers where it lives. Each piece works on its own, but they're scattered, spread out, dependent on your memory between one sprint and the next. This lesson is the moment to bring it all together in one place, with a name and an order, turning it into a product system that works for you instead of a pile of good hacks.
Look at your sales day right now: a saved prompt that writes the prospecting email that always opens a conversation, a proposal template you duplicate and tweak by hand for every client, a CRM pipeline-update flow you built and almost never run because you forgot the steps. Each piece works on its own, but they're scattered, dependent on your memory, and every deal you rebuild it from scratch. This lesson is the moment to bring it all together in one place, with a name and an order, turning it into a sales system that works for you instead of a pile of good hacks.
Look at your operation today: a prompt that summarizes the status of each process step in a clean paragraph, an SLA control spreadsheet you duplicate and tweak by hand every week, a quality-check flow you built and barely use because you forgot which folder it's in. Each piece works on its own, but they're scattered, spread out, dependent on your memory. This lesson is the moment to bring it all together in one place, with a name and an order, turning it into an operations system that works for you instead of a pile of good hacks.
Look at your compliance work today: a saved prompt that maps a process's risk into a clear summary, an audit report template you duplicate and tweak by hand every cycle, an LGPD check flow you built and almost never use because you forgot where you saved it. Each piece works on its own, but they're scattered, spread out, dependent on your memory, in a place where the trail matters. This lesson is the moment to bring it all together in one place, with a name and an order, turning it into a compliance system that works for you instead of a pile of good hacks.
Look at your way of working today: a saved prompt that turns user research notes into an organized insight, a flow template you duplicate and tweak by hand for every new journey, an accessibility checklist you built and almost never open because you forgot which folder it's in. Each piece works on its own, but they're scattered, spread out, dependent on your memory between one project and the next. This lesson is the moment to bring it all together in one place, with a name and an order, turning it into a UX system that works for you instead of a pile of good hacks.
Look at your way of working today: a saved prompt that turns loose market news into a competitive intelligence summary, a board deck template you duplicate and tweak by hand every quarter, a scenario script that helped in a big decision and that you can barely find because you forgot which folder it's in. Each piece works on its own, but they're scattered, spread out, dependent on your memory right at the meeting that matters most. This lesson is the moment to bring it all together in one place, with a name and an order, turning it into a strategy system that works for you instead of a pile of good hacks.
Let me tell you something about courses. A common course delivers a lesson: you watch, do the exercise, close the tab, and three weeks later you remember roughly the concept. Think with me: what stayed in your workday? Almost nothing. A strong course is something else. A strong course delivers infrastructure, something that stays running after you closed the tab, that changes how you operate Monday morning. This entire module was built to leave you with infrastructure, not with a memory. This lesson is where we install it for good.
The core idea of this lesson. Your technology function's OS is a living library with four shelves: the prompts that work, the delivery templates in the canonical format, the agents and flows that run on their own, and the audit checklist every delivery passes through. The criterion for what becomes what is simple: a repeatable, stable task becomes a template or an agent; a task that changes every time stays more in your hands, with AI helping. And the trick is that this system improves itself: every good delivery you make becomes a new piece in the library. You're not leaving here knowing about AI in technology. You're leaving with AI installed in the way your team works, and nobody takes that away.
01The difference between a lesson and infrastructure
Let's call it what it is. What separates whoever watches an AI course and keeps doing the same from whoever watches it and moves up a level isn't the amount of memorized prompts. It's whether that turned into a system or turned into a note.
A note is fragile. It depends on you remembering, on you finding the file, on you having the energy to rebuild the prompt in a Friday-at-5-PM rush with an open incident. A system is the opposite: it's ready, has a fixed place, opens fast, and works even when you're tired or when it's someone else on the team on call. The economic question behind this is direct. What's an hour of engineering worth? Every time someone on the team rebuilds from scratch something that's already been done ten times, the team is paying that hour for not having organized. The OS is what stops charging that bill.
The difference isn't magic, it's arrangement with intent. And that's exactly what we're going to do now. Fair?
02The OS's four shelves
The technology function's OS isn't a product you buy. It's a four-shelf structure you build with what you already produced in this module. Each shelf has a clear function.
- Shelf 1, the prompts that work. The collection of commands already tested that deliver good results: triaging a new ticket, correlating an incident's logs, summarizing a deploy's status. Not every prompt anyone ever wrote. It's the subset that passed the real test, with a descriptive name, ready to reuse without rewriting.
- Shelf 2, delivery templates. The postmortem in canonical format, the build versus buy matrix, the prioritized technical debt map, already in the right section structure. The template carries the good form so nobody has to decide the layout every time, in an incident or a vendor decision.
- Shelf 3, agents and flows. The backlog triage that runs on its own, the technical debt sweep that fires periodically. Here lives the work that happens without anyone pressing a button.
- Shelf 4, the audit checklist. The five-item checklist you saw in the previous lesson, through which every agent PR passes before becoming a delivery. It's the shelf that protects the other three, because it's the one that guarantees speed didn't turn into a mistake with the look of certainty.
Notice this isn't theory. You've already produced a piece for each of these shelves throughout the module. The OS is the act of taking them out of the drawer and putting them on the right shelf.
03The criterion: what becomes a template, what becomes an agent, what stays manual
The question that trips people up most here is: automate what? The answer has a single criterion and it fits in one sentence. The more repeatable and stable the task, the higher up the automation scale it climbs. The more it changes every time, the more it stays in your hands, with AI just helping.
- Repeatable and identical every time, becomes an agent or flow. Ticket triage that always follows the same criterion, the debt sweep that always runs the same way. This fires on its own. You just audit the result.
- Repeatable but with new content each time, becomes a template. The postmortem always has the same structure, but the incident is always different. The template fixes the form and frees you to handle the content.
- Changes every time, stays in your hands. The build versus buy decision for a new vendor, reading an atypical incident that doesn't resemble any existing runbook. AI helps you think, but you're at the wheel. Trying to automate this only creates a rigid system that breaks when the case strays from the script.
This criterion spares the team two expensive mistakes. The first is automating what changes, and getting stuck with an agent that gets it wrong outside the script in an incident nobody foresaw. The second is leaving in your hands what's identical every time, and continuing to pay engineering hours out of reluctance to build the flow. You want each task at the right height on the scale. Fair?
Learn more: why "build versus buy" almost always stays manual
It's worth a concrete example of why an important task doesn't always climb the automation scale. The decision to build a tool internally or buy from a vendor seems repeatable, because the team faces this choice several times a year. But the content of each decision changes: the vendor is different, the internal maintenance cost is different, the dependency risk is different. Turning this into an agent would be dangerous, because a fixed criterion doesn't capture each case's nuance. What it safely becomes is a template: a matrix with the same columns every time (total cost, lock-in risk, integration time, support), filled in fresh for each decision. AI helps fill it out fast; reading the matrix stays yours, because it's judgment, not repetition.
04The trick: the system that improves itself
Here's the part that turns the OS from a dead file into something alive. A well-built OS doesn't stay still. It grows with every use.
Here's how it works. The team closes an incident this week, say a postmortem that came out particularly well written, with a clear root cause and a specific prevention action. In the old way, that work dies at delivery: someone posts it in the Slack channel and life goes on. In the OS, it doesn't die. The prompt that helped write that postmortem becomes a piece on the prompts shelf. The structure that worked becomes or reinforces the template. The check that caught an important detail becomes one more line in the audit checklist. Every good delivery leaves a sediment in the system.
The compound effect of this is big. In month one, the OS has the basics. In month six, it has the entire library of the best ways to do each thing, distilled from dozens of incidents, PRs, and real decisions. The team gets faster not because the agent got smarter, but because the team's system became more theirs. The practical rule is one: every good delivery ends with a question, what's worth keeping from this? That question is what keeps the OS alive.
And notice that's the opposite of starting from zero. Most teams start every incident or every decision at square one, wrestling with the same prompt again. Whoever has an OS starts from the accumulated. That's the advantage that shows up slowly and then becomes impossible to catch up to.
05The module's choreographies already go into the OS
Now it's time to close the loop. Everything you practiced in this module wasn't a loose exercise. Every choreography is already a piece ready to go on the shelf. To recap:
- The new game of the technology function and mapping the system's state. Becomes your OS's context base, feeding every prompt and template with the real reality of your repositories, tickets, and architecture.
- The backlog that triages itself. Becomes an agent on shelf three, the triage that runs without anyone needing to open the board.
- Visible technical debt. Becomes a template plus a flow: the debt map on shelf two, the periodic sweep on shelf three.
- Incident response with a copilot. Becomes the postmortem template and living runbook on shelf two, fed by the log correlation prompts on shelf one.
- The build versus buy decision. Becomes a template on shelf two, the auditable matrix you fill in fresh for every vendor.
- The audit of code you didn't read. Is the entire shelf four, the checklist that protects the other three before any agent PR becomes a delivery.
If you want to see where the technology function's OS fits in the bigger picture of the journey, it's your instance of what the orchestration track calls infrastructure: each piece of it is a packaged capability the team reuses instead of reinventing. Technology was just the domain where you built the first one. The method is the same for any area of the business.
And that's why the message from the start of this module holds true here: you're not leaving here knowing about AI in technology. You're leaving with AI installed in the way your team works. The difference is huge: knowing fades, systems stay. You didn't finish a module, you built infrastructure. And nobody takes that away.
Do it now
Open a blank document and give it the title: Technology Function OS, your real task. Create the four shelves as sections:
- Prompts that work. List three to five prompts you or the team tested in this module and that delivered good results (e.g., "new ticket triage", "incident log correlation", "deploy summary for the team"). Give each a descriptive name and paste the prompt.
- Delivery templates. List the canonical formats you already have or want to have: the postmortem, the build versus buy matrix, the technical debt map. For each, write the section structure in one line.
- Agents and flows. List what already runs or should run on its own: backlog triage, the debt sweep. Mark what already exists and what's still to be built.
- Audit checklist. Write the five checks every agent PR passes before becoming a delivery (does the diff match the intent, is the blast radius what you'd expect, and so on).
At the end, classify each item on shelf 3 by the lesson's criterion: is it repeatable and identical (becomes an agent), repeatable with new content (becomes a template), or does it change every time (stays manual). This document is the index of your team's OS. From today on, every good delivery ends with the question: what's worth keeping from this?
Practice
1. What's the criterion for deciding what becomes an agent, what becomes a template, and what stays manual in technology?
2. What makes the technology function's OS a living system, not a dead repository of scripts?
3. What's the difference between a module that delivers a lesson and one that delivers infrastructure, in this track's sense?
For the board
On what remainsknowledge fades, systems stay. The team walks away with running infrastructure, not notes.
On the criterionstable and repeatable becomes an agent. Repeatable with new content becomes a template. What changes every time stays in your hands.
On compoundingevery good delivery leaves a sediment, and the system becomes more the team's with each round.
Thanks for the feedback. It helps sharpen the next lesson.