英文原文：I just dumped all my job titles
编者注：Jeff Dickey 是一位在不少创业公司工作过的工程师，他在 Medium 上发表了这篇文章，认为在工程师团队中拿掉头衔等级变身扁平化会对团队更有帮助。
在软件领域，技术人员的晋升路线一般是这样的：
软件工程师 1/2/3 级—高级软件工程师—主管工程师—高级主管工程师—技术总监
但你有没想过为什么会有这些职位和等级？我今天想了想可能有这么几个原因：
内部学习文化对一家公司来说是很重要的
我们从过去的经验中会知道，如果一家公司能有高效快速地运作，那它成功可能性更大。而在今天，一家公司能多快适应新环境，那它的成功几率也会更大。如果是一家有着学习文化的公司，那它很可能就有了高效和快速适应新环境的特性。
一个好的学习文化会对以下几点有促进作用：
这些特性应该是对公司全员都普适的，尤其是对创业公司来说，这就更加重要了。
但这些等级头衔会妨碍这样的学习文化
在我早期的工作经历中，常碰到所谓的架构师或高级主管工程师等职位的人员来到项目组来指导经验。我记得当时的体验很不好，不论是我个人还是团队其他成员，都是有能力做好自己项目的。但是，这种指导就让我们的心态变了，我们从原本的只想做好产品，转变为想向上级和公司证明我们的能力，这样的管理是不对的。
并且这其中还会有“这些高级人员的意见权重会更大”等约定俗成的规则。如果大家有了分歧，那高级人员总是被认定是对的。这样就把公司成员给分极化了，一边是高级人员，一边是初级人员。
当我自己经过努力头衔和职位不断上升了，成为公司内的专家，我又会带着自我意识来去管理。新来的人员不会被赋予足够的信任，去处理一些重要的架构决策。有合适经历的人才适合去处理那些。我就会写数据库架构，写复杂的算法，而初级人员只会做些改 bug 的工作。
我们都知道这样是不行的。
这种层级式的管理和思考方式从石器时代就开始了，当时人们只处理一些很简单的手工任务，这种管理方法还挺好用。而在现在这样一个创造性的行业里，它是阻碍生产力的。当然追逐更高的头衔和管理职位也是一个激励因素，但别忘了彼得原理：
在一个等级制度中，每个职工趋向于上升到他所不能胜任的地位
你是希望员工只为头衔奋斗？还是希望他们能取悦你的顾客？不排除是自己臆想成分多一点，我总会相信一个工程师所能有的最大激励，就是让使用自己产品的用户能用得高兴。我自己很幸运在几家结构扁平的公司里工作过，我发现大量的会议和争论都被免掉了。如果我们真的陷入了某个僵局，我们就通过快速迭代、分析或者是果断跟着某个更在意这起僵局的人的思路走。我觉得这会比那些花费数周来争论，最后只会在各方之间积累矛盾的方式要好得多。
我们不需要这些头衔
我也看到不少观点，声称头衔等级在沟通技术时是很有必要的。但是，当我在和那些有好几年开发经历的人交流时，我甚至不需要看他的简历。我只会看他的 portfolio，一个 GitHub 账号，技术博客或代码，任何一些能告诉别人他的编程技能的东西都行。我自己也同那些有个好听头衔但技能很挫的人合作过。
真正重要的是技能
如果有高级 Rails 工程师这样的头衔还算是比较能说明你技能的。但我不认为重写简历，然后突出这种技能有什么难的。而且，(理想情况) 你在公司不只培养出了的一种技能。但对于头衔而言，你只能有一个，所以通过头衔来描述技能也不是很好的。
那些你想要的(但现在还不拥有)的技能更重要
我自己的第一个 Rails 项目花了不少时间，之前我都没有经历。当时我在弄 Django 但兴趣不是很大。我最终通过自己努力还是成为一个 Rails 开发者了。当我现在已对 Rails 了解很多后，我会想尝试新领域比如 Objective-C。当我在新的学习周期上时，就会进步很快。
对于技术人员来说，那些他们有兴趣去掌握的东西和技能会比他们已经拥有的东西重要得多。
工作角色其实也并非那么重要
那些分前端工程师和后端工程师的做法其实很奇怪。几个月前我面试时会被问到我到底是做哪一类 (前端还是后端)，我都会变得畏畏缩缩。我不是一项东西，而是我在做东西。通常情况是，我只想做出用户想用的东西。但如果在这个过程中，我发现不知道怎么做，那我就去思考和学习，直到找出方法。
如果需要的话，我也可以做更多。我可以写文案，我可以设计好看的按钮。其实这两项我并不擅长，但是我并不会因为它没别为我部门的事我就一概不管。提升用户体验就是我部门的事。
我把自己的头衔都抹掉了
我把我的简历中的所有头衔都变成了软件工程师，虽然自己也不太喜欢这个字眼，但起码在我看来它已经是一个比较好的描述了。我并不是说你也得这样，但是大家都可以思考一下，头衔 + 等级到底是不是好事情。而我个人比较想要的就是，除了头衔以外的，能方便和快速告诉别人：我想做什么，以及我能做什么的方法。
相关文章
