More on this book
Community
Kindle Notes & Highlights
Read between
June 8 - July 11, 2019
It turns out that this Genius Myth is just another aspect of our insecurity. Most programmers are afraid to share work they’ve only just started, because it means peers will see their mistakes and know the author of the code is not a genius. To quote a programmer from Ben’s blog:
Humility You are not the center of the universe. You’re neither omniscient nor infallible. You’re open to self-improvement. Respect You genuinely care about others you work with. You treat them as human beings, and appreciate their abilities and accomplishments. Trust You believe others are competent and will do the right thing, and you’re OK with letting them drive when appropriate.
“being humble” is not the same as saying one should be an utter doormat: there’s nothing wrong with self-confidence. Just don’t come off like a know-it-all. Even better, think about going for a “collective” ego instead; rather than worrying about whether you’re personally awesome, try to build a sense of team accomplishment and group pride. For example, the Apache Software Foundation has a long history of creating communities around software projects; these communities have incredibly strong identities and reject people who are more concerned about self-promotion.
The trick is to make sure you (and those around you) understand the difference between constructive criticism of someone’s creative output and flat-out assaults against someone’s character. The latter is useless — it’s petty and nearly impossible to act on. The former is always helpful and gives guidance on how to improve. And most importantly, it’s imbued with respect: the person giving the constructive criticism genuinely cares about the other person and wants her to improve herself or her work. Learn to respect your peers and give constructive criticism politely. If you truly respect
...more
The more you are open to influence, the more you are able to influence; the more vulnerable you are, the stronger you appear. These statements sound like bizarre contradictions. But everyone can think of someone they’ve worked with who is just maddeningly stubborn. No matter how much people try to persuade him, he digs his heels in even more. What eventually happens to such team members? In our experience, they end up just getting “routed around” like an obstacle everyone takes for granted. People stop listening to their opinions or objections.
Choose your battles carefully. Remember that in order to be heard properly, you first need to listen to others.
In short, you should care because if you don’t put effort into building and maintaining your culture, your team will eventually be overtaken by strong personalities that cultivate their culture in your team. This culture may turn out to be a productive, healthy culture that cranks out piles of great code, but more often than not, it won’t turn out as such, and you’ll suddenly find a lot of your energy that used to go into designing and creating your product is suddenly expended in arguments and infighting.
If you’re happiest when writing code and shipping product, it’s definitely in your best interest to find a team that values that, and to work to maintain that environment. It’s not that you can’t create something great without a strong and productive culture, but it’s going to cost you a lot more time and energy to do so without one. A strong culture gives you focus, efficiency, and strength, and these things make for a happier team.
In the assembly line environment, employees are accomplishing simple tasks, often by rote, with little creative-thinking or problem-solving skills required. In the software world, a great deal of creative thinking is required of engineers working on a product,3 and if you want a great product, you need great engineers. If you want great engineers to do great work (and to stick around), you need to create a culture for them that allows them to safely share ideas and have a voice in the decision-making process.
If you examine any successful, efficient culture, you’ll find high value placed on numerous channels of communication, such as mailing lists, design docs, chat rooms, mission statements, code comments, production how-tos, and more.
A good general rule around communication is to include as few people as necessary in synchronous communication (like meetings and phone calls), and to go for a broader audience in asynchronous communication (like email, issue trackers, and document comments).
it’s an excellent example of a mission statement: it includes both a direction (improve the web experience…by enabling developers) and a scope limiter (Java tools). Several years later we were having dinner with the team lead, and Fitz told him how thankful we were that he had supported us so strongly in our effort to get the team to write a mission statement. He responded that he had actually thought the entire exercise was a waste of time when we first proposed it, but that once he started debating it with the team, he discovered something he’d never known: his lead engineers did not agree
...more
If you’re trying to design something new, try to include no more than five people in your meeting — it’s practically impossible to come up with new designs and make decisions with more than five people in a room unless there’s only one person in the room making the decisions.
Whoever’s running the meeting should actually run the meeting and not hesitate to (gently) cut off someone who veers off-topic or, even worse, tries to monopolize the conversation. Doing this well can be tricky, but is worthwhile. And most importantly, don’t be afraid to end a meeting early if you’ve completed the agenda.
When you’re part of a distributed team or working remotely from them, you not only need to find different ways to communicate, but also need to put more work into communication, period.
One thing to note about all of these people is that, despite all the advances in social media and videoconferencing technology, nothing even comes close to the bandwidth and the intimacy of being face to face with someone else in real life.
A design doc is typically owned by one person, authored by two or three, and reviewed by a larger set. It serves not only as a high-level blueprint of your future project, but also as a low-cost way to communicate to your larger team what you want to do and how you intend to do it.
Since you haven’t spent weeks (or months) writing code, it’s a lot easier to accept criticism at this point and you’ll wind up with a better product and a better implementation. In addition, once you’ve nailed down the design doc, it will serve as your guide for both scheduling and dividing the work on your project.
No matter what your team’s culture is, and regardless of how well your team communicates, every effective team that we’ve ever seen has a leader. In the next chapter, we’ll look into what makes the most effective team leader, why her role is probably not what you think, and why it’s important for every team member to understand the basics of leading a team.
Great engineers also demand great team leaders, because crappy leaders not only tend to be too insecure to deal with great engineers, but also tend to boss people around.
“Leader” Is the New “Manager” Most people still use the title “manager” despite the fact that it’s often an anachronism. We think the term manager should be eliminated and the term leader should be used instead.
Traditional managers worry about how to get things done, while leaders worry about what things get done…(and trust their team to figure out how to do it).
There are great reasons to consider becoming a manager: first, it’s a way to scale yourself. Even if you’re great at writing code, there’s still an upper limit to the amount of code you can write. Imagine how much code a team of great engineers could write under your leadership! Second, you might just be really good at it — many people who find themselves sucked into the leadership vacuum of a project discover that they’re exceptionally skilled at providing the kind of guidance, help, and air cover a team needs.
The symptoms of this disease include, but are by no means limited to, micromanaging, ignoring low performers, and hiring pushovers.
The team at Google that is responsible for keeping all of their services running has a motto: “Hope is not a strategy.”
While the leader is hoping and the low performer isn’t getting better (or leaving), high performers on the team waste valuable time pulling the low performer along and team morale leaks away into the ether. You can be sure that the team knows they’re there even if you’re ignoring them — the rest of the team is acutely aware of who the low performers are, because they have to carry them.
Ignoring low performers is also a way to keep new high performers from joining your team, and a way to encourage existing high performers to leave.
cost of dealing with an employee you never should have hired in the first place. This “cost” manifests itself in lost team productivity, team stress, time spent managing the employee up or out, and the paperwork and stress involved in firing the employee.
We can assure you that you will not get everything right, nor will you have all the answers, and if you act like you do, you’ll quickly lose the respect of your team.
Try to appreciate inquiry: when someone questions a decision or statement you made, remember that this person is usually just trying to better understand you. If you encourage inquiry, you’re much more likely to get the kind of constructive criticism that will make you a better leader of a better team.
asking questions. When a team member asks you for advice, it’s usually pretty exciting because you’re finally getting the chance to fix something! That’s exactly what you did for years before moving into a leadership position, so you usually go leaping into solution mode, but that is the last place you should be.
The person asking for advice typically doesn’t want you to solve her problem, but rather to help her solve it, and the easiest way to do this is to ask her questions.
Working to build team consensus is a leadership skill that is often used by unofficial leaders because it’s one way you can lead without any actual authority. If you have the authority, you can direct and dictate direction, but that’s less effective overall than building consensus.
One of the hardest things to do as a team leader is to watch a more junior-level team member spend three hours working on something you know you can knock out in 20 minutes.
Teaching people and giving them a chance to learn on their own can be incredibly difficult at first, but it’s a vital component of effective leadership. This is especially important for new hires who, in addition to learning your team’s technology and code base, are learning your team’s culture and the appropriate level of responsibility to assume.
the ability to gauge how much help your mentee needs. The last thing is probably the most important — giving your mentee enough information is what you’re supposed to be doing, but if you overexplain things or ramble on endlessly, your mentee will probably tune you out rather than politely tell you she got it.
When you’re providing direct feedback or criticism, your delivery is key to making sure your message is heard and not deflected. If you put the recipient on the defensive, he’s not going to be thinking of how he can change, but rather how he can argue with you to show you you’re wrong.
Yet another leader starts one-on-one sessions with his team members by dealing with their technical issues as a way to break the ice, and then takes some time to make sure each engineer has everything he needs to get his work done. After they’ve warmed up, he talks to the engineer for a bit about how he’s enjoying the work he’s doing and what he’s looking forward to next.
One of the most valuable tools in tracking your team’s happiness is, at the end of each one-on-one meeting, to ask the team member, “What do you need?”
there are usually a few things that everyone would like to do in the next five years: get promoted, learn something new, launch something important, and work with smart people.
If you’re new to a leadership role, you probably need to work hard to delegate work to other engineers on your team, even if it will take them a lot longer than you to accomplish that work.
Rarely will these problems work themselves out, and the longer you wait to address them, the more they’ll adversely affect the rest of the team and the more they’ll keep you up at night thinking about them. By waiting, you’re only delaying the inevitable and causing untold damage in the process. So act, and act quickly.
When Ben first got asked to manage a large team, a similar script went through his mind: “You want me to own this project? That’s crazy, but OK, I guess I’ll pretend to be a leader for a while.” Then every year at performance-review time, he’d look back at his success and and say, “Yeah, I guess I’ll keep pretending a bit longer — seems to be going well!”
Dan claims you can increase intrinsic motivation by giving people three things: autonomy, mastery, and purpose.
The term poisonous person is a nasty label and automatically creates a dividing line between “us” (the good guys) and “them” (those nasty jerks). There’s a better way to think about the problem. Instead of running your team as an elite fraternity with a mission to “repel mean people,” it’s healthier to create a culture that simply refuses to tolerate certain negative behaviors. It’s the behaviors you want to filter out, not particular individuals.
Establish proper etiquette around email discussions. Keep archives, get newcomers to read them, and prevent filibustering by noisy minorities.
Document all history: not just code history, but also design decisions, important bug fixes, and prior mistakes.
Rely on consensus-based decisions, but also have a fallback process for resolving conflicts when consensus can’t be reached.
If you’re going to defend your team against poisonous people, the first thing you need to do is to understand exactly what constitutes a threat and when you should become concerned. What’s specifically at risk is your team’s attention and focus.
look for facts. If someone is complaining, listen carefully. Always start by giving the person the benefit of the doubt, despite the angry or rude language. Does the person have a real point? Is there something to learn from the person’s experience, or is there an idea worth responding to?
