Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How DevRel should proceed with the breaking cha...

How DevRel should proceed with the breaking change project?

The presentation file given on March 11th, 2023 at DevRelCon Yokohama 2023

Takeshi Nick Osanai

March 11, 2023
Tweet

More Decks by Takeshi Nick Osanai

Other Decks in Technology

Transcript

  1. Takeshi Nick Osanai ver1.0 How DevRel should proceed with the

    Breaking Change Project? March 11th, 2023 Takeshi “Nick” Osanai
  2. Self Introduction Takeshi “Nick” Osanai Recent Career • Division Director

    at Global Commons inc (3 years) • Product Manager, DevRel, Sales Engineer of Movable Type (original blogging software) at Six Apart KK (8.5years) • DevRel, Developer Success at Freee K.K (Japanese Unicorn, 3.5years) • CRE (Customer Reliablity Engnieer) at FLUX inc (current)
  3. My Life Mission Connecting technology and people Product Manager DevRel,

    Advocate Sales Engineer Customer Reliability Engineer
  4. Scenario • You are a DevRel of a SaaS company

    • Breaking changes will be adopted to the API Your Mission • Communicate with developers and get them to modify a huge number of systems and applications.
  5. What is Breaking Change? • A major specification change that

    does not involve backward compatibility. • Breaking Change often causes external systems and applications to stop working, requiring third parties to modify their systems.
  6. My Case December 2020, endpoints of REST API have been

    largely changed Needed to contact to thousands of thousands 3rd parties and ask them to respond https://developer.freee.co.jp/release-note/2948
  7. Strategy Flow Confirm Changes Estimate the impact Estimate the schedule

    Create the Communication Plan Coordinate with the stakeholders Start to Communicate
  8. Confirm and understand what the changes • Have a conversation

    with the engineering team to sort out what the changes will be, how many changes will occur, and what types of changes they are. • You can't start a project without understanding what the changes are. • As the Developer Relation person, make sure you understand and sort out the changes.
  9. Estimate the impact Mining facts from log data via SQL

    • number of apps and systems • number of API call • number of unique user id
  10. Estimate the schedule My case: over a year to proceed

    the project Before 1 year (Nov-Dec 2019) Before 6months (May 2020) Before 5months (June 2020) Before 3 months (Jul-Aug 2020) Before 1month (Nov-Dec 2020) Month of Execution (Jan 2021) * Confirmed changes *Created the Schedule *Created the Communication plan * Published the release notes * Started to provide the new version of API *Communicated to external developers and stakeholders * Confirmed log data * Switched to the new version of API * Discontinue releasing the old version
  11. Create the Communication Plan External Communication Internal Communication one by

    one communication via developer’s site via Twitter send email to developers Sync internal stakeholders Sync over orgnaization investigate log data communicate developers privately Release notes News FAQ send private email discuss one by one communicate via sales team communicate via success team communicate via support team ready to track metrics with analytics team discuss with sales team about how to communicate
  12. • Even if you publish documentation of breaking changes, you

    cannot be sure that the developer will notice. • If no effort is made to communicate, important information may not be delivered.
  13. Coordinate with the stakeholders • Once you create the schedule

    and the communication plan, it is time to coordinate with stakeholders both inside and outside.. • We have to continue to communicate based on our passion and beliefs as a Developer Relation person.
  14. Important points • Communicate widely and get involved. • The

    important thing is to "deliver the information to the developers who need it. • We asked every internal stakeholders within the company to help us contact all third parties and developers.
  15. Results 2020-05 2020-06 2020-07 2020-08 2020-09 2020-10 2020-11 2020-12 28th

    May Published News June Coordinate with internal members July, August Communicated via internal members to external developers and third parties December Final communication one by one before switching to specification
  16. What have I learned? • "The perfect communication" is not

    possible. • "Publishing release notes and blogs" is not enough to reach all developers. • We have to think, think, think, and execute, execute “How can I deliver information effectively to developers” • “Working with the teams” is essential.
  17. Wrap up Confirm Changes Estimate the impact Estimate the schedule

    Create the Communication Plan Coordinate with the stakeholders Start to Communicate
  18. Thank you very much! Takeshi “Nick” Osanai LinkedIn: https://bit.ly/3Kkwnan Twitter:

    http://bit.ly/3kb6ZcH Today’s Slide http://bit.ly/3JtF5lV