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

Transcript

1. Jonathan Maltz
   [email protected]/@maltzj
   Want to Make a Change?
   Stop Talking and Start Listening
   

   View Slide

2. Yelp’s Mission
   Connecting people with great
   local businesses.
   

   View Slide

3. View Slide

4. View Slide

5. View Slide

6. View Slide

7. Empathy
   +
   Trust
   

   View Slide

8. Empathy
   

   View Slide

9. Em·pa·thy - the ability
   to share and understand
   the feelings of another.
   

   View Slide

10. In·cen·tive - a thing that
    motivates or encourages
    one to do something.
    

    View Slide

11. Individual
    vs.
    Group
    

    View Slide

12. View Slide

13. Engineers
    

    View Slide

14. Engineers
    Designers
    

    View Slide

15. Engineers
    Product
    Managers
    Designers
    

    View Slide

16. Engineers
    Product
    Managers
    Pick the right
    features to build
    Designers
    

    View Slide

17. Engineers
    Product
    Managers
    Pick the right
    features to build
    Designers
    Make those
    features beautiful
    and easy to use
    

    View Slide

18. Engineers
    Write maintainable
    code
    Designers
    Make those
    features beautiful
    and easy to use
    Product
    Managers
    Pick the right
    features to build
    

    View Slide

19. Engineers
    Product
    Managers
    Designers
    Beautiful
    project that
    never makes
    money
    

    View Slide

20. Engineers
    Product
    Managers
    Designers Unmaintainable
    pile of technical
    debt
    

    View Slide

21. Engineers
    Product
    Managers
    Designers
    Unusable
    solution to a real
    problem
    

    View Slide

22. Engineers
    Product
    Managers
    Designers
    Where the magic
    happens
    

    View Slide

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.
    

    View Slide

24. View Slide

25. Show how your
    change matters in
    their language
    

    View Slide

26. View Slide

27. OMG drowning in
    technical debt
    

    View Slide

28. I should talk to our
    product manager
    about paying this
    down in our sprint.
    

    View Slide

29. ● Incentive for engineer
    ○ Code is easier to work with. More testable and
    extendable
    What are the incentives?
    

    View Slide

30. We should pay
    down tech debt in
    our next sprint. It
    will make our code
    easier to work with.
    

    View Slide

31. That doesn’t
    sound like
    delivering
    customer
    value...
    

    View Slide

32. I don’t think we
    have time for
    that
    

    View Slide

33. View Slide

34. ● Incentive for engineer
    ○ Code is easier to work with. More testable and
    extendable
    What are the incentives?
    

    View Slide

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?
    

    View Slide

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?
    

    View Slide

37. Can’t do this?
    Re-evaluate your
    solution
    

    View Slide

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?
    

    View Slide

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
    

    View Slide

40. I can pay short
    term cost to get
    long-term benefits
    

    View Slide

41. Sure! Let’s see if we
    can get that
    scoped!
    

    View Slide

42. View Slide

43. Be Curious
    

    View Slide

44. View Slide

45. Takeaway #2: Learn about
    what other stakeholders value
    in order to align what you
    want with what they want.
    

    View Slide

46. Trust
    

    View Slide

47. You really should
    change the way you’re
    rendering views. It’s
    causing performance
    problems.
    

    View Slide

48. Who is this guy
    telling me how to
    do my job?
    

    View Slide

49. You really should
    change the way you’re
    rendering views. It’s
    causing performance
    problems.
    

    View Slide

50. Romain knows a thing
    or two about
    performance. I should
    listen to him
    

    View Slide

51. Takeaway #3: No matter how
    right you are, you will only get
    to execute on your ideas if
    people trust you.
    

    View Slide

52. How to Build
    Trust?
    

    View Slide

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?
    

    View Slide

54. 1. Start With Small
    Changes
    

    View Slide

55. ● Changes with engineers
    ○ Try out changes in tests
    ○ Write a small, throwaway feature
    Start Small
    

    View Slide

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
    

    View Slide

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
    

    View Slide

58. Let’s Try It
    

    View Slide

59. 2. Provide
    Touchpoints
    

    View Slide

60. touch·point - a point of
    contact between a buyer
    and seller.
    

    View Slide

61. ● Touchpoints for Engineers
    ○ Code reviews
    ○ Design documents
    Provide touchpoints
    

    View Slide

62. ● Touchpoints for Engineers
    ○ Code reviews
    ○ Design documents
    ● Touchpoints for Product Managers
    ○ Tickets/Progress Visualizations
    Provide touchpoints
    

    View Slide

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
    

    View Slide

64. 3. Have a Plan
    

    View Slide

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
    

    View Slide

66. Example!
    

    View Slide

67. Rewrite our app in Kotlin
    

    View Slide

68. ● Incentives? Faster iteration speeds, more features,
    better Yelp
    Rewrite our app in Kotlin
    

    View Slide

69. ● Incentives? Faster iteration speeds, more features,
    better Yelp
    ● Milestone 1: Write + build a single file in Kotlin
    Rewrite our app in Kotlin
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

75. 4. Help Others
    Accomplish Their
    Goals
    

    View Slide

76. Don’t Always
    Get Your Way
    

    View Slide

77. Don’t Always
    Get Your
    Way
    

    View Slide

78. Don’t Always
    Get Your
    Way
    

    View Slide

79. Case Study
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

83. 1. Build Trust
    

    View Slide

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
    

    View Slide

85. 2. Understand
    Incentives
    

    View Slide

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
    

    View Slide

87. 3. Educate
    (as necessary)
    

    View Slide

88. 4. Suggest a small
    change
    

    View Slide

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}”
    

    View Slide

90. 5. Execute
    Effectively +
    Measure
    

    View Slide

91. ● How many times were people breaking master
    previously? What about now?
    ● Call this out in your team retrospectives
    Execute and Measure
    

    View Slide

92. 6. Make a Larger
    Plan
    

    View Slide

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”
    

    View Slide

94. 7. Gather
    Feedback
    

    View Slide

95. I’m worried
    that we won’t
    have enough
    time to do
    that
    

    View Slide

96. Hmm, maybe we should
    just setup Espresso and
    write high value tests
    

    View Slide

97. 8. Finalize Plan +
    Execute
    

    View Slide

98. View Slide

99. View Slide

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
     

     View Slide

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
     

     View Slide

102. www.yelp.com/careers/
     We're Hiring!
     

     View Slide

103. Questions
     

     View Slide

104. @YelpEngineering
     fb.com/YelpEngineers
     engineeringblog.yelp.com
     github.com/yelp
     

     View Slide