스태프 엔지니어가 문제를 찾는 방법: 흡수하고, 쌓고, 공통점을 찾아라
How I find problems to solve as a staff engineer
스태프 엔지니어로 승진하려는 멘티의 질문에 답하며, 저자는 빈 페이지 앞에서 '전략적으로 생각'하는 대신 일상의 소음에서 문제를 흡수하는 방법을 공유한다. 문제를 바로 해결하지 않고 쌓아두면 서로 다른 팀에서 같은 문제가 반복되거나 표면적으로 다른 문제가 같은 본질을 가진 경우를 발견할 수 있다. Perfetto의 매크로와 확장 서버 사례를 통해 공통된 형태를 찾는 과정과, 아이디어를 검증하고 압력을 테스트하는 방법을 설명한다. 이 과정은 신뢰를 쌓아 더 넓은 영향력을 발휘하게 해준다.
문제를 찾는 것은 직업의 나머지 부분과 분리된 것이 아닙니다. 그것은 어떤 단일 요청도 보여줄 수 없는 것을 보기 위해 사람들의 작업에 충분히 오랫동안 관여하는 데서 비롯됩니다.
HN 토론
161- stevepotter
나는 젊은이들에게 작은 회사를 찾으라고 조언한다. 이상적으로는 제품/시장 적합성을 겪고 있는 회사, 즉 최근에 팔 무언가를 만들어서 팔기 시작한 회사를 말이다. 자원이 제한적이고, 성장은 좋지만 폭발적이지 않은 그런 회사. 이런 회사는 많다. 이런 환경에서는 적은 것으로 더 많은 것을 해내는 법, 진짜 문제를 식별하는 법, 빠르게 전달하는 법, 고객과 직접 일하는 법, 좋은 제품을 만드는 법을 빠르게 배우게 된다. 그 후에 큰 회사에서 일하고 싶다면 가서 일해보라. 얼마나 잘 해내는지 놀랄 것이다.
- wpasc
저자는 다음과 같이 언급한다:
> 한 가지 주의할 점: 제 경험은 주로 대기업에서 인프라와 개발자 도구를 작업하고, 엔지니어들이 로드맵에 영향을 미칠 수 있는 하향식 자율성을 많이 가진 팀에서 얻은 것입니다. 더 하향식 환경에서는 이런 방식으로 일할 여지가 단순히 적을 수 있습니다.
기술 업계의 전반적인 추세가 엔지니어들이 하향식 자율성을 덜 경험하고 더 하향식 통제 환경을 경험하는 것인지 궁금하다. 얼마나 많은 기술 회사(또는 평균적인 엔지니어의 경험)가 엔지니어가 자율성을 가진 기술 주도에서 제품 관리 주도로 바뀌었는지 보고 싶다. 증거는 없지만, 기술 문화가 (내 생각에) 기술 중심에서 비즈니스, 관리, 제품 중심으로 옮겨가면서 엔지니어는 단지 비즈니스, 관리, 제품의 목표를 달성하는 임무를 맡은 부품에 불과하게 되면서 전반적인 엔지니어링 자율성은 해가 갈수록 감소했다고 의심한다.
모두 가설일 뿐, 일화적 데이터만 있을 뿐이다.
- 9dev
사람들이 그런 문제를 겪는다니 재밌네요. 저는 경력의 대부분을 스타트업 분야에서 보냈는데, 제 경험상 해결해야 할 문제의 양은 제가 깨어 있는 시간에 합리적으로 달성할 수 있는 것보다 훨씬 많았습니다.
그래서 저는 해결할 문제를 찾지 않고, 어떤 문제가 가장 시급한지, 또는 어떤 해결책이 여러 문제를 동시에 해결하는지 평가하려고 합니다. 모든 팀과 고객을 만족시키고 생산적으로 유지하기 위해 그런 우선순위를 제대로 정하는 법을 배우는 것이 제 경력에서 매우 자랑스러운 부분입니다.
- CSMastermind
이 모든 것은 아주 좋은 조언이지만, 에세이 시작 부분에서 그 질문을 하는 사람이라면 아마 스태프 엔지니어가 되면 안 된다고 경고하고 싶습니다. 그 직함이 차별화된 책임이 없는 단순한 승진 사다리의 한 단계인 회사(그런 회사가 많이 있습니다)가 아니라면 말입니다.
제가 함께 일했던 스태프+ 엔지니어로 성공한 모든 사람들은 승진이 보통 형식적인 절차에 불과했습니다. 이미 분명히 그 일을 하고 있었기 때문입니다. 제가 '무능력의 수준까지 승진'하는 사람들을 본 경우는 모두 직함/급여 인상을 위해 노력하고 '게임을 하려고' 했습니다.
사람들의 문제를 해결하려는 동기가 승진을 위한 것이라면, 문제 해결을 좋아해서가 아니라면, 그 직업은 아마 당신에게 맞지 않을 것입니다.
- rr808
우리 회사의 가장 고위 스태프 엔지니어/아키텍트들이 실제로 유용한 일을 했으면 좋겠어요. 그들은 현재 플랫폼이나 우리가 나아가는 방향과 전혀 상관없는 새로운 기술을 가지고 노는 것을 좋아합니다. 때로는 지난 아키텍트가 시작한 일을 고치려고 하다가 그들도 다른 직업으로 옮겨가기도 합니다.
- ronnier
나는 기술 산업의 거의 모든 것이 비대해졌고 대규모 해고가 대부분의 회사에 큰 타격을 주지 않을 것이라고 생각합니다(사람들의 삶에 해롭기 때문에 하는 것은 잔인해 보이지만). 팀당 인원이 적을수록 컨텍스트 스위칭이 줄어들고 개발자가 더 많이 소유하게 됩니다. 그들은 일자리를 찾을 필요가 없습니다. 일이 눈앞에 있을 테니까요. 제가 일했던 대형 기술 회사들 중 많은 곳에서 할 일이 충분하지 않은 사람들을 너무 많이 봤습니다. 그들은 결국 회의와 같은 낭비적인 일(문서 작성)을 만들어 시간을 보냅니다. 관리자와 디렉터는 크고 비대한 팀을 원하는 것 같습니다. 인원수가 많을수록 더 많은 것을 요구하고 승진을 추진할 수 있으니까요.
- intoXbox
시니어-스태프의 경계에서 제가 어려움을 느끼는 부분은 깊은 기술 지식을 갖추면 요청과 같은 단기적인 문제를 빠르고 효과적으로 해결할 수 있다는 것입니다.
저자는 다른 팀의 불만을 이해하는 데 시간을 투자해야 한다고 말하지만, 그것은 많은 시간이 걸리고 저는 말만 하고 코드를 푸시하거나 기능을 출시하지 않는 사람이 되고 싶지 않습니다. 다른 사람들이 그런 경험을 어떻게 했는지 듣고 싶습니다.
- napo
저는 스태프 레벨에서 한동안 일했습니다. 핵심은 매니저들을 관리하는 디렉터에게 보고하는 것이라고 생각합니다. 그렇게 할 때마다 저는 좋은 시간을 보냈고, 프로젝트를 정의하기 쉬웠고 사람들을 설득하기 쉬웠습니다. 다른 IC를 관리하는 몇몇 매니저들과 같은 레벨이었을 때는 결코 잘 풀리지 않았습니다. 다른 IC들은 작업에 대해 경쟁하려 하고, 사람들은 당신에게 자신의 필요를 말하지 않으며, 다른 프로젝트에 대해 너무 늦게 알게 되고, 다른 팀들은 영역을 지키려고 해서 당신이 개입하는 것을 원하지 않습니다.