The critical idea in this chapter is that software development is a team endeavor. And to succeed on an engineering team — or in any other creative collaboration — you need to reorganize your behaviors around the core principles of humility, respect, and trust.
At a previous company we had Leadership Principles. The way I explained why we had them was this:
Many of the Leadership Principles are part of a set of ways to think about how we impact the people we work with.
Are you a positive effect — magnifying, even? Is having you on the team making their code better, more productive, or even just happier?
Or a negative effect; are you dragging down the people around you?
And some people are neither. Maybe they're best doing mostly individual work.
That's independent of how good of an engineer you are. There are great engineers who can lift a team, and make them a super productive set of people. There are great engineers who might be best to send off on their own to bang out a solution mostly independently. Then there are those brilliant engineers that nobody can stand, who sometimes even repel the other great engineers.
I don't think Google's system (Difficulty, Leadership, Impact, and Citizenship) does this as well. There are elements in there, but it's not the same; it's not as targeted, or as effective in shaping behavior and evaluation.
