Braze 제품팀 구조조정

모든 소프트웨어 제품의 이면에 있는 가장 중요한 원동력은 해당 제품을 구축하는 사람들의 그룹과 서로 간의 관계입니다. 따라서 가능한 한 많은 영향력과 영향력을 가질 수 있도록 팀을 구성하는 것이 중요합니다.

Braze에서 우리는 제품 및 엔지니어링 조직이 어떻게 설계되었는지에 대해 광범위하게 생각했으며, 기능의 우선 순위를 지정하고, 팀 전문성을 개발하고, 제품을 보다 효율적으로 구축하는 방법을 크게 개선하는 데 도움이 된 주요 부서 개편에서 얻은 교훈을 공유하고자 합니다.

초기 구조: 제품/시장 적합성 및 그 이상

제품/시장 적합성을 찾고 이를 활용하여 비즈니스를 성장시키는 것은 모든 스타트업이 통과해야 하는 도가니입니다. 스타트업 개발의 ​​이 단계 전반에 걸쳐 실험 속도와 기회를 신속하게 활용하는 능력이 중요합니다. 이를 위해 원래 제품 팀 구조는 다음과 같았습니다.

기능적 전문성을 기반으로 팀을 분할한 이 구조는 여러 가지 이유로 잘 작동했습니다.

첫째, 제품/시장에 맞게 변형되는 제품 변경 사항을 효율적으로 처리할 수 있었습니다. 전문가들은 방대한 양의 우리 코드베이스를 소유하고 가장 편한 언어, 프레임워크 및 디자인 결정을 사용할 수 있었습니다. 엄청난 양의 카페인에 힘입어 1군 프로젝트 "팀"은 정기적으로 엄청난 노력을 기울였습니다. 여기에는 고객 대면 공용 API를 구축하고 전체 메시지 전송 인프라를 점검하는 작업이 포함되어 종종 단독 엔지니어, 제품 관리자 및 디자이너의 역할을 수행합니다. 이러한 유형의 극단적인 조치는 대기업에서는 미친 짓이지만 초기 성장 기간에는 필요하고 거의 일상적입니다.

또한 이 구조는 10-15명으로 구성된 팀으로 특정 기술 영역을 깊이 숙달하는 데 도움이 되었습니다. 핵심 제품의 많은 요소(예: 프런트 엔드의 모델 보기 컨트롤러 계층, API 및 처리량이 많은 메시지 전송 코드)는 소수의 개인만 완전히 이해했습니다.

그 당시에는 간단하고 우리에게 필요한 전부였습니다. 속도가 전부일 때 간단한 지침을 기반으로 구성하면 인지 오버헤드를 줄이는 데 도움이 되었고 가장 잘 할 수 있는 곳에 주의를 집중할 수 있었습니다.

후기 구조: 성장 및 확장

그러나 우리 팀이 30~40대를 넘어서면서 이러한 구조가 무너지기 시작했습니다. 우리는 궁극적으로 우리의 가장 큰 과제 중 일부에 대한 해결책으로 제품 팀의 재구성을 확인했습니다. 우리는 전략적 프로젝트를 위한 팀을 구성하기 위해 기술 세트와 타임라인을 저글링하는 지속 불가능한 노력을 소비하고 있었습니다. 또한 우선 순위 지정에 지나치게 많은 시간을 할애했으며 기술 기반 팀 구조가 가장 필수적인 제품 요구 사항에 직접 매핑되지 않았기 때문에 비즈니스 전반에 걸쳐 모든 제품 우선 순위를 강제로 지정하는 경우가 많았습니다. 마지막으로 팀 구성원이 특정 고객 사용 사례에 대한 깊은 경험을 개발할 기회가 거의 없었습니다.

우리는 궁극적으로 Spotify에서 대중화된 Squad/Tribe 모델과 유사한 Agile 다기능 팀으로 구성된 조직으로 전환했습니다. 새 조직 구조는 다음과 같습니다.

우리 팀의 대부분은 우리 제품 또는 비즈니스의 핵심 영역에 해당하는 "제품 카테고리" 내에서 일합니다. 예를 들어:

• 당사의 이메일 및 엔터프라이즈 팀은 이메일을 위에서 아래로 실행하며, 다수의 대규모 고객에게 중요한 권한 관리와 같은 특정 제품 영역을 운영합니다.
• 메시징 및 자동화 팀은 사용자 세분화, 메시징 및 당사의 주력 오케스트레이션 제품인 Canvas와 관련된 여러 제품 영역을 소유하고 있습니다.

업종 내에서는 각 업종이 특정 고객 요구 사항에 해당하므로 우선 순위 지정이 (상대적으로) 간단할 것으로 기대합니다. Visual Design, DevOps 및 인프라 엔지니어링 그룹과 같은 특정 팀은 전체 플랫폼을 포괄하여 주요 영역에서 일관성을 구축합니다.

영향

우리의 재구성은 팀 간 의존성을 크게 줄였습니다. 이전에는 특정 기술(엔지니어링, 디자인, 제품 관리 등)의 적절한 균형을 주어진 프로젝트에 할당해야 하는 스도쿠와 같은 일정 문제로 어려움을 겪었습니다. 또한 단기 인센티브도 조정했습니다. 전환 전에 팀은 종종 관련 없는 목표를 목표로 하는 상대방에게 의존하게 되었습니다. 우리의 새로운 구조를 통해 제품 팀은 독립적이고 일정을 훨씬 더 잘 제어할 수 있으며 목표에 완벽하게 맞춰져 생산성과 사기를 높일 수 있습니다.

새로운 조직 디자인은 우선 순위 지정도 개선했습니다. 예를 들어, 이메일 및 엔터프라이즈 팀은 이메일 인프라 업그레이드, 핵심 이메일 기능 구축 또는 엔터프라이즈 사용성 문제 수정 중 하나를 결정해야 할 수 있습니다. 이 세 가지 모두 유사한 방식으로 고객의 요구와 관련되기 때문에 간단하고 쉽게 수량화할 수 있는 결정입니다. .

너무 많은 우선 순위 요구 사항으로 어려움을 겪고 있는 팀은 해당 제품 영역에 더 많은 리소스가 필요하다는 지표이기도 합니다. 이를 통해 우리는 어려운 우선순위 지정 문제를 인력 수요로 재구성할 수 있습니다. 이 문제는 여전히 도전적이지만 개념적으로는 해결하기 쉽습니다.

마지막으로, 특정 제품 영역에 대부분의 팀을 집중함으로써 개인은 시간이 지남에 따라 깊은 전문 지식과 매우 생산적인 업무 관계를 구축할 수 있습니다. 처음에는 구축 초기 몇 년 동안 개인은 기본적으로 전체 제품과 코드베이스를 머릿속에 담을 수 있었지만 성장하면서 이것이 불가능해졌습니다. 제품 문제는 프랙탈입니다. 자세히 볼 때마다 더 많은 뉘앙스와 깊이를 찾습니다. 결과적으로 제품 또는 코드베이스의 특정 영역에서 많은 시간을 보내고 비즈니스 요구 사항을 깊이 이해하는 것이 실제 제품 혁신을 달성하는 가장 좋은 방법 중 하나입니다. 또한 집중적인 장기 팀을 만들면 소유권과 관계가 형성되고 일관된 공동 작업자 집합 간의 무언의 작업 관계가 형성됩니다.

물론 완벽한 시스템은 없습니다. 제품 중심의 기둥에 초점을 맞춰 팀이 전체적인 우선 순위를 희생하면서 지역화된 요구 사항에 맞게 최적화할 수 있는 가능성을 높였습니다. 예를 들어, 글로벌 문제("프론트 엔드 프레임워크를 변경하면 전반적인 엔지니어링 속도가 증가함") 대신 지역화된 기술 부채("이 컨트롤러는 번거로움")에 집중할 수 있습니다. 이러한 필요성을 예상하여 우리는 위에서 언급한 크로스커팅 팀을 구성하기 위한 조치를 취했으며 다른 광범위한 프로젝트에 전용 위원회를 사용했습니다. .

우리의 새로운 구조는 또한 총체적이고 혁신적인 제품 변경을 위해 더 높은 활성화 에너지를 제공합니다. 백엔드 API와 같은 제품의 일부 영역은 여러 팀이 공동으로 소유하고 있습니다. 우리 코드베이스의 광범위한 교차 영역을 전면적으로 변경하기 위한 임계값이 더 높기 때문에 이러한 유형의 구조는 제품의 골격이 크게 형성되면 가장 잘 작동합니다.

테이크아웃

전반적으로 재설계된 제품 조직 구조에 만족합니다. 팀 종속성, 우선 순위 지정 및 장기적인 제품 전문 지식 구축과 관련된 문제를 해결하거나 크게 개선했으며 확장 방법에 대한 유용한 로드맵도 가지고 있습니다. 특히 다음을 배웠습니다.

• 종속성을 제거하고 인센티브를 조정하면 효율성이 크게 향상됩니다.
• 사과 대 사과 우선 순위 지정은 더 간단하고 효과적입니다.
• 특정 고객 또는 비즈니스 요구에 대한 깊은 전문 지식은 더 나은 제품 결과로 이어집니다.
• 오랜 기간 동안 같은 팀원들과 함께 일하는 것은 훌륭한 업무 관계를 구축하는 데 매우 중요합니다.

특정 핵심 특성을 공유하는 모든 팀에 이 구조를 권장합니다. 제품 관리자, 디자이너 및 엔지니어와 같은 기능 전문가가 동등한 이해 관계자인 다기능 조직. 결합된 제품 개발 팀에 약 15-20명 이상의 사람들이 있습니다. 그리고 가장 중요한 것은 확고한 제품 시장 적합성입니다. 이러한 유형의 팀 구조가 귀하에게 매력적으로 들린다면 고용하고 있습니다!