1. 질문하는 골든타임 15분!
15분동안 고민해서 해결할 수 없으면 바로 질문해야 한다.
모르는 일이거나 전혀 힌트를 얻을 수 없는 상황에서는 질문 필수!!
2. 피드백 요청
많은 사람들은 자신 이외에 관심이 없고, 먼저 나서서 피드백 받기를 해야 한다.
피드백 상대의 발전과 성장을 위한 피드백이어야 한.
간혹 쓴소리가 피드백인줄 아는 사람들이 존재하며, 골탕 먹이려고 나쁜 의도로 피드백을 하는 사람도 있음
이럴땐 피드백해주는 사람의 모수를 늘려서 도움 되는 피드백을 수집하는 것이 좋다.
3. 남겨진 코드(문서를 쓰는 것이 좋다)
코드는 2년정도 지나면 최초 작성자의 손을 완전히 떠나는데, 추후에 내가 아닌 누군가가 코드를 유지보수할 경우 관련 문서가 작성되어 있으면 도움이 많이 된다.
4. 입사시 해볼만 한 것 = 온보딩 개선하기!
직전 입사자 온보딩 이후 방치되는 문서가 그 사이 조직내에서 여러사항이 변경될 수 있으므로 자신이 온보딩하면서 필요에 따라 업데이트를 하고 이를 다른 사람들에게 공유를 해보자.
ex) 온보딩 개선
Readme.md 내에 링크가 깨져있거나 예전 링크들을 최신화 하여 PR 작성
PR 작성법이 온보딩 문서에 없는 경우 이를 질문해서 적어두고
배포 프로세스를 배우는 도중에 문서에 없는 내용이 발견되면 즉시 문서에 변경사항 업데이트하기
5. 업무일지 작성하기
입사 초기에는 업무가 별로 없으므로 이때 내가 기억하기 위해 업무일지를 작성하는 것이 좋다.
잘된 업무일지를 참고하여 작성하는 것이 좋으며, 문서를 늘리기 위한 목적으로 작성하며 안된다.
프로젝트에서 이런 내용들을 업데이트 했다거나, Trouble-Shooting 등 내용들을 간략하게 적으면 된다.
ex) 방치된 프로젝트를 내가 해결하면서 알게 된 점들을 작성하기
비즈니스 로직을 파악해서 PHP 문서의 코드를 기획자들에게 크로스체크하면서 문서를 작성하면 나중에 정책문서를 만드는데 도움이 된다.
6. 일의 주인이 되어보자!
적극적으로 문제를 해결하려는 사람이 되어야 하며, 쉽게 대체될 수 없는 사람이 되어야 한다.
자신이 일을 잘하고 있는지는 바로 위의 상사부터 대표까지 무의식 속에 어떤 존재로 각인이 되어 있는지에 따라 가시성을 볼 수 있다.
사람들은 평소에 남에게 관심이 없으므로 먼저 남에게 인사를 하며 칭찬을 해주자.
"누구님 덕분에 일이 잘 해결되었습니다." 라고 이메일 뿐만 아니라 문자, 카톡, 대화로써 남에게 감사움을 표현하면, 상대방도 내가 저사람에게 도움이 되었구나라는 것을 느끼게 되어 무의식속에 각인된 존재가 된다.
7. 높은 성과를 해낸 팀의 핵심
구글에서 Project Aritotle을 진행하여 높은 성과를 낸 팀들을 연구하였는데, 그 연구 결과가 아래 그림과 같다.
- 심리적 안정감
- 신뢰감
- 구조와 명확성
- 일의 의미
- 영향력
이중에서 제일 중요한 것이 1. 심리적 안정감이다.
신입으로서 기획, 인프라, 구조 등에 대한 아이디어를 표현하기 쉽지 않지 않지만, 문서화 및 공유를 하여 문제점들을 해결하거나 커피챗을 이용하여 의도적으로 가벼운 이야기를 하여 친해져서 상대에 대한 거부감 및 안좋은 감정을 풀어내려고 노력해보자.
참고) https://brunch.co.kr/@easyahn/273
Q&A
Q) 인터뷰어로서 면접볼때 같이 일하고 싶은 사람을 판단하는 기준이 있나?
A) 일을 못하는 사람을 걸러내는 것이 중요하며 그 팀에 내가 필요한 사람이 되는게 중요하다.
Q) 팀원으로서 되지 말아야 할 유형
A) 1. 남탓 하는 사람 2. 단어 선택이 공격적인 사람
Q) 팀 동료가 합류했을 때 채용에 성공했다고 느끼는 기준은?
A) 대부분 신입들은 3개월 안에 포텐셜을 보여주는데, 일주일 안에 그 사람이 뛰어난지 바로 알아낼 수 있다.
뛰어난 사람들은 자기가 해야 할 것을 알아서 해나가기도 하고 할당한 업무에 관한 문서 등 업무의 맥락을 파악하기 위해 질문을 많이 한다.
참고) 일잘러 신입 개발자
참고)
토이 프로젝트 참고
이력서 작성시 참고1
이력시 작성시 참고2
읽어볼 책)
일의 감각 - 조수용,
Linchpin - 세스 고딘 책을 읽을 것을 추천함.
