[{"content":" ","permalink":"https://ray-han.com/fbcs_application/awards/","summary":"\u003cmeta http-equiv=\"refresh\" content=\"0;url=/fbcs_application/#awards\"\u003e","title":"Awards"},{"content":" ","permalink":"https://ray-han.com/fbcs_application/innovation/","summary":"\u003cmeta http-equiv=\"refresh\" content=\"0;url=/fbcs_application/#invention-and-innovation\"\u003e","title":"Innovation"},{"content":" ","permalink":"https://ray-han.com/fbcs_application/mentoring/","summary":"\u003cmeta http-equiv=\"refresh\" content=\"0;url=/fbcs_application/#mentoring-and-coaching\"\u003e","title":"Mentoring"},{"content":" ","permalink":"https://ray-han.com/fbcs_application/responsibility/","summary":"\u003cmeta http-equiv=\"refresh\" content=\"0;url=/fbcs_application/#responsibility\"\u003e","title":"Responsibility"},{"content":"Why? When advancing complex projects with Vibe Coding, relying on a single Agent quickly hits a capability bottleneck. First, the context window fills up with low-value information, forcing task interruptions. Second, mixing different roles like search, planning, and coding in one process lowers efficiency and increases errors. Finally, security concerns arise: lacking a global plan leads to redo work, and no permission isolation risks dangerous operations.\nAn Agent Team separates roles—planning is planning, execution is execution, and reading is separated from writing—alleviating the first two problems significantly. Harness adds a layer of control: assigning permissions, matching models, managing context, and constraining behavior. However, off-the-shelf solutions rarely fit directly since each project’s tech stack, development standards, task types, and workflows differ. One-size-fits-all solutions struggle to meet real needs.\nFortunately, customizing your own system isn’t complicated. Open a multi-Agent-supporting IDE or CLI tool (like Claude Code or OpenCode) and follow three key steps: design architecture and roles, manage permissions, models, and context, and add a Plan workflow. There’s also a faster option: import a ready-made Team + Harness framework and tailor it to your project’s specific requirements.\nStep One: Design Architecture and Roles Start Simple You don’t have to build a complete multi-role team from the start. Begin with a single Agent, hereafter called the Builder, roughly equivalent to a default Build Agent in most AI coding tools. As task complexity grows, gradually split roles as needed. Each role is effectively a Sub-agent that takes on specialized tasks delegated by the Builder:\nBuilder handles all work initially; if context or efficiency bottlenecks arise, consider splitting duties. Add read-only roles Explorer / Researcher: responsible for search and information collection, offloading retrieval work from the main Agent. Add Coder: focused on code implementation and modification to improve code quality and consistency. Add Planner: manages planning and task breakdown for multi-file or multi-step complex tasks. Extend with roles like Reviewer or General as needed for review, general assistance, or permission isolation. \u0026ldquo;The best agent architecture is the one you don\u0026rsquo;t need to build. Start simple. Add complexity only when metrics prove it helps.\u0026rdquo; —Reliable Data Engineering\nCore Design Principles Separate Planning and Execution: Planning (deciding what to do and task breakdown) and execution (actual coding and modification) engage different cognitive processes and should be handled by separate roles to avoid frequent context switches and errors. Separate Reading and Writing: The risks and costs of reading/searching information versus writing code differ sharply. Reading errors mainly waste time; writing errors can break the project. Assign retrieval tasks to read-only roles and code modification tasks to roles with permissions and review workflows. Separate Internal and External Searches: Internal codebase search and external internet research require different tools and strategies. Codebase search relies on project structure understanding (like Glob/Grep/Read), while internet search focuses on keywords, source evaluation, and info synthesis. Combining both in one role leads to bulky tools or conflicting strategies. Design and manage them separately. Builder’s Routing Decisions The Builder is the team’s decision-maker, using the most capable general-purpose model (e.g., Claude Opus). It rarely codes directly; its core duty is routing tasks to the most suitable roles.\nA common routing schema looks like this:\nTarget Agent Main Function Coder Code implementation/modification Explorer Codebase search (read-only) Researcher Web and external data research Reviewer Code review and quality control General Handle general subdividable tasks Builder Minor edits or urgent rollbacks Humans must clearly describe each Agent’s responsibilities and let the Builder’s underlying model decide whom to delegate. Adjust routing rules and thresholds based on performance. Over time, introduce quantitative metrics like delegation success rate, rollback count, and task completion time to iteratively optimize the division of labor.\nAdditional Behavioral Rules These can be initially added to the Builder’s prompt, with specific numbers left for the model to decide and refined later:\nPrefer Delegation: When uncertain, delegate first to avoid Builder becoming a jack-of-all trades swamped by context details. 3-Failure-Stop: Stop and ask the user after 3 consecutive failures on the same subtask; avoid infinite retries. Plan Before Action: For tasks involving more than five files or multiple steps, assign a Planner to create a plan first instead of rushing to finish. Confirm Before Declaring Done: Before declaring completion, verify all parts are handled, code is reviewed, and tests pass. Overview of Roles Roles are realized as Sub-agents that take delegated tasks from Builder. There’s no fixed number of roles; if a task type occurs frequently and needs distinct capability or permissions, it’s worth creating a dedicated role:\nCoder (coding executor): Uses a capable, cost-effective model to implement analyzed tasks. Cannot call Task (no recursive delegation) or use Skill. Hard constraints include: cannot pass tests by deleting existing ones, cannot deliver code with TODO or empty functions, must run tests and report results.\nExplorer (internal analyst): Read-only codebase search. Tools: Glob / Grep / Read. Output must include a Not found section listing searched but unhit items explicitly.\nResearcher (external researcher): Read-only info gathering on the internet. Tools: web search / URL fetch / GitHub browsing. All URLs and references must appear in the final report. Search language affects quality; English is recommended due to richer, more reliable tech content. Cross-verify to avoid hallucination and misinformation.\nReviewer (review and quality control): Uses code-specialized model with reasoning capabilities. Review priority: Completeness \u0026gt; Correctness \u0026gt; Quality. Output must be one of PASS / WARN / FAIL. Also used to review Plan.\nCommon design for read-only roles: Explorer, Researcher, and Reviewer have no edit or bash permissions to isolate side effects and prevent accidental file changes during read operations.\nGeneral (generalist): Has the highest allowed independent steps, full toolset, and can schedule Sub-agents. Used for tasks that are dividable but hard to categorize or cross-domain complex tasks.\nCompaction (context compression): Uses long-context models with reasoning enabled to decide which messages to keep.\nStep Two: Manage Permissions, Models, and Context Permissions: Least Privilege Each role should retain only the minimal permissions needed to perform its tasks:\nRole edit bash task skill web Builder ✓ ✓ ✓ ✓ ✓ Planner edit only isolated .plan dir ✓ ✗ ✓ ✓ Coder ✓ ✓ ✗ ✗ ✗ Explorer ✗ ✗ ✗ ✗ ✗ Researcher ✗ ✗ ✗ ✗ ✓ Reviewer ✗ ✗ ✗ ✗ ✗ General ✓ ✓ ✓ ✓ ✓ Many AI Agents tend to \u0026ldquo;do as much as possible.\u0026rdquo; If given edit permission, they may modify files during research; if given task permission, they may further delegate even simple problems. Explicitly restricting permissions ensures each role sticks to its job.\nTypical example: If Coder has task permission, it might delegate tough problems to Researcher or Explorer instead of solving them directly. This breaks Builder’s routing logic, wastes tokens, and keeps Builder unaware. Correct practice: Coder handles what it can by coding; if stuck, returns the problem to Builder.\nModel Matching Different tasks require different intelligence levels. The most expensive models go to tasks needing the most judgment.\nTier Model Type Roles Thinking Enabled Reason Flagship Most powerful model Builder, Planner Yes, large budget Routing and planning decision quality directly impacts end-to-end efficiency Execution Cost-effective model Coder Yes, small budget Tasks are analyzed and focused on instruction compliance General Varies by complexity General Optional Tasks have fuzzy boundaries and require cross-domain coordination Search Lightweight models Explorer, Researcher Optional Search is deterministic, prioritizing speed, cost, and tool call success rate Long context Long window models Compaction — Needs to first comprehend large context before compressing When configuring, also consider multi-provider mixing and fallback strategies to benchmark performance, cut costs, and mitigate single points of failure.\nContext Management and Information Isolation Context is the scarcest resource; a tight context window quickly degrades model performance. Every bit of context should be used efficiently:\nSub-agents communicate with Builder only via final messages; intermediate steps are invisible to Builder. Builder just needs “task done, result is XXX”; detailed process info is provided only on exceptions.\nCompaction can use three strategies simultaneously: auto (automatic triggers), prune (active trimming), and reserved (reserved space).\nStep Three: Add the Plan Workflow to Handle More Complex Tasks Why Plan Before Execution? For complex tasks, invoking Builder directly without planning leads to four typical problems:\nInsufficient context window (already discussed). Lack of global view: Agent changes first file, then mid-way discovers conflicts in file three, requiring rework. No recoverability: interruption or context exhaustion causes progress loss; must start over. No auditability: Humans don’t know Agent’s intent until after execution, risking costly misdirection. The two-phase Plan-Execute workflow addresses these issues. We add a dedicated Planner responsible for crafting structured Plan files.\nPlanner Agent Planner takes complex tasks and outputs structured Plan files. Plans are persisted as files, bringing four benefits:\nGlobal view isn’t lost due to context exhaustion. Progress can resume after interruption. Both machine and human can review and adjust plans before execution (human-in-the-loop). Planner has read/write access restricted to a specific directory (e.g., ./plans/\u0026lt;name\u0026gt;.md), physically isolating planning from execution.\nStructure of the Plan File The Plan file is a structured execution checklist with three core design points:\nBatch Thinking: Tasks in the same batch are independent and can run in parallel; batches have dependencies and must run sequentially. Parallel execution drastically speeds things up but requires logic to identify true independence—this judgment is the Planner’s responsibility.\nFive Elements of a Task:\nAssigned role: which Sub-agent executes it. Description: executable task explanation including files and expectations. Involved files: list of files to create, modify, or read. Verification criteria: clear checks. Status flags: pending / in-progress / completed / blocked Mandatory final verification batch: The last Batch must include integration tests and final review. Passing individual tasks doesn’t guarantee overall correctness—e.g., Task A changes an interface, Task B still uses old interface; each test passes alone but combined fails.\nExecuting the Plan Executing the plan is managing a state machine to drive tasks from pending to completed. A simple Skill can describe this.\nCore execution steps:\nLoad the Plan file and scan all task statuses. Find the first incomplete Batch and start executing it. For each task: mark as in-progress and write to file → delegate to Agent → on response update status and write immediately. Batch gate: only after all tasks in current batch finish can the next batch start. Execute the final verification Batch. Checkpoint recovery: If tasks marked in-progress remain on load, it means last execution was interrupted. Recovery steps:\nLocate interrupted tasks. Assign Explorer to assess damage: Are files complete? Are there TODO placeholders? Does the project compile? Based on assessment: completed → validated by Reviewer; partial → continued by Coder; damaged → fixed by Coder. Core principle: Never assume interrupted work is done.\nAdditional Behavioral Rules Scope Per Delegation: No delegating to Coder tasks involving more than 5 files at once; split bigger tasks. Done Means Verified: Completion criterion is meeting verification checks, not just \u0026ldquo;code written\u0026rdquo; or \u0026ldquo;all tasks delegated\u0026rdquo;. Persist Progress Eagerly: Write status changes to file immediately. Specification Drift Check: After all batches, re-read Goal and Verification Criteria word by word, compare with outputs to detect any silent feature creep, missing requirements, or deviations. Advanced Concept: Ralph Loop For even more complex projects needing long AI autonomy with clear goals, you can introduce the Ralph Loop method.\nIn March 2026, Anthropic accidentally leaked all 512,000 lines of TypeScript source code for Claude Code. A Korean developer, Sigrid Jin, rewrote the entire codebase from TypeScript to Python in two hours using Ralph Loop, without writing a single line manually—fully relying on Agent-driven iterative development until success.\nRalph Loop’s key idea: break requirements into independent items, process one per iteration, proceed only after passing validation; each iteration starts a fresh Agent context. Memory between iterations is passed through files (git history, progress files, requirement status), avoiding context degradation from long runs.\nThe flow:\nList all requirements, mark each as passed or failed. Launch fresh Agent context and pick the highest priority unmet item. Implement and validate it; if pass, mark done. Append experience to progress file for next iteration’s reference. Repeat until all pass or reach max iterations. Ralph Loop can be implemented as a Skill, invoked and driven by the Builder to repeatedly execute the existing Agent Team.\nSummary Building an Agent Team is fundamentally architectural design, not just Prompt engineering. It’s like designing microservices or team workflows. Interestingly, once you start splitting roles, defining permissions, and designing state transitions, you realize these insights reflect how human teams work: why clear responsibility boundaries matter, why persistent workflows matter, why review and testing can’t be skipped. Agents hold up a mirror, reflecting your understanding of organizing work.\n","permalink":"https://ray-han.com/articles/personalized-agent-team-harness/","summary":"\u003ch2 id=\"why\"\u003eWhy?\u003c/h2\u003e\n\u003cp\u003eWhen advancing complex projects with Vibe Coding, relying on a single Agent quickly hits a capability bottleneck. First, the context window fills up with low-value information, forcing task interruptions. Second, mixing different roles like search, planning, and coding in one process lowers efficiency and increases errors. Finally, security concerns arise: lacking a global plan leads to redo work, and no permission isolation risks dangerous operations.\u003c/p\u003e\n\u003cp\u003eAn Agent Team separates roles—planning is planning, execution is execution, and reading is separated from writing—alleviating the first two problems significantly. Harness adds a layer of control: assigning permissions, matching models, managing context, and constraining behavior. However, off-the-shelf solutions rarely fit directly since each project’s tech stack, development standards, task types, and workflows differ. One-size-fits-all solutions struggle to meet real needs.\u003c/p\u003e","title":"Building a Personalized Agent Team and Harness"},{"content":"Many engineers and teams have already integrated AI into their everyday workflows, but when it comes to selecting tools, they still rely mostly on intuition or reputation. This often leads to fluctuating efficiency and uncontrollable costs. In a fast-iterating product market, chasing the \u0026ldquo;best tool\u0026rdquo; or blindly following benchmarks tends to focus attention on the tools themselves rather than the core question: what specific work scenarios do we need to accomplish?\nA more reliable approach treats tool selection like workflow design: first break down your workflow into clear, distinct scenarios—such as daily Q\u0026amp;A, in-depth research, coding execution, code review and merge—and then for each scenario, match the most appropriate tools and models rather than searching for a one-size-fits-all solution. This makes your decisions explainable, replaceable, and stable over the long term—even if specific products change often, the framework remains valid.\nTherefore, I recommend a three-step process when selecting AI tools: clarify the responsibilities and boundaries of each tool → match model capabilities to tasks → design layered procurement and redundancy. The combinations below are based on my personal experience from late 2025 to early 2026.\nGeneral AI Assistants: Q\u0026amp;A and Research These tools don\u0026rsquo;t interact directly with your code repositories; their roles include answering daily questions, searching information, and supporting deeper, longer-chained research. Separating them from development execution tools helps clarify later selection decisions.\nTool Main Use Notes Gemini Everyday technical Q\u0026amp;A Globally stable access, top-tier search ability, strong hallucination control, $15/month good bang for the buck Manus In-depth research (technical reports, investment analysis) Max model is expensive, but output quality justifies cost—$1 buys a logically clear, well-sourced deep analysis Google NotebookLM Deep research (knowledge organization and summary) Uses doc libraries as knowledge sources, supports multi-turn, contextual deep Q\u0026amp;A and synthesis Development Tools (IDE/CLI): Execution and Delivery Once you’re in the core development workflow, you need tools that directly interact with code, repositories, and your review process. This layer determines delivery efficiency.\nTool Core Positioning \u0026amp; Notes OpenCode (CLI/Web UI) Open-source alternative to Claude Code; fast iteration, strong customizability, stable access. Value lies not in single-point abilities but as an easy-to-access, simple-interaction multi-agent collaboration platform GitHub Copilot (Web) Typical workflow: select repo, describe requirements, launch VM, automatically fix issues, initiate PR review, discuss changes, merge. Suited for medium-complexity, end-to-end automated tasks Zed (Editor) Lightweight IDE; can integrate OpenCode in sidebar Trae, VS Code + Extensions Deprecated OpenCode\u0026rsquo;s key is the oh-my-opencode plugin, a multi-agent collaboration system with fine-grained role division. Although this design leads to frequent agent interactions, longer task chains, and high token consumption, it ensures delivery quality in complex technical scenarios. Once familiar with interaction patterns and matching models to roles, it supports hours-long, continuous autonomous technical discussions.\nGitHub Copilot Web represents a different path: highly integrated, scenario-closed, striving for end-to-end automation. It minimizes multi-turn deep interactions and focuses on one-stop solutions from issue description to code merge. For clearly bounded medium-complexity tasks, it delivers extremely high efficiency and integrates seamlessly with GitHub\u0026rsquo;s development review flow—experience-wise, it\u0026rsquo;s close to contributing full code to open source projects.\nEach has its strengths: OpenCode emphasizes control and depth, GitHub Copilot prioritizes automated closed loops. In practice, teams often use both complementarily—OpenCode for complex architectural discussions, Copilot for specific bug fixes.\nModel Selection: Matching Capabilities by Scenario After fixing tools, the next step is selecting models tailored to each task scenario.\nDomain/business understanding tasks are special: they depend entirely on user-supplied context (business docs, historical code, decision records). Here pretrained model knowledge can cause hallucinations, so model choice is less sensitive—window size matters more.\nAside from domain understanding, typical scenarios get assigned different models and strategies:\nScenario Preferred Model Secondary/Backup Key Considerations \u0026amp; Notes Task decomposition \u0026amp; workflow planning Claude Opus 4.6 Kimi K2.5 Requires very strong logic and step planning, understanding complex constraints. Opus is near perfect here. Solution and code review GPT 5.3-Codex Claude Opus 4.6 Demands strict code quality review, vulnerability detection, and architectural judgment. Comprehensive development (architecture discussion and coding) Claude Opus 4.6 GLM-5-Turbo Needs instruction-following and deliverable code. GLM-5-Turbo is mostly reliable but less stable. Independent closed problem solving GPT 5.4 Pro - Single-model single-agent, good for one-off answer tasks like implementing an algorithm without external input. Simple code implementation Kimi K2.5 MiniMax M2.5 Highly cost-effective for function filling, simple scripts, data transforms. Requires clear scope and small tasks. MiniMax is faster but rougher. Search \u0026amp; project understanding Any cheap model - Focuses on combining MCP search and language server calls for live info and code semantics; model capability secondary. Multi-language technical writing Gemini / GPT / Claude - Styles differ: Gemini is rigorous, GPT fluent, Claude structurally clear—pick accordingly. Chinese tech writing Claude Opus 4.6 GLM-5 Greater emphasis on logic and accurate expression. Development documentation writing Claude Opus 4.6 - Needs clear, structured expression of complex technical decisions. Opus has strongest logic. To set expectations quickly: Opus resembles an experienced senior engineer whose outputs still require end-to-end verification; GLM-5 acts like a competent but less stable engineer; Kimi K2.5 and MiniMax M2.5 are cheap interns reliable only on deterministic tasks; Claude Sonnet/Haiku have many better cost-effective Chinese market alternatives and are generally unnecessary.\nCloud Service Procurement Once models and tools are chosen, the final question is procurement. Key rule: don’t put your entire budget on a single vendor; diversify purchases by task risk level and keep redundancy on critical paths.\nService Monthly Fee Notes Zhipu Coding Plan Pro ¥499 Provides GLM-5 and others, but SLA unstable with occasional faults Volcano Ark Coding Plan ¥200 Average model with delayed updates; benefits are ample quota and low latency, suited for low-cost bulk tasks GitHub Copilot Pro+ $39 High quota, but token consumption triples when used with Claude Opus 4.6; strict cost control required OpenCode Zen Pay-as-you-go Multi-model aggregation service, deeply integrated with OpenCode ecosystem for unified management and scheduling PPIO Pay-as-you-go Provides GLM-5 service with good latency stability; backup when Zhipu is unstable Conclusion Efficiency gains come not from chasing the strongest model but from continuously decomposing workflows and matching tools/models to scenarios. You don\u0026rsquo;t need to get everything perfect initially—starting by separating general AI assistants and development execution tools and clearly distinguishing scenarios already beats intuition-based tool selection. Later, refine model division and procurement based on actual pain points and budget.\nNote that using multiple tools and models involves switching costs and learning curves, so factor in adaptation time.\n","permalink":"https://ray-han.com/articles/ai-selection-combination-strategy/","summary":"\u003cp\u003eMany engineers and teams have already integrated AI into their everyday workflows, but when it comes to selecting tools, they still rely mostly on intuition or reputation. This often leads to fluctuating efficiency and uncontrollable costs. In a fast-iterating product market, chasing the \u0026ldquo;best tool\u0026rdquo; or blindly following benchmarks tends to focus attention on the tools themselves rather than the core question: what specific work scenarios do we need to accomplish?\u003c/p\u003e","title":"AI Selection: Scenario-Distinguished Combination Strategy"},{"content":"In internet company R\u0026amp;D, there\u0026rsquo;s a common archetype: the engineer drowning in demands. Back-to-back meetings all day, hundreds of unread messages, a backlog that only grows. At the end of the day, it feels like everything got touched but nothing got done. Meanwhile, the high-value long-term work you know matters — value analysis, key technical challenges, system refactoring — never gets started.\nIf this lasts a week, it\u0026rsquo;s just a busy stretch. If it persists for months, you need to step back and solve the problem differently.\nWhy This Happens The internet industry moves fast, so this isn\u0026rsquo;t a one-week problem: organizations constantly restructure and chase new growth, iteration cycles are short, and business dependencies are complex. Demands are generated faster than any individual can absorb them. The harder you chase, the further behind you fall. Eventually you\u0026rsquo;re stuck in the weeds, unable to discover new value.\nSince you can\u0026rsquo;t finish everything, the real question isn\u0026rsquo;t how to finish it all — it\u0026rsquo;s deciding what to do and what to skip, so you can carve out time for long-term, high-value work.\nHow do you break out? My recommendation: build a working principles document. Below is what it should contain, why, and how to use it.\nHow to Do It The document isn\u0026rsquo;t complicated. Call it \u0026ldquo;Working Principles\u0026rdquo; or something softer like \u0026ldquo;How to Work With [Your Name].\u0026rdquo; Put the link in your team wiki or chat profile so anyone with a request can find it.\nSection 1: Define your scope. State what you\u0026rsquo;re responsible for and what you\u0026rsquo;re not. This lets requesters quickly determine whether they\u0026rsquo;ve found the right person.\nSection 2: Prioritized short-term requests. This is what requesters care about most.\nFirst, lay out your priority principles by category. For example: production incidents \u0026gt; committed deliverables \u0026gt; items blocking others \u0026gt; new business requests \u0026gt; internal optimization and exploratory work. This establishes the overall ordering.\nThen within each category, rank by value and urgency, and place them in a table:\nType Item Estimated Value Estimated Effort Urgency Requester Expected Delivery … … … … … … … Four key points:\nThe most important column is \u0026ldquo;Estimated Value.\u0026rdquo; If something has no value, urgency alone doesn\u0026rsquo;t justify doing it. The ordering commits to delivery sequence — items higher up will be completed before items lower down — but it does not promise that everything will eventually get done. Always estimate expected delivery dates, and include some buffer, because higher-priority requests may arrive at any time. When a new request comes in, re-sort according to your principles, update delivery estimates, and notify anyone affected. Section 3: Reserve time for high-value work. Short-term requests carry built-in urgency. If you can never finish them, you\u0026rsquo;ll never have time for long-term work. So the document must explicitly state when long-term work happens. Two common approaches:\nBlock two hours every day. Block one or two full days per week. Defend the time allocation as a hard floor. If high-value work falls short in a given period, make it up at the start of the next day or week.\nSection 4: Handle trivial requests on the spot. For anything solvable in under ten minutes without a context switch, just do it immediately. Ten minutes is a reference threshold — adjust to your situation, but you must have a concrete number, otherwise everything becomes \u0026ldquo;trivial.\u0026rdquo; For must-do-today trivial items, commit to batching them in a fixed time slot before end of day.\nWith these four sections, the document is complete.\nMake It Public Principles that aren\u0026rsquo;t shared don\u0026rsquo;t resolve conflict — they just defer it. But once the document is public, the dynamic flips. As long as the principles are reasonable, requesters will read Section 1 and self-filter, then look at Section 2 to understand your reasoning and timelines.\nIf someone insists their request is more important, they now need to argue why it should jump the queue — which means making a case against every item ranked above theirs. The burden of justification shifts to the requester, not you. This also gives you a defensible way to push back when your manager drops in something unimportant.\nApplying It People stuck in execution mode share a common habit: they accept every request without weighing it. Their first reaction to any incoming task is \u0026ldquo;what is this and how do I solve it\u0026rdquo; — skipping the prior question of \u0026ldquo;should this be done at all, and how important is it?\u0026rdquo;\nSo for every incoming request:\nInvest the effort to determine exactly which section and category it falls into, and where it belongs in the order. This requires communicating around the principles you\u0026rsquo;ve established, understanding the request deeply, and explaining the reasoning to the requester when needed. Identify where the document doesn\u0026rsquo;t fit reality, and continuously refine both the document and the principles. Turn exceptions into standard cases, and make the standard cases more effective. Measuring Effectiveness You need a set of metrics to verify the system is actually working. I recommend three layers, from low to high:\nLayer What to Watch Typical Metrics Execution Request flow Weekly new requests, weekly resolved, backlog size, average delivery time Structure Time allocation Actual ratio of long-term vs. short-term work, trivial-task ratio, number of queue-jumps Value Value delivered What was the highest-value output each cycle, and did it come from long-term or short-term work? The three layers are progressive. But the one that truly matters is the value layer — the other two exist to diagnose which link failed when something goes wrong. Looking only at execution is misleading: high throughput might just mean you\u0026rsquo;re rapidly processing low-value requests. Looking only at structure isn\u0026rsquo;t enough either: spending time on long-term work doesn\u0026rsquo;t guarantee you produced anything new.\nClosing Before this document exists, you and your requesters have no shared frame of reference — every new request triggers a fresh priority negotiation from scratch. Once the document is published, disputes have a ruleset to reference, and communication shifts from repeated one-on-one explanations to collective trade-offs against a shared set of principles. The work still won\u0026rsquo;t all get done, but the feeling of being dragged along will stop. You can step back and focus on value.\n","permalink":"https://ray-han.com/articles/escape-dev-execution-overload/","summary":"\u003cp\u003eIn internet company R\u0026amp;D, there\u0026rsquo;s a common archetype: the engineer drowning in demands. Back-to-back meetings all day, hundreds of unread messages, a backlog that only grows. At the end of the day, it feels like everything got touched but nothing got done. Meanwhile, the high-value long-term work you know matters — value analysis, key technical challenges, system refactoring — never gets started.\u003c/p\u003e\n\u003cp\u003eIf this lasts a week, it\u0026rsquo;s just a busy stretch. If it persists for months, you need to step back and solve the problem differently.\u003c/p\u003e","title":"Breaking Out of the \"Never-Ending\" Execution Trap"}]