首页 > 其他分享> > 从技术专家到技术管理，对管理的思考

从技术专家到技术管理，对管理的思考

2021-08-30 15:34:00 作者：互联网

观点

首先，从工程师到技术管理的转变，有两个观点要明确：

1）技术Leader是团队最好的工程师之一；

2）技术Leader是为团队服务，解决团队的问题；

工程师只需要对自己负责，而管理者需要对团队负责，这两个身份所立足的核心点是一样的。

首先要有符合要求的专业性，专业性越强越能够给他人带来信任感；其次是良好的沟通能力。但是这两件事在管理者和工程师身上的要求和方向却又很大的差异。

　　对于工程师来说，所谓的专业性单纯的指技术领域的专业性，因为工程师的核心产出主要依赖于其技术领域的造诣，主要的要求是对自己的产出负责。

所以需要不停的钻研自己需要依赖的技术，打磨自己使用的工具，不断提升自己能做的事情的边界，不断的提升自己的深度；

　　对于管理者来说，所谓的专业性则更加偏向于如何提升团队产出，所以核心的要求会和工程师有所变化，我个人认为可以拆解到以下几方面：

团队建设：核心包括招聘和团队层次搭建，团队和个人最直接的区别就是人数。团队是一个组织，对于管理者来说，首先需要的就是把这个组织建立起来，一个人的组织很难比10个人的组织产出高；
设定目标：当团队已经搭建起来，最重要的事情就是要做什么，如果团队的目标是错误的，那很可能导致整个团队负向产出，所以目标一定要对。在这一点上是最体现管理者的“专业性”的，方向走对了，整个团队事半功倍，整个团队都会信服管理者，反之，则全是管理者一个人的责任。
提升效率：一般我们直观能想到的就是招更好的人提升效率，但站在管理者的角度还要考虑是否能在工具或流程上改造，是否能靠提升团队分工情况来改善效率等。
树立榜样：管理者是团队的模仿对象，是团队的行为标杆，将自身的能力、行为分享和传达给团队，建立积极的竞争氛围。竞争能够高效激发员工的潜力，要让团队中员工处理良性竞争状态，给团队创造“危机意识”。

　　对于工程师来说，核心的沟通方一般是团队内部和产品，沟通的要求主要是能和产品沟通清楚需求，能讲明白自己的技术方案即可。

　　对于团队管理来说，核心的沟通方都是其他团队，管理者需要帮团队解决的一个大问题就是外部资源依赖问题。所以对沟通的要求要高很多，

如何能说服其他团队提供资源解决自己的问题是管理者需要解决的核心工作之一。你推进的不再是一个简单的、自闭环的事。

你需要对上沟通，跨团队沟通，以及对下沟通，开始需要学习各种技能，更多的掌握业务，站在用户角度，然后再来思考如何通过系统来满足需求。

从团队维度来讲，从一名工程师到技术管理的转变，我总结了四个方面：

如果只是以工程师的角度去工作，可能只会关注项目里面的某些点，容易陷入思维定势，不太容易去思考全局。

因此在最开始应该学会“躬身入局”，了解团队工作中的重要节点，而不是高高在上。工程师和技术管理只是职责上不同，而非职级或者“阶级”上的区分。

团队要做的事情，从复杂程度以及数量多寡来说，肯定远远超过个人。因此要学会分辨那些是重要紧急的事项，从全局角度考虑，可以适当的做“局部牺牲”来保证整体拿到更好的结果。

个人的时间和精力都是有限的，从工程师到技术管理，很多时候时间不再是自己的。

尝试去相信团队里面的每个同学，给他们机会去做一些超过之前职责和能力的事情，当然过程中要及时给予指导和过程把控，相信他们能拿到更好的结果。

作为技术出身的管理者，要时刻保持对新技术的学习，并在可能的范围之内承担一定的开发&测试工作或者说要对团队内技术项目足够深入，在成员遇到问题时要能给出解决方案或者思路。

保持耐性，有服务和指导以及培养团队的的意识，提升整个团队的实力。技术管理者要能规划和提出团队的目标，明确团队前进的方向，并确保大家能够不偏离轨道，不断纠正，直到达到目标。

技术Leader必须是团队最好的工程师之一，要能够基于自己的技术能力&业务认知做决策。要确保技术成长的速度，通过现象看出背后的原因或原理，要能成为问题终结者。

工程师更多是面向技术，是一个很小的圆；成为技术管理者后，需要调整自己的认知边界，成为更大的圆，及时补齐不同方面的能力缺失。

当你作为一个技术管理者，需要保证一定的思考时间，转换埋头执行的工作方式。需要从单点模式的思考，快速过度到一个项目甚至更高维度的业务层级。这是一个“点-线-面”的过程，需要保持耐心。

学会抓大放小，结果导向。精力有限很难面面俱到，学会放手让有能力的人去具体落地，自己做好跟进识别业务核心、把控方案设计、codereview等工作。

标签：沟通,工程师,管理者,管理,技术,专业性,思考,团队
来源： https://www.cnblogs.com/chenyablog/p/15206126.html