Toc
  1. 所有伟大的科技领袖都知道这是一个奇怪的把戏
  2. 成为技术领导 101
    1. 技术领导的主要角色
      1. 系统架构师和业务分析师
      2. 项目策划师
      3. 软件开发人员和团队负责人
  3. 管理项目
  4. 管理项目
  5. 决策点:保持技术路线或成为经理
    1. 想象中的高级个人贡献者的生活
    2. 高级个人贡献者的真实生活
    3. 想象中的经理生活
    4. 经理的真实生活
  6. 好经理,坏经理:流程沙皇
  7. 如何成为一名伟大的技术领袖
    1. 了解架构
    2. 成为团队合作者
    3. 领导技术决策
    4. 沟通
    5. 评估自己的经历
Toc
0 results found
第三章:技术领导
2020/07/18

多年前,我成为技术领导。我已经晋升为高级工程师,并且正在与其他几位高级工程师组成一个小团队。我被提升为技术领导,真是令人惊讶,因为无论从头衔还是从业经验,我都不是团队中最高级的人。回想起来,我有一些优势。首先,我不仅仅是一名优秀的工程师。我是一个很好的沟通者。我可以写清晰的文档,可以进行演讲而不会崩溃,并且可以与不同团队和不同角色的人交谈,并解释发生了什么。我也擅长确定优先级。我渴望推进工作,并确定下一步需要做什么。最后,我愿意整理并做需要取得进展的事情。我认为,最终,这种务实的紧迫性是决定性因素。

我也看到技术领先者陷入困境。一个特别令人难忘的斗争是一个人,他是一位了不起的工程师,写了很棒的代码,但是讨厌与人交谈,并且经常被技术细节分散注意力。我看着他在一个又一个的兔子洞里钻进去,与此同时,产品经理利用他的缺席,带领团队的其他成员致力于设计不当且过于激进的特征发布。该项目一团糟,技术领导做了什么?在下一次重构之后,他开始追逐,因为他确信问题完全出在代码的结构方式上。您可能会认识到这个故事,因为它无处不在。技术领导角色应自动授予最有经验的工程师的想法,能够处理最复杂的功能或编写最佳代码的人是一个普遍的误解,即使是经验丰富的经理也都喜欢这样做。对于那些希望自由地专注于自己的代码细节的人来说,技术领导不是工作。这样做的技术领导并没有做好自己的工作。但是,技术领导的工作是什么呢?我们对这个人有什么期望?

与软件工程中的许多标题一样,“技术领先者”缺乏通用定义。我能做的最好的就是借鉴自己和他人的经验。我作为技术领导的工作是继续编写代码,但还要承担额外的责任,即代表团队代表管理层,审查我们的功能交付计划以及处理项目管理流程的许多细节。尽管我不是最高主管,但我仍然可以担任技术领导,因为我愿意并且能够担当此职位的职责,而我团队中的其他成员则对纯粹专注于他们正在编写的软件更感兴趣。当我在 Rent the Runway 的团队创建我们的工程职业阶梯时,我们有意识地选择将技术领导的角色定义为工程师可以在阶梯上的许多点而不是特定级别上承担的一组特征。我们之所以采取这种策略,是因为我们想认识到,随着团队的变化和发展,技术领导角色可能由工程师的许多不同阶段担任,并且可能会从一名工程师转移到另一名工程师,而不必由任何人改变其职务级别。一家公司之间,甚至一家公司的团队之间,技术领导的角色可能不完全相同,但是从头衔中我们知道,预计它既是技术职位又是领导角色,并且通常是临时职责而非永久性头衔。因此,话虽这么说:技术领先者是什么?这是我们在“租用跑道”中创建的描述:而不是特定级别。我们之所以采取这种策略,是因为我们想认识到,随着团队的变化和发展,技术领导角色可能由工程师的许多不同阶段担任,并且可能会从一名工程师转移到另一名工程师,而无需任何人更改其职能性工作水平。一家公司之间,甚至一家公司的团队之间,技术领导的角色可能不完全相同,但是从头衔中我们知道,预计它既是技术职位又是领导角色,并且通常是临时职责而非永久性头衔。因此,话虽这么说:技术领先者是什么?这是我们在“租用跑道”中创建的描述:而不是特定级别。我们之所以采取这种策略,是因为我们想认识到,随着团队的变化和发展,技术领导角色可能由工程师的许多不同阶段担任,并且可能会从一名工程师转移到另一名工程师,而无需任何人更改其职能性工作水平。一家公司之间,甚至一家公司的团队之间,技术领导的角色可能不完全相同,但是从头衔中我们知道,预计它既是技术职位又是领导角色,并且通常是临时职责而非永久性头衔。因此,话虽这么说:技术领先者是什么?这是我们在“租用跑道”中创建的描述:技术领导的职位可能由工程师的许多不同阶段担任,并且可以从一名工程师转移到另一名工程师,而无需任何人更改其职务级别。一家公司之间,甚至一家公司的团队之间,技术领导的角色可能不完全相同,但是从头衔中我们知道,预计它既是技术职位又是领导角色,并且通常是临时职责而非永久性头衔。因此,话虽这么说:技术领先者是什么?这是我们在“租用跑道”中创建的描述:技术领导的职位可能由工程师的许多不同阶段担任,并且可以从一名工程师转移到另一名工程师,而无需任何人更改其职务级别。一家公司之间,甚至一家公司的团队之间,技术领导的角色可能不完全相同,但是从头衔中我们知道,预计它既是技术职位又是领导角色,并且通常是临时职责而非永久性头衔。因此,话虽这么说:技术领先者是什么?这是我们在“租用跑道”中创建的描述:但是从头衔中我们知道,它既有望担任技术职务,又是领导角色,而且通常是临时职责,而不是永久头衔。因此,话虽这么说:技术领先者是什么?这是我们在“租用跑道”中创建的描述:但是从头衔中我们知道,它既有望担任技术职务,又是领导角色,而且通常是临时职责,而不是永久头衔。因此,话虽这么说:技术领先者是什么?这是我们在 Rent the Runaway 中创建的描述:

技术领导的角色不是阶梯上的重点,而是工程师升至高级职位后可能要承担的一系列职责。该角色可能包括人员管理,也可能不包括人员管理,但如果这样,则技术领导应按照 RTR 技术的高管理标准来管理这些团队成员。这些标准包括:

  • 常规(每周)1-1 个触摸基准
  • 定期反馈有关职业发展,实现目标的进展,需要改进的地方以及应有的表扬
  • 与报告一起确定要学习的领域,并通过项目工作,外部学习或其他指导帮助他们在这些领域中成长

如果技术领导没有直接管理,他们仍有望为团队的其他成员提供指导和指导。

技术领导正在学习如何成为一名强大的技术项目经理,因此,他们通过有效地委派工作而不进行微观管理来扩展自己。他们专注于整个团队的生产力,并努力提高团队工作产品的影响力。他们有权为团队做出独立决策,并正在学习如何处理困难的管理和领导情况。他们还学习如何与产品,分析和其他业务领域有效地合作。

不需要工程师作为技术领导者才能取得进步,但这是工程师从高级工程师 1-> 2 成长的最常见方法,并且要求从高级工程师 2 成长为工程主管。实际上,由于在高层领导和责任方面的重要性,即使没有在个人贡献者方面担任过技术领导,也很难超越高级工程师 2。

也许更好的简写就是 Patrick Kua 在他的书 《与技术领导交谈》 中使用的描述:

负责(软件)开发团队的领导者,至少花费 30%的时间与团队一起编写代码。

技术领导可以充当强大的技术项目负责人,并可以更大规模地利用他们的专业知识,从而使他们的整个团队变得更好。他们可以做出独立的决定,并且在与团队可能拥有的其他非工程合作伙伴进行协调中发挥重要作用。您会注意到,这里没有专门的技术工作。这是高级工程职位,但是将技术领先的概念与团队中最好或最有经验的工程师联系在一起是错误的。您不能在没有其他人参与的情况下发挥领导作用,而人际交往能力正是我们要求的新技术领先优势,而不仅仅是纯粹的技术专长。但是,技术领导将致力于一项主要的新技术技能:项目管理。

如果您发现自己处于技术领先地位,那么恭喜!有人认为您有成为团队关键人物的条件。现在该学习一些新技能了!

成为技术领导

成为技术领导是一种在没有权威的情况下进行影响的练习。作为技术领导,我领导着一个团队,但我们都向同一位工程经理汇报。因此,我不仅必须影响同龄人,而且还必须影响我的经理,以确保我们优先考虑正确的工作。在担任最近的职务时,这尤其具有挑战性,因为在成为技术领导后,我处理的首批项目之一是停止所有功能开发并专注于技术债务。对我来说,很明显,“技术债务可以”已经走了很长时间。部署新代码很困难,操作现有服务很昂贵,而且轮班期间的轮换很麻烦。我相信我们需要放慢脚步,才能在未来更快地前进。但是,这对其他开发人员而言并非易事,谁想编写有趣的新功能,或者想向我的经理询问客户不断提出的要求。我通过关注对单个团队成员的不同影响来卖出这个想法。对于某些团队成员而言,这是为了提供更可靠的服务;对于其他团队而言,则是与迭代速度有关;对于其他团队而言,则是减轻通话中的负担,使他们可以彻夜难眠。在与经理交谈时,我强调了减少的运营开销,这意味着我们将来可以作为一个团队完成更多的功能工作。对于其他人而言,则是减轻通话中的负担,使他们可以整夜入睡。在与经理交谈时,我强调了减少的运营开销,这意味着我们将来可以作为一个团队完成更多的功能工作。对于其他人而言,则是减轻通话中的负担,使他们可以整夜入睡。在与经理交谈时,我强调了减少的运营开销,这意味着我们将来可以作为一个团队完成更多的功能工作。

成为技术领导者需要我改变自己的重点。现在,工作不再是我的事,而是从事最具技术挑战性的想法或最有趣的项目。相反,我的重点更多地放在团队上。我如何赋予他们权力?如何消除阻碍它们前进的障碍?进行改写或一些新的令人兴奋的功能可以帮助我充分表达自己的技术实力,这可能会更有趣,但是当时团队需要解决技术问题并专注于运营。最后,该倡议取得了令人难以置信的成功。该团队将关键寻呼警报的数量减少了 50%,在接下来的季度中,我们几乎将能够完成的部署数量增加了一倍。

凯蒂·麦卡弗里

所有伟大的科技领袖都知道这是一个奇怪的把戏

您是技术领导,这意味着您对软件有所了解,并且经理认为您已经足够成熟,可以承担更大的项目责任。但是,如果您不知道要成为一名优秀的技术领导者的最大诀窍,那就是拥有技术排骨和成熟度:愿意摆脱代码并想出如何在整个工作中平衡技术承诺的意愿团队需求。您必须不再完全依赖您的 技能,而开始学习一些新技能。您将学习平衡的艺术。

从现在开始,无论您从事何种职业,平衡都可能是您的核心挑战之一。如果您希望自己的工作有自主权,并且希望自由选择何时工作,那么您就必须掌握自己的时间以及如何使用它。更糟糕的是,您经常需要在知道自己会做的事情和喜欢做的事情(例如编写代码)和不知道怎么做的事情之间取得平衡。人们喜欢他们已经掌握的活动是很自然的事情,因此当您不得不花更少的时间在当前的才华上去学习新事物时,就会感到非常不舒服。

很难在项目管理和监督工作与实际技术交付之间取得平衡。有时您会按照制造商的日程安排,而有些时候您将根据经理的日程安排。通过反复试验,您将需要学习如何管理自己的时间,以便为自己提供适当大小的模块来进行工作。最严重的调度错误是使您自己随意参加会议。如果您每小时都被会议打扰,那么进入编写代码的行列就很难。

即使安排了周密的时间,您也不会经常有时间集中精力进行编码问题。希望您现在已经学到了一些技巧,可以帮助您分解自己的工作,这样您就无需花费几天的精力来完成技术任务。您还知道,让您的团队制定计划以使他们能够长时间专注于开发很重要,因为 他们 将需要花几天时间专注于编码问题。领导力的一部分是帮助其他利益相关者,例如您的老板和产品经理,尊重团队的重点,并设置会议日历,这些日历对于个人贡献者来说不算太多。

成为技术领导 101

假设您正在与产品经理和其他四名工程师组成的团队合作,进行为期数周的巨大努力,以启动一项新计划。在这种情况下,技术领导要承担许多责任,具体取决于您在项目生命周期中的位置。当然,您需要编写一些代码并做出一些技术决策。但这只是您扮演的角色之一,而且可能甚至不是最重要的角色。

技术领导的主要角色

作为技术领导,您的头等大事是对工作进行广泛的了解,以使项目保持进展。从组织和计划自己编写的代码到组织和领导整个项目,您将如何走?

系统架构师和业务分析师

在系统架构师和业务分析师角色中,您将确定需要更改的关键系统以及为交付后续项目而需要构建的关键功能。这里的目标是提供一些基础来进行估算和排序工作。您不必完全确定项目的每个要素,但是花时间思考与项目相关的外部性和问题具有很多价值。该角色要求您 对系统的整体体系结构有很好的了解,并对如何设计复杂的软件有深入的了解 。它可能 还需要您能够理解业务需求并将其转换为软件

项目策划师

项目计划人员将工作分解为可交付成果。戴上这顶帽子,您正在学习找到有效的方法来分解工作,以便团队可以快速工作。这里的挑战之一是尽可能多地并行完成富有成效的工作。这可能很困难,因为您可能习惯于只考虑自己的工作,而不是一群人的工作。寻找应用商定的抽象以实现并行工作的场所是关键。例如,如果您的前端使用了某个 API 的 JSON 对象,那么就无需完全完成该 API 即可开始前端开发。取而代之的是,就 JSON 格式达成共识,并开始使用虚拟对象将其编码为该格式。如果幸运的话,您以前已经看到过这种情况,并且只是在模式匹配您以前的工作。在这个阶段,收集团队专家的意见 ,并与了解该软件受影响部分的人员进行深入交流,以便他们可以在此处提供详细信息。在此过程中,您还将希望 开始确定优先级。哪些部分至关重要,哪些是可选的?在项目早期如何处理关键项目?

软件开发人员和团队负责人

软件开发人员和团队负责人编写代码,交流挑战并委托。随着项目的进行,出现了意料之外的障碍。有时,技术领导很想走英雄主义,自己克服这些障碍,加班加点以完成所有工作。在担任技术领导的位置,您应该 继续编写代码 ,但不要过多。即使您很想亲自将兔子从帽子中拉出来,也必须首先传达这个障碍。您的产品经理应该尽早知道任何可能的挑战。根据需要寻求工程经理的帮助。在一个健康的组织中,尽早提出问题不会有耻辱或伤害。团队通常会失败,因为他们在产品经理本来愿意妥协的功能上过度劳累。随着大型项目的交付日期临近,功能上会有所妥协。开始寻找机会 委派工作,尤其是如果您希望自己没有时间解决系统中的某些部分。

从这些描述中可以看出,在成为技术领导的过程中,您必须扮演软件开发人员,系统架构师,业务分析师和团队负责人的角色,他们知道什么时候应该一手做某事,什么时候该做什么。将工作委托他人。幸运的是,您不必一次完成所有这些任务。刚开始时可能会感到不舒服,但是您会发现时间和练习之间保持平衡。

询问 CTO:我讨厌成为技术领导者!

我本以为成为技术领导会很棒,但是现在我的经理希望我追踪所有有关项目状态的所有细节,并告诉她什么时候要完成,我真的很讨厌。为什么没有人告诉我技术领先地位如此糟糕?

我知道,所有这些新责任都很艰巨。我喜欢将此特殊问题称为“胜利之石”。(辛普森一家 粉丝们会为我开玩笑。)胜利的石头是获得认可的隐喻,只是发现认可付出了沉重的代价。尽管在工程领导职业的许多阶段都是如此,但技术领先阶段无疑是最沉重的工作之一。很少有技术领导会因薪水增加或头衔增加而受到影响,而首次担任技术领导常常不知道新职责有多难。正如我在职位定义中提到的那样,许多公司都认为这只是一个临时头衔,是您可能会承担的一系列职责,并且在您的职业生涯中多次卸任。它可能是晋升到更高级别的必要垫脚石,但通常不是立即获得切实回报的里程碑。

为什么技术领导角色负担如此沉重?与单个贡献者职位的高级工程师相比,技术领导的职责范围要广得多。要求技术领导帮助设计项目,然后完成实际计划工作的步骤。期望技术领导确保团队完全了解项目要求,计划工作,团队有效并表现良好,而所有这些都不一定要承担任何管理职责,并且通常不需要任何特定的培训。而且,实际上,大多数经理都希望他们的技术领导继续编写与担任领导职务之前一样多的代码。通常,这纯粹是责任和工作范围的增加。如果您是第一次担任技术领导,那么您会非常忙碌。

因此,恭喜,他们给了你胜利石!幸运的是,背负这种负担最终将使您变得更坚强,并为您提供职业发展所需的技能。它不会总是像现在看起来那样沉重。

管理项目

我记得我最初在复杂项目管理中的经历非常生动。我是第一次担任技术领导,而我的团队正在执行一项非常复杂的任务。我们拥有一个已经扩展到极限的现有系统。在将本书中的几乎所有技巧都扔了之后,我们决定是时候该弄清楚如何在多台机器上运行它了。这可以追溯到分布式系统的早期,那时大多数软件开发人员实际上对创建它们的最佳实践并不十分了解。但是我们拥有一支由精明的人组成的强大团队,我们对可以解决这个问题充满信心。

我们确实很慢但确实找到了答案。我们花了很长时间思考设计和破坏计算的不同方法,因此在多台计算机上进行计算时它们才有意义。然后,有一天,我的老板迈克将我拉到他的办公室,并告诉我我需要制定一个项目计划。

这是有史以来最糟糕的经历之一。

我不得不处理这组极其复杂的任务,并试图找出哪些任务依赖于其他任务。我不得不考虑各种依赖性。我们如何使其在我们所依赖的复杂测试框架中起作用?我们将如何部署它?我们什么时候需要订购硬件进行测试?集成测试需要多长时间?问题一直在继续。我要去迈克的办公室,在这张大木桌旁坐在他对面,然后我们将讨论任务说明,日期和细目分类。他会帮助我完成其中的一些工作,然后派遣我处理需要更多工作的部分。

这不是我喜欢的事情。作为一系列令人沮丧而乏味的步骤,它被烧入我的记忆,在这些步骤中,我不得不克服不确定性和对犯错误的恐惧,对遗失物品的恐惧,以便制定出可以通过麦克的判断的计划。然后,我们进行了另一轮乏味的工作,将其整理成可以呈现给领导团队的格式,以便他们接受。它差点杀死我。这是我职业中最重要的学习经历之一。

敏捷软件开发是否能摆脱对项目管理的需求?不会。敏捷软件开发是一种思考工作的好方法,因为它迫使您专注于将任务分解为较小的块,计划这些较小的块,并逐步而不是一次全部交付价值。这些都不意味着您不需要了解如何进行项目管理。您将拥有由于某种原因而无法在单个冲刺甚至两个小冲刺中完成的项目。您需要估计管理团队的项目时间,并提供一些详细信息,说明为什么您认为事情会花那么长时间。有一些项目,通常用诸如 infrastructureplatformsystem 之类的词来描述,需要架构或重要的高级规划。面对此类项目,其中包括许多未知因素和相对艰巨的截止日期,您会发现它与标准敏捷过程不太匹配。

在事业发展中,您需要了解如何分解复杂性超出个人能力的工作。对于大多数人来说,长期运行的基于团队的项目的项目管理并不有趣。我觉得这很乏味,有时还有些恐怖。我想建立自己并获得价值,而不是试图思考如何分解仍然有非常模糊的实现细节的项目。恐怕我将被追究责任,并且我可能会错过使该项目失败的重要过程。但是替代方法是项目失败的速度变慢,而不是更快。

项目管理并不是每次都需要详细进行的事情,并且在某些组织中已被过度使用。我什至不喜欢雇用项目经理,因为他们经常充当工程师使用的拐杖,而不是学会思考未来的工作,并询问有关他们在做什么和为什么的真正问题,而他们的存在意味着您还有更多瀑布式项目,而不是敏捷过程。尽管如此,项目管理还是必须发生的,作为技术领导,您应该在需要时执行它,尤其是对于技术含量较高的项目。

归根结底,计划的价值不是在于您完美地执行计划,不是事先掌握了每一个细节,还是您预测了未来。就是说,您要强制自律,在深入研究并观察会发生什么之前,对项目进行深入的思考。在可以合理地做出预测和计划的地方,一定程度的预谋是目标。计划本身,无论结果多么准确,都没有比花时间进行计划重要。

回到我的第一个项目管理经验。该项目是否按计划完美运行?当然不是。有颠簸,错误,意外的延迟以及我们错过的事情。但是,令人惊讶的是,我们仍然按时完成了该项目,并且不需要一连串的不眠之夜。我们设法做出了必要的更改,以将这个复杂的系统移动到分布式可部署工件中,同时与 40 个其他开发人员一起对自己的主代码分支进行了修改。所有这些都是可能的,因为我们拥有一支出色的团队,并且制定了计划。我们仔细考虑了成功的模样,并确定了可能导致失败的一些风险。

自从与 Mike 进行一系列令人沮丧的会议之后,我参加了自己的一系列项目规划会议,当时我是 Mike 的一员,对面的是 Carlo 或 Alicia 或 Tim。他们每个人都感到计划缺乏细节的挫败感,他们每个人都走了,做了不舒服的工作,去思考那些无法完美预测的代码。由于这项工作,他们每个人都带领复杂的项目取得了成功的结果,并且他们了解了分解项目的真正含义,因此能够更好地构建更大的系统并领导更大的团队。

花时间解释

博士课程的最后一步之一就是辩护。经过多年的研究,您是这里的博士候选人。您将在这个领域中向您所在领域的专家小组展示您的工作结果,专家小组将判断您的结果是否值得博士学位。几年前,我很幸运地获得了美国最负盛名的应用数学课程之一的数学博士学位。我小组的一名评审是数值分析领域的著名数学家。在我的(成功的)辩护在我整个职业生涯中一直困扰着我之后,他对我说了一些话(不是在数学上!)。他说:“您的论文是我多年来读过的最清晰,最清晰的论文之一。谢谢!” 他的话我当然感到满意,但也感到非常惊讶。我以为他 作为世界一流的数学家,他将“了解所有相关信息”,并且只是“观察”我的论文的结果。实际上,正如他所解释的那样,他之所以能够做到这一点,只是因为我费力地解释了问题空间的基本思想以及我思​​想背后的动机。我从未忘记这一课。从那以后,在软件和大型组织中工作了多年之后,我变得更加欣赏这些评论。

我们认为我们的管理层“获得”我们作为技术专家的工作。只是“读代码,伙计!” 我们每天生活和呼吸的软件对于任何从事技术工作的人来说应该都是显而易见的,对吗?但事实并非如此。技术经理(希望)雇用最能解决难题的最佳人选。但是他们没有“得到”全部。当我能以一种不威胁和不屈从的方式向他们解释一些非常基本的现代想法(例如,NoSQL 的全部含义以及我为什么要关心吗?)时,我总是感到非常惊讶,他们对高级技术经理如此感激。

最近,工作中的一位高级业务经理私下问我为什么将传统的已部署胖客户端架构迁移到托管平台对我们很重要。他承受着很大的内部压力来资助这项工作,但是他不知道为什么这样做是必要的。他可能也太尴尬而无法公开询问。我花了两个非常有成果的时间来解释(没有 PowerPoint!)。如今,我毫不犹豫地借此机会向高级或初级会员解释了基本知识和动机。它教育了他们,但又不让他们感到渺小,他们学会了相信我的判断和建议,并且我们带来了改变。花时间解释非常重要。

迈克尔·马尔卡(MichaelMarçal)

管理项目

项目管理是将复杂的最终目标分解为较小的部分,将这些部分按应执行的最有效顺序排列的过程,确定哪些部分可以并行执行,哪些必须依次执行,并尝试取笑。排除可能导致其速度变慢或完全失败的未知项目。您正在解决不确定性,试图找到未知数,并认识到您将在过程中犯错,并且尽管尽了最大努力也会错过一些未知数。以下是一些准则:

  1. 分解工作。 找出电子表格,甘特图或任何适合您的内容,然后开始将您的大型交付项目(例如,重写计费系统)分解为任务。从最大的片段开始,然后将较大的片段分解为较小的片段,然后将其分解为更小的片段。您实际上不必自己做所有事情。如果您对系统的某些部分不太了解,请向执行该操作的人员寻求帮助。将一些大的东西分解,然后将注意力转移到工作的顺序上。什么可以立即开始?将那些任务交给那些实际上可以将其转变为票务大小的工作的人。
  2. 深入了解细节和未知数。 项目管理的诀窍是当您感到有些卡住或厌倦时不要停止。正如我之前所说,它既累又乏味。而且您可能不知道该怎么做。因此,请继续克服刺激,无聊和疼痛的问题。一个好的经理会与您坐在一起,告诉您哪里还不够好,问一些问题以提示您,甚至与您一起解决其中的一些问题。我们也不喜欢它,但这是教学活动的一部分。努力探索未知事物,直到您真正感觉到花费时间去获得更多的价值。
  3. 运行项目并随时调整计划。 良好的计划过程的价值在于,它可以帮助您大致了解项目已经完成了多少,以及距完成还有多远。随着事情的进展(他们总是这样做),让所有人了解情况。但是现在,您不必猜测要走多远,而可以清楚地指出已达到的里程碑并概述预期的剩余工作。
  4. 使用在计划过程中获得的见解来管理需求变更。 通过分解给定原始要求的项目,您学到了很多东西。如果需求开始改变中途,请获取这些见解并将其应用于更改。如果更改为项目增加了重大风险,需要进行新的规划或仅需进行大量额外工作,则应清楚这些更改的成本。如果您要在一个紧迫的期限内工作,则大致了解所需的工作将有助于您确定工作的优先级,削减和简化工作,以最大程度地兼顾功能,质量和交货日期。
  5. 临近完成时,回头重看详细信息。 在项目结束时,烦人的事情又回来了。现在是时候真正注意最后的细节了。什么不见​​了?什么测试?什么验证?进行 前期准备,这是一个练习,在此练习中,您会研究启动此大项目时可能失败的所有事情。确定“足够好”的界限在哪里,对其进行社交并致力于它。削减低于“足够好”标准的工作,并集中团队关注最重要的最终细节。制定启动计划;制定回滚计划。最后,别忘了庆祝!
询问 CTO:我不确定我是否会成为技术领导

我的经理不断推动我考虑成为技术领导。她要我经营一个大项目。我知道如果我担任这个职位,我将有更少的时间来编写代码,因为我必须参加很多会议并进行大量协调。我不想要我,但是我该如何决定?

对于将人们推向管理职位,我有强烈的意见,那就是您不应该这样做。如果您还不准备承担管理类责任,请不要承担这些责任。深入研究技术没有错,特别是如果您觉得在成为专家之前仍然有很多东西要学习。

优秀的管理人员正在寻找可以担任更大领导角色的人才,但这有时会导致他们在准备就绪之前将人们从编码中移开。这种做法会对您的职业产生非常负面的影响,因为在更高级别的人员中,被认为“技术水平不够”的人会发现很难晋升为承担更多责任的管理职位。与尝试学习所有这些技能并同时学习管理技能相比,保持专注的个人贡献者角色并了解在那里需要学习的知识要容易得多。

在某个时候,即使您有兴趣留在个人贡献者(非管理人员)的职业道路上,也可能需要完成技术领导工作,才能取得职业上的进步。这并不意味着您现在需要这样做。如果您觉得有很多纯粹的技术知识可让您在团队中完成,而您希望与其他人一起在该项目上单独工作,请不要担任技术领导。另一方面,如果您认为个人工作不会给您带来技术上的挑战,那么也许是时候让您自己学习一些新技能了,而技术领导的技能则是尝试的好方法。

决策点:保持技术路线或成为经理

决定是否要成为经理或留在技术轨道上是一个艰难的决定。它是难以置信的特定于上下文的,我无法告诉您该怎么做。但是,作为一个梦想和生活在这两个轨道上的人,我可以告诉您我是如何想象角色以及我最终经历和观察的。因此,请注意,这些只是讽刺漫画,而不是一成不变的,让我告诉您想象力和现实如何对我有所不同。

想象中的高级个人贡献者的生活

您的日子花在各种深层思考上,解决一些棘手的难题,这些难题在智力上挑战您,但仍然充满乐趣和新颖性,并与其他深刻的思想家合作。它是软件,因此您知道会有一些牛刮毛,但是您可以做一些最有趣的工作,并且您有很大的能力选择要处理的工作。您喜欢编写代码,修复代码,使代码运行更快,使计算机做新的事情,并且您将花费大量的时间来执行此操作。

由于您的资历,经理会在开发开始之前就如何进行开发向您提出建议,因此您知道正在发生的一切,但您实际上并不需要处理构建人员的细节。我们邀请您参加制定重要决策的正确会议,但会议数量不至于干扰您的流程。越初级的开发人员就会仰视您,并抓住您的每个单词,以获取您的反馈,但又不会过多地影响您的深层思考时间。

您的上升轨迹永远不会减慢,总会有新的大问题可以解决,以向组织展示您的价值。您会努力工作,但很少有人要求您熬夜或周末工作,因为众所周知,每周工作太多小时是不可能完成高质量,周到的工作的。当您上班迟到时,是因为您陷入了如此繁忙的流程,以至于迫不及待想要完成手边的功能或修复刚刚发现的错误。

您可以写书,进行演讲和创建开源工作,而且如果有运气和毅力,您将在整个行业享有盛誉。没有人会在乎您有点尴尬或害羞,也不希望您发展自己的沟通方式,因为您说的话是如此重要。您组织中的每个人都知道您是谁,了解您的工作有多有价值,并尊重您的意见。

简而言之,您在工作,名声和积累的专业知识之间达到了完美的平衡,这使您变得无价,受人尊敬,高薪和有影响力。

高级个人贡献者的真实生活

当您找到正确的项目以及正确的项目的正确生命周期时,您的生活就很棒。您面临挑战,并且可以学习新事物。您对日常事务有很多控制权,当然,会议要比管理部门的同事要少,但是您的日子并不总是在幸福的状态下度过。在每个项目中,都有一个想法,然后将其出售给人们,试图说服他们这是正确的方法。或者,您已经实施了该系统,但是现在您需要让其他团队开始使用它,因此您需要与他们一起坐上几天,向他们展示来龙去脉,解释其用途,并试图说服他们游说经理有时间采用它。

您的上升轨迹并不像您希望的那样快速便捷。实际上,它非常慢。那些证明您是一名宝贵的建筑师的大型项目很难找到。团队不需要新的编程语言,新的数据库或新的 Web 框架。您的经理不擅长将您的才华向整个组织展示出来。她希望 告诉 这些机会在哪里。发现好的项目似乎是个运气。选择错误的项目,尽管您尽了最大的努力,但您却花了几个月甚至几年的时间去做可能会被取消的项目。您对管理中的朋友有些嫉妒,他们在保持团队成长的同时,晋升得更快。

其他开发商则是混血儿。您是一个很好的人,所以其中一些人欣赏您并听取您的意见,但其他人似乎嫉妒您的影响力。新开发人员要么花费太多时间,要么出于某种原因似乎害怕您。领导大型有趣项目的同行肯定具有一定的竞争力。

您的经理有点痛苦。她并不十分支持您希望开源系统的愿望,因为您认为它为行业需求提供了一种新的日志记录方法,并且她建议如果您要进行演讲或写书,也许您需要花费一些时间。这些时间上的私人时间。她会征求您对技术问题的反馈,但有时会忘记告诉您有关新计划的信息,直到您花两美分为时已晚。您怀疑您错过了重要信息,因为您没有参加正确的会议,但是每次她邀请您参加这些会议时,您都会记住它们是多么无聊和低效,以及您失去了多少宝贵的聚焦时间。而且她对您希望摆脱繁琐的工作(例如回复电子邮件,面试,

尽管如此,您大多数时候还是会构建东西。您可以将时间花在技术问题,系统设计和工程问题上,而不必与他人打交道或参加无聊的会议。您通常可以选择项目,如果需要新的东西,可以在团队之间轻松移动。而且您发现自己的薪水比您的经理还高!因此,生活并非一帆风顺。

想象中的经理生活

您拥有团队,拥有控制权,可以做出决定,最终可以让其他人按自己的方式做事。您的团队尊重您,并乐意在所有事务中屈服于您的权威。您认为他们应该编写更多测试?您告诉他们,“编写更多测试”,然后他们就会这样做!您想确保每个人都受到平等对待,而不管其性别,种族等如何?您确保做到这一点,并解雇任何越界并创建一个对团队其他成员不利的环境。

因为您关心别人,所以他们知道即使他们不同意您,他们也总是尽力为他们尽力。他们给您带来疑问的好处,当您搞砸时,他们会以公开的反馈为您提供 1-1,并渴望收到您的反馈。当然,与人打交道会带来压力,但他们知道您在乎他们,因此也很有意义。您现在处于这种权威地位,您会看到教练的影响迅速发生。

当您看到另一位经理做错了事时,您可以自由地给他建议,就像与需要系统设计帮助的另一位工程师交谈一样。其他经理总是对听到您的想法感兴趣,他们可以看到您使团队工作的效率如何,您对组织的健康状况的关心程度如何,以及使所有人变得更好的真正兴趣。

您的经理会为您提供大量指导,但很少介入以告诉您该怎么做。在您准备组建一个更大的团队的那一刻,您的经理很乐意为您提供更多的人员并扩大您的组织。她向您传递清晰的目标,很少改变任何事情。即使您承担很多责任,您仍然有一些时间来撰写博客文章并进行演讲,这受到鼓励,因为这将帮助您的团队聘用并提高您在科技行业的地位。

简而言之,您可以做出决定,创建文化,并且您的效率对周围的人都是显而易见的,这使您可以快速晋升,职业生涯令人兴奋而有利可图。

经理的真实生活

你有一个团队。您拥有一定的控制权,但是您很快发现,让人们去做某事比仅仅告诉他们去做要困难。您似乎已经放弃了对自己日常的所有控制。通常,您整天都在开会。您知道即将到来,但是直到您活了下来,您才真正了解它的含义。当您只有一个很小的团队时,您可以平衡事物并仍然编写代码,但是随着团队的成长,您已经失去了与代码的联系。它会咬你作为你应该做的事情,但是没有时间了。每次花几个小时编写代码,您就会意识到将其检入并让团队支持它是不负责任的,因此最好在这里获取一个脚本,在那里调试一个问题。专注于自己打造更大的东西是遥远的回忆。

您可以做出决定 - 好吧,一些决定。实际上,您可以缩小将要决定的事情的范围。您可以将团队的精力集中在某些事情上,例如编写更好的测试,但是他们仍然有要实施的产品路线图,并且对于应优先考虑哪些技术任务也有自己的想法。因此,除了自己做出决定之外,您还可以帮助团队做出决定。您的经理给您目标,但有时有时会完全更改这些目标,这取决于您向团队解释。

您确实为团队设定了文化标准,这是好是坏。当他们照顾到您最好的方面时,这是一件好事,而当您意识到您的团队也在反映您的过错时,那是不好的。

您的团队自然不会仅仅同意您,尊重您,甚至不喜欢您。您意识到授权不仅需要标题。当项目进展不佳时,或者当您不得不告诉个人他们还没有准备好晋升,他们没有得到加薪,没有东西的时候,您会发现自己正努力激励他们度过艰难的时期今年奖金。他们中有些人不高兴的时候不会告诉你。他们只是受够了然后退出,直到您注意到有什么问题。当公司运转良好时,您有很多钱可以支付,并且有许多令人兴奋的项目,生活就很棒;但是,当事情充满压力时,您就会发现让人们开心的力量很小。更糟糕的是,您甚至必须经过疯狂的 HR 程序才能解雇人员!仍然,您会发现您的工作对其中的一些人很重要,由于您的指导,他们变得更快乐,更成功。这些小小的胜利使您度过了艰难的时刻。

其他经理对您的反馈不感兴趣。实际上,当他们认为您正在蚕食他们的地盘时,他们会发现您正在干预并获得竞争优势。您自己的经理不同意您已准备好组建一个更大的团队,也无法真正解释原因。他的教练技能还有很多不足之处。也许他只是担心您会胜过他?不过,他绝对不希望您花费所有时间进行演讲 - 无论您离开办公室太多,无论团队可能从中获得多少价值,他都会感到烦恼。在不损害同事或老板的情况下弄清楚如何领导的政治比您预期的要棘手。但是,如果您可以组建更大的团队,就知道您将获得升职,因此至少您的道路是明确的。当您发现为您工作的工程师比您赚的更多时,您几乎输了,所以最好弄清楚如何快速组建更大的团队。否则,所有这些压力和废话的意义何在?

我的最终建议是记住,您可以根据需要切换曲目。人们通常会在某个时候尝试管理,意识到他们不喜欢它,然后回到技术轨道。关于此选择的任何内容都不必是永久性的,但请睁大眼睛进入。每个角色都有其优点和缺点,这取决于您感觉自己最喜欢什么。

好经理,坏经理:流程沙皇

流程沙皇认为,有一个真实的流程,如果正确实施并按照设计进行,它将解决团队的所有最大问题。沙皇可能会沉迷于敏捷,看板,混乱,精益甚至瀑布方法。他们可能对呼叫应如何工作,必须如何进行代码审查或发布过程如何运行有非常精确的想法。他们往往非常有条理并且对细节很满意,并且善于了解规则并精确地遵循它们。

流程沙皇通常在质量检查,服务台或产品管理小组中找到。它们在咨询机构和其他对特定工作进度进行评估的地方也很常见。他们可能专注于运营,尽管根据我的经验,您的经典系统运营团队中相对而言很少。他们可以成为项目管理团队中非常有价值的成员,因为他们倾向于确保没有遗忘任何任务,并且按照应有的方式包装了所有内容。

当流程沙皇未能意识到大多数人不擅长遵循流程时,他们就会感到挣扎。他们倾向于将所有问题归咎于未能遵循最佳流程,而不是承认需要灵活性以及意外更改的必然性。他们经常专注于易于测量的事物,例如办公室的工作时间,而错过了专注于易于度量的事物时无法捕捉到的细微差别。

相信“适合工作的工具”的工程师有时在成为技术领导时会变成沙皇,寻求解决计划,重点,时间管理和优先级等所有问题的正确工具。他们在寻求完美流程的过程中尝试停止所有工作,或者不断推动团队中的新工具和流程来解决人类互动中较为棘手的问题。

流程沙皇的反面不是不是一个完全放弃流程的经理,而是一个了解流程必须满足团队和工作需求的人。具有讽刺意味的是,尽管“敏捷”通常是严格地实施的,但 《敏捷宣言》 的原则却很好地总结了健康的过程领导力:

  • 个人与流程和工具之间的互动
  • 通过全面的文档工作软件
  • 客户合作而非合同谈判
  • 响应计划变更

作为新的技术领导,请谨慎依靠流程来解决由于团队中的沟通或领导力差距导致的问题。有时,对流程进行更改会有所帮助,但这很少是灵丹妙药,而且没有两个伟大的团队在流程,工具或工作方式上看起来完全相同。我的另一条建议是寻找自我调节过程。如果您发现自己扮演了任务负责人的角色(批评违反规则或不遵循流程的人员),请查看流程本身是否可以更改为更易于遵循。玩规则警察很浪费您的时间,而自动化通常会使规则更加明显。

作为流程沙皇的经理,请帮助该人更轻松地处理歧义。与许多经理的陷阱一样,对流程的痴迷可能与对失败的恐惧以及对控制事物以防止意外的渴望有关。如果您是诚实的并且清楚地指出失败和不完美是安全的,那么通常这足以使您的流程专家放松一下并让他们变得模棱两可。防止流程专家花费所有精力是非​​常重要的寻求完美的工具或流程,尤其重要的是要确保他们不会因不遵守流程而惩罚团队。

如何成为一名伟大的技术领袖

伟大的技术领先者具有许多特征,但这是最重要的。

了解架构

如果您担任技术领导,但又觉得自己不完全了解所支持的体系结构,请花一些时间来理解它。学习吧。对此有所了解。可视化它。了解其连接,数据所处的位置以及系统之间的流动方式。了解它如何反映所支持的产品以及这些产品的核心逻辑所在。当您不了解要更改的体系结构时,几乎不可能很好地领导项目。

成为团队合作者

如果您自己进行所有有趣的工作,请停止。查看棘手,无聊或烦人的技术需求区域,看看是否可以解决这些问题。在代码库中不那么令人兴奋的部分上工作可以教会您很多有关过程中断的地方。对于无聊或令人沮丧的项目,如果有经验的人花时间查看它们,通常会发现并修复一些明显的问题。如果您只是在做最无聊的工作,也请停止该工作。您是一名高级工程师,具有作为开发人员的大量才能,因此承担一些较艰巨的任务是合理的。您想鼓励团队中的其他人学习整个系统,并希望给他们机会扩展自己,但是您不必总是在选择工作上自我牺牲。偶尔给自己一个有趣的任务,

领导技术决策

您将参与团队的大多数主要技术决策。但是,参与其中与作为一个人使所有这些人变得不一样。如果您在不征求团队意见的情况下开始做出所有技术决定,那么他们会怨恨您,并在出现问题时责备您。另一方面,如果您不做任何技术决定,而是将一切留给团队,那么原本可以迅速做出的决定可能会拖延而无法解决。

确定您必须做出哪些决定,应该将哪些决定委派给具有更多专业知识的其他人,以及哪些决定需要整个团队来解决。在所有这些情况下,请清楚说明正在讨论的问题,并传达结果。

沟通

现在,您的生产力已不如整个团队的生产力重要。通常,这意味着您要提前付出沟通开销的代价。您不必代表每个团队成员参加会议,而是可以代表团队,传达他们的需求,并将会议中的信息带回团队。如果一位通用人才将成功的领导者与其他人才区分开来,那就是沟通技巧。成功的领导者会写得很好,他们会仔细阅读,并且可以在小组面前站起来讲话。他们在会议上关注并不断测试他们的知识和团队知识的极限。现在是练习写作和口语技能的好时机。编写设计文档,并从更好的作家那里获得反馈。为您的技术博客或个人博客撰写博客文章。在团队会议上发言,

在所有这些交流过程中,请不要忘记听。给其他人讲话的机会,听他们说些什么。练习将事情重复讲给别人,以确保您理解它们。学习如何听到别人说的话,并用自己的话重新表达。如果您不是一个好记笔记者,则可能需要成为一个。无论您选择深入研究技术还是成为经理,都没有关系 - 如果您无法交流和倾听其他人的讲话,从那时起您的职业发展将受到影响。

评估自己的经历

您的组织有技术领导吗?这个职位有书面的职位描述吗?如果是这样,它怎么说?如果不是,您将如何定义组织中的角色?技术领导将如何定义角色?
如果您正在考虑成为技术领先者,您准备好推动自己了吗?您是否愿意在代码之外花费一些时间?您是否觉得自己足以胜任代码库方面的专家,从而能够成功领导他人工作?
您是否曾问过经理,他 / 她对技术领导的期望是什么?
谁是您合作过的最好的技术领导?这个人做了什么使他或她伟大的事情?
您是否曾与令人沮丧的技术领导合作?他或她做什么使你感到沮丧?

下一章:管理人员

打赏
支付宝
微信
本文作者:CodingRabbit
版权声明:本文首发于CodingRabbit的博客,转载请注明出处!