아마존에서 14가지 리더십 원칙모든 작업은 기본적으로 수행됩니다.

AWS 뉴스 블로그당신은 팀 리더입니다 제프 바 아마존 리더십 원칙에 기반 AWS 뉴스 블로그 작성 원칙당신이 공유 2020년 AWS 뉴스 블로그 팀의 일원으로서 내부적으로 공유하면서 블로그 글을 작성하고 이를 유념하고 있습니다.

이 기사에서는 번역 외에도 AWS 뉴스 블로그를 작성하면서 개인적으로 느낀 점을 괄호 안에 넣었습니다.

AWS 뉴스 블로그를 시작한 Jeff Barr(부사장 겸 AWS 수석 에반젤리스트) 소개

고객 집착 – 두 가지 유형의 고객이 있습니다.

무엇보다도 귀하는 귀하의 기사를 읽고 있는 AWS 고객이며 제한된 시간과 관심을 가지고 있음을 기억하십시오. 두 번째는 우리와 함께 일하고 고객의 요구 사항을 충족하는 제품을 만들기 위해 열심히 노력한 AWS 제품 팀입니다.

블로거로서 독자들이 제품 팀의 노고에 감사하게 해야 합니다.

(대부분의 경우 블로그 글을 올린 후 고객님께서 좋은 글을 써주셔서 감사하고 해보고 싶다며 담당자와의 연결을 요청하는 경우가 많습니다.

이때 고객의 의견을 전달하고 연락을 취하는 것이 가장 제품 팀 책임자에게 정보를 제공하는 것도 그중 하나입니다.

)

재산 – AWS 서비스 소개 블로그 하단에 이름이 기재됩니다.

당신이 하는 일에 자부심을 가져라. (다른 회사 블로그를 보면 제품 개발을 직접 담당하는 대부분의 사람들이 출시 블로그 게시물을 작성합니다.

대신 뉴스 블로그 팀의 모든 블로거는 제품 팀에서 제품을 사용해 보고 독자의 입장에서 경험하는 임무를 받았습니다.

관점 프로덕트 팀이 직접 작성해야 하는 것에서 한 단계 더 나아가는 것은 지루할 수 있지만 제3자 검토 프로세스를 통해 더 높은 품질과 더 완전한 기능을 구축할 수 있다고 생각합니다.

최종 기사 작성자단일 릴리스를 완료하려면 몇 개월에 걸쳐 수십 개의 검토가 필요합니다.

)

AWS 뉴스 블로그의 작성자 블로그 게시물 목록

발명과 단순화 – 블로그 게시물을 작성하거나 제품을 설명하는 정해진 방법은 없습니다.

창의력을 발휘하고 자신에게 맞는 스타일과 목소리를 찾으십시오. 풍부한 어휘를 사용하되 과시하기 위해 모호한 단어를 사용하지 마십시오. (Jeff는 각 사람이 자신의 이야기를 하도록 격려합니다.

제 경험 법칙은 독자가 새로운 기능을 읽은 후 5분 이내에 완전히 이해하도록 하는 것이므로 서론은 가능한 한 짧게 유지하고 기능의 본문은 ‘시작 Function’ 부분에서 스크린샷이나 예제 코드를 짧지만 풍부하게 제시하고 마지막에 주의할 사항이 있을 때 장황하게 표현하는 편이다.

많이 맞다 – 제품 기능을 설명하기 어렵거나 콘솔 화면이 혼란스럽거나 잘못된 텍스트가 포함된 경우 제품 팀에 올바른 피드백을 제공하십시오. 새로운 기능을 가장 먼저 확인하는 고객이 될 것입니다.

혼란스럽다면 다른 AWS 고객도 마찬가지일 것입니다.

(사실 알파/베타 기능을 처음 사용하다보면 콘솔 화면의 흐름이 이상하거나 기능에 버그가 있는 경우가 많습니다.

개발팀 슬랙 채널이나 이슈 트래커에도 제보를 합니다.

그 과정에서 지난번 블로그 글 작성시 일부 수정될 예정입니다.

)

배움과 호기심 – 처음에는 다양한 기술 주제가 생소합니다.

그러나 새로운 것을 배우고 “구루”가 될 수 있는 기회입니다.

주제가 이해하기 어려운 경우 텍스트에서 사람으로 인정하는 것을 환영합니다.

아무도 모든 것을 알지 못합니다.

누구나 새롭고 복잡한 것을 배우기 위해 최선을 다하는 사람처럼 생각할 것입니다.

(AWS 서비스가 많기 때문에 뉴스 블로그 팀 내에서 전문 지식을 공유합니다.

저는 주로 컨테이너, DB/분석, 보안/네트워크 및 사물 인터넷 서비스 출시를 다룹니다.

하지만 그렇다고 제가 그렇지 않다는 의미는 아닙니다.

다른 서비스에 전혀 관여하지 않습니다.

호기심과 학습을 충족시키기 위해 가끔 다른 도메인 릴리스에 대한 글을 씁니다.

)

최고 수준을 고집합니다.

– 제품이 출시 준비가 되지 않았다고 생각되면 팀에 의견을 알려주세요. 릴리스 기능이 여전히 불완전하거나 사용하기에 너무 어려운 경우 팀에 미리 알려주세요. (제품 출시는 미뤄야 합니다.

) 새로운 기능이 좋은 첫인상을 줄 수 있는 기회는 한 번뿐입니다.

(일부 새로운 기능은 아직 제대로 준비되지 않았습니다.

제품팀의 사정에 따라 출시 일정이 빡빡한 경우도 있습니다.

이때 물론 출시가 지연될 것입니다.

직접적으로 표현하지 마세요. (저만 그렇게 생각하는 게 아니죠. 출시가 몇 달, 심지어 1년 늦어지는 경우도 있습니다.

)

크게 생각하라 – 새로운 기능이나 서비스의 장기적인 영향에 대해 많이 생각하십시오. 독자들이 이러한 서비스가 미래에 어디로 갈지 숙고할 수 있도록 힌트를 남겨주세요. (이것도 가장 어려운 부분입니다.

새로운 AWS 기능은 고객의 요구에 따라 생성되며, 고객이 이를 어떻게 사용할지 또는 어떤 새로운 요구가 발생할지 예측하기 어렵습니다.

미래에 고객이 원하는 것을 스스로 실현할 수 있도록 기존 기사에 대한 링크를 통해 과거에 출시된 기능에 대한 컨텍스트를 소개합니다.

)

Reinvent 2022 출시를 위한 Slack 채널

행동 지향 – 초기에 제품팀과 자주 소통하고 필요한 문서나 자료를 얻습니다.

PRFAQ 문서, 함수 API, 콘솔 베타 화면 및 기술 문서를 빠르게 사용할 수 있습니다.

(신기능 출시 약 3개월 전에 블로그 글 작성 요청을 받습니다.

글 작성에 필요한 정보를 받고 직접 테스트한 후 출시 약 한 달 전에 초안을 전달합니다.

초안을 최소 10개 정도 다듬으면서 시간 Slack 채널을 통해 빠르게 공유해야 할 사항이 있지만 Product Manager, Product Marketing Manager, Development Team Manager, Lead Developers 및 Legal 또는 PR 직원과 같이 관련된 사람들이 너무 많기 때문에 중요한 결정이 어렵습니다.

.발급권에 꼭 남겨주세요 피드백 주고받는건 블로거가 앞장서야 합니다.

)

검소함 – 자신과 독자의 시간을 절약하십시오. 제품 팀에서 릴리스된 기능 및 제한 사항에 대한 명확한 목록을 받아 시간을 절약하세요. 독자의 시간을 절약하고 독자가 짧은 시간 안에 기능을 즉시 이해할 수 있도록 기사를 짧게 유지하십시오. (어쨌든 제품팀은 새로운 기능에 대해 최대한 많은 설명을 포함하고 싶어합니다.

하지만 독자들이 짧은 시간에 기사를 읽어서 너무 길게 쓸 수 없습니다.

이것을 조정하는 것이 상당히 어렵습니다.

기능을 설명할 때 자세한 내용은 기술 문서나 다른 블로그 게시물을 설명하거나 참조할 필요가 없도록 간략하게 설명하려고 합니다.

)

신뢰를 얻다 – AWS 내에서 이 주제에 대한 신뢰할 수 있는 권위자가 되십시오. 기사의 내용을 100% 정확하게 기술하도록 노력하고, 오류가 있는 경우 즉시 인정하고 수정합니다.

(동일한 지역의 출시 기사를 여러 번 다루다 보면 같은 제품 팀의 같은 사람들과 작업하는 경우가 많습니다.

다음에 또 뵙겠습니다.

기사 내용뿐 아니라 협업 주기도 중요하고 특히 시차가 있기 때문에 하루에 두 번, 늦은 저녁과 아침에 시애틀 근무 시간에 맞춰 피드백을 주려고 노력합니다.

내 피드백 주기는 항상 하루 늦습니다).

깊이 파고들다 – 주제에 대한 철저한 조사를 수행하고 도전적인 질문을 함으로써 제품 팀과 신뢰를 구축하십시오. (새로운 기능을 도입할 때 이러한 원칙을 최대한 간결하게 유지하기 어려운 경우가 많기 때문에 기능 이외의 일부 영역을 자세히 살펴봅니다.

일반적으로 고객이 서비스 기능에 대한 보안을 보장하는 방법과 다른 AWS에 새로운 기능을 도입할 수 있는 방법은 서비스와 연계하여 어떻게 사용할 수 있는지, 대체 AWS 기능은 무엇인지 등에 대해 많은 질문을 합니다.

가끔 답변을 요약하여 알아둘 사항에 게시합니다.

)

척추가 있다; 동의하지 않고 커밋(Grit, Object 또는 Accept 포함) – 제품팀의 의견이 조금이라도 부족하다고 느끼시면 블로그팀에 알려주세요. 기능 재설계를 포함하여 개선을 강력히 권장합니다.

그러나 제품 팀의 반응에 따라 전략적인 이유로 수정되지 않은 버전을 출시해야 하는 경우가 있음을 인정해야 합니다.

(프로덕트팀과 블로거 사이에 의견 불일치가 있을 때 Jeff와 마케팅팀이 제품 출시를 돕습니다.

VP급인 Jeff는 블로거의 의견을 최대한 존중하기 위해 의견을 조율하기 때문에 도움이 됩니다.

가끔 블로거들은 의견 대신 이 기능을 사용하는 클라이언트에 대한 약속과 같은 정당한 이유로 이것이 시행되는 경우가 있습니다.

Amazon Workdocs를 통해 제품 팀과 함께 초안 블로그 초안 피드백 프로세스의 예(AWS IoT 그린그래스 2.0)

최고를 고용하고 개발하십시오 – 블로깅 팀에 새 블로거를 추가할 때마다 기존 회원에게 고용 기준을 높이면서 성장할 여지를 제공하십시오. 새로운 회원이 배우고 성공하도록 돕습니다.

(뉴스블로그팀은 다양성을 존중합니다.

그래서 북미뿐만 아니라 유럽, 아시아, 아프리카 등 다양한 지역의 복음주의 블로거들이 블로거로 참여하고 있습니다.

다양성은 배움의 기회를 제공합니다.

편견없는 의견을 들어보세요 It 할 수 있어서 좋고, 어떤 사람들은 영어가 모국어가 아니기 때문에 저를 도와주는 영어 에디터들로부터 많은 것을 배웁니다.

)

결과 제공 – AWS 고객이 새로운 제안을 이해하고 즉시 사용할 수 있도록 훌륭한 블로그 게시물을 작성하십시오. (기사를 완성하는 것도 성과지만 얼마나 많은 사람들이 그것을 읽느냐도 중요합니다.

따라서 대부분의 경우 블로그의 KPI는 페이지 조회수나 방문자 수에 의해 결정됩니다.

그래서 우리는 단순히 방문자 수를 측정하지 않습니다.

, 그러나 그들이 기사를 읽은 후 어떤 행동을 취했는지 – 예를 들어 새 계정에 등록했는지, 콘솔에 로그인했는지 등 – 또는 소셜 미디어에 어떤 피드백을 남겼는지 등은 확실합니다.

확인 해봐 😉

AWS re:Invent 2022 출시 블로그 게시물에서 존경하는 Adrian Cockcroft(AWS 전 부사장)

지금까지 살펴본 바와 같이 Amazon의 리더십 원칙은 개별 업무에 자세히 적용됩니다.

일하는 회사가 다르고 지역이 다르더라도 일하는 기본 원칙으로 볼 수 있습니다.

흥미롭게도 일부 직원들이 개인 생활에도 적용하는 것을 보았습니다.

예를 들어, 자녀에게 “고객 집착”의 원칙을 알려주십시오. 귀하의 고객은 누구입니까? 고객이 엄마이자 교사라면 어떻게 해야 할까요? 그렇게 말했나요… 친구들 만나면 농담으로 “Bia For Action” 원칙에 따라 식당을 예약했다고 말합니다.

새해에는 자신의 업무에 맞는 리더십 원칙을 만들어보는 것은 어떨까요?

– 윤채니;

※ 부인 성명– 이 글은 개인적인 의견으로 제가 근무하거나 근무했던 회사의 공식적인 입장을 대변하거나 반영하지 않습니다.

팩트체크 및 개인적인 투자판단은 독자 개인의 책임이며 언론매체의 상업적 이용 및 인용도 금지됨을 양해 바랍니다.

(여기에 표현된 의견은 본인의 의견이며 현재 또는 이전 고용주의 의견을 반드시 대변하지는 않습니다.

귀하의 투자에 대한 사실 확인에 대한 판단에 대한 책임은 전적으로 귀하에게 있으며 귀하의 인용을 상업적 콘텐츠 또는 뉴스 출처로 금지합니다.

)