Dẫn dắt một đội, tôi đang hống hách?


12

Tôi đang ở một nơi dường như rất lạ. Tôi là "trưởng nhóm" trong vai trò cho một dự án cụ thể, Kỹ sư phần mềm Sr. trong chức danh công việc. Trong nhóm của tôi, tôi có 4 nhà phát triển, một trong số họ đóng vai trò tương tự trong một dự án khác nhưng hiện tại tôi đã được ưu tiên nên anh ấy làm việc cho tôi. Tôi cũng có 2 người thử nghiệm, một trong số họ là Quản lý. Một thành viên khác của nhóm là "Đại diện khách hàng", một thành viên của bộ phận hoàn toàn không liên quan. Tôi cũng có một Người quản lý trực tiếp ở trên tôi và tôi cũng tin rằng Người quản lý kiểm tra đó là một phần của nhóm tôi ... không chắc chắn về điều đó.

Tôi đã cố gắng làm rõ lý do tại sao vai trò của tôi chính xác là nhiều lần. Thật khó cho tôi để tìm ra nơi mà thẩm quyền của tôi bắt đầu và kết thúc, nếu tôi thậm chí có bất kỳ. Câu trả lời tôi hiện đang làm việc là tôi là "trưởng nhóm kỹ thuật" của đội. Điều này dường như có nghĩa là thẩm quyền của tôi đối với các quyết định kỹ thuật liên quan đến kiến ​​trúc, thiết kế và quy trình / tiêu chuẩn mã hóa khi chúng liên quan đến chính mã sản phẩm.

Hôm nay có một cái gì đó xuất hiện và kết quả của mã tôi đã ủy thác cho một trong những thành viên trong nhóm của tôi, nơi được hiển thị cho phần còn lại của công ty trong cuộc họp tất cả các chương trình Scrum của chúng tôi. Người đại diện khách hàng làm việc hiển thị. Một cái gì đó đã được thể hiện ngày hôm nay mà tôi thực sự không đồng ý và thậm chí không ai từng hỏi tôi rằng tôi có muốn có tiếng nói trong những gì đã xảy ra không. Nói tóm lại, để cung cấp khả năng người dùng hiển thị giá trị trong báo cáo theo các cách sau (đơn vị "doc", đơn vị thiết kế, làm tròn, không làm tròn), họ đã cung cấp các trường truy cập cho mỗi lần hoán vị. Do đó, chúng ta có giá trị trong các đơn vị doc tròn, đơn vị thiết kế tròn, đơn vị doc không có nền tảng, đơn vị thiết kế không có nền tảng. Mỗi bản ghi mà người dùng sẽ muốn làm việc có nhiều giá trị như vậy và mỗi bản ghi được hoán vị theo cách này.

Tôi thực sự ghét điều này.

Những người chúng tôi đã chỉ ra điều này muốn đảm bảo rằng API chúng tôi sử dụng cho báo cáo giống như cách chúng tôi thực hiện những việc như xuất dữ liệu sang Excel. Thật không may, bây giờ chúng ta đang đạt được động lực này theo một hướng mà tôi nghĩ là thực sự, thực sự tồi tệ.

Tôi đã có một chút khó chịu trong cuộc họp tiếp theo và tôi đã hỏi hai người đã làm điều này, "Tại sao tôi không tham gia vào quyết định này ??" Đó là một vấn đề liên tục xuất hiện và tôi gặp khó khăn khi dường như chỉ cần đưa mọi người vào đội mà tôi phải dẫn đầu để hỏi tôi có muốn tham gia không. Đôi khi tôi không và tôi nghĩ bất cứ điều gì họ nghĩ ra sẽ ổn. Lần khác tôi làm. Trừ khi mọi người hỏi tôi mặc dù thật khó để biết rằng có điều gì đó đang diễn ra cần đầu vào của tôi và họ không cho tôi cơ hội đó.

Thật không may, thẩm quyền của tôi không mở rộng để nói với mọi người, "Lần sau bạn đi và tự mình làm điều gì đó như thế này mà không nói chuyện với tôi, bạn sẽ bị kỷ luật." Đó là một vấn đề "PR" là một lĩnh vực khá rõ ràng không thuộc phạm vi thẩm quyền của tôi. Điều đó thực sự tốt với tôi vì tôi không muốn phải đối phó với những thứ nhảm nhí đó nếu có người khác sẵn sàng.

Tuy nhiên, hôm nay, người quản lý của tôi, trước mặt mọi người (mà tôi đoán là một phần lỗi của tôi vì đã đưa nó lên như thế) nói với tôi rằng tôi không thể tham gia vào mọi quyết định và cần phải ủy quyền.

Tôi tất nhiên nghĩ rằng tôi đúng .... Tôi luôn luôn làm. Tôi không nói những điều tôi nghĩ là BS. Tôi nghĩ rằng tôi nên đã được tiếp cận về vấn đề này và hỏi nếu tôi có một ý tưởng tốt hơn. Định hướng của tôi cho điều này thực ra là chỉ quyết định MỘT giá trị để cung cấp ngay bây giờ, vì đây thực sự là giai đoạn khởi đầu của một tính năng mới và thảo luận về các tùy chọn để cung cấp quyền truy cập thêm trong tương lai nếu muốn. Tôi chưa bao giờ chấp thuận hoặc đề nghị thực hiện hiện tại và tôi thực sự không nghĩ rằng nó nên nhìn thấy ánh sáng trong ngày.

Câu hỏi là, tôi có phải là người không hợp lý?


Chà, hai chúng tôi đã nói về nó và đồng ý rằng cả hai chúng tôi "thả bóng" và chúng tôi dường như ở cùng một trang. Sáng thứ hai ... Chúng tôi sẽ cố gắng đảm bảo vai trò của mình rõ ràng trong đội và vâng, tôi phải quyết định khi nào có sự thay đổi thiết kế hoặc nhiệm vụ cần phải xảy ra; Tôi được đề xuất và đồng ý hoặc quyết định tôi cần nhìn sâu hơn. Sau đó, có một số bit khác tôi có thể cố gắng làm việc để đảm bảo rằng họ biết rằng họ có thể đến với tôi.


1
Nếu đại diện khách hàng thể hiện điều đó như thể đây là điều họ muốn, thì có, bạn đang không hợp lý. Bạn cần phải đưa ra trường hợp (nếu có) rằng những gì họ đã làm sẽ ngăn họ nhận được những gì họ thực sự muốn trong tương lai (nếu thực sự nó sẽ như vậy). Nếu bạn có thể hiển thị nó dưới dạng tiền (tức là nếu họ làm theo cách của bạn, nó sẽ tiết kiệm cho họ x gillionillion đô la), bạn sẽ là một anh hùng.
Robert Harvey

1
@Robert - Tôi đồng ý với điều đó với một lời cảnh báo ... Tôi nghĩ rằng tôi nên tham gia trước khi nó được thể hiện. Tôi nghĩ rằng tôi nên có cơ hội để nói, "Không, chúng ta đừng làm theo cách này và đây là lý do tại sao." Nếu tôi bị ghi đè, cho dù người khác có sai đến đâu, thì đó là như vậy. Tôi nhận ra điều đó và sống với nó. Vấn đề của tôi là không có cơ hội trong khi được cho là "thủ lĩnh". Bạn vẫn sẽ xem xét rằng không hợp lý?
Edward Strange

8
Tôi không nghĩ bạn được coi là người lãnh đạo, dựa trên mô tả của bạn về tình huống. Bạn sẽ phải trở thành "người lãnh đạo bằng ví dụ", anh chàng hướng tới những lời đề nghị được xem xét nghiêm túc vì bạn thực hiện những điều tốt. Điều này sẽ đúng ngay cả khi bạn được cấp thẩm quyền cụ thể.
Robert Harvey

@Crazy - không, nó không phải là không có lý, đó là những gì một nhà lãnh đạo dành cho.
quick_now

1
Hãy nhớ rằng sự tôn trọng là kiếm được và không thể được thi hành. Cuối cùng họ sẽ theo bạn, nếu bạn làm đúng.
Falcon

Câu trả lời:


17

Âm thanh như bạn cần để theo dõi cam kết nguồn. Perforce có khả năng này một cách tự nhiên, Git có nó thông qua các hook, những người khác tôi chắc chắn có phương pháp riêng của họ. Bạn không cần phải thực hiện mọi cam kết, nhưng ít nhất việc có thông báo và phân biệt chúng sẽ giúp bạn có cái nhìn thoáng qua về mọi thứ diễn ra trong dự án của bạn.

Đối với người quản lý của bạn nói rằng bạn cần ủy quyền, tôi không chắc chắn rằng tôi đồng ý - với một nhóm bốn nhà phát triển, bạn sẽ có thể xử lý nó. Hơn nữa, tôi có thể đứng về phía anh ấy (hoặc cô ấy). Tất nhiên, ngay cả trong các nhiệm vụ được ủy quyền, bạn nên yêu cầu cập nhật trạng thái hoặc xem qua các thay đổi thiết kế, v.v.

Không có gì tiêu cực nên bao giờ được đưa lên trong các cuộc họp - âm thanh thích cả bạn và quản lý của bạn giảm bóng trên thế này. Điều tuyệt đối tồi tệ nhất mà bạn có thể đã từng làm gì để một peer là gây rắc rối cho họ. Là một người lãnh đạo (như với người quản lý của bạn), bạn cần phải dễ gần và đáng tin cậy. Việc tin tưởng ai đó sẽ dẫn đến sự phẫn nộ, điều này sẽ làm giảm khả năng lãnh đạo nhóm của bạn (cũng như dẫn đến những nhân viên bất mãn).

Tôi ghét nghe từ "kỷ luật" từ bất cứ ai trong vai trò lãnh đạo. Kỷ luật (ít nhất là trong bối cảnh này) là tiêu cực và không hiệu quả. Làm việc với ai đó (cá nhân chứ không phải trong môi trường họp), tìm hiểu lý do tại sao họ làm điều gì đó và cung cấp giải pháp thay thế nếu bạn không đồng ý với các giải pháp được đề xuất của họ là điều nên làm. Đôi khi, bạn sẽ thấy rằng người bạn làm việc cùng là đúng và bản năng ruột của bạn là sai. Tại sao? Họ đã dành nhiều thời gian cho vấn đề cụ thể hơn bạn có.

Một điều khác khiến tôi lo lắng là "Tôi luôn nghĩ mình đúng". IMO, đó là thái độ tồi tệ nhất có thể từ bất kỳ khách hàng tiềm năng nào. Rõ ràng là bạn nên tự tin vào khả năng của mình, nhưng nhận ra rằng nếu bạn không khắc sâu vào một vấn đề cụ thể, thì nhiều lần hơn là không, các đề xuất của bạn sẽ xuất hiện từ phía sau của bạn (cho dù bạn có bao nhiêu kinh nghiệm) và có thể không trở nên tốt nhất. Nếu ai đó đang tập trung vào một vấn đề cụ thể cung cấp giải pháp thay thế, thì đó là công việc của bạn (cũng như của họ, tùy thuộc vào mức độ kinh nghiệm của chính họ) để chứng minh lý do tại sao bạn tốt hơn, không chỉ nói "Tôi là người dẫn đầu và Tôi luôn nghĩ rằng tôi đúng ", đó là những gì câu nói của bạn khiến tôi tin tưởng.

Để gói nó

Có, bạn không hợp lý ở một số điểm, nhưng những điểm khác thì không. Với tư cách là một người dẫn đầu, tôi hy vọng rằng nếu có những thay đổi về tính năng hoặc kiến ​​trúc mà ít nhất chúng sẽ được bạn thông qua.

Tuy nhiên, đó cũng là công việc của bạn để đảm bảo chất lượng mã và hệ thống tổng thể, mà bạn cần phải tự làm. Công ty của bạn sử dụng đánh giá mã? Bạn có để các lập trình viên của bạn thiết kế những gì họ đang làm việc trước khi nhập mã không? Nếu không, bạn có thể muốn bắt đầu xem xét sử dụng các loại cơ chế kiểm soát chất lượng này.


Tôi đã cố gắng thực hiện đánh giá mã và thiết kế trước. Không làm việc vì nhiều lý do, bao gồm một số trong những lý do tôi đã than thở ở trên. Tôi cũng đã có một thời gian khó khăn để tìm ra một cách không làm chúng ta chậm lại. Một phần khác của vấn đề là mọi người dường như không sẵn sàng phê bình mã. Tôi cũng đã cố gắng có nhiều người đưa ra ý tưởng / thiết kế cho các phần khó trong dự án của chúng tôi. Thật không may, cái của tôi luôn là thứ chúng tôi sử dụng nên tôi nghĩ điều đó có thể làm nản lòng. Cả hai đều là những điều tôi nghĩ rằng chúng ta cần phải làm (và kiểm tra đơn vị, vâng), nhưng đã gặp sự cố.
Edward Strange

Bất kỳ đề xuất? Làm thế nào chúng ta có thể thực hiện đánh giá mã mà không mất nhiều thời gian? Làm cách nào tôi có thể khiến các thành viên khác trong nhóm GIÁ TRỊ nó (và cả bài kiểm tra đơn vị nữa)? Đó dường như là vấn đề lớn. Có vẻ như tôi chỉ giao một loạt công việc bận rộn khiến mọi người chậm lại khi tôi thực sự tin rằng chúng ta sẽ tốt hơn. Một vấn đề lớn đối với tôi ở đây là chưa bao giờ được cố vấn vào vị trí này, tôi chỉ phải đảm nhận nó (công ty nhỏ, thích hợp thuê người ra khỏi trường đại học). Đã ở đó một thời gian dài nhưng học được bằng nghiên cứu, thử nghiệm và thất bại thay vì làm việc dưới một tốt hơn.
Edward Strange

2
- Một điều khác khiến tôi lo lắng là "Tôi luôn nghĩ mình đúng" .-- Tôi thấy tất cả các điểm của bạn và đồng ý với họ. Là một lựa chọn kém của biểu hiện pha trộn với một số hài hước tự ti. Tôi cố gắng giữ cho tóc của tôi không chỉ lên.
Edward Strange

Có một vài công cụ mà bạn có thể sử dụng để giúp tăng tốc độ đánh giá mã. Các công cụ dựa trên web dường như hoạt động tốt - bạn có thể tìm thấy danh sách các dự án hệ điều hành tại đây: lasatic.com/blog/open-source-code-review-tools . Tất nhiên, thành phần lớn nhất để có đánh giá thành công là trách nhiệm . Người đánh giá phải chịu trách nhiệm cho đánh giá của họ.
Demian Brecht

1
Thực sự, nó sôi sục để đảm bảo rằng nhóm của bạn tự hào về những gì họ làm và những gì họ đầu ra. Biết rằng tên của họ được đính kèm với đánh giá và họ đã ổn những gì đang diễn ra trong sự thay đổi sẽ khiến họ làm tốt công việc của mình (hoặc ít nhất là tốt nhất có thể). Nếu họ không, thì có lẽ một số cố vấn theo thứ tự (một lần nữa, ở chế độ riêng tư) .. Tìm hiểu lý do tại sao họ không quan tâm đến những gì họ đang xem xét và nhấn mạnh tầm quan trọng của các đánh giá (số lỗi thấp hơn, chất lượng mã, Vân vân).
Demian Brecht

9

Bạn có thể bị kiểm tra quản lý và nếu bạn thất bại (điều đó có thể không phải là điều xấu; nhiều người trong chúng ta là nhà phát triển tốt và sẽ là người quản lý tồi, và tôi thích lập trình hơn là quản lý lập trình viên).

Người quản lý thường không có thẩm quyền cho mọi việc họ dự kiến ​​sẽ làm. Hoàn thành công việc dù sao cũng là một dấu hiệu của một người quản lý tốt. Bạn cần tìm cách khiến mọi người làm việc mà không cần thực hiện bất kỳ hành động kỷ luật nào. (Lưu ý: chê bai mọi người ở nơi công cộng phải không. Khen ngợi ở nơi công cộng, chỉ trích riêng tư và thể hiện sự quan tâm đến cấp dưới của bạn như mọi người.)

Người quản lý cũng phải ủy thác, ngay cả khi đau. Bạn có thể dành nhiều thời gian hơn để xử lý vấn đề này hơn là bạn đã dành thời gian để tự viết nó, và điều đó tốt. Khi bạn đã giải quyết nó, những người đã làm điều đó sẽ học được điều gì đó và họ sẽ ít làm những điều sai lầm trong tương lai.

Cách đúng đắn để đối phó với một cái gì đó như thế này là riêng tư, trước tiên hãy hỏi các nhà phát triển tại sao họ lại hiển thị theo cách đó. Không phải trong một cuộc họp, và không phải bằng cách giả sử rằng bạn đúng và họ sai (ngay cả khi bạn đúng và họ sai). Hãy cho họ một cơ hội để giải thích. Điều đó không có nghĩa là bạn phải đi với quyết định của họ; bạn, sau tất cả, là người dẫn đầu về kỹ thuật. Điều đó có nghĩa là bạn cần cung cấp cho họ lý do để thực hiện theo cách của bạn và bạn nên giải quyết bất kỳ vấn đề cơ bản nào thể hiện trong cuộc họp riêng tư đó.

Ngoài ra, các nhà quản lý có trách nhiệm cho những gì phát sinh từ người của họ. Bạn nên cố gắng không bị mù quáng bởi bất cứ điều gì họ làm, đặc biệt là trước mặt khách hàng. Điều này có thể liên quan đến việc theo dõi các đăng ký mã hoặc có các cuộc hội thảo nhỏ với các nhà phát triển của bạn (mặc dù bạn cần cẩn thận với điều đó, bạn không muốn làm gián đoạn chúng khi chúng ở trong khu vực). Có thể bạn nên nói chuyện với tất cả các nhà phát triển vào buổi chiều trước cuộc họp với đại diện khách hàng.


Tôi cho rằng nó có thể nhưng tôi thực sự nghi ngờ nó. Chúng tôi chỉ thuê một người quản lý và khi tôi ứng tuyển vào vị trí tương tự, tôi đã bị CEO bỏ qua một bên. Khá rõ ràng họ không thấy vị trí đó là chơi theo sở trường của tôi: PI có thể bị mài mòn. Sau khi xem anh chàng mới tôi phải đồng ý với một số đánh giá. Sự điều động chính trị và ngoại giao của anh ấy để hoàn thành công việc là điều tôi chắc chắn có rất nhiều điều để tìm hiểu.
Edward Strange

"Các nhà quản lý thường không có thẩm quyền cho mọi việc họ dự kiến ​​sẽ làm. Hoàn thành mọi việc dù sao cũng là một dấu hiệu của một người quản lý tốt." Vâng, rất nhiều như vậy. Tôi đã luôn có thái độ kéo dài thẩm quyền của mình hết mức có thể và xem điều gì sẽ xảy ra. Bị đập xuống? Vâng, tôi tìm thấy nơi giới hạn. Làm điều này mặc dù - bạn phải đúng thường xuyên hơn sai. Thật không may, mặt khác của vị trí dẫn đầu / người quản lý là một số người chỉ đơn giản là THỰC SỰ CỨNG để đối phó, và khi họ không thể chấp nhận được bất kỳ lý do nào trong cuộc sống thì rất khó khăn.
quick_now

4

Đừng mang nó theo cá nhân

Đó là một nỗ lực của nhóm. Bạn là người dẫn đầu về kỹ thuật, không phải là người duy nhất trong dự án. Bạn nên tập trung vào việc nhóm học hỏi từ những sai lầm hoặc thay đổi quy trình.

Dẫn dắt và học hỏi

Một phần của bất kỳ vị trí lãnh đạo nào, bao gồm một lãnh đạo kỹ thuật, là để hiểu rằng bạn làm tốt nhất có thể với những người bạn có. Nhóm càng làm việc cùng nhau, họ sẽ càng biết khi nào nên đưa mọi thứ lên và khi nào không. Chỉ cần chắc chắn rằng bạn không rơi vào cái bẫy của việc ra lệnh cho đội của bạn. Xem lại những gì đã sai những gì đã diễn ra tốt trên cơ sở hàng tuần. Giao tiếp với nhóm của bạn nếu bạn muốn họ làm những việc khác nhau. Biện pháp trừng phạt phải luôn là biện pháp cuối cùng và chúng thường có nghĩa là bạn cần sa thải ai đó, hoặc bạn đã thất bại trong vai trò của mình.

Xem lại trước khi trình bày của khách hàng

Nếu bạn là người dẫn đầu dự án, tại sao bạn chưa xem xét tính năng và triển khai trước khi nó được trình bày?

Nếu nó sai sửa nó

Giải thích rõ ràng tại sao một cái gì đó sai và thay đổi nó. Nó đắt hơn, nhưng nếu nó thực sự sai thì hãy sửa nó. Nếu nó không sai, chỉ khác với cách bạn muốn mọi thứ được thực hiện, sau đó một lần nữa; hiểu bạn không phải là người duy nhất làm việc trong dự án.


3

Có bất kỳ tài liệu cụ thể tài liệu những gì được cho là sẽ được thực hiện? Đưa ra một yêu cầu kết thúc quá mở, các nhà phát triển thường sẽ điền vào chỗ trống (hoặc yêu cầu quản lý vi mô) với bất cứ điều gì họ cho là phù hợp.

Vì vậy, cuối cùng bạn sẽ đến gặp người quản lý của mình với "Vì vậy, thay vì làm việc với những gì trong thông số kỹ thuật, họ đã quyết định thực hiện [tính năng]. Bây giờ chúng tôi đứng sau, vì một tính năng không được chấp thuận ngay từ đầu."

Sau đó, bạn có thể bắt đầu làm việc để loại bỏ tính năng này khi các nhà phát triển đã được chỉ định lại.

chỉnh sửa> Và không, tôi không nghĩ bạn đang hống hách. Công việc của họ kết thúc là mông của bạn.


Chà, nó đã kết thúc mở trong thực tế là nó không nói KHÔNG làm những gì đã làm. Tất cả những gì câu chuyện đang được thực hiện nói là đưa các giá trị vào báo cáo trong các đơn vị của tài liệu. Một người khác, ở đâu đó đã quyết định rằng họ cần nhiều hơn thế, điều mà tôi có thể đồng ý với một nơi nào đó trên đường ... điều làm phiền tôi là hack, tôi muốn nói rằng: "Tôi thực sự không nghĩ bạn nên làm điều đó theo cách đó. "
Edward Strange

@Crazy Eddie: bạn cũng có thể tiếp cận nó theo cách suy nghĩ tiến lên. Tạo một lỗi chỉ ra rằng chức năng cần phải được loại bỏ / thay thế bằng bất cứ thứ gì cần có và gán cho nhà phát triển đã viết nó ở vị trí đầu tiên. Sau đó, nó chỉ là kinh doanh như bình thường sửa một lỗi.
Steven Evers

2

Tôi thấy mình thường ở cùng một vị trí và nâng cao nó trong các cuộc họp và thảo luận dường như không đi đến đâu. Đôi khi như một phương sách cuối cùng trước khi tôi từ chức để đi đến quyết định đã đưa ra (albiet không phải của tôi), tôi gửi email cho các bên liên quan nêu rõ điều này bằng màu đen và trắng với lý do tại sao.

Sau đó, tôi sẽ lưu trữ email đó để đảm bảo tôi có nó để tham khảo trong tương lai trong trường hợp cần tiếp tục xuống dòng khi người quản lý hoặc khách hàng hỏi tại sao điều gì đó được thực hiện theo cách đó hoặc tại sao một thay đổi lại tốn kém quá nhiều để khắc phục.


+1: Cái này được gọi là "Tập tin Súng hút thuốc". In những thứ đó ra và giữ nó ở nhà.
quick_now

2

Tôi nghĩ bạn đã sai khi đưa nó lên theo cách bạn đã làm, như bạn đã thừa nhận. Bạn không sai khi nói rằng bạn nên có một số đầu vào về thiết kế ở cấp độ này nhưng tôi không chắc bạn dự kiến ​​sẽ triển khai như thế nào là hợp lý. Mọi người sẽ không chạy một thiết kế của bạn nếu họ cho rằng nó đơn giản; vì họ có thể dễ dàng sai lầm về việc nó đơn giản như họ có thể về chính thiết kế mà bạn sẽ không tìm thấy những người tình nguyện cho bạn xem tất cả các thiết kế sai của họ. Tại thời điểm này, tôi chủ yếu tò mò về thói quen làm việc và các kiểu giao tiếp của bạn, nhưng thực sự không có vấn đề gì được thực hiện đôi khi bạn sẽ chỉ bị mù quáng bởi những điều này. Nói ngắn gọn về việc xem xét cẩn thận mọi cam kết Tôi không chắc bạn chứng minh điều này như thế nào.


1

Tôi thường xuyên cảm thấy như thế này về mặt cảm xúc:

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

nhưng tôi có ý thức về mặt trí tuệ để biết rằng tôi thỉnh thoảng sai. Tôi cũng biết khi nào nên chọn một cuộc chiến - bạn không thể tranh luận về mọi thứ, và đôi khi một thỏa thuận bất ngờ về phía bạn có thể làm nên điều kỳ diệu.


Tôi luôn cho phép ai đó chứng minh tôi sai hoặc thuyết phục tôi rằng tôi là. Tôi thực sự có xu hướng nghĩ rằng tôi đúng cho đến khi điều đó được thực hiện: P
Edward Strange

1

Một nhà lãnh đạo thực sự là gì?

Là người có thể sa thải cấp dưới, bất kỳ cấp dưới nào. (nhưng không cần thuê một cái mới)

Đôi khi, hầu hết mọi người được "gắn thẻ" là một nhà lãnh đạo của một dự án nào đó, nhưng, không có sức mạnh của ai đó, thì đó là một "hướng dẫn" / "giáo viên" hơn là một nhà lãnh đạo thực thụ.

Nhưng một lần nữa, nó có thể xảy ra rằng bạn có thể là một người lãnh đạo nhóm nhưng không dẫn dắt dự án hiện tại của bạn. Các trường hợp xấu nhất là khi khách hàng đang dẫn đầu dự án. Tại thời điểm này, nếu dự án thất bại (và nó sẽ thất bại) thì đó không phải là trách nhiệm của bạn.

Và trường hợp xấu nhất là khi tồn tại hai nhà lãnh đạo của dự án.

Là một quân đội, các chuỗi chỉ huy là tất cả (không triệt để như "chết vì một dự án" nhưng đủ gần). Đối với vấn đề này, người quản lý của bạn đã phá vỡ trạng thái của bạn, hạ thấp đạo đức của "người" của bạn và không giúp đỡ gì cả.


1

Vâng, ông chủ của bạn là đúng - bạn không thể tham gia vào mọi quyết định. Trong thực tế, không thể bắt mọi thứ như thế này trừ khi bạn tự làm tất cả. Tôi nghĩ đó là nơi bạn đến - bạn cảm thấy bạn không thể xử lý tốt toàn bộ dự án trừ khi bạn tham gia vào từng chi tiết nhỏ, nhưng bạn không thể tham gia vào từng chi tiết nhỏ mà không áp đảo bạn (điều này sẽ làm mất tinh thần đội và có thể đốt cháy bạn ra).

Câu trả lời là đừng lo lắng về những điều sai lầm - họ luôn làm thế - thay vào đó là lo lắng về việc sửa chúng sau đó, theo cách xây dựng.

Nếu bạn tiếp tục theo dõi thông tin liên lạc, bạn không chỉ có thể ủy thác mà còn có thể để những người cấp cao của bạn ra đi và làm những gì họ biết là cần thiết mà không phải luôn giữ họ lại với các đánh giá, thảo luận và cố gắng kiểm soát sai. Tin tưởng họ làm điều đúng đắn và ở đó để 'trò chuyện' về những gì đang diễn ra để bạn có thể được giữ trong vòng lặp (và dán mũi vào khi bạn cảm thấy thực sự cần thiết).


0

Bạn có một số vấn đề. Đầu tiên người quản lý của bạn đứng về phía nhóm của bạn và bảo bạn giao phó nhiều hơn. Điều này cho thấy sự thiếu tự tin về khả năng lãnh đạo nhóm của bạn. Thực tế nó cho thấy rằng trong khi bạn có danh hiệu lãnh đạo công nghệ, thì thực tế, bạn không phải là người dẫn đầu về công nghệ vì bạn không có thẩm quyền. Bạn cần phải ngồi xuống với người quản lý của bạn và có một trái tim chân thành về điều này. Không ai có thể thành công ở vị trí lãnh đạo kỹ thuật nếu không có sự hỗ trợ của người quản lý và không có quyền thay đổi các quyết định thiết kế do nhóm đưa ra mà không có sự đồng ý của anh ấy. Bạn không có thẩm quyền để làm công việc của bạn. Sếp của bạn cần hiểu rằng bạn đang ở trong một vị trí không thể thắng và anh ấy phải cung cấp cho bạn sự hỗ trợ công khai của anh ấy để nó trở nên tốt hơn. Trách nhiệm mà không có thẩm quyền là tình huống tồi tệ nhất có thể để tìm thấy chính bạn.

Tiếp theo, nhóm của bạn bịt mắt bạn. Bạn cần nói chuyện này với họ. Bạn nên có cuộc thảo luận thiết kế với họ trước khi họ thực hiện bất kỳ sự phát triển nào và rất lâu trước khi họ thực hiện bất kỳ bài thuyết trình nào. Bạn có thể ủy thác một số thiết kế (mặc dù bạn, không phải họ, có quyền quyết định những gì bạn nghĩ nên được ủy quyền), nhưng không được phép họ tiến hành mà không thông báo cho bạn. Họ đã đánh mất niềm tin của bạn bằng cách che mắt bạn, giờ họ phải học hành vi tốt hơn. Bạn cần kiểm tra với họ thường xuyên để đảm bảo họ sẽ không làm phiền bạn nữa và nếu họ làm vậy, bạn nên thực hiện một số báo cáo chính thức về vấn đề này cho phòng nhân sự. Dẫn không dẫn đến phổ biến, khi các nhà phát triển cố tình đi xung quanh họ sau khi được nói không, sau đó họ xứng đáng nhận hậu quả. Nó không' Không quan trọng họ có thích bạn hay không nhưng rõ ràng tại thời điểm họ không tôn trọng bạn. Họ cần có những câu hỏi cho hành vi không phù hợp của mình hoặc nó sẽ trở nên tồi tệ hơn. Tuy nhiên, bạn không thể khắc phục phần này của sự cố cho đến khi bạn khắc phục sự cố hỗ trợ quản lý.

Tiếp theo bạn thổi công khai, bạn cần xin lỗi công khai. Điều này sẽ giúp bạn xây dựng danh tiếng của bạn trở lại.

Sau đó, bạn cần phải đưa từng người sang một bên một cách riêng tư và nói cho họ biết hậu quả của hành vi xấu tiếp tục của họ (một khi bạn đã nhận được người quản lý của mình đồng ý cho phép bạn đưa ra hậu quả cho họ). Công chúng khen ngợi và ủng hộ, phê bình riêng nên là quy tắc của bạn. Bạn cũng có thể cần đăng ký với họ thường xuyên hơn bên ngoài các bước sóng nhóm để họ không thể bịt mắt bạn.

Bây giờ, thẳng thắn vì cả những người bên trên và bên dưới bạn nghĩ rõ ràng bạn là người có thể bị bỏ qua và không được thông báo, bạn cần phải làm một tâm hồn nghiêm túc tìm kiếm chính mình về những gì khiến họ không tôn trọng bạn. Bạn cũng cần phải quyết định xem bạn sẽ không hạnh phúc hơn nếu không trở thành một nhà lãnh đạo công nghệ hay bạn nên chuyển đến một nơi mà bạn sẽ có thẩm quyền để đi theo trách nhiệm. Nếu bạn quyết định bạn muốn duy trì quan điểm, bạn sẽ phải yêu cầu mọi người san bằng với bạn về lý do tại sao họ đối xử với bạn rất kém. Điều đó sẽ rất đau đớn và có lẽ bạn sẽ không muốn nghe câu trả lời, nhưng bạn cần biết lý do tại sao bạn cảm nhận theo cách họ nhìn nhận rõ ràng về bạn.


bạn bịt mắt? Đau buồn, bạn làm việc ở cửa hàng mồ hôi nào mà bạn phải hỏi người quản lý của mình từng chi tiết nhỏ và đồng ý từng chút công việc? Nếu không có người quản lý của anh ấy, tôi có thể dễ dàng thấy toàn bộ đội của anh ấy muốn nghỉ việc.
gbjbaanb

@gbjbaanb, vấn đề thiết kế không phải là chi tiết nhỏ, chúng ảnh hưởng nhiều hơn là ngay lập tức. Thiết kế là trách nhiệm của anh ấy không phải của họ. Họ cố tình thể hiện uy quyền của mình (và từ mô tả đó không phải là lần đầu tiên) và xứng đáng bị đánh gục nặng nề vì điều đó.
HLGEM

1
@gbjbaanb - điều đó sẽ khiến cho chủ nhân của tôi khá vất vả vì tôi cũng đã quyết định đến lúc phải tiếp tục. Tôi có nó trong tôi để trở thành một nhà lãnh đạo giỏi, và tôi biết rất nhiều (đó là lý do tại sao tôi kết thúc ở vị trí đó), nhưng việc bị ném vào đó mà không có bất kỳ người cố vấn nào là một thảm họa và sự thất vọng liên tục đối với tôi.
Edward Strange
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.