11 Motivation

[jongfeel]

제 11장 동기부여

쾌속 개발의 네 분야인 사람, 공정, 제품, 기술 중에서 사람이 소프트웨어 일정을 단축할 수 있는 잠재력이 가장 크다.
여러 연구는 비슷한 경력의 개발자 사이에 10배가 넘는 생산성 차이를 발견하기도 했다 (Sackman, Erikson and Grant 1968, Curtis 1981, Mills 1983, DeMarco and Lister 1985, Curtis et al. 1986, Card 1987, Valett and McGarry 1989)

의심할 여지 없이 동기는 생산성에 가장 큰 영향을 미치는 요인이다.
하지만 동기는 무형적인 요소이기 때문에 정량적인 측정이 어렵다.

그렇다고 해도 개발자 동기를 고취하는 방법이 전적으로 베일에 쌓인 수수께끼는 아니다.

11.1 전형적인 개발자 동기

표 11-1에서 제시하는 자료의 개발자는 프로그래머 분석가를 대상으로 하고 있긴 하다.
개발자에 따라 프로그래머 분석가 보다는 관리자 혹은 일반 대중이 더 맞을 수도 있다.

Table 11-1. Comparison of Motivators for Programmer Analysts vs.Managers and the General Population

Programmer Analysts	Managers of Programmers	General Population
1. Achievement	1. Responsibility	1. Achievement
2. Possibility for	2. Achievement	2. Recognition growth
3. Work itself	3. Work itself	3. Work itself
4. Personal life	4. Recognition	4. Responsibility
5. Technical-supervision	5. Possibility for	5. Advancement opportunity growth
6. Advancement	6. Interpersonal	6. Salaryrelations, subordinate
7. Interpersonaㅣ	7. Interpersonal	7. Possibility forrelations, peersrelations, peersgrowth
8. Recognition	8. Advancement	8. Interpersonalrelations, subordinate
9. Salary	9. Salary	9. Status
10. Responsibility	10. Interpersonal	10. Interpersonalrelations, superiorrelations, superior
11. Interpersonal	11. Company policies	11. Interpersonalrelations, superior and administrationrelations, peers
12. Job security	12. Job security	12. Technical-supervision opportunity
13. Interpersonal	13. Technical-supervision	13. Company policies relations, subordinate opportunity and administration
14. Company policies	14. Status	14. Working conditions and administration
15. Working conditions	15. Personal life	15. Personal life
16. Status	16. Working conditions	16. Job security

Sources: Adapted from Software Engineering Economics (Boehm 1981) and “Who Is the DP Professional?” (Fitz-enz 1978).

자료는 옛날 자료이지만 개발자, 관리자, 일반 대중 사이에 나타나는 차이점을 이해하는 데 커다란 의의가 있다.

개발와 관리자 사이에 나타나는 차이가 둘 사이에 흔히 발생하는 의사소통 문제 중 일부라고 볼 수 있다.
개발자에게 의욕을 불어넣고 싶다면 기술적인 도전, 자율, 새 기술을 배우고 활용할 기회, 경력 개발을 강조하고 개인 생활을 존중해야 한다.

개발자 동기를 이해하는 데 도움이 되는 자료는 MBTI(Myers-Briggs Type Indicator) 인성검사를 이용해 개발자 성격 유형을 조사한 결과이다.
MBTI 인성검사는 사람의 선호경향을 네 범주로 나누고 측정 결과를 4가지로 분류한다.
16가지 조합이 가능하며, 16가지 성격 유현이 존재할 수 있다.

두 차례 걸친 대규모 조사에서 컴퓨터 전문직 종사자가 일반 대중보다 훨씬 내향적으로 밝혀졌다.
내향적인 내성적과는 다르다. 내향적은 사람이나 물질과 같은 외부 세계보다 사상과 같은 내적인 세계에 더 큰 관심을 기울인다는 뜻이다.
일반 대중은 1/4 혹은 1/3이 내향형인데, 전산 인력은 1/2 에서 2/3 정도가 이에 속한다 (Lyons 1985, Thomsett 1990)

같은 연구에서 컴퓨터 전문직 종사자는 80%가 사고(T)를 선호한다고 밝혀졌다.
사고형은 주관적인 개인 가치보다 논리적이고 객관적인 기준에 근거하여 결정을 내린다.
따라서 인지(P)보다 판단(J)을 선호하는 성향도 드러난다.
전산 인력은 2/3가 판단형으로 밝혀졌다.
인지형은 융통성과 적응력이 높은 반면, 판단형은 계획적이고 정돈된 방식으로 생활하는 경향이 있다.

개발자를 설득하려면 논리적으로 주장하는 편이 낫다.
동기유발을 위해 불가능한 목표를 설정하는게 낫다고 얘기하지만 이는 감정형(F)에게는 자극을 주지만 사고형(T)에게는 비논리적이라는 이유로 이런 목표를 거부한다.

사람마다 동기를 유발하는 요인이 다르다.
따라서 개인에게 맞는 동기 유발 요인을 찾는 것이 좋다.

Motivation, Morale, and Job Satisfaction

동기는 업무에 전념하게 만드는 힘이다. 동기가 노력 형태, 방향, 감도, 지속시간을 결정한다.
사기는 직업에 충실하려는 열의를 말한다.

동기가 낮고 사기가 높다면 프로젝트가 쉽고 팀이 재미있으며 활발하여 프로젝트에 계속 참여하고 싶은 것이다.
반대로 사기가 낮고 동기가 높다면 회사가 그만두는 자신을 안타까워 하도록 참여하기 싫은 프로젝지만 뛰어난 성과를 거두고 싶은 경우도 있다.

직업 만족도는 현재 직업에서 만족할 수 있는 가치를 말한다.
직업 만족도와 동기 사이에도 어느 정도 상관 관계가 있지만 동기는 낮고 직업 만족도가 높을 수 있으며 그 반대인 경우도 있다.

쾌속 개발 관점에서는 단일 프로젝트에서는 동기가 가장 중요하고, 조직 내 장기적인 쾌속 개발 능력에는 직업 만족도가 가장 중요하다.

11.2 5대 동기 유발 요인

압력을 가해 동기를 유발하는 방법은 나쁘다.
프레드릭 허츠버그가 밝혔듯이 이 방법은 동기 향상이 아니라 이직을 유발한다 (Hezberg 1987)

개발자의 내적 욕구를 충족할 수 있는 환경을 조성하라.
의욕이 넘치는 사람은 초과근무를 해도 즐거워한다.
개발자 동기에 영향을 미치는 5대 요인에 집중해 신명나는 분위기를 조성할 수 있다.

• 성취감
• 성장 가능성
• 업무 자체
• 개인 생활
• 기술 관리 기회

성취감

좋아하는 일에 집중할 수 있는 환경을 제공하면 좋아하는 소프트웨어 개발을 잘 할 수 있게 된다.

주인 의식

주인 의식 혹은 참여 의식은 성취욕을 자극하는 열쇠다.
다른 사람이 정한 목표 보다는 자신이 세운 목표를 달성하기 위해 더 열심히 일하기 마련이다.
개발자가 세우는 일정은 대체로 야심적이기 때문에 일정이 길다고 걱정할 필요는 없다(Cusumano and Selby 1995)

목표 설정

개발 기간을 목표로 잡으면 개발자들이 실제로 달성하기 위해 노력한다.
물론 전반적으로 합리적인 경우에 한해서다.
제럴드 와인버그와 에드워드 슐만은 목표가 개발자 성능에 미치는 영향을 조사하기 위해 재미있는 실험을 했다(Weinberg and Schulman 1974).
다섯 개발팀에게 동일한 프로그램 과제를 주고 동일한 목표 5개를 준 후에 팀마다 다른 우선순위를 줬다.
표 11-2는 실험 결과이다.

Table 11-2. Team Performance Ranked AgainstObjectives That Teams Were Told to Optimize

Objective that Team was Told	Memory Use	Output Readability	Program Readability	Minimum Statements	Minimum Programming Time
Memory use	1	4	4	2	5
Output readability	5	1	1	5	3
Program readability	3	2	2	3	4
Minimum statements	2	5	3	1	3
Minimum programming time	4	3	5	4	1

Source: “Goals and Performance in Computer Programming” (Weinberg and Schulman 1974).

다섯 팀 중 네 팀이 목표 1위를 차지했다. 다른 한팀도 2위이다.
두 번째 중요한 목표도 정해줬는데 세팀이 두 번째 목표에서 2위를 차지했다.
다섯 목표에서 모두 상위를 차지한 팀은 하나도 없다.

이 연구 결과는 개발자는 지시에 따른다는 사실을 잘 보여준다.
개발자는 성취 욕구가 강하므로 주어진 목표를 달성하려고 노력한다.
이는 목표를 분명하게 명시했을 때 한해서이다.

따라서 여러 목표를 동시에 만들어서 한꺼번에 모두 달성하는 건 불가능하다.
ITT에서 수행한 연구에서도 여러 목표가 주어질 때 생산성은 급격히 감소했다(Vosburgh et al. 1984)

성장 가능성

소프트웨어 개발의 흥미로운 점은 지속적인 변화이다.
최신 정보를 파악하려면 항상 배워야 하고, 현재 쓰는 지식은 3년 뒤면 구식이 된다.
이런 점을 고려하면 성장 가능성은 동기 유발 요인이라는 점은 당연하다.

회사는 개발자에게 프로젝트를 통해 성장할 기회를 제공해 동기를 유발할 수 있다.
이 경우, 회사 성장 목표와 개인 성장 목표를 조절할 필요가 있다.
베리 뵘은 이걸 다음과 같이 표현한다.

경력 개발 원칙에 따라 사원들이 성장하고 싶은 방향을 정하도록 보조하고, 그 방향으로 경력 개발 기회를 제공하려는 노력은 회사에 이익이 되는 일이다.
당연한 원칙이지만 반대로 행동하는 소프트웨어 회사가 의외로 많다.

회사는 다음의 방법으로 개발자의 직업적인 성장에 관심을 보일 수 있다.

• 전문지식 교육에 드는 학비 지원
• 교육이나 연구를 위한 시간 할당
• 전문서적 구입에 드는 비용 지원
• 기술력을 향상할 수 있는 프로젝트에 투입
• 새 개발자에게 지도 개발자 할당
• 과도한 일정 압력 회피

닛산은 서머나에 새 공장을 세웠을 때 교육비를 개인당 3만불을 책정했다고 톰 피터스가 Thriving on Chaos에서 언급했다 (Peters 1987).
생산성과 품질 면에서 상위 10% 안에 드는 회사를 조사한 결과, 평균적으로 소프트웨어 개발자에게는 1년에 2주, 소프트웨어 관리자에게는 1년에 3주 교육 기회를 제공한다고 밝혀졌다 (Jones 1994).
존 나이스빗과 패트리샤 어뷰든은 가장 우수하고 능력 있는 인재는 성장 기회를 주는 회사로 모여든다(Naisbitt and Aburdene 1985).

업무 자체

리처드 해크만과 그렉 올드햄은 내적 동기를 유발하는 일반적인 요인 세 가지를 제시한다 (Hackman and Oldham 1980).

• 업무에서 의미를 찾아야 한다.
• 업무 결과에 책임감을 느껴야 한다.
• 업무 활동이 가져다주는 실제 결과를 알아야 한다.

그리고 업무 자체를 다섯 가지 특성으로 나눠 설명한다.
첫 세 가지는 업무에 의미가 있다고 느껴지는 정도에 영향을 미친다.

• 기술 다양성은 업무 수행에 다양한 기술이 필요한 정도다. 이 특성은 지루함과 피로감을 덜 느끼게 한다.
• 업무 독자성은 완전히 독자적인 업무를 맡았거나 자신이 기여하는 바가 크다고 느낄 때 업무에 더 신경을 쓴다
• 업무 중요도는 다른 사람에게 미치는 영향이나 사회 복지에 기여하는 정도이다. 사람들은 최종 제품이 가치 있다고 느끼고 싶어한다.

넷째 특성은 업무 결과에 책임감을 느끼는 정도에 영향을 미친다.

• 자치권은 업무를 수행하는 데 필요한 수단이나 도구를 결정할 수 있는 정도이다. 책임감을 느끼는 정도와 자신이 가진 결정권의 범위를 말한다.

마지막 특성은 업무 활동에서 오는 실제 결과를 이해하는 정도에 영향을 미친다.

• 업무 평가도는 어느정도 분명하고 직접적인 평가를 받을 수 있는지를 말한다. 업무 자체, 즉 프로그램이 평가를 제공하므로 실행 유무를 통해 즉시 확인할 수 있다.

이 다섯 가지 특성을 조절해 의미 있는 업무를 만들고, 이를 성취욕이 큰 사람들에게 맡겨 동기를 유발할 수 있다.
로버트 자와키는 15년에 걸친 연구를 통해 개발자 동기 중 대략 60%는 적합한 업무 할당에서 생긴다고 했다 (Zawacki 1993).

소프트웨어 개발자는 일정 보다는 품질이 더 큰 동기를 유발한다.
기술을 선도하는 뭔가를 창조하는 일을 하기 원하므로 그 수준을 끌어올리는 프로젝트에 참가하고 있다면 높은 의욕을 가지게 된다.

업무 자체에 집중할 기회

사소한 행정 업무로 시간을 소모하면 주의를 분산시키므로 프로젝트에 도움이 되지 않는다.
비품실에서 노트 가져오는 절차, 복사기 쓰는데 걸리는 시간, 컴퓨터가 고장나면 대응하는 데 걸리는 시간, 업무에 필요한 모니터 구매 시간 등등은 의욕을 떨어드린다.
그 외 엄격한 복장 규정, 엄격한 업무 시간 등 개발 업무와 동떨어진 정책으로 주의를 분산시킨다.

개인 생활

관리자 입장에서는 뛰어난 개발자를 지명해 프로젝트에 투입하는 건 보상이라고 생각하고 개인 생활 감소에 대해서는 생각하지 않는다.
개발자 입장에서는 그런 책임 추가는 보상이 아니라 보복이며 개인 생활 감소가 일어나므로 손실이 일어난다.

개인 생활이 보장되도록 현실적인 프로젝트 일정을 세우고 휴가나 휴일을 지켜준다면 동기유발책으로 개인 생활을 사용할 일은 거의 없다.

기술 관리 기회

기술 업무를 관리할 기회는 다른 개발자를 이끌 만한 기술 수준을 성취했다는 뜻이다.

기술 관리 기회는 개발자에게 프로젝트 기술 수석을 맡기는 것만 뜻하지 않는다.
이 동기 유발 요인은 다음과 같이 더 생각해 볼 수 있다.

• 프로젝트에서 팀원에게 특정 제품 분야를 할당한다. UI, DB, Algorithm, Network 등
• 특정 공정 분야에서 팀원에게 기술 수석 임무를 맡긴다. 기술 검토, 재사용, 통합, 도구 평가, 성능 평가, 시스템 테스트 등
• 신참을 제외한 개발자 모두에게 지도 개발자 임무를 맡긴다.

11.3 기타 동기 유발 요인

포상과 장려금

개발자는 보상을 하지 않는 회사를 위해 일하는 데 싫증을 느끼게 된다.
따라서 장기적인 관점에서 포상은 중요한 동기 유발책이다.

금전적인 포상은 신중해야 하는데, 보상 액수가 노력에 상응하지 않으면 바로 알아챈다.
우수한 개발자들은 비합리적인 포상 시스템에 실망해 회사를 떠난다. (Boehm 1987a)

포상을 감사의 뜻으로 주는 태도 역시 중요하다.
성공적인 업무로 대가를 기대하는 사람들은 전혀 기대하지 않는 사람들보다 효율이 떨어진다고 밝혔다(Kohn 1993).
업무 자체가 동기를 유발하는 가장 큰 요인이다.

감사의 뜻을 표현할 수 있는 방법 몇 가지가 있다

• 특정 성과에 대한 진심어린 칭찬
• 팀 티셔치, 폴로 셔츠, 럭비 셔츠, 시계, 장식용 핀, 머그 컵, 포스터 등
• 액자, 선물권, 트로피 등 재미있는 포상
• 중요한 성과를 축하하는 행사, 좋은 식당에서 저녁 식사, 공연, 여행, 스키 여행, 상사 집으로 저녁 초대
• 예외적인 특별 대우: 금요일 평상복 출근, 탁구대 설치, 음료수 제공
• 특별 교육
• 컨퍼런스 특별 후원
• 등급 승진
• 특별 보너스

어떤 방식으로 표현하든 정말 중요한 것은 감사하는 마음이다.
장려나 조종이 아닌 감사를 나타내는 포상을 하라.

Figure 11-1.The well-appreciated software developer.

시험 프로젝트

수십 년 동안 호손 효과(Hawthorne effect)는 생산성 실험 결과와 소프트웨어 측정 자료를 헷갈리게 만들었다.

• 피험자가 자신이 실험 대상이라는 상황을 인지했을 때, 피험자의 업무 능률이나 결과가 향상되는 일종의 현상을 호손 효과라고 한다.

생산성 향상이 새 기술을 사용한 탓인지 아니면 호손 효과로 발생했는지 판단하기 어렵기 때문이다.
기술 수석이나 관리자 입장에서는 중요하지 않다. 어쨌든 원하는 결과를 얻을 수 있으면 되니까.

이 효과를 소프트웨어 프로젝트에 적용하는 방법은 다음과 같다.
프로젝트를 시험 프로젝트처럼 하는 것이다.
새 기술이나 방법론을 사용해 얻는 효과를 모을 수 있다고 하고 시험 프로젝트라고 알린다.
결론을 도출하지 못할 정도로 자료가 불충분해도 상관은 없다.
그래도 호손 효과는 얻을 수 있다.

하지만 동기 유발과 조종에는 엄연한 차이가 있다는 사실을 기억해야 한다.
개발자를 조종해서는 안 된다.

업무능력 평가

인텔 사장인 앤드류 그루브는 업무능력 평가가 상사가 수행하는 업무관련 평가 중 가장 중요한 방법이다 라고 말한다(Grove 1982).
또 업무능력 평가는 긍정적이든 부정적이든 부하 직원 역량에 오랫동안 영향을 미친다. 따라서 이는 관리자가 부하 직원을 격려하기 위해 가장 중점을 두어야 할 활동이다"라고 말했다.

에드워드 데밍은 미국에서 평가의 대부분은 형편없으며, 보통 관리자가 업무능력 평가로 인한 피해를 복구하는 데 반년은 걸린다고 말했다(Peters 1988).
그는 업무능력 평가를 부정적으로 수행하는 경향을 가장 심각한 관리 문제로 꼽았다.

1년에 한 두번 정도 평가를 수행한다면 효과 높은 기회를 충분히 활용하되 의욕을 꺽지 말고 동기를 유발하는 평가를 시행하라.

11.4 사기 저하 요인

1960년대 프레드 허즈버그는 동기 관련 요인을 두 가지로 분류했다(Herzberg 1987).
있으면 효율을 높이는 동기 요인(만족유발자)과
없으면 효율을 낮추는 위생 요인(불만유발자)을 구분했다.

위생 요인

소프트웨어 개발자에게 해당하는 위생 요인 목록이다.

• 적절한 조명, 난방, 냉방
• 충분한 책상과 책장 공간
• 집중할 수 있는 조용한 환경(예, 전화를 끌 수 있는 기능)
• 방해를 막을 수 있는 사적 공간
• 사무 장비(복사기, 팩스키 등)
• 사무용 비품 구비
• 컴퓨터 무제한 사용
• 최신 전산 장비
• 즉각적인 장비 수리
• 적절한 소프트웨어 도구 활용
• 적절한 하드웨어 활용
• 참고 매뉴얼과 관련 분야 논문 활용
• 참고 문헌과 온라인 도서
• 새로운 소프트웨어, 도구 방법론 사용시 기본 교육 제공
• 소프트웨어 정품 사용
• 전반적으로 자율적인 업무 시간과 업무 시간 유동성

기타 사기 저하 요인

*관리측 조종
개발자는 관리자에게 조종당하는 데 민감하게 반응한다. 그들은 문제에 정면으로 반응하는 편이며 관리층이 자신들을 솔직하게 대하기를 바란다.

가짜 기한을 내세워 개발자를 조종하려는 관리자가 가끔 있다.
설명 없이 특정 기한을 요구할 만한 타당한 이유가 있을 수도 있다 - 그냥 내려온 기한, 주식 공모를 위한 기한 등
이런 대답은 둘러대면서 조작하려는 것이고 개발자는 이런 태도를 수긍하지 않는다.
기한이 왜 중요한지 상세하게 설명해줄 수 없는 상황에 처한 관리자는 그로 인해 개발자 동기가 저하된다는 사실을 염두에 두어야 한다.

*과도한 일정 압력
결정된 일정이 여전히 비현실적인 경우가 있다. 개발자 사기를 완전히 꺾는 가장 쉬운 방법은 불가능한 일정이다. 불가능한 줄 알면서도 열심히 일하는 사람은 거의 없다. 특히 MBTI 성격 유형 중 감정보다 논리에 수긍하는 사고형은 더 그렇다.

*개발자 노력에 대한 보상 부족
개발자는 스스로 동기를 부여하고 오랜 시간이라도 힘든 일을 마다하지 않는 성향이 있다.개발자가 능력을 제대로 발휘하기를 바란다면, 열심히 일하는 개발자에게 절대로 열심히 하지 않는다고 말해서는 안 된다.

*기술적으로 무지한 관리자의 부적절한 개입
이해하지 못하면서 간섭하려고 하면 개발자 사이에서 비웃음거리가 될 뿐이다. 존경하지 않는 사람과 일하면서 의욕이 생기기 힘들다.

*관련 결정에서 개발자 소외
이런 일이 생기면 관리자가 개발팀을 신경쓰지 않거나 존중하지 않는다는 인상을 가지게 된다.
관리층이 개발자를 참여시켜야 하는 일반적인 경우는 다음과 같다.

• 새 일정 결정
• 새 기능이나 기능 변경 결정
• 새 팀원 고용
• 프로젝트 외 단기 업무에 개발자가 자발적으로 참여하도록 유도
• 제품 설계
• 기술적인 결정
• 사무실 이동
• 컴퓨터 하드웨어 교체
• 소프트웨어 도구 교체
• 시험용 제품 출시 약속
• 새 개발 공정 결정

관리자는 알아서 결정을 내려야 할 경우도 있지만 팀 사기를 꺾어서는 안될 의무도 있다.
가장 하지 말아야 할 건 결정을 내려 놓고 팀에 의견을 구하는 척 하는 것이다.
여기에 조종까지 하면 최악의 상황으로 가며 사기 저하 요인이 된다.

*생산성 장애물
팀이 장애물을 극복하느라 업무에 집중하지 못하는 상황을 만들면 안 된다.

*낮음 품질
개발자는 자신이 개발한 제품에 자부심을 가지게 마련이다.
주인 의식은 동기를 유발하고 그러려면 자부심이 있어야 한다.
짧은 시간에 품질이 낮은 제품을 개발한다면 자부심을 느끼기 어렵다.

여기서 관리자가 일정 문제로 품질을 낮추라고 요구한다면 주인 의식과 자부심의 동기 요인을 없애는 셈이 된다.
일정을 맞춰 개발을 하고 보너스를 받아도 낮은 품질로 괴로워하는 개발자도 있다.

관리자가 일정 내에 품질 요구사항을 만족할 수 없다고 판단되면 개발자들에게 결정하도록 한다.
그러면 개발자들은 구현 시간을 줄이는 설계를 택할 수도 있고 어쩔 수 없이 품질을 낮추는 결정도 할 수 있다.
이 방법은 품질이 낮은 제품을 개발하라고 강요하는 것 보다는 훨씬 낫다.

*서투른 동기 유발 행사
포스터, 구호, 입으로만 하는 격려는 도움이 되기 보다는 지적 수준을 모욕하는 것이다.
개발자에게는 가벼운 격려가 훨씬 효과적이다.

읽을 거리

개발자 동기 유발에 관한 책이다.

• DeMarco, Tom, and Timothy Lister. Peopleware: Productive Projects and Teams. New York: Dorset House, 1987.
• Weinberg, General M. Becoming a Technical Leader. New York: Dorset House, 1982.
  • 3장에 동기 유발을 가로막는 장애물과 다른 사람의 동기를 자극하는 방법을 다룬다.
• Weinberg, Gerald M. The Psychology of Computer Programming. New York: Van Nostrand Reinhold, 1971.
  • 10장에서 동기 유발을 다룬다. 나머지 장에서는 프로그래밍의 심리를 고찰한다. 개발자가 생각하는 방식을 이해하는 데 유용하다.

마이크로소프트가 활용한 개발자 동기 유발책이다.

• Cusumano, Michael, and Richard Selby. Microsfot Secrets: How the Worlds Most Powerful Software Company creates Technology, Shapes Markets, and Manages People. New York: Free Press, 1995.
• Zachary, Pascal. Showstopper! The Breakneck Race to Create Windows NT and the Next Generation at Microsoft. New York: Free Press, 1994.

동기 부여에 대한 일반적인 내용이다.

• Herzberg, Frederick. 'One More Time: How Do You Motivate Employees?' Harvard Business Review, September-October 1987, 109-120.
  • 이 계몽적인 기사는 위생 요인보다 업무 보강과 성장 요인에 초점을 두는 동기 유발을 논한다.
  • 1968년에 원문 출판, 1987년에 논평을 더해 재출판하였다.
• Peters, Tomas J., and Robert H. Waterman, Jr. InSearch of Excellence. New York: Warner Books, 1982.
  • 기술/비기술 직원의 동기 유발 방법을 알 수 있다.
• Hackman, J. Richard, and Greg R. Oldham. Work Redesign. Reading, Mass: Addison-Wesley, 1980.
  • 업무 자체에 관한 동기 유발 요인 소개.
  • 동기, 생산성, 품질 향상을 위해 업무를 재설계하는 기반 구조를 제시