最近，我越来越意识到搞砸的管理情况会导致搞砸的技术情况。在过去的几个月里，我写了一些关于这个的文章，并开始思考不久前的一个具体轶事。
我在一个团队工作，这个团队应该是应对中断和其他类似问题的“最后一道防线”。这个团队运行的一项服务一直存在问题，该服务运行在车队的每个系统上，并且对于保持运行至关重要（你知道，猫的照片）。我们无法弄清楚为什么它一直在发生。
最终，我结束了从我的“修复者”团队转移到包含有问题的团队的组织，我的第一个“职责”是嵌入该团队以弄清楚发生了什么。我的发现很有趣。
最初的团队成立几年前，但那些最初的成员已经不在了。他们已经转向公司内部的其他事情。原来的人还在的时候，有一个人加入了团队，此时，他是唯一一个和原来的开发人员“重叠”的人。
我发现，这个历史可以追溯到“OG”还在的时候的人基本上承担了整个团队的重担。其他人都很新，所以这取决于他。
我开始了解他，发现他不是坏蛋，甚至不是恶意的。他刚刚承受了太多的负担，结果发疯了。不知何故，我们设法调用超时并让他们停止运送破损的东西一段时间。然后我很幸运，在他仍然处于愚蠢的高负载下时截获了一些更奇怪的想法，我们让其他一些人站出来开始分散负载。
我也参与其中，比如尝试帮助团队中一些恼怒的客户并做一些一般的“客户服务”工作。我的想法是，如果我可以代表团队做一些“防火墙”类型的工作，这会给他们一些空间，这样他们就可以放松并弄清楚如何前进。
这非常有效。令人惊讶的是后来开始了半年一次的审查周期，“校准会议”开始了。他们想给这个人一些胡说八道的低于标准的评级。我基本上是说，如果他们给他的任何东西都不“符合预期”，我会非常生气，因为这不是他的错。
有趣的是，他们向我的一位前队友提出了同样的问题（他也一直在处理这些相同可靠性问题的后果），而他也说了同样的话！直到很久以后，我们才知道我们都被问到了这件事。我们甚至没有与超负荷的工程师讨论过这种情况。这对我们俩来说都是显而易见的。
由于我们都给出了相同的反馈，他们认真对待，并没有在评论中对他进行吹嘘。他继续为监控和其他新事物做了一些非常有趣的事情（包括首先将其从团队的其他成员那里反弹），并最终推开（希望）更快乐的海岸。
与此同时，该服务在不破坏事物方面做得更好。团队似乎以前所未有的方式凝聚在一起。它甚至挺过了一场真正疯狂的周五晚上活动，您认为这会导致整个站点中断，但事实并非如此。每个人都聚在一起解决了这个问题。最大的影响是内部没有人可以在几个小时内发布新功能，而我们已经弄清楚并让一切恢复正常。外界从未察觉。
在那件事之后不久，我认为该团队“毕业”了，我不再需要与他们并肩作战，然后去了公司基础设施组织的那个特定部分的下一个古怪团队。
这从来都不是技术问题。这是一个肩负着 3 或 4 个人重担的人，他尽了最大努力，但仍然非常人性化，因此在压力下崩溃了。事后他们试图把他扔到公共汽车下，但我们不会容忍。这首先是让它发生的管理问题。
看看它怎么运作？