Tags
Writing, research, projects, and photos around “Engineering”.
A 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.
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.
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.
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.
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.
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.
Part of the column “Technical Systems” · Chapter 3
Managers don't need to review every line of code, but if they drift away from front-line detail they lose the ability to judge risk, cost, and what is really blocking the team; the point is to build sampling-based understanding, not micro-control.
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.
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.
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.
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.
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.
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.
Self-use isn't about 'spending more time in the product'; it's a feedback system spanning real tasks, valid evidence, and verified fixes.
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.
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.
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.
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.