How DevRel should proceed with the breaking change project?

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

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?
6. 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.
7. What will you do?
8. 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
9. Strategy Flow Confirm Changes Estimate the impact Estimate the schedule Create the Communication Plan Coordinate with the stakeholders Start to Communicate
10. Confirm Changes • Confirm changes through the conversation with the engineers • Sort out the changes
11. 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.
12. Estimate the impact Mining facts from log data via SQL • number of apps and systems • number of API call • number of unique user id
13. 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
14. 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
15. • 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.
16. Coordinate with the stakeholders communication, communication, and communication
17. 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.
18. 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.
19. 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
20. Success！
21. 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.
22. Wrap up Confirm Changes Estimate the impact Estimate the schedule Create the Communication Plan Coordinate with the stakeholders Start to Communicate
23. Thank you very much! Takeshi “Nick” Osanai LinkedIn: https://bit.ly/3Kkwnan Twitter: http://bit.ly/3kb6ZcH Today’s Slide http://bit.ly/3JtF5lV