Ở các bài trước, tôi cho rằng xây dựng một Design Team không phải là bài toán tuyển đủ headcount, mà là bài toán kết hợp đúng những năng lực để phục vụ chiến lược kinh doanh.
Trong bài viết này, tôi muốn dùng từ scale theo một nghĩa khác. Scale không chỉ là tăng số lượng designer. Theo tôi, scale trước hết là sự trưởng thành về năng lực của tổ chức, sau đó mới đến quy mô đội ngũ. Thực tế có những công ty hàng trăm nhân viên nhưng đội ngũ thiết kế vẫn chỉ gồm vài người, và điều đó hoàn toàn không có gì bất thường.
Phần lớn những mô hình tổ chức Design mà chúng ta biết ngày nay đều được hình thành từ các công ty công nghệ và sản phẩm số trên thế giới. Trong bài viết này, tôi tham khảo một phần bộ khung từ cuốn Org Design for Design Orgs của Peter Merholz và Kristin Skinner, đồng thời đối chiếu với những bài viết gần đây của Peter về Design Organization. Tuy vậy, tôi không xem đây là một mô hình chuẩn để áp dụng nguyên vẹn. Theo tôi, mọi doanh nghiệp vẫn cần điều chỉnh cho phù hợp với quy mô, chiến lược và bối cảnh thực tế của mình.
Theo tôi, sự thay đổi lớn nhất khi Design bắt đầu scale không nằm ở số lượng designer, mà ở việc Design chuyển từ giải quyết bài toán của từng sản phẩm riêng lẻ sang xây dựng năng lực chung cho cả tổ chức.
Scale không bắt đầu từ số lượng designer
Có một thời điểm trong quá trình quản trị của mình, khi thấy công việc chồng chéo và chất lượng thiết kế thiếu đồng nhất giữa các nhóm và cá nhân, phản ứng tự nhiên đầu tiên của tôi là tìm hiểu khả năng của từng người, sau đó đối chiếu với những gì sản phẩm và tổ chức yêu cầu.
Và tôi nhận ra vấn đề hiếm khi nằm ở con người, mà nằm ở cách tổ chức để những designer hiện có cùng làm việc hiệu quả. Từ đó tôi nhận ra, khi Design bắt đầu gặp vấn đề, phản ứng đầu tiên không nên là tuyển thêm người, mà là xem lại cách đội ngũ đang được tổ chức.
Một hiểu lầm khá phổ biến là: Team càng đông người thì càng cần tổ chức phức tạp.
Điều này không hoàn toàn đúng. Tôi từng chứng kiến những team chỉ 3–5 designer nhưng việc phối hợp đã rất rối ren. Ngược lại, có những tổ chức hàng chục designer vẫn vận hành khá trơn tru. Điều tạo nên sự khác biệt không nằm ở số lượng đầu người, mà nằm ở độ phức tạp của bài toán, kỳ vọng của tổ chức và chi phí phối hợp.
Sự phức tạp xuất hiện khi doanh nghiệp bắt đầu mở rộng:
- Phục vụ nhiều nhóm sản phẩm cùng lúc thay vì một nhóm duy nhất.
- Xử lý sản phẩm có hàng chục luồng trải nghiệm và điểm chạm khách hàng khác nhau.
- Nhiều nhóm cùng can thiệp và thay đổi trên một hệ thống Design System.
- Cùng một tổ chức nhưng tồn tại các nhóm có chiến lược cạnh tranh khác nhau (Phòng thủ, Phản ứng, Tiên phong hay Phân tích).
Khi kỳ vọng tăng lên, số lượng các mối liên kết tăng nhanh hơn số lượng con người. Đó mới là lúc Design cần nghĩ đến việc scale về mặt chất lượng lẫn mô hình vận hành.
Dấu hiệu cho thấy Design cần thay đổi cách tổ chức
Trong thực tế, doanh nghiệp thường chỉ nhận ra mình cần scale khi các "triệu chứng" vận hành bắt đầu xuất hiện lặp đi lặp lại:
- Về phía tổ chức/ sản phẩm: Trải nghiệm sản phẩm tạo ra khoảng cách chất lượng lớn về trải nghiệm so với đối thủ; hiệu quả đầu tư (ROI) của đội ngũ phát triển và tiếp thị không cải thiện; sản phẩm thiếu phản biện từ người dùng một phần vì designer không được tham gia từ đầu. Sản phẩm không được cập nhật, đổi mới định kỳ.
- Về phía công việc hằng ngày: Cùng một thành phần giao diện nhưng mỗi team làm một kiểu; các nhóm mất thời gian xử lý lại những quyết định thiết kế đã được người khác giải quyết trước đó; designer dành nhiều thời gian "quản lý mâu thuẫn bên liên quan" hơn là giải quyết bài toán người dùng; lập trình viên tự chỉnh sửa giao diện để kịp tiến độ; quy trình duyệt thiết kế chậm trễ vì thiếu tiêu chuẩn chung; thiết kế phải chạy theo tốc độ của nhóm lập trình.
Khi xuất hiện từ 3 dấu hiệu trở lên, tổ chức bắt đầu coi thiết kế là một "điểm nghẽn". Vấn đề lúc này hiếm khi nằm ở năng lực cá nhân của từng designer, mà xuất phát từ việc tổ chức chưa có phương pháp để giúp đội ngũ làm việc như một hệ thống.
Bên cạnh đó, Peter Merholz cũng cho rằng một nhóm thiết kế hiệu quả thường chỉ nên gồm khoảng 4–6 designer dưới sự dẫn dắt trực tiếp của một Design Manager. Khi quy mô vượt quá ngưỡng này, chi phí phối hợp, coaching và ra quyết định bắt đầu tăng lên. Đây chưa phải là dấu hiệu doanh nghiệp cần một Design Organization phức tạp hơn, nhưng là thời điểm nên xem lại cấu trúc đội ngũ và cách phân chia trách nhiệm.
Khi doanh nghiệp không còn cạnh tranh bằng Feature
Ở giai đoạn đầu, các startup cạnh tranh chủ yếu bằng tốc độ: Ra tính năng nhanh hơn, tìm Product-Market Fit trước. Lúc này, một vài Product Generalist linh hoạt sẽ tạo ra nhiều giá trị hơn một bộ máy thiết kế phức tạp.
Nhưng khi thị trường trưởng thành, lợi thế cạnh tranh bắt đầu dịch chuyển. Một tính năng (feature) mới ở giai đoạn đầu có thể tạo ra khác biệt rất lớn, nhưng về sau, khoảng cách tính năng giữa các sản phẩm ngày càng thu hẹp. Đối thủ có thể sao chép một tính năng chỉ trong vài tuần hoặc vài tháng.
Điều khó sao chép hơn lại là tốc độ học hỏi của tổ chức, chất lượng trải nghiệm, sự nhất quán và khả năng vận hành sản phẩm ở quy mô lớn.
Lúc này, doanh nghiệp không còn cạnh tranh chủ yếu bằng tính năng. Họ cạnh tranh bằng khả năng vận hành và mở rộng sản phẩm một cách bền vững. Đó chính là lý do Design cần scale — chuyển từ việc "tạo ra từng màn hình" sang "xây dựng năng lực cho cả tổ chức".
3 Mô hình tổ chức qua góc nhìn thực tế
Theo tôi, đây không phải ba cấp độ trưởng thành (maturity levels). Một doanh nghiệp hoàn toàn có thể chuyển đổi qua lại giữa các mô hình khi chiến lược kinh doanh thay đổi.
Centralized (Tập trung) ◄──► Embedded (Phân tán) ◄──► Central Partnership (Đối tác tập trung)
- Centralized (Tập trung): Designer thuộc chung một Design Team dưới sự dẫn dắt của Design Leader. Góc nhìn thực tế: Rất tốt ở giai đoạn đầu để xây dựng văn hóa, quy trình và tiêu chuẩn thống nhất. Tuy nhiên, hạn chế lớn nhất là nhóm dễ bị xem như một phòng ban làm dịch vụ nội bộ, tư tưởng "nhóm mình vs nhóm khác", xa rời ngữ cảnh sản phẩm và bị các nhóm khác phàn nàn là bàn giao chậm.
- Embedded (Phân tán): Designer cắm chốt trực tiếp và báo cáo trong từng nhóm sản phẩm. Góc nhìn thực tế: Cho tốc độ thực thi rất nhanh - Đây là mô hình rất phổ biến ở các công ty phát triển sản phẩm theo mô hình squad hoặc cross-functional team. Nhưng về lâu dài, designer bị xé lẻ, thiếu sự phản biện chuyên môn từ đồng nghiệp và thiếu lộ trình thăng tiến. Nếu thiếu các tiêu chuẩn chung, sản phẩm sẽ nhanh chóng bị rời rạc và tốn chi phí bảo trì.
- Central Partnership (Matrix / Đối tác tập trung): Designer thuộc về tổ chức thiết kế (về chuyên môn & con người) nhưng cắm chốt làm việc hằng ngày trong từng nhóm sản phẩm. Góc nhìn thực tế: Đây là mô hình được đánh giá phù hợp nhất cho các sản phẩm phức tạp quy mô lớn (Fintech, Ngân hàng, SaaS). Thay vì chia designer theo từng tính năng lẻ tẻ, nhóm Design được tổ chức xoay quanh Hành trình người dùng (User Journey), ví dụ chia nhóm phục vụ luồng cá nhân, hoặc luồng doanh nghiệp trong ngân hàng. Mô hình này giúp cân bằng giữa tốc độ thực thi của từng team và sự nhất quán xuyên suốt toàn bộ trải nghiệm khách hàng.
Khi scale, Capability nên trở thành một Role riêng
Nói cách khác, chức danh (role) chỉ là biểu hiện bên ngoài của năng lực (capability). Đừng tạo ra một chức danh chỉ vì thấy các công ty lớn đang có. Một năng lực chỉ nên tách thành một vị trí riêng khi nó đạt đủ 4 yếu tố: Đủ quan trọng, đủ phức tạp, đủ khối lượng công việc dài hạn và tạo ảnh hưởng xuyên suốt nhiều nhóm.
Dưới đây là những vai trò chuyên biệt thường xuất hiện khi bộ máy thiết kế lớn lên:
- Design Technologist / Design Engineer: Vai trò kết nối giữa thiết kế và công nghệ. Nếu Design System giúp chuẩn hóa giao diện, thì nhóm này giúp chuẩn hóa cách Design khai thác công nghệ — từ việc tạo prototype bằng code, đồng bộ giữa Figma và mã nguồn, đến ứng dụng AI và tự động hóa quy trình để tăng năng suất cho toàn đội.
- UX Researcher: Khi sản phẩm và tổ chức phát triển, việc nghiên cứu trở nên chuyên sâu và diễn ra liên tục hơn. UX Researcher chịu trách nhiệm lập kế hoạch nghiên cứu, thu thập và phân tích dữ liệu định tính, định lượng, từ đó giúp đội ngũ hiểu đúng nhu cầu người dùng, giảm rủi ro khi ra quyết định và cải thiện hiệu quả của các vòng lặp thiết kế (design iteration).
- Service Designer: Không phải mọi doanh nghiệp đều cần Service Designer - người thiết kế theo dõi toàn bộ dịch vụ, thay vì chỉ tập trung thiết kế một sản phẩm hay một màn hình. Họ đảm bảo trải nghiệm khách hàng xuyên suốt nhiều điểm chạm như ứng dụng, website, cửa hàng, tổng đài và các quy trình vận hành nội bộ. Capability này chỉ thực sự cần thiết khi doanh nghiệp có sơ đồ dịch vụ (Service Blueprint) đủ phức tạp, như ngân hàng, bảo hiểm, bệnh viện hay logistics.
- Design Program Manager (DPM): Khác với Product Owner chịu trách nhiệm cho một sản phẩm cụ thể, Design Program Manager chịu trách nhiệm điều phối những sáng kiến thiết kế ảnh hưởng tới nhiều sản phẩm cùng lúc (Design System, Accessibility, Re-branding), đảm bảo mọi chiến lược được triển khai nhất quán và đúng lộ trình.
- DesignOps: Khi đội ngũ lớn dần, DesignOps giúp chuẩn hóa quy trình, công cụ, onboarding, lập kế hoạch nguồn lực và các hoạt động vận hành của tổ chức thiết kế. Đây là năng lực giúp designer dành nhiều thời gian hơn cho việc giải quyết bài toán thiết kế thay vì các công việc điều phối.
(Trong bối cảnh mỗi tổ chức tùy quy mô, các vai trò này không nhất thiết phải tuyển một vị trí riêng biệt ngay lập tức, mà có thể là một nhóm kỹ năng chuyên sâu được đầu tư cho nhân sự sẵn có).
Hiện tại với sự xuất hiện của AI, theo tìm hiểu cuả tôi thì các nhóm đã hầu như thu nhỏ số lượng khoảng 30-50%. Nhưng nên nhớ các nhóm có thể thu nhỏ vì năng suất từng vị trí đã tăng lên chứ không phải loại bỏ một vai trò nào đó. Hiện tại trong quá trình sản xuất phần mềm, AI hoặc chuyển đổi vai trò, chứ chưa thể thay thế hoàn toàn bất cứ vị trí nào.
Scale không phải là thêm người
Sau cả bốn bài viết, điều tôi muốn nhấn mạnh nhất là: Scale là xây dựng những năng lực có thể được lặp lại, chia sẻ và mở rộng trong toàn tổ chức. Đó là hành trình dịch chuyển tư duy:
Design as Execution → Design as Organizational Capability
Xâu chuỗi lại cả series, chúng ta sẽ thấy Design dần được nhìn ở những cấp độ khác nhau:
- Bài 1: Trước khi tuyển designer, hãy hiểu doanh nghiệp thực sự cần Design để tạo ra giá trị gì.
- Bài 2: Khi đã hiểu chiến lược, hãy xác định doanh nghiệp cần những năng lực nào thay vì chỉ nhìn vào chức danh tuyển dụng.
- Bài 3: Khi xây dựng đội ngũ, mục tiêu không phải là tập hợp những designer giỏi nhất, mà là kết hợp những năng lực bổ trợ cho nhau.
- Bài 4: Khi doanh nghiệp phát triển, bài toán không còn là xây dựng một Design Team, mà là biến những năng lực đó trở thành năng lực của cả tổ chức.
Kết luận
Có lẽ, xây dựng một tổ chức thiết kế (Design Organization) không phải là đích đến cuối cùng. Ngay cả khi doanh nghiệp có đúng người, đúng năng lực và đúng cấu trúc tổ chức, vẫn còn một câu hỏi khó hơn: Làm thế nào để những năng lực đó thực sự tạo ra tác động cho doanh nghiệp?
Với tôi, mọi điều được chia sẻ trong cả bốn bài viết đều hướng đến một mục tiêu chung: giảm ma sát để năng lực của Design có thể chuyển hóa thành tác động kinh doanh.
Tôi rất tâm đắc với công thức của Katie Dill (VP of Design tại Stripe, cựu Head of Design tại Airbnb và Lyft):
Khả năng thực tế của Sản phẩm = Tiềm năng của Nhóm Thiết kế − Tính Quan liêu của Tổ chức
Lãnh đạo thiết kế không chỉ là làm nghề giỏi hay xây dựng một đội ngũ mạnh, mà còn là tạo ra môi trường để những năng lực đó có thể được lắng nghe, phối hợp và chuyển hóa thành giá trị thực tế — bằng cách học cách vượt qua những rào cản vận hành và tính quan liêu của tổ chức.
Đó cũng sẽ là chủ đề mà tôi muốn tiếp tục chia sẻ cùng các bạn trong bài viết sắp tới!
