Building Repeatable Systems as the Manager Role in E Myth Business Roles
This skill teaches you how to design, document, and implement operational systems and processes that create order, consistency, and scalability, fulfilling the Manager function within the E-Myth's three essential business roles.
Start by auditing your operations for tasks that repeat weekly or more often. For each repeatable task, document the trigger, inputs, steps, quality standards, and expected output. Package these into written process documents or checklists. Then train someone other than yourself to execute each system, verify the output meets your standards, and iterate. The Manager role succeeds when the business produces consistent results without depending on any single person's memory or intuition.
Outcome: You produce written, testable process documents that let someone other than you execute critical business functions to a consistent quality standard, freeing your time for higher-leverage Manager and Entrepreneur activities.
Prerequisites
- Familiarity with the Technician, Manager, Entrepreneur Framework and the three e myth business roles
- Ability to perform the task you want to systematize at least once yourself
- A list of recurring operational tasks or workflows in your business
- Basic documentation tools (Google Docs, Notion, or even a plain text editor)
Overview
The Manager role in the Technician, Manager, Entrepreneur Framework exists to create order from chaos. While the Technician does the work and the Entrepreneur envisions the future, the Manager builds the scaffolding that holds the business together: repeatable systems, documented processes, quality standards, and accountability structures. Most small business owners spend the vast majority of their time as Technicians, doing the work themselves. When they try to grow, they hit a ceiling because everything depends on their personal knowledge, habits, and presence. Building systems is the primary act of the Manager role, and it is the single most important skill for breaking through that ceiling.
A "system" in this context is not software. It is a documented, repeatable process that produces a consistent result regardless of who executes it. It includes a trigger (what starts the process), inputs (what information or materials are needed), steps (the specific sequence of actions), quality gates (how you verify the output meets standards), and an output (the deliverable or outcome). The artifact you produce from this skill is a process document, sometimes called a Standard Operating Procedure (SOP), that is specific enough for a new team member to follow on their first day and produce an acceptable result. Think of it as a recipe: precise enough to cook the dish, flexible enough to accommodate the cook's skill level.
This skill sits at the operational core of the e myth business roles. It is downstream of assessing your balance across the three roles (you need to know you are under-investing in the Manager before you can correct it) and upstream of shifting from working in to working on your business (systems are the mechanism that makes that shift possible). Without documented systems, delegation is just hoping someone else figures it out. With them, delegation becomes predictable. Success looks like this: you can leave your business for two weeks, and the core operations continue producing results at the same quality level as when you are present. That is the Manager's contribution to a business that works.
How It Works
The mental model behind system-building is straightforward: you are converting tacit knowledge (things you know how to do but have never written down) into explicit knowledge (documented steps anyone can follow). This conversion is the single highest-leverage activity in a small business because it transforms your personal capacity into organizational capacity. One person's time is finite. A system's capacity scales with the number of people who can execute it.
The reason systems work is that most business operations are far more repetitive than they feel. When you onboard a new client, you follow roughly the same steps each time. When you fulfill an order, the sequence is similar. When you publish content, there is a pattern. The Technician in you experiences each instance as unique because you are focused on the craft. The Manager in you recognizes the pattern and extracts the repeatable structure. This is not about removing judgment or creativity. It is about removing the need to reinvent the basic sequence every time, so that judgment and creativity can be applied to the parts that actually require them.
A good system has five components that work together. First, the trigger defines when the system activates: a new lead comes in, a weekly calendar event fires, a customer submits a support ticket. Without a clear trigger, people do not know when to start the process. Second, the inputs specify what information or materials must be gathered before execution begins. Third, the steps describe the specific actions in sequence. Fourth, the quality gates define what "done well" looks like at critical checkpoints. Fifth, the output describes the deliverable or state change that marks completion. When any of these five components is missing or vague, the system breaks down in predictable ways: people do not start the process (missing trigger), start but stall (missing inputs), produce inconsistent results (missing steps or quality gates), or do not know when they are finished (missing output definition).
The deeper principle at work here connects directly to the Technician, Manager, Entrepreneur Framework. The Technician's instinct is to do it themselves because they can do it best and fastest right now. The Manager's instinct is to make it work without them because that is the only path to scale. Building a system forces you to slow down once, so you can speed up permanently. The initial investment of 3-5 hours to document a process that takes 30 minutes to execute pays for itself after 6-10 delegated executions. After that, every execution is pure leverage. This is why system-building is the Manager's primary skill: it is the mechanism that converts the Technician's excellence into organizational capability.
One important nuance: systems are not static documents. They are living artifacts that improve through use. The first version of any system will be incomplete. That is expected and correct. The goal of the first version is to capture 80% of the knowledge needed, then refine through real execution. Each time someone executes the system and encounters an ambiguity or gap, that gap gets documented and the system improves. After three to five iterations, most systems stabilize into reliable, low-maintenance processes.
Step-by-Step
Step 1: Audit Your Operations for Systematizable Tasks
Open a blank document and list every task you personally perform in a typical two-week period. Include everything from client communication to invoicing to content creation to internal meetings. Next to each task, note two things: how often it repeats (daily, weekly, monthly, per-project) and whether the basic sequence is roughly the same each time. Tasks that repeat weekly or more often and follow a similar pattern each time are your prime candidates for systematization.
Sort this list by frequency, with the most frequent tasks at the top. You are looking for the 5-10 tasks that consume the most cumulative time and follow a repeatable pattern. Do not include one-off strategic decisions or deeply creative work. Focus on the operational backbone: onboarding, fulfillment, reporting, communication sequences, quality checks.
Tip: If you struggle to list your tasks from memory, track your actual time for one week before doing this step. Use a simple spreadsheet with columns for date, task, duration, and whether the task was reactive or planned. The tracking data is far more accurate than recall.
Step 2: Select Your First System to Build
From your sorted list, choose one task that meets three criteria: it repeats frequently (weekly or more), it has a clear beginning and end, and you can explain the basic steps to someone in under 15 minutes. Do not start with your most complex or most important process. Start with something moderately important that you understand well. The goal is to build your system-building muscle on a manageable task before tackling the high-stakes ones.
Common strong first choices include: weekly reporting, client onboarding emails, invoice creation, social media publishing, or new employee setup. Write down the name of the process, who currently does it (probably you), and roughly how long it takes per execution.
Tip: Resist the temptation to systematize your most painful process first. Painful processes are often painful because they are tangled with exceptions and judgment calls. Start with a straightforward process to learn the documentation pattern, then tackle complexity.
Step 3: Perform the Task Once While Narrating Every Action
Execute the task in real time, but this time, narrate or write down every single action as you take it. This includes the obvious steps and the micro-decisions you make unconsciously. If you log into a tool, note which tool and why. If you copy information from one place to another, note the source and destination.
If you make a judgment call ("this looks good enough" or "this client needs the premium version"), note the criteria you use to make that judgment. Record the actual inputs you use: where did you get the data, what format was it in, what did you do if something was missing. This narration exercise is the most important step because it surfaces the tacit knowledge that lives only in your head. Most people underestimate how many small decisions they make during a "simple" task.
The narration reveals them.
Tip: Screen recording (Loom, QuickTime, or similar) combined with verbal narration is often faster and more complete than writing notes in real time. You can transcribe the recording afterward and extract the steps.
Step 4: Structure Your Notes into the Five-Component System Format
Take your raw narration and organize it into the five-component format. Start with the trigger: what event or condition causes this task to begin? Then list the inputs: what information, tools, access, or materials must be available before execution starts? Next, write the steps in numbered sequence.
Be specific enough that someone unfamiliar with your business could follow them. Include the exact tool names, menu locations, and field names where relevant. After the steps, define the quality gates: at what points should the executor pause and verify their work, and what does "correct" look like at each checkpoint? Finally, describe the output: what artifact is produced, where does it go, and who needs to be notified?
Use plain language. Write at a level that assumes the reader is competent but has never done this specific task in your specific business context.
Tip: For each step, ask yourself: "If I handed this to a smart person who has never worked here, what would they get stuck on?" That question reveals the hidden assumptions and context you need to make explicit.
Step 5: Add Decision Points and Exception Handling
Review your step sequence and identify every point where the executor might need to make a judgment call or encounter an unexpected situation. For each decision point, write a simple if/then rule. For example: "If the client has not responded within 48 hours, send Follow-Up Template B. " You do not need to cover every possible edge case.
Focus on the exceptions that occur in at least 20% of executions. For truly rare situations, a simple instruction like "If you encounter something not covered here, pause and ask [name/role] before proceeding" is sufficient. The goal is to handle the common branches, not to create a decision tree for every conceivable scenario.
Tip: Review your last 10 executions of this task and note which ones deviated from the standard path. Those deviations are your exception cases. If you cannot recall specific deviations, the process is likely more straightforward than you think, and you can add exceptions as they surface during testing.
Step 6: Test the System with Someone Else
Hand the documented system to another person and ask them to execute it without your help. This is the critical validation step. Sit nearby but do not intervene unless they are about to cause irreversible harm. Take notes on every point where they hesitate, ask a question, make an error, or deviate from the documented steps.
After they complete the execution, review the output against your quality standards. Then debrief: ask them what was unclear, what they had to guess at, and what they would add to the document. Every question they asked represents a gap in your documentation. Every error they made represents an ambiguous instruction.
This testing step typically reveals 3-7 gaps in a first draft, which is completely normal and expected.
Tip: The ideal test person is someone who is capable but unfamiliar with the specific task. A very experienced team member will fill in gaps from their own knowledge, masking documentation weaknesses. A completely new person gives you the cleanest test of the system's completeness.
Step 7: Revise the System Based on Test Results
Incorporate every gap, question, and error from the test execution into your system document. Be specific in your revisions. ", add the exact template name and location to the relevant step. If they produced a lower-quality output at a particular stage, add a quality gate with explicit criteria ("The proposal should include at least three pricing options and a timeline.
"). After revising, note the version number and date. Run a second test if possible, either with the same person or a different one. Most systems reach an acceptable level of completeness after two to three test-revise cycles.
Tip: Keep a changelog at the top of the document. Even a simple list of revision dates and what changed helps you track how the system is evolving and signals to users that it is actively maintained.
Step 8: Assign Ownership and Set a Review Schedule
Every system needs an owner: one person responsible for maintaining the document, training new executors, and updating it when the process changes. The owner does not need to be the executor. In a small team, the owner is often you initially, transitioning to a team lead as you grow. Write the owner's name at the top of the document.
Set a review schedule, typically quarterly for processes that change frequently and semi-annually for stable ones. Put the review date on your calendar. During each review, the owner should verify that the steps still match actual practice, update any tool names or access details that have changed, and confirm the quality gates still produce acceptable results. A system without an owner degrades within months.
Tip: The review meeting should take 15-30 minutes. Pull up the document, walk through it with the current executor, and ask: "Is this still how you actually do it?" The gap between documentation and practice always widens over time. Regular reviews close that gap before it becomes a problem.
Step 9: Integrate the System into Your Operating Rhythm
A documented system that lives in a forgotten folder is worthless. Place the system where people actually work: link it from your project management tool, pin it in a relevant Slack or Teams channel, or include it in your onboarding checklist. Create a simple index or directory of all your systems so anyone can find the right process quickly. As you build more systems, organize them by function: client-facing, internal operations, finance, marketing, fulfillment.
Over time, this directory becomes your operations manual, the Manager's primary artifact. Reference it during team meetings when process questions arise. ", the answer should be a link to the relevant system, not a verbal explanation from memory.
Tip: Name your systems with the same prefix pattern so they sort naturally in any tool. For example: "SYS-ONBOARD: New Client Onboarding", "SYS-INVOICE: Monthly Invoice Generation", "SYS-CONTENT: Blog Post Publishing". This naming convention makes systems searchable and distinguishable from other documents.
Examples
Example: Solo Consultant Systematizing Client Onboarding
A freelance marketing consultant handles 3-4 new client engagements per month. Each onboarding takes about 90 minutes of scattered tasks: sending a welcome email, creating a shared folder, scheduling the kickoff call, collecting brand assets, and setting up project tracking. The consultant does everything from memory and occasionally forgets steps, leading to awkward follow-ups.
The consultant starts by executing the next onboarding while narrating every action into a Loom recording. She discovers 14 distinct steps she performs, including several she had forgotten about (like checking the CRM for previous interactions and adding the client to the monthly reporting list). " She adds three quality gates: welcome email sent within 2 hours, shared folder structure verified against template, and kickoff agenda confirmed 24 hours before the call. She tests the system by having her part-time VA execute the next onboarding.
The VA completes 11 of 14 steps correctly, gets stuck on CRM notation format, and misses adding the client to the reporting list because that step was buried in a paragraph. The consultant revises: she reformats all steps as a numbered checklist, adds a screenshot of correct CRM notation, and moves the reporting-list step to a more prominent position. The second test execution runs smoothly. The consultant now delegates all onboarding to the VA, saving herself 4-6 hours per month and eliminating forgotten steps entirely.
Example: E-Commerce Team Systematizing Order Fulfillment
A 6-person e-commerce company ships 200-300 orders per week. Three different warehouse staff handle fulfillment, and error rates vary significantly: one team member ships incorrect items about 2% of the time, while another runs at 0.3%. The business owner suspects the difference is in personal process habits, not skill. Peak season is 8 weeks away, and they need to hire two temporary workers.
The owner asks the lowest-error team member to narrate their process while fulfilling ten orders. The narration reveals two key habits the others do not follow: she verifies the SKU against the packing slip before sealing the box (a quality gate), and she groups multi-item orders by location zone to reduce pick path time (an efficiency step). " Two quality gates are added: SKU verification before sealing and weight check against expected range. Decision points include handling for oversized items, fragile items, and international shipments with customs forms.
The system is tested with the higher-error team member, who completes it correctly but flags that the international shipping decision point needs the customs form codes listed directly in the document rather than referencing a separate sheet. After revision, all three existing staff use the system for one week. 4% across all staff. The two temporary holiday workers are trained using the system document and reach acceptable error rates within their first shift, something that previously took a full week of shadowing.
Example: B2B SaaS Startup Systematizing Weekly Reporting
A 12-person SaaS startup produces a weekly metrics report for the leadership team. The report includes MRR, churn, new trials, support ticket volume, and NPS. The CEO currently compiles it every Monday morning, pulling data from five different tools. It takes 75 minutes, and the CEO frequently pushes it to Tuesday or skips it entirely during busy weeks. The team has expressed frustration about inconsistent reporting.
The CEO documents the report compilation process during the next Monday session, noting every source, login, export, and calculation. She discovers that 40 minutes of the 75-minute process is spent on two calculations that could be pre-computed in a spreadsheet with formulas. " The inputs section lists the five tools with exact navigation paths to the relevant dashboards. Steps include exporting data, pasting into the master spreadsheet (which auto-calculates the derived metrics), drafting a 3-sentence narrative summary for each section, and sending via the standard email template.
Quality gates include verifying that MRR change matches the Stripe dashboard and that churn count matches the CRM cancellation log. She delegates the system to the operations coordinator, who completes the first test report in 55 minutes with two errors: an incorrect date range filter in the analytics tool and a missed NPS data point because the survey tool URL had changed. After revision, the coordinator produces accurate reports independently. The CEO reclaims 75 minutes per week, and the team receives consistent Monday morning reports for the first time.
Example: Agency Owner Systematizing Content Approval
A 20-person digital agency handles content production for 15 clients. Content goes through multiple review stages: writer draft, editor review, client review, revision, final approval, and scheduling. Different account managers follow different approval workflows, leading to missed deadlines, conflicting feedback, and occasional publishing of unapproved content. The agency owner wants to standardize without slowing down production.
The owner interviews three account managers and maps their actual workflows on a whiteboard. " Critical decision points include: what to do when client feedback contradicts the brief (escalate to account manager, do not interpret independently), how to handle late client feedback (auto-reminder at 48 hours, escalation at 72 hours), and the definition of "approved" (written confirmation in the project tool, not a verbal "looks good" on a call). She adds status labels that must be updated at each stage so the entire team has visibility. The system is tested with two account managers over a two-week period covering 22 content pieces.
Three gaps surface: the handoff from editor to client reviewer needed a templated email, the revision step needed a maximum-revision-count policy (set at two rounds), and the scheduling step needed a 24-hour buffer before publish date for final checks. After revision, all account managers adopt the system. Missed deadlines drop by 60% in the first month, and zero unapproved content is published.
Best Practices
Document the process as it actually works today, not as you wish it worked. Aspirational documentation creates confusion because the executor's experience will not match the instructions. Capture reality first, then improve the process in a separate, deliberate step. If you document an idealized version, people will abandon the document as unreliable after their first execution.
Write steps at the action level, not the goal level. "Prepare the client proposal" is a goal. "Open the proposal template in Google Docs, duplicate it, rename with client name and date, fill in sections 1-4 using data from the intake form" is a set of actions. Goals leave room for interpretation, which is exactly what systems are designed to eliminate for routine work.
When you find yourself writing a step that is really a mini-project, break it into sub-steps.
Include the 'why' behind critical steps, not just the 'what.' When an executor understands why a quality gate exists or why a step must happen in a particular order, they make better judgment calls when edge cases arise. A step like "Always CC the account manager on the delivery email because they need visibility for the Monday pipeline review" prevents the executor from quietly dropping that CC when they are in a hurry.
Set explicit quality standards using examples, not adjectives. "Write a professional email" means different things to different people. "Write an email following the format in Template A, keeping it under 150 words, and including the three data points from the report" is testable and consistent. Wherever possible, link to a gold-standard example that shows what "done well" looks like for that step.
Build systems incrementally by function, not all at once. Attempting to systematize your entire business in a week leads to burnout and shallow documentation. Build one complete, tested system per week. After 10-12 weeks, you will have a functional operations manual covering your core processes. This pace is sustainable and produces higher-quality systems.
Separate the system document from training materials. The system document is a concise reference for someone who already knows the basics. Training materials are longer, include background context, and walk through the first execution step by step. Combining them produces a document that is too long for daily reference and too terse for initial learning.
Version and date every system document. When someone follows an outdated process and produces a wrong result, you need to know whether the problem is the person or the documentation. A clear version history with dates lets you trace errors to their source. It also signals to users that the document is actively maintained, which builds trust in the system.
Treat every process failure as a system improvement opportunity, not a people problem. When an error occurs, ask "Where did the system fail to guide the executor correctly?" before asking "Why did the person make a mistake?" This mindset shift produces better systems and a healthier team culture around process compliance. Document the fix and update the system immediately.
Common Mistakes
Documenting everything at once instead of starting with one high-frequency process
Correction
The urge to systematize the entire business in one sprint comes from the Technician's "do it all now" mindset. It produces dozens of half-finished documents that are too incomplete to use and too numerous to maintain. The signal that you have fallen into this trap is a folder full of documents that no one references. Instead, commit to finishing one complete system per week, including the testing step.
A single well-tested system is worth more than twenty untested drafts.
Writing steps that are too vague for someone unfamiliar with the task to follow
Correction
This happens because the person writing the system unconsciously fills in gaps with their own knowledge. You will recognize this mistake when your test executor asks multiple questions per step, or when two different people following the same system produce noticeably different results. The fix is the narration exercise in Step 3: performing the task while documenting every micro-action, including the ones that feel too obvious to mention. If you catch yourself writing 'process the order,' break it into the 4-6 specific actions that processing an order actually involves.
Creating systems that are rigid scripts instead of flexible frameworks with decision points
Correction
Overly rigid systems break the first time an edge case appears, and the executor either freezes or improvises without guidance. This usually happens when the system builder tries to eliminate all judgment from the process. Watch for team members saying "the process doesn't cover this" frequently. The solution is to include explicit decision points with if/then rules for common variations, and a clear escalation path for uncommon ones.
A good system constrains the routine parts and empowers judgment for the non-routine parts.
Building the system but skipping the test-with-another-person step
Correction
Untested systems have an average of 4-6 critical gaps that the author cannot see because their own expertise fills in the blanks. The telltale sign is a system that works perfectly when you execute it but fails when anyone else tries. This is the most common mistake because testing feels slow and the Technician in you wants to move on to the next task. Force yourself to complete Step 6 before considering the system finished.
An untested system is a draft, not a system.
Failing to assign an owner and review schedule, so the system becomes outdated within months
Correction
Systems without owners decay silently. Tools get updated, team members change, and the documented process drifts from actual practice. You will notice this when a new hire follows the system and produces incorrect results, or when experienced team members say "oh, we don't do it that way anymore." The fix is simple but requires discipline: assign one owner per system, schedule quarterly reviews on the calendar, and make the review a 15-minute standing meeting. An outdated system is worse than no system because it creates false confidence.
Over-engineering the first version with elaborate templates, automation, and software before validating the process manually
Correction
Premature automation locks in a process that may not be correct yet. You see this when someone spends two weeks building a Zapier workflow or custom software for a process they have only executed three times manually. The first version of any system should be a written document and a checklist. Automate only after the process has been manually executed and refined at least five times.
At that point, you know which steps are truly stable and which still need flexibility.
Other Skills in This Method
Shifting from Working In to Working On Your Business
Practical techniques for reducing day-to-day task execution so you can invest time in strategic planning, systems design, and business growth.
Designing Role-Based Time Allocation Across the Three Roles
How to structure your weekly schedule to intentionally allocate time to technician tasks, manager responsibilities, and entrepreneurial thinking.
Assessing Your Technician, Manager, and Entrepreneur Balance
How to diagnose which of the three business personalities currently dominates your work style and where imbalances are holding you back.
Developing Your Entrepreneurial Vision
Techniques for cultivating the entrepreneur mindset — identifying future opportunities, setting a compelling business vision, and driving innovation.
Transitioning from Technician to Entrepreneur
A step-by-step approach for craft-focused founders to delegate technical work, build leadership capacity, and embrace the entrepreneurial role.
Applying the E-Myth Framework to Agencies and Service Businesses
How to use the Technician-Manager-Entrepreneur model specifically within creative agencies, consultancies, and professional service firms.
Frequently Asked Questions
How do I decide which processes to systematize first?
Start with processes that repeat at least weekly, take more than 15 minutes per execution, and are currently done by only one person (creating a single point of failure). Frequency times duration gives you the total time investment per month. A 30-minute weekly task consumes 2 hours monthly, making it a better first candidate than a 3-hour task you do once a quarter. Also prioritize processes where errors have visible consequences, like client-facing deliverables or financial transactions.
How detailed should my system documentation be?
Detailed enough that a competent person who has never done this specific task in your specific business can produce an acceptable result on their first attempt. The test is literal: hand the document to someone and watch them execute it. Every point where they ask a question or make an error reveals a gap. You do not need to explain basic professional skills (how to write an email, how to use a spreadsheet), but you do need to specify your business-specific choices (which email template, which spreadsheet, which cells to fill in).
Should I build systems before or after assessing my Technician-Manager-Entrepreneur balance?
Assess your balance first using the [assessment skill](/skills/assessing-your-technician-manager-entrepreneur-balance). The assessment reveals how much of your time is spent in each role and where the imbalance lies. If you discover you are spending 80% of your time as a Technician, building systems is the direct corrective action. The assessment provides the diagnosis, and system-building is the treatment. Without the assessment, you might systematize the wrong things or underestimate how much Manager work you need to do.
How long should it take to build a complete, tested system?
Plan for 3-5 hours for your first system, spread across several days. The narration and initial documentation takes 1-2 hours, structuring into the five-component format takes 1 hour, testing with another person takes 30-60 minutes, and revision takes 30-60 minutes. After you have built three or four systems, the process speeds up because you develop a feel for the right level of detail. Subsequent systems typically take 2-3 hours each. Do not rush the testing step, as it consistently reveals gaps that save many hours of confusion later.
What tools should I use for documenting systems?
Use whatever tool your team already works in daily. A system document in Notion is useless if your team lives in Google Docs. A beautifully formatted SOP in Confluence is worthless if no one logs into Confluence. Common choices include Google Docs (simple, shareable, version history built in), Notion (good for linking between systems and embedding checklists), and even shared Google Sheets for process checklists. The tool matters far less than the discipline of maintaining and referencing the documents. Start with plain text. Upgrade to specialized tools only after you have 10 or more active systems.
How do I handle processes that have too many exceptions to systematize?
Processes that feel unsystematizable usually have a stable core with a volatile surface. Separate the two. Document the core steps that happen every time (typically 60-80% of the process), then create a decision framework for the variable parts. For example, a client strategy session has a standard preparation checklist, a standard agenda structure, and standard follow-up actions. The actual strategic advice varies per client, but the process around delivering that advice is repeatable. If after this separation the process is still more than 50% judgment calls, it may not be a good candidate for systematization yet. Focus your energy on higher-repeatability processes.
Why does my system documentation keep drifting from actual practice?
Drift happens for two reasons: the process evolves (tools change, team members find faster methods, client requirements shift) but the document does not, or the document was aspirational rather than descriptive from the start. Fix the first problem by assigning an owner and scheduling quarterly reviews. Fix the second by documenting how the process actually works today, then improving it deliberately through a separate change process. A useful diagnostic: ask the current executor to read the system document and highlight every step that no longer matches reality. If more than 20% of steps are inaccurate, the system needs an immediate overhaul, not a minor revision.