[IT 회사 생활] 다른 부서에서도 신뢰받는 엔지니어의 특징 다섯가지

※ 일본의 한 블로그 글을 번역한 포스트입니다. 오역 및 의역, 직역이 있을 수 있으며 틀린 내용은 지적해주시면 수정하도록 하겠습니다.

 

1. 가능한 방법을 함께 생각해준다.

 다른 부서 사람의 입장에서 개발의 상세한 부분을 잘 알지 못하기 때문에 엔지니어에게 상담하여 판단을 받는 경우가 많다고 생각한다. 

 예를 들어 다른 부서에서 개발과 관련해서 상담했을 때, 아래와 두 타입으로 답변을 하는 엔지니어가 존재한고 생각한다.

A : "그건 무리입니다", "안됩니다"

B : "그대로는 무리입니다만, 이렇게 하면 원하는 형태에 가깝게 될지도 모릅니다"

 A와 같은 답변을 받으면 가지고 있는 스킬 분야가 다르기 때문에 다른 부서의 입장에서는 이 이상의 발전적인 토론이 불가능하다. B와 같은 답변을 해주는 엔지니어는 이야기의 발전 가능성을 열어주기 때문에 신뢰를 얻을 수 있다.

 

2. 상정한 개발 기간을 지난 경우 그 이유에 설명을 정중하게 해준다.

 예를 들어 납품이나 릴리즈 시기가 뒤로 밀린 경우, 다양한 이유가 있겠지만, 엔지니어들 사이에서는 그 이유가 타당하다고 생각할지 몰라도 다른 부서의 입장에서는 이유 자체는 이해해자민 그 타당성에 대해서는 이해하기가 어려울 수 있다.

 이러한 일이 몇 번이고 반복되면 설령 정당한 이유였다고 해서 "왜 인지 항상 일이 늦는 사람"이라는 인상을 주기 쉽다. 그러므로, 특히 다른 직종의 사람에게 연장된 이유에 대해서 알기 쉽고 정중하게 설명해야겠다는 의식을 가지고 설명을 해야한다.

 

3. 개발에 관련된 리스크를 지적해준다.

 이와 관련해서는 특히 영업이나 마케팅 사이드 사람과의 커뮤니케이션에서 많이 발생한다. 상품을 판매하는 프로모션이 미션인 그들에 입장에서는 "작동되고 있는 " 상태이외에 대해서는 크게 고려하지 않는 경우가 많다.

 예를 들어 "이번에 수주를 위해 XXX 기능을 추가해줬으면 한다"라는 오퍼가 있었을 때, 그것을 구현하면 큰 리스크를 안게 될 가능성이 있는 상황이 있다고 하자. 이러한 상황에서 그대로 개발에 착수하지말고, 추가는 가능하지만 어떠한 리스크가 발생할 가능성이 있는지 충고할 필요가 있다.

 해당 기능을 출시한 후에 리스크가 발각되어 손해가 발생한 경우 "영업쪽에서 부탁한대로 개발했기 때문에"라고 말하는 것으로 책임 회피는 할 수 있겠지만, 회사 내에서 각 부서간의 신뢰 부분은 큰 영향을 끼치게 된다.

 

4. 엔지니어라면 할 수 있는 일은 바로 주워 온다.

 예를 들어 비즈니스 멤버가 원하는 데이터를 내준다던지, Slack의 bot 설정을 추가하여 커뮤니케이션을 효율적으로 할 수 있도록 도와준다던지등 엔지니어라면 다른 부서에 비해서 단시간내에 할 수 있는 것을 해줌으로써 신뢰를 얻을 수 있다. 

 

5. 기술자로서의 긍지가 있다.

 다루고 있는 기술이나 만들고 있는 상품에 대해서 고집이나 양보할 수 없는 라인을 가지고 있는 사람은 신뢰받는다. 물론 조직이나 회사 상황에 따라 탛벼해야 하는 부분이 발생하지만, 자신만이 가지고 있는 양보할 수 없는 라인이나 이상적인 이미지를 가지고 있고 그것에 가까워 지기 위해 끊임 없이 노력하고 있는 사람은 주위에서 신뢰받고 존경받게 된다.

 다른 부서의 입장에서는 그 내용 자체를 상세하게 이해하기는 어렵지만, 그러한 자세를 가지고 있는 사람에게 특정 부분 관련해서는 그 사람에게 맡길 수 있는 믿음으로 연결되게 된다.

---

참고자료

https://qiita.com/Kensuke_Shibata/items/ae0cf3c0cf1bbef9534b