随着团队的发展，单一技术栈的人数已经快达到10个人的规模，一些团队问题慢慢的也暴露了出来。以单一技术栈（Web前端）来举例，目前前端技术栈一共有9名开发，职级分布如下
T11-13 ：5人
T14-16 : 4人
当前遇到的主要问题有如下两点：
月末绩效互评时，高职级与低职级的开发之间无法很客观的相互给出评价，经常会因此产生矛盾，大家互相不认可。因为高职级开发的工作内容经常会带有面试，带新人，技术预言等工作，而低职级的开发绝大部分的工作是业务开发，两方工作内容有一定的区别。高职级开发的战斗力没有完全发挥出来，部分高职级开发大部分精力忙于做基础的业务开发，而在思考设计，优化，带新人等工作上花的时间较少，从而导致项目的技术创新、技术优化不足，新人的成长及归属感不够。
自己思考了比较长的时间，也与其他公司朋友探讨技术团队的管理方式，发现我们团队目前的绩效标准以及人员职责要求是有比较大的问题的。我们意识到，一个团队倡导什么，鼓励什么，就会带来相应的结果。在目前的团队规模和职级分布情况下，绩效评分标准层次过于的单一，虽然标准中划分了工作量，工作难度，工作质量三个维度，但这些维度过于通用，无法适应不同人员的能力及岗位要求，其实是在隐形的倡导大家都往业务开发。同一套标准用在了不同能力层级的人员身上，导致工作职责及其导向并没有结合人员的能力。这种方式下，就会出现上述的两个问题，也许还有更多隐藏的问题未被感知和发现。因此，我们需要在团队岗位职责，绩效标准上做改变，对其进行重新定义。基于当前的团队现状，我们将对绩效标准与评定方式做如下修改。
按照团队职级分布，将团队成员划分成两个层级，如前端工程师（11-13），高级前端工程师（13-16）。针对不同层次的工程师，制定不同的岗位要求及绩效考核标准。绩效互评时，不同层次的工程师分开独立互评，各自按照各自层级的标准进行评分。
针对前端工程师，沿用旧有规则，主要维度及其占比如下：
- 研发工作量（50%）
- 研发工作质量（30%）
- 研发工作难度（20%）
针对高级前端工程师，对标准做了比较大的调整，主要维度及其占比如下：
- 新人培养（20%）
- 技术优化、创新及规划（40%）
- 前端工程师三项（40%）
通过上述的方案，期望能使得不同层级开发能更加明确自己的岗位职责，知道自己该往哪些方向去努力和发力。方案中将之前比较缺失的灰色地带，如技术优化、带新人等工作内容明确下来，以提升大家对这些工作的重视程度。