Những Sai Lầm Tôi Mắc Phải Khi Làm CTO Mới

Mọi thứ thường bắt đầu vì một lý do, và đó là cách tôi khởi động Madison Technologies. Quá thường xuyên, chúng ta quên rằng có những lý do tại sao chúng ta làm những việc đó. Tôi thích học hỏi qua thất bại. Để thất bại, bạn phải là một người lý tưởng để chọn con đường bạn muốn đi. Tôi đã chọn con đường này vì những bài học tôi học được khi là CTO sáng lập của GOJEK (hiện được gọi là GoTo và niêm yết công khai trên Sở Giao dịch Chứng khoán Indonesia.)

Tôi gia nhập GOJEK vào tháng 12 năm 2014. Tôi là CTO mới và đến ngay trước khi ra mắt ứng dụng di động. Chúng tôi là một đội ngũ vui vẻ gồm 3 kỹ sư cốt lõi, và tôi là thành viên mới. Công việc khó khăn để xây dựng ứng dụng đã được hoàn thành, và tôi sẵn sàng nắm quyền khi chúng tôi ra mắt. Nhìn lại, có sự phấn khích, nhưng lúc đó tôi đã quá sức. Cảm giác như có quá nhiều việc phải làm và không có thời gian hay nhân lực để làm. Dù vậy, tôi bắt đầu làm việc và phân chia thời gian tốt nhất có thể để cuối cùng ra mắt.

Một trong những sự kiện ra mắt đầu tiên của chúng tôi liên quan đến việc tập hợp một nhóm nhỏ các nhà báo tại một nhà hàng ở SCBD, Jakarta. Nadiem, CEO của chúng tôi, đã trình bày một bài thuyết trình, sau đó chúng tôi mời các nhà báo tải ứng dụng và trải nghiệm đặt Gojek trực tiếp. Tuy nhiên, trong thời gian đó, chúng tôi gặp phải một lỗi khó chịu: dịch vụ hiển thị bản đồ với tất cả các tài xế sẽ bị sập, khiến tất cả các tài xế biến mất khỏi bản đồ. Điều này cũng có nghĩa là không ai có thể đặt xe, và chúng tôi sẽ phải khởi động lại dịch vụ.

Và rồi, 5 phút trước khi Nadiem kết thúc bài thuyết trình, tôi liếc nhìn điện thoại và thấy bản đồ tài xế trống rỗng. Tôi chạy đến laptop nhanh nhất có thể, cầu nguyện rằng kết nối 3G từ điện thoại sẽ cho phép tôi ít nhất SSH vào server để khởi động lại dịch vụ. May mắn đã ở bên tôi ngày hôm đó, và tôi đã kịp khởi động lại dịch vụ đúng lúc và ngồi đó thở hổn hển khi các nhà báo trở nên phấn khích vì họ có thể đặt tài xế của mình. Đây là bức ảnh của chúng tôi vào cuối sự kiện ra mắt.

Từ trái sang phải: Sam, Kevin, tôi, Nadiem, Mikey, và Rio

Có rất nhiều câu chuyện như trên. Ứng dụng là trọng tâm chính của chúng tôi, và lúc đó, chúng tôi có rất nhiều đám cháy cần dập tắt. Khi người dùng của chúng tôi tăng lên, chúng tôi gặp phải các lỗi và bug mà chúng tôi chưa từng thấy trước đây.

Trong giai đoạn này, tôi đảm nhận vai trò chiến thuật, trực tiếp làm việc với code và cố gắng debug các vấn đề xuất hiện. Một lần tôi đang phân tích bộ nhớ cho cùng một dịch vụ tài xế vì có vẻ như garbage collector đang làm toàn bộ dịch vụ (đã ở mức 98% CPU usage) bị treo. Mất quá nhiều thời gian đến nỗi tôi quyết định từ bỏ và viết lại API từ Java sang Go, thay thế nó phía sau load balancer của chúng tôi, và ngạc nhiên khi thấy CPU usage giảm xuống 3% cho server đó. Cảm giác thật tuyệt, nhưng đó không phải là điều tôi nên làm.

Tôi cần thêm người, và tôi cần họ nhanh chóng. Tôi đáng lẽ nên chú ý nhiều hơn đến rất nhiều lĩnh vực khác của công ty cần sự giúp đỡ. Chẳng hạn, bảng điều khiển vận hành của chúng tôi, nơi chúng tôi theo dõi việc onboarding và quản lý tài xế, rất cần được cải tổ. Bạn có tin rằng chúng tôi đã sử dụng Post-Its để theo dõi một số trường cơ sở dữ liệu của chúng tôi không? Thật đấy:

Và sau đó là phân tích của chúng tôi để theo dõi chi tiêu quảng cáo đang diễn ra như thế nào. Chúng tôi đã sử dụng nhiều SDK, nhưng đây là một cái nhìn về cuộc trao đổi tôi đã có với đội AppsFlyer lúc đó:

Rất nhiều lĩnh vực khác cần sự chú ý của tôi đã không nhận được nó. Tôi bị mắc kẹt trong tình trạng thiếu nhân sự này và trong một tư duy sẽ không khiến tôi chi tiêu số tiền vốn đã khan hiếm của chúng tôi.

Trước tiên, tôi đáng lẽ nên dành nhiều thời gian hơn để phát triển một mạng lưới các cá nhân thông minh từ không gian công nghệ. Những cá nhân tôi có thể trao đổi ý tưởng hoặc nhờ giúp đỡ khi cần. Tôi tưởng tượng rằng tôi phải bảo vệ chặt chẽ tất cả IP bí mật của mình và không nói chuyện với ai. Tệ hơn nữa, tôi là người hướng nội, và các cuộc trò chuyện không tự nhiên đến. Và kết quả là, tôi có thể tốt hơn trong việc duy trì liên lạc và nuôi dưỡng các mối quan hệ. Nếu tôi đã làm việc đó thông qua mạng lưới của mình, sẽ dễ dàng hơn đáng kể để nhận được sự giúp đỡ hoặc đề xuất về tuyển dụng.

Tiếp theo, tôi đáng lẽ nên song song hóa nhiều hơn. Tôi đang trong cơn sốt tuyển dụng, nhưng có một thời điểm khi tuyển dụng đạt đến điểm mà bạn có một loạt các cuộc phỏng vấn và ứng viên tiềm năng, nhưng tiến độ lại đình trệ. Tôi khá thận trọng và do dự khi đầu tư vào một đội ngũ thuê ngoài để làm việc trên các dự án đồng thời. Trọng tâm của tôi chỉ là lấp đầy các vị trí nội bộ, điều mà nhìn lại, hóa ra là một sai lầm. Nếu tôi đã thay đổi tư duy, tôi đáng lẽ nên tạm thời bổ sung các đội vận hành và marketing của mình bằng một đội kỹ thuật thuê ngoài và cho phép các luồng công việc đó di chuyển song song trong khi tôi làm việc trên các vấn đề thách thức hơn.

Nhìn lại, tác động đáng kể nhất của những sai lầm của tôi là mất mát thời gian. Đây không phải là thứ bạn có thể lấy lại; đối với một startup, thời gian thường là một nguồn tài nguyên khan hiếm khi cố gắng cạnh tranh với những người khác trong không gian đó. Chúng tôi đáng lẽ có thể di chuyển nhanh hơn nếu tôi đã chạy các luồng công việc cho vận hành, marketing và HR song song bằng cách thuê một đội ngũ thuê ngoài. Chúng tôi cũng sẽ có nhiều dữ liệu hơn để đưa vào phát triển ứng dụng. Cuối cùng, chúng tôi có thể hấp dẫn hơn đối với các VC bằng cách giành lại thời gian đó và sẽ huy động tiền sớm hơn. Mặc dù đã tham gia một vài vòng gọi vốn, không có vòng nào diễn ra suôn sẻ hoặc nhanh như bạn mong đợi.

Mặc dù có vẻ đơn giản, đây là một trong những bài học quan trọng nhất tôi học được. Công nghệ không chỉ là sản phẩm cốt lõi của bạn. Việc áp dụng công nghệ mở rộng vượt ra ngoài kỹ thuật và vào các phòng ban khác như Vận hành, Marketing, HR và Tài chính. Các CTO mới đôi khi có thể bỏ qua thực tế này và không cung cấp sự hỗ trợ cần thiết cho các chức năng này một cách kịp thời như yêu cầu. Tôi chắc chắn đã như vậy, và nhìn lại, bước đầu tiên của tôi sẽ là mở rộng trọng tâm của mình vượt ra ngoài sản phẩm.

Một động thái nghiệp dư khác của tôi là nắm quyền sở hữu duy nhất của tất cả mọi thứ liên quan đến công nghệ. Bằng cách cố gắng cung cấp công nghệ cho các đội khác một mình, tôi đã làm chậm mọi người, bao gồm cả chính tôi. Nếu tôi đã đặt một đội ngũ tạm thời hoặc thuê ngoài với một tech lead tốt trong các chức năng đó, tôi đáng lẽ có thể trao quyền cho các chủ sở hữu chức năng để nắm quyền và phát triển các giải pháp theo yêu cầu của họ. Sự phụ thuộc của họ vào tôi sẽ bị giới hạn ở các vấn đề quan trọng như kiến trúc và sự gắn kết tổng thể. Tôi nhận ra rằng bằng cách cố gắng kiểm soát mọi thứ, tôi đang sử dụng tư duy 2x chứ không phải 10x. Vì vậy, hãy từ bỏ kiểm soát, cung cấp cho các đồng lãnh đạo của bạn các nguồn lực, và tránh đường của họ.

Điều này đưa chúng ta quay trở lại lý do tại sao tôi bắt đầu Madison Technologies. Chúng tôi ở đây để giúp bạn di chuyển mọi thứ nhanh hơn. Chúng tôi ở đây để nhận phần việc trong khi bạn thuê đội ngũ mơ ước của mình. Chúng tôi đã ở đó trước đây, và chúng tôi sẽ vượt qua điều này cùng nhau.

Hãy liên hệ với tôi qua LinkedIn của tôi để có cuộc trò chuyện sâu hơn. Hãy kết nối!

Sheran Gunasekera là một nhà nghiên cứu bảo mật và nhà phát triển phần mềm. Ông là đồng sáng lập và Giám đốc Nghiên cứu của Madison Technologies, một công ty phát triển phần mềm ở Singapore, nơi ông tư vấn cho đội kỹ thuật nội bộ về bảo mật máy tính cá nhân và thiết bị di động. Cuộc hành trình của Sheran vào bảo mật di động bắt đầu vào năm 2009 khi ông bắt đầu với nghiên cứu bảo mật BlackBerry. Kể từ đó, ông đã đảm nhận các vai trò lãnh đạo trong cả kỹ thuật và bảo mật tại một số startup ở châu Á bao gồm GOJEK, ứng dụng đa dịch vụ theo yêu cầu hiện đã được niêm yết công khai.