As everything else, I read and summarize I try and take notes that I can refer to myself at a later date. Either as a reminder to myself on what I have learned or so others taking the same path can gain insight into the lessons of a book. When reading I focus on how lessons apply to startups from the perspective of the engineering lead such as a CTO, CIO, or Head of Engineering.
I don’t agree that every strategy in this book is always applicable. There are engineering teams I’ve lead in India that wouldn’t respond to half of these strategies. The point is having tools available to try until you find the right combination to accomplish your goal.
Having good individuals does not make a good team. As a manager, it’s better to have a team aligned than siloed proficient individuals.
Absence of Trust
Often the root of the unwillingness or ability of the team to be vulnerable and open up to each other about mistakes. There is overlap with The Pragmatic Programmer which can be referred to in the mindset section. A team able to share insight and experience without feeling judgement will be more productive as the culmination of knowledge gives a substantial advantage.
Hiding the interpersonal shortcomings and deficiencies is already hardwired into our instincts. On top of that, the competition amongst the piers and the focus on hero culture can cause peers to be protective of their reputations. This lack of sharing weakness means the team runs less efficiently as work can’t be redirected as appropriate. A culture of admitting to mistakes serves the team, as a whole, better.
To enable increased trust.
Personal history exercise
Shortlist of seemingly uninteresting facts about themselves. I like to focus on mundane and worst experiences they have had so it doesn’t become a competition
Team effectiveness exercise
Have each peer list contributions that other peers make to the team. Have to be careful with this one so think about the current team dynamics and if this will have a negative impact before blindly implementing.
Fear of Conflict
Teams that trust are able to have conflicts. Conflicts are not inherently bad, it can be one of the most productive methods to innovate if it comes from a respectful place where the feedback will be taken as constructive instead of critical or punishable. This reminds me of one of my favorite books Crucial Conversations which applies more generally to life.
The key to these conflicts is to balance the positive of losing a little control and allowing members to put critical topics on the table so that real issues can be solved. While balancing the negative extreme of letting disputes regress into personally destructive attacks.
For creating healthy conversations.
Assign a respected understanding member of the team who is comfortable calling out sensitive issues. That one team member who is straightforward that no-one takes personally may be a good place to start.
When a conflict degenerates and becomes personal, interrupt. But when conflicts are ideological, identify as such and keep the conversation going.
Lack of Commitment
Psychologists have demonstrated that it’s more important to have opinions considered than implemented. No matter what the outcome the commitment by the team as a unit is necessary. The ability for a team to understand that there is always uncertainty and there will never be full consensus but it’s important to go in the right direction even if it’s not the optimal path. From a machine learning standpoint, this is like mini-batch gradient descent. Leaders can set an example of agreeing to a decision they aren’t in favor of putting the focus on the process to validate an idea instead of obsessing over the optimal trajectory.
For creating commitment.
Discipline is one of the most effective methods for dealing with a lack of commitment. Honoring and delivering for a deadline builds a public version of this commitment.
Fear of contributing to a disaster is a big reason for a lack of team member buy-in. Showing the worst-case scenario for the decision can allay the fear allowing commitment and focus. Lean product methodology does something similar with their de-risking approach. The cognitive bias of being risk-averse is another topic to read and consider.
When a team is committed, it is easier to hold the team accountable. Often, team members avoid holding each other accountable because of the fear of it jeopardizing a personal relationship. Encouraging positive peer pressure in an environment where there are commitment and vulnerability can help give the right push to improve of performance.
Publication of Standards
Making it clear the expectation of a project, feature, or sprint increases the transparency of who is responsible for the result. Making sure everyone knows where they fit into the bigger picture and that others are counting on them in something like a tracker during a standup is a way to prevent ambiguity.
In addition to rewards for individuals, rewards for teams should be more important. Reducing competition and incentivizing team dynamics reduces the wrong type of competition. In some situations, there may decrease personal responsibility so it’s important to keep that communication line open with other members to understand if this occurs.
Inattention to Results
Curbing interests to focus on the results of the team can give motivation in the right direction; the collective result. Individuals’ interests will almost always be more important than team interests as part of the human instinct. Getting results as a team and having results, instead of time, being the driving factor.
Teams that are willing to publicly commit to future victories are inclined to work towards it, even if it is to avoid public shaming. This connects back to the publication of standards and public deadlines.
Team-oriented awards on results is the ideal combination. Awarding one for doing with-in the absence of results incentivizes a less than ideal bevaviour.
Overall, I think there are many good lessons in this book. I don’t agree with everything here but that may also depend on my personal experiences with the engineering teams I’ve led. If you are like me where part of your engineering team is in India or Ukraine, adaptations to this may need to be made.