반응형
반응형

강점을 매일 사용하는 직원들은
업무에 만족할 가능성이 6배 높고, 스트레스와 불안은 줄어든다.
관리자가 직원의 약점에 초점을 맞출 때 직원의 성과가 27% 감소하는 반면,
강점에 초점을 맞추면 36퍼센트 증가한다.
상사가 부하직원의 강점에 초점을 맞출 때 직원들은
관리자와 더 좋은 업무관계를 구축하고, 성과가 향상되며,
업무 적극성이 높아지는 것으로 드러났다.
- 갤럽


‘자질이 부족한 사람을 배치하고 약점에 초점을 맞추는 것은 낭비다.
그것은 인간 자원의 오용이다.
강점을 활용해 생산성을 올리려고 노력하지 않으면,
그가 얻는 것은 기껏 충격과 그의 약점,
그리고 성과와 목표달성 능력에 대한 장애물로부터 오는 허탈감 뿐이다.’
경영 구루 피터 드러커 교수의 지적입니다.
약점 보완이 아닌 강점 활용에 집중해야 합니다.

반응형
반응형

 

https://careerly.co.kr/comments/82474

 

킴코더 / 주니어 개발자를 고용하는 데 드는 어려움 | 커리어리

회사 입장에서 어려움 점을 이해해 보고 주니어 개발자가 꼭 알아야 할 점을 파악해 봅니다. 1️⃣ 주니어 개...

careerly.co.kr

 

https://copyconstruct.medium.com/tactical-challenges-in-hiring-junior-engineers-29e31634a9bd

 

Tactical Challenges In Hiring Junior Engineers

All too often, I see tweets that read like platitudes about how every team should be hiring junior engineers. Let me start off by saying…

copyconstruct.medium.com



회사 입장에서 어려움 점을 이해해 보고 주니어 개발자가 꼭 알아야 할 점을 파악해 봅니다.

1️⃣ 주니어 개발자는 1, 2년의 투자 기간이 필요하다

최소 1, 2년 정도 한 사람에게 투자할 수 있는 팀이 아니라면 주니어 개발자를 고용하지 않는 것이 좋다. 특히 투자자들에게 결과물을 빨리 내야 하는 스타트업에는 적합하지 않은 고용 방법일 수 있다.

2️⃣ 그들에게는 경력이 많은 관리자가 필요하다

경력이 없거나 자질이 없는 관리자는 주니어 개발자를 고용하거나 멘토 할 수 없다. 주니어 개발자를 고용하려면 경력이 풍부한 관리자가 필요하다.

3️⃣ 잘 정의된 업무만 줄 수 있다

주니어에게 몇 주 만에 결과물을 내야 하는 업무를 줄 수 없다. 따라서 팀은 최소 6개월에서 12개월 안에 결과물을 낼 수 있는 프로젝트를 갖고 있어야 한다. 하지만 실상에서 '주니어'에게 적합한 프로젝트를 많이 가진 팀이 없다.

4️⃣ 주니어 개발자에게 투자한 만큼 이득을 못 볼 수 있다

실리콘 밸리의 엔지니어는 같은 회사 근무 기간이 평균 18개월에서 24개월이다. 그만큼 이직이 잦은데, 주니어 개발자를 성장시키기 위해 약 1년에서 2년 투자하면 이득을 보기 전에 그들은 다른 회사로 이직할 확률이 크다.

📌 원문에는 '시니어 개발자의 생산력을 저하한다'라는 포인트도 있지만, 개인적으로 주니어 개발자를 발굴하고 그들을 성장시키는 것 또한 시니어 개발자의 직책이라고 생각합니다. 단기적으로 생산력을 저하할 수 있어도, 여러 가지 프로세스 개선(예: 개발자 온보딩 코스 만들기, 자주 묻는 질문에 대한 답변 문서화하기, 그룹 학습 세션 정기적으로 열기, 다른 사람에게 위임하기 등등)을 통해 생산력을 올릴 수 있고, 무엇보다도 장기적으로 보면 좋은 일이라고 생각합니다. 그리고 팀마다 적합한 시니어/주니어 비율을 갖는 것이 '회사의 책임'이라고 생각합니다. 좋은 시니어/주니어 비율과 학습 프로세스 개선은 오히려 생산성을 높일 수 있다고 봅니다.

📌  주니어 개발자가 알아둬야 할 점

글을 읽고 주니어 개발자가 알아야 할 점을 생각해 봤습니다. 

1. 경험이 많은 관리자가 있는 팀을 찾자.
2. 주니어 개발자에게 투자할 수 있는 팀인지 확실하게 알아보자.
3. 시니어/주니어 비율이 상대적으로 좋은 팀으로 가자.
4. 온보딩 프로세스나 문서화가 잘되어 있는 팀은 주니어 개발자로써 학습 속도를 끌어올리는 데 도움 된다.
5. 주니어 개발자의 성장을 돕고 '그들의 성장'을 '직책'이라고 여기는 시니어 개발자와 관리자와 함께 일하는 것이 좋다.

🪴 함께 읽으면 좋은 글:

개발자 진로에 중요한 직급별 스킬과 기대 역할
https://careerly.co.kr/comments/78043

코딩 테스트, 알고리즘 공부 로드맵
https://careerly.co.kr/comments/82187

코드 리뷰 잘하는 법
https://careerly.co.kr/comments/82185

반응형
반응형


직원이 자신의 운명에 대해 좀더 많이 책임감을 느끼기를 바란다면
관리자는 내적 헌신을 이끌어내야 한다.
원칙적으로 내적 헌신은 참여를 전제로 하기 때문에 권한이양과 밀접한 관계가 있다.
직원의 내적 헌신을 원한다면 원대한 목표를 정하고
세부 목표를 수립하며 목표를 성취할 방법을 모색하는 과정에
직원들을 더 많이 참여시켜야 한다.
- 크리스 아지리스, 하버드 대학 교수


일찍이 18세기에 영국 법리학자 윌리엄 앨턴 존스는
‘가장 뛰어난 두뇌의 소유자보다는 동료의 두뇌와 재능을 조화롭게 이용하는 사람이
가장 만족스러운 결과를 얻는다’고 말한 바 있습니다.
동료의 재능을 활용하고 싶다면 오너십을 심어주어야 하고,
이를 위해선 중요한 의사결정에
가능하면 많이 참여할 수 있는 장치를 마련하는 것이 좋습니다.

반응형
반응형

나는 자기 스스로 일에 높은 동기를 부여하지 않은 사람이
관리자로 성공한 경우를 결코 보지 못했다.
사람에게 최고의 동기를 부여하는 사람은
대부분 자신들의 업무에 최선을 다해 몰두하여 열심히 일한 사람들이다.
- 밴 플리트, '22가지 관리함정'에서


상대방의 관점에서 바라보기, 비전 제시, 성장에 도움 주기,
좋은 사람들과 함께 일하기, 칭찬과 높은 기대, 가치있는 업무 등이
급여와 근로조건 보다 더 중요한 동기부여 요인으로 밝혀졌습니다.
그러나 최후의 동기부여 요인, 그리고 가장 효과가 높은 것 중 하나는
바로 리더가 몸으로 실천하는 솔선수범입니다.
구성원에게 요구하기 전에 먼저 실행해 보십시오.
분명 놀랄만한 효과를 거둘 수 있습니다.

반응형
반응형

[KAKAO] 플러스친구, 관리자센터


옐로우아이디에서 플러스친구로 변경되었다. 플러스 친구 만들어야 함. 


https://center-pf.kakao.com/login



플러스친구 개설하고 챗봇 스타트~ 


플러스친구 관리자 > 관리 > 상세설정 > 홈 공개 On.


플러스친구 관리자 > 홍보하기 에서 QR코드도 다운받고. 


1:1채팅과 스마트채팅을 해보자고요~ 



관리자 메뉴얼 : https://t1.daumcdn.net/rocket/user-guide/user-guide.pdf?x-content-type=application%2Fpdf&v=1502428941400


앱에서 관리 할 수 있다.


안드로이드 : https://play.google.com/store/apps/details?id=com.kakao.yellowid&hl=ko


아이폰 : https://itunes.apple.com/kr/app/id990571676?mt=8


...

반응형
반응형

구글이 제시한 '관리자의 자격'



2002년 무렵 구글에는 관리자가 없었다. 당시의 구글은 개발자에 의한, 개발자를 위한, 개발자의 회사였다. 그들은 철저히 개발자 중심 문화를 가지고 있었기 때문에 관리자가 필요없다고 생각했을 것이다. 코드를 생산하는 개발자 중심 문화에서 관리자는 잘하면 필요악, 그렇지 않으면 개발자에게 기생하는 부차적 존재로 취급되었을 것이다.

개발자 중심의 문화는 구글만의 이야기가 아니다. 2002년에 국한되는 이야기도 아니다. 지금도 미국에서는 코딩 실력이 좋은 개발자가 관리자가 되기를 거부하거나 마음속으로 관리자의 업무를 불필요하게 생각하는 일이 드물지 않다. 지위가 올라가도 코드를 생산하지 않으면 부차적 존재라는 자괴심을 느낄 수밖에 없는 문화다. 그렇기 때문에 좋은 관리자들은 기술로부터 멀어지지 않기 위해서 부단한 노력을 기울인다. 최근 칼럼에서 언급한 개발자 무정부주의(developer anarchy)는 이런 개발자 중심 철학과 문화의 연장선에 놓여있다.

관리자의 필요성을 인정하지 않은 구글은 2008년에 한 걸음 더 나아가서 관리자 무용론을 실제로 증명하기 위한 연구를 진행했다. 그걸 증명까지 해야할까 싶지만, 아벨 아브람이 최근 인포큐에 기고한 글에 의하면 구글의 연구는 기대했던 것과 반대의 결론을 도출했다고 한다. 관리자가 쓸모없는 존재가 아니라 팀의 생산성을 담보하기 위한 중요한 요소라는 뜻밖의(!) 결과가 나온 것이다. 

[아벨 아브람 기고 원문 바로가기]


팀에 마이너스가 되는 엉터리 관리자가 많은 것은 사실이지만 팀의 생산성을 높이는데 결정적인 역할을 수행하는 좋은 관리자가 존재하는 것도 사실이다. 이것은 우리의 상식이나 경험에 비추어봐도 이해하기 어려운 일이 아니다. 

그럼 팀에 도움이 되는 좋은 관리자는 어떤 사람인가? 


* 구글의 연구팀은 좋은 관리자가 가져야 하는 8가지 덕목을 다음과 같이 정리했다.

1. 좋은 코치(coaches)다.


2. 팀에게 권한을 양도하며 마이크로매니지를 하지 않는다.


3. 팀원의 성공에 관심을 표명하며 개인적 삶에도 관심을 기울인다.


4. 생산적이며 결과를 중심으로 사고한다.


5. 훌륭한 커뮤니케이션 능력을 가지고 있다.


6. 팀원들이 경력을 키워나가도록 도움을 준다.


7. 팀을 위한 명확한 비전을 가지고 있다.


8. 팀에게 조언을 해주기에 충분한 기술적인 능력을 갖추고 있다.


좋은 코치는 스스로 뛰는 사람이 아니라, 선수가 원하는 포지션에서 마음껏 뛰게 해주는 사람이다. 기술 관리자(technical manager) 중에는 자신의 기술적 역량과 판단을 팀원의 것보다 우위에 놓고 시시콜콜하게 명령을 내리는 사람이 있다. 이런 태도는 다음 항목인 마이크로매니지와 연결된다. 팀원이 아니라 자신의 기술력에 의존하기 때문에 팀원을 스스로 생각하는 창의적인 개발자가 아니라 자신의 명령을 오차없이 수행하는 병사로 취급한다. 이런 관리자 아래에서 일하는 개발자가 건강한 동기부여를 가질 리 없다.


■ 진정한 개발자 세계에서 관리자는 '상관'이 아니다

사소한 부분을 일일이 간섭하고 통제하는 마이크로매니지는 관리자의 그릇과 연결된 문제다. 넷플릭스는 이걸 “통제(control)가 아니라 문맥(context)"이라고 표현했다. 좋은 관리자는 팀원을 통제하는 것이 아니라 팀원에게 필요한 일의 전후맥락을 설명한 후, 믿고 맡긴다. 사소한 통제에 집착하는 관리자는 문맥을 제시할 능력이 없기 때문에 그렇게 하는 것이며, 따라서 관리자로서의 역량이 부족한 것이다. 관리자의 마이크로매니지는 개발자의 생산성을 저해하는 치명적인 독이다.

팀원의 개인적 삶에 관심을 갖는 것은 관리자 자신의 취향과 스타일에 달려있는 문제다. 하지만 팀원의 성공에 관심을 갖는 것은 좋은 관리자가 갖춰야 하는 필수 덕목이다. 최근에 나는 회사에서 자신의 팀원과 '경쟁'하는 관리자를 발견하고 전후맥락을 살핀 다음 인사조치를 단행한 경험이 있다. 자기가 가진 권력적 우위를 이용해서 팀원의 아이디어를 자신의 아이디어로 둔갑시키는 관리자를 발견한 것이다. 이건 관리자가 가질 수 있는 모습 중에서 최악이다. 좋은 관리자는 팀원을 이용해서 자기를 돋보이게 만드는 것이 아니라 진심으로 팀원의 성공을 위해서 봉사해야 한다.

결과를 중심으로 사고하는 것도 반드시 필요하다. 개인적인 호불호, 지연이나 학연, 아부, 허황된 장담, 소문, 감정에 휘둘리는 관리자는 관리자로서의 자격이 없다. 누가 좋은 품질의 코드를 생산하는가, 얼마나 빠르고 정확하게 일을 마치는가, 어려운 문제를 해결하기 위한 좋은 아이디어를 제안하는가, 다른 사람과 잘 협업하는가, 스스로 할 일을 찾아서 적극적으로 행동하는가, 의사소통을 잘 해서 자기가 하는 일을 투명하게 만드는가. 이런 구체적인 결과만으로 판단을 해야한다. 출퇴근 시간, 휴가, 재택근무, 병가 같은 근태 역시 결과 중심의 사고에 영향을 주지 않아야 옳다.

관리자가 좋은 커뮤니케이션 능력을 가져야 한다는 것은 상식이다. 다만 여기에서 말하는 커뮤니케이션은 말을 뉴스앵커처럼 또박또박 유려하게 하라는 뜻이 아니다. 투명하고 솔직해야 한다는 뜻이다. 공감(empathy)하고 공명(resonance)해야 한다는 뜻이다. 아무리 역량이 뛰어나고 성실한 관리자라고 해도 타인의 이야기에 공감할 줄 모르면 팀원에게 고통을 준다. 공감. 8개의 항목 중에서 이게 제일 중요하다. 팀원의 입장과 처지를 자기 것처럼 이해하고, 고민하고, 아파하고, 억울해하고, 분노하고, 노력하고, 기뻐하는 것. 관리자가 가져야 하는 덕목 중에서 제일 중요한 것은 공감능력이다. 이게 핵심이며 여기에 비하면 다른 능력은 모두 부차적이다.

명확한 비전과 기술적 능력은 관리자 자신의 역량 문제다. 있으면 좋고, 없으면 아쉽지만 그렇다고 해서 관리자로서의 결정적인 결격사유는 아니다. 비전은 더 위에 있는 디렉터나 CTO에게 빌릴 수 있고, 기술적 능력이 부족하면 팀원들에게 빌릴 수 있기 때문이다(비전을 남에게 빌릴 수 없는 CTO나 임원급 간부는 면도날처럼 날카로운 비전을 스스로 가지고 있어야 한다. 이 주제는 나중에 다루겠다).

이상 구글 연구진의 발표내용을 중심으로 관리자의 자격을 살펴보았다. 불만을 품은 직원은 회사를 떠나는 것이 아니라 관리자를 떠난다는 말이 있다. 관리자의 역할이 그만큼 중요하다는 뜻이다. 진정한 개발자 세계에서 관리자는 '상관'이 아니다. 수행하는 일의 기능(function)이 서로 다를 뿐이다. 관리자는 개발자가 개발에 집중할 수 있도록 옆에서 봉사하는 사람이지 개발자를 상대로 명령하거나 독단적으로 판단하는 권력을 가진 사람이 아니다. 좋은 관리자는 이런 사실을 이미 잘 알고 있다. 행여 관리자라는 타이틀을 봉사가 아니라 권력으로 착각하는 사람이 있으면 이 글을 읽고 생각을 바꾸기 바란다. 관리자의 자격은 그 착각이 없는 사람으로 국한되기 때문이다.



원문보기: 

http://www.zdnet.co.kr/column/column_view.asp?artice_id=20170227091914



.

반응형

+ Recent posts