Gần đây, tôi liên tục suy nghĩ về hai chủ đề có cùng chủ đề. Chủ đề đầu tiên liên quan đến cơ sở hạ tầng công cộng của bang California và mức độ kém hiệu quả của nó trong những năm qua. Thứ hai là sự thất bại của các công ty công nghệ lớn trong việc đổi mới và thực hiện nhanh hơn so với các công ty khởi nghiệp đương nhiệm. Hãy để tôi cung cấp một số quan điểm về lý do tại sao các chủ đề này có liên quan với nhau bằng cách đưa ra hai ví dụ đầu tiên để bạn suy nghĩ:

• Cơ sở hạ tầng : Cầu Cổng Vàng mất khoảng bốn năm để xây dựng (1933–1937) và tiêu tốn của chúng tôi ~500 triệu đô la theo giá đô la ngày nay. Ngược lại, SDS ( Hệ thống ngăn chặn tự tử ), về cơ bản bổ sung một mạng lưới xung quanh cây cầu, sẽ mất 5 năm để hoàn thành (2017–2023) và dự kiến ​​tiêu tốn của chúng tôi ~217 triệu đô la. Nếu bạn xem xét các dự án cơ sở hạ tầng lớn ở California, bạn sẽ thấy rằng đối với các dự án hoàn thành trước những năm 1950, công việc được thực hiện nhanh hơn, rẻ hơn và có chất lượng cao hơn so với hiện nay ít nhất gấp 5 lần, mặc dù ngày nay chúng ta có nhiều vốn hơn, công nghệ tốt hơn, nguyên liệu thô tốt hơn và số lượng kỹ sư và kiến ​​trúc sư dân dụng tuyệt đối cao hơn.
• Các công ty công nghệ : Adobe, bất chấp tất cả các nguồn tài chính và nhân lực của mình, thấy mình phải mua một đối thủ cạnh tranh với giá 20 tỷ đô la. Vẫn còn phải xem liệu Adobe có trả quá cao cho Figma hay không, nhưng câu hỏi thú vị hơn là tại sao một công ty có nhân sự gấp 100 lần, bề dày kinh nghiệm gấp 100 lần về công cụ thiết kế và vốn tài chính gấp 100 lần lại không giành được?

Tương tự, nếu bạn xem xét bên trong các công ty, bạn có thể thấy rằng khi họ phát triển, quy trình và sự phình to len lỏi vào mọi thứ và bóp nghẹt công việc thực sự cũng như sự đổi mới. Trong môi trường đó, những nhân viên háo hức nhất để tạo ra mọi thứ, những người chế tạo, thấy rằng sẽ hấp dẫn hơn khi chuyển đến một nơi nhỏ hơn, nơi công việc của họ có một lối thoát để hiện thực hóa. Cả thất bại về cơ sở hạ tầng và thất bại trong đổi mới của công ty ít nhất một phần là do sự phình to và chậm chạp của quy trình.

Tại sao quá trình creep xảy ra?

Mọi quá trình đều bắt đầu với ý định tốt.

• “Chúng tôi muốn đảm bảo rằng tất cả các bên liên quan đều có ý kiến ​​đóng góp cho công việc cuối cùng, vì vậy tất cả các đề xuất dự án đã gửi cần được xem xét bởi các nhóm pháp lý, thiết kế, sản phẩm và kỹ thuật.”
• “Chúng tôi muốn đảm bảo rằng các dự án cơ sở hạ tầng lớn không gây hại, vì vậy chúng tôi cần thực hiện các nghiên cứu kỹ lưỡng về môi trường trước khi bắt đầu bất kỳ công việc nào.”
• “Chúng tôi muốn giảm thiểu vi phạm dữ liệu, vì vậy mọi yêu cầu về dữ liệu cần phải được thực hiện thông qua nhóm CNTT và Bảo mật.”

Con đường dẫn đến chủ nghĩa hoàn hảo

Tôi nhớ đã nghe một người quản lý có thiện chí nói với cấp dưới trực tiếp của mình rằng hãy viết phần mềm như thể nó sẽ tồn tại 100 năm. Mặc dù lời nhận xét là cường điệu, nhưng lời khuyên lặp lại một điều mà tôi thường nghe trong ngành công nghệ thông qua những câu ngạn ngữ như “đo hai lần và viết một lần” hoặc “nếu bạn không có thời gian để làm đúng, bạn có thời gian để làm không nó hai lần? Đây không phải là lời khuyên tồi. Trong một số tình huống, bạn phải viết mã như thể nó sẽ tồn tại 100 nămvà lao đầu vào thực hiện mà không lập kế hoạch là lãng phí. Tuy nhiên, quá chú trọng vào việc lập kế hoạch có thể dẫn đến tê liệt và không nhận ra lợi ích của việc học thông qua lặp đi lặp lại. Tôi thà sống trong một thế giới mà phần mềm được viết lại hàng năm bởi vì có một sự thừa nhận mạnh mẽ rằng sự hoàn hảo không tồn tại và điều kiện tiên quyết cho sự tiến hóa là sự thay đổi, thay vì một thế giới nơi mọi thứ chạy trên “ cơ sở mã 50 năm tuổi ”.

Quá nhiều keo

Nhiều năm trước, tôi đã đọc bài đăng trên blog của Tanya Reilly về việc trở thành Keo (rất nên đọc, btw). Vào thời điểm đó trong sự nghiệp của tôi, nội dung thực sự gây được tiếng vang vì tôi đang làm việc với một số đồng nghiệp mặc dù có năng lực về mặt kỹ thuật nhưng lại không làm việc đúng hướng. Những người gắn kết tham gia vào một quá trình lãnh đạo kỹ thuật và cố vấn dẫn đến việc làm cho những người khác trong nhóm làm việc hiệu quả hơn. Tuy nhiên, một số lượng keo là cần thiết, tuy nhiên, tôi thấy rằng quá nhiều keo sẽ tạo ra một loạt các vấn đề khác:

• Những người làm công việc dán keo ngăn cản người khác cải thiện các kỹ năng phi kỹ thuật của họ. Ví dụ: Trưởng nhóm công nghệ không để nhóm của họ nói về công việc của họ hoặc thường hoạt động như một “bộ đệm” về cơ bản là lấy đi cơ hội của các IC để đấu tranh và cuối cùng là cải thiện kỹ năng giao tiếp của họ.
• Các phiên bản cực đoan và độc hại của hành vi keo đôi khi thể hiện ở việc coi thường công việc của người khác hoặc tạo ra sự quy kết phóng đại quá mức (“ví dụ: nếu không có tôi đóng vai trò trung gian, dự án sẽ không thành công”). Trong khi Tanya nói về những tình huống mà những người Keo thường không được thừa nhận, thì trải nghiệm của tôi lại hoàn toàn ngược lại. Bởi vì những người Keo là những người giao tiếp tốt, họ biết cách quảng cáo công việc của mình và chơi chính trị giỏi. Đổi lại, họ sẽ có khả năng hiển thị cao hơn và nhiều cơ hội thăng tiến hơn, trong khi kỹ sư làm việc về chi tiết triển khai thường nhận được xác nhận mã thông báo hoặc không có tín dụng nào cả.
• Cuối cùng, việc thêm quá nhiều người gắn bó sẽ làm giảm quyền sở hữu và trách nhiệm giải trình của từng kỹ sư. Thay vì bổ sung những người gắn kết để quản lý một nhóm có năng lực kỹ thuật, tôi chỉ đơn giản là loại bỏ những kỹ sư dường như không có trực giác kinh doanh, thiếu kỹ năng giao tiếp hoặc không thể viết một đoạn văn mô tả lý do tại sao công việc họ làm lại có tác động. Đề xuất rằng bạn cần thêm chất keo để quản lý các kỹ sư cuối cùng lại bác bỏ mô hình chung rằng những người xuất sắc về kỹ thuật cũng có trí thông minh chung cao, đọc nhiều, học hỏi suốt đời và rất giỏi kinh doanh chứ không chỉ viết mã.

Khi tôi còn ở Novell, tôi đã học được rằng có những người mà tôi gọi là “những người keo kiệt”. Những người keo dán là những người cực kỳ tốt bụng ngồi ở ranh giới kẽ giữa các nhóm và họ hỗ trợ trong hoạt động. Và họ rất, rất trung thành, và mọi người yêu mến họ, và bạn không cần họ chút nào.

Tại Novell, tôi luôn cố gắng loại bỏ những người keo kiệt này, bởi vì họ đang cản đường, bởi vì họ làm mọi thứ chậm lại. Và mỗi khi tôi loại bỏ họ trong một nhóm, họ sẽ xuất hiện trong một nhóm khác, và họ sẽ chuyển đi, được tuyển dụng lại và tất cả những thứ đó.

Sự hỗn loạn

Khi các tổ chức phát triển, kiến ​​thức thể chế, số lượng các bên liên quan, cơ sở mã và entropy tăng lên. Entropy tăng dẫn đến lãng phí cao, tải nhận thức cao, vô tổ chức và hỗn loạn.

Với tư cách là kỹ sư phần mềm, tôi nghĩ chúng tôi đã thực hiện một công việc dở tệ trong việc quản lý độ phức tạp. Ví dụ: trong nhiều năm, chúng tôi đã nghe nói rằng nguyên khối là xấu vì chúng tạo ra cơ sở mã cồng kềnh, gây khó khăn cho việc triển khai hoặc tạo ra sự cố với khả năng mở rộng. Tuy nhiên, ở một khía cạnh khác, nơi chúng tôi phải hoạt động trong một thế giới của các dịch vụ siêu nhỏ, tôi nhận thấy rằng để vận chuyển những thứ cơ bản, tôi cần vận hành trên nhiều cơ sở mã được viết bằng các ngôn ngữ khác nhau, mỗi cơ sở đều có các đặc điểm triển khai và mẫu kiến ​​trúc riêng, với toàn bộ mô hình biến thành mì spaghetti lambda . Dừng lại và tập trung lại vào những gì quan trọng có tác động lớn đến việc giảm entropy. Ở cấp độ thấp, định hướng hành động, nó có thể biểu hiện như sau:

• Xóa mã chết không được thực thi trong sản xuất. Tôi đã tương tác với rất nhiều cơ sở mã trong đó >50% mã là mã chết và tạo ra gánh nặng nhận thức cho đồng nghiệp. Tôi ước có thứ gì đó trong không gian năng suất của nhà phát triển tạo ra phạm vi mã dựa trên các dòng được thực thi trong quá trình sản xuất. Mỗi quý, bạn dừng lại và xem xét các báo cáo đó và chỉ cần xóa các tệp không thực thi.
• Với tư cách là người quản lý sản phẩm, chúng tôi không suy nghĩ đầy đủ về những tính năng nào chúng tôi nên loại bỏ hoặc hoàn nguyên. Tuy nhiên, việc dừng lại và suy nghĩ về những gì nên xóa có thể rất có ý nghĩa trong việc đơn giản hóa và cải thiện trải nghiệm người dùng. Tôi tự coi mình là người am hiểu công nghệ, nhưng tôi thấy rằng nhiều sản phẩm được tạo ra ngày nay đã được siêu tối ưu hóa trên một nhóm người dùng hiện tại, dẫn đến trải nghiệm UX lộn xộn và khó hiểu cho người dùng mới. Hỏi vào cuối quý "Chúng tôi có thể bỏ tính năng nào?" có thể hữu ích trong việc giảm sự lộn xộn.

Bản ngã là kẻ thù

Ryan Holiday gợi ý trong cuốn sách Bản ngã là kẻ thù của anh ấy, có một “sự cám dỗ mạnh mẽ tồn tại đối với tất cả mọi người - để nói chuyện và thổi phồng để thay thế hành động.” Cái tôi là một lý do lớn tại sao sự tiến bộ và đổi mới có thể mờ nhạt ở nhiều tổ chức. Đây là cách cái tôi thể hiện:

• Nhìn thấy những người giống nhau nóng lòng bày tỏ suy nghĩ của họ vào một cuộc trò chuyện nhóm, mặc dù ý tưởng của họ không mang lại hoặc có rất ít giá trị biên.
• Có những người không bao giờ tích cực tài trợ cho đồng nghiệp của họ hoặc những người cố gắng tích trữ tầm nhìn. Nếu bạn là người quản lý hoặc người quản lý của những người quản lý, bạn có thể nhận thấy điều này bằng cách xem tần suất báo cáo trực tiếp của bạn nói về những thành công hoặc đóng góp của người khác trong 1:1 của bạn. Thiếu sự thừa nhận hoặc tài trợ vị tha của những người khác có thể là dấu hiệu của một cái tôi không lành mạnh.
• Tối ưu hóa cho nhóm thay vì toàn bộ công ty hoặc tổ chức. Tôi đã mượn sơ đồ từ Con đường của kỹ sư nhân viên của Tanya Reilly và nó minh họa hoàn hảo vấn đề này khi các nhóm tối ưu hóa cho mức tối đa cục bộ. Ví dụ: bạn có đồng ý giải tán nhóm của mình và phân bổ lại nhân viên cho các nhóm khác nếu trong miền của bạn, bạn đang chuyển sang chế độ bảo trì không? Hầu hết các nhà quản lý sẽ không bao giờ làm điều đó bởi vì điều đó có nghĩa là mất đi bất kỳ vốn xã hội và chính trị nào trong công ty.

• Tùy thuộc vào vai trò của bạn, có sự khác biệt rất lớn về cách bạn nhìn nhận giá trị của các cuộc họp. “ Những người quyền lực nhất đều nằm trong lịch trình của người quản lý ”. Thật không may, nhận thức của họ về giá trị của các cuộc họp tạo ra một văn hóa đè lên ảnh hưởng đến những người thích có thời gian không bị gián đoạn để suy nghĩ về một vấn đề và giải pháp. Ngay cả đối với mục đích động não, bằng chứng cho thấy rằng động não theo nhóm là một sự lãng phí thời gian . Tuy nhiên, tại sao nhiều tổ chức cồng kềnh lại có đến một nửa thời gian của các IC dành cho các cuộc họp?

Phần kết luận

Động cơ của sự đổi mới dựa trên sự thay đổi mang tính tiến hóa. Cuối cùng, nếu một thể chế trở nên cứng nhắc và không thích ứng với sự thay đổi, nó sẽ chết dần chết mòn. Theo kinh nghiệm của tôi, việc giới thiệu một quy trình thường có những chi phí ngoài ý muốn dẫn đến giảm vận tốc. Thay vào đó, tôi sẽ tập trung vào những điều sau:

• Thích lặp đi lặp lại và học hỏi từ những sai lầm thay vì cố gắng đạt được chủ nghĩa hoàn hảo.
• Những người gắn kết là cần thiết, nhưng số lượng của họ phải có giới hạn để họ có thể hành động với đòn bẩy cao. Đơn giản chỉ cần thuê những người vừa có năng lực kỹ thuật vừa có trực giác kinh doanh tốt là có thể giải quyết nhu cầu tuyển dụng quá nhiều cho các vị trí keo dán.
• Cuối cùng, tôi sẽ tập trung vào việc giảm entropy bằng cách liên tục hỏi những gì có thể bị loại bỏ và thưởng cho những người có hành vi làm tăng tính đơn giản.