Teamwork in Practice: Humility
Humility is simply teachability.
The difference between theory and practice is usually gained through experience. Nowhere is this more apparent than high level aims of good performance. Teamwork is a particularly interesting skill that is very valuable but at times hard to test. Teamwork is a nebulous proposition, and it is particularly tricky when you have to evaluate your value, and what you brought to the table.
Everyone says you should have good teamwork, and in school, there are group projects for every class to give you the opportunity to practice. However, those cases are usually idealized in the sense that the projects are smaller in scope, and the components are more interesting.
Teamwork in industry requires something else: humility.
Humility as a principle is greatly under-appreciated and misunderstood. Humility is both a willingness to learn as well as a willingness to sacrifice. Humility says that our part in a large project is both important and required, but everyone else’s job is as important and required. So if you view everyone’s job on the project as essential and important as your job, then you will have some humility. This includes all the service staff like the cleaning staff. While they may not seem like they are building the product, they are doing a job necessary for the company to succeed.
Most projects that succeed require a huge amount of team work through many people and other companies. The result is that no one person makes even 1% of the total contributions. This is hard to learn in school where the largest projects have 10 or so people and are design projects.
Humility is thus a willingness to do the jobs necessary for the product to succeed even if they are not always glamorous. On Face ID, there were dozens of people who could train the deep net, but not that many actually did. At the same time, the project was so large that even the people training the deep nets were a small piece of the puzzle. At times, I saw those jobs as the most glorious jobs, but they would have failed entirely without a network of people collecting, storing, cleaning, labeling, and analyzing data.
From the team perspective, everyone should be replaceable. Not being able to replace people puts the team as a whole at risk if someone leaves. So while it may seem good for job security to be able to do a task nobody else can, the best path is to be able to do or learn other jobs in case your job goes away.
While on one project, an algorithm designer left. He was the only one with full knowledge of the algorithm. Instead of freaking out, our leadership sat us down, told us we would be stronger for it, and afterwards, everyone learned the algorithm so thoroughly, we even found some major improvements.
If someone, something, or some vendor becomes essential, it is only an illusion. Essential is temporary.
How do you separate your contributions from the team? If all you do is focus on the team at the sacrifice of your own goals, will that sacrifice later opportunities?