$30 off During Our Annual Pro Sale. View Details »

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

maltzj
April 24, 2018

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

maltzj

April 24, 2018
Tweet

More Decks by maltzj

Other Decks in Programming

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