Am I a Senior or an Obsolete Architect?

Một bản Việt dịch từ: https://dev.to/hatem_zidi/am-i-a-senior-or-an-obsolete-architect-178g

Làm một Architect giống như làm nhạc trưởng trong một dàn nhạc. Bạn không phải là người chơi tất cả các nhạc cụ, nhưng công việc của bạn là đảm bảo mọi người đều hòa nhịp với nhau và tạo ra một tổng thể hài hòa.

Tôi từng xem Simon Rattle chỉ huy 6 dàn nhạc trường học Berlin biểu diễn bản Peer Gynt Suite của Edvard Grieg. Thực tế là họ chưa từng làm việc hay tập luyện cùng nhau trước đó. Lần biểu diễn đầu tiên của họ rất tệ và chói tai, nhưng sau nhiều lần sửa chữa và tập luyện, Rattle đã biến buổi biểu diễn cuối cùng thành một tác phẩm tuyệt vời và hoành tráng.

Điều gì đã giúp ông thành công? Làm sao ông có thể khiến mọi người lắng nghe? Làm thế nào ông biến hỗn loạn thành hài hòa? Làm sao ông có thể khai phá tiềm năng tốt nhất của mỗi nghệ sĩ?

Tương tự vậy, với vai trò là một Architect, làm thế nào để bạn làm việc hiệu quả? Làm sao để giữ mọi thứ cân bằng và đồng bộ?

Trong bài viết này, tôi sẽ chia sẻ 5 hành vi then chốt mà tôi cho là thiết yếu nhất, không chỉ giúp bạn gia nhập thế giới hỗn độn của các Architect mà còn phát triển mạnh mẽ trong đó.

TL;DR?

1. Lắng nghe chủ động, nói năng khéo léo 
2. Tư duy hệ thống toàn diện 360°
3. Đảm bảo tính nhất quán & đồng bộ
4. Là chất xúc tác cho sự thay đổi
5. Nâng cao tiêu chuẩn

1. Lắng nghe chủ động, nói năng khéo léo

Không thể phủ nhận, người biết lắng nghe là người tập trung cao độ, họ cam kết tiếp thu thông tin và phản hồi mang tính xây dựng. Một Architect phải thấu hiểu vô số yêu cầu, mối quan tâm và giới hạn của các bên liên quan, team kỹ thuật và người dùng cuối. Do đó, họ phải chú ý đến từng chi tiết và không ngại đặt câu hỏi để làm rõ vấn đề.

Chúng ta vẫn thường nghe câu "Quỷ ẩn trong chi tiết". Là một Architect, châm ngôn này phải trở thành thói quen hàng ngày khi thảo luận với đồng nghiệp và khách hàng để nắm bắt cả những yêu cầu rõ ràng lẫn những nhu cầu tiềm ẩn có thể không được nói ra trực tiếp.

Mặt khác, chúng ta - những Architect rất thích nói và chia sẻ suy nghĩ, quan điểm và phát hiện của mình, đặc biệt là sau khi tiếp thu được nhiều thông tin. Tuy nhiên, ngôn ngữ có thể thay đổi tùy theo đối tượng và mức độ phức tạp của ý tưởng.

Giao tiếp rõ ràng, súc tích và có tác động giúp định hướng mọi người về cùng một mục tiêu và tạo sự đồng cảm với nhiều đối tượng khác nhau, kể cả kỹ thuật hay phi kỹ thuật.

"Làm sao để trở thành người biết lắng nghe và nói năng khéo léo?" bạn có thể hỏi. Chà, không có gì cao siêu ở đây hay đặc thù trong ngành IT cả.

Trước hết, "Lắng nghe chủ động" không chỉ đơn thuần là im lặng; mà là để thấu hiểu hoàn toàn.

• Với điều này trong đầu, hãy "giữ suy nghĩ của bạn" để tránh ngắt lời. Dù có muốn chen ngang nhưng hãy để người nói có không gian.
• Tiếp theo, "hỏi về lý do và động lực". Đừng giả định; hãy đào sâu vào lý luận của họ. Và đừng quên làm rõ vấn đề.
• "Hỏi về định nghĩa" của các thuật ngữ chính và "ý nghĩa đằng sau những từ thông dụng". Mọi người thường dùng cùng một từ nhưng lại có ý nghĩa hoàn toàn khác nhau. Bằng cách cụ thể hóa, bạn sẽ tránh được sự nhầm lẫn.

Tương tự, "Khéo léo trong giao tiếp" là về việc truyền đạt thông điệp của bạn một cách chính xác, có chủ đích và dễ liên hệ, đảm bảo mỗi từ đều có trọng lượng. Trở nên khéo léo nghĩa là làm cho ý tưởng của bạn ghi dấu ấn.

• Đầu tiên, "đơn giản hóa những ý tưởng phức tạp". Nếu bạn không thể giải thích một cách đơn giản, hãy suy nghĩ lại. Sự rõ ràng quan trọng hơn biệt ngữ. Chọn từ ngữ có mục đích, mỗi từ phải có ý nghĩa, không dùng từ đệm hay buzzword.
• Thứ hai, "sử dụng phép ẩn dụ". Chúng biến những khái niệm trừu tượng thành điều gì đó cụ thể. Hãy xem phép ẩn dụ như cầu nối giữa điều bạn biết và điều họ hiểu.
• Cuối cùng, "luyện tập" nói chậm rãi và sâu sắc. Cho bản thân thời gian để suy nghĩ và cho người nghe thời gian để tiếp thu.

Một câu chuyện thực tế

Tôi từng tham dự một cuộc họp với các stakeholder từ bộ phận IT của một ngân hàng. Nhiệm vụ của chúng tôi là xây dựng một framework phát triển riêng cho ngân hàng từ đầu.

"Framework ư?" - Tôi thầm nghĩ, "Đây là một dự án lớn đây." Tại sao lại muốn tạo một framework mới trong khi thị trường đã có quá nhiều lựa chọn? Liệu nó phục vụ cho development hay business? Sử dụng nội bộ hay công khai? Tôi giữ những suy nghĩ này cho riêng mình và kiên nhẫn lắng nghe họ trình bày.

Ban đầu, người sales của chúng tôi thao thao bất tuyệt một hồi về năng lực xây dựng framework của công ty, cố gắng nhấn mạnh điểm này. Sau đó, họ bất ngờ chuyển lời cho tôi để thuyết trình thêm. Tôi cảm ơn họ, nhưng thay vì thuyết trình, tôi đặt cho panel một câu hỏi trực diện: "Tại sao các anh/chị cần một framework mới?"

Họ bắt đầu giải thích và tôi im lặng lắng nghe, chỉ ghi chép. Người sales không hài lòng về điều này. Họ liên tục nhìn tôi với ánh mắt "anh-nên-nói-gì-đi", nhưng tôi phớt lờ. Khi panel trình bày xong, tôi đặt thêm vài câu hỏi dựa trên ghi chép của mình. Họ lại giải thích thêm về động cơ của mình, và tôi vẫn giữ im lặng, tiếp tục lắng nghe. Người sales, vẫn không hài lòng, liếc nhìn tôi với vẻ khó chịu rõ ràng về sự im lặng của tôi.

Hóa ra họ không thực sự cần một framework hoàn toàn mới. Điều họ thực sự muốn là một bộ UI components chuyên biệt để chuẩn hóa giao diện và trải nghiệm trong phát triển SPA - thứ có thể đẩy nhanh tiến độ delivery bằng cách cung cấp sẵn các business interface. Yêu cầu ban đầu của họ đã bị phóng đại và gây hiểu nhầm. Phạm vi thực tế? Hoàn toàn khác. Và kết quả? Không như những gì được đề cập ban đầu.

Việc chủ động lắng nghe trong trường hợp này đã giúp tôi khám phá ra nhu cầu thực sự, tập trung vào việc xây dựng những gì họ cần, và có được sự tin tưởng của các stakeholder bằng cách thực sự hiểu được mục tiêu của họ.

Còn về người sales? Chúng tôi đã học cách làm việc cùng nhau. Họ có thể hát, nhưng tôi là người định nhịp.

2. Tư duy hệ thống toàn diện (360°)

Bạn có từng rơi vào tình huống hệ thống có quá nhiều dependencies phức tạp đến mức một thay đổi nhỏ ở góc này có thể gây ra sự cố nghiêm trọng ở một góc hoàn toàn không liên quan khác không?

Hiệu ứng cánh bướm, nghe quen thuộc chứ?

Là một Architect, tư duy toàn diện nghĩa là phải nhìn xa hơn những giải pháp tức thời và ảnh hưởng của các công nghệ, tools hay phương pháp khác nhau. Điều này có nghĩa là đảm bảo các quyết định ở một layer của hệ thống phải đồng bộ với các layer khác, từ infrastructure cho đến application và business.

Tư duy toàn diện rất quan trọng để tránh thiết kế manh mún, rời rạc, đảm bảo hệ thống hoạt động như một khối thống nhất chứ không phải là sự ghép nối lỏng lẻo của nhiều phần, từ đó tránh được những vấn đề về hiệu suất và rắc rối trong tương lai.

Thực tế, các Architect phải thực hành System Thinking và nhìn nhận hệ thống một cách tổng thể, hiểu được mối quan hệ nhân quả giữa các components và môi trường xung quanh cũng như cách chúng tương tác với nhau.

Điều này không chỉ đòi hỏi đánh giá các yếu tố kỹ thuật riêng lẻ mà còn cả bối cảnh rộng lớn hơn nơi chúng hoạt động, bao gồm mục tiêu kinh doanh, trải nghiệm người dùng, khả năng mở rộng...

Tôi khuyên bạn nên đọc cuốn [Learning Systems Thinking] của Diana Montalion, cuốn sách cung cấp hướng dẫn thực tế về cách làm chủ tư duy hệ thống trong lĩnh vực công nghệ. Không chỉ là lý thuyết suông, nó giúp cải thiện cách tiếp cận Architectural một cách cụ thể và hữu ích ngay lập tức.

Để đi sâu vào Systems Thinking, bạn cần tập trung vào:

• Quan sát và phân tích patterns: Bắt đầu bằng việc nhận diện các patterns trong công việc, team và dự án. Đừng chỉ quan sát những gì đang xảy ra mà hãy tìm hiểu tại sao nó xảy ra. Systems thinking là về việc hiểu được động lực đằng sau những patterns này. Bạn đang rèn luyện khả năng nhìn xa hơn những sự kiện riêng lẻ để nắm bắt được cấu trúc bên dưới bề mặt.
• Thực hành vẽ sơ đồ hệ thống: Cầm bút lên và vẽ ra. Map hệ thống, liệt kê các components, mối quan hệ và feedback loops. Đây không đơn thuần là bài tập vẽ; mà là cách để kết nối các điểm và thấy được luồng hoạt động.
• Và quan trọng nhất là Học cách nhìn xa hơn các triệu chứng. Architects không chỉ xử lý triệu chứng; họ đào sâu hơn để tìm ra nguyên nhân. Khi có vấn đề, đừng chỉ sửa nó, mà hãy tìm hiểu nó. Hỏi "tại sao" nhiều lần cho đến khi tìm ra nguyên nhân gốc rễ. Kỹ thuật 5 Whys này sẽ giúp bạn chuyển từ việc xử lý nhanh sang tìm ra giải pháp thực sự.

Một câu chuyện nhỏ

Trong một buổi workshop với các đại diện từ một công ty dầu khí nổi tiếng của Pháp, chúng tôi đang tìm hiểu về một yêu cầu thay đổi quy trình BPMN nhằm đồng bộ hóa các chính sách quan trọng giữa các phòng kỹ thuật, hậu cần và an toàn.

Trong nhóm có một vị giám đốc kiến trúc doanh nghiệp (Chief Enterprise Architect) tóc bạc với nhiều kinh nghiệm. Chúng tôi đã xây dựng được mối quan hệ tin tưởng và tôn trọng lẫn nhau qua các dự án trước đó.

Việc thay đổi này không hề đơn giản. Quy trình workflow chứa đầy các dependencies, và chúng tôi liên tục vấp phải các edge case, khiến mọi bước đi trở nên khó khăn hơn. Vị Chief EA cũng không dễ dãi bỏ qua bất cứ điều gì, ông rất khắt khe và thông minh trong việc chỉ ra những tác động tiềm ẩn và các bottleneck có thể xảy ra trong mọi giải pháp mà chúng tôi đề xuất.

Sau nhiều giờ brainstorming, mapping impacts và tìm hiểu vấn đề, tôi nhớ là mình đang cúi xuống tìm thuốc giảm đau trong ba lô vì bắt đầu nhức đầu, thì Chief EA bỗng ngắt lời cả nhóm và hỏi: "Khoan đã mọi người! Tool tốt nhất chúng ta có thể dùng ở đây là gì?".

Cả phòng im lặng; mọi người nhìn nhau, gãi đầu và đưa ra vài gợi ý.

Với một nụ cười, ông chỉ nhẹ nhàng vẫy tay, mỉm cười, nháy mắt với tôi và lấy ra viên thuốc nhức đầu của chính mình. "Các bạn ơi!" ông nói, "chúng ta cần nhiều thứ này hơn!"

3. Đảm bảo tính Coherence và Alignment

Tôi tin chắc 100% rằng các Architect là người gác cổng cho tính coherence trong bất kỳ hệ thống nào. Nếu một hệ thống giống như một mớ hỗn độn không ăn khớp với nhau một cách thanh lịch, tin tôi đi! Đã có vấn đề xảy ra trong phần Architecture.

Coherence nghĩa là mọi phần của hệ thống đều phải phù hợp trong một cấu trúc lớn hơn—tính nhất quán về technical, design principles, và alignment với mục tiêu chiến lược phải đồng bộ với nhau.

Điều quan trọng là: Một Architect không chỉ vẽ diagram rồi bỏ đi. Họ phải làm trung gian giữa các thế giới, đảm bảo business, development và operations không bị tách biệt. Mỗi bên đều có ngôn ngữ, mục tiêu và áp lực riêng, nhưng Architect sẽ align chúng lại, kết nối nhu cầu business với thực tế technical.

Đây không chỉ là việc check list; mà là đảm bảo những gì đang được xây dựng phải khả thi, hiệu quả, mang lại giá trị và tạo impact.

Làm thế nào để học và thực thi coherence? Tôi sẽ nói...

• Đứng ra làm cầu nối giữa các team, tiếng nói và agenda khác nhau. Be the Mediator. Coherence không phải là chọn phe; mà là về sự thống nhất. Giúp mọi người cùng đồng điệu với nhau.
• Nhìn vào những gì đã thành công (và thất bại) trong các dự án tương tự. Real-world lessons là kinh nghiệm quý giá để xây dựng hệ thống coherent và hiệu quả.
• Think holistically. Nhớ chứ? Nhìn toàn bộ hệ thống, không chỉ từng phần riêng lẻ. Coherence là về việc làm cho mọi phần hoạt động cùng nhau một cách mượt mà.
• Nói chuyện, làm rõ và lặp lại. Misalignment thường đến từ miscommunication. Coherence phát triển tốt khi đối thoại diễn ra cởi mở.

Một câu chuyện nhỏ

Product Manager theo trường phái Khắc kỷ của tôi đã nêu lên những lo ngại từ các bên liên quan về cách khách hàng đang truy cập sản phẩm SaaS của chúng tôi. Chúng tôi cần cải thiện điều này, đảm bảo trải nghiệm người dùng mượt mà với các backend component mà không ảnh hưởng đến bảo mật hay hiệu quả vận hành.

Team engineering đã ngay lập tức đề xuất giấu component truy cập hiện tại đằng sau một layer mới, thêm một facade hoàn toàn mới để forward mọi thứ tới các script tự động được wrap lại. Trên lý thuyết, nó có vẻ là một giải pháp nhanh, nhưng với tôi, đó chỉ là thêm một lớp băng keo tạm thời, thêm component và độ phức tạp trong khi không giải quyết được vấn đề gốc rễ.

Việc bảo trì chỉ càng trở nên khó khăn hơn.

PM muốn giảm thiểu những rào cản cho người dùng và vận hành, trong khi engineering muốn phát triển nhanh hơn.

Tuy nhiên, ý định của tôi là đơn giản hóa. Tôi muốn tinh gọn mọi thứ thành một cách tiếp cận duy nhất, mang lại bảo mật tốt hơn, kiểm soát truy cập và giảm thiểu công sức vận hành, đồng thời giảm technical debt.

Ban đầu, đề xuất của tôi có vẻ nặng nề và chậm để triển khai. Nhưng tôi biết tính nhất quán lâu dài của hệ thống sẽ đáng giá. Design cuối cùng được đề xuất đã giảm đáng kể code footprint bằng cách loại bỏ các component dư thừa, tăng cường bảo mật bằng cách giới hạn attack surface, và thống nhất authentication cho tất cả người dùng.

Bài học chính là gì? Sự nhất quán không chỉ là giải quyết vấn đề hiện tại; mà là việc căn chỉnh các mục tiêu kinh doanh, kỹ thuật và vận hành để tạo ra một hệ thống bền vững. Cách tiếp cận ban đầu có vẻ chậm hơn thực tế đã giúp chúng tôi tiết kiệm được nhiều thời gian và đau đầu về sau.

4. Chất xúc tác cho sự thay đổi

Thay đổi là điều duy nhất không thay đổi

... và Architects phải đứng lên làm chất xúc tác cho sự Thay đổi. Chúng ta không chỉ xây dựng hệ thống mà còn thúc đẩy sự chuyển đổi.

Trong khi nhiều team mắc kẹt ở hiện tại, chúng ta đã nhìn về phía trước và suy nghĩ về tương lai. Hiện tại không phải là nơi chúng ta muốn dừng lại.

Cho dù là áp dụng công nghệ mới, định hình lại business model, hay hướng dẫn team qua các quy trình mới, Architects đào sâu để phát hiện cơ hội và thúc đẩy những cải tiến thiết thực nâng tầm tổ chức.

Nhưng thay đổi không dễ dàng. Mọi người tự nhiên sẽ chống lại, và đó là lúc Architects phải vươn lên. Công việc của chúng ta là giúp mọi người vượt qua sự do dự, đưa mọi người cùng một hướng, và gieo mầm thay đổi. Xoa dịu sự miễn cưỡng, kéo mọi người tiến lên, truyền cảm hứng để họ bước ra khỏi vùng an toàn - đó là nhiệm vụ hàng ngày của chúng ta.

Là một Architect, bạn phải thúc đẩy sự linh hoạt và ủng hộ việc delivery linh động và từng bước. Thiết kế những hệ thống không chỉ đáp ứng nhu cầu hiện tại mà còn có thể thích ứng với những thay đổi trong tương lai mà không bị sụp đổ.

Hơn nữa, Architects tạo ra văn hóa cải tiến liên tục nơi sự đổi mới phát triển, các team được trao quyền, và thay đổi là điều mà mọi người sẵn sàng đón nhận.

Bạn muốn tạo ra thay đổi thực sự? Đây là cách thực hiện:

• Thay đổi cần động lực. Hãy Master the Art of Influence. Sự ảnh hưởng là nhiên liệu của bạn. Truyền cảm hứng, thuyết phục, lobby và tập hợp mọi người xung quanh tầm nhìn của bạn.
• Nếu bạn không thấy được tương lai, không ai có thể thấy được. Hãy Sharpen Your Vision. Xác định rõ thay đổi trông như thế nào và tại sao nó quan trọng.
• Mọi người theo những người họ trust. Hãy xuất hiện, lắng nghe và giữ vững tính nhất quán. Trust là cây cầu dẫn đến thay đổi.
• Nói thì dễ - hãy chỉ cho họ con đường. Lead by Example. Hãy tự mình đón nhận thay đổi; mọi người sẽ theo vì họ thấy bạn sống với nó.

Một câu chuyện

Trong một buổi tối se lạnh, tôi bước vào phòng họp trực tuyến với đầy ắp những ý tưởng để tạo nên những thay đổi có ý nghĩa. Tôi tin rằng chúng tôi đang đứng trước thềm của một sự chuyển mình quan trọng. Mục tiêu? Một cuộc cải tổ toàn diện về Architecture để nâng tầm sản phẩm và quy trình phát triển. Tôi hình dung về một đội ngũ đoàn kết, cùng chung một hướng đi.

Nhưng thực tế nhanh chóng đập tan hy vọng của tôi.

Mọi nỗ lực kết nối mục tiêu của tôi đều thất bại. Tôi chứng kiến sự thất vọng ngày càng tăng khi mọi người tranh cãi gay gắt, ý kiến xung đột và một bức tường vô hình dần hình thành giữa chúng tôi.

Team bị chia rẽ, sự thiếu gắn kết hiện rõ. Mỗi thành viên kéo theo một hướng riêng, bị giới hạn trong những ưu tiên và agenda của họ. Developers chỉ quan tâm đến code của mình, team Operations không nhìn xa hơn công việc hàng ngày, và Management thì không muốn đầu tư. Tôi cảm thấy như đang cố lái một con tàu với đội thủy thủ không cùng chung một bản đồ.

Lúc đó, tôi nhận ra không thể ép buộc thay đổi mà thiếu sự đoàn kết. Tôi rời khỏi buổi họp với tâm trạng nặng nề, hiểu rằng để tác động đến người khác cần có sự kiên nhẫn, vận động và nhiều nhượng bộ để tạo nên sự kết nối và thấu hiểu thực sự.

Kế hoạch chuyển đổi? Chỉ là một tài liệu bị lãng quên trong ngăn kéo của họ.

5. Nâng cao tiêu chuẩn

"Đủ tốt" thì chưa đủ.

Không có cụm từ nào trong tiếng Anh gây hại hơn "good job".

-- Terence Fletcher - Whiplash (2014)

Những Architects giỏi truyền cảm hứng cho team vươn cao hơn, vượt qua tư duy chỉ đơn thuần "hoàn thành công việc". Bằng cách tập trung vào innovation, chất lượng và sự tỉ mỉ trong từng chi tiết, các Architects này định hình nên một tiêu chuẩn xuất sắc.

Việc đặt ra các chuẩn mực cao là vô cùng quan trọng. Dù là trong thiết kế, performance, security hay bất cứ lĩnh vực nào, nâng cao tiêu chuẩn đồng nghĩa với việc đưa ra best practices, ủng hộ công cụ mới, và đảm bảo team hiểu được thế nào là chất lượng thực sự.

Sự tầm thường có tính lây lan

Tiêu chuẩn cao không chỉ là đòi hỏi "sự hoàn hảo"; mà là tạo ra một baseline nơi mọi người đều hiểu thế nào là xuất sắc và cảm thấy được trao quyền để theo đuổi nó.

Architects không phải là người thông minh nhất trong team; họ là người giúp mọi người trở nên thông minh hơn.

Một Architect là người khuếch đại IQ.

-- Gregor Hohpe

Về mentorship. Architects thực thụ không chỉ lãnh đạo; họ còn dạy dỗ. Họ nỗ lực nâng cao năng lực của tất cả thành viên, hướng dẫn họ hiểu được những nét tinh tế trong việc tạo ra sản phẩm chất lượng cao. Hiệu ứng lan tỏa này không chỉ cải thiện kết quả dự án mà còn tạo nên niềm tự hào và tinh thần làm chủ trong team. Khi Architects nâng cao tiêu chuẩn, họ tạo ra một môi trường nơi sự xuất sắc trở thành chuẩn mực, và innovation không chỉ được khuyến khích mà còn được kỳ vọng. Đó là cách thay đổi thực sự diễn ra.

Để nâng cao tiêu chuẩn, bạn cần nâng tầm bản thân.

• Cam kết học tập liên tục. Đào sâu vào các kỹ năng, xu hướng và công nghệ mới. Giữ sự tò mò và bao quanh mình bởi những người xuất sắc hơn; đó là vũ khí bí mật của bạn.
• Định nghĩa thế nào là Excellence. Đừng chấp nhận sự tầm thường. Đừng chỉ nhắm tới đích đến; hãy nâng nó lên! Đòi hỏi chất lượng cao nhất trong mọi dự án và truyền cảm hứng cho team làm theo.
• Kiên cường. Hiểu rằng việc nâng cao tiêu chuẩn thường đi kèm với thách thức và thất bại. Hãy kiên định với mục tiêu và học hỏi từ những thất bại trên chặng đường.

Một câu chuyện

Chúng tôi đã ở đó - mắc kẹt trong cùng một vòng tuần hoàn, tái sử dụng những ý tưởng cũ, bị giới hạn trong lối tư duy cũ. Tôi gần như có thể cảm nhận được không khí văn phòng trở nên ngột ngạt với mỗi cách tiếp cận "đã được thử nghiệm" mà chúng tôi đưa ra. Chúng tôi đã trở thành chuyên gia trong việc ở trong vùng an toàn của mình, tin rằng không có cách nào tốt hơn để làm mọi thứ.

Tôi đang nghĩ đến việc tuyển thêm người mới để thay đổi tình hình thì một email thú vị xuất hiện trong hộp thư. Không phải email công việc thông thường mà là email cá nhân, với tiêu đề: "Xin thực tập".

Tin nhắn từ một cô gái trẻ vừa tốt nghiệp, cô ấy tìm thấy công ty chúng tôi vì chúng tôi là một trong số ít công ty làm việc với công nghệ mà cô ấy quan tâm. Cô ấy đã nỗ lực hơn thế, làm bài tập về nhà, đọc toàn bộ website công ty, tìm hiểu về team, tình cờ thấy tên tôi, mạo hiểm đoán địa chỉ email của tôi và gửi thư.

Tin nhắn của cô ấy sắc bén, đi thẳng vào vấn đề, không hoa mỹ, không có những câu cliché kiểu "Tôi đam mê công nghệ đó" và có đủ sự táo bạo để khiến tôi dừng lại.

Tò mò, tôi đã trả lời. Chúng tôi sắp xếp một cuộc phỏng vấn. Cô ấy thật tuyệt vời, với năng lượng lan tỏa, góc nhìn mới mẻ và sự táo bạo để đặt ra những câu hỏi mà team chưa từng nghĩ tới. Chỉ trong năm phút, tôi biết mình sẽ tuyển cô ấy.

Và để tôi nói cho bạn biết, tác động là tức thì. Cô ấy mang lại sức sống mới cho team. Đột nhiên, mọi người đều tham gia, các cuộc trò chuyện trở nên thú vị, và ý tưởng bắt đầu tuôn trào như thể chúng đã chờ đợi để được giải phóng. Năng suất tăng vọt. Ngay cả những thành viên hoài nghi nhất trong team cũng không thể phủ nhận ảnh hưởng của cô ấy.

Thật thú vị - chúng tôi đã mất nhiều tháng trời để loanh quanh trong cùng một vòng tròn, nhưng chỉ cần một góc nhìn mới để thay đổi mọi thứ. Tiêu chuẩn được nâng cao chỉ bằng cách dám đưa vào một người có tư duy khác biệt và truyền cảm hứng cho những người còn lại làm điều tương tự. Và tất cả chỉ vì ai đó dám đánh cược vào linh cảm và gửi một email. Đôi khi, những ý tưởng tốt nhất không đến từ những nơi thông thường; chúng chỉ cần một cú hích nhỏ... và đúng địa chỉ.

Suy nghĩ cuối cùng

Suy nghĩ cuối cùng? Nếu bạn đang ở đây, bạn đã biết rằng làm Architect không chỉ là về những chức danh hoa mỹ hay kỹ thuật cao siêu; mà là về việc chấp nhận một mindset luôn phá vỡ giới hạn và xây dựng cầu nối.

Đó là về việc lắng nghe nhiều hơn nói, nhìn thấy bức tranh tổng thể, thúc đẩy sự đồng thuận, thúc đẩy thay đổi, và đúng vậy, liên tục nâng cao tiêu chuẩn.

Nếu bạn đang đọc điều này, có lẽ bạn đã là một phần của hành trình này hoặc đang cân nhắc tham gia.

Dù thế nào, hãy nhớ rằng: không có một blueprint hoàn hảo nào cả. Mỗi hệ thống, team và dự án đều độc đáo, và con đường của mỗi Architect được định hình bởi câu chuyện riêng của họ.

Vì vậy hãy giữ sự tò mò, kiên cường và tiếp tục thách thức bản thân cũng như team của bạn. Bởi vì khi bạn dẫn dắt với mục đích và tầm nhìn, Architecture không chỉ là một vai trò - mà là một di sản để lại dấu ấn.