Li Hui Cham / notes

I’ve spent almost a year at a startup now, doing the work, mentoring interns, and leading a few projects of my own. The freedom to explore compounded my skills faster than anything else could.

Everyone knows getting ahead takes brains and hard work. A year in, I’ve found that what actually separated people had little to do with either. It was who moved first, who acted without waiting for permission, and under uncertainty.

Taking the initiative to fix things

Unlike school when the environment that you are in is mostly controlled (fixed syllabus and timetables), the working world is a lot more hectic, even more so in a startup.

Codebases could be written inefficiently1, raw data being messy or unclean, business documents being scattered across different shared Drives. It’s no doubt that the team moves very fast but at the same time leaving traces of tech debt behind. Some of that debt doesn't impact downstream work immediately. Some does, and by the time you notice it, the snowball has grown big enough to demand attention.

Faced with that, some sit and complain but do nothing, because technically it’s “out of my scope” or “it doesn’t break product”. A small group, though, is willing to take the initiative to fix it.

As juniors, we are unusually well-placed to spot these snowballs. This is because we carry no old SOPs or best practices to defend, no seniority (or ego) to protect and nothing to unlearn.

When a workflow gets annoying enough that the workaround costs 2-3x more time than fixing the root cause would, it usually means the snowball has grown too big to keep ignoring. Ignoring it further only leads to disaster.

That’s why the mindset shift matters so much here. Become the person who takes the initiative to solve it. It all boils down to three steps :

1. Spot the problem. Frustration is the strongest signal.

2. Find the right person2 and ask them the uncomfortable question : “Why does it work like that, and how can we make it better?”.

3. Be the person who says yes to fixing it.

Observing interns and junior employees at my company, I’ve seen where people stall. Almost everyone spots the problem, but few move on to fixing it. Fixing it is painful, but those who run toward it almost certainly come out stronger on the other end and develop new skills in the process.

Sometimes what you dig up is ugly and people have intentionally buried it to avoid the blame. The best leaders I’ve worked with reward individuals for surfacing it anyway. They praise honesty and want the junior person to ask questions instead of nodding along.

Embrace failures in your experiments

Before AI, launching a product took a team one to two years, if not longer. Now I wouldn’t blink if a friend quit their job on a Friday, called themselves a solopreneur and shipped something real in under six months.

At Pluang, we leaned into that :

• A semi-automated pipeline reports and categorises KYC issues, with a human kept in the loop to supervise the AI.

• Non-technical members are writing code to replace their manual work on spreadsheets

Part of my job has quietly turned into being a tech consultant to business teams (not quite at the level of a Forward Deployed Engineer yet), helping them optimise their processes3. In my opinion, there are two ways to solve a problem :

• Build → build → build → test

• Build → test → build → test → build → test

Most people who aren’t used to hacking reach for the first approach - refining it in private until it’s “perfect”, then revealing it to their colleagues or manager. But there’s never only one perfect solution, just as there's never only one road to a destination.

The second approach finds the best road faster i.e. the problem-solution fit. Every test that you wedge between builds, whether a survey, a user session, or something else, uncovers a gap large enough to make or break the whole thing. Following the 80/20 rule, we should tackle the biggest gap first and each iteration brings us much closer to the desired outcome.

Act fast and get your hands dirty

There’s no faster way to learn something than just doing it.

My learning loop has changed drastically. Now, I :

Strikethroughs below are my old method.

1. Face a problem

2. Intense research and planning on Google. Search “how to do XXX” on Google, YouTube and Reddit. Read through two or three posts on each.

3. Get overwhelmed by the 100 different approaches. Pick the one approach I think could solve 80% of my problem.

4. Call it a day. Work on the problem and iterate from there.

By dropping the exhaustive way of learning, I've gained a momentum I never used to have in my projects. I can now deliver in weeks what would once have cost me a quarter. More often than not, by the time everyone else is still deciding how to begin, I've already failed once and started again.

On AI replacing us

You already know the headlines. AI is coming for white-collar jobs, and big tech layoffs happen almost every week now. Juniors are expected to have mid-level skills, gutting the openings for fresh graduates and making interviews brutally hard.

I won't pretend to have the macro answer. But after a year of watching people work, the ones who struggle tend to fall into one of two extremes. And this happens at every level, from junior to senior manager.

• The ones who ignore AI, by choice. They won't touch it, whether from too many excuses or their own fear that learning it means training their replacement. So they fall behind on execution speed.

• The ones who trust AI too much. They tend to be impatient, presenting whatever the AI feeds them without checking it against a domain expert. So the quality of their work gets poorer over time.

Human judgement is still the most valuable thing in the room. AI is astonishing at execution, but it can't yet decide the trade-offs involved in building complex systems or answering high-level business questions.