Staff Engineer가 일자리를 발명하는 방법
A Staff Engineer's Guide to Inventing Work
Platform 팀은 제품 주도가 아닌 엔지니어링 주도로 움직이기 때문에, 로드맵이나 제품 관리자가 없어 일은 엔지니어가 직접 발명해야 한다. Staff Engineer는 시스템, 사용자, 조직, 산업에서 오는 신호를 읽어 다음에 무엇을 만들지 결정한다. 이 글은 11가지 신호를 소개하고, 각 신호가 얼마나 논리를 제공하는지, 선행/후행 지표인지에 따라 순위를 매긴다. 가장 큰 위험은 빈 백로그가 아니라, 가장 시끄러운 신호만 모아 만든 백로그다.
엔지니어링 주도 platform 팀의 실패 모드는 빈 백로그가 아니다. 가장 시끄러운 신호, 보통은 crash, 때로는 skip-level에서 모은 백로그다. 일을 발명하는 것은 신호를 찾는 것보다, 왜 이 신호이지 다른 열 가지가 아닌지 설명할 수 있는 능력에 가깝다.
HN 토론
32- dabedee
> Platform 팀은 제품 주도가 아니라 엔지니어링 주도로 움직인다. 로드맵을 건네주는 프로덕트 매니저가 거의 없고, 따라야 할 매출 라인도 없고, 잃을 시장도 없다.
바로 이런 프레이밍과 사고방식 때문에 플랫폼 팀은 실제로 사람들을 잘 지원하지 못하고, 대개는 일을 만들어내는 사람들로 구성된 매우 역기능적인 탑이 된다.
시장이 없다는 문제의 해결책은, 당신이 지원하는 팀들이 떠날 수도 있다고 생각하는 것이다. 이 글 전체가 신호들을 나열하는데, 그중 그런 신호는 하나도 없다. 갇혀 있다는 것이 사용자나 내부 팀에게 다른 선택지가 없고 그것을 눈치채지 못한다는 뜻은 아니다. 제품 주도라는 것은 사용자를 신경 쓰는 것이다. 플랫폼 팀은 바로 그 좁은 의미에서 엔지니어링 주도가 아니라 제품 주도여야 한다. 그렇지 않으면 이 글이 멋지게 폭로하듯이 일을 만들어내게 된다.
- fsloth
"엔지니어가 발명하지 않으면 그 일은 존재하지 않는다."
이건 정말 이상하다. 내 생각에 회사가 엔지니어를 고용하는 유일한 목적은 비즈니스를 지원하는 것이다. 스태프 엔지니어는 비즈니스 측면에서 무엇이 흥미로운지 알려주는 프로젝트 매니저가 필요하지 않아야 한다. 목표가 대부분 기술적일 가능성이 크더라도 말이다.
이게 항상 들어맞지는 않는다는 걸 안다. 하지만 내게는 자신의 작업에 대해 비즈니스 지표로 어떤 근거도 제시할 수 없다면, 학술적 연습에 참여하고 있는 것이다.
- juancn
나는 "다음에 우리를 죽일 것은 무엇인가" 철학을 쓴다.
그게 무엇인지 알아내고, 그것을 피하기 위해 뭔가를 한다.
빨고, 헹구고, 반복한다.
- nmehner
"일을 발명한다" = "요구사항 공학"
내 생각에 "일을 발명한다"는 표현을 쓰는 건 이상하다.
- stephbook
글 내용은 사실이면서도 이상하게 프레이밍되어 있다.
작가는 "제품 고객"이 멍청한 프로그래머 자동인형이 코드로 번역하기만 하면 되는 깔끔한 요구사항 목록을 건네준다고 생각하는 걸까? 당연히 아니다. 고객도 자신이 무엇을 원하는지, 혹은 원할 수 있는지 모른다. 유명하게도, 그들은 더 빠른 말을 원한다고 주장한다.
그런 다음 작가는 "크래시 주도 발견"을 나열하는데, 마치 프로덕션에서 버그 우선순위를 정하는 것과 그렇게 다른 것처럼 말한다. 아니면, 아무 생각이 없으면 그냥 효율성을 개선하는 것. 아니면 고객과, 아니 사용자와 대화하는 것.
이 모든 것은 사실이고, 이 모든 것은 다른 소프트웨어와 다를 바 없이 다른 용어로 번역된 것뿐이다.