팀을 이끌고, 나는 압도적입니까?


12

나는 나에게 매우 이상한 위치에있는 것입니다. 저는 직책에서 특정 프로젝트, 소프트웨어 엔지니어 선임의 "팀장"입니다. 내 팀에는 4 명의 개발자가 있는데 그 중 한 명은 다른 프로젝트에서 비슷한 역할을 수행하지만 이제는 내 작업에 우선 순위가 부여되었습니다. 또한 2 명의 테스터가 있는데 그 중 하나는 관리자입니다. 팀의 다른 구성원은 완전히 관련이없는 부서의 일부인 "고객 담당자"입니다. 나도 바로 위에있는 관리자가 있고 팀의 일부인 테스트 관리자 위에도 있다고 생각합니다.

내 역할이 정확히 여러 번인 이유를 명확히하려고 노력했습니다. 내가 가지고 있다면 내 권위가 어디에서 시작하고 끝나는 지 알아내는 것은 어렵습니다. 현재 작업중인 답변은 팀의 "기술적 리더"입니다. 이것은 제품 코드 자체와 관련된 아키텍처, 디자인 및 프로세스 / 코딩 표준에 관한 기술적 결정에 대한 나의 권한이 나의 권한임을 의미하는 것 같습니다.

오늘 뭔가가 나타 났고 코드 결과는 우리 팀의 구성원 중 한 명에게 위임하여 Scrum show-it-all-off 회의에서 회사의 다른 사람들에게 보여주었습니다. 고객 담당자가 과시합니다. 오늘 내가 정말로 동의하지 않았으며, 무슨 일이 있었는지에 대해 이야기하고 싶은지 아무도 묻지 않았다는 것이 오늘 밝혀졌습니다. 즉, 사용자가 다음과 같은 방식 ( "doc"단위, 디자인 단위, 반올림, 반올림하지 않음)으로 보고서에 값을 표시 할 수있는 기능을 제공하기 위해 각 순열에 대한 액세스 필드를 제공했습니다. 따라서 우리는 반올림 된 문서 단위, 반올림 된 디자인 단위, 반올림 된 문서 단위, 반올림 된 설계 단위의 가치를가집니다. 사용자가 작업하고자하는 각 레코드에는 많은 값이 있으며 각 레코드는 이러한 방식으로 변경됩니다.

나는 정말로 이것을 싫어한다.

우리가 보고서에 사용하는 API가 Excel로 데이터를 내보내는 것과 같은 방식과 동일한 지 확인하기 위해 이것을 보여 주었던 사람들. 불행하게도, 지금 우리는이 운동량이 실제로 아주 나쁘다고 생각되는 방향으로 얻고 있습니다.

나는 다음 회의에서 약간 화를 냈고 나는 이것을 한 두 사람에게 물었다. "왜이 결정에 관여하지 않았습니까?" 계속 문제가되고 있으며, 내가 참여하고 싶은지 물어 보도록 이끌고있는 팀원을 데려 오는 것이 어려운시기입니다. 때때로 나는 그렇지 않으며 그들이 생각하는 것은 괜찮을 것이라고 생각합니다. 다른 시간에. 사람들이 나에게 묻지 않는 한 내 의견이 필요한 일이 일어나고 있다는 것을 알기가 어려우며 그 기회를주지 않습니다.

불행히도, 나의 권위는 사람들에게 "다음에 나에게 말도하지 않고 혼자서 이런 일을 할 때 징계를받을 것"이라고 말하지는 않습니다. 그것은 내 권위의 범위에 있지 않은 한 가지 영역 인 "PR"문제입니다. 다른 사람이 기꺼이 그런 종류의 쓰레기를 다루고 싶지 않기 때문에 실제로는 괜찮습니다.

그러나 오늘, 모든 사람 앞에서 내 관리자 (내가 부분적으로 그렇게 생각하기도 내 잘못이라고 생각합니다)는 모든 결정에 참여할 수 없으며 위임해야한다고 말했습니다.

물론 나는 내가 옳다고 생각합니다. ... 항상 그렇습니다. 나는 BS라고 생각하는 것을 말하지 않습니다. 나는이 문제에 대해 접근하고 더 좋은 아이디어가 있는지 물어야한다고 생각합니다. 이것이 실제로 새로운 기능의 시작 단계 였기 때문에 현재 제공 할 하나의 가치를 결정하고 원하는 경우 향후 추가 액세스를 제공하기위한 옵션에 대해 논의하기위한 나의 방향은 실제로 하나의 가치를 결정하는 것이 었습니다. 나는 현재 구현을 승인하거나 권장하지 않았으며 실제로 그것이 오늘날의 빛을 보았을 것이라고 생각하지 않습니다.

문제는 내가 불합리한 사람인가?


글쎄, 우리 둘은 그것에 대해 이야기하고 우리가 "공을 떨어 뜨렸다"고 동의했고 같은 페이지에있는 것 같습니다. 월요일 아침 ... 팀에서 내 역할이 명확 해 지도록 노력할 것입니다. 그리고 그래야 할 디자인 또는 작업 변경이있을 때 결정해야합니다. 나는 더 깊이 보일 필요가 있다고 제안하고 동의하거나 결정합니다. 그런 다음 그들이 나에게 올 수 있음을 알기 위해 노력할 수있는 다른 비트가 있습니다.


1
이것이 고객이 원하는 것처럼 고객 담당자가 제시했다면, 당신은 불합리한 것입니다. 그들이 한 일이 미래에 실제로 원하는 것을 얻지 못하도록 막는 것 (있는 경우)을 만들어야합니다. 돈으로 표시 할 수 있다면 (즉, 그들이 당신의 방식대로한다면, x 달러로 절약 할 것입니다) 당신은 영웅이 될 것입니다.
Robert Harvey

1
@ 로버트-나는 한 가지 경고에 동의합니다 ... 나는 그것이 보여지기 전에 참여해야한다고 생각합니다. "아니요, 이런 식으로하지 말고 여기에 이유가 있습니다."라고 말할 기회가 있었어야한다고 생각합니다. 내가 다른 사람들이 아무리 잘못해도 내가 기각한다면 그것은 바로 그 길입니다. 나는 그것을 인식하고 그와 함께 산다. 내 문제는 아마도 "리더"인 동안 기회를 얻지 못하는 것입니다. 당신은 여전히 ​​그것을 불합리하다고 생각하십니까?
Edward Strange

8
나는 당신이 상황에 대한 당신의 설명에 근거하여 당신이 리더 인 것으로 인식되지 않는다고 생각합니다. 좋은 예를 만들기 때문에 제안을 진지하게 고려하는 '예를 들어 리더'가되어야합니다. 특정 권한이 부여 된 경우에도 마찬가지입니다.
Robert Harvey

@Crazy-아닙니다. 무리한 것은 아닙니다. 그것이 리더의 목표입니다.
quick_now

1
존중은 얻어지고 집행 될 수 없다는 것을 기억하십시오. 당신이 올바르게하면 그들은 당신을 결국 따라갈 것입니다.
팔콘

답변:


17

소스 커밋을 모니터링해야 할 것 같습니다. Perforce는 기본적 으로이 기능을 가지고 있으며 Git은 후크를 통해 다른 기능을 가지고 있습니다. 모든 커밋을 nitpick 할 필요는 없지만 적어도 알림과 diff를 가하면 프로젝트에 들어가는 모든 것을 간략하게 엿볼 수 있습니다.

관리자가 위임해야한다고 말하면서 4 명의 개발자로 구성된 팀과 동의 할 것이라고 확신하지 못합니다. 더 이상, 나는 그 (또는 그녀)와 사이딩을하고 있을지도 모른다. 물론 위임 된 작업에서도 설계 변경 등에 대한 상태 업데이트 또는 연습을 요청해야합니다.

아무것도 부정적한다 이제까지 회의에서 제기 할 수 - 소리가 당신과 당신의 관리자 모두가이 일에 공을 떨어 좋아한다. 당신이 수의 절대 최악의 일은 그 어느 피어에 어떻게 그들을 당황입니다. 리더로서 (매니저와 마찬가지로) 접근 가능하고 신뢰할 수 있어야합니다. 벨 리틀 링은 분노를 불러 일으켜 팀을 이끌 수있는 능력을 손상시킬 수 있습니다.

나는 주도적 인 역할을하는 사람으로부터 "징계"라는 단어를 듣는 것이 싫습니다 . 징계 (적어도이 맥락에서)는 부정적이며 생산적이지 않습니다. 다른 사람 (개인이 있고 회의 환경이 아님)과 함께 일하면서 이유 를 알아 내고 제안 된 솔루션에 동의하지 않는 경우 대안을 제공하는 것이 수행되어야합니다. 때때로, 당신은 당신이 일하는 사람이 옳고 장 직감이 잘못되었음을 알게 될 것입니다. 왜? 그들은 당신보다 그 특정한 문제에 더 많은 시간을 보냈습니다.

저를 걱정하는 다른 것은 "항상 옳다고 생각합니다"입니다. IMO, 그것은 모든 리드에서 가능한 최악의 태도입니다. 당신 분명히 자신의 능력에 자신감을 가져야 하지만, 만약 당신이 특정한 문제에 깊이 빠져 있지 않다면, 그보다 더 자주, 당신의 제안은 (어떤 경험이 있든지 상관없이) 뒤에서 나오고 그렇지 않을 수도 있다는 것을 인식하십시오 최고가 되십시오. 사람이하면 되는 특정 문제에 집중 대안을 제공합니다, 그것은의 당신 을 (자신의 경험 수준에 따라, 그들의뿐만 아니라 잘) 작업 증명 당신이 더 나은 이유는 단지 내가 리드 해요 "말과하지에, 나는 항상 내가 옳다고 생각합니다. "당신의 문장이 저를 믿게합니다.

마무리하려면

그렇습니다. 당신은 어떤 점에서는 불합리하지만 다른 사람들은 그렇지 않습니다. 리드로서, 적어도 당신에 의해 전달 된 기능이나 구조적 변화가있을 것으로 예상됩니다.

그러나 전체 시스템 및 코드 품질을 보장하는 것도 본인의 일입니다. 귀사는 코드 검토를 수행합니까? 프로그래머가 코드에 들어가기 전에 작업중인 것을 디자인하도록 하시겠습니까? 그렇지 않은 경우 이러한 종류의 품질 관리 메커니즘을 사용하는 것을 고려해 볼 수 있습니다.


코드 검토 및 사전 디자인을 구현하려고했습니다. 내가 위에 애도했던 것들을 포함하여 여러 가지 이유로 인해서도 운동하지 않았습니다. 또한 우리를 늦추지 않는 방법을 알아내는 데 어려움을 겪었습니다. 문제의 또 다른 부분은 사람들이 코드를 비판 할 의사가없는 것처럼 보였습니다. 또한 여러 사람이 프로젝트의 어려운 부분에 대한 아이디어 / 디자인을 생각해 보았습니다. 불행히도 내 것이 항상 우리가 사용했던 것이었기 때문에 그것이 실망 스러울 수 있다고 생각합니다. 둘 다 우리가해야 할 일 (및 단위 테스트도 필요합니다)이지만 문제가 있습니다.
Edward Strange

어떤 제안? 많은 시간을 소비하지 않고 어떻게 코드 검토를 할 수 있습니까? 팀의 다른 구성원이이를 평가하고 (단위 테스트도) 어떻게 할 수 있습니까? 큰 문제인 것 같습니다. 우리가 더 나아질 것이라고 생각할 때 모두를 느리게하는 바쁜 일을 많이 할당하는 것 같습니다. 나를 위해 하나의 큰 문제는이 위치에 멘토링 된 적이없는 것입니다. 지금은 오랜 시간을 보냈지 만 더 나은 작업을 수행하는 대신 연구, 시험 및 실패로 배웠습니다.
Edward Strange

2
-나를 걱정하는 다른 것은 "나는 항상 옳다고 생각한다"입니다.-나는 당신의 모든 요점을보고 그들에 동의합니다. 약간의 비난적인 유머와 혼합 된 표현의 선택이 잘못되었습니다. 머리카락이 위로 향하지 않도록 노력합니다.
Edward Strange

코드 검토 속도를 높이는 데 사용할 수있는 몇 가지 도구가 있습니다. 웹 기반 도구가 잘 작동하는 것 같습니다. ostatic.com/blog/open-source-code-review-tools 에서 OS 프로젝트 목록을 찾을 수 있습니다 . 물론, 검토를 성공적으로 수행하는 데 있어 가장 큰 요소는 책임 입니다. 검토자는 자신의 검토에 대해 책임을 져야합니다.
Demian Brecht 2016 년

1
실제로 팀이 수행하는 작업과 출력에 대해 자부심을 갖도록해야합니다. 자신의 이름이 리뷰에 부착 그들이 변화에 무슨 일이 일어나고 있는지 승인 한 광고 소재으니 것을 알고 해야한다 (물론 그들이 할 수 적어도이나)도 자신의 일을하도록지도한다. 그렇지 않은 경우, 아마도 약간의 멘토링이 (개인적으로, 다시) 순서에 .. 알아 그들은 그들이있는 거 검토 신경과, 코드 품질 (리뷰의 중요성을 강조 낮은 버그에 포함되지 않습니다, 기타).
데미안 브레히트

9

당신은 관리를 위해 체크 아웃 될 수 있고, 그렇다면 당신이 실패하고 있습니다 (나쁘지 않을 수도 있습니다; 우리 중 많은 사람들이 좋은 개발자이고 나쁜 관리자 일 것입니다. 그리고 나는 프로그래머를 관리하는 것보다 훨씬 프로그램을합니다).

관리자는 종종 자신이 기대하는 모든 것에 대한 권한을 갖지 못합니다. 어쨌든 일을 끝내는 것은 훌륭한 관리자의 신호입니다. 징계 조치를 취하지 않고 사람들이 일을하도록하는 방법을 찾아야합니다. (참고 : 공개적으로 사람들을 비난하는 것은 아닙니다. 공개적으로 칭찬하고, 사적으로 비판하고, 부하 직원들에게 관심을 보이는 사람들을 찾으십시오.)

또한 관리자는 아프더라도 위임해야합니다. 이 문제를 직접 작성하는 것보다이 문제를 처리하는 데 더 많은 시간을 할애 할 가능성이 있습니다. 일단 당신이 그것을 다루었다면, 그 일을 한 사람들은 무언가를 배워야했고, 그들은 미래에 잘못된 일을 할 가능성이 적습니다.

이와 같은 문제를 처리하는 올바른 방법은 개인용으로 먼저 개발자에게 왜 그런 식으로 표시했는지 묻습니다. 당신이 옳고 그들이 틀렸다고 가정한다고해서 회의에 있지 않은 것. 그들에게 설명 할 기회를주십시오. 그렇다고해서 결정을 내려야한다는 것은 아닙니다. 결국 당신은 기술 책임자입니다. 그것은 당신이 그들에게 당신의 방법을 제시 할 이유를 제시해야한다는 것을 의미하며, 당신은 그 개인 회의에서 나타나는 근본적인 문제를 해결해야합니다.

또한 관리자는 직원들로부터 나오는 것에 대한 책임이 있습니다. 특히 고객 앞에서하는 일에 눈을 멀게하지 마십시오. 코드 체크인을 추적하거나 개발자와 빠른 미니 회의를하는 것이 필요할 수 있습니다 (주의해야하지만 영역에있을 때 중단하지 않으려는 경우). 고객 담당자와의 회의 전에 오후에 모든 개발자와 대화해야합니다.


나는 그것이 가능하다고 생각하지만 실제로는 의심합니다. 우리는 방금 관리자를 고용했고 같은 직책을 신청할 때 CEO가 옆으로 빼앗 았습니다. 내 강점에 따라 플레이하는 위치를 보지 못한다는 것이 분명합니다. : PI는 연마가 가능합니다. 새로운 남자를보고 난 후 평가에 동의해야합니다. 그의 정치적인 행동과 외교는 똥을 끝내는 것입니다.
Edward Strange

"매니저는 종종 자신이해야 할 모든 일에 대한 권한을 갖지 못합니다. 어쨌든 일을 끝내는 것은 좋은 관리자의 신호입니다." 그렇습니다. 나는 항상 내가 할 수있는 한 내 권위를 늘리고 어떤 일이 일어나는지 보는 태도를 취했습니다. 헤매지? 글쎄, 나는 한계가 어디에 있는지 발견했다. 그래도 이렇게하는 것-틀린 것보다 더 자주 옳 아야합니다. 불행히도, 리드 / 매거진 입장의 다른 측면은 일부 사람들은 정말 다루기 힘든 평범한 사람들이며, 모든 삶에서 어떤 이유로 든 적응할 수 없을 때 매우 어려워진다는 것입니다.
quick_now

4

개인적으로 가져 가지 마십시오

팀 노력입니다. 프로젝트의 유일한 사람이 아니라 기술 책임자. 팀이 실수로부터 배우거나 프로세스를 변경하는 데 중점을 두어야합니다.

지도하고 배우십시오

기술 리드를 포함한 모든 리더십 직책의 일부는 귀하가 가진 사람들과 함께 최선을 다한다는 것을 이해하는 것입니다. 팀이 함께 일할수록 일을 제기 할 때와하지 않을 때를 더 많이 알게됩니다. 팀에게 지시하는 함정에 빠지지 않도록하십시오. 무엇이 잘못 되었고 매주 무엇이 잘 되었는지 검토하십시오 . 다른 일을하려는 경우 팀과 의사 소통하십시오. 징벌 조치는 항상 최후의 수단이어야하며 일반적으로 누군가를 해고해야하거나 귀하의 역할에 실패했음을 의미합니다.

고객 프리젠 테이션 전에 검토

프로젝트의 리더가 왜 기능과 구현이 제시되기 전에 검토하지 않았습니까?

틀렸다면 고치세요

왜 문제가 있는지 명확하게 설명하고 변경하십시오. 더 비싸지 만 실제로 잘못되면 수정하십시오. 틀린 것이 아니라면, 원하는 일과 다른 방식으로 다시 한 번; 프로젝트에서 일하는 유일한 사람이 아니라는 것을 이해하십시오.


3

구현해야 할 사항을 문서화 한 사양이 있습니까? 지나치게 개방 된 요구 사항이 주어지면 개발자는 종종 자신이 적절하다고 생각하는 것으로 공백을 채우거나 소액 관리가 필요합니다.

"당신은 사양의 내용을 다루는 대신에 대신 [기능]을하기로 결정했습니다. 이제 처음에는 승인되지 않은 기능 때문에 뒤처졌습니다."

그런 다음 개발자가 다시 할당되면 기능을 스크러빙하는 작업을 시작할 수 있습니다.

편집> 아니, 난 당신이 압도하고 있다고 생각하지 않습니다. 그들의 일은 결국 당신의 엉덩이가됩니다.


글쎄, 그것은 행해진 일을하지 말라고 말하지 않았다는 사실로 끝났습니다. 작업 중이었던 모든 이야기는 문서 단위로 보고서에 값을 가져 오는 것이 었습니다. 다른 누군가가 어딘가에 동의 할 수도있는 것보다 더 많은 것을 필요로하기로 결정했습니다. 제가 해킹을 귀찮게하는 것은 "나는 정말로 당신이 그렇게해야한다고 생각하지 않을 것입니다. 그런 식으로."
Edward Strange

@Crazy Eddie : 당신은 또한 앞으로 생각하는 방식으로 접근 할 수 있습니다. 기능을 제거 / 교체해야 함을 나타내는 버그를 작성하고 처음에 기능을 작성한 개발자에게 할당하십시오. 그런 다음 버그를 수정하는 것과 마찬가지로 비즈니스입니다.
Steven Evers 2016 년

2

나는 종종 자신이 같은 입장에 있다는 것을 알게되었고, 회의에서 토론을 올리는 것은 아무 데나 가지 않는 것 같습니다. 때때로 나는 내 결정을 내리지 않기로 결정하기 전에 최후의 수단으로 (내가 아닌) 자신의 이유와 함께 이것을 흑백으로 알리는 이메일을 관련 당사자에게 보냅니다.

그런 다음 해당 이메일을 보관하여 관리자 나 고객이 왜 그런 식으로 일을했는지 ​​또는 변경으로 인해 많은 비용이 드는 이유를 물을 때 나중에 참조 할 수 있도록 이메일을 보관합니다.


+1 : 이것을 "흡연 총 파일"이라고합니다. 그 물건을 인쇄해서 집에 보관하십시오.
quick_now 2012 년

2

나는 당신이 인정한 것처럼, 당신이 그랬던 것처럼 그것을 제기하는 것이 잘못되었다고 생각합니다. 이 수준에서 디자인에 대한 의견을 제시해야한다고 말하는 것은 틀리지 않지만 합리적인 구현 방법을 잘 모르겠습니다. 사람들이 간단하다고 생각하면 디자인을 실행하지 않을 것입니다. 그들이 디자인 자체에 대해 할 수있는 것처럼 쉽게 직설적이기 때문에 쉽게 잘못 될 수 있기 때문에, 당신은 사람들이 당신에게 그들의 모든 잘못된 디자인을 보여주기 위해 자원하는 것을 발견하지 못할 것입니다. 이 시점에서 나는 당신의 작업 습관과 의사 소통 패턴에 대해 대부분 궁금하지만, 실제로 어떤 일을 하든지간에 당신은 이러한 것들에 의해 눈을 멀게 할 것입니다. 모든 커밋을 부지런히 검토하지 않아서 어떻게 이것을 증명하는지 잘 모르겠습니다.


1

나는 너무 감정적으로 이렇게 느낀다.

 I of course think I'm right....I always do. 

그러나 나는 때때로 내가 틀렸다는 것을 지적으로 알고 있습니다. 나는 또한 언제 싸움을 선택할지 알고 있습니다-당신은 모든 것에 대해 논쟁 할 수 없으며 때로는 당신의 예기치 않은 합의가 놀라운 일을 할 수 있습니다.


나는 항상 누군가가 나를 잘못 증명하거나 내가 있다고 확신하도록 허용합니다. 나는 그것이 끝날 때까지 내가 옳다고 생각하는 경향이있다. : P
Edward Strange

1

진정한 지도자는 무엇입니까?

하위 직원, 모든 하위 직원을 해고 할 수있는 사람입니다 . (하지만 새로 고용 할 필요는 없습니다)

때때로, 대부분의 사람들은 어떤 프로젝트의 리더로 "태그"되어 있지만, 불의 힘이 없으면 진정한 리더보다 "지도"/ "교사"가 더 많습니다.

그러나 팀 리더가 될 수는 있지만 현재 프로젝트를 이끌지는 못할 수도 있습니다. 최악의 경우는 고객이 프로젝트를 주도 할 때입니다. 이 시점에서 프로젝트가 실패하면 실패 할 것입니다.

최악의 경우는 프로젝트의 두 리더가 존재하는 경우입니다.

군대로서, 일련의 명령은 모든 것입니다 ( "프로젝트를위한 다이"만큼 급진적이지는 않지만 충분히 가깝습니다). 이 문제에 대해 귀하의 관리자는 귀하의 지위를 어 기고 "귀하의"사람들의 도덕을 낮추었으며 전혀 도움이되지 않았습니다.


1

그렇습니다. 상사는 옳 습니다. 모든 결정에 관여 할 수는 없습니다 . 실제로 모든 것을 직접하지 않으면 이와 같은 모든 것을 잡을 수 없습니다. 나는 그것이 당신이 어디에서 왔는지 생각합니다-당신은 모든 작은 세부 사항에 관여하지 않는 한 전체 프로젝트를 잘 처리 할 수는 없다고 생각하지만, 당신을 압도하지 않고 모든 작은 세부 사항에 관여 할 수는 없습니다. 팀과 아마 당신을 태워).

해답은 항상 잘못되는 것에 대해 걱정하지 말고 건설적인 방식으로 나중에 수정하는 것에 대해 걱정하는 것입니다.

의사 소통을 계속하면 위임 할 수있을뿐만 아니라 고위 사람들이 리뷰, 토론 및 잘못된 통제 시도로 사람들을 항상 붙 잡지 않고 필요한 것을 수행하도록 할 수 있습니다. 그들이 옳은 일을하도록 믿으십시오. 그리고 무슨 일이 일어나고 있는지에 대해 '채팅'을하도록하세요.


0

몇 가지 문제가 있습니다. 먼저 관리자가 팀과 협력하여 더 위임하도록 지시했습니다. 이는 팀을 이끌 수있는 능력에 대한 자신감이 부족함을 나타냅니다. 실제로 기술 책임자의 제목을 가지고 있지만 실제로는 권한이 없기 때문에 기술 책임자가 아닙니다. 당신은 당신의 관리자와 함께 앉아서 이것에 대해 마음을 가질 필요가 있습니다. 관리자의 지원없이 그리고 팀의 동의없이 팀이 내린 디자인 결정을 변경할 권한이 없으면 기술적 인 리더 위치에서 성공할 수 없습니다. 귀하는 귀하의 업무를 수행 할 권한이 없습니다. 상사는 당신이 승리하지 않은 입장에 있고 더 나아지려면 대중의지지를 받아야한다는 것을 이해해야합니다. 권위없는 책임은 자신을 찾을 수있는 최악의 상황입니다.

다음으로 팀이 눈을 멀게했습니다. 당신은 그들과 이것을 이야기해야합니다. 개발 전에 그리고 공개 프레젠테이션을하기 전에 디자인 토론을해야합니다. 디자인의 일부를 위임해도 괜찮습니다 (심지어 당신이 위임해야한다고 생각하는 것을 결정할 수는 있지만). 그들은 당신을 눈 멀게하여 당신의 신뢰를 잃었습니다. 이제 그들은 더 나은 행동을 배워야합니다. 그들이 당신을 다시 눈을 멀게하지 않는지 확인하기 위해 자주 확인해야하며, 만약 그렇다면, HR에 문제를 공식적으로보고해야합니다. 개발자가하지 말라고 의도적으로 의도적으로 주변을 돌아 다니면 결과는 가치가 있습니다. 그렇지 않습니다 그들이 당신을 좋아하는지 아닌지에 상관없이 그들이 당신을 존중하지 않는 순간에 명확하게 말입니다. 부적절한 행동에 대한 결과가 필요합니다. 그렇지 않으면 악화 될 것입니다. 그러나 관리 지원 문제를 해결할 때까지 문제의이 부분을 해결할 수 없습니다.

다음으로 공개적으로 폭파했습니다. 공개적으로 사과해야합니다. 이것은 당신이 명성을 되 찾는 데 도움이 될 것입니다.

그런 다음 각 사람들을 개인적으로 따로 가져 가서 계속 나쁜 행동에 대한 결과를 말해야합니다 (한 번 관리자에게 결과를 줄 수 있도록 동의 한 경우). 대중의 칭찬과 지원, 사적인 비판이 당신의 규칙이어야합니다. 당신은 또한 당신의 눈을 멀게 할 수 있도록 그룹 nmeetings 밖에서 더 자주 그들과 함께 체크인해야 할 수도 있습니다.

솔직히 위와 아래의 사람들은 당신이 무시 당하고 정보를 유지할 수없는 사람이라고 분명히 생각하기 때문에 진지한 영혼이 자신을 무례하게 만드는 원인을 스스로 찾아야합니다. 또한 기술 책임자가 더 행복하지 않을지 또는 책임을 맡을 수있는 권한이있는 곳으로 이동해야하는지 결정해야합니다. 당신이이 자리에 머무르기를 원한다면, 사람들이 왜 당신을 그렇게 잘 대하지 않는지에 대해 당신과 같은 수준을 유지하도록 요청해야 할 것입니다. 그것은 고통스럽고 아마도 대답을 듣고 싶지 않을 것입니다. 그러나 그들이 당신을 분명하게 인식하는 방식으로 왜 인식되는지 알아야합니다.


눈을 멀게 했습니까? 슬픔, 당신은 관리자에게 모든 세부 사항을 요구하고 모든 작업에 동의해야한다는 점에서 어떤 종류의 땀을 흘리는 조직을 운영하고 있습니까? 그것이 그의 매니저가 아니었다면, 그의 팀 전체가 그만두고 싶어하는 것을 쉽게 볼 수 있습니다.
gbjbaanb

@ gbjbaanb, 디자인 문제는 세부 사항이 아니며 즉각적인 것 이상으로 영향을 미칩니다. 디자인은 그들의 책임이 아닙니다. 그들은 의도적으로 그들의 권위를 비판했고 (그리고 처음이 아니었던 설명에서) 그것을 열심히 헤쳐 나갈 자격이있다.
HLGEM

1
@gbjbaanb-그것은 또한 나아갈 시간을 결정했기 때문에 고용주에게 매우 어려울 것입니다. 나는 훌륭한 지도자가되기를 원하며 많은 것을 알고 있습니다. (그 이유는 내가 그 자리에있게 된 이유입니다), 어떤 멘토도 가지지 않고 그것에 던져지는 것은 제게 재앙이었고 끊임없이 좌절했습니다.
Edward Strange
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.