스마트폰 SW 개발 업무의 경우, 복잡한 SW 구조와 밀접도 때문에 개발팀 간 R&R이 불분명한 grey area가 많이 존재한다. 해서 새로운 기능 요청이 발생한 경우, 이 기능을 A팀과 B팀 어느 쪽에서 구현이 가능한 경우 - 구조적으로 어느 쪽에서 하는 것이 바람직하다는 판단을 떠나서 - 서로 일을 맡지 않기 위해 온갖 논리로 싸우게 되는 경우가 많다.
이런 일이 발생하는 경우 나는 싸우기 보다는 우리팀에서 해당 기능을 구현하는 편을 선호한다. 여기에는 몇가지 장점이 있다. 우리팀과 직접적인 관련이 없는 기능이라 하더라도 우리팀에서 구현을 하면 우리를 필요로 하는 사람들이 많아진다. 물론 일을 많이 하면 해결해야 하는 이슈도 많이 생겨서 불만을 갖는 팀원이 대다수이긴 하다. 하지만 이슈가 많이 생긴다고 해서, 우리팀에게 해가 되는 경우를 본 적은 거의 없다. 프로젝트의 성패에 심대한 영향을 끼친 경우라면 모를까, 대개의 경우는 팀 리드 (나와 같은 사람들)가 대표로 가서 깨지고 오면 그만이다. 오히려 윗사람들에게 많이 노출되는 부수 효과가 있어서 우리팀의 기여도를 각인시켜주는 효과가 있다. ‘저 팀 왜 이렇게 문제가 많아’ 보다 더 걱정해야 하는 말은 ‘저 팀은 무슨 일을 하는 팀이지?’이다. 기술적인 이슈가 많은 팀은 경영자가 골치를 썩긴 하겠지만 어쨌든 경영자의 머리 속 한 켠에 자리를 잡는다. 하지만 노이즈를 만들어내지 않는 팀은 경영자의 기억 속에서 멀어지고 몇차례의 조직 개편을 겪으면 없어지거나 쪼그라 들기 십상이다.