Want to Make a Change? Stop Talking and Start Listening (Android Makers 2018)

Here are the slides for my presentation on creating change, trust, and empathy, at Android Makers 2018

Resources Links:
Having Productive Discussions When I Disagree: https://twitter.com/b0rk/status/980938694118002688
Life is Great And Everything Will Be Okay, Kotlin is Here: https://youtu.be/fPzxfeDJDzY?t=19m40s
The Lean Startup: https://www.amazon.com/Lean-Startup-Entrepreneurs-Continuous-Innovation/dp/0307887898/ref=sr_1_3?ie=UTF8&qid=1523837751&sr=8-3&keywords=the+lean+startup
Kanban: Successful Evolutionary Change for Your Software Business: https://www.amazon.com/Kanban-Successful-Evolutionary-Technology-Business/dp/0984521402/ref=sr_1_1?s=books&ie=UTF8&qid=1523837772&sr=1-1&keywords=Kanban+evolutionary+change
Agile Development in Scrum https://www.amazon.com/Agile-Software-Development-Scrum/dp/0130676349/ref=sr_1_4?s=books&ie=UTF8&qid=1523837801&sr=1-4&keywords=Agile+development+in+scrum
Don't Make Me Think: https://www.amazon.com/Dont-Make-Think-Revisited-Usability/dp/0321965515/ref=sr_1_1?s=books&ie=UTF8&qid=1523837830&sr=1-1&keywords=don%27t+make+me+think
A Designers Guide to Android: http://tech.dramafever.com/
Fundamentals of Design: How To Think Like a Designer:
https://www.skillshare.com/classes/Fundamentals-of-Design-How-to-Think-Like-a-Designer/1986357063/classroom/discussions
Learning to Speak Designer: https://www.youtube.com/watch?v=80hrknwD74Q

Transcript

1. Jonathan Maltz maltz@yelp.com/@maltzj Want to Make a Change? Stop Talking and Start Listening
2. Yelp’s Mission Connecting people with great local businesses.
7. Empathy + Trust
8. Empathy
9. Em·pa·thy - the ability to share and understand the feelings of another.
10. In·cen·tive - a thing that motivates or encourages one to do something.
11. Individual vs. Group
13. Engineers
14. Engineers Designers
15. Engineers Product Managers Designers
16. Engineers Product Managers Pick the right features to build Designers
17. Engineers Product Managers Pick the right features to build Designers Make those features beautiful and easy to use
18. Engineers Write maintainable code Designers Make those features beautiful and easy to use Product Managers Pick the right features to build
19. Engineers Product Managers Designers Beautiful project that never makes money
20. Engineers Product Managers Designers Unmaintainable pile of technical debt
21. Engineers Product Managers Designers Unusable solution to a real problem
22. Engineers Product Managers Designers Where the magic happens
23. Takeaway #1: Other disciplines are not martians out to get you. They’re people solving hard problems in a different way than you are.
25. Show how your change matters in their language
27. OMG drowning in technical debt
28. I should talk to our product manager about paying this down in our sprint.
29. • Incentive for engineer ◦ Code is easier to work with. More testable and extendable What are the incentives?
30. We should pay down tech debt in our next sprint. It will make our code easier to work with.
31. That doesn’t sound like delivering customer value...
32. I don’t think we have time for that
34. • Incentive for engineer ◦ Code is easier to work with. More testable and extendable What are the incentives?
35. • Incentive for engineer ◦ Code is easier to work with. More testable and extendable • Incentive for product manager ◦ Bug free features as fast as possible What are the incentives?
36. • Incentive for engineer ◦ Code is easier to work with. More testable and extendable • Incentive for product manager ◦ Bug free features as fast as possible • Incentive for everyone ◦ Build the best possible version of Yelp What are the incentives?
37. Can’t do this? Re-evaluate your solution
38. • Incentive for engineer ◦ Code is easier to work with. More testable and extendable • Incentive for product manager ◦ Bug free features as fast as possible • Incentive for everyone ◦ Build the best possible version of Yelp What are the incentives?
39. We should take time to pay down technical debt in our next sprint. We have a bunch of work on some challenging code coming up, and taking time to refactor first will make that work quicker
40. I can pay short term cost to get long-term benefits
41. Sure! Let’s see if we can get that scoped!
43. Be Curious
45. Takeaway #2: Learn about what other stakeholders value in order to align what you want with what they want.
46. Trust
47. You really should change the way you’re rendering views. It’s causing performance problems.
48. Who is this guy telling me how to do my job?
49. You really should change the way you’re rendering views. It’s causing performance problems.
50. Romain knows a thing or two about performance. I should listen to him
51. Takeaway #3: No matter how right you are, you will only get to execute on your ideas if people trust you.
52. How to Build Trust?
53. • You have a proven track record of being correct • You show that you’ll consider other people’s perspective even without their input • You are willing to admit when you’re wrong Why would people trust you?
54. 1. Start With Small Changes
55. • Changes with engineers ◦ Try out changes in tests ◦ Write a small, throwaway feature Start Small
56. • Changes with engineers ◦ Try out changes in tests ◦ Write a small, throwaway feature • Changes with product managers ◦ Do only a few days of work ◦ Timebox Start Small
57. • Changes with engineers ◦ Try out changes in tests ◦ Write a small, throwaway feature • Changes with product managers ◦ Do only a few days of work ◦ Timebox • Changes with designers ◦ Build a prototype ◦ User test Start Small
58. Let’s Try It
59. 2. Provide Touchpoints
60. touch·point - a point of contact between a buyer and seller.
61. • Touchpoints for Engineers ◦ Code reviews ◦ Design documents Provide touchpoints
62. • Touchpoints for Engineers ◦ Code reviews ◦ Design documents • Touchpoints for Product Managers ◦ Tickets/Progress Visualizations Provide touchpoints
63. • Touchpoints for Engineers ◦ Code reviews ◦ Design documents • Touchpoints for Product Managers ◦ Tickets/Progress Visualizations • Touchpoints for Designers ◦ Over-the-shoulder design reviews ◦ Sending screenshots before shipping Provide touchpoints
64. 3. Have a Plan
65. • Turn your long-term goal into milestones ◦ Gives more touchpoints ◦ Closer milestones should be well-defined ◦ Further milestones can be fuzzier • Have checks at each milestone to make sure you’re accomplishing your goals Have a plan
66. Example!
67. Rewrite our app in Kotlin
68. • Incentives? Faster iteration speeds, more features, better Yelp Rewrite our app in Kotlin
69. • Incentives? Faster iteration speeds, more features, better Yelp • Milestone 1: Write + build a single file in Kotlin Rewrite our app in Kotlin
70. • Incentives? Faster iteration speeds, more features, better Yelp • Milestone 1: Write + build a single file in Kotlin • Milestone 2: One engineer writes their tests in Kotlin Rewrite our app in Kotlin
71. • Incentives? Faster iteration speeds, more features, better Yelp • Milestone 1: Write + build a single file in Kotlin • Milestone 2: One engineer writes their tests in Kotlin • Milestone 3: All engineers write their tests in Kotlin Rewrite our app in Kotlin
72. • Incentives? Faster iteration speeds, more features, better Yelp • Milestone 1: Write + build a single file in Kotlin • Milestone 2: One engineer writes their tests in Kotlin • Milestone 3: All engineers write their tests in Kotlin • Milestone 4: Write all new code in Kotlin Rewrite our app in Kotlin
73. • Incentives? Faster iteration speeds, more features, better Yelp • Milestone 1: Write + build a single file in Kotlin • Milestone 2: One engineer writes their tests in Kotlin • Milestone 3: All engineers write their tests in Kotlin • Milestone 4: Write all new code in Kotlin • Milestone 5: Whenever we touch an old file, migrate it to Kotlin Rewrite our app in Kotlin
74. • Incentives? Faster iteration speeds, more features, better Yelp • Milestone 1: Write + build a single file in Kotlin • Milestone 2: One engineer writes their tests in Kotlin • Milestone 3: All engineers write their tests in Kotlin • Milestone 4: Write all new code in Kotlin • Milestone 5: Whenever we touch an old file, migrate it to Kotlin • Milestone 6: Migrate all of our legacy code to Kotlin Rewrite our app in Kotlin
75. 4. Help Others Accomplish Their Goals
76. Don’t Always Get Your Way
77. Don’t Always Get Your Way
78. Don’t Always Get Your Way
79. Case Study
80. You’ve just joined a new team and you’ve noticed that they’re struggling to ship effectively. There’s no tests and no CI, so the build occasionally breaks and features need to be frequently patched
81. • Continuous Integration to prevent people from breaking builds • Automated testing to ensure that old features don’t break • Rearchitecting the app to introduce new patterns which make it more unit-testable What you think should happen
82. • Incentive for everyone ◦ Build the best possible version of your app • Incentive for engineers ◦ Less time spent fixing builds and bugs, more time writing cool new features • Incentive for product managers ◦ More features built because each one is more reliable Incentives
83. 1. Build Trust
84. • With Engineers ◦ Write excellent code ◦ Do great code reviews ◦ Be a resource of Android knowledge • With Product Managers ◦ Deliver timely and effective tickets Building Trust
85. 2. Understand Incentives
86. • Why is there no CI in place? ◦ Are people unfamiliar with CI? ◦ Do people know about it but haven’t had time? ◦ Is it too expensive? • Why are there no tests? ◦ Is there a knowledge gap? Understand
87. 3. Educate (as necessary)
88. 4. Suggest a small change
89. “Hey team, I think we should invest some time in implementing a CI Server. It will help us prevent these issues where master hasn’t compiled. It’ll take about 1 week if we setup ${service here}”
90. 5. Execute Effectively + Measure
91. • How many times were people breaking master previously? What about now? • Call this out in your team retrospectives Execute and Measure
92. 6. Make a Larger Plan
93. “Hey Team. I think we should start writing tests. It would help us prevent all these errors in production. It’ll take a few months, but we can first setup espresso, then write tests for high value flows, and then test everything”
94. 7. Gather Feedback
95. I’m worried that we won’t have enough time to do that
96. Hmm, maybe we should just setup Espresso and write high value tests
97. 8. Finalize Plan + Execute
100. • People in other disciplines are solving hard problems with different incentive structures • Learn what’s important to your other teammates, especially cross-functional ones • No matter how good your ideas are, you need to build trust that you can execute them Three Big Takeaways
101. • How To Productively Disagree • Life’s Great and Everything Will Be Ok, Kotlin is here • The Lean Startup • Kanban: Successful Evolutionary Change for Your Software Business • Agile Software Development In Scrum • Don’t Make Me Think • A Designer’s Guide to Android • Fundamentals of Design: How to Think Like a Designer • Learning To Speak Designer External Links
102. www.yelp.com/careers/ We're Hiring!
103. Questions
104. @YelpEngineering fb.com/YelpEngineers engineeringblog.yelp.com github.com/yelp