https://leaddev.com/culture-engagement-motivation/using-deadlines-effectively-build-happy-and-creative-teams 사업부에서 설정한 데드라인은 요즘은 거의 의미가 없음. 소프트웨어를 릴리즈하는 게 너무 쉽고, 그래서 릴리즈 한번 한번의 비용이 너무 작아졌기 때문.
도메인별로 중요한 이벤트(교육이면 입학 시즌, 스포츠면 리그 시즌, 이커머스면 블랙프라이데이 등)를 제외하면 거의 모든 데드라인은 환상이다. 두려움과 불안에서 비롯된, 가짜 긴급함(false urgency)에서 비롯된 것.
거꾸로 말하면, 팀에게 실제로 긴급한 무언가가 있다면, 그리고 데드라인을 지킴으로서 얻는 이득이 크다면 설정하면 된다. 근데 설정한다고 끝이 아니다. 팀원들이 모두 같은 모드로 일하려면 이 데드라인을 지키는 것이 왜 중요한지 잘 싱크되어야 함. 예를 들어 펀딩받은 돈이 떨어져간다는 식의 불편한 대화이더라도 해야 함.
그래서 데드라인을 동기부여하는 채찍으로 쓰는 건 안 좋음. 데드라인을 잘 사용하는 방법이 크게 두 가지가 있음.
1. 창의성을 발휘하는 데 도움을 주는 제약으로 사용 - 제약을 가할 때 그 상황에 맞는, 또는 그를 극복하기 위한 창의성이 잘 발휘되기도 함. 특히 프로덕-마켓 핏을 찾아가는 초기 단계에서 데드라인은 과한 계획과 설계를 방지하는 데 큰 도움이 됨. - 다른 예시로, 인프라 개발팀을 리딩했던 경험에서도 데드라인이 유용했음. - 인프라 개발 업무는 일반적인 프로덕 개발 업무보다 훨씬 걸리는 시간도 길고, 가치를 증명하기 위해 보여줘야 하는 것도 많으며, 처음 의도했던 것 이상의 가능성을 열어주는 것도 많음. 그래서 인프라 업무는 가성비 분석이 어려움. - 그러다보니 많은 인프라 팀이 본인들의 리드에게 전체 플랫폼을 2년간 재작성하는 따위의 작업의 당위성을 설득하는 데 어려움을 느낌. 당연히 이런 작업은 거의 항상 실용적이지 않음. - 그래서 나는, 6주에 한번씩 팀이 데모를 보여주도록 데드라인을 설정했음. 완전히 동작하는 무언가를 보여줄 필요는 없지만, 우리가 옳은 길로 가고 있다는 신뢰를 받을 수 있을 수준으로는 만들도록 함.
2. "giving"을 관리하는 도구로 사용 - 세상에 3종류의 사람이 있음. - giver는 이득을 고려하지 않고 남을 도움 - taker는 남을 생각하지 않고 이득을 취하고자 함 - matcher는 그 중간. take하고 나면 give하고, give하면 take하고자 하고. - 회사에서 퍼포먼스 기준으로 줄을 세워보면, 고성과자 giver도 많은데 저성과자 giver도 많음. - 무엇이 이 차이를 만드는지 살펴보니, 탑 giver는 언제 give할지, 언제 내 일을 할지 giving을 관리하는 법을 안다. 이 때 데드라인이 유용한 툴이 됨. - 우리는 대부분 giver와 일하고 싶어하며, giver가 많은 조직은 이직도 적음. 이런 조직에서는 giver들이 저성과자가 되지 않게 관리해주는 게 중요하고 데드라인을 그 도구로 사용하면 됨
음성 기능은 200자로 제한됨 | 
