Tags
Writing, research, projects, and photos around “Engineering”.
A consultation about a high-pressure blended role: looking past the schedule to the business goal, shared expectations, resources, and authority the work requires.
Consulting
7 min read
Part of the column “Engineering Teams & Technical Judgment” · Chapter 1
An edited consultation about an FDE conference, technical communication, and AI’s business value: when owners care about revenue and cost, how can technical people explain their work as a result worth testing?
Consulting
9 min read
Part of the column “Consulting & B2B Business” · Chapter 1
A learning protocol for search delay, CUPED, page versions, and traffic incidents.
Case
2 min read
Part of the column “Search Engine Growth” · Chapter 8
A recoverable URL state machine and an incident workflow for separating submission, crawling, indexing, and algorithm context.
Case
3 min read
Part of the column “Search Engine Growth” · Chapter 4
A project-based introduction to discovery, crawling, indexing, clicks, and business conversion.
Case
3 min read
Part of the column “Search Engine Growth” · Chapter 1
A page contract for identity, crawl boundaries, rendering, migrations, and Core Web Vitals.
Case
3 min read
Part of the column “Search Engine Growth” · Chapter 3
A practical value model for search, page consumption, Web2App handoff, and retention.
Case
3 min read
Part of the column “Search Engine Growth” · Chapter 2
This paper examines task decomposition, subtask capability classification, model selection, and bounded execution-time fallback, while reducing the broader Agent scheduling problem to an engineering slice of dsh-quota-router.
13 min read
Read summaryA position paper: functional lines were efficient in an era of highly specialized work; once tools lower skill barriers, organizations should be redesigned around end-to-end business capability. It provides the mechanism, a spectrum of organizational forms, judgment signals, the two Chinese and American starting points, talent needs, and a falsifiable pilot protocol.
14 min read
Read summaryAn uncompressed question bank: prepare promotion materials, interview answers, and stage reviews item by item across business, technology, team, individual judgment, and organizational capability.
Short
18 min read
Functional lines once made specialized capability run efficiently; once tools lower workflow barriers, organizations should redesign around end-to-end business capability rather than cling to historical divisions of labor.
Short
2 min read
Part of the column “Technical Systems” · Chapter 5
A multi-region system can neither cram every difference into a single core nor rebuild everything for each region. The key is to identify stable boundaries, preserve extension points, and clarify module ownership.
Short
3 min read
Part of the column “Technical Systems” · Chapter 4
Every role owns its own delivery, and everyone shares accountability for production outcomes. A quality loop depends on monitoring, fast containment, precise fixes, and retrospectives.
Short
2 min read
Good standards don't turn every step into an approval; they make the key handoff points — where distortion, rework, and accidents are most likely — visible, discussable, and reusable.
Short
2 min read
Part of the column “Technical Systems” · Chapter 3
A manager's distance from the code shouldn't be a fixed number but a consequence of the goal: close enough to judge architecture, risk, and blockers, far enough to spend energy on defining problems, unblocking collaboration, and securing authority upward.
Short
3 min read
Code decay rarely comes from any single moment of bad writing; it comes from local changes repeatedly bypassing shared boundaries. What truly needs maintaining is the consistency between design and collaboration.
Short
2 min read
Part of the column “Technical Systems” · Chapter 2
Technology can't manufacture a selling point out of thin air, but engineers can still help the team understand users more precisely, shorten validation cycles, and turn implicit constraints into choosable problems.
Short
2 min read
From the resume and fundamentals to the project presentation: an interview is not about guessing a standard answer, but about letting people see your facts, judgment, learning style, and way of collaborating.
Short
10 min read
Product sense isn't guessing at requirements. A ready-to-use list of talking points, from two angles: how engineers should understand the product, and what product managers actually do.
Short
2 min read
Part of the column “One-on-One Conversations” · Chapter 6
From completing requirements to taking part in planning, how engineers place technical implementation between user problems and business outcomes.
Short
13 min read
Part of the column “Product Judgment” · Chapter 1
An engineering POC is neither a project secretary nor someone who covers for everyone else; the role exists to keep goals, commitments, risks, and decisions clear in cross-functional collaboration.
Short
6 min read
Self-use isn't about 'spending more time in the product'; it's a feedback system spanning real tasks, valid evidence, and verified fixes.
Short
4 min read
Facing cross-functional requirements, how should an engineering POC divide work, surface risks, handle changes, and manage their own workload? A public FAQ for real-world collaboration.
Short
11 min read
The value of an engineering retrospective is not in retelling what happened or blaming individuals, but in turning an experience into improvements that can be verified, maintained, and reused.
Short
6 min read
An entry page is not a pile of links, but the shared memory a constantly changing project leaves for its team: it helps readers enter by task, judge whether information is still valid, and find the people responsible for maintaining it.
Short
5 min read
Part of the column “Documentation & Knowledge” · Chapter 2
An index of interview and engineering fundamentals compiled after the spring 2018 job search; keeping it as a reminder that interview questions are never just interview questions.
Method
1 min read