Làm việc trong Big Corp: Align, quy trình và cách hoàn thành việc ở quy mô lớn

Điều đầu tiên khiến người ta bất ngờ khi từ công ty nhỏ chuyển sang một công ty lớn không phải là phúc lợi hay sơ đồ tổ chức. Đó là việc một cá nhân kiểm soát ít đến mức nào trong cả hệ thống — mà nó vẫn chạy tốt. Bạn đến với kỳ vọng về sự kém hiệu quả, và bạn tìm thấy một cỗ máy ship phần mềm đáng tin cậy cho hàng triệu người, vận hành theo những luật bạn không viết, và gần như chẳng nhận ra nếu một kỹ sư bất kỳ biến mất một tháng.

Đó không phải lời xúc phạm; đó là thiết kế. Big corp được tối ưu cho quy mô và độ tin cậy, không phải cho tốc độ của bất kỳ cá nhân nào. Khi hiểu được điều đó, những thứ ban đầu gây bực bội — họp, phê duyệt, tài liệu — thôi trông giống quan liêu-vì-quan liêu và bắt đầu trông giống cái giá của việc vận hành ở quy mô lớn. Đây là hướng dẫn thực tế để làm việc tốt bên trong cỗ máy đó: việc của bạn nằm ở đâu, vì sao align mới là công việc thật, làm sao thực sự ship được, và phát triển ra sao.

Đây là bài đào sâu đầu tiên sau bài tổng quan so sánh big corp, startup và outsourcing — nên ở đây ta đi thẳng vào thế giới tập đoàn.

"Lớn" thực sự thay đổi điều gì

Quy mô không chỉ thêm người; nó thay đổi vật lý của công việc. Ba thứ bị đảo chiều:

• Bán kính sát thương (blast radius). Một bug bạn ship có thể ảnh hưởng hàng triệu người dùng, hệ thống của team khác, doanh thu, hoặc compliance. Cái giá của "đi nhanh và làm vỡ đồ" không còn là một cái nhún vai — nó là một buổi incident review.
• Chi phí phối hợp. Với hàng chục team động vào hệ thống chung, phần đắt đỏ không phải viết code — mà là đảm bảo thay đổi của bạn khớp với của mọi người. Giao tiếp, chứ không phải gõ phím, trở thành nút thắt.
• Tính lâu bền. Người thì luân chuyển, nhưng hệ thống sống cả thập kỷ. Quyết định phải đọc hiểu được bởi những kỹ sư còn chưa vào công ty, đó là lý do rất nhiều thứ được ghi lại.

Gần như mọi điều đặc trưng của đời sống big corp đều bắt nguồn từ ba thứ đó. Giữ chúng trong đầu thì phần còn lại thôi bí ẩn.

Việc của bạn nằm ở đâu: hệ thống lập kế hoạch phân tầng

Ở startup bạn thường thấy cả cái bảng. Ở big corp bạn thấy ô vuông của mình, và cái bảng thì rất lớn. Việc đi xuống qua nhiều tầng:

Đến lúc một ticket tới tay bạn, cái "tại sao" nằm cao hơn vài tầng. Đây là con dao hai lưỡi nổi tiếng của đời sống tập đoàn: rõ ràng nhưng đánh đổi bằng khoảng cách. Bạn hiếm khi phải tự hỏi việc mình có quan trọng không — đã có người quyết là có — nhưng bạn dễ mất tầm nhìn về việc nó quan trọng như thế nào. Những kỹ sư phát triển tốt cố ý leo cái thang đó trong đầu: họ đọc OKR, hỏi epic của mình phục vụ mục tiêu nào, và nối lại ticket hằng ngày với một kết quả cho khách hàng. Chỉ một thói quen đó đã tách người thấy mình như mắt xích khỏi người thấy mình là chủ một mảnh nhỏ nhưng có thật.

Align mới là công việc thật

Đây là điều không ai nói trước với bạn ở vai trò enterprise đầu tiên: một phần lớn công việc kỹ sư cấp cao không phải là code. Đó là align — khiến nhiều người đồng ý về một hướng đi trước khi có ai bắt tay xây. Đó không phải sự kém hiệu quả; với chi phí phối hợp cao, align chính là sự hiệu quả. Phương án thay thế — ai cũng xây phiên bản của mình rồi hòa giải sau — đắt hơn nhiều.

Align chạy bằng các sản phẩm văn bản, vì viết thì mở rộng được còn họp thì không:

Cũng bản năng đó hiện ra trong code review, nơi một pull request rõ ràng tự nó là một hành động align — xem Cách viết một Pull Request tuyệt vời. Ở quy mô lớn, khả năng viết của bạn chính là tầm với của bạn.

Quy trình không (chỉ) là quan liêu

Những cái cổng tạo cảm giác cản trở thường tồn tại vì một thứ gì đó đắt đỏ đã từng hỏng. Một buổi security review tồn tại vì một vụ rò rỉ từng tốn hàng triệu. Một bước change-management tồn tại vì một lần deploy không review đã làm sập thanh toán đúng ngày lễ. Một khâu QA chính quy tồn tại vì một regression từng tới tay những khách hàng không chịu nổi nó.

Điều đó không có nghĩa mọi quy trình đều chính đáng. Rất nhiều cái là cargo cult — nghi thức sao chép từ một bối cảnh nó hợp lý sang một bối cảnh nó vô nghĩa, được bảo vệ bằng câu "ở đây làm vậy". Kỹ năng là phân biệt hai loại:

• Quy trình xứng đáng bảo vệ trước một thất bại thật, đắt đỏ, có khả năng xảy ra. Hãy tôn trọng nó, và học lý lẽ phía sau để đi qua nó nhanh.
• Trình diễn (theatre) không bảo vệ trước thứ gì đo được và chủ yếu sinh ra các bản cập nhật trạng thái. Hãy đặt câu hỏi — lịch sự, có dữ liệu, qua đúng người — và bạn sẽ là một trong những người làm tổ chức tốt hơn thay vì chỉ than phiền.

Sâu, hẹp, và phụ thuộc vào người khác

Ở big corp bạn thường sở hữu một lát — một service, một subsystem, một domain — và sở hữu nó sâu. Mặt còn lại là bạn phụ thuộc vào các team chuyên môn cho mọi thứ ngoài cái lát đó: SRE cho production, DBA cho dữ liệu, team platform cho hạ tầng, team design-system cho UI, security để duyệt, team release cho con đường lên production.

Điều này hiệu quả, nhưng nghĩa là một phần đáng ngạc nhiên trong hiệu suất của bạn đến từ việc làm việc xuyên ranh giới: biết ai sở hữu cái gì, xây quan hệ trước khi cần nhờ vả, viết ticket mà team khác hành động được, và tôn trọng hàng đợi cùng ràng buộc của họ. Kỹ sư coi team khác là chướng ngại thì bị kẹt; kỹ sư coi họ là đối tác thì được khơi thông. Nếu bạn đến từ startup nơi bạn cứ tự đổi database, đây là sự điều chỉnh lớn nhất — và học cách handoff cho tốt là một kỹ năng thật, không phải một bước lùi.

Làm sao thực sự ship được bên trong cỗ máy

Ship ở big corp ít liên quan tới tốc độ code thô và liên quan nhiều hơn tới khả năng điều hướng. Vài chiến thuật luôn hiệu quả:

• Tìm người ra quyết định thật. Sơ đồ tổ chức cho biết chức danh; công việc cho biết ai thực sự khơi thông được. Xác định họ sớm và lôi kéo họ vào trước khi bạn đã xây xong, không phải sau.
• Viết tài liệu trước. Một bản đề xuất một trang làm lộ ra các phản đối khi chúng còn rẻ để xử lý, và tạo một bản ghi bảo vệ bạn về sau.
• Làm thay đổi nhỏ và có thể đảo ngược. Feature flag, rollout từng phần, và các bước tương thích ngược đi qua chuỗi review nhanh hơn thay đổi kiểu một-phát-ăn-ngay, vì chúng ít rủi ro để duyệt.
• Bàn trước, đừng phục kích. Dắt các reviewer chính đi qua kế hoạch của bạn từ trước. Một cuộc họp review nên là nơi xác nhận một thỏa thuận, chứ không phải nơi người ta lần đầu nghe ý tưởng của bạn.
• Tôn trọng hàng đợi của team khác. Cho dependency thời gian báo trước. "Tôi cần cái này hôm nay" với một team lập kế hoạch theo sprint sẽ thất bại; cũng yêu cầu đó nhưng báo trước hai tuần thì thành công.

Stakeholder và chính trị — loại lành mạnh

"Chính trị" mang tiếng xấu, nhưng trong một tổ chức lớn nó là điều không tránh khỏi và không tự bản chất là bẩn. Kỹ năng chính trị lành mạnh chỉ đơn giản là: hiểu những người khác nhau quan tâm điều gì và giúp căn chỉnh chúng lại. Việc của bạn ảnh hưởng tới roadmap của một product manager, độ tin cậy của một team khác, OKR của một director. Làm những lợi ích đó hiện rõ, và cho thấy kế hoạch của bạn phục vụ chúng ra sao, là cách mọi thứ được duyệt và cấp ngân sách.

Phiên bản độc hại — giành công, giấu thông tin, hạ bệ đồng nghiệp — cũng tồn tại, và đáng gọi tên ra để bạn tránh làm và nhận ra khi nó nhắm vào mình. Nhưng đừng nhầm quản lý stakeholder với thao túng. Làm với sự chính trực, nó chỉ là phiên bản cấp cao của làm việc nhóm ở quy mô lớn.

Những failure mode cần đề phòng

Công ty lớn có những cách rất đặc trưng để bào mòn con người. Biết chúng là một nửa của sự phòng vệ:

Phát triển ở đây ra sao

Công ty lớn thường có ladder sự nghiệp rõ ràng nhất trong ba thế giới — cấp bậc được định nghĩa, kỳ vọng viết ra, và thăng tiến có hiệu chuẩn nơi một hội đồng, không chỉ sếp bạn, xét hồ sơ của bạn. Đó là một món quà: luật chơi đọc được. Để leo nó:

• Tăng phạm vi ảnh hưởng, không phải số giờ. Thăng tiến bám theo kích thước và bề rộng của vấn đề bạn sở hữu — từ task của bạn, tới team của bạn, tới xuyên nhiều team.
• Làm cho ảnh hưởng của bạn hiện rõ. Trong tổ chức lớn, việc không được truyền đạt thì coi như không tồn tại. Viết tài liệu, demo, chia sẻ chiến thắng (và cả công lao).
• Xây thành tích đưa việc liên-team về đích. Hành vi được tưởng thưởng — dẫn dắt align và giảm rủi ro — chính xác là bộ kỹ năng cấp cao.
• Tìm người bảo trợ (sponsor), không chỉ mentor. Mentor khuyên bạn; sponsor lên tiếng cho bạn trong căn phòng nơi quyết định thăng tiến.

Nếu sau tất cả những điều này bạn thấy nhịp quá chậm hoặc khoảng cách tới khách hàng quá xa, đó là sự tự hiểu mình hữu ích — có thể một startup hoặc sự đa dạng của outsourcing hợp với bạn hơn lúc này. Không cái nào là cánh cửa một chiều.