Data Science for Teams

CHAPTER 1 Lesson 1: Respect the basics, learn the roles 1.1 Organizational options1.2 Team roles, generic1.3 Team roles, actual1.3.1 Infrastructure engineer1.3.2 AI expert1.3.3 Software developer1.3.4 Team mentor-coordinator1.3.5 Other roles and specialties1.4 Our brave little teamCHAPTER 2 Lesson 2: Team building -- people over things2.1 Building the team2.2 Complexities and trade-offs2.3 Getting people onboard2.3.1 Setting the criteria2.3.2 Misconceptions2.3.3 Red flags2.3.4 How to do it right2.4 Letting people go2.5 DeparturesCHAPTER 3 Lesson 3: Keep the team happy, then committed3.1 Leading versus Managing3.1.1 Data Science as Engineering3.1.2 Data Science is not classic Project Management3.1.3 Key priorities and the human factor3.2 Incentives and Commitment3.2.1 Excellence and job satisfaction3.2.2 Handling younger members3.3 Team roles, revisited3.3.1 In-depth guidelines3.3.2 Transitions and integrations3.3.3 The kick-off3.3.4 The daily emergencies3.3.5 Addressing personal issues3.4 The dress code issueCHAPTER 4 Lesson 4: Give room to new ideas, but always have contingenciesin place4.1 The Software Engineering paradigm4.1.1 Key differences and similarities with DS4.1.2 Dealing with problems and failures4.2 Exploiting new ideas4.2.1 Diversity and collaboration4.2.2 Gender diversity in the team4.2.3 Diversity and Game Theory4.3 Contingencies4.3.1 Groupthink4.3.2 Backups as a team principle4.4 The big whiteboardPART 2 Bend the rulesCHAPTER 5 Lesson 5: In the real world, there are no well-defined tasks 5.1 Unknown unknowns5.1.1 Recognizing the proble5.1.2 Analysis paralysis5.2 Use cases5.2.1 Civil Aviation5.2.2 Agricultural quality control5.3 The first shockCHAPTER 6 Lesson 6: In the real world, data are raw and not ready for use6.1 Handling real-world data6.1.1 Factors and issues6.1.2 Exploring the data6.2 Use cases6.2.1 Civil Aviation6.2.2 Vehicle mobility analytics6.2.3 SARS-CoV-2 pandemic6.3 The second shockCHAPTER 7 Lesson 7: Keep things simple, but not too simple 7.1 The automatic control paradigm7.1.1 Principles of automatic control7.1.2 Automation versus human factor7.2 Project management and leadership7.2.1 Toxic leadership7.2.2 Project management, the NASA way7.2.3 The Westrum model7.3 Simplicity as a principle7.3.1 Dealing with complexity7.4 Use case: Adaptive X-ray machineCHAPTER 8 Lesson 8: Embrace good ideas, even if they are risky 8.1 Assignments and initiatives8.1.1 Who gives the presentations?8.1.2 Remote control8.1.3 Blame games8.2 Endorsing openness8.2.1 The curse of micro-management8.2.2 Inclusive teamwork8.3 Use cases8.3.1 Mammographic mass shape analysis8.3.2 Textiles modeling8.4 Cold feetCHAPTER 9 Lesson 9: Avoid the "one tool for all'' mindset9.1 Getting into the weeds9.1.1 Traditional versus ``blind'' ML9.1.2 Smart clouds and edges9.1.3 "Not invented here'' syndrome9.2 Tunnel vision9.2.1 The "Einstellung''9.3 Focus on the most valuable9.4 Use cases9.4.1 fMRI unmixing9.4.2 COVID-19 data analysisCHAPTER 10 Lesson 10: Avoid the "minimum effort principle'' 10.1 Minimum efforts10.1.1 Low productivity mode10.1.2 Knowledge silos10.1.3 Simplicity is not laziness: The "XOR'' example10.2 Marginally adequate10.2.1 Quiet quitting10.2.2 Learning versus delivering10.2.3 Motivation alone is not enough10.3 Opening upPART 3 Forget the rulesCHAPTER 11 Lesson 11: Always have backups -- prepare for the unexpected11.1 Hints from software risks11.2 Managing risk11.2.1 Assessment, prioritization, mitigation11.2.2 Preventive planning11.2.3 A little Game Theory11.3 Team risks11.3.1 Burnout11.3.2 Over-confidence11.3.3 Insecurities11.4 Use case: Urban ETA predictionCHAPTER 12 Lesson 12: Embrace critical feedback, always12.1 The feedback loop12.1.1 Reception of criticism12.1.2 Dealing with arrogance12.2 Conflict resolution in the team12.2.1 Pack leaders and threshold guardians12.2.2 Removing the barriers12.2.3 Emergence of cooperation12.3 Use case: Refugee influx analysis12.