brunch

You can make anything
by writing

C.S.Lewis

by Noah Jul 22. 2021

라이트닝 토크합시다.

개발자 발표는 왜 자꾸 해야 할까?

라이트닝 토크는 왜 하는 걸까?

"발표는 자꾸 왜 하라고 하는 걸까?'

"우리 조직의 정체성은 무엇일까?"


우리가 하는 일이라는 걸 정의할 때 성장과 공유를 꼭 넣고 싶었다.

자기 계발도 일이고, 그 결과로 공유하는 것도 우리의 일의 일부라고.

그래서 1on1 미팅이나, 새로운 기술에 대해서 얘기할 기회가 있을 때마다 라이트닝 토크, 세미나 발표 등에 대한 이야기를 많이 하곤 한다.

대부분의 구성원들은 이런 것들에 대해서 긍정적으로 생각은 하고 있다.


라이트닝 토크에 대해서 고민을 하게 된 개기가 생겼다.

"우리 조직 말고 다른 조직까지 포함해서 발표해보면 어떨까요?"


"범위가 넓어지면 우리의 라이트닝 토크는 라이트 합니까?"


다음날 고민 끝에 팀원들께 사과를 하였다.

발표의 범위는 발표자가 정하는 게 맞는 것 같다. --> 강요하지 말았어야 한다.

하지만 더 많은 사람에게 좋은 정보를 공유하는 건 더 큰 의미가 있지 않을까?   

이왕 준비한 거 더 많은 사람에게 하면 더 좋을 것 같다. (영향력의 확대)


그럼에도 더 많은 사람들을 대상으로 발표해주길 바란다는 말은 덧붙였다.


우리는 어떤 개발자에 환호하는가?


개발만 잘하는 아니 잘한다고 생각하는 개발자들은 많다. 그런데 그런 개발자를 동경하거나 롤모델로 지는 않는다.

우리가 롤모델로 설정하고 동경하는 개발자는 공유하는 능력도 탁월하다.


건전한 조직 문화

어떻게 성장할 것이냐와 강하게 연결되는 것 같다.  우리는 남이 배우고 익힌 것을 공유하고 공유받고 싶어 한다. 그런 도움을 받으려면 스스로 학습하고 그걸 공유하는 습관을 갖고 있어야 한다.


코드를 통한 성장도 필요하지만, 코드로만 성장하는 학습하는 건 특정 부분에 한계가 있다고 생각한다.

(예를 들면 다른 좋은 코드를 접하는 방법이라든가... 좋은 스터디 멤버를 만나는 방법이라든가... )


발표와 평가

발표 많이 하면 평가가 좋아질까?

발표만 잘하면 평가가 좋을 것이라고 말할 수 있는 조직장이 과연 있을까?

하지만 자발적으로 학습한 걸 공유하고 조직과 동료의 성장에 기여하는 행위에 대한 보상을 안 줄 수도 없지 않나 싶다.

발표의 횟수가 아니라 어떤 의도와 팀 성장과, 동료 성장에 좋은 영향에 대한 기여다.     

절대 발표 횟수나 발표 규모가 절대적인으로 좋은 평가를 보장하지는 않을 것 같다.


성장(승진)

요즘 많은 기업에서 개발자의 등급을 정의하고 있다. 높은 등급으로 올라가려면 적극적인 공유 능력과 다른 구성원에게 끼치는 영향력까지 요구한다.

자기 부서가 아니라 타 부서에 공유할 수 있는 능력

지식, 스킬 경험을 공유하여 동료와 팀을 성장시킬 수 있는 능력

이런 능력들이 요구된다. 운 좋게 기회가 닿아서 다른 부서와 협업을 많이 하면 모르겠지만

자기 우물에 들어가서 열심히 일하는 부서에서는 교류가 힘들지 않을까?


그럼에도 라이트닝 토크, 세미나 발표 등을 권할 때 마음 한 구석이 불편하긴 하다.

원래도 하기 싫은 일을 누가 시켜서 하면 정말 정말 하기 싫어지니...   

하고 싶은 일, 해야 하는 일, 쉽지 않은 일이라고 생각해보자. -> 생각만 해도 너무 싫다.


오늘도 이런저런 대안들을 생각해본다.

'기술세미나가 어렵다면 관심사 토크는 어떨까?'

'정기적인 지식 나눔 시간을 갖을까요?'

'라이트닝 토크 주제 리스트를 꾸준히 관리하는 것은 어떨까요?'



매거진의 이전글 매니저 1개월
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari