More on this book
Community
Kindle Notes & Highlights
One size does not fit all
Engineering School does not teach you to work with others.
Group projects and what they teach you
Team sports. Trust trumps talent.
You’re (probably) not a genius and that’s okay. Collaboration is far more important.
Working in groups increases the odds of success.
Early feedback reduces risk.
Don’t work alone
Team sports team sports team sports
I don’t like this example. it suggests one of your motivations for being nice to people is to get them to do stuff for you later. Very “how to win friends and influence people” to me. Treat people kindly because it’s good to treat people kindly.
I think this is a far better way to advocate “leave your ego at the door”
Be open to feedback.
Sometimes the best thing to say is “I don’t know”
Why have all the engineers had “He” pronouns, and the first “she” we get is a baker?
What makes a strong culture
all team cultures are self selecting
I really hope they go on to talk about the risks to doing this.
More team sports
Seek feedback
This is a great idea. I have worked on two teams that tried it, and it never sticks. No one is willing to call sidebar on someone else (esp when seniority or other power dynamics comes into it), and if it ever does happen, no one wants to be the first one to leave early, since it admits “I don’t care about this as much as you all.” Sort of like how when unlimited vacation is the rule, people take less vacation.
These rules are great. Only thing I see missing is stressing to *actually* show up on time. It’s futile to keep a meeting on track and stick to your agenda if others (or you!) cannot be bothered to show up on time
Hmmm. I’ve been in no-laptop meetings. What if we just asked those people to leave? Or didn’t invite them to the next iteration (if it’s recurring)
I think one of the problems with sync meetings is that they don’t have a dedicated runner
I would love some tips on how to actually make this happen. So far this seems easier said than done.
If you’re designing an email to be easy to filter (and therefore ignore), maybe you should consider just not sending them?
I think our use of chat tools has gotten out of hand. If I miss more than a day I just give up and mark everything as read
Any time someone DMs me with an on point question I ask them to stay in the public channel so others can learn as well.
More and more I get the vibe that real work is in the drudgery of the maintenance. Which few want to do because it’s not “glamorous” (see the previous points about celebrity and genius programmers). No one ever becomes a celebrity for quietly curating the backlog
Yes yes yes. To a certain extent I almost don’t care *how* you do something so long as you always do it that way
This is essential for understanding the style, gaining buyin, and making future changes
This could be the fact that I work on internals, but to me weekly is not frequent. Frequent is multiple times per day
I am curious to see if they cover what to do if you feel you don’t have a leader. Should you step up yourself? Is that considered mutiny or a coup? What if you don’t even want to lead, but just want someone to lead you?
I don’t really see how you can lead a project without having to deal with the people aspects of it
Trust goes such a long way
It doesn’t take a lot of formal education or preparation to be a mentor; in fact, you primarily need three things: experience with your team’s processes and systems, the ability to explain things to someone else, and 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.
Ithis last one is also very hard. Would love to get some tips here.
It can also be worthwhile to pay some attention to your team’s happiness outside the office. Be wary of assuming that people have no life outside of work — having unrealistic expectations about the amount of time people can put into their work will cause people to lose respect for you, or worse, to burn out. We’re not advocating that you pry into your team members’ personal lives, but being sensitive to personal situations that your team members are going through can give you a lot of insight into why they may be more or less productive at any given time.
This is walking a pretty tight line between caring and creepy
If you’ve been leading teams for a while or if you pick up a new team, one of the easiest ways to gain the team’s respect and get up to speed on what they’re doing is to get your hands dirty — usually by taking on a grungy task no one else wants to do. You can have a résumé and a list of achievements a mile long, but nothing lets a team know how skillful and dedicated (and humble) you are like jumping in and actually doing some hard work.
This is also important for maintaining context on where your engineers are coming from when you interact with them.
Just as important is the need to talk about what your culture should not include.
Arguably more important
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. It’s naïve to think of individuals as purely good or bad; it’s more constructive and practical to identify and reprimand the intolerable behaviors.
Attention and focus are the scarcest resources you have. The bigger the team, the more capacity the team has to focus on building things and solving interesting problems — but it’s always a finite amount. If you don’t actively protect these things, it’s easy for poisonous people to disrupt your team’s flow. Your team ends up bickering, distracted, and emotionally drained. Everyone ends up spending all their attention and focus on things other than creating a great product.
The person doesn’t use her real name. Instead, you’ll see only childish nicknames like “SuperCamel,” “jubjub89,” or “SirHacksalot.” To make things worse, often the person will have different nicknames in different media — one name for email, a different one for instant messaging, and perhaps a different one for code submissions.
The fact that I can’t get the same handle everywhere makes me potentially poisonous? This feels prejudicial
Either way, your job isn’t to cultivate condescension and lock out the less enlightened peasants from your project; rather, your job is to be intolerant of destructive behaviors and to be explicit about your expectations of HRT. It takes wisdom to understand the difference and real skill to carry it out.
It boils down to this: is your manager serving you? Or are you serving your manager? It should always be the former.
We advise that you steer clear of the office politician: route around him where possible, but don’t carelessly badmouth him to other people above him in the organization, because it’s quite difficult to know who he has hoodwinked and who is wise to him. If you’re the kind of person who is happy to keep your head down and focus on building interesting technology, you may want to rethink this strategy when there’s an office politician around. If you don’t put energy into getting promoted because you don’t want to “play the game,” you may find that the office politician gets promoted over you, in
...more
Lastly, your company might lack important things like focus, vision, or direction. This is often the result of too many masters, or “design by committee,” which results in conflicting orders being sent down to the rank and file. So you wind up moving in ever-tighter circles instead of in a coherent direction.
If you focus on the way things should be in your organization, you’ll usually find nothing but frustration and disappointment. Instead, acknowledge the way things are, and focus on navigating your organization’s structure to find the mechanisms you can use to get things done and to carve out a happy place for yourself in your company.
Offensive work is typically effort toward new user-visible features — shiny things that are easy to show outsiders and get them excited about, or things that noticeably advance the appeal of a product (e.g., improved UI, faster response times). Defensive work is effort aimed at the long-term health of a product (e.g., code refactoring, feature rewrites, schema changes, data migration, or improved emergency monitoring). Defensive activities make the product more maintainable, stable, and reliable. And yet, despite the fact that they’re absolutely critical, you get no political credit for doing
...more
A good Three Bullets and a Call to Action email contains (at most) three bullet points detailing the issue at hand, and one — and only one — call to action. That’s it, nothing more — you need to write an email that can be easily forwarded along. If you ramble or put four completely different things in the email, you can be certain that they’ll pick only one thing to respond to, and it will be the item that you care least about. Or worse, the mental overhead is high enough that your mail will get dropped entirely.
community members about this attitude and deal more productively with analysts. Passive-aggressively fighting the system — no matter how irritating it is — just doesn’t make sense. It’s no different from telling the restaurant reviewer to get back at the end of the line. Should the reviewer get preferential treatment? Probably not. But is it worth sticking it to him as a matter of principle? Definitely not. You’re only hurting yourself in the process. Choose your battles carefully.
If users click on a particular ad, it must be useful to them;
I don’t agree with this assumption
