임파워드 - 평범한 사람들이 만드는 특별한 제품

대다수 기업은 IT 기술에 대해 여전히 구시대적 마인드셋(사고방식)을 갖고 있다. IT 기술을 비즈니스의 핵심적인 원동력으로 보지 않고 단순한 필요 비용으로 여긴다. IT팀원을 비즈니스를 위해 일하는 사람으로, IT 부서의 관리자와 리더를 단순히 비즈니스를 지원하는 인력으로 여긴다. IT팀은 실제 고객과 단절되어 있으며, 회사에서는 제품을 직접 사용하는 사람이 아닌, 회사 내의 이해관계자들을 고객으로 여기도록 독려되는 것이 현실이다.

(그래서 직접 경험해보니 “내부 고객"이란 말이 정말 싫어졌다. 거의 혐오할 정도)

“리더십은 모든 사람의 내면에 위대함이 있음을 알아봐 주는 것이고, 리더의 임무는 그 위대함을 펼칠 수 있는 환경을 만들어 주는 것이다.”

(요즘에 읽는 책들은 어디서나 빌 켐벨의 이야기가 나온다. 어떤 사람이었을지 정말 궁금해진다)

경쟁력 있는 제품 기업의 IT팀은 단순한 비용이 아니라 비즈니스 그 자체다. IT 기술은 고객에게 제공하는 제품과 서비스를 가능하게 하고 강화한다. IT 기술을 통해 최신 기술을 반영하여 고객의 문제를 해결해 줄 수 있다…따라서 경쟁력 있는 제품 기업의 제품팀의 목적은 고객을 만족시키는 동시에 비즈니스에도 적합한 제품을 만드는 것이다.

기능 개발팀은 크로스펑셔널하고, 풀어야 할 문제를 전달받기보다는 구현할 기능과 프로젝트를 통보받기 때문에 산출물을 내는 것이 중요하며, 사업의 성과는 중요하지 않다.

임파워드 제품팀도 기능 개발팀처럼 크로스펑셔널하지만 기능 개발팀과는 대조적으로 구현할 기능이 아니라 풀어야 할 문제가 주어지고, 이에 대한 해결 방안을 스스로 생각하여 결과물을 구현할 수 있는 권한이 있으며, 이를 통해 성과가 측정되고 결과에 대한 책임을 진다.

(결국 업무의 주도권, 주도권이라는 말이 영역 다툼같이 느껴진다면, 주체라고 표현하면 맞을까? 이 부분이 어느 쪽에 있느냐의 문제로 보인다)

CIO가 원래 비즈니스 중심적인 자리였나? 최소한 여기서는 그렇게 설명하고 있긴 한데, 내게는 처음 보는 시각이다.

유명한 벤처 캐피털리스트인 존 도어John Doer는 기업에는 ‘용병mercenaries 팀이 아닌 미션 missionaries 팀이 필요하다고 설명한다…에반젤리즘은 끝이 없고 지속적으로 해야 하는 일이라는 사실을 리더가 이해하는 것은 아주 중요하다…팀원이 진심으로 조직가치를 믿고 있는지 항상 분명히 해야 한다.

(나 스스로부터 믿고 있는가? 여기부터 시작해야)

돈을 받고 고용된 용병팀이 아니라, 오너십을 가지고 열정적으로 스스로 일하는 미션팀이 필요하다는 것을 명심해야 한다.

중요한 것은 칭찬과 비판에 솔직해지는 것이다. 누군가가 특별히 잘하고 있다면 주저하지 말고 칭찬하라.마찬가지로, 개선이 필요한 부분에 대해서 사탕발림하지 마라. 항상 공개적으로 칭찬하되,비판은 개인적으로 해야 한다는 사실을 명심하라.

(이건 어디서나 쉽게 볼 수 있는 이야기. 이제는 나름대로 내 내면에도 익숙해져서 어떤 이야기를 할 때 어느 정도는 자동으로 공개적으로 할지 개인적으로 할지 구분할 수 있게 되었다)

신규 PM은 사용자의 제품 인식부터 맛보기/테스트trial를 거쳐 실제 사용자가 되는 단계에 이르기까지 전체 유입 경로를 이해해야 한다.

(CEO나 PO들에게 처음부터 business flow를 end to end로 파악해야 한다고 이야기해왔다. 물론 그런다고 완전히 파악되지는 않는다. 지속적으로 이야기하고 요구해서 정리해달라고 전달하고 있다)

훌륭한 제품 마케팅은 그 시장을 이해하는 것이 우선이다. 고객의 실제 현실에 적응(adapt)하고,자리(position)잡아, 팔려(market) 나갈 수 있도록 시장이 알려 주는 것에 따라 가설을 압박 검증(pressure-test)한다. 고객의 언어와 경험과 니즈(needs)를 활용하여 왜 당신의 제품이 가치 있고 사랑받아야 하는지 명확하게 한다.

성과 평가에서 놀랄 일은 없어야 한다… 핵심 도구는 매주 하는 1:1 미팅이다.

(그래서 각 조직 lead들에게는 이 부분, 1 on 1을 통해 지속적으로 잘 하고 있는 일과 개선이 필요한 일에 대해 이야기하도록 나와의 1 on 1에서 전달은 하고 있지만, 확인은 필요해 보인다)

프로덕트 매니저로서 오너처럼 생각한다는 것은 고객, 제품팀, 이해관계자 및 회사 투자자에 대한 진정한 의무와 책임을 느껴야 한다는 의미라고 들었다.

왜 그럴까? 프로덕트 매니저가 제품팀을 이끌고, 팀과 회사의 임원이 내 말과 행동으로 나를 판단하기 때문이다.

(PO들에게는 이런 면에서 매우 힘든 일이 될거라고 분명히 전달했었고, 지속적으로 이야기하고 있다. 담당하는 팀의 모든 communication을 알고 파악해야 하며, 우선순위를 파악하고 앞으로 해야 할 기능에 대해 계획도 마련하고, 이해관계자간의 조정도 해야 한다고)

https://media.corporate-ir.net/media_files/irol/97/97664/reports/Shareholderletter97.pdf

https://www.aboutamazon.com/news/company-news/2019-letter-to-shareholders

시간 관리가 항상 어렵지만, 항상 중요하다. 프로덕트 매니저를 관리하거나 코칭하는 업무를 한다면, 이것이 가장 중요한 코칭 주제가 될 것이다.

프로덕트 매니저도 문제를 해결해야 한다. 사용자 경험, 또는 확장 가능한 아키텍처의 결함 없는 fault-tolerant 솔루션을 설계하려는 것은 아니다. 그보다는 고객의 비즈니스, 업계, 특히 자신의 비즈니스와 관련된 제약을 해결한다. 이것은 고객이 필요로 하는 것인가? 다른 경쟁 제품보다 훨씬 나은가? 회사가 효과적으로 마케팅해서 판매할 수 있고, 만들어 낼 수 있으며, 서비스 및 지원이 가능하고, 법적 및 규제 관련 제약을 준수하는 것인가?

(architecture가 중요하지 않은 건 아니지만, 결국 가장 중요한 건 business)

게다가, 기술 기반 제품과 서비스가 가진 특수한 도전 과제는 제품, 디자인, 엔지니어링이라는 세 가지 유형의 제약 조건을 동시에 해결해야 한다는 것이다. 따라서 진정한 협력이 필요하다(이는 다음 장의 주제다).

기능 개발팀 모델이 있는 회사에서, 기능은 일반적으로 이해관계자로부터 나오기 때문에 이해관계자는 자신을 ‘클라이언트’로, 제품팀을 ‘고용된 IT 자원’으로 여긴다. 한편, 기능 개발팀의 목적이 사업을 지원하는 것이라고 말하기도 한다. 반면, 권한이 있는 제품팀의 목적은 고객이 좋아하면서도 비즈니스에 유효한 방식으로 고객에게 서비스를 제공하는 것이다.

상호 신뢰가 있다면 상호작용이 더 원활해진다. 어느 쪽이든 개인적 감정으로 받아들이지 않으면서도 일과 관련하여 반대 입장을 표하기가 쉬워진다. 누구나 아끼는 사람과 함께 일할 때 더 즐겁다는 것은 당연하지 않은가!

(그래서 신뢰 형성을 위해 서로간의 개인적인 이야기나 업무와 무관한 주제에 대해서 이야기하는 게 필요하긴 하다. 하지만 이것도 결국은 업무 관련된 신뢰를 형성하기엔 부족하다. 극단적으로 일 못하는 착한 사람과 일 잘하는 나쁜 놈 중에서 업무 현장에서 더 필요한 건 어느 쪽일까? 업무를 잘 하면서 형성되는 신뢰관계가 결국 중요한 부분이라고 생각한다)

일부 프로덕트 매니저가 경영진에게나 회의에서 그다지 감동 없는 프레젠테이션을 하는 것을 볼 때마다, 나는 그 발표자가 아니라 그 사람의 관리자에게 실망한다.

(나도 어느 정도는 반성해야겠다. PO들의 발표가 매번 뛰어날 수는 없어도 또 그냥 보기만 하면 안 되니)

책임은 실제로 무엇을 의미할까? … 권한이 있는 제품팀의 프로덕트 매니저의 책임은 실수에 대해 책임을 지려는 의지를 의미한다. 다른 사람에게 잘못이 있을 때에도, 위험을 더 잘 관리하거나 더 나은 결과를 얻기 위해 개인적으로 무엇을 할 수 있었는지 항상 묻는다.

팀, 특히 프로덕트 매니저는 한 단계 더 나아가서 팀이 반대한 의견이라도, 내려진 결정에는 따르겠다고 동의해야 한다.

(Disagree and commit)

물론 회의를 하는 데는 수만 가지 이유가 있겠지만, 실제 제품 조직에는 일반적으로 의사소통, 의사 결정 및 문제 해결의 세 가지 유형이 있다.

“자신이 일하는 곳이 자랑스럽지 않거나, 회사가 세상에 미치는 영향이 자랑스럽지 않거나, 리더십이 그 진정성을 신경 쓰지 않는다고 생각한다면, 다른 일자리를 찾아야 할 때다.”

(이직에 대해 결정이 어려울 때 딱 맞진 않겠지만 참고할만하다)

너무나도 모호한 개념인 ‘문화적 적합성’을 지니고 있는지

(그래서 cultural fit interview라는 걸 별로 좋아하지 않는다. 중요하지 않다는 건 아니지만, 평가하기 정말 어렵고 애매하다는 생각이다)

1. 실행력 — 당신은 일처리를 문제없이 진행하고, 시키지 않아도 올바른 일을 진행하며, 여러 목표를 관리합니까?
2. 창의성 — 당신은 얼마나 자주 팀에서 가장 좋거나 최고의 아이디어를 냅니까?
3. 전략 — 당신은 진행 중인 업무에 대해 더 넓은 시장 관점 혹은 비전 관점으로 바라보고 정의하여 동료와 공유합니까?
4. 성장성 — 당신은 스마트한 프로세스, 팀 관리 등을 통해 노력에 대한 결과를 증대시키는 데 얼마나 능숙합니까?

이 질문의 표면적인 가치는 채용 후보자가 평가한 스스로의 약점에 대해 어떻게 대화를 이어 나가는지 보는 것이다.

나는 제품 담당자가 스스로의 능력을 자각하고 성장할 수 있는 부분을 인정하는 역량을 매우 중요하게 생각한다(이 질문은 “당신의 약점에 대해 얘기해 주세요’의 덜 인위적이면서 조금 더 효과적인 버전이라고 볼 수 있다. 나는 이 대화를 피하려 들거나 달갑게 생각하지 않는 채용 후보자에 대해 회의적이다. 또한 스스로의 평가가 지금까지의 면접 내용에서 관찰한 부분과 상충하는 경우에도 회의적이다.

전반적인 발굴 프로세스에서, 특히 혁신의 성공은 심리적 안정감이라는 개념에 달려 있다.

https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/

채용 매니저는 연간 성과 평가가 절대로 주요 피드백 도구가 되어서는 안 된다는 사실을 꼭 이해해야 한다. 연간 성과 평가를 주요 피드백 도구로 사용하고 있다면, 당신은 매니저로서 완전히 실패했다고 본다.

(채용 매니저만이 아니라 모든 매니저가 그래야 한다고 생각한다)

우리의 일이 회사에 미치는 영향을 이해하는 한편, 모든 이익은 결국 고객에게 실제로 가치 있는 것을 제공하는 데에서 비롯된다는 사실을 잊지 말아야 한다.

비전에 대한 수요를 검증할 수는 있다…

우리가 검증할 수 없는 것은 솔루션이다…

이것이 제품 비전이 대체로 믿음의 도약leap of faith(경험적 증거가 없는 것을 믿는 것)이라고 말하는 이유다. 우리가 발굴할 솔루션이 비전을 실현할 수 있다는 것을 스스로 확신해야 한다.

특히 팀이 아주 다양한 기술을 보유하고 있기 때문에(배우뿐 아니라 조명, 무대 장치, 의상 디자이너, 의상 제작자, 무대 감독 등등), 연출의 업무는 미래를 위한 공통된 목표와 비전을 만드는 일이다.

(연출만이 아니라 모든 리더, 특히 C level로 갈수록 이래야 한다)

대부분의 경우, 더 큰 범위의 오너십은 임파워먼트에 좋지만, 책임 범위가 팀의 규모와 기술에 비해 너무 넓다면 어려워질 수 있다…높은 수준의 인지 부하cognitive load는 팀의 임파워먼트에 불리하게 작용한다.

임파워먼트는 오너십의 범위에만 영향을 받는 것이 아니라, 오너십의 명확성도 요구된다. 팀이 어떤 업무를 맡고 있는지 불분명할 경우, 임파워먼트는 약화된다. 업무의 오너십이 모호해지는 경우가 종종 일어날 것으로 예상해야 하지만, 팀 구조가 좋다면 오너십 문제를 일으키기보다는 오히려 많은 문제가 해결된다.

(팀 구조가 좋다면 어떻게 해결이 되는 거지? 책을 읽어도 아직 이 부분은 좀 이해가 안 간다)

플랫폼팀은 서비스와 아키텍처의 기본적인 복잡성을 추상화함으로써 다른 팀의 권한부여 수준을 높여 준다. 하지만 반대로 플랫폼팀 자체의 임파워먼트에 관한 문제는 항상 까다롭다. 경험팀의 목적은 사용자와 고객의 문제를 해결하는 것이지만, 플랫폼팀의 목적은 사실상 경험팀이 고객의 문제를 더 잘 해결할 수 있도록 하는 것이기 때문이다. 그러므로 플랫폼 팀의 기여는 간접적이다.

(비즈니스에 간접적으로 관여하는 팀의 일을 관리하는 건 확실히 까다로운 부분이 있다는 걸 경험하고 있다. 특히 동기부여 측면에서 팀 구성할 때부터 어려웠다)

각각의 근접성에는 트레이드오프가 있다는 것은 분명하다. 전반적인 원칙으로는, 관리자, 고객 또는 기타 다른 것을 최적화하는 게 아니라, 제품팀을 위한 최적화를 위해노력한다.

빠르게 확장 중이거나 현재 어려움을 겪고 있는 조직을 면밀히 살펴보면, 좋은 의도와는 상관없이 실질적으로 집중하는 일이나 제품 전략이 없다. 한꺼번에 너무 많은 일을 하려고 들면, 최고의 엔지니어링팀이라고 한들 분명 어려움을 겪을 것이다.

많은 경우에 있어서, 내가 투입된 것이 회사가 추구하려는 방향을 다시 정립해야 하는 중요한 사건이 된다. 내가 직접 그들을 위해 선택할 수는 없지만, 리더에게 꼭 필요한 선택을 해야 한다고 주장할 수는 있다.

(딱 내가 겪는 상황이라 정말 마음에 와닿는다)

직원은 회사의 마음과 영혼이다. 그리고 신뢰는 직원이 효과적으로 함께 일하면서 혼자서 일할 때 상상했던 것보다 훨씬 더 많은 것을 만들어 내고 성취할 수 있게 해 준다. 신뢰는 성공한 기업의 핵심(마술)이다.

각 조직의 기능은 회사 전체에 고유한 전문 지식을 제공한다. 최고의 제품팀에서는 엔지니어링의 고유한 가치가 우수한 제품을 제공하는 기술과 함께 지속적으로 혁신된다. 어떤 이유로든, 엔지니어링 조직이 제품을 제공(릴리즈)할 수 없는 상태라고 인지될 때, 신뢰문제가 발생한다. 임원은 엔지니어링 조직을 신뢰하지 않고, 엔지니어는 임원을 신뢰하지 않는다. 신뢰 부족은 모든 면에서 나쁜 행동과 사기 문제를 일으키고, 대개 조직 전체의 기능이 하향 곡선을 그리게 된다.

따라서 건강하게, 지속적으로 신뢰하는 것은 조직에서 필수적이다. 신뢰를 재정립하고 유지하려면 조직의 모든 구성원, 즉 최상위 임원뿐만 아니라 엔지니어도 포함해서, 집중해야 할 초점과 전략 설정을 포함하여 어려운 작업이 많이 필요하다. 이 부분은 다음 주제로 이어진다.

놀랍게도, 내가 본 대부분의 제품 조직은 제품 전략이 없다. 개발해야 하는 기능과 진행할 예정인 프로젝트가 넘치고 개발하고 있는 모든 것은 이유가 있어서 만들어지고 있지만, 제품 전략 없이 일을 하는 게 곧 드러난다…

이 현상은 두 가지 결과를 초래한다. 첫째, (주로 제품 로드맵에 의존하기 때문에) 낭비되는 노력이 너무 많다. 둘째, 회사의 성과를 낼 수 있는 가장 중요한 문제들에 대해 충분히 집중하지 못한다.

(그래서 PO들에게 비즈니스에 대해 가능한 end to end로, 소위 뾰족하게 기능을 기획하라고 요구하고 있다)

단순히 무엇을 할지 말지를 결정하는 것이 아니라, 진정으로 영향을 줄 수 있는 몇 가지를 고르라는 것이다.

주요 배움과 통찰력을 종합하고 요약하여, 매주 또는 격주로 전체 조직에 가장 중요한 부분을 공유하는 것이다.

그러나 대개 상관관계와 이유를 혼동하고 있다. 성공한 기업이 OKR 기법을 사용했기 때문에 성공한 것이 아니다. 이들이 OKR 기법을 사용하는 이유는 OKR이 임파워드 제품팀 모델을 활용할 수 있도록 설계되었기 때문이다.

(내가 지금까지 OKR이 맘에 들지 않았던 게 이 부분을 간과했기 때문일까? 혹은 내가 속한 조직에서 이 부분이 결여됐기 때문일까?)

팀과 대화를 주고받으며 더 나은 결과를 찾는 것이 리더의 일이다. 리더로서 수동적인 팀을 원하면 안 된다. 팀이 적극적으로 참여하고 토론하지 않는다면, 팀에 그들의 생각과 이유를 분명하게 물어봐야 한다.

팀이 ‘주객이 전도된’ 결정을 내리지 않도록 주의해야 한다. 때때로 팀이 가장 의미 있는 것을 측정하려기보다는 측정하기 쉬운 것으로 핵심 결과를 정의하려는 유혹에 빠지게 된다는 말이다.

모든 비즈니스에서는 중요한 것을 정해진 마감일까지 반드시 해내야 하는 경우가 종종 있다.

(물론 동의한다. 그러나 이건 상호작용을 통해 같이 할 일이지 일방향으로 전달이 되면 안 된다는 걸 많이들 모른다)

기본적인 스타일의 애자일 프로세스Agile process에 익숙하다면, 높은 신뢰도의 날짜를 정하는 것이 불가능하지는 않더라도 매우 어렵다는 것을 알고 있을 것이다. 그러나 제품 출시와 병행하여 제품을 발굴하는 모델에 익숙하다면, 회사에서 필요한 제품 발굴 작업이 끝날 때까지(대개는 며칠이 걸린다) 기다릴 용의가 있는 한, 매우 신뢰할 만한 날짜를 정하는 것은 어렵지 않다.

(그러나 실제로는 어렵다. 특히 비개발 회사에서는 비즈니스에서 개발팀을 임파워드팀이 아니라 기능 개발팀으로만 생각하거나 대하기 때문이다)

이 작업을 수행하기 위해 OKR과 같은 형식적인 기법을 사용하는지 여부는 중요하지 않다. 핵심은 목표에 관한 대화를 나누고, 리더가 필요한 코칭을 제공하고, 제품팀이 가장 적합하다고 생각하는 방식으로 문제를 해결할 수 있는 환경을 제공하는 것이다.

팀 목표에 회사 목표 달성을 위해 해야 하는 중요한 일을 포함하려 한다. 이러한 목표는 해결책이 아니라 해결해야 할 문제를 의미한다.

모든 기업은 시장의 위치가 다르고, 팀이 가진 재능이 다르며, 서로 다른 기술력과 회사 문화를 가진, 고유한 상황에 있음을 이해해야 한다.

이러한 관계의 기본은 제품 리더가 비즈니스를 깊이 이해하고 있으며, 제공된 솔루션이 비즈니스의 다양한 측면에서 작동하도록 보장하기 위해 최선을 다하고 있음을 경영진이 믿어야 한다는 것이다.
이것은 제품 리더의 중요한 무기이자 자산이다. 이것 말고도 다음의 세 가지 관점에서 제품 리더를 평가해 볼 수 있다.
1. 사업 실적 2. 제품 전략 3. 제품팀

알다시피, 모든 것이 강력한 제품 리더를 확보하는 데 달려 있다. 준비가 안 된 사람에게 이런 핵심 역할을 맡기는 실수를 하지 마라. 어쩔 수 없이 준비되지 않은 사람이 역할을 맡아야 한다면, 입증된 제품 리더에게 심도 있는 코칭을 받게 해야 한다.

(PO 관련 업무에 대해서 코칭을 어떻게 받을 수 있을까? 애자일 코치같은 역할이 PO쪽도 있을까?)

기능팀은 보통 대행사 모델과 매우 유사하다. 기능팀은 인소싱이고, 대행사 모델은 아웃소싱이라는 것 외에는 동일하다…기능과 마찬가지로 대행사 직원들은 더 많은 역량이 있고, 기능팀이 싫어하는 것만큼이나 자신들의 모델을 좋아하지 않는다. 하지만 현실은 ‘고객’이 말하는 대로 기능을 만들어내지 않으면 고객은 다른 대행사로 바꿀 것이다.

(이 악순환의 고리를 끊으려면 어떻게 해야 할지가 가장 큰 고민)

에반젤리즘은 결코 멈출 수 없다. 에반젤리즘을 멈추는 순간, 일은 이상한 방향으로 홀러가기 시작한다. 경영진은 초조해 할 것이다. 엔지니어는 자신이 작업하는 이유를 모른다고 주장할 것이다. 사람들에게 이미 충분한 에반젤리즘을 전달했다고 믿고 멈추는 순간, 이러한 부정적인 변화가 생겨난다.

임파워드 제품팀으로 전환한다는 것은 실제로 어떤 의미인가? 전환의 전제조건은 일반적으로 IT 기술의 역할을 비즈니스를 수행하는 데 필요한 비용이 아닌 비즈니스의 핵심 원동력으로 CEO와 고위 리더가 이해하게 하는 것이다…

큰 그림으로 보자면, 다음의 세 가지를 단계적으로 적용해야 한다.

첫째, 훌륭한 제품 리더를 확보해야 한다…

둘째, 훌륭한 제품 리더에게 임파워드 제품팀에 필요한 사람을 모집하고 그들을 향상시킬 수 있는 능력을 제공해야 한다...

셋째, 임파워드 제품팀 모델로 일할 준비가 된 제품팀의 경우 비즈니스와의 관계를 재정의해야 한다. 기능 개발팀 모델에서는 이해관계자가 주도권을 가지고 있으며, 개발팀은 비즈니스를 단순히 지원하는 역할을 수행했다…

(내가 현재 요구하는 게 결국 이 부분, 세번째)

회사가 제품 조직의 기준을 높이고 싶다면 제품에 대해 다르게 생각해야 한다. 제품을 기술 조직(더 나쁘게는 IT 조직)의 일부로 보지 말고, 고유한 조직으로 생각해야 한다… 어떻게 조직의 가치 동인이 되어야 하는지에 대해 이야기하는 것이다.

이러한 유형의 조직에 참여하여 배운 또 다른 교훈은 경영진이 이 제품 운영 모델에 참여하지 않으면 성공적인 전환 가능성이 희박하다는 것이다. 경영진이 제품 조직을 이해하고 참여하여 서로 소통할 수 있는 언어를 갖는 것이 매우 중요하다는 사실을 알게 되었다.

엔지니어의 권한 부여는 엔지니어에게 해결할 문제와 전략적 콘텍스트를 제공하고 기술을 활용하여 문제에 대한 최상의 솔루션을 찾을 수 있음을 의미한다.

엔지니어에게 권한을 부여했는지 여부를 쉽게 알 수 있는 방법이 있다. 엔지니어가 스프린트 계획 회의sprint planning meeting에서 제품 아이디어를 처음 본다면 분명 기능 개발팀이고, 엔지니어에게 의미 있는 권한이 없다는 것이다. 엔지니어를 사용하여 코딩만 하는 경우, 엔지니어 가치의 절반만 얻을 수 있다.