Your Next 90 Days, and the Limits

This is Unit Eight of Leading AI at Work, on your own next ninety days, and on what the method cannot do. Unit Seven closed on teaching others. This unit turns the method on the person doing the teaching: you. Carry one question through this lecture: once the templates fade, what question is the method really asking? The answer arrives with the book's deepest shift, near the end. By the end you will be able to describe three role shifts and four habits. To plan your first seven, thirty and ninety days, and spread the method by coaching. And to state its six ideas and its limits.

Five entries on what a practitioner does differently, three shifts in role, and four habits that need nobody's permission.

What method do you use?

LAI 176 What You Do Differently

The M-CaReM-AI method, by J. R. Carver, closes with a chapter about you. An analyst is asked what method she uses. She asks which thing is changing, writes it on a card, keeps a short page about each important thing, and gives AI those pages first. Her director is unconvinced until he reads her impact assessments.

Shift one.

LAI 177 From Writer to Steward

The book reframes the requirements writer as an Object Steward, who guards the meaning of the things a system is built around: naming them, clarifying fields and states, and catching the change that quietly redefines one. AI can draft words, the book says, but cannot own meaning and responsibility.

Shift two.

LAI 178 From Translator to Conceptual Architect

The second shift turns the translator between business and technology into a conceptual architect. Instead of rephrasing requirements, you shape the structure AI, code, tests and policies plug into, and can say what else must be considered when one thing is touched. The book calls that architecture of concepts.

Shift three.

LAI 179 From AI Consumer to AI Framer

The third shift is from using AI to framing it: giving the tool a Pack and cards and forbidding invented fields or rules. The book calls this role durable, because the better tools get at writing, the more valuable the person who frames and checks them. An unframed request gets a typical answer.

Four habits.

LAI 180 Four Personal Habits

The book's four habits need nobody's permission: the thing question daily, one card a week, a Pack open while working, and every AI request anchored, starting with the thing's definition, its fields, and an instruction not to invent concepts. Then correct the output against the Pack, rather than accept or reject it whole.

Eight entries on a personal ninety-day plan, the portfolio it leaves, and how to spread the method without policing it.

The first week.

LAI 181 Your First Seven Days

The book's first week takes the method into one real piece of work. Pick a current initiative, not an imaginary one. Ask the thing question in every meeting about it and note the answers. Draft one Silver Pack without chasing perfection. Write one card for a visible behavior. Run one AI prompt with the thing's definition and the card template, and compare it with your Pack. Keep it light: one conversation changed by the method matters more than one finished Pack.

The first month.

LAI 182 Your First Thirty Days

By day thirty, the book aims for a starter portfolio from real work: two Packs, at least one Silver; five to eight cards; a rough matrix for one thing; two or three saved prompts that worked. Work Pack references into stories, cite a Pack in a meeting weekly, and note where a document changed a conversation. Those notes matter as much as the documents, because they become your examples when someone asks why your work is clearer.

The first ninety days.

LAI 183 Your First Ninety Days

By day ninety, the book's goal is quiet leadership: being known for bringing clarity and safety to things, changes and AI. Three to five Packs, one Gold if your domain is high-risk; ten to fifteen cards; one or two matrices; three to five solid prompts. Use the language of things in meetings, help a colleague write a card, use a matrix in a change discussion, and start a small object library. None of it needs a title change; the portfolio records that you did it.

Why the portfolio matters.

LAI 184 Why the Portfolio Matters

The book says a small portfolio gives proof of what you can do, reusable templates, and a personal standard of clarity. If your role changes, it shows an uncommon mix: requirements leadership that is thing-centric and aware of AI. Build it from real work, not made-up examples.

Coaching, not policing.

LAI 185 Coaching, Not Policing

The book warns against becoming the method police when colleagues notice your work is clearer. Its suggested answer is not that everyone should follow the framework, but: I've started doing a few things differently; want to try them? People adopt small tools that solve today's pain far more readily than a method they must obey.

Other methods, respected.

LAI 186 A Bridge, Not a Rival

The book advises respecting methods colleagues already use: user stories, use cases, event storming, Domain-Driven Design. Its suggested line: your stories are great narratives; our Packs make the underlying things explicit. Competing with a beloved method loses allies; connecting to it gains them.

Four kinds of skepticism.

LAI 187 Answering Personal Skepticism

The book answers four personal objections. To "no time," make a tiny request: a one-page Pack for this Gold thing before we change it. To "too academic," drop the philosophy and show a card from their own work. To "AI will make this obsolete," agree in part, then compare a prompt with no context against one given the Pack and card template. To "too many frameworks," call it a lens and vocabulary inside their process. Each time, the document persuades, because a visible difference convinces where a claim does not.

A Pack for yourself.

LAI 188 A Pack for Your Own Practice

The book applies material cause, playfully, to your own practice: your habits are what your career is made of. A personal Pack might list your domains and values as fields, a lifecycle from beginner to mentor, and cards such as facilitate a hard conversation. Mastering the method, it says, is also refining yourself.

Seven entries on the method's six ideas, its deepest shift, its honest limits, and the role guides. The opening question is answered here.

Six ideas.

LAI 189 The Six Ideas, Plainly

The book reduces the method to six plain ideas. Systems are made of things. Change happens to something. Each thing needs one place. Truth lives between people. Change is safer when you know what hangs off each thing. And AI is powerful but needs a frame. Remember those six better than any template.

The deepest shift.

LAI 190 From Requirements to Living Things

The book calls the deepest change psychological: requirements stop being gathered, frozen and signed off, and become ongoing accounts of how things change. The question shifts from did we capture all the requirements, to do we understand our things well enough to change them safely? That answers this lecture's question; the aim is systems built to change without shattering.

As AI grows stronger.

LAI 191 Capability Is Not Alignment

The book's reason careful work on things matters more as AI grows stronger is that capability is not alignment. It suggests agents may one day draft services from Packs or tests from cards, and if so, the method becomes the language they use to stay in step with people. That is the book's projection, offered as plausible, not certain.

Five honest limits.

LAI 192 What the Method Cannot Do

The book is candid about five limits. The method does not remove politics, align incentives, supply domain expertise, remove ambiguity, or replace good engineering. It makes disagreements precise and shows where ambiguity lives, but people still must listen to domain experts. No method is magic, and the book says so.

Whose problem is it?

LAI 193 Whose Work Is It?

When the method seems not to fix everything, the book says, ask whose work the problem really is. If teams are rewarded only for speed, they skip validation, and that is work for leadership and incentives, not any method. Asking a method to do leadership's job makes both look weak.

Guides for three roles.

LAI 194 Role Guides: Analyst, Architect, Tester

The Toolbox's role guides each begin with a strength. The analyst turns ambiguity into shared understanding, so names each feature's things, drafts cards rather than single sentences, and links them in stories. The architect builds structures that outlast projects, so labels data models with thing names and uses matrices as architecture views. The tester protects against wishful thinking, so tags tests by thing and card and plans regression from matrices. All three give AI definitions first. Starting from strengths makes the method feel like a better version of the job.

Managers and AI engineers.

LAI 195 Role Guides: Manager and AI Engineer

The manager moves many people roughly the same way, so uses Packs in steering reviews, frames scope by things, as in this release touches three Gold things, and adds the done lines. The AI engineer builds tools that can go very wrong unanchored, so treats Packs as ground truth for features and labels, supplies the Pack before generating or classifying, and checks matrices for affected policies and tests. The book's sharpest warning: a model on free-floating signals is hard to explain, audit and change safely.

Look at what you can now do. You can describe the three shifts, writer to steward, translator to conceptual architect, consumer to framer, and the four habits that need no permission. You can plan your first seven, thirty and ninety days into a portfolio, and spread the method by coaching rather than policing, with a document to show each skeptic. And you can state the six ideas, the question that replaces them all, and the limits the book admits. Unit Nine is the capstone.