Essential Practices for Effective Engineering Projects and R&D Management

Customer (User)

(1) Make your customers happy; otherwise the rest of the article is irrelevant.

(2) Start with the right number of customers (often just one) and the right kind of customer (who allows you to build core technology), and increase the number carefully.

(3) Interact directly with customers; many internal conflicts can be resolved by saying, "I just talked to the customer, they said…".

(4) Recognize that customers may not be able to articulate their true needs; spend time deeply understanding their use‑cases and even read their code.

Project Management

(5) Have a clear mission statement; e.g., "We will become the reliable foundation for FB infra."

(6) Re‑evaluate task difficulty repeatedly; decision‑makers often lack the time or context to assess correctly.

(7) Assign tasks to individual contributors (ICs) strategically; stay on the critical path because you usually know the problem and codebase better than managers.

(8) Treat the roadmap as a means, not an end.

(9) Support and tolerate good managers; if you lack such a manager, seek clarification.

(10) Build projects robust to organizational changes; ensure manager turnover does not create unfair career outcomes for ICs.

Organizational adjustments are frequent; preventing unfair outcomes for ICs is challenging.

(11) Track how long similar features take in other projects to benchmark task difficulty.

Design

(12) Be conservative on APIs and liberal with implementations.

(13) Introduce new implementations cautiously (gradual roll‑out).

(14) When designing APIs, code the first implementation, plan the second, and hope the third will work.

(15) Design APIs with migration to new implementations in mind; avoid custom migrations that are costly and unreliable.

(16) Design as a team, implement as individuals; resist parallel design impulses.

(17) For storage systems, prioritize consistency and durability over availability early on.

(18) Maintain multiple API implementations in tests and compare results.

(19) Use late binding: encourage the team to explore the whole design space before committing to a solution.

(20) After design, any IC should be able to write code for the implementation.

(21) Keep the right amount of abstraction—neither too few (monolith) nor too many (cognitive overload).

(22) Avoid relying on real‑time guarantees for correctness unless you understand clock error bounds.

(23) Maintain a single source of truth and simple invariants across state types.

(24) Cultivate a culture where ICs constantly explore alternative designs and stay curious.

(25) Understand your SKU; hardware knowledge remains crucial despite cloud abstraction.

Code Review

(26) In a fast‑review, transparent codebase, guard against API leakage of implementation details.

(27) Encourage critical thinking on diffs and create an environment where reviewers are thanked, not rebuked.

(28) For critical components, consider informal rules such as requiring two LGTM approvals.

(29) Do not equate delivery speed with importance; allow longer review cycles for high‑quality work.

(30) If a design proves wrong after an IC proposes it, resist the urge to ship and then fix; allow discarding faulty code.

Strategy

(31) Regularly ask why the team/project exists and how it adds value to the company.

(32) Track other major projects in your domain; be able to explain their technical designs better than their own ICs.

(33) Avoid competing on raw performance; focus competition on fundamental design attributes.

(34) If another team has a better system for your use‑case, consider adopting it.

Observability

(35) Measurement is a means, not an end.

(36) Detect service issues before customers do.

(37) Place observability above APIs and outside implementations to enable easy switching and comparison.

(38) Pay special attention to hard‑to‑measure attributes like consistency.

(39) Push critical checks (e.g., consistency) into deployments and minimize external service checks.

Research

(40) Track research outcomes in your field to quickly combine ideas across projects.

(41) Favor novel solutions within feasible bounds; resist copying designs verbatim.

(42) Write papers for audiences unfamiliar with your work to clarify assumptions and attract talent.

Disclaimer & Promotion

The article concludes with a disclaimer that the shared materials are collected from the internet, belong to original authors, and are provided for learning purposes only; it also includes a promotional invitation to join an architecture community for additional resources.