book

Debugging Teams

by Brian W. Fitzpatrick, Ben Collins-Sussman

October 2015

Intermediate to advanced

190 pages

4h 54m

English

O'Reilly Media, Inc.

Read now

Unlock full access

From FitzFrom BenAbout the Authors
Who Is This Book For?Warning: This Is Not a Technical ManualThe Contents of This Book Are Not Taught in SchoolThe Pitch
Help Me Hide My CodeThe Genius MythHiding Is Considered HarmfulIt’s All About the TeamThe Three PillarsHRT in PracticeLose the EgoLearn to Both Deal Out and Handle CriticismFail Fast and IterateLeave Time for LearningLearn PatienceBe Open to InfluenceNext Steps
What Is Culture?Why Should You Care?Culture and PeopleCommunication Patterns of Successful CulturesHigh-Level SynchronizationThe Mission Statement—No, ReallyEfficient MeetingsWorking in a “Geographically Challenged” TeamDesign DocsDay-to-Day DiscussionsMailing ListsOnline ChatUsing an Issue TrackerCommunication as Part of EngineeringCode CommentsPutting Your Name on Your WorkRequire Code Reviews for Every CommitHave Real Test and Release ProcessesIt Really Is About Your Product, After All
Nature Abhors a VacuumManager Is a Four-Letter Word“Leader” Is the New “Manager”The Only Thing to Fear Is…Well, EverythingThe Servant LeaderAntipatternsAntipattern: Hire PushoversAntipattern: Ignore Low PerformersAntipattern: Ignore Human IssuesAntipattern: Be Everyone’s FriendAntipattern: Compromise the Hiring BarAntipattern: Treat Your Team Like ChildrenLeadership PatternsLose the EgoBe a Zen MasterBe a CatalystFailure Is an OptionBe a Teacher and a MentorSet Clear GoalsBe HonestTrack HappinessOther Tips and TricksPeople Are Like PlantsIntrinsic Versus Extrinsic MotivationFinal Thoughts
Defining “Poisonous”Fortifying Your TeamIdentifying the ThreatLack of Respect for Other People’s TimeEgoEntitlementImmature or Confusing CommunicationParanoiaPerfectionismRepelling the PoisonRedirect the Energy of PerfectionistsDon’t Feed the Energy CreatureDon’t Get Overly EmotionalLook for Facts in the BileRepel Trolls with NicenessKnow When to Give UpFocus on the Long TermA Final Thought
The Good, the Bad, and the StrategiesHow Things Ought to BeThe Ideal Employee ExperienceHow Things Usually AreThe Bad ManagerThe Office PoliticianThe Bad OrganizationManipulating Your Organization“It’s Easier to Ask for Forgiveness Than Permission”6If You Can’t Take the Path, Make the PathLearn to Manage UpwardLuck and the Favor EconomyYour Political Bank AccountGet Promoted to a Position of SafetySeek Powerful FriendsHow to Ask a Busy Executive for Anything…via EmailPlan B: Get OutAll Is Not Lost
Managing Public PerceptionPay Attention to First ImpressionsUnderpromise and OverdeliverWork with Industry Analysts RespectfullyHow Usable Is Your Software?Choose Your AudienceConsider Barrier to EntryMeasure Usage, Not UsersDesign MattersPut the User FirstSpeed MattersDon’t Try To Be All ThingsHide ComplexityManaging Your Relationship with UsersRespect Users’ IntelligenceBe PatientCreate Trust and DelightRemember the Users

A Final Thought

Content preview from Debugging Teams

Chapter 6. Users Are People, Too

We’ve explored a long list of ingredients that are critical to successful product development.

Start with a small group of smart, creative people. Fertilize the team with a strong culture of humility, trust, and respect. Lead them as a servant, empowering them to collaborate and make good decisions. Give them water, sunlight, direction, and intrinsic motivation as needed. Protect them from negative influences—destructive behaviors (or environments) that threaten the culture and the ability to make progress. Bake at 72°F for six months, and you’ve got some great software. All done, right?

A lot of programmers stop there. They write software for themselves, are pleased with the end result, and then declare victory.

Unfortunately, that’s not how the real world works. “Good software” is an overly narrow definition of success. If you’re trying to pay the bills (or simply boost your résumé) you also need a lot of other people to use your software and be happy with it. The software development process doesn’t end with throwing a product over a wall; it never ends, in fact. People use your product and you need to react to them, improving it over time. If you don’t learn how to master this feedback loop your creation will die.

We’ll examine three general phases of user engagement in this chapter. First you need to get users to notice your work—are they even aware that it exists? How do they perceive it before they walk in the door? Then you’ll need to think ...