Started working in Saturn Pyro Sdn. Bhd. since my graduation period - as a software engineering team lead (product manager too), building a new IoT Energy Efficiency Management system; https://iotwatt.io
This was my first ever production-heavy applicaiton to be built for real-world corporate clients and something glaring I noticed is my inability to work in a team. I can manage one, but I have been lacking in my ability to lead.
Soft Skills
Main thing I’ve noticed in myself: constant what-ifs and complaints. One thing that has to immediately change to ensure the development of the product is quite simply: facing reality and head down building. So, that’s what I did for the past 6 months as of writing this note (November 2025). The first 4 months of development was genuine string-theory 3rd dimension knots of miscommunication, misunderstanding and missed expectations within the team.
There are a few lessons other than the glaring internal issue I had with myself, and they are lessons within our own internal discussions in the team:
- Context beats complexity all the time: As we further designed the application, we focused on the idea that a simple insight will beat a complex algorithm with no explanation. We found this out the hard way with clients asking what is wattmind and what are applets, but we found it was likely the simplest way to explain device efficiency using their own set standard. Sunk cost fallacy led us to continue using the terminology but we’d have to allow users to wrap their head around this, and so we focused on design.
- Real-time is overrated. Next-day is underrated : Executives don’t need millisecond updates. They need accurate daily summaries. Save real-time for operators watching live systems - this is how we’ve planned out and set up IoTWatt.
- Attribution is everything : “The building saved money” is useless. “Chiller 2 optimization saved RM 12,000 this month” is actionable.
- Users don’t read documentation: If it needs explanation, the UI is wrong. Make it obvious. Use colors. Use plain language. Remove jargon.
- Build for the person who has to fix it.: Engineers don’t want “Anomaly detected.” They want “Chiller 2 COP dropped 15%—check refrigerant levels.” This was something we just recently found out, and we’re actively trying to experiment with more ways to understand and design this insight for users of our application.