Một ngày quan trọng đã đến đối với Red Hat, cộng đồng nguồn mở Nga và tất cả những người liên quan - nó đã được xuất bản bằng tiếng Nga . Cô ấy kể chi tiết và sinh động về cách chúng tôi ở Red Hat đưa ra những ý tưởng tốt nhất và con đường cho những người tài năng nhất, cũng như về cách không lạc lối trong sự hỗn loạn và đoàn kết hàng triệu người trên khắp thế giới.
Cuốn sách này cũng nói về cuộc sống và thực hành. Nó chứa đựng rất nhiều lời khuyên dành cho những ai muốn tìm hiểu cách xây dựng một công ty bằng mô hình tổ chức mở và quản lý nó một cách hiệu quả. Dưới đây là một số nguyên tắc quan trọng nhất được đưa ra trong cuốn sách mà bạn có thể lưu ý ngay bây giờ.
Quá trình làm việc của Jim với công ty rất đáng chú ý. Nó cho thấy rằng không có sự phô trương nào trong thế giới nguồn mở, nhưng có một cách tiếp cận mới để lãnh đạo:
“Sau khi nói chuyện với nhà tuyển dụng, tôi bày tỏ sự quan tâm đến một cuộc phỏng vấn và anh ấy hỏi liệu tôi có phiền bay đến trụ sở Red Hat ở Raleigh, Bắc Carolina vào Chủ nhật không. Tôi nghĩ Chủ nhật là một ngày kỳ lạ để gặp nhau. Nhưng vì tôi vẫn định bay đến New York vào thứ Hai nên nói chung là nó đang trên đường đến và tôi đã đồng ý. Tôi lên máy bay từ Atlanta và hạ cánh xuống sân bay Raleigh Durham. Từ đó, tôi bắt một chiếc taxi thả tôi trước tòa nhà Red Hat trong khuôn viên Đại học Bắc Carolina. Hôm đó là Chủ nhật, 9 giờ 30 sáng và không có ai ở xung quanh. Đèn tắt và khi kiểm tra tôi thấy cửa đã bị khóa. Lúc đầu tôi tưởng mình bị lừa. Khi tôi quay lại định bắt taxi, tôi thấy nó đã rời đi. Chẳng mấy chốc trời bắt đầu mưa, tôi không có ô.
Ngay khi tôi chuẩn bị đi đâu đó để bắt taxi thì Matthew Shulick, sau này là chủ tịch hội đồng quản trị và CEO của Red Hat, dừng xe lại. “Chào,” anh chào. “Bạn có muốn uống một chút cà phê không?” Đây có vẻ là một cách khác thường để bắt đầu cuộc phỏng vấn, nhưng tôi biết mình chắc chắn cần uống một ít cà phê. Cuối cùng, tôi nghĩ, sẽ dễ dàng hơn cho tôi khi bắt taxi đến sân bay.
Buổi sáng chủ nhật ở Bắc Carolina khá yên tĩnh. Phải mất một lúc chúng tôi mới tìm được một quán cà phê mở cửa trước buổi trưa. Quán cà phê không phải là quán tốt nhất trong thành phố và cũng không phải là quán sạch sẽ nhất, nhưng nó hoạt động tốt và bạn có thể uống cà phê mới pha ở đó. Chúng tôi ngồi xuống bàn và bắt đầu nói chuyện.
Sau khoảng ba mươi phút, tôi nhận ra rằng tôi thích cách mọi việc đang diễn ra; Cuộc phỏng vấn không hề truyền thống, nhưng bản thân cuộc trò chuyện lại rất thú vị. Thay vì thảo luận về những điểm tốt hơn trong chiến lược công ty của Red Hat hoặc hình ảnh của nó trên Phố Wall – điều mà tôi đã chuẩn bị – Matthew Shulick lại hỏi thêm về những hy vọng, ước mơ và mục tiêu của tôi. Bây giờ tôi thấy rõ rằng Shulik đang đánh giá xem liệu tôi có phù hợp với văn hóa nhóm và phong cách quản lý của công ty hay không.
Sau khi chúng tôi kết thúc, Shulick nói rằng anh ấy muốn giới thiệu tôi với cố vấn chung của công ty, Michael Cunningham, và đề nghị tôi gặp anh ấy ngay bây giờ để ăn trưa sớm. Tôi đồng ý và chúng tôi chuẩn bị rời đi. Sau đó, người đối thoại của tôi phát hiện ra rằng anh ta không mang theo ví. “Ồ,” anh nói. - Tôi không có tiền. Và bạn?" Điều này làm tôi ngạc nhiên nhưng tôi trả lời rằng tôi có tiền và không ngại trả tiền cà phê.
Vài phút sau, Shulik thả tôi xuống một nhà hàng Mexico nhỏ, nơi tôi gặp Michael Cunningham. Nhưng một lần nữa, không có cuộc phỏng vấn hay cuộc họp kinh doanh truyền thống nào diễn ra mà thay vào đó là một cuộc trò chuyện thú vị khác diễn ra. Khi chúng tôi chuẩn bị thanh toán hóa đơn thì hóa ra máy thẻ tín dụng của nhà hàng bị hỏng và chúng tôi chỉ có thể nhận tiền mặt. Cunningham quay sang tôi và hỏi liệu tôi có sẵn sàng trả tiền không vì anh ta không mang theo tiền mặt. Vì tôi sắp đi New York nên tôi có rất nhiều tiền mặt nên tôi trả tiền cho bữa trưa.
Cunningham đề nghị chở tôi đến sân bay và chúng tôi lên xe của anh ấy. Sau vài phút, anh ấy hỏi, “Bạn có phiền nếu tôi dừng lại và đổ xăng không? Chúng ta sẽ dốc hết sức lực về phía trước." “Không vấn đề gì,” tôi trả lời. Vừa nghe thấy tiếng máy bơm nhịp nhàng thì có tiếng gõ cửa sổ. Đó là Cunningham. “Này, ở đây họ không chấp nhận thẻ tín dụng,” anh nói. “Tôi có thể mượn một ít tiền được không?” Tôi bắt đầu tự hỏi liệu đây thực sự là một cuộc phỏng vấn hay một hình thức lừa đảo nào đó.
Ngày hôm sau, khi đang ở New York, tôi đã thảo luận về cuộc phỏng vấn này với vợ tôi ở Red Hat. Tôi nói với cô ấy rằng cuộc trò chuyện rất thú vị, nhưng tôi không chắc những người này có nghiêm túc khi thuê tôi hay không: có lẽ họ chỉ muốn đồ ăn và xăng miễn phí? Nhớ lại cuộc gặp hôm nay, tôi hiểu rằng Shulick và Cunningham chỉ đơn giản là những người cởi mở và đối xử với tôi như bất kỳ người nào khác mà họ có thể cùng uống cà phê, ăn trưa hoặc đổ xăng. Đúng, thật buồn cười và thậm chí buồn cười là cả hai đều không có tiền. Nhưng đối với họ vấn đề không phải là tiền. Họ, giống như thế giới nguồn mở, không tin vào việc trải thảm đỏ hay cố gắng thuyết phục người khác rằng mọi thứ đều hoàn hảo. Họ chỉ cố gắng hiểu tôi hơn chứ không cố gắng gây ấn tượng hay chỉ ra sự khác biệt của chúng tôi. Họ muốn biết tôi là ai.
Cuộc phỏng vấn đầu tiên của tôi tại Red Hat đã cho tôi thấy rõ ràng rằng công việc ở đây rất khác biệt. Công ty này không có hệ thống phân cấp truyền thống và cách đối xử đặc biệt dành cho người quản lý, ít nhất là theo hình thức thông thường ở hầu hết các công ty khác. Theo thời gian, tôi cũng biết được rằng Red Hat tin vào nguyên tắc trọng dụng nhân tài: việc cố gắng thực hiện ý tưởng tốt nhất luôn đáng giá, bất kể ý tưởng đó đến từ quản lý cấp cao hay từ một thực tập sinh mùa hè. Nói cách khác, trải nghiệm đầu tiên của tôi tại Red Hat đã giúp tôi hiểu được tương lai của vai trò lãnh đạo sẽ như thế nào.”
Lời khuyên để nuôi dưỡng chế độ nhân tài
Chế độ nhân tài là giá trị cốt lõi của cộng đồng nguồn mở. Đối với chúng tôi, việc bạn chiếm giữ cấp độ nào của kim tự tháp không quan trọng, điều quan trọng là ý tưởng của bạn tốt đến mức nào. Đây là những gì Jim gợi ý:
- Đừng bao giờ nói “Đó là điều sếp muốn” và đừng dựa vào thứ bậc. Điều này có thể giúp ích cho bạn trong thời gian ngắn, nhưng đây không phải là cách bạn xây dựng chế độ nhân tài.
- Công khai ghi nhận những thành công và đóng góp quan trọng. Đây có thể là một email cảm ơn đơn giản gửi kèm toàn bộ nhóm.
- Hãy xem xét: quyền hạn của bạn là một chức năng của vị trí của bạn trong hệ thống phân cấp (hoặc quyền truy cập vào thông tin đặc quyền), hay đó là kết quả của sự tôn trọng mà bạn giành được? Nếu là cái đầu tiên, hãy bắt đầu làm cái thứ hai.
- Yêu cầu phản hồi và thu thập ý tưởng về một chủ đề cụ thể. Bạn nên phản ứng với mọi thứ, chỉ kiểm tra những gì tốt nhất. Nhưng đừng chỉ lấy những ý tưởng tốt nhất và tiếp tục với chúng - hãy tận dụng mọi cơ hội để củng cố tinh thần chế độ nhân tài, ghi công cho tất cả những người xứng đáng.
- Ghi nhận một thành viên gương mẫu trong nhóm của bạn bằng cách đưa ra một nhiệm vụ thú vị, ngay cả khi nó không thuộc lĩnh vực công việc thông thường của họ.
Hãy để các ngôi sao nhạc rock của bạn theo đuổi niềm đam mê của họ
Sự nhiệt tình và sự tham gia là hai từ rất quan trọng trong một tổ chức mở. Chúng được lặp đi lặp lại liên tục trong cuốn sách. Nhưng bạn không thể khiến những người đam mê sáng tạo làm việc chăm chỉ, phải không? Nếu không, bạn sẽ không nhận được mọi thứ mà tài năng của họ mang lại. Tại Red Hat, những trở ngại cho dự án của họ được giải quyết càng nhiều càng tốt:
“Để thúc đẩy sự đổi mới, các công ty phải thử nhiều thứ. Cách tiếp cận của Google rất thú vị. Kể từ khi Google được biết đến ở mọi nhà vào năm 2004, các giám đốc điều hành và nhà tư tưởng trong lĩnh vực kinh doanh Internet đã cố gắng làm sáng tỏ bí mật chính của công ty nhằm lặp lại thành công ấn tượng của nó. Một trong những chương trình nổi tiếng nhất nhưng hiện đã đóng cửa là tất cả nhân viên của Google được yêu cầu dành 20% thời gian để làm hầu hết mọi việc họ muốn. Ý tưởng là nếu nhân viên theo đuổi các dự án và ý tưởng riêng mà họ đam mê ngoài công việc, họ sẽ bắt đầu đổi mới. Đây là cách mà các dự án của bên thứ ba phát sinh thành công: GoogleSuggest, AdSense cho Nội dung và Orkut; tất cả đều đến từ thí nghiệm 20% này – một danh sách đầy ấn tượng! […]
Tại Red Hat, chúng tôi áp dụng cách tiếp cận ít trang trọng hơn. Chúng tôi không có chính sách cố định về lượng thời gian mỗi nhân viên nên dành cho “đổi mới”. Thay vì dành thời gian riêng cho mọi người để tự học, chúng tôi đảm bảo rằng nhân viên có quyền dành thời gian để học những điều mới. Thành thật mà nói, nhiều người có rất ít thời gian, nhưng cũng có những người có thể dành gần như cả ngày làm việc của mình cho việc đổi mới.
Trường hợp điển hình nhất trông giống như thế này: một người nào đó làm việc trong một dự án phụ (nếu anh ta giải thích tầm quan trọng của dự án đó với người quản lý - trực tiếp tại nơi làm việc; hoặc ngoài giờ làm việc - theo sáng kiến của riêng anh ta), và sau đó công việc này có thể chiếm toàn bộ giờ phút hiện tại của anh ấy.”
Hơn cả việc động não
“Lạc đề trữ tình. Alex Fakeney Osborne là người phát minh ra phương pháp động não, sự tiếp nối của phương pháp này ngày nay là phương pháp từ đồng nghĩa. Điều gây tò mò là ý tưởng này xuất hiện trong Chiến tranh thế giới thứ hai, khi Osborne chỉ huy một trong những tàu của đoàn tàu chở hàng của Mỹ đang có nguy cơ bị tàu ngầm Đức tấn công bằng ngư lôi. Sau đó, thuyền trưởng nhớ lại chiêu thức mà bọn cướp biển thời Trung Cổ đã áp dụng: nếu thủy thủ đoàn gặp rắc rối, tất cả thủy thủ tập trung trên boong để thay phiên nhau đề xuất cách giải quyết vấn đề. Có rất nhiều ý tưởng, trong đó có những ý tưởng thoạt nhìn vô lý: ví dụ như ý tưởng cùng cả đội thổi một quả ngư lôi. Nhưng với phản lực của máy bơm tàu, vốn có sẵn trên mọi con tàu, hoàn toàn có thể làm chậm một quả ngư lôi hoặc thậm chí thay đổi hướng đi của nó. Kết quả là Osborne thậm chí còn được cấp bằng sáng chế cho một phát minh: một cánh quạt bổ sung được gắn ở mạn tàu, đẩy dòng nước dọc theo mạn tàu và ngư lôi trượt dọc theo.”
Jim của chúng tôi liên tục nhắc lại rằng làm việc trong một tổ chức mở không hề dễ dàng. Ngay cả ban quản lý cũng hiểu được điều đó, vì không ai không cần phải bảo vệ ý kiến của mình. Nhưng đây chính xác là cách tiếp cận cần thiết để đạt được kết quả xuất sắc:
“Các diễn đàn và phòng trò chuyện [nguồn mở] trực tuyến thường tràn ngập các cuộc thảo luận sôi nổi và đôi khi gay gắt về mọi thứ, từ cách tốt nhất để sửa lỗi phần mềm cho đến những tính năng mới nào cần được xem xét trong bản cập nhật tiếp theo. Theo quy định, đây là giai đoạn thảo luận đầu tiên, trong đó các ý tưởng mới được đưa ra và tích lũy, nhưng luôn có vòng tiếp theo - phân tích phản biện. Mặc dù bất kỳ ai cũng có thể tham gia vào các cuộc tranh luận này, nhưng người đó phải chuẩn bị sẵn sàng để bảo vệ quan điểm của mình bằng tất cả sức lực của mình. Những ý tưởng không được ưa chuộng tốt nhất sẽ bị từ chối, tệ nhất là bị chế giễu.
Ngay cả Linus Torvalds, người tạo ra hệ điều hành Linux, cũng bày tỏ sự không đồng tình với những thay đổi được đề xuất đối với mã. Một ngày nọ, Linus và David Howells, một trong những nhà phát triển chính của Red Hat, đã tranh luận sôi nổi về giá trị của việc thay đổi mã mà Red Hat đã yêu cầu để giúp cung cấp bảo mật cho khách hàng của chúng tôi. Đáp lại yêu cầu của Howells, Torvalds viết: “Thành thật mà nói, đây là [từ không thể in được] thật ngu ngốc. Mọi thứ dường như đều xoay quanh những giao diện ngu ngốc này và vì những lý do hoàn toàn ngu ngốc. Tại sao chúng ta nên làm điều này? Tôi không thích trình phân tích cú pháp X.509 hiện có nữa. Các giao diện phức tạp ngu ngốc đang được tạo ra và bây giờ sẽ có 11 giao diện như vậy – Linus 9.”
Bỏ qua các chi tiết kỹ thuật, Torvalds tiếp tục viết với tinh thần tương tự trong tin nhắn tiếp theo - và theo cách mà tôi không dám trích dẫn. Cuộc tranh chấp này ồn ào đến mức nó thậm chí còn được đưa lên các trang của Tạp chí Phố Wall. […]
Cuộc tranh luận này cho thấy rằng hầu hết các công ty sản xuất phần mềm độc quyền, không tự do không có cuộc tranh luận cởi mở về những tính năng hoặc thay đổi mới mà họ có thể đang thực hiện. Khi sản phẩm đã sẵn sàng, công ty chỉ cần giao nó cho khách hàng và tiếp tục hoạt động. Đồng thời, trong trường hợp của Linux, các cuộc thảo luận về những thay đổi nào là cần thiết và - quan trọng nhất - tại sao chúng lại cần thiết, không hề lắng xuống. Tất nhiên, điều này làm cho toàn bộ quá trình trở nên lộn xộn và tốn thời gian hơn nhiều.”
Phát hành sớm, thường xuyên phát hành
Chúng ta không thể đoán trước được tương lai nên chúng ta phải thử:
“Chúng tôi hoạt động theo nguyên tắc “ra mắt sớm, cập nhật thường xuyên”. Vấn đề chính của bất kỳ dự án phần mềm nào là nguy cơ sai sót hoặc lỗi trong mã nguồn. Rõ ràng, càng có nhiều thay đổi và cập nhật được thu thập trong một bản phát hành (phiên bản) phần mềm thì khả năng xảy ra lỗi trong phiên bản này càng cao. Các nhà phát triển phần mềm nguồn mở đã nhận ra rằng bằng cách phát hành các phiên bản phần mềm một cách nhanh chóng và thường xuyên, nguy cơ xảy ra sự cố nghiêm trọng với bất kỳ chương trình nào sẽ giảm đi - xét cho cùng, chúng tôi không đưa tất cả các bản cập nhật ra thị trường cùng một lúc mà lần lượt từng bản cập nhật cho mỗi phiên bản. Theo thời gian, chúng tôi nhận thấy rằng phương pháp này không chỉ giảm sai sót mà còn mang lại nhiều giải pháp thú vị hơn. Hóa ra việc liên tục thực hiện những cải tiến nhỏ sẽ tạo ra nhiều đổi mới hơn về lâu dài. Có lẽ không có gì đáng ngạc nhiên ở đây. Một trong những nguyên tắc chính của các quy trình sản xuất hiện đại như Kaizen a hay Lean B là tập trung vào những thay đổi và cập nhật nhỏ và tăng dần.
[…] Phần lớn những gì chúng tôi làm có thể không thành công. Nhưng thay vì dành nhiều thời gian để tự hỏi điều gì sẽ hiệu quả và điều gì không, chúng tôi thích tiến hành những thử nghiệm nhỏ hơn. Những ý tưởng được ưa chuộng nhất sẽ dẫn đến thành công, còn những ý tưởng không hiệu quả sẽ tự lụi tàn. Bằng cách này, chúng tôi có thể thử nhiều thứ thay vì chỉ một thứ mà không gặp nhiều rủi ro cho công ty.
Đây là một cách hợp lý để phân bổ nguồn lực. Ví dụ, mọi người thường hỏi tôi cách chúng tôi chọn dự án nguồn mở nào để thương mại hóa. Mặc dù đôi khi chúng tôi bắt đầu các dự án nhưng thường thì chúng tôi chỉ đơn giản nhảy vào những dự án hiện có. Một nhóm nhỏ các kỹ sư—đôi khi chỉ một người—bắt đầu đóng góp cho một trong các dự án của cộng đồng nguồn mở. Nếu dự án thành công và được khách hàng yêu cầu, chúng tôi bắt đầu dành nhiều thời gian và công sức hơn cho nó. Nếu không, các nhà phát triển sẽ chuyển sang một dự án mới. Vào thời điểm chúng tôi quyết định thương mại hóa đề xuất, dự án có thể đã phát triển đến mức mà giải pháp trở nên rõ ràng. Nhiều dự án khác nhau, bao gồm cả những dự án không phải phần mềm, tự nhiên xuất hiện trong khắp Red Hat cho đến khi mọi người thấy rõ rằng bây giờ sẽ có người phải làm việc toàn thời gian cho dự án này.”
Đây là một trích dẫn khác từ cuốn sách:
“Tôi nhận ra rằng để đáp ứng được vai trò này, các nhà lãnh đạo trong tương lai phải có những đặc điểm mà các tổ chức thông thường thường bỏ qua. Để lãnh đạo một cách hiệu quả một tổ chức mở, người lãnh đạo phải có những phẩm chất sau.
- Sức mạnh cá nhân và sự tự tin. Các nhà lãnh đạo thông thường sử dụng quyền lực vị trí – vị trí của họ – để đạt được thành công. Nhưng trong chế độ nhân tài, các nhà lãnh đạo phải giành được sự tôn trọng. Và điều này chỉ có thể thực hiện được nếu họ không ngại thừa nhận rằng họ không có tất cả các câu trả lời. Họ phải sẵn lòng thảo luận vấn đề và đưa ra quyết định nhanh chóng để cùng nhóm của mình tìm ra giải pháp tốt nhất.
- Tính kiên nhẫn. Các phương tiện truyền thông hiếm khi kể những câu chuyện về mức độ “kiên nhẫn” của một nhà lãnh đạo. Nhưng anh thực sự phải kiên nhẫn. Khi bạn đang làm việc để đạt được nỗ lực và kết quả tốt nhất từ nhóm của mình, trò chuyện hàng giờ và lặp đi lặp lại mọi việc cho đến khi nó được thực hiện đúng, bạn cần phải kiên nhẫn.
- EQ cao (trí tuệ cảm xúc). Chúng ta thường đề cao trí thông minh của các nhà lãnh đạo bằng cách tập trung vào chỉ số IQ của họ, trong khi điều thực sự cần được tính đến là chỉ số trí tuệ cảm xúc hay còn gọi là điểm EQ của họ. Trở thành người thông minh nhất trong số những người khác là chưa đủ nếu bạn không thể làm việc với những người đó. Khi bạn làm việc với cộng đồng gồm những nhân viên gắn bó như Red Hat và bạn không có khả năng ra lệnh cho bất kỳ ai xung quanh, khả năng lắng nghe, xử lý có phân tích và không coi trọng mọi việc của bạn sẽ trở nên vô cùng quý giá.
- Tâm lý khác nhau. Các nhà lãnh đạo đến từ các tổ chức truyền thống được nuôi dưỡng với tinh thần có qua có lại (tiếng Latin nghĩa là “có qua có lại”), theo đó mọi hành động đều phải nhận được sự đền đáp xứng đáng. Nhưng khi muốn đầu tư xây dựng một cộng đồng cụ thể, bạn cần phải suy nghĩ lâu dài. Nó giống như việc cố gắng xây dựng một hệ sinh thái cân bằng một cách tinh vi, trong đó bất kỳ bước sai lầm nào cũng có thể tạo ra sự mất cân bằng và dẫn đến những tổn thất lâu dài mà bạn có thể không nhận ra ngay. Các nhà lãnh đạo phải loại bỏ tư duy đòi hỏi họ phải đạt được kết quả ngay hôm nay bằng bất cứ giá nào và bắt đầu kinh doanh theo cách cho phép họ thu được lợi ích lớn hơn bằng cách đầu tư vào tương lai.”
Và tại sao nó lại quan trọng
Red Hat sống và hoạt động dựa trên những nguyên tắc rất khác với tổ chức phân cấp truyền thống. Và nó có tác dụng, nó làm cho chúng ta thành công về mặt thương mại và hạnh phúc về mặt nhân văn. Chúng tôi dịch cuốn sách này với hy vọng truyền bá các nguyên tắc tổ chức mở giữa các công ty Nga, giữa những người muốn và có thể sống khác biệt.
, thử nó!
Nguồn: www.habr.com