Giám đốc điều hành PlanetScale trên Cloud-Prem và Leo lên bậc thang kỹ thuật

Sam Lambert là Giám đốc điều hành của Quy mô hành tinh, nhà cung cấp cơ sở dữ liệu không có máy chủ tương thích với MySQL. Trước khi gia nhập PlanetScale (khi đó là giám đốc sản phẩm), ông là Phó Giám đốc kỹ thuật tại GitHub.

Trong cuộc phỏng vấn này, Lambert thảo luận về một số chủ đề liên quan đến các mô hình phân phối phần mềm gốc trên nền tảng đám mây, bao gồm cả serverless trông như thế nào, ai nên chạy Kubernetes và sự xuất hiện của “cloud-prem” - một mô hình triển khai kết hợp các điểm mạnh của trên nền tảng đám mây. -phần mềm prem và các dịch vụ SaaS. Anh ấy cũng chia sẻ kinh nghiệm trở thành CEO không phải là người sáng lập cũng như lời khuyên của anh ấy về thời điểm và cách thức chuyển từ kỹ thuật sang quản lý.

---

TƯƠNG LAI: Bạn đã mô tả những gì PlanetScale đang thực hiện - ít nhất là dịch vụ không thuần túy SaaS của nó - điện toán "đám mây". Bạn định nghĩa thuật ngữ đó như thế nào?

SAM LAMBERT: Đám mây-prem về cơ bản là một mô hình mới - giải pháp gốc đám mây cho tại chỗ. Theo truyền thống, các công ty phải có một tại chỗ giải pháp hoặc một điện toán đám mây giải pháp, và việc dàn xếp cả hai theo truyền thống là rất khó khăn. Tại GitHub, chúng tôi gặp phải sự căng thẳng khi vận hành github.com và bán GitHub Enterprise như một giải pháp tại chỗ. Với sản phẩm đám mây, chúng tôi phải có khả năng thúc đẩy và phân phối liên tục. Việc cắt bỏ một bản phát hành dựa trên đó là một nhiệm vụ thực sự khó khăn và việc xây dựng kiến ​​trúc cho cả hai có nghĩa là chúng tôi đã không cung cấp giải pháp tại chỗ tốt như lẽ ra chúng tôi có thể làm; nó chỉ là rất khó khăn để làm. 

Khi đến với PlanetScale, chúng tôi đã quyết định rằng chúng tôi chỉ muốn hoạt động trên nền tảng đám mây, nhưng tất nhiên, bạn không thể làm điều đó với một sản phẩm cơ sở dữ liệu hoặc một sản phẩm có yêu cầu tuân thủ nghiêm ngặt. Vì vậy, với cloud-prem, về cơ bản, chúng tôi triển khai mặt phẳng dữ liệu của sản phẩm vào một VPC do người dùng quản lý, nơi họ sử dụng mặt phẳng điều khiển của chúng tôi để sắp xếp nó và chúng tôi quản lý nó. Về cơ bản nó có cảm giác như bạn chỉ đang sử dụng một sản phẩm SaaS dựa trên đám mây thông thường nhưng dữ liệu nằm trong tài khoản của bạn. Nhóm bảo mật của bạn có thể kiểm tra nó và họ cảm thấy an toàn và tin cậy khi có nó trong ranh giới cơ sở hạ tầng của họ mà không gặp nhược điểm là phải tự vá, phát hành và quản lý phần mềm tại chỗ.

Có một lợi ích bổ sung khác, đó là nếu bạn là khách hàng lớn với mức giá thương lượng tốt với Amazon, chẳng hạn, bạn vẫn phải trả mức giá đó và giữ khoản chi tiêu đã cam kết với Amazon trong tài khoản của mình.

Bạn nhận được loại phản hồi nào? Có một số cửa hàng SaaS và cửa hàng tại chỗ cứng rắn…

Chúng tôi có thể cung cấp cho bạn SaaS thuần túy, nơi chúng tôi lưu trữ dữ liệu bên trong tài khoản của mình và mọi người hoàn toàn hài lòng với điều đó. Trở ngại thực sự là nếu mọi người chỉ muốn có mặt tại chỗ. Nhưng mô hình cloud-prem đang thực sự bắt đầu tạo được tiếng vang. Chúng tôi đã yêu cầu các công ty được quản lý sử dụng sản phẩm này vì họ thấy được lợi ích kép của việc lưu giữ dữ liệu cục bộ để đảm bảo an ninh hoặc tuân thủ mà không cần phải quản lý dữ liệu đó. 

Đây là lý do tại sao mô hình này rất tuyệt vời và là một thời điểm thực sự: Bởi vì nó giải quyết được vấn đề không phải các công ty không muốn thực hiện tại chỗ - và về cơ bản nó là một mô hình cũ, đã chết - nhưng hầu như vẫn đáp ứng được các yêu cầu tại chỗ sẽ như vậy.

Nhưng vâng, đôi khi bạn vẫn gặp phải sự kháng cự. Có một số công ty không tin tưởng vào phần mềm SaaS, nhưng đám mây đang nhanh chóng loại bỏ điều đó. Giống như, bạn không được quyết định thời điểm và cách thức Amazon cập nhật S3 và làm cho S3 tốt hơn, điều đó chỉ xảy ra thôi. Điều quan trọng nhất là xây dựng niềm tin với nhiều khách hàng rằng bạn là công ty tốt nhất để quản lý một công việc cụ thể cho họ và giúp họ cảm thấy thoải mái hơn với công việc đó. 

Bạn không thể xây dựng trải nghiệm tốt nhất cho nhà phát triển khi cung cấp phần mềm tại chỗ. Bạn không thể liên tục cải thiện. Bạn không thể quản lý chất lượng, tính khả dụng, thời gian hoạt động — tất cả những thứ đó đều là một phần của trải nghiệm.

Các nhà phát triển có thể khá quan tâm đến cơ sở dữ liệu họ sử dụng. Mô hình triển khai trên nền tảng đám mây nói lên trải nghiệm của nhà phát triển như thế nào?

Nó giống như mô hình triển khai loại bỏ các trình chặn hơn. Bạn không thể xây dựng trải nghiệm tốt nhất cho nhà phát triển khi cung cấp phần mềm tại chỗ. Bạn không thể liên tục cải thiện. Bạn không thể quản lý chất lượng, tính khả dụng, thời gian hoạt động — tất cả những thứ đó đều là một phần của trải nghiệm. Nếu không tự mình quản lý dịch vụ thì rất khó có thể tạo ra trải nghiệm cao cấp như vậy. 

Tất nhiên, một yếu tố chặn chính chỉ dành cho SaaS là ​​một số người dùng cần phải kiểm soát dữ liệu của họ. Một yếu tố chặn chính cho hoạt động tại chỗ có thể là khả năng mở rộng. Và do đó, mô hình cloud-prem giống như một cơ chế để loại bỏ những rào cản đó và mang lại cho mọi người những điều tốt nhất của cả hai thế giới.

Vai trò của Kubernetes trong mô hình triển khai của bạn là gì? Và bạn nghĩ vai trò tổng thể của Kubernetes đối với những hoạt động như triển khai trên nền tảng đám mây là gì?

Kubernetes cho phép chúng tôi triển khai vào môi trường khách hàng theo cách rất chuẩn hóa và trông giống như cụm Kubernetes mà chúng tôi chạy nội bộ. Về mặt kiến ​​trúc, chúng tôi cũng dựa trên Vitess, chạy trên Kubernetes và được phát triển trên Borg, tiền thân của Kubernetes tại Google. Vì vậy, về bản chất, nó có khả năng tự phục hồi rất cao. Nếu bạn mất nhóm hoặc mất cơ sở hạ tầng, nó sẽ tự phục hồi khá nhiều; chuyển đổi dự phòng không phải là điều bạn phải xem xét theo cách thủ công.

Trong mô hình của chúng tôi, người dùng không phải chạy cụm Kubernetes mà chúng tôi triển khai. Chúng tôi không thực hiện mô hình triển khai trên cụm Kubernetes hiện có, điều mà một số nhà cung cấp tại chỗ thực hiện như một cách cố gắng làm cho việc này dễ dàng hơn. Thành thật mà nói, tôi hoài nghi liệu nó có dễ dàng hơn không.

Hầu hết mọi người không cần chạy Kubernetes. Đó là một phụ trợ tuyệt vời cho các nhà cung cấp cơ sở hạ tầng, nhưng Tôi không nghĩ đó nhất thiết phải là cơ chế triển khai phù hợp cho hầu hết các công ty. Tôi nghĩ rất nhiều người đã đi theo con đường đó và nhận thấy rất ít hoặc không thấy giá trị gì từ việc làm đó.

Nếu bạn tải một tệp lên Dropbox và họ hỏi bạn: "Bạn muốn chúng tôi duy trì tệp này trên bao nhiêu máy chủ để nó luôn khả dụng cao?" Bạn sẽ nói: “Không phải đó là số tiền tôi phải trả sao? bạn vì?"

Theo bạn, có mức độ quy mô nào mà nó bắt đầu có ý nghĩa không? Hoặc một trường hợp sử dụng cụ thể, chẳng hạn như điều hành một nhóm nền tảng nội bộ?

Nếu bạn đang làm những gì chúng tôi làm, nơi bạn muốn đơn giản hóa cơ sở hạ tầng và có thứ gì đó linh hoạt như Kubernetes, thì điều đó thật tuyệt. Nhưng mức độ linh hoạt đó rất mở nên nếu bạn chỉ đang xây dựng một công ty thương mại điện tử đang cố gắng lưu trữ một trang web, thì bạn không cần Kubernetes trong phần phụ trợ để thực hiện điều đó. 

Nó được áp dụng rất rộng rãi và tôi nghĩ nhiều người cố gắng xây dựng các nền tảng nội bộ này và họ coi Kubernetes là một cách để có cơ sở hạ tầng nội bộ đơn giản. Không phải vậy đâu; nó không đi đủ xa với trải nghiệm của người dùng cuối. Mọi người nên sử dụng đám mây để làm gì nó tốt nhất và để các đám mây cũng như những người như chúng tôi chạy Kubernetes như một cách đơn giản hóa những gì we làm. 

Nhưng chắc chắn sẽ có lúc một tổ chức có tầm ảnh hưởng đủ lớn để biện minh cho việc vận hành nội bộ một thứ như Kubernetes, phải không? Giống như bạn đang làm ở GitHub?

Nếu bạn có nhiều máy chủ cần quản lý — và chúng ta đang nói đến hàng nghìn máy, chứ không phải nhiều công ty — và bạn muốn cơ sở hạ tầng có khả năng tự phục hồi tốt hơn một chút hoặc có thể tận dụng một nhóm máy lớn, điều đó sẽ giúp bạn có sự linh hoạt để xử lý những việc này. 

Tôi nghĩ câu hỏi dành cho mọi công ty, bất kể lựa chọn kỹ thuật nào, nên là: Điều này có tạo nên sự khác biệt cho khách hàng của chúng ta không? Có câu chuyện hoặc yêu cầu nào của người dùng cuối được cải thiện nhờ chúng tôi vận hành và quản lý cơ sở hạ tầng này không? Và nếu câu trả lời là Không, thì bạn không nên làm điều đó với bất kỳ công nghệ nào cả.

Giống như, về cơ bản thì bây giờ không ai có thể biện minh cho việc chạy dịch vụ lưu trữ Git của riêng họ. Thật điên rồ khi không chi số tiền thấp đến mức nực cười để GitHub hoặc GitLab làm điều đó cho bạn. Đó là một cuộc tranh luận đã được giải quyết; không có lợi ích gì khi tự mình làm điều đó. Khi công nghệ không có máy chủ và công nghệ nói chung trở nên tốt hơn, dòng sản phẩm đó sẽ di chuyển khắp mọi nơi cho mọi người. Bạn sẽ không xây dựng được nhóm cơ sở dữ liệu nội bộ hoặc nhóm vận hành tốt hơn các nhà cung cấp dịch vụ như chúng tôi. 

Và ngay cả khi bạn làm vậy thì làm sao người dùng biết được? Nó sẽ làm gì cho cơ sở người dùng của bạn? Rất ít - 99.9 phần trăm thời gian, họ không quan tâm đến kho công nghệ của bạn. Mọi công ty hầu như chỉ nên làm những việc thúc đẩy người dùng của chính họ và tận dụng nhiều cơ sở hạ tầng được quản lý nhất có thể.

Bảo mật là một vấn đề về trải nghiệm người dùng và nó rất cơ bản. Thật khó để được bảo mật nếu bạn gây khó khăn cho người dùng của mình làm điều đúng đắn.

Bạn thấy mối lo ngại về bảo mật và quyền riêng tư dữ liệu đang gia tăng như thế nào, đặc biệt là đối với các nhà cung cấp SaaS?

Mọi người đều quan tâm đến an ninh. Đó là điều chúng tôi phải cực kỳ coi trọng với tư cách là một công ty lưu trữ dữ liệu của mọi người. Một xu hướng tôi thấy là các công ty đang tiến hành cấp chứng nhận tuân thủ sớm hơn trước đây. Bây giờ bạn phải có được Chứng nhận SOC 2 khá nhiều ngay lập tức, nếu không bạn sẽ không thể chơi được. (Nếu bạn muốn đọc tốt, Fly.io đã viết một bài đăng blog trên SOC 2 điều đó đáng để xem xét.)

Và nói chung, các công ty rất quan tâm đến một số khả năng nhất định hiện đang đóng vai trò quan trọng trong bảng, chẳng hạn như xác thực đăng nhập một lần, ghi nhật ký kiểm tra và mã thông báo truy cập có thể thu hồi thích hợp.

Ví dụ: bây giờ, nếu bạn vô tình kiểm tra thông tin đăng nhập cơ sở dữ liệu của mình vào kho lưu trữ GitHub công khai, chúng tôi sẽ ngay lập tức thu hồi chúng để mọi người không thể truy cập vào cơ sở dữ liệu của bạn. Đó là điều đã từng xảy ra — mọi người sẽ đẩy thông tin xác thực AWS của họ vào kho lưu trữ nguồn mở và sau đó tài khoản của họ đột nhiên được sử dụng để khai thác Bitcoin và họ đã phải chi hàng chục nghìn đô la hóa đơn hoặc dữ liệu của họ bị phá hủy. ở ngoài kia trên internet

Cuối cùng, điều quan trọng nhất của tôi là bảo mật là vấn đề về trải nghiệm người dùng và nó rất cơ bản. Thật khó để được bảo mật nếu bạn gây khó khăn cho người dùng của mình làm điều đúng đắn. Nếu bạn đặt bảo mật ở chế độ không mặc định và là điều mà mọi người phải suy nghĩ và định cấu hình, họ sẽ có nhiều khả năng mắc lỗi hơn. Vì vậy, ví dụ: bạn không thể kết nối với PlanetScale theo cách không được mã hóa — bạn không thể. Mọi người muốn nó khác vì họ muốn lười biếng hoặc họ muốn làm mọi việc theo những cách nhất định. Chúng tôi chỉ không làm cho nó có thể. Kết quả là không ai có thể gây rối và gửi dữ liệu của họ ở dạng văn bản thuần túy qua internet. Điều đó, một lần nữa, là một phần của trải nghiệm người dùng. 

Đối với mỗi [dịch vụ nhà cung cấp đám mây] — và có hàng trăm dịch vụ trên Amazon — có năm công ty khởi nghiệp trẻ đang cạnh tranh với nó. Và sẽ rất khó khăn để quan tâm đến số lượng người dùng và trường hợp sử dụng đó cũng như duy trì quy mô của nó.

Bạn đã đề cập đến serverless trước đây. Định nghĩa làm việc của bạn về serverless là gì?

Cách tôi mô tả là các sản phẩm không có máy chủ tốt sẽ chỉ hiển thị những gì bạn hoàn toàn cần phải kiểm soát để hoàn thành công việc. Nếu bạn tải một tệp lên Dropbox và họ hỏi bạn: "Bạn muốn chúng tôi tiếp tục duy trì tệp này trên bao nhiêu máy chủ để nó luôn có tính khả dụng cao?" Bạn sẽ nói: “Không phải đó là số tiền tôi phải trả sao? bạn vì?" Đó có phải là lời hứa của đám mây? Đám mây không chỉ bổ sung vCPU và bộ nhớ mà còn có nhiều chức năng hơn trên đám mây. 

Serverless cho biết: “Đơn vị giá trị của người sử dụng? Cái gì người sử dụng muốn làm?" Và nó không buộc họ phải làm gì hơn thế. Vì vậy, đối với tôi, đó là một phong trào lạc quan hướng tới sự đơn giản và thiết kế sản phẩm tốt hơn. 

Bạn đánh giá thế nào về mối quan hệ giữa công ty của bạn và các nhà cung cấp đám mây lúc này? “Kẻ thù” có phải là một mô tả công bằng?

Thật thú vị, bởi vì chúng tôi cạnh tranh theo một số cách nhưng chúng tôi cũng mang lại nhiều cách sử dụng hơn cho nền tảng của họ. Đối với những khách hàng đang chạy phiên bản đám mây được quản lý của chúng tôi, chúng tôi làm việc với đại diện của Amazon để mọi người không rời đi và truy cập vào Google; họ ở lại Amazon và sử dụng phần mềm của chúng tôi. Vì vậy, các đại diện vẫn nhận được rất nhiều lượt tiêu thụ, chúng tôi nhận được toàn bộ thỏa thuận đó và điều đó thật tuyệt. Tôi nghĩ họ đang dần đi lùi và để những công ty như chúng tôi mang lại trải nghiệm cho người dùng cuối. Và cuối cùng họ vẫn thắng vì họ vẫn bán được máy chủ với số lượng ngày càng lớn hơn. 

Nhưng chúng ta đang ở giai đoạn giữa thú vị này, nơi họ không chỉ là những nhà bán lẻ lớn. Họ vẫn cạnh tranh với chúng tôi bằng một số sản phẩm nhất định, nhưng điều đó ngày càng khó khăn hơn bởi vì hiện tại, với mỗi dịch vụ của họ - và có hàng trăm dịch vụ trên Amazon - có năm công ty khởi nghiệp trẻ đang cạnh tranh với nó. Và sẽ rất khó khăn để quan tâm đến số lượng người dùng và trường hợp sử dụng đó cũng như duy trì quy mô của nó.

Nếu bạn là kiểu người quản lý không phải lúc nào cũng cố gắng leo lên từng bậc thang - mà chỉ hoàn thành những gì bạn nói rằng bạn sẽ làm, và bạn có tính tập thể khi làm điều đó, bạn giúp mọi người giành chiến thắng và bạn thúc đẩy mọi người tiến về phía trước - bạn chỉ cần tự nhiên được đưa vào những căn phòng lớn hơn.

Không liên quan: Ngay từ đầu bạn đã không phải là Giám đốc điều hành của PlanetScale. Quá trình chuyển đổi từ CPO sang CEO của bạn diễn ra như thế nào?

Khi tôi gia nhập, công ty đang làm mọi việc hơi khác một chút. Chúng tôi đang thực hiện Vitess được lưu trữ trên máy chủ, đây là sản phẩm cũ mà chúng tôi có. Tôi quyết định muốn xây dựng một sản phẩm cơ sở dữ liệu tuyệt vời lấy Vitess làm cốt lõi, trong đó Vitess là công cụ cơ bản nhưng không phải là sản phẩm cuối cùng. Vì vậy, chúng tôi đã vứt bỏ sản phẩm cũ và xây dựng sản phẩm mới này, và nó đã rất thành công. Và sau đó tôi đã thuê rất nhiều người từ công ty cũ của tôi, GitHub, và những người mà tôi biết rõ. 

Vào thời điểm đó, rất nhiều người trong công ty và văn hóa là những người đã đến làm việc với tôi — để làm việc cùng nhau một lần nữa — vì vậy, sự thay đổi kép giữa văn hóa và sản phẩm đã đến thông qua những gì tôi muốn làm. Điều hợp lý cuối cùng là sắp xếp mọi thứ theo tầm nhìn đó. Đó là lý do tại sao tôi trở thành CEO.

Đó là một quá trình chuyển đổi đơn giản được thực hiện và phủi bụi rất nhanh. Ý tôi là, những người sáng lập của chúng tôi rất tuyệt vời. Họ thành lập công ty này, họ xây dựng công ty và sau đó họ bàn giao nó như rất nhiều người sáng lập đã làm. Một số công ty đáng lẽ phải làm theo cách này sớm hơn.

Bạn cũng thăng tiến khá nhanh tại GitHub, từ DBA lên Phó chủ tịch kỹ thuật. Lời khuyên của bạn là gì để thực hiện thành công những kiểu chuyển đổi đó và cũng để quyết định xem việc chuyển sang quản lý có phải là điều đúng đắn hay không?

Trước hết, Nếu bạn đang làm việc tại một công ty yêu cầu phải trở thành người quản lý để có bất kỳ ảnh hưởng nào thì bạn đã đến nhầm công ty. Tôi nghĩ nhiều người rời bỏ vai trò đóng góp cá nhân để đi làm quản lý chỉ để ở lại trong phòng, điều này thật tồi tệ. 

Lời khuyên của tôi là trở thành nhà quản lý nếu bạn quan tâm sâu sắc đến mọi người và quan tâm đến kết quả mà những người vĩ đại có thể đạt được. Bạn có thể đi quá xa theo hướng khác, nơi bạn chỉ là người quản lý nhân sự và không quan tâm nhiều đến công việc. Tôi nghĩ cuối cùng bạn muốn thấy những điều tuyệt vời được xây dựng và bạn làm điều đó thông qua nền văn hóa tuyệt vời và trao quyền cho mọi người. Vì vậy, nếu bạn quan tâm đến những thứ đó và có thể xây dựng những thứ đó, hãy trở thành người quản lý.

Tôi thực sự quan tâm đến những điều đó. Tôi gia nhập GitHub với tư cách là một kỹ sư và tôi đã có tác động ở đó và tôi yêu thích nó. Và tôi biết rằng để mở rộng quy mô, để chúng tôi tiếp tục phát triển kỹ thuật tốt, chúng tôi cần có sự quản lý tuyệt vời. Tôi muốn xây dựng một nền văn hóa hiệu suất cao với những kỹ sư giỏi. Vì vậy, tôi bắt đầu làm điều đó và chúng tôi đã có rất nhiều thay đổi. Công ty đã phát triển, nhưng tôi chỉ làm việc rất nhất quán với những người mà tôi biết đang làm những điều tốt và chỉ trưởng thành từ đó. 

Bạn luôn được yêu cầu làm nhiều hơn. Nếu bạn là kiểu người quản lý không phải lúc nào cũng cố gắng leo lên từng bậc thang - mà chỉ hoàn thành những gì bạn nói rằng bạn sẽ làm, và bạn có tính tập thể khi làm việc đó, bạn giúp mọi người giành chiến thắng và bạn thúc đẩy mọi người tiến về phía trước - bạn chỉ cần tự nhiên được đưa vào những căn phòng lớn hơn. Chuyện đó chỉ xảy ra trong một khoảng thời gian. Và cuối cùng, vâng, tôi đã điều hành một nhóm lớn ở đó với tư cách là Phó chủ tịch vì tôi luôn làm chính xác những gì cần thiết cho doanh nghiệp và bám sát nó, làm việc chăm chỉ và trao quyền cho mọi người. 

Và điều tôi tự hào nhất là có bao nhiêu người đến với PlanetScale từ GitHub vì họ biết điều đó. Bạn có hiểu ý tôi? Họ đã không có ĐẾN. Đối với tôi, đó là dấu hiệu cho thấy tôi có thể thực hiện một cách nhất quán những gì tôi đã nói với tư cách là một nhà lãnh đạo. Mọi người đến vì điều đó.

Ngoài ra: Rất thường xuyên, các nhà quản lý phá hoại công ty. Chúng tôi đã viết một tuyên ngôn quản lý điều đó thể hiện cảm nhận của chúng tôi về vai trò đó.

Nếu bạn không thể chịu đựng được ý nghĩ rằng những sai lầm của bạn sẽ ảnh hưởng đến sự nghiệp của mọi người và rằng mọi người thực sự phụ thuộc vào bạn, thì [công việc quản lý] không dành cho bạn. 

Nếu bạn là một IC đang muốn chuyển sang vị trí quản lý, bước đầu tiên là gì?

Tôi nghĩ bạn phải bắt đầu học cách suy nghĩ một cách xã hội học về động lực của nhóm và những người xung quanh bạn cũng như cách bạn có thể tác động đến cách mọi người làm việc cùng nhau như một nhóm. Trở thành một trưởng nhóm công nghệ, chẳng hạn, có nhiều động lực xã hội hơn là chỉ viết mã tốt nhất. Bạn phải suy nghĩ về những thứ chúng ta phụ thuộc, những người chúng ta phụ thuộc và cách chúng ta định hình tổ chức của mình để phản ánh công việc chúng ta sẽ làm - mà không cần phải đi sâu vào suy nghĩ và cảm xúc của mọi người và thực sự quản lý chúng. . Vì vậy, một cách tốt là thử và lãnh đạo một dự án có nhiều công việc phụ thuộc và liên chức năngvà yêu cầu mọi người phối hợp tốt với nhau để xem liệu bạn có khả năng truyền cảm hứng cho mọi người hoàn thành công việc của họ với tư cách là một nhóm hay không. 

Nếu bạn có thể làm điều đó thành công thì bạn có thể bắt đầu học những kỹ năng cần thiết để thực sự làm việc tốt với mọi người và trở thành người quản lý của họ. Bởi vì đó là một vai diễn khó; đó là một vai trò nô lệ. Mọi người đặt sự nghiệp của họ vào tay bạn và đó là điều bạn phải hết sức nghiêm túc. Nếu bạn không thể chịu đựng được ý nghĩ rằng những sai lầm của bạn sẽ ảnh hưởng đến sự nghiệp của mọi người và rằng mọi người thực sự phụ thuộc vào bạn thì điều đó không dành cho bạn. 

Nếu bạn nghĩ mình có thể làm được và muốn giúp mọi người trở thành phiên bản tốt hơn của chính họ, hãy tham gia.

Đăng ngày 2 tháng 2022 năm XNUMX