베스트 프랙티스, 좋은 테크니컬 문서 등의 리소스를 찾는 써드파티 개발자쪽에서나 솔직한 시장의 피드백을 원하는 회사 내부 개발팀 양쪽 모두에게 Developer Relations는 중요합니다. 경쟁

베스트 프랙티스, 좋은 테크니컬 문서 등의 리소스를 찾는 써드파티 개발자쪽에서나 솔직한 시장의 피드백을 원하는 회사 내부 개발팀 양쪽 모두에게 Developer Relations는 중요합니다. 경쟁력있는 DevRel팀이 되기 위해서는, 1. DevRel팀 그들 또한 실력있는 개발자이어야 합니다. 개발자들 사이에서 영향력이 있기 위해서는 동료로서 존중받을 수 있어야 합니다. 그들이 만든 라이브러리, 콘텐츠 등이 수많은 개발자들에게 공유될 것이므로 그들의 엔지니어링 실력은 중요합니다. 2. 개발자들의 관심을 이끌어내고 의미있는 피드백을 이끌어 내기 위해서 커뮤니케이션에 능해야 합니다. 3. 포용적인 조직이어야 합니다. 포용적인 DevRel팀일수록 더 넓은 개발자의 공감을 이끌어내고 포용할 수 있다는 것을 의미하기 때문입니다. 4. 세일즈 하시면 안됩니다. 어떻게 우리가 개발자들을 도울 수 있을까? 라는 질문을 가지는 것이 핵심이고 만약 개발자들이 관심을 가지지 않는다면 그 이유가 무엇인지에 집중합니다. 5. 개발자들처럼 느끼고 생각해야합니다. DevRel팀은 모든 개발자 플랫폼이나 API의 0번째 고객이어야 합니다. 6. 듣고, 듣고 듣고 그리고 대답해야합니다. 7. 활발한 다량의 활동을 해야합니다. 8. 스케일업할 수 있는 전략이 중요합니다. 상대로 하는 개발자 커뮤니티는 훨씬 크기 때문에 늘 파급력이 있는 방법으로 접근해야 합니다. 추가의견) 모두 좋은 의견이나 그 중 1번은 동의하기 어려운데, 저자는 DevRel을 개발자를 위한 직접적인 콘텐츠를 만드는 에반젤리스트의 관점에서만 쓰셨지만 DevRel에서는 그런 에반젤리스트나 Advocate들이 사내 밖의 커뮤니티에서 여러가지 활동을 하기 위한 커뮤니케이션과 전략을 보다 더 큰 그림에서 고민하는 PM과 같은 조직도 있기에, DevRel이 꼭 개발자여야 한다는 말은 개인적으로는 동의하긴 어렵습니다. 경쟁력있는 팀에는 둘 다가 필요하죠. 저를 포함, Techie가 아니어도 DevRel로 활동하는 분들은 아주 많습니다. :)