Startup CTO's Handbook - Cẩm nang dành cho CTO startup
(github.com/ZachGoldberg)- Cung cấp nội dung sách mới nhất của Startup CTO's Handbook, và có thể đọc phần nội dung chính ở định dạng Markdown
- Có thể mua sách trên Amazon và Audible
- Liên kết bản PDF được dựng từ phiên bản Markdown mới nhất hiện đang ở trạng thái Coming Soon, còn bản thảo gốc hiện tồn tại dưới dạng phiên bản cũ trên Google doc
- Khuyến khích đóng góp issue và pull request để phản ánh các bổ sung, thay đổi, đề xuất và phê bình vào các ấn bản sau
- Giấy phép cho phép sao chép, chỉnh sửa và phân phối lại với điều kiện không bán lại, giữ nguyên tên tác giả và ghi nhận bản quyền, đồng thời công bố các phiên bản sau theo giấy phép tương tự hoặc giống hệt
1 bình luận
Ý kiến trên Hacker News
Chắc chắn có những điểm tôi đồng ý. Ví dụ, tôi ủng hộ ghi hình tất cả các cuộc họp. Nhưng cũng có nhiều phần cá nhân tôi không đồng ý, như quản lý hiệu suất[0]
Không hẳn là phê phán, mà ý tôi là mỗi miền vấn đề có thể cần cách tiếp cận và phong cách lãnh đạo khác nhau. Mong là đừng xem hướng dẫn này như thứ thiêng liêng bất khả xâm phạm. Nếu nội dung ở đây không khớp với trải nghiệm của bạn, tôi khuyên nên tin vào trải nghiệm của chính mình hơn
[0] https://twitter.com/bcantrill/status/1216491216356823040
Với tư cách CTO, tôi không biết làm sao có thể đưa ra yêu cầu đó mà không mang tính ép buộc
Tuy vậy, trên thực tế thường có những khoảng cách kỹ năng thật sự, và tôi nghĩ nếu người quản lý đóng vai trò coach thì có thể giúp ai đó phát triển và đạt hiệu suất nhanh hơn
Bên đó đang nói về quản lý hiệu suất hướng tới tương lai, tức là làm thế nào để cải thiện hiệu suất trong thời gian tới. Nhưng ở hầu hết công ty, đánh giá hiệu suất gần với đánh giá hồi cứu hơn, tức là xếp hạng hiệu suất trong quá khứ trong quá trình phân bổ lương thưởng và thăng chức
Quy trình hướng tới tương lai thì rất tuyệt, nhưng cuối cùng vẫn cần một mức độ đánh giá nào đó về hiệu suất quá khứ
Tôi đã có cơ hội làm việc cùng tác giả ở hai công ty, và thật khó diễn tả hết những điều được viết ở đây tạo ra khác biệt lớn đến mức nào khi được triển khai trong thực tế
Tác động không chỉ nằm trong sản phẩm hay engineering mà lan ra toàn bộ tổ chức. Dù là hệ thống hay khuyến nghị nào thì cuối cùng cũng phải điều chỉnh cho phù hợp với tổ chức của mình, nhưng tôi khuyên nên tận dụng cách Zach giảng dạy nhiều nhất có thể
Tôi khá thích ghi hình cuộc họp. Không phải để dùng làm bằng chứng khi nhóm bắt đầu đổ lỗi qua lại, mà vì việc có thể xem lại các cuộc họp và thảo luận thật sự rất tốt
Nếu đang ở trong một cuộc thảo luận quan trọng hoặc cuộc họp căn chỉnh mà tôi phải dùng khá nhiều năng lực của mình, thì rất khó vừa tập trung vào chủ đề, vừa ghi chú, vừa nhớ hết mọi thứ. Biết rằng có bản ghi hình giúp tôi trong lúc họp có thể tập trung hoàn toàn vào việc chú ý, đặt câu hỏi hay và kiểm chứng các giả định
Ngày hôm sau, tôi có thể nghe lại cuộc gọi, tạm dừng, nghe ở tốc độ 2x·3x, tạo ghi chú cá nhân, viết biên bản họp hoặc tóm tắt nội bộ, phát hiện sự không nhất quán trong suy nghĩ, hoặc chạy công cụ ghi chú AI theo lịch của mình
Nó cũng hữu ích khi ai đó bị ốm, phải đi đón mẹ vợ ở sân bay, có cuộc họp khác cùng lúc, hoặc mới tham gia sau một cuộc họp căn chỉnh quan trọng một tuần. Nếu là cuộc họp không quan trọng thì cứ bỏ qua, và chỉ cần đặt quy tắc tự động xóa hợp lý là xong
Tôi không nghĩ mọi người thật sự dành thời gian lén lục lọi những nơi họ không nên vào, nên tôi không xem đó là vấn đề lớn
Họp nhóm cũng khiến cuộc trò chuyện nghiêng về phía những người tự tin khi nói. Điều này đặc biệt bất lợi cho người mới tham gia hoặc người dùng ngôn ngữ chính khác
Tôi không phản đối bản thân cuộc họp. Có những người thích giao tiếp bằng lời nói hơn rất nhiều so với viết, và một đội ngũ tốt cần có khả năng dung nạp cách làm việc mà từng thành viên ưa thích
Nhưng nếu đó là một cuộc họp nhóm quan trọng và đòi hỏi nhiều năng lực của người tham gia, thì nó không nên là một cuộc họp. Chỉ nên họp khi tất cả người tham gia đều cho rằng cuộc họp là phương tiện tốt nhất cho cuộc đối thoại cụ thể đó
Cuộc họp giống như ngồi trước vòi nước, bạn sẽ bỏ lỡ các chi tiết
Chúng tôi đã chuyển sang Google Workspace vì việc ghi hình và tìm kiếm cuộc họp rất dễ. Ví dụ, bản ghi được nhúng trong sự kiện lịch
Nếu một cuộc họp không đủ quan trọng để ghi hình thì có lẽ nó cũng không đáng để tổ chức
Cá nhân tôi dành nhiều giờ hơn người khác trong ngày, nhưng điều đó không diễn ra đồng bộ. Các cuộc họp quan trọng có thể trùng nhau, và nếu chỉ đọc biên bản họp thì sẽ mất rất nhiều sắc thái. Hơn nữa, mọi người cũng không đọc biên bản họp kỹ
Dù vậy, nếu ghi hình cuộc họp thì có thể rà soát biên bản nhanh và đúng cách, rất hữu ích. Vì thế tôi đang thúc đẩy khá mạnh việc ghi hình cuộc họp
Càng hiểu nhanh nguyên nhân thực sự thì càng sửa vấn đề nhanh. Để hiểu khái niệm này và cách áp dụng vào công ty, tôi rất khuyến nghị Extreme Ownership của Jocko Willink và Leif Babin, cựu Navy SEAL
Tham gia họp bất đồng bộ là điều tuyệt vời vì những lý do đã nói ở trên. Nó giúp thông tin trong cuộc họp có thể tìm kiếm được. Giờ đây cuộc họp có thể được tạo phụ đề bằng xử lý ngôn ngữ tự nhiên, và nội dung đó có thể được LLM tìm thấy
Hiện chúng tôi đang huấn luyện chatbot nội bộ bằng nội dung Confluence và đang muốn mở rộng sang cả nội dung cuộc họp đã ghi hình
Quảng bá một chút thì tôi đang làm https://designpro.ai, một công cụ biến đầu vào từ nhiều nguồn thành insight và tác vụ. Tôi đã dùng nó để rút insight từ bản chép lời cuộc gọi và biết rằng nó thật sự hoạt động
Gần đây tôi trở thành CTO, và một trong những khó khăn lớn nhất là giao tiếp với CEO. Có thể sách đã đề cập nội dung này, nhưng tôi chỉ đọc phần mục lục
Trong 8 tháng qua, CEO không muốn có các cuộc họp căn chỉnh, không muốn lập kế hoạch gì, không muốn dẫn dắt tầm nhìn, mà chỉ muốn tập trung vào tính năng sát thủ
Cũng không muốn tạo mockup hay prototype để thử nghiệm với người dùng, và nếu làm thì bảo phải đẹp. Không muốn làm việc gì mất hơn một tuần, và cũng từ chối các cuộc họp hiệu quả
Điều tôi muốn nói là, những thứ không có trong sách mới chính là những thứ tôi đang thấy thiếu. Nhân tiện, chúng tôi chỉ có 3 đồng sáng lập
CTO là “người phụ trách kỹ thuật” của CEO, và gần như chỉ vì là người phụ trách kỹ thuật giỏi nhất hoặc quan trọng nhất trong số đó nên được trao chức danh CTO
Nghe thì đáng buồn, nhưng bạn nên cân nhắc khả năng CEO đang xem bạn chỉ như một nhân viên khác có chức danh oách hơn. Với tư duy như vậy, từ phía CEO, việc đưa bạn vào các quyết định của họ sẽ có vẻ như lãng phí
Tôi vẫn nhớ chính xác câu trả lời của Marc. “Nếu đã có nghi ngờ, thì không cần phải nghi ngờ nữa”
Tôi biết đây là một quyết định quá lớn để bị thuyết phục bởi một bình luận bất kỳ trên Internet, nhưng dù vậy tôi vẫn nói: đã 8 tháng trôi qua rồi. Có lẽ những gì đáng thử để sửa chữa thì bạn đều đã thử
Còn lại điều gì bạn chưa thử? Về mặt logic, bạn đang kỳ vọng điều gì sẽ xảy ra ở đây? Bạn cần nghĩ xem mình định đầu tư thêm bao nhiêu cuộc đời vào tình huống này, trong khi có thể dễ dàng chuyển sang nơi hiệu quả hơn
Nói nghiêm túc thì, thứ bạn đang va phải chính là điểm khiến công việc này khó khăn
Thứ nhất, bạn nên thử đặt các buổi 1:1 với những lãnh đạo khác. Nếu có lãnh đạo nào ngoài CEO mà bạn làm việc cùng, bạn có thể có thêm bối cảnh về tình huống mình đang bước vào. Khi nắm được nhu cầu của họ, bạn cũng sẽ thấy nhu cầu của tổ chức rộng hơn
Bạn được tuyển để loại bỏ vấn đề của CEO, ngay cả khi CEO không yêu cầu. Khả năng hòa nhập vào đội ngũ lãnh đạo là một trong những cách tốt nhất để chứng minh năng lực, và điều cần có là sự nhất quán, tận tâm, cởi mở, cùng thái độ thật sự muốn đặt những câu hỏi hữu ích
Thứ hai, nếu CEO và đội ngũ lãnh đạo gặp nhau định kỳ, hãy xin tham gia; nếu chưa có, bạn nên tự lên kế hoạch. Lý tưởng nhất là trước đó đã căn chỉnh với các lãnh đạo khác ngoài CEO. Ngay cả khi CEO không thể đến tất cả hoặc phần lớn các cuộc họp, họ cũng sẽ biết ơn sự chủ động đó và bạn sẽ xây dựng được niềm tin
Vì bạn đã nói CEO không muốn những cuộc họp như vậy, có thể bạn cần đi đường vòng trước thông qua một lãnh đạo khác có ảnh hưởng với CEO
Thứ ba, nếu là CTO, rất có khả năng CEO cũng sẽ muốn có một buổi 1:1 định kỳ ở mức nào đó, ít nhất là để bảo đảm bạn không rời đi. Chỉ cần tìm nhịp phù hợp với lịch của CEO: hằng tuần, hai tuần một lần, hằng tháng, v.v.
Mục đích của cuộc họp này là căn chỉnh với CEO và nhận phản hồi về những lĩnh vực bạn đang làm tốt cũng như những lĩnh vực cần cải thiện. Nếu bạn không thể sắp xếp được cuộc họp này, tôi khuyên nên xem đây là môi trường không thể thành công và rời đi
Nếu khó đặt cuộc họp này, bạn nên thúc đẩy hai cách tiếp cận ở trên trước để xây dựng quan hệ rồi thử lại. Nếu bạn hoàn toàn không thể có thời gian định kỳ với CEO và các lãnh đạo khác ở bất kỳ tần suất nào, thì thực tế bạn không phải CTO, và nên cân nhắc rời đi
Tôi từng viết về khác biệt đó ở đây: https://www.mooreds.com/wordpress/archives/2555
Tuy nhiên, việc thiếu kế hoạch và không thúc đẩy tầm nhìn là điều đáng lo. Cả hai đều là cốt lõi trong vai trò CEO ở giai đoạn đầu. Bạn có biết vì sao họ chỉ tập trung vào những thứ ngắn hạn như vậy không? Họ đang cố đẩy MVP để gọi vốn hoặc bán hàng, hay là không có tầm nhìn? Tôi sẽ đào sâu phần đó để hiểu lý do. Hoặc như những người khác nói, rời đi cũng là một cách
Đã đến giai đoạn mà khi bạn sắp xếp các bước ngắn hạn thật sự cần thiết, CEO nói “Ừ được, đây là việc chúng ta sẽ làm” chưa?
Hay là đang ở giai đoạn tuyệt vời khi bạn thúc đẩy chứng nhận SOC2 thì CEO nói “chưa phải lúc”, nhưng trong pitch bán hàng lại nói “chúng tôi đang hướng tới chứng nhận SOC2”?
Không cần lo. Người bị phân liệt không phải là bạn
Wikipedia mô tả DevOps là một tập hợp thực hành kết hợp phát triển phần mềm và vận hành IT, nên việc dịch nó thành “mọi việc bảo đảm phần mềm kinh doanh chạy được ở những nơi không phải máy của developer” có vẻ là một cách diễn giải hơi kỳ lạ so với định nghĩa gốc
Đặc biệt là phần chuyên gia DevOps
Tôi sẽ viết lại để truyền đạt điều đó tốt hơn
Tôi chẳng biết công ty hay người nào được nêu ở đây. Tò mò không biết người khác có biết không
Trước khi dành thời gian đọc, phải nói là tôi vốn có nghi ngờ bản năng với những người gọi là “giám đốc công nghệ”. Có đáng đọc không?
Độc giả mục tiêu có vẻ là những người gần như không có, hoặc hoàn toàn không có, kinh nghiệm chuyên môn nhưng trở thành đồng sáng lập kỹ thuật của startup và được thừa hưởng chức danh CTO
Tôi đã làm CTO ở ba công ty trong 10 năm qua, và có thể giờ tôi đã già hơn và kém kiên nhẫn hơn, nhưng như những người khác nói, cuốn này có vẻ giống sách dành cho những người vừa tốt nghiệp, mới trở thành CTO với tư cách đồng sáng lập hơn. Tôi đang làm cố vấn kỹ thuật cho những người như vậy
Theo kinh nghiệm của tôi, càng làm vai trò này lâu, bạn càng tìm đến thông tin cụ thể hơn, như trong những cuốn sách kiểu Accelerate
Công nghệ nhàm chán thật sự quan trọng. Startup khu vực tư nhân vốn đã là những thực thể bất ổn rồi, vậy tại sao lại tăng thêm rủi ro bằng công nghệ chưa được kiểm chứng?
Ví dụ, trong giai đoạn từ 2013 đến 2016, đã có lúc MongoDB, vì lý do khó giải thích, gần như trở thành cơ sở dữ liệu mặc định. Trông như khoảng một phần ba số startup đã chuyển từ MySQL hoặc Postgres sang MongoDB. Đó thật sự là một thảm họa hỗn loạn và ngớ ngẩn hoàn toàn
Trong trường hợp đó, rất khó tưởng tượng lý do chọn Mongo. Ngoài việc giúp nhanh hơn một chút trong vài ngày đầu phát triển vì không cần tạo và cập nhật schema, thì chẳng có gì cả
Vấn đề là ngay khi dữ liệu trở nên phức tạp và cần những thứ như BI, bạn sẽ phải trả lại lợi thế ban đầu đó với mức lãi khổng lồ
Dù sao thì, ngay cả khi dữ liệu không phải dữ liệu quan hệ, JSON của Postgres vẫn hoạt động tốt hơn Mongo
Một số công nghệ mới sẽ biến mất, một số sẽ tồn tại
Ở giai đoạn đầu sự nghiệp của tôi, SQL từng là công nghệ mới hào nhoáng. Tôi đã thúc đẩy mạnh mẽ rằng công ty nên bỏ cơ sở dữ liệu mạng và chuyển sang SQL, và kết quả rất tốt
Lập trình hướng đối tượng so với C truyền thống cũng tương tự
Có những công nghệ rốt cuộc không bao giờ đạt được như lời hứa, và trở thành xiềng xích cho tổ chức đã áp dụng chúng
Đã từng có thời điểm còn quá sớm để đưa công nghệ LLM vào một cách có trách nhiệm. Nhưng sẽ sớm đến lúc hội đồng quản trị hỏi tại sao chưa áp dụng. Với use case bên ngoài thì có thể, còn use case nội bộ thì chắc chắn có thể như vậy
Một trong những nhiệm vụ khó của CTO là phán đoán thời điểm áp dụng công nghệ mới. Cần xác định khi nào công nghệ nhàm chán là lựa chọn tốt nhất cho công ty, khi nào có thể đưa công nghệ giai đoạn đầu vào, và khi nào công nghệ mới trở thành một bộ tăng tốc quá lớn đến mức nhất định phải áp dụng
Việc chia CTO thành ba kiểu: định hướng công nghệ, định hướng con người và định hướng bên ngoài khá thú vị
Một startup ở giai đoạn rất sớm đang đề nghị vai trò CTO. Họ chưa có sản phẩm, chỉ có vài demo cơ bản, và đang chuẩn bị gọi vốn pre-seed
Tôi tò mò không biết vai trò này cần điều gì nhất. CTO công nghệ hay CTO con người? Ban đầu chắc chủ yếu là vai trò kỹ thuật vì phải phát triển sản phẩm. Nhưng tôi thắc mắc khi nào thì sẽ chuyển sang CTO lấy con người làm trọng tâm. Nếu ai có insight hoặc kinh nghiệm liên quan, tôi muốn được nghe
Chủ yếu hãy trở thành vai trò đó, còn các phần còn lại thì chống đỡ tạm ổn; khi việc đó trở nên quá nhiều hoặc quá quan trọng, hãy tuyển người đảm nhiệm hai mảng còn lại hoặc hơn
Câu hỏi thứ hai khó trả lời hơn là họ, tức các CXO khác, muốn bạn trở thành gì. Điều này có thể cản trở câu hỏi thứ nhất. Trong một số trường hợp, đó là CTO không có chữ C, tức chỉ là người phụ trách kỹ thuật bị chỉ bảo phải làm gì, chạy các demo để khoe, và không được nghe phần “tại sao” của doanh nghiệp
Tôi có bookmark vài liên kết về “rốt cuộc CTO là gì”
http://www.startuplessonslearned.com/2008/09/what-does-start...
https://www.allthingsdistributed.com/2007/07/the_different_c...
Tôi cũng khuyên đọc The Manager’s Path của Camille Fournier
Dù nói rằng “trả nợ chủ động là khoản đầu tư cần thiết cho sức khỏe kỹ thuật tổng thể”, nhưng một số nợ kỹ thuật đôi khi về tổng thể rẻ hơn nếu để vỡ nợ thay vì trả
Miễn là product manager không cố đi đòi nợ
Nhưng một dự án có quy mô và độ phức tạp nhất định mà đi đến phá sản kỹ thuật thì chỉ xảy ra khi không làm theo lời khuyên trong sách. Nếu phớt lờ nợ kỹ thuật để tung tính năng, việc release sẽ ngày càng khó hơn và bug cũng ngày càng thường xuyên hơn
Chúc mừng sách được xuất bản
Dựa trên kinh nghiệm làm CTO của một startup nhỏ và VPoE của một công ty niêm yết, tôi đang viết Opinionated Launch(https://opinionatedlaunch.com) để chia sẻ các ý tưởng thực tế
Khi bắt đầu viết, tôi nhận ra chủ đề chia thành hai nhánh: quản lý·đội nhóm·con người và kỹ thuật. Tôi đã tập trung vào phần kỹ thuật, nơi mình có nhiều đam mê hơn, nên rất vui khi có ai đó làm phần còn lại