PhonePe 的工程之旅：工程师和工程经理的成长框架
已发表: 2020-07-12PhonePe 的职业阶梯更多的是围绕对技能培养很重要的维度进行滑动，并很好地映射到文化和价值观
PhonePe 工程之旅的“范围和影响”描述了角色责任的广度和深度以及团队所衍生的价值
基于这个原则，在工程中的软件开发功能中，PhonePe在IC赛道有两个角色——软件工程师和软件架构师
随着 PhonePe 进入下一个发展阶段，我面临的挑战是设计一个工程组织，将我们雄心勃勃的目标放在中心位置，同时为工程师提供专业发展路线图。
PhonePe 是一个为各种产品和服务提供动力的生态系统，可帮助消费者和企业参与并在经济中蓬勃发展——Karte Ja Badhte Ja！
我个人认为 PhonePe 是一个技术平台，可以与各种合作伙伴持续协作。 我们创造创新和智能的产品，以交易速度、简单性和安全性为基础，为客户提供丰富的体验。
但在如此广阔的画布上绘画也意味着在可预见的未来，不同的团队将处于产品成熟度的不同阶段，工程师们不断地在长期能力建设和增长黑客之间进行权衡，同时扩展平台以管理超增长。 这涉及模糊问题的解决、处理歧义、数据驱动的决策、广泛的计划和大量的编码。
根据他们正在研究的产品的生命阶段，工程师可能需要在一项技能或一个领域锻炼更多肌肉而不是其他技能。 与此同时，公司的雄心壮志要求我们通过引进具有不同技术水平和领域专业知识的新人才来继续壮大团队。 因此，我开始考虑一个框架，该框架将通过随着时间的推移学习和技能积累与工程师的整体成长保持一致，同时仍然关注组织的目标和需求。
最初的思考过程是按照我们今天的方式简单地定义一个更细化的工程职业阶梯。 根据我过去的经验，典型的职业阶梯包含一个能力框架，该框架将角色中技能水平的组合与头衔挂钩。 这往往会驱动那些特别关注实现个人名义增长的局部最大值的行为。
另一方面，现代职业（尤其是在消费者互联网领域）更加流动。 他们要求个人在选择开发和锻炼哪些技能组合时具有相当大的灵活性，以便为公司带来最大价值。
这让我将我们对职业阶梯的定义重新定义为一个框架，该框架基于不断扩大的所有权和责任范围设定工程师的成长预期。 在我看来，这更好地映射到快速发展的组织中的实际职业发展，随着他们拥有的章程变得越来越大，对个人的需求变得更加多维。
我对 PhonePe 的职业阶梯的看法更多的是围绕对技能培养很重要的维度进行调整，并很好地映射到 PhonePe 的文化和价值观。 没有明显的阶梯函数，你可以指着任何一项技能说“干得好！ 您现在是高级工程师或 SDE3” 等。
当您在组织中承担更多责任时，它将被视为如何以最佳方式运作以产生最大影响的指南。 并在此过程中积累技能和学习，使一个人成为全面的工程领导者，同时也因创造的价值和影响而获得回报。 不以目标为导向，更多的是追求卓越。 因此得名， PhonePe 的工程之旅。
我们如何定义 PhonePe 工程之旅？
PhonePe 工程之旅被定义为一个框架，该框架通过其所有权范围、影响力和影响力而不是任期或等级来映射工程组织中任何个人的成长。 它旨在服务于以下目的：
- 成为个人贡献者的指南，了解他们需要发展的特质和技能，以便随着责任的扩大而变得更加有效
- 成为管理者的指南，让他们在团队中表现出有希望的个人承担起更大的责任，同时确保他们因其宝贵的贡献而获得公平和一致的奖励
- 让工程组织致力于创造一个环境，使工作中的学习和应用能够影响每个人的主要目标，职业发展是这一过程的自然结果
随着我们对详细说明工程之旅的想法进行改进，我们融合了一系列核心原则，这些原则反映了我们作为工程组织的价值观以及我们对真正意义上的工程增长的信念。 详细说明这些很重要，因为它对我们未来的角色和责任定义有影响
核心原则
基于“范围和影响”并以“增长维度”为导向的增长
PhonePe 工程之旅的“范围和影响”描述了角色责任的广度和深度以及团队/组织从中获得的价值。 角色的成长必须仅通过扩大范围和影响的镜头来衡量——随着工程师成长为专业人士，他们的范围（和相应的影响）也将从拥有和交付（在监督下）团队中的小任务和功能转变，到拥有端到端的功能和服务，到拥有端到端的大型平台和产品。
“成长维度”指的是我们作为一个组织所特有的技术技能和行为特征，以及使工程师在 PhonePe 取得成功的原因。 这是我们的组织功能（支持多样化产品、支付和金融服务领域以及数据驱动决策的开放式大型平台）以及我们想要灌输给工程师的文化（高度的所有权和热情、交易能力）模棱两可，通过持续学习实现成长，通过积极影响发挥领导作用）。
“成长的维度”仅用作指南，而不是准备和渴望增加责任范围的清单。 例如，作为一名工程师（无论是后端工程师还是应用程序开发人员）渴望承担更广泛的职责，他们需要提高自己的设计和开发技能，以及对周围系统的理解等等。
为你推荐：
RBI 的账户聚合器框架将如何改变印度的金融科技
企业家无法通过“Jugaad”创建可持续、可扩展的初创公司：Cit...
元界将如何改变印度汽车业
反暴利条款对印度初创企业意味着什么？
教育科技初创公司如何帮助印度的劳动力提高技能并为未来做好准备……
本周新时代科技股：Zomato 的麻烦仍在继续，EaseMyTrip 发布强...
同时，他们还需要投资于更好的规划和优先级，以交付越来越复杂的项目。 然而，除此之外，工程师还需要提高他们指导他人的能力，通过他们的影响范围影响变革（而不是由等级结构支持），并为自己和他们的团队管理变革和模糊性要成功。
通过作为持续改进的指南，“增长维度”允许工程师根据团队的需要自我管理他们在不同开发领域的投资，同时确保作为工程师的长期整体成长。
避免千篇一律的增长方式
工程师在组织中的所有权范围和影响不仅取决于工程师在各个增长维度中所处的位置，还取决于他/她所属的业务和团队的需求。 有时，工程师可能会专注于业务所需的特定维度并过度索引，而牺牲其他维度的增长。
因此，不应期望在任何给定时间点，公司中承担相似职责的所有工程师都将在各个方面处于相同的增长水平。 同样，责任和/或补偿范围的增加不应总是取决于有预谋地展示所有方面的改进。 但是，组织和个人应确保随着时间的推移，通过结构化轮换、在职学习和指导，实现跨维度的增长。
以下是上述两个指导原则的说明——拥有相似所有权范围和预期影响力的三个人将在范围和影响力和维度量表上进行不同的映射。 同心圆代表范围和影响的增长，五个轴代表增长的维度：
个人贡献者和经理的平行增长轨迹
在 PhonePe，我们在工程方面有两条截然不同且平行的职业轨道——个人贡献者 (IC) 轨道和管理轨道。 工程之旅必须确保 IC 轨道的增长在所有方面都与管理轨道的增长相当，在创造影响、展示领导技能和薪酬方面没有玻璃天花板。 如果个人贡献者对人员管理的核心职责感兴趣，他们可以成为经理。 但这种变化将是横向移动，而不是提升。 这有助于确保我们不会因为错误的原因而产生改变曲目的动机。
功能标题优于分层标题
鉴于公司的增长是您的所有权范围和影响力的直接代表，因此仅需要标题来准确反映该功能范围，而无需在其中建立层次结构。 我们通过增加薪酬和责任，而不是授予以任何方式描述资历的头衔来奖励和认可人们在范围和/或影响力方面的提升。
这确保了头衔不再是个人的动力。 成为特定讨论论坛、激动人心的新举措或决策职能的一部分的权利取决于一个人的职能角色和绩效，而不是头衔。 这建立了一种文化，在这种文化中，组织层级在与人的日常互动中没有作用，并且讨论的发生并以所提出论点的技术优点而不是背后的个人为基础。
那么这对 PhonePe 的工程角色意味着什么呢？
如前所述，鉴于我们的工程阶梯在确定的维度上更像是一个滑动比例，我们正在摆脱在成长的每一步中为角色命名，以确保重点继续放在获得更多责任而不是获得头衔上。 我们的头衔是功能性的，旨在表示角色的适用性，而不是资历。
个人贡献者追踪
基于这个原则，在工程中的软件开发职能中，我们在 IC 赛道上有两个角色——软件工程师和软件架构师。 软件工程师角色的职能职责主要映射到产品团队或一组相邻的 POD，其目标通常与组织的 L1 目标相关联。 软件架构师的职能职责更加横向，主要映射到规模、可靠性、性能、数据中心成本优化等技术组织目标。
然而，随着时间的推移，软件工程师会成为一名深入的产品级专家，但这并不意味着他们不参与团队之外的更广泛的计划。
出于同样的原因，软件架构师并不仅仅短视地专注于组织计划。 他们仍然属于团队并定期为团队计划做出贡献，但这不是他们关注的首要焦点。 正是这种功能差异保证了不同的标题。 但是，这两个角色一直都有平行的成长路径，不需要出于学习或薪酬的原因从一个切换到另一个。
经理跟踪
我们采用了与管理轨道类似的分支，以团队和组织范围作为职业发展的基础。 入门级工程经理以及具有团队范围的更有经验的工程经理被映射到工程经理的角色。 随着工程管理方面的章程扩大到包括非团队特定的组织责任以及损益责任的共同所有权，该角色变成了工程主管的角色。
在这种情况下，虽然工程经理和工程主管之间的职业生涯图会有一些重叠，但工程经理的自然职业发展是进入工程主管的角色。
级别
在这两个轨道中，上述每个角色都映射到 HR 系统中的薪酬级别。 这是为了确保我们有能力根据市场持续对工资进行基准测试，并在系统内设置加薪和招聘检查点。 然而，这些层级并不为个人所知，因为它违背了在一个函数中设置平面角色的目的。 在薪酬决定之外对这些水平的任何使用都是不正常的。
这可以推广到工程的所有学科吗？
PhonePe 拥有广泛的软件工程学科，包括后端、移动、UI、DevOps、数据科学、质量和安全性。 我们还有许多业务和产品单元，它们以 POD 的形式进行跨职能组织。 虽然上面的例子主要强调了工程中的核心开发功能，但我相信这些方法和原则适用于所有学科和团队的工程师和经理。
通过确保我们在整个公司拥有一致的标准，我们可以实现流畅的内部流动性并进一步支持个人成长。 个人应该能够通过处理广泛的产品和问题来拓宽他们的技能和视角。 这就是最终目标。
参考
当我开始思考我想如何在 PhonePe 构建一个工程增长框架时，我开始寻找其他人如何解决同样的问题。 许多组织对他们的理念持开放态度，这让我感到惊喜。 鉴于他们中的许多人激发了我对此的思考，我们应该公开发表我们的观点以征求反馈意见，同时也赞扬那些对其产生影响的人。