团队文化
在 LeanCloud 的工作体验非常特别。这种特别很大程度上来自它是一个由工程师主导的团队。工程师直接面对产品和用户，个人有充分的判断空间，也承担完整的责任；团队通过公开的信息、共同的规则和彼此的专业判断来组织协作。这套工作方式让一个规模不大的团队能够维护多条产品线，也要求每个人理解更广的上下文，并对自己的决定和协作结果负责。
工程师主导
工程师不仅实现产品，也直接参与产品判断、用户支持和团队建设。
LeanCloud 的团队几乎全部由工程师构成，长期很少设置专职产品经理。它提供的是一套面向开发者的基础平台：底层服务相对稳定，其上的功能、工具和使用方式仍有很大的改进空间。用户本身也是工程师，因此产品中的许多问题需要技术背景才能准确理解，工程师自然成为最接近产品和用户的人。
产品工作通常不会从一份完整的需求文档开始。工程师可以根据自己的判断改进已有功能、设计新的能力，也会直接参与一线技术支持。工单按产品模块由工程师负责，用户反馈不会只被整理和转交；一个反复出现的问题可能继续变成 SDK 的接口调整、控制台里的提示、文档修改或新的自动化工具。技术职位的招聘同样主要由工程师参与和判断。
对我们来说，工程师的职责因此不只是选择实现方案，而是对产品结果负责。这样的自由减少了角色之间的信息传递，也让真正理解问题的人能够直接推动改进；它的另一面是工程师需要自己判断优先级、补齐产品细节，并在开发、支持和协作之间分配精力。
跨团队协作
项目各有负责人，但工程师可以跨过模块和技术栈完成需要的改动。
LeanCloud 的产品线较多，团队和管理结构却相对扁平。一个工程师通常会参与或负责多个模块，项目之间没有明显的部门墙。后端服务、控制台、SDK 和文档虽然各有负责人，却不是彼此封闭的工作范围。
当一项功能涉及多个项目时，我们通常会尽量由最了解需求的人完成整组修改，而不是把它拆成几份需求交给不同团队排期。工程师可以进入并不熟悉的代码库，由原项目负责人 review 改动。负责人的专业判断会得到尊重，但这并不妨碍其他人提出不同意见，或直接提交一个更完整的方案。
这种协作依赖维护良好的内部文档、相近的开发流程和足够的自动化测试。它降低了参与陌生项目的门槛，也避免某个团队成为所有相关需求的瓶颈。对工程师而言，这意味着能把一个问题从头到尾解决，同时也要求我们理解更广的产品范围和技术栈。
Code Review
每一项改动都经过他人检查，代码质量和项目知识由团队共同维护。
在 LeanCloud，Code Review 是日常开发的基础流程。代码进入主线前，需要由其他工程师检查业务逻辑、实现方式、可读性和测试覆盖。无论作者的经验和职位如何，这一步都不会因为「足够熟悉」而省略。
我们并不把 Review 只当作发布前的审批。作者需要把改动解释清楚，Reviewer 也会借此了解项目正在发生的变化。它既帮助新人熟悉已有规范和架构，也让资深工程师的判断通过具体代码在团队中传播，减少知识长期集中在个别人手里的风险。
Code Review 与自动化构建、测试和发布共同组成了开发流程。质量并不是等到最后交给某个角色检查，而是在代码提交和发布的各个阶段持续得到验证。这些流程需要投入时间，但它们让跨项目修改和频繁发布变得可行，也是小团队能够长期维护多种 SDK、云服务、控制台和文档的重要基础。
信息透明
代码、文档、内部讨论和管理事务默认向全员开放。
在 LeanCloud，内部信息通常以公开为默认值。代码、设计文档、项目讨论、会议记录和管理事务很少按部门划分访问权限。加入一个项目一般不需要先申请一串权限，每个人都可以了解一项决定的背景，以及公司和产品正在发生什么。
公开也意味着参与不受工作边界限制。即使一件事与自己的职责没有直接关系，我们仍然可以提出问题和意见。讨论会尊重项目负责人的专业判断，但职位本身不能代替理由；不同级别的同事可以在同一份文档或邮件中平等地讨论，目标是找到更合适的方案。
许多工作通过邮件发起、用日历安排，结论则保留在可以检索的文档中。相较于当时国内公司更常见的即时沟通，这种方式更适合归档、搜索和异步协作，也让没有参加现场讨论的人能够获得完整上下文。对我们来说，信息透明不仅减少了协作门槛，也要求每个人更清楚地表达判断，并愿意让自己的工作接受公开讨论。
事故复盘
故障需要透明地说明，复盘关注系统和流程如何避免问题再次发生。
维护云服务意味着线上故障是工程工作的一部分。LeanCloud 通过监控和 on-call 机制响应异常，发生问题时，相关工程师会放下原来的工作排查、回滚和恢复服务。事故结束后，团队会整理时间线、影响范围、直接原因和改进措施；影响用户的严重故障还会公开说明。
复盘不会以找到一次误操作或一个应当负责的人为终点。我们更关心的是，为什么一次操作能够造成这样的影响，监控为什么没有更早发现，权限、测试、发布或应急流程还缺少什么。个人失误无法完全避免，制度和工具的责任是降低失误发生的概率，并限制它能够影响的范围。
这种做法让故障成为改进系统的输入，而不是只留下一个临时修复。公开事故会给团队带来更高的解释和兑现压力，但也建立了内部协作与用户信任：问题本身不需要被隐藏，真正需要证明的是我们是否理解了原因，并采取了足以防止重演的措施。
公平与标准化
用公开和一致的规则减少谈判能力、职位和个人裁量带来的差异。
LeanCloud 不要求候选人在拿到 offer 前透露过去的薪酬，也不对 offer 进行议价。薪酬按照公开的职能基数、级别因子、选择因子和补贴计算；标准需要调整时，同类职位会一起调整，而不是为某个候选人或员工单独改变。
这套做法并不是认为公式可以定义绝对公平，而是希望避免把过去的薪酬差异和谈判能力带进团队。善于讲价的人不应仅因此得到更高回报，不擅长谈判的人也不应受到惩罚。对我们来说，薪酬的依据和未来空间可以被提前了解，管理者的决定也需要符合一套所有人都能检查的标准。
类似的标准化还体现在期权、招聘、绩效反馈、休假和技术支持等事务中。规则会随着实践继续调整，但调整的原因和适用范围需要说清楚。它减少了日常管理对个人关系和临时判断的依赖，也使员工能够更稳定地预期公司会怎样处理相似的问题。
数据来源
本页根据 LeanCloud 公开的 文化和价值、技术支持标准、技术面试指南、薪酬制度、期权计划和历年 招聘页面 整理，并与团队博客中的产品更新、故障说明和内部工具记录相互核对。
Code Review、跨项目协作、邮件与日历等日常细节来自本站收到的前员工亲历回忆，并参考江宏关于 Code Review 和 Google 大规模协作开发 的文章。页面描述的是 LeanCloud 独立运营时期较稳定的团队特征，不代表所有员工在所有阶段的体验。