정치질이나 팀 간 소통 단절이나 업무 방식으로 인한 갈등 대부분은 어디서든 발생하는 일인 것 같다. 조직 내에서 개개인에 대한 신뢰감이 바탕이 되지 않으면 이런 일들이 더 자주 일어난다. 신뢰감이 없는 상황이란 이런 것이다. 1. 비난을 받을 것 같아 의도적으로 다른 사람을 폄하하거나 비난하여 본인의 입지를 다진다. 2. 다른 개발자가 자기 편의만 생각하며 일한다고 생각하며 소극적, 혹은 수동공격적으로 커뮤니케이션에 임한다. 3. 저 팀은 안 그래도 바쁜 우리 팀원들에게 공수를 요청하므로 요청에 부정적으로 응한다(내용과 관계없이). 4. 이 동료의 역량은 믿을 수 없으므로 곤란한 질문을 하거나 부담스러운 업무를 제공한다. 5. 이 동료는 마음에 들지 않으므로 꼭 필요한 자료를 전달하지 않거나 도움 요청에..
페스타에서 우연히 devfest 개최 글을 보고 흥미롭다고 생각해 참석 신청을 했다. 굉장히 많은 사람들이 참석했고 특정 세션들은 넓은 홀을 사람들이 꽉 채울 정도로 인기가 많았다. 가장 인상적이었던 발표는 3시 50분에 진행된 [팀장의 탄생] 이라는 주제였다. 엔지니어였다가 팀장직을 맡게 되고 어떤 식으로 좋은 팀장이 되기 위해 노력했는지에 대해 이야기해주셨다. 좋은 팀장의 가장 중요한 점은 업무를 하달하는 역할이 아니라 업무를 잘 할 수 있게 만드는 역할이라는 점이다. 이 일을 왜 해야하지? 왜 이렇게 하면 안 되지? 누가 이런 걸 하라고 하는거지? 라는 식으로 팀원에게 단순히 업무만 전달해서는 동기부여를 끌어내기 어렵다. 적어도 단기적으로는 기술에 대한 열정 정도로 이겨낼 수도 있겠지만, 장기적으로..
최근에 같이 일하기 싫지 않은 개발자라는 글을 봤다. https://brunch.co.kr/@kaily/40 같이 일하고 싶지 않은 개발자 특앞으로도 쭉- 만나고 싶지 않은 개발자의 유형을 정의하고 경험을 공유한다 | 경력이 길어질수록 많은 협업자들을 만나는데, 그중 가장 많이 만나고 많은 커뮤니케이션을 하는 게 개발자다. 주brunch.co.kr 글이 올라오고 한바탕 떠들썩했는데, 개인적으로는 뭐 그러려니 했다...구현이 불가능한데 로직 정의도 정확히 못한다면서 디자이너나 기획자의 역량이 부족하다며 탓을 하거나은근슬쩍 개발이 가장 전문적인 직무인 것처럼 행동하는 안하무인 자아과다 개발자들이 한둘이 아니었다.그러니 기획자라고 못할 일이 뭐 있겠는가...(동의한다는 뜻은 아님)..
