“The hardest thing when working at a tech product company is getting sympathy from other teams. Why does the product keep bugging constantly, why are the features released so slowly, etc.”
Nam Pham - Director of Engineering at Buymed (thuocsi.vn - Vietnamese health-tech startup has raised series B of 50M USD)
Most early-stage startups choose sufficient technical infrastructure to meet the business and operating requirements. However, when it comes to scale-up, they have to face the choices: how to make the system more robust, easily add more functions, and satisfy more users. That was also the day previous companies recruited me and, most recently, Thuocsi. Naturally, I feel my presence really makes sense ^^
I joined Thuocsi at the end of 2020. The system mainly depended on open-source, resulting in unresponsive in terms of performance and load capacity. In addition, they made the whole team confused because people didn’t fully understand the software. Finally, we decided to rebuild ourselves from CRM, CS, Marketing, Operations, Purchasing, and Delivery,… until now, the changing blood process has been relatively complete. Implementing a new system in any company is fraught with risks. With a new self-build system, the most prominent thing is figuring out how to do it. Do we make it right, or is it enough? Sometimes, when we released a new version, the Operation team was unsatisfied, so the developer team had to rebuild from the beginning. The second risk is that a lot of errors arise. We have a QA team, but it doesn’t work all the time. Users sometimes act differently than we expect. For example, in the phone number box, we think people will enter the number, but no, many still enter words. QA should have checked all the above cases, but within a particular deadline, they can only test happy or risky cases. Besides, the system’s performance also challenges us. Ultimately, I found a way to speed up the process, recruiting and building the first version that worked for the North in just three and a half months.
We have fortunate that all departments understood what was going on. If you build the in-house product, there will be errors. When doing startups, we couldn’t wait for everything to be perfect before releasing it. The fact that users are the testers, and their feedbacks are also much more valuable than the internal testing team. Startup timing is everything. Enter the market too early or too late could make the company stuck. So we have to trade-off.
Trade-offs also remind me of the case of making a purchasing system for customers. If the primary function runs fine when deploying the product, it’s a yay moment. Time, cost, and human effort do not allow us to spend on too severe cases. Technically, these problems are completely doable. For instance, when an internal employee updates a new product’s price at the same time, or in a split of 0.5 to 1 second, a customer orders that item. The real story is that a customer was putting a product at 2$ in the cart, then paid until he returned to the order and saw the new price at 3$. Well, he complained a lot. But we have fixed that; it’s all over now ^^
The hardest thing when working at a tech product company, in my opinion, is getting sympathy from other teams. Why does the product keep bugging all the time? Why are the features released so slowly, etc? Technically, only when we don’t update or add new features but maintain, there will be no errors. As we constantly build, the team can only do its best not to cause stuck for other teams. Of course, I don’t expect everyone to get along well and accept our mistakes. When people report, developers will have more motivation to fix and support. However, I hope other teams can handle it flexibly to avoid affecting the big goal. I always tell our candidates that the company’s goals will greatly affect each person’s work pressure. If the KPI is 5%/year, everyone will be gentle, with no OT, and easy to sympathize with each other. The startup environment can’t be like that! We are always in a state of survival.
Building a successful company is my job goal, not building tech products. Technology is just a part of helping the company grow. I can use any old-school stacks as long as the company x5 x10 revenue. And like the chicken-and-egg story, no one will give me essential tasks if I think this company is someone else. So when recruiting new teammates, I will describe our values, our culture and ask if they want to join. About one-third of candidates turn down an offer, but those who do, they’ll stick around. Regarding firing people, I used to feel very difficult and apologetic. However, I have realized recently that firing is about giving them the opportunity to do other jobs that are more suitable for them, making them happier, and (usually) higher salaries and benefits. It doesn’t seem to be a bad thing.
