建立和授权高绩效团队有助于产生出色的结果，这已经不是什么秘密了. It sounds simple enough, but how do you truly build this type of dream team? It all hinges on learning.
作为软件工程师，我们的工作围绕着快速吸收和利用新的和不熟悉的技术, libraries, frameworks, systems and codebases. Learning is the largest day-to-day time sink for engineers.
Learning takes time
This learning takes up many forms. 下面是我每天在工作中学习的一些常见方法:
- programming languages and their features
- libraries and package ecosystems
- underlying technical concepts
- codebases – where everything lives and what it all does
- best practices – for technologies, libraries and codebases
- general engineering principles
- how to go about working on code to produce the desired results
- non-functional domain knowledge
It’s a lot.
传统的学习和发展方法，如会议和课程，可能很难涵盖这种学习. 根据我的经验，他们倾向于深入学习一个大的主题, rather than many small topics quickly. 虽然这些对传统的学习和发展活动很重要, such as enhancing careers or expanding your knowledge, 它们不适合复杂的项目和以团队为中心的学习.
当我们知道我们需要做什么并且确切地知道如何做时，软件工程可以(令人惊讶地)快速和简单. 但这就是挑战所在——我们如何真正优化团队，以便在工作中进行这种类型的学习?
It’s time to buddy up!
One fantastic method is paired programming. Now, 有些人认为结对/分组的工程师效率较低，因为可以同时完成的票据较少——例如，在一个6人的团队中结对工作, only 3 tickets get worked on at once. But pairing or grouping is hugely efficient for learning. Even though you’re doubling up team members, 你把集体学习的时间减半了，所以仍然有很大的价值.
与他人合作解决日常问题可以帮助你同时学到很多东西. For example, 如果你和另一个工程师结对——你正在学习正在使用的语言, the codebase they’re working on, how they go about engineering and implementing the feature. 通过与他人合作，我们可以理解我们不知道我们需要学习的东西!
通过让工程师们积极地相互教授，并在联系在一起的情况下经常重复知识，我们 maximise the retention of that information. This also invokes the protégé effect, 这告诉我们学习(或巩固你以前的学习)一个主题的最好方法是把它教给别人.
Paired programming has a long list of benefits to a team. It reduces problem solving time, catches more mistakes early, 帮助人们建立导师/被指导者关系，通常会阻止我们变得太孤独. I strongly recommend pairing, 但我也强烈建议不要把它强加给一个自信而快乐的团队. Not all activities (i.e. 那些问题和解决方案都被很好地理解的地方)需要配对，如果经常使用，它会变得很消耗人.
Modern software delivery is a team sport
Next up is building a resilient mesh of overlapping knowledge within a team. 在这个网格中，有一个共享的“核心”知识，团队中的每个人都应该知道——这通常是需要经常使用的公共部分.
T-shaped skills graphs describe something very similar, with the idea being that in a team of generalist engineers, 有一个共享的核心基础知识，允许任何人在理论上从事任何工作. It also protects the team from disasters, 比如当一个掌握着大量知识的关键团队成员离开公司时.
重要的是要意识到，对个人的最佳选择并不总是对团队的最佳选择. Modern software delivery is fundamentally a team sport. As an individual member of the team, you need to check your ego at the door. 准备好通过结对或回答他们的问题来支持你的同事，而不是自己做大量的工作.
Don’t forget culture
然而，在一个足够复杂的项目中，筒仓和知识专长自然会发展起来. 当然，通过与特定技术和代码库领域的交互，人们对它们的了解会越来越多. In a knowledge mesh, 确保每个人都知道每件事是低效的(也是不可能的). Instead, 高绩效团队的成员应该对问“愚蠢”的问题以及用问题打断团队成员来解开工作障碍的想法感到自在.
Remember: there are no dumb questions. 问一个快速的问题，即使会分散别人几分钟的注意力，也比在你离开自己解决问题的时候继续专注于你的任务要有效得多! 这种方法的关键是拥有强大的团队文化和良好的心理安全感. After all, people can feel vulnerable when admitting they don’t know things.
In teams with weaker cultures or poor psychological safety, 工程师们可能会感到压力，要将自己与同行进行比较，并单独承担困难的任务，以验证自己的能力. Knowledge silos also tend to appear, 因为团队成员在他们不熟悉的领域工作时，会感到不自信.
To prevent this, 而不是用个人贡献的总和来评估团队的生产力, we should evaluate it as the collective output of the entire team. By switching a team to use systems such as four key metrics, 我们可以努力提高团队的产出，而不必担心每个人完成了多少票/功能/故事点等不重要的细节.
We’re always learning
Learning is the major time sink for engineers delivering software. 但是，通过优化我们的团队学习，我们能够更好地支持团队成员之间的协作工作和定期提问——这对于建立高绩效团队至关重要.
As engineers, we’re always learning. If after reading this you have any feedback, further suggestions or just want something clarified – please get in touch!
If you’d like to read more about software engineering, subscribe to our Made Tech Insights newsletter to get new blog posts straight to your inbox.
