工程师在业务中的成长
May 22, 2024
Date
May 22, 2024
Slug
engineer-thinking-1
Author
Status
Published
Summary
Type
Post
Thumbnail
Tags
🤔 Thinking
updatedAt
Jan 26, 2026 01:59 PM
正式工作一年多了，用我现在的感受和想法写一篇博客回顾我刚工作时的担忧，也尽量解答我刚工作时的疑惑。
关于当时的疑惑
我所在的团队是最普通的业务研发团队，说白了就是“做需求的”。在离开校园开始工作前，我身边的很多同学都认同一条技术鄙视链，比如认为做开发的不如做算法的，做前端的不如做后端的，做业务的不如做基架的。从我在大学时候的理解看，这条鄙视链是基于工作的“门槛”定义的，比如大部分的算法岗位需要硕士学历，同时网络上能够看到大把自称培训班出身的前端工程师。所以按照这个鄙视链来看，我的工作处于鄙视链的最底端。
当然，我选择这份工作有一定的原因同样是因为它较低的”门槛“和还不错的工资。我在入职前也对于这份”鄙视链最底端”的工作有一定的担忧：
- 是否因为技术没有挑战性所以发展上限会很低
- 是否会因为技术栈过时而没有可迁移的能力
- 业务工程师应该如何成长
现在工作过去一年了，我想在现在的视角写下我对每个问题的理解。
关于技术挑战性和发展上限
对于第一个问题，不可否认业务部门的技术挑战性确实是低于基架或者技术部门的，因为业务部门的目标是服务于产品业务，让产品有办法赚钱盈利。同时，业务团队的技术scope很小，每个团队集中于产品中很小的一个模块，只能在这个模块内部耕耘技术。
对一个新人工程师来说，技术上的成长无疑是更有优势的，因为这表示你能够解决更难的技术问题，能够实现复杂度更高的系统，更能够体现工程师解决问题的能力。这部分业务部门能够提供的机会和资源都会少很多。但同时，由于业务工程师需要在一线解决业务问题，能够获取到的业务反馈也更多，更能够知道有哪些和技术相关的业务痛点，以及怎样用技术解决业务中的实际问题。
技术团队的工作像是造轮子，每个轮子有不同的针对点，能针对性地解决不同问题。业务团队的工作更偏向于选择合适的轮子并组装给业务使用，需要知道各个轮子的优劣并选出最适合自己业务的。业务团队和技术团队能带来两种不同的视野，同样点的技能树侧重点也不同，对于偏技术的团队来说，技术的难度更高，对工程师在技术深度的成长中更有帮助。而业务团队能够培养的更多是一种sense，即对产品现存问题的感知，以及用技术解决业务痛点的能力。如果需要当好一个Tech lead manager，这种对业务的sense是必不可少的。
关于可迁移的能力
当初提出这个问题，一方面是因为现在的科技行业迭代很快，不知道自己的岗位什么时候会被取代。另一方面是担心业务比较细分，如果日后换方向或者跳槽，遇到不熟悉的业务没有别的能力可迁移。
这一年的工作基本打消了这部分疑虑，因为能力不是单一维度的，任何找工作的考察也不会要求百分之百的匹配，毕竟路不是越走越窄的。但同时保持学习的习惯和对行业的关注是程序员保持竞争力需要坚持做的事。
关于业务工程师的成长
之前看到在外企公司工作的同事分享，外企会有更明确的工程师成长路径和更频繁的one one，如果你有晋升到下个level的诉求，mentor会详细帮你找出你还缺乏哪部分的能力，以及告诉你应该去做什么事体现你的这部分能力。但对比下来字节在工程师成长这部分是缺少明确路线的，更多是会明确每个等级或阶段需要有什么样的能力，需要自己去想办法做到一些能够证明拥有这部分能力的事。在我和我的老板以及一些senior的同事多次沟通后，我觉得现实确实是如此的。但至少公司层面上对于你需要具有的能力的定义还是很清晰的，只是需要自己花更多的时间知道需要如何做到。可能公司认为成长是自己的事，没有义务帮助员工成长，公司只会定时筛选掉能力不符合要求的员工。
但从能力模型上来说，各种能力应该是世界通用的，比较字节能做出赚全世界人的钱的产品，从业务角度来说这必然是一个成功的公司。至于要有什么样的能力，我感觉网络上随便一搜就有很多关于技术规划、架构、项目管理相关的文章，都能够比我现在的理解讲得更好，我就不在博客中赘述了。