Back to Details

engineering-culture

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Engineering Culture

工程文化

Scope

适用范围

Covers
  • Diagnosing the current engineering culture and delivery system (technical, architectural, cultural, and management capabilities)
  • Defining a clear engineering culture code (principles → behaviors → decision rules → anti-patterns)
  • Aligning org structure with architecture (Conway’s Law) and reducing cross-team friction
  • Increasing clock speed (safe shipping + experimentation throughput) and improving DevEx
  • Creating a practical cross-functional workflow contract (how engineering + PM/Design/Marketing collaborate in the same toolchain)
  • Making AI-assisted development safe and effective (humans as “architects”: spec, review, and oversight)
When to use
  • “Help me improve engineering culture / DevEx and make it concrete.”
  • “Our delivery is slow—build a plan to increase shipping speed without breaking things.”
  • “Our org structure fights our architecture—analyze Conway’s Law and propose changes.”
  • “We want tighter processes and faster experimentation (higher clock speed).”
  • “Non-engineering functions struggle to work with engineering—define a shared workflow contract.”
  • “We’re adopting AI coding tools/agents—set norms so engineers shift toward higher-level design and review.”
When NOT to use
  • You need to respond to an active incident or outage (use incident response/runbooks)
  • You need HR/legal policy, investigations, or employee relations handling (involve HR/legal)
  • You only need to implement a specific technical improvement (e.g., “set up CI”) without culture/org/process work
  • You need a full company strategy/roadmap prioritization across many bets (use 
    prioritizing-roadmap
    )
涵盖内容
  • 诊断当前工程文化及交付系统（技术、架构、文化及管理能力层面）
  • 明确界定工程文化准则（原则→行为→决策规则→反模式）
  • 使组织架构与技术架构对齐（Conway定律）并减少跨团队摩擦
  • 提升交付速度（安全交付+实验吞吐量）并优化DevEx
  • 制定实用的跨职能工作流契约（工程团队与PM/设计/营销团队如何在同一工具链中协作）
  • 确保AI辅助开发安全有效（人类作为“架构师”：负责需求定义、审核与监督）
适用场景
  • “帮我优化工程文化/DevEx，使其落地可执行。”
  • “我们的交付速度太慢了——制定一个计划，在不影响质量的前提下提升交付效率。”
  • “我们的组织架构与技术架构冲突——分析Conway定律并提出改进方案。”
  • “我们需要更严谨的流程和更快的实验节奏（更高的交付速度）。”
  • “非工程职能团队与工程团队协作困难——定义统一的工作流契约。”
  • “我们正在采用AI编码工具/Agent——制定规范，引导工程师转向更高层次的设计与审核工作。”
不适用场景
  • 需处理活跃事件或系统故障（请使用事件响应/运行手册）
  • 需制定HR/法务政策、开展调查或处理员工关系问题（请联系HR/法务团队）
  • 仅需实施特定技术改进（如“搭建CI系统”），无需涉及文化/组织/流程层面的工作
  • 需制定覆盖多个业务方向的全公司战略/路线图优先级（请使用
    prioritizing-roadmap
    工具）

Inputs

输入要求

Minimum required
  • Org context: product(s), stage, engineering size, team topology, on-call model
  • Current symptoms + 2–5 examples (e.g., slow delivery, flaky deploys, low ownership, poor collaboration, high toil)
  • Current delivery system snapshot (release cadence, CI/CD maturity, test strategy, environments)
  • Architecture constraints (e.g., monolith vs services; coupling hotspots; ownership boundaries)
  • Cross-functional workflow reality (where work is tracked, how decisions are made, how releases happen)
  • Desired outcomes (what should be more true in 4–12 weeks?) + timeline constraints
Missing-info strategy
  • Ask up to 5 questions from references/INTAKE.md (3–5 at a time), then proceed with explicit assumptions.
  • If metrics are missing, use best-effort ranges and label confidence; list instrumentation gaps.
  • Do not request secrets, credentials, or proprietary identifiers; use redacted summaries.
最低必填信息
  • 组织背景：产品信息、发展阶段、团队规模、团队拓扑结构、On-Call模式
  • 当前问题症状及2-5个实例（如交付缓慢、部署不稳定、主人翁意识薄弱、协作不畅、重复劳动过多）
  • 当前交付系统快照：发布节奏、CI/CD成熟度、测试策略、环境配置
  • 架构约束（如单体应用vs微服务；耦合热点；所有权边界）
  • 跨职能工作流现状：工作跟踪工具、决策方式、发布流程
  • 期望成果（4-12周后需达成的具体状态）及时间限制
缺失信息处理策略
  • 从references/INTAKE.md中最多提出5个问题（每次3-5个），之后基于明确假设推进工作。
  • 若缺失度量数据，使用合理范围并标注置信度；列出需要补充的监控指标缺口。
  • 不得索要密钥、凭证或专有标识；使用脱敏后的摘要信息。

Outputs (deliverables)

输出成果（交付物）

Produce an Engineering Culture Operating System Pack in Markdown (in-chat; or as files if requested):
  1. Culture + capability snapshot (what’s true today; evidence; capability gaps)
  2. Engineering culture code (v1) (3–7 principles with behaviors, do/don’t, decision rules, anti-patterns)
  3. Org ↔ architecture alignment brief (Conway’s Law analysis + proposed operating model changes)
  4. Clock speed + DevEx improvement backlog (prioritized initiatives with owners, sequencing, metrics)
  5. Cross-functional workflow contract (GitHub/issue/PR/release norms; how non-engineers contribute; AI norms)
  6. Rollout + measurement plan (30/60/90, rituals, metrics + guardrails, feedback loops)
  7. Risks / Open questions / Next steps (always included)
Templates: references/TEMPLATES.md
Expanded guidance: references/WORKFLOW.md
生成一份工程文化操作系统包（Markdown格式，可在对话中展示；若有需求也可导出为文件），包含以下内容：
  1. 文化与能力快照（当前现状、证据、能力缺口）
  2. 工程文化准则（v1版）（3-7条原则，含对应行为、可为/不可为、决策规则、反模式）
  3. 组织↔架构对齐简报（Conway定律分析+拟议的运营模式调整方案）
  4. 交付速度+DevEx优化待办事项（已排序的举措，含负责人、实施顺序、度量指标）
  5. 跨职能工作流契约（GitHub/需求单/PR/发布规范；非工程师参与方式；AI使用规范）
  6. 落地与度量计划（30/60/90天计划、例行会议、度量指标+防护机制、反馈闭环）
  7. 风险/待解决问题/下一步行动（必含内容）
模板参考：references/TEMPLATES.md 扩展指引：references/WORKFLOW.md

Workflow (7 steps)

工作流程（7步）

1) Intake + boundary setting

1) 需求收集与边界设定

  • Inputs: User context; references/INTAKE.md.
  • Actions: Confirm scope (team vs org), decision owner(s), timeline, and constraints. Identify any HR/legal or active-incident concerns and route appropriately. Confirm which deliverables to produce.
  • Outputs: Context snapshot + assumptions/unknowns list.
  • Checks: Scope boundaries are explicit; success definition is stated in observable terms.
  • 输入：用户提供的背景信息；references/INTAKE.md
  • 行动：确认范围（团队级vs组织级）、决策负责人、时间线及约束条件。识别HR/法务相关问题或活跃事件并转介至对应团队。确认需交付的成果内容。
  • 输出：背景快照+假设/未知事项清单
  • 检查项：范围边界明确；成功标准以可观测的指标定义

2) Diagnose the current culture as a delivery system (capability map)

2) 诊断当前文化与交付系统（能力图谱）

  • Inputs: Symptoms/examples; current process/tooling; architecture context.
  • Actions: Build a capability map across technical, architectural, cultural, and management capabilities. Capture evidence and gaps (not platitudes). Distinguish stated culture vs lived culture.
  • Outputs: Culture + capability snapshot (draft).
  • Checks: Each claimed problem has at least one piece of evidence (example, metric, observed behavior) or is labeled “needs data”.
  • 输入：问题症状/实例；当前流程/工具；架构背景
  • 行动：构建覆盖技术、架构、文化、管理四个维度的能力图谱。记录证据与缺口（避免空泛描述）。区分宣称的文化与实际践行的文化。
  • 输出：文化与能力快照（草稿）
  • 检查项：每个提出的问题至少有一个证据支撑（实例、指标、观测到的行为），或标注“需补充数据”

3) Define the target culture (culture code v1)

3) 定义目标文化（v1版工程文化准则）

  • Inputs: Snapshot; constraints; what already works.
  • Actions: Pick 2–4 priority shifts, then write a culture code: 3–7 principles with behaviors, do/don’t, decision rules, and anti-patterns. Prefer rules that increase autonomy while reducing ambiguity.
  • Outputs: Engineering culture code (v1).
  • Checks: Every principle includes a concrete “how we work” example and at least one measurable/observable signal.
  • 输入：现状快照；约束条件；已验证的有效实践
  • 行动：选定2-4个优先级改进方向，撰写工程文化准则：3-7条原则，含对应行为、可为/不可为、决策规则、反模式。优先选择能提升自主性同时减少模糊性的规则。
  • 输出：工程文化准则（v1版）
  • 检查项：每条原则均包含具体的“工作方式”实例及至少一个可度量/可观测的信号

4) Align org structure with architecture (Conway’s Law)

4) 组织架构与技术架构对齐（Conway定律）

  • Inputs: Current team topology; architecture coupling/ownership hotspots; dependency pain.
  • Actions: Map org → architecture fit. Propose changes: team boundaries, ownership, interfaces, and standardization (e.g., leveling definitions, incident policies, review expectations) where misalignment causes friction.
  • Outputs: Org ↔ architecture alignment brief.
  • Checks: Proposed changes include migration/transition steps and explicit trade-offs (what gets worse).
  • 输入：当前团队拓扑结构；架构耦合/所有权热点；依赖痛点
  • 行动：映射组织→架构的匹配度。提出调整方案：团队边界、所有权归属、接口规范及标准化内容（如职级定义、事件处理流程、审核要求），解决因架构与组织不匹配导致的摩擦。
  • 输出：组织↔架构对齐简报
  • 检查项：拟议的调整方案包含迁移/过渡步骤及明确的权衡（哪些方面会受影响）

5) Increase clock speed (safe shipping + experimentation throughput)

5) 提升交付速度（安全交付+实验吞吐量）

  • Inputs: Current shipping/experiment cadence; pipeline constraints; quality constraints.
  • Actions: Define “clock speed” targets and bottlenecks. Propose initiatives that raise throughput safely (small batches, CI reliability, test strategy, progressive delivery, observability). Convert into a prioritized backlog.
  • Outputs: Clock speed + DevEx improvement backlog (draft).
  • Checks: Each initiative has an owner, an effort range, a dependency note, and a metric/leading indicator.
  • 输入：当前交付/实验节奏；流水线约束；质量约束
  • 行动：定义“交付速度”目标及瓶颈。提出可安全提升吞吐量的举措（小批量交付、CI可靠性优化、测试策略调整、渐进式交付、可观测性建设）。转化为已排序的待办事项列表。
  • 输出：交付速度+DevEx优化待办事项（草稿）
  • 检查项：每项举措均包含负责人、工作量范围、依赖说明及度量指标/领先指标

6) Create the workflow contract (including AI norms)

6) 制定工作流契约（含AI使用规范）

  • Inputs: Collaboration pain points; tool constraints; roles.
  • Actions: Specify how work flows from idea → issue → PR → deploy → learn. Define cross-functional participation (where PM/Design/Marketing contribute) and working agreements (review SLAs, merge/deploy policy, experiment ownership). Add AI-assisted development norms: where agents help, human review requirements, and safe data handling.
  • Outputs: Cross-functional workflow contract.
  • Checks: The contract reduces common failure modes (stalled PRs, unclear ownership, “drive-by” requests) and is teachable to new hires.
  • 输入：协作痛点；工具约束；角色定义
  • 行动：明确工作从想法→需求单→PR→部署→复盘的全流程。定义跨职能参与方式（PM/设计/营销团队的参与节点）及工作协议（审核SLA、合并/部署政策、实验所有权）。补充AI辅助开发规范：Agent的适用场景、人工审核要求、安全数据处理规则。
  • 输出：跨职能工作流契约
  • 检查项：契约需解决常见失效模式（PR停滞、所有权模糊、“临时”请求），且可快速传授给新员工

7) Rollout + measurement + quality gate

7) 落地、度量与质量校验

  • Inputs: Draft pack.
  • Actions: Create a 30/60/90 rollout plan with rituals/cadence and training. Define metrics and guardrails (e.g., DORA + quality + DevEx). Run references/CHECKLISTS.md and score with references/RUBRIC.md. Finalize Risks / Open questions / Next steps.
  • Outputs: Final Engineering Culture Operating System Pack.
  • Checks: The first 1–2 actions can start this week; measurement is feasible; risks/trade-offs are explicit.
  • 输入：草稿版操作系统包
  • 行动：制定30/60/90天落地计划，含例行会议/培训安排。定义度量指标与防护机制（如DORA指标+质量指标+DevEx指标）。执行references/CHECKLISTS.md中的检查清单，并使用references/RUBRIC.md进行评分。最终确定风险/待解决问题/下一步行动。
  • 输出：最终版工程文化操作系统包
  • 检查项：前1-2项行动可在本周启动；度量方案可行；风险/权衡已明确说明

Quality gate (required)

质量校验（必做）

  • Use references/CHECKLISTS.md and references/RUBRIC.md.
  • Always include: Risks, Open questions, Next steps.
  • 使用references/CHECKLISTS.md及references/RUBRIC.md进行校验。
  • 必须包含：风险、待解决问题、下一步行动

Examples

示例

Example 1 (slow delivery + DevEx): “Use 
engineering-culture
. Context: B2B SaaS, 35 engineers, monolith + a few services, weekly releases, rising incidents. Goal: increase shipping speed without quality regressions. Output: an Engineering Culture Operating System Pack with a clock-speed backlog and a workflow contract.”
Example 2 (Conway misalignment): “We have 6 teams but architecture ownership is unclear and everything depends on platform. Analyze Conway’s Law issues and propose a new operating model + standardization (leveling, code ownership, on-call) plus a rollout plan.”
Boundary example: “Write a generic essay about what engineering culture is.”
Response: explain this skill produces a concrete operating system pack; ask for context/symptoms/timeline or provide the intake checklist and an example template from references/TEMPLATES.md.
示例1（交付缓慢+DevEx优化）：“使用
engineering-culture
工具。背景：B2B SaaS产品，35名工程师，单体应用+少量微服务，每周发布一次，事件数量上升。目标：在不降低质量的前提下提升交付速度。输出：包含交付速度待办事项及工作流契约的工程文化操作系统包。”
示例2（Conway定律不匹配）：“我们有6个团队，但架构所有权不明确，所有工作都依赖平台团队。分析Conway定律相关问题，提出新的运营模式+标准化方案（职级、代码所有权、On-Call）及落地计划。”
边界示例：“写一篇关于工程文化是什么的通用文章。” 回复：说明本工具用于生成可落地的操作系统包；请求提供背景信息/问题症状/时间线，或提供references/TEMPLATES.md中的需求收集清单及示例模板。