긍정적 사고, 음식의 절제, 규칙적인 운동

장점  지시명령형 리더십은 빠르게 일처리를 해야할 때 유용하게 쓰입니다. 긴급한 상황에 신속한 지시와 명령이 필요한 경우에 지시명령형 리더십이 큰 효과를 발휘합니다. 조직의 긴장이 풀려 있어서, 긴장 분위기를 조성해야 하는 경우 혹은 고객의 불만에 신속히 대응해야 하는 경우에 유용합니다.

단점 지시명령형 리더십의 큰 단점은 부하직원에게 자주성을 부여하지 못한다는 점입니다. 이 리더십을 반복하다 보면 상사의 명령만을 기다릴 뿐 스스로는 아무것도 하지 못하는 지시대기형 부하직원이 만들어지기 쉽습니다. 언제나 상사로부터 지시받은 대로만 하는데 익숙해지기 때문입니다.

장점  미래의 비전을 제시하여 조직 구성원들에게 열정적으로 일할 동기를 부여합니다. 설정된 하나의 목표만을 향해 조직이 움직이기 때문에 조직 구성원은 효율적으로 일할 수 있습니다.

단점 비전형 리더십은 리더에 대한 부하의 존경과 신뢰가 반드시 있어야만 효과를 볼 수 있습니다. 리더보다도 경험이 풍부하고 지식이나 전문능력이 높은 부하직원이 있는 경우, 비전형 리더십은 효과적이지 못합니다. 리더로서의 권위를 잃거나, 리더를 부하직원들이 신뢰하지 않을 때도 마찬가지로 비전형 리더십은 효과를 보기 어렵습니다.

장점 관계중시형 리더십은 새로운 직원을 조직에 동화시키고 업무에 적응시키는데 효과적입니다. 비전형 리더십과 관계중시형 리더십을 함께 발휘하면 더욱 효과적일 것입니다. 비전형 리더십으로 비전을 제시하고 관계중시형 리더십으로 팀의 화합을 도모한다면 팀의 효율은 배가될 수 있습니다.

단점 관계중시형 리더가 이끄는 조직은 ‘사이 좋은’ 클럽으로 빠져버릴 위험이 있습니다. 멤버간에 모두 친밀하기 때문에 조직은 평화롭지만 긴장감이 전혀 없을 수가 있기 때문입니다. 이 때문에 조직성과가 높지 않을 가능성이 큽니다.  

장점 가장 민주적인 리더십으로 모든 부하구성원의 의사에 귀를 기울일 수 있습니다.

단점 집단운영형 리더는 조직을 리드하면서 최종결정을 내리는 능력이 부족합니다. 이 때문에 아무리 부하들과 회의를 거듭해도 의견일치를 이끌어내지 못할 가능성도 있습니다. 의사결정과 업무수행 속도가 떨어진다는 단점이 있고, 긴급한 업무를 수행할 수 없을 때도 많습니다.

장점 조직 규모가 작아 조직 구성원이 조직 전략과 이에 필요한 기술을 잘 알 수 있을 때 효과를 발휘하는 리더십입니다. 조직 구성원이 우수하고 상사의 특별한 상사의 관리가 필요하지 않을 때, 부하가 의욕적이어서 상사의 동기부여를 필요로 하지 않을 경우에 효과적입니다.

단점조직이 크고 복잡해서 상사 혼자서 업무를 처리하기 힘든 경우나, 부하에게 많은 것을 지시하고 가르쳐야 할 때는 큰 효과를 거들 수 없습니다.

장점 육성형 리더십은 부하가 스스로 발전하고자 하는 의지가 있을 때 매우 효과적입니다.

단점 리더의 지도기술이 부족하여 자신이 지도할 부하와 가르쳐야 하는 내용에 대해 제대로 파악하지 못할 경우에는 효과를 볼 수 없습니다. 단기적인 성과를 요구하는 일을 할 때도 육성형 리더십은 효과적이지 않습니다.

  

프로그래머에게 필요한 5가지 덕목

         

1. 모든 걸 잘 하는 게 아닌 걸 인정하자

아무리 난다 긴다 하는 프로그래머도 모든 걸 잘 할 수는 없습니다. 어떤 프로그래머도 모든걸 경험할 수 없습니다. 이걸 모두가 인정하는게 가장 중요합니다. 기획자와 프로그래머 사이에 미묘한 긴장감이 흐르면 기획자는 “내가 만든 기획들은 다른 회사에서 이미 했던거야, 그러니 너는 나에게 반박할 수 없을 걸?”이라는 생각을 가지고 접근하게 됩니다.

가끔 프로그래머에게 와서 이거 되냐고 묻죠. 된다고 얘기하면 그 때 된다고 하지 않았냐며 기획에 넣었다 그러죠. 그런데, 된다. 한다. 할 것이다. 이게 다 같은 얘긴가요? 아닙니다. 이런 문제가 일어나는 이유는 팀웍에 문제가 있기 때문입니다. 그래서 인정해야 합니다. 너와 나, 우리 모두 모든 걸 잘하는 게 아님을.

 

2. 자존심을 세우는 건 좋지만, 쓸데 없는 자존심은 버리자

프로그래머들의 성향은 자존심이 센 경우가 많습니다. 전문직종 사람들이 다들 그렇죠. 이는 본인이 하는 일에 대한 프라이드이기도 하고 자신의 두뇌에 대한 프라이드이기도 한데, 그렇게 나쁜 것만은 아닙니다. 프라이드가 적은 사람은 그만큼 책임감도 적기 때문입니다.

하지만, 내가 해본 것과 해보지 않은 것, 할 수 있는 것과 할 수 없는 것, 빨리 할 수 있는 것과 빨리 할 수 없는 것은 냉철하게 판단해야 합니다. 그래서 “난 이 기간 동안 이걸 만들 수 없다.”고 말할 수 있어야 합니다.

 

3. 기획단계부터 참여하자

이 말을 잘 이해해야 합니다. 기획에 감 놔라, 배 놔라 하라는게 아닙니다. 기획단계에서부터 서로 대화를 하라는 겁니다. 무엇을 만들기로 했으면 어떻게 해야 쉽고 빠르게 만들수 있는지 서로 대화를 해서 내가 선택한것처럼 기획자가 선택할수 있게 되면 더할나위 없이 좋겠죠. 이는 서로에게 좋은 기회일 겁니다.

 

4. 폭넓은 지식을 쌓자

프로그래머가 너무 기술만 파면 다른 파트와 대화가 안 됩니다. 폭넓은 지식을 쌓을수 있도록 노력해야 됩니다. 그래야 기획도 할 수 있고, 기획자랑 대화도 할 수 있고, 나중에는 사업도 할 수 있습니다.

 

5. 같은 프로그래머끼리 괴롭히지 말자

“내가 만들면 3일이면 되는데 저거 만드는데 뭐 이렇게 오래걸려?” 이런 말을 입에 달고 사는 사람들이 있습니다. 어떤 미국에 좋은 학교를 나온친구가 자기가 하면 일주일이면 된다고 했습니다. 그래서 그 사람에게 일을 시켰죠. 그런데 못했어요. 한 달 넘게 걸렸을 겁니다. 그 친구가 프로그래밍 실력이 없어서 못한건 아니에요. 상대 업체가 메뉴얼을 줬는데 준데로 만들어도 안됐거든요.

모든일이 각자 다 사정이 있습니다. 위와 같은 말은 절대 해선 안됩니다.

 

 

보너스, 기획자에게 부탁하고 싶은 말

 

1. 막 던지지 말자

300명이 참여한 프로젝트와 비교하지 마세요. 특히… “엑셀처럼 만들어 주세요”, “포토샵은 되던데”, “네이트온에 있는 기능은 다 있으면 됩니다”

… 이런 말은 일진 애들이 빵셔틀한테 500원 주고 2만원 어치 사온 다음 거스름돈 가져와라는 말과 같습니다.

 

2. 프로그래머의 개인 취향과 특성을 존중하자

저는 게임회사를 다니고 있습니다. 제가 본 바로는, 아티스트들에 대해서는 취향과 경험을 존중해 줍니다. 물론 경영진 앞에서는 이런 것들이 무시되기 십상이기 때문에 나름의 고충이 있지요. 그런데 프로그래머는 더 심합니다. 프로그래머들의 장단점, 취향 따위는 아예 고려가 되지 않습니다.

기획자는 다른 회사의 제품을 벤치마킹을 해서 기획을 합니다. 그리고 프로그래머에게 기획서를 주죠. 그럼 프로그래머는 연구도 하고 삽질도 하면서 프로젝트를 진행시킵니다. 당연히 야근은 필수고 과정 자체도 만족스럽지 못하며 프로그램을 완성시켜도 질이 좋지 않습니다.

 

3. 프로그래머는 시다바리가 아닙니다

우리나라는 서비스 기획자가 최고입니다. 이 나라에 있는 대부분의 회사가 그렇게 생겼습니다. 하지만 해외에서는 프로그래머가 주도하는 회사도 많습니다. 글로벌 기업의 경우에는 더욱 그렇고요. 건축현장에서도 설계자와 현장에서 일하시는분과의 마찰이 있고, 의상디자이너와 현장직 아주머니와의 마찰이 있습니다. 그래도 이 분들은 다들 전공이 그쪽입니다. 반면 소프트웨어, 웹 기획자는 전산 전공이 아니죠.

때문에 디테일한 부분에서 프로그래머가 더 많이 아는 영역이 많습니다. 많은 기획자 분들이 따라오려 노력하지만, 그 차이는 쉽지 않습니다. 그렇다면 당연히 프로그래머를 파트너로 대해야겠지요?

 

원문: 모영철 프로그램 철학 / 편집: 리승환

최고, 최악의 상사를 가르는 체크리스트

http://www.insight.co.kr/news.php?Idx=1883&Code1=002

심리학자 Steve Albrecht 박사가 미국의 심리학 전문 사이트인 Psychology Today에 기고한 칼럼에 따르면 좋은 상사와 나쁜 상사의 유형은 아래와 같다.

■ 좋은 상사

- 팀원들의 의견을 경청한다.

- 모두를 공정하게 대한다.

- 커리어에 대해 멘토링을 해준다.

- 사람들 앞에서 칭찬을 해준다.

- 실수로부터 배울 여유를 준다.

- 경조사, 생일, 아플 때 등 디테일하게 챙겨준다.

■ 나쁜 상사

- 알콜 홀릭

- 업무지시를 번복한다.

- 소리 지른다.

- 무능력하다.

- 부하 직원들의 화장실 가는 시간까지 체크한다.

- 남의 아이디어를 가로챈다.

- 팀원들과 소통하지 않는다.

- 업무에 대해 아무것도 가르쳐주지 않으며, 질문을 귀찮아한다.

- 상부에 나를 깎아내리는 말을 한다.

- 개선책 없이 꾸짖기만 한다.

위와 같이 두 부류의 특징은 완전히 상반된다.

워커홀릭 유능한 상사는 독일까 약일까? ⓒMBC

그렇다면 스스로 질문해보자. “내 보스들은 그들의 리스트를 갖고 있는가?”

그렇다. 그들도 역시 나를 누군가와 비교하고 있을 것이다.

<!--[if !supportEmptyParas]--> <!--[endif]-->

이제 적어놓은 리스트로부터 좋은 상사가 되려면 무엇을 해야 할지, 그리고 하지 말아야 할 것은 무엇인지 배워야 할 시점이다. 

구글다움(Googliness) 을 유지하는 10가지 핵심 가치

1. 최고의 인재와 일하고 싶다.
2. 최고의 인재를 채용하고 직원을 최고로 만들어 줘야 한다.
   똑똑한 사람을 채용해서 바보로 만들지 말자.
3. 공정하게 대하자. 더 좋은 아이디어가 나올 수 있도록 하자.
4. 다양성이 중요하다. 60억 인구를 상대하려면 우리부터 다양해야 한다.
5. 의사결정은 정량적으로 통계에 기반해 한다.
6. 기술적 혁신이 가장 중요하다.
7. 구글에서 일하는 것은 재미있어야 한다.
8. 주인의식을 가져야 한다. 당신이 회사다. 불만이 있으면 직접 고쳐라.
9. 성공은 그냥 오는 것이 아니다. 낮은 자세로 임하고 겸손하라.
10. 옳은 것을 하라. 악마가 되지 말자.
    

사업 개발자(Biz Dev)는 무엇을 잘해야 할까?

바야흐로 개발자의 시대이다. 스타트업의 핵심은 역시 개발이요 개발을 통해 무에서 유를 창조하고 세상을 바꿀 서비스를 만들어 내는 것이야말로 스타트업의 로망이라 하겠다. 그럼 개발자가 아닌 사람들은 무엇을 잘 해야 할까? 보통 인문계 출신의 분들이 사업 개발(Biz Dev) 의 역할을 맡게 되는데, 개발과 제품에 대한 대한 많은 방법론(어자일, 린스타트업, MVP, AARRR 등등등)은 많이 보았지만 Biz Dev의 조건과 역량에 대한 논의는 본 적이 없는 것 같다. 종종 회사의 Biz Dev으로서의 역할을 수행하게 되는 벤처투자자로서 조금이라도 더 도움이 되는 사람이 되려면 무엇을 해야할지 고민하게 되는데, 결과적으로 아래의 역량들이 중요하다.

1. 사람에 강해지자

사람에 강하다는 것은 무슨 뜻인가? 많은 사람들이 이 경우 카리스마적인 리더의 모습이나 넓은 인간관계를 가진 활동적인 사람의 모습을 떠올린다. 물론 그런 것도 사람에 강한 모습일 수 있겠으나 이것이 핵심은 아니다.

비즈니스 관계에서 사람에 강해진다는 뜻은

• 타인에 대한 기본적인 호의를 가지되 악의를 가진사람을 구분해 낼 수 있고
• 타인이 필요로 하는 것, 원하는 것이 무엇인지를 잘 파악하며
• 이를 제공하기 위해 적극적으로 노력하고 커뮤니케이션 하면서
• 동시에 내가 원하는 것을 적극적으로 요구하고 얻어낼 수 있는 명확한 자기 인식과 용기를 가진다.

이러한 능력을 바탕으로 Biz Dev는 좋은 협상가, 좋은 갈등의 중재자가 되어야 하며 실질적으로 도움이 되는 네트워크를 충분히 확보하고 있어야 한다. 인사가 만사라는 말도 있지 않은가?

2. 명확하게 쓰고 말하자

명확하게 글을 써야한다. 여기서 글이란 이메일, 프리젠테이션, 워드 형식의 보고서 등 모든 비즈니스 라이팅을 말한다. 보고서나 PT 자료를 정리하고 전달하는 일은 Biz Dev 업무의 매우 큰 부분이며 이를 명확하고 빠르게 처리할 수 있으면 생산성은 비약적으로 상승한다.

말하기도 마찬가지다. 여기에 더해 청중 앞에서 좋은 프리젠터가 될 수 있다면 Biz Dev의 가치는 더욱 상승한다. 생각보다 남 앞에 서서 말하기를 어색해하는 사람들이 많으며, 이를 전문적으로 훈련하고 가다듬어 자신의 무기로 만든 사람은 소수다. 하지만 프리젠테이션은 연마될 수 있으며 기본적인 훈련만 해도 바로 큰 효과를 볼 수 있다.

반대로 피해야 할 것이 말과 글을 낭비하는 것이다. 이는 사고를 모호하게 만들고, 쓰는 시간과 읽는 시간을 더 걸리게 만든다. 물론 정황상 때때로 이도저도 아닌 내용을 구구절절 써야하는 경우가 있지만 일단은 명확하게 쓰고 말할 줄 안 다음에 하는 것이 좋다. 정말 기본적인 내용이지만 이만큼 중요한것도 없다.

3. 경영학적 개념에 익숙해지고 이를 잘 응용하자

비즈니스맨에게 있어 경영학은 공부하는것이 아니라 스스로 생각하고 연마하는 것이다. 종종 경영학을 공부한다고 각종 경영 서적을 열심히 읽고 공부하는 분들이 있는데 사실 경영학 개론 책과 몇몇 유명한 책들만 잘 읽어도 중요한 프레임워크와 경영학개념들을 대부분 숙지할 수 있다. 하지만 단순히 지식을 알기만 하는 것은 사업에 도움이 되지 않으며 이러한 개념들을 필요에 맞게 조합하여 각각의 회사에 적합한 분석과 전략을 유연하게 도출하는 것이 중요하다.

예를 들어, ‘협상력’ 이라는 개념을 생각해 보자. 사업 관계에 있어 협상력의 강약은 어디에나 존재하며 상호 교환하고자 하는 재화에 대한 니즈가 더 약한 쪽이 더 강한 협상력을 가지게 된다. 하지만, 이 협상력을 어떻게 강화할지는 상황마다 다 다르다. 여기서 중요한 것은 (1) 협상력 이라는 컨셉을 이해하고 이를 강화하기 위해 노력해야한다’ 라는 방향성을 잡는 것이며 (2) 이를 현재 상황에 맞추어 협상력 강화라는 문제를 집중적으로 해결하는 것이다. 이렇듯, 핵심 개념을 여러가지 상황에 맞추어 자유 자재로 적용하고 분석할 수 있어야 한다.

말로 설명하기 참 어려운 부분인데 보다 실제적인 경영/경제학 이슈들을 다룬 책(‘이코노믹 씽킹’ 이나 ‘머니볼’ 같은) 들을 보면 몇 가지 핵심적이고 기본적인 경영학/경제학적 개념을 바탕으로 사업을 분석하고 문제를 해결해 나가는 예시를 많이 볼 수 있다. 중요한 것은 개념을 숙지하는 것 보다 그것을 조합하고 이용하여 현재 비지니스에 특화된 분석과 전략을 도출하는 것이다. 좋은 Biz Dev은 이러한 능력이 뛰어나야 하며 이를 바탕으로 사업에 대한 펀더멘털한 이해하에서 사업 개발에 나서야 한다.

4. 외국어를 하자

이건 자세한 설명이 필요 없다. 영어는 필수다.

무림 고수의 정권지르기 처럼

어찌보면 기본적인 내용이고 측정이 쉽지 않은 역량들이다. 하지만, ’기본중의 기본들에 충실해야 한다’ 는 것이 말하고자 하는 핵심이다. 무림 고수가 30년 연마한 정권지르기와 초보자의 정권지르기가 다르듯, 기본적인 것들의 깊이와 숙련도가 사업 개발을 담당하는 사람의 역량을 좌우하지 않나 싶다. 기본만 하면 된다니 얼마나 좋은가? 새로운 개발 언어를 배울 필요도 없고 유학을 갈 필요도 없으니.

글 : 위현종
출처 : http://goo.gl/6LtNv2