More on this book
Community
Kindle Notes & Highlights
I encourage you to create and build a strong network of peers.
When you want to work on projects, ask. Advocate for yourself. When your manager isn’t helpful, look for other places to get help. Seek out feedback, including constructive feedback on areas to improve. When that feedback comes to you, take it graciously, even when you don’t agree with it.
I can’t guarantee you that it’ll go well, but if you’ve set a goal for yourself, you owe it to yourself to do what you can to make it happen.
Especially as you become more senior, remember that your manager expects you to bring solutions, not problems.
When you have a problem, instead of demanding that your manager solve it for you, try asking her for advice on how she might approach the problem. Asking for advice is always a good way to show respect and trust.
Plenty of great engineers make ineffective managers because they don’t know or want to deal with the politics of leadership in their companies. A strong engineer may make a great mentor-manager to someone early in his career, but a terrible advocate-manager for someone who is more senior.
pay attention to your own behavior. Are you spending all your time thinking about what you want to say next? Are you thinking about your own work? Are you doing anything other than listening to the words coming out of his mouth? If so, you’re not listening well.
He may not ask questions even when he doesn’t understand things. Make your life easier and get those questions out of him. The odds of you spending all of your time answering questions are slim compared to the odds that your intern will go off in the absolute wrong direction because he didn’t ask enough questions.
You may be an introvert, or someone who does not find socializing easy, but conscious effort and practice in getting to know new people and helping them succeed will pay off. Your attitude about this will determine success or failure. Adopt the mindset that network building is a worthwhile investment of your time and energy.
Teams often fail because they overworked themselves on a feature that their product manager would have been willing to compromise on.
The politics of figuring out how to lead without undermining your peers or your boss are trickier than you expected. But
The opposite of the process czar is not a manager who gives up on process completely, but rather someone who understands that processes must meet the needs of the team and the work.
“Regular 1-1s are like going to a psychiatrist when you’re fine and discovering you have depression.”
Trust and control are the main issues around micromanagement.
Autonomy, the ability to have control over some part of your work, is an important element of motivation. This is why micromanagers find it so difficult to retain great teams. When you strip creative and talented people of their autonomy, they lose motivation very quickly. There’s nothing worse than feeling like you can’t make a single decision on your own, or feeling like every single piece of work you do has to be double- and triple-checked by your manager.
My advice is to dedicate 20% of your time in every planning session to system sustainability work (“sustainability” instead
These health signals — frequency of code releases, frequency of code check-ins, and infrequency of incidents — are the key indicators of a team that knows what to do, has the tools to do it, and has the time to do it every day.
Before you try to change everything to fit your vision, take the time to understand the company’s strengths and culture, and think about how you’re going to create a team that works well with this culture, not against it. The trick is not to focus on what’s broken, but to identify existing strengths and cultivate them.
figuring out what’s important, and going home.
same questions you ask your team: Can I do this faster? Do I need to be doing this at all? What value am I providing with this work?
discussion. Instead of talking about structure, I talk about learning. Instead of talking about process, I talk about transparency. We don’t set up systems because structure and process have inherent value. We do it because we want to learn from our successes and our mistakes, and to share those successes and encode the lessons we learn from failures in a transparent way.
One of the greatest writings about organizational politics is a piece called “The Tyranny of Structurelessness” by Jo Freeman. While the article is about early feminist/anarchist collectives, Freeman’s insights apply equally well to startup culture. Pretending to lack structure tends to create hidden power structures resulting from the nature of human communication and the challenges of trying to scale that communication.
Even when the overall company grows beyond the small group, the engineering team often pushes itself to stay unstructured. Hiring “full stack” engineers who are exclusively sourced from the professional and social networks of the current team results in low skill specialization and high homogeneity. Forcing the team to be collocated lowers communication barriers. And perhaps most critically, having an engineering team that operates solely as the execution arm of the product or founder makes the team highly task-oriented.
The example of the structureless team also applies to technical decisions and processes. There is a reason that you often find a lot of spaghetti code in early startups. When work is done to satisfy an immediate task, in a unified code base worked on by a team of interchangeables, the result is not usually a larger thoughtful structure, but a tweak here, a hack there — anything to get things done and moving forward. It’s no surprise that we usually end up refactoring spaghetti code when we want to make it scalable, because refactoring usually involves identifying and explicitly drawing out
...more
time. If the value of your future time is less than the value of your current time, then you’re probably not going to worry too much about saving future time.
In the modern SaaS world, bugs can be easily fixed, and the risk involved in shipping a bug is much lower than that of not expanding features quickly enough to keep up with competition. It’s
I said earlier that I prefer to talk about learning and transparency rather than using the word structure, because really what we’re talking about here is identifying the causes of failures, especially frequent failures, and trying to figure out what we can change to solve for those failures. This is fundamentally about learning.
Culture is how things get done, without people having to think about it.
Reality is much more of a race for survival, with culture as an afterthought or a post hoc justification.
communication. It is to your advantage to create a culture that allows for bringing a broader range of people into your community. “Engineers who graduated from MIT” is not a culture. “People who value technology innovation, hard work, intellect, scientific process, and data” might be. The first allows only an incredibly narrow subset of humanity to pass through it successfully. The second allows a much broader set of people to fit, while ensuring those people actually have the same values.
At our technology department all-hands meetings, we would have people give shoutouts to each other for “keeping it dope” and going above and beyond. Some people find this exercise uncomfortable, myself included. Reach through the part of you that is shy about praising people or embarrassed to share your feelings, and go into the part of you that cares about the people you work with. You can share these stories in a way that is not forced or fake. The stories that we tell as a community bond us together.
You certainly don’t want to hire people that your team can’t stand to be around, but cultural fit is not about hiring friends. I’ve had great working relationships with people that I would not want to chat with for hours outside of work, and terrible working relationships with people I would love to be stuck with in an airport.
A very smart engineer who really values independence may not be a fit for a team where everyone must collaborate extensively on all projects.
Someone who believes that the most analytical argument always wins may not work well in a company that values empathy and intuition over pure analytical skill.
Be clear about code review expectations. For the most part, code reviews don’t catch bugs; tests catch bugs. The exceptions to this rule are that code review can catch missing updates to comments or documentation or missing changes to related features, and code reviewers can sometimes tell when there is inadequate testing of the new or changed code. Code review is largely a socialization exercise, so that multiple team members have seen and are aware of the changed code.
Use a linter for style issues. Engineers can waste absurd amounts of time on questions of style, specifically formatting. This should not be up for debate in code review. Decide on a style, and put that style into a linter that formats the code automatically. Allowing style to be up for discussion in code review often leads to nitpicking and criticism that can feel unproductive at best, and bullying at worst.
In fact, instead of calling the process a postmortem, many have started calling it a “learning review” to indicate that its purpose is not determining cause of death but learning from the incident. There
The goal of architecture review is to help socialize big changes to the appropriate group, and to make the risks for those changes clear.
The most important lesson I’ve learned is that you have to be able to manage yourself if you want to be good at managing others. The more time you spend understanding yourself, the way you react, the things that inspire you, and the things that drive you crazy, the better off you will be.
Great managers are masters of working through conflict. Getting good at working through conflict means getting good at taking your ego out of the conversation.
