Tôi là một quản trị viên linux gắt gỏng, người viết rất nhiều kịch bản, và tôi nhận thấy rằng tôi có kỹ năng giao tiếp kém. Tôi nghe rất giống anh chàng của bạn. Trên thực tế, đó là lĩnh vực duy nhất tôi nhận được trong các bài đánh giá hiệu suất. Mặt khác, tôi liên tục dẫn dắt nhóm của mình trong việc đổi mới và giải quyết vấn đề, và đã tạo ra và dẫn đường đến nền tảng mới mà chúng tôi triển khai và đã tiết kiệm cho nhóm của tôi rất nhiều thời gian và công ty của tôi rất nhiều tiền bằng cách được phép là chính mình
Sếp cũ của tôi đã được yêu cầu gia đình / vợ của anh ấy VÀ quản lý cấp cao của công ty chúng tôi rời khỏi vị trí của anh ấy .... đồng thời. Anh ấy làm việc không mệt mỏi để cân bằng các trách nhiệm một cách công bằng và tự mình gánh vác rất nhiều tải trọng. Trong bất kỳ tương tác với bất kỳ ai bên ngoài bộ phận, nếu có một sự hiểu lầm trong giao tiếp đã trở lại với anh ta, anh ta đã nhanh chóng, ah, trừng phạt nó một cách trừng phạt. Anh ta rất kém trong việc "quản lý trở lên", vì vậy nhóm của chúng tôi là người cuối cùng nhận được tài nguyên cho đến khi nó là một trường hợp khẩn cấp, và sau đó công ty đã trả tiền cho các nhà cung cấp với các mức bán hàng lắt léo cho phần cứng chưa được kiểm tra mà không hỏi ý kiến nhóm sẽ sử dụng các công cụ đó. Trong nỗ lực tạo ra một nhóm "cân bằng tốt", anh ấy đã vi mô hóa danh sách nhiệm vụ của chúng tôi và cố gắng cân bằng các nhiệm vụ để các thành viên trong nhóm có thể cải thiện bộ kỹ năng của họ ở những nơi họ không tuyệt vời, dẫn đến RẤT NHIỀU mã bị hỏng hoặc triển khai kiến trúc kém. Trong khi những người khác ngoài tác giả được giao nhiệm vụ hỗ trợ cụ thể cho mã bị hỏng đó để họ có thể "học" - việc triển khai, mã và kiểm tra được kiến trúc kém tạo ra rất nhiều thiện chí kém giữa các thành viên trong nhóm và thực sựsự xuất hiện gia tăng của "trò chơi đổ lỗi", đó là một con đường nhanh đến trạng thái đội độc hại.
Sếp hiện tại của tôi là một cá nhân điềm tĩnh, thu thập, xuất thân từ vai trò quản trị viên cơ sở và đã làm việc theo cách của mình. Anh ấy đưa ra quyết định tốt và dựa nhiều vào các thành viên trong nhóm để đặt ưu tiên của riêng họ. Anh ấy là một người giao tiếp tuyệt vời và phản ứng bình tĩnh và phối hợp với người giám sát của anh ấy với bất kỳ vấn đề, ý tưởng hoặc nhu cầu giao tiếp nào được thể hiện bởi nhóm của tôi. Anh "làm việc trở lên" không mệt mỏi. Anh ấy chậm chạp trong việc thay đổi kiến trúc lớn, và tư vấn kỹ lưỡng với toàn bộ đội trước khi thay đổi môi trường của chúng tôi và thoải mái dựa vào các đặc sản của các thành viên trong nhóm.
Theo người quản lý mới, thời gian chết của chúng tôi đã giảm xuống gần như bằng không (điều này cũng đã giảm phần trăm thời gian chúng tôi dành cho các nhiệm vụ hỗ trợ từ khoảng 40% xuống còn khoảng 10%), sự hài lòng của nhóm chúng tôi đã đi qua mái nhà, và chúng tôi trên đường đã chuyển từ 'phá vỡ ngân hàng trên phần cứng mới cứ sau ba đến năm năm' sang một kế hoạch mua lại liên tục sẽ giúp công ty tiết kiệm được một triệu đô la mỗi năm trong vòng năm năm. Kế hoạch đó là một chương trình cơ sở chưa từng xảy ra dưới thời người quản lý trước nhưng được người quản lý mới tích cực đẩy lên quản lý cấp cao và phụ thuộc vào việc tìm kiếm RẤT NHIỀU hiệp lực trong bộ kỹ năng của đội. Chúng tôi đã được CIO thông báo một cách không chính thức rằng chúng tôi hiện là nhóm duy nhất trong công ty thực sự "có chung sở thích" và anh ấy ' Sẽ can thiệp vào môi trường làm việc của chúng tôi càng ít càng tốt và xáo trộn càng nhiều tài nguyên đối với các khu vực có vấn đề mà chúng tôi xác định càng tốt. Điều này đã thành sự thật và nó khiến cho "chi phí" hỗ trợ của chúng tôi thậm chí còn thấp hơn, mặc dù nó đã phá vỡ khối lượng công việc của một số nhóm khác - nhưng điều đó cũng khiến chi phí hỗ trợ của các đội đó thấp hơn.
Hãy nhìn xem, nơi để các nhà phát triển cải thiện bộ kỹ năng của họ là ở trường hoặc vào thời gian riêng của họ. Nơi để họ sản xuất mọi thứ là vào thời gian của công ty bạn. Cách tốt nhất để sản xuất mọi thứ là bằng cách sản xuất những gì họ biết tốt nhất. Khi làm việc trong các khu vực mà một nhà phát triển không thoải mái, họ nên tìm kiếm một nhà phát triển thứ hai chuyên về và làm việc theo nhóm hoặc nhà phát triển chuyên ngành nên viết mã và tạo tài liệu và sơ đồ. Định tuyến nhiệm vụ hỗ trợ cho những người đã viết mã. Có, điều này làm tăng cái mà chúng tôi gọi là "yếu tố xe buýt" của bạn - khả năng bộ phận của bạn gặp sự cố về tốc độ nếu chuyên gia nên bị xe buýt đâm. (Hoặc bị sa thải, hoặc chuyển đổi công việc, hoặc ...) Sự thật của nó là sự suy giảm năng suất của bạn từ nỗi sợ hãi đó là những đơn đặt hàng có cường độ cao hơn so với tổn thất thực tế khi "sự kiện xe buýt" xảy ra. Điều thường xảy ra trong một "sự kiện xe buýt" là người thừa kế công việc của chuyên gia làm lại nó bằng hình ảnh của chính mình để anh ta có thể hỗ trợ nó một cách hiệu quả nhất, nói chung là giải quyết một loạt vấn đề và giảm thời gian dành cho hỗ trợ hơn nữa, và cuộc sống tiếp tục trên, bật.
Chỉ định mọi thứ cho những người có thể làm chúng tốt nhất. Làm cho họ hỗ trợ và tài liệu công việc của họ. Thúc đẩy sự sáng tạo của họ và cho phép họ tập trung mà không bị phân tâm hoặc quản lý vi mô. Mọi thứ khác là BS của trường quản lý, điều không may là có vẻ như công ty của bạn đang bơi vào. Điều đó không có nghĩa là nhóm của bạn cũng cần phải bơi trong đó.
Từ quan điểm của một công ty, một người quản lý tốt sẽ thúc đẩy các giá trị của công ty trong khi thực hiện các nhiệm vụ theo các giá trị đó. Từ quan điểm của một nhân viên CNTT, một người quản lý giỏi cho phép nhóm làm những gì đúng đắn và nhanh chóng nhất có thể và đóng vai trò như một rào cản chống lại quản lý cấp cao đẩy các giá trị mà họ học được trong các lớp MBA cuối tuần xuống cổ họng của những kẻ dưới quyền. Bạn đang là người của công ty và điều đó có thể không phải là tốt nhất cho nhóm của bạn. Những người có kỹ năng giao tiếp "tốt" thì quá lịch sự để nói điều đó.