Một tuần làm việc của Engineering Manager (p2)

Thứ tư – ngày không họp hành

Qua hai ngày đầu tuần thì hẳn các bạn sẽ đặt dấu hỏi, ủa, vậy EM thấy họp suốt ngày vậy thì còn làm gì khác không? Thật ra thì cũng có đấy. Ngoài các khoảng nghỉ giữa các cuộc họp thì EM sẽ có những tasks của riêng mình, và những tasks này thường sẽ tận dụng các khoảng thời gian rảnh giữa các meeting, hoặc là tận dụng no-meeting day để hoàn thành.

(1) Làm các tasks liên quan đến engineering. Cụ thể là viết thinking document hoặc design document để nêu hoặc phân tích một vấn đề nào đó. Các vấn đề phân tích mà vai trò EM phụ trách thường sẽ mang tính tổng quan hoặc chiến lược hơn so với các bài toán vận hành hàng ngày. Ví dụ như một vài vấn đề mình sẽ phải viết gần đây:

  • Chia sẻ quan điểm về vai trò của low-code platform trong tổ chức? Có nên dùng hay không? Nếu dùng thì nên dùng như thế nào?
  • Bài toán workflow automation là bài toán của ai (trong tổ chức lớn hơn), nên được giao cho ai?
  • Đề xuất cho một platform khác có liên quan đề platform của mình

(2) Thực hiện vai trò giám sát và coaching. Một trong những trách nhiệm lớn nhất của EM là phải giám sát và chịu trách nhiệm cho sự phát triển của team mình. Để thực hiện vai trò này thì bản thân cần liên tục theo dõi các kênh thông tin của team mình trên Slack để xem các thành viên đang trao đổi về vấn đề gì, có thể nhảy vào cùng trao đổi và tìm cách đưa cuộc thảo luận theo đúng hướng (nếu bản thân thấy chưa đúng hướng).

Ngoài ra cũng sẽ dùng các nội dung trao đổi này để mang ra thảo luận với từng cá nhân trong quá trình 1:1 để góp ý và chia sẻ quan điểm của mình. Sẽ có những tình huống bản thân thấy một thành viên A nào đó phản hồi chưa hợp lý, hoặc chưa trọn vẹn, ví dụ như bạn ấy đang giải thích về một vấn đề cho một người dùng non-tech nhưng lại dùng quá nhiều thuật ngữ kỹ thuật. Trong những tình huống như vậy thì mình sẽ cần ghi nhận và thảo luận với bạn ấy trong những buổi gặp mặt để bạn lưu ý hơn.

Bên cạnh đó, EM cũng sẽ cần phải giúp các thành viên phát triển thông qua việc thảo luận về career path, cũng như xác định độ ưu tiên cho các thành viên và cân bằng giữa nhu cầu phát triển bản thân và nhu cầu của công ty. Bên công ty mình thì trong thời gian gần đây có triển khai một hoạt động gọi là Plan & Priority, trong đó mỗi thành viên sẽ cần tự đặt ra các mục tiêu phát triển bản thân cũng như các ưu tiên trong sự nghiệp hiện tại. EM sẽ dựa vào nhu cầu của từng thành viên để từ đó có sự phân công các tasks phù hợp.

Ví dụ như nếu một bạn trong 6 tháng tới muốn đầu tư nhiều quanh hệ thống Data, vậy thì EM cần tìm cách để đưa bạn vào nhóm làm task liên quan đến Data nhiều hơn. Hoặc một bạn quan tâm đến DevOps thì EM cần tìm cách phân các tasks liên quan đến DevOps nhiều hơn cho bạn, …

(3) Thực hiện vai trò lên kế hoạch. Lập và thực thi kế hoạch là một trong những vai trò quan trọng mà EM cần phải đảm đương, đặc biệt là việc lên kế hoạch dài hạn với chu kỳ 3-6 tháng trở lên. Trong một tổ chức lớn như nơi bản thân đang làm việc, việc có những chiến lược và kế hoạch dài hạn 2-3 năm là cần thiết vì nhiều lý do. Nhiệm vụ của EM lúc này là phải hiểu được platform hoặc team mình đang phụ trách đang đứng ở đâu trong bức tranh toàn cảnh của công ty, phòng ban của mình để tự đó đưa ra được các kế hoạch phù hợp.

Trong vai trò này, bản thân sẽ cần phải tham gia chuẩn bị những thứ như

  • Budget planning. Dự toán xem hạ tầng của team đang quản lý cần kinh phí bao nhiêu trong 6 tháng – 1 năm tới.
  • OKR planning. Mỗi 6 tháng một lần, sẽ phải thống nhất OKR của team để review với các manager cùng các stakeholders liên quan.
  • Vision and Strategy docs. 1 năm một lần sẽ cần phải review lại về chiến lược dài hơi của team, platform để coi team đang ở đâu và cần phát triển theo hướng nào.
  • Execution plan. Tham gia vào soạn thảo các kế hoạch thực thi ở phía engineering từ một kế hoạch lớn ảnh hưởng đến nhiều bộ phận khác nhau.

(4) Các task khác lặt vặt không tên. Tùy vào quy mô và quy trình của tổ chức mà số lượng task lặt vặt có thể nhiều hoặc ít, nhưng sẽ có kha khá các tasks có thể kể tên như: review và approve request xin quyền từ team, support một bạn user của platform, xin budget engagement, …

Thế nào là một ứng dụng tốt?

Đọc bài viết gốc: http://coding-geek.com/what-is-a-good-application/

Gần đây, tôi ứng tuyển vào một vị trí kỹ thuật ở công ty đang làm hiện tại. Một trong những câu hỏi mà người phỏng vấn hỏi tôi đó là “Thế nào là một ứng dụng tốt?”.

Hơi bất ngờ vì tôi chưa thực sự nghĩ về điều này trước đây. Vì thế tôi nghĩ đây sẽ là một bài tập tốt cho bản thân mình khi tổng hợp lại góc nhìn của mình về “Thế nào là một ứng dụng tốt?”. Thời điểm được phỏng vấn, tôi đã đưa ra một câu trả lời từ góc nhìn của một dân kỹ thuật. Và bây giờ, tôi lại nghĩ về câu hỏi đó một lần nữa, và đây là những suy nghĩ mới nhất của tôi cho câu hỏi này.

Continue reading “Thế nào là một ứng dụng tốt?”

Social Proof – Nhiều người tin thì chưa hẳn là điều đúng

Trong lần đầu sang Singapore công tác, tôi học được một quy tắc ứng xử của người dân Singapore đó là khi đi trên thang cuốn thì sẽ đứng bên trái, và chừa phía bên phải để những người vội vã có thể chạy lên. Và vô hình chung, tôi vừa nhìn thấy họ làm điều đó thì tôi cũng làm theo. Tại sao vậy? Tại vì chúng ta chịu sự tác động của Social Proof, hay nôm na là hiệu ứng bầy đàn.

Social Proof là một hiệu ứng ám chỉ việc một cá nhân sẽ có khuynh hướng ứng xử tương đồng với tập thể mà người đó thuộc về. Ở trong một tập thể mà ai cũng bỏ rác đúng nơi quy định, thì tự khắc chúng ta cũng sẽ làm điều tương tự nếu không sẽ bị đào thải. Nhưng nếu trong một tập thể nơi mọi người bỏ rác lung tung, tự khắc chúng ta sẽ cảm thấy “kỳ kỳ” khi bản thân mình lại làm điều đúng.

Và chính như hai ví dụ đó nêu ra, Social Proof có tác động tích cực khi “tập thể” đang hành xử theo chiều hướng tốt, đang tin vào điều đúng. Nhưng ngược lại, chúng ta cũng phải ý thức được rằng, khi nhiều người xung quanh chúng ta cùng tin vào một thứ, không có nghĩa là đó chắc hẳn là điều đúng và chúng ta phải làm theo.

Là một người lý trí, chúng ta cần phải luôn tự có phán xét đúng, sai của riêng mình.

Bài viết liên quan: Social Loafing

Clustering Illusion – Khi ta nhìn thấy những hình hài tạo bởi những đám mây

Clustering Illusion là một thuật ngữ nhằm ám chỉ những ảo giác khi nhìn thấy những hình dạng có ý nghĩa từ những hình hài ngẫu nhiên. Ví dụ như đôi khi chúng ta nhìn thấy hình dạng động vật trên những đám mây, hay khi nhìn thấy gương mặt của chúa, những gương mặt cười trên những chiếc bánh mì chẳng hạn…

Điều này vốn dĩ chẳng có gì lạ vì trí óc con người vốn rất giỏi trong việc nhận diện các khuôn mẫu (pattern) và luôn tìm cách tạo ra những ý nghĩa từ những sự việc ngẫu nhiên. Lý do vì sao lại như vậy thì mình cũng chưa hiểu rõ.

Nhìn chung, bài học chúng ta rút ra được từ Clustering Illusion là gì? Khi chúng ta nhìn thấy hai sự kiện tình cờ xảy ra, bên cạnh suy nghĩ tìm cách kết nối chúng lại với nhau để tìm ra điểm chung, chúng ta cũng không nên bác bỏ một khả năng khác: đơn giản đó chỉ là sự tình cờ.