Tech, Leadership, Systems, Blogging | Articles by Victoria Lo

Inside a Mastermind’s Mind: How Empire of AI Deconstructed the Great Game

Victoria Lo — Sun, 05 Apr 2026 23:00:00 GMT

Recently, I enjoyed reading Karen Hao’s Empire of AI and watching her on the Diary of a CEO episode. Like most people, I had heard the initial headlines about carbon footprints, labor exploitation, and data centers. Most readers walk away from her work feeling a sense of dread or a call to social activism.

But as I turned the pages and listened to her break down the history of OpenAI, how he engages in mythmaking, his way of manipulating other around him for his goals, I became so intrigued. This is no longer a book about how a company rise to power in the AI space to me. Instead, I recognized the "scent" of a high-level architect, a grandmaster play a game of chess while everyone else was still trying to remember how the pieces moved.

Welcome back to another Articles by Victoria, the place where I randomly write things I’m curious about.

In this article, I want to explore something I don’t usually write about: psychology, specifically what might be going on inside the mind of a mastermind like Sam Altman. Whether we like him or not, it’s hard to deny that he understands the game and has played it well, strategically building one of the most influential AI empires of our time.

Why is Sam Altman a Mastermind

As an INTJ myself, I’ve always been drawn to understanding how people think at a systems level, how they make decisions and the underlying logic behind them. In my article on How Cognitive Functions Changed the Way I Understand People, I wrote a 3000+ word article on my deep dive into how I observe and interpret human behaviours.

Within the framework of cognitive functions, the INTJ archetype is often called the “mastermind” or the “architect” because of their ability to see patterns, anticipate outcomes, and strategize long term.

For those of us wired this way, the world is a series of systems to be understood and mastered. We don't just look at what a person does. We look at the "why" and the "how" behind the execution. Watching Sam Altman through Hao’s lens became intriguing for me. I'm not saying I align with his values or support his actions. It wasn't about whether his impact was "good" or "bad" (honestly that's a whole another article waiting to be written haha).

Instead, it was about the sheer, breathtaking scale of his psychological and long term strategic planning. Emphasis on the long term part. And that's why I was so intrigued, simply from a scientific point of view.

He didn't just build an app/product. He shaped and framed a global narrative, redirected the flow of billions in capital, and outmaneuvered the smartest and most powerful people in the room. And that's something I want to dissect in this article. How did he do it? What went through his mind as he planned with such precision, positioning each move for the long game, almost like placing pawns on a chessboard several steps ahead of everyone else?

And more importantly, why does it now feel like parts of that strategy are starting to fracture? What was the blind spot the one that even highly strategic thinkers tend to overlook?

This is a study of that mind: the motivations, the goals, and the dark, complex psychology of a man who is always thinking three steps ahead.

To those of you who usually read my work on tech, leadership, and reflections this is a bit of a digress.

If this direction intrigues you, I’m happy to go deeper and explore more of these psychological and strategic breakdowns in future pieces. But if it feels a little too intense or uncomfortable, I can stick to what I usually write about. Let me know by reaching out!

The Dinner Party Gambit: Engineering the Original Team

One of the most revealing sections of the book involves the literal birth of OpenAI. It wasn't a spontaneous meeting of minds, but was a carefully staged social engineering project. Altman didn't just send a generic LinkedIn message. He launched a high-stakes recruitment campaign through cold emails and frequent, intimate dinners, targeting the "titans" of the field: Dario Amodei, Ilya Sutskever, and Greg Brockman.

As an INTJ, I found the mechanics of these dinners fascinating. Sam Altman wasn’t just offering high salaries to attract talent. He was leveraging something far more powerful: social currency.

By hinting that Elon Musk might show up, he created an almost irresistible pull. Musk, at the time, was one of the most polarizing and magnetic figures in tech and Altman understood exactly what people were drawn to.

It was a classic blend of FOMO and proximity bias. At that time, he knew he was a nobody so he strategically borrowed Musk’s brand to validate his own vision and get these geniuses into the room.

And the result: they all joined. Maybe it’s easy to say this now, knowing how things played out. But even from the start, I never fully bought Altman's "non-profit" pitch. I don't believe in the altruistic mission. How can a person like him not make this revolutionary technology for profit? It makes zero sense to me.

Then again, perhaps he hid his true intentions well. Perhaps if I was there in the room, I would have been fooled too.

Only later, as Hao’s narrative unfolds, do we see the fallout. One by one, the original team realized they weren't partners in a mission but were part of a system being built for something else entirely, like components in a machine Altman was building for a very different purpose.

When it became clear that the “non-profit” structure was more of a phase than a principle, some chose to leave. People like Dario Amodei went on to build alternatives like Anthropic.

From the outside, it looks like a talent drain. Was the non-profit vision ever meant to last, or was it simply the most effective way to gather the right minds at the right time to build something much bigger?

From my analysis of the mastermind’s perspective, he had already extracted what he needed from them: the initial breakthrough and the technical legitimacy to pivot into a global power player. It was all part of the plan, a gambit. He never intended for OpenAI to stay a non-profit, he just needed their brilliance to build the foundation of his for-profit empire.

Myth-Making as a Tool of Control

In the DOAC episode, I particularly enjoyed how Karen Hao talks about how empires create power and control using an analogy from the sci-fi epic Dune. In that world, leaders engage in "myth-making" to control the masses. They plant prophecies and religious narratives among the people to ensure their own rise to power. Hao argues that AI leaders, starting with Altman, are doing the exact same thing.

They know the "AGI for humanity" mission is, at its core, a myth designed to gain power and control. By showing off incredible tech demos and speaking about a future where AI solves every human problem, they make the public eager to "jump into" the AI era. But the question is: Can AGI really help humanity?

This is something I’ve spent a lot of time discussing with close friends and colleagues. There are a couple of likely scenarios for the future once AGI arrives, but maybe I’ll save that for a future article.

Anyways, back to myth-making for control, here is where the psychology gets truly complex as Hao explains in the episode: when you embody, live, and breathe a myth daily to convince others, the line between the lie and reality begins to blur.

These companies eventually lose themselves in their own stories. They started by using the myth as a tool to bypass ethical scrutiny and gain funding, but eventually, the mask becomes the face.

This reminds me of a quote by French author François de La Rochefoucauld:

We are so accustomed to disguise ourselves to others that in the end we become disguised to ourselves

It’s a reminder of how easy it is to lose sight of our true intentions when we’re constantly performing for the world. For someone like Altman, I find this a fascinating study in cognitive dissonance. He had to play the part of the selfless visionaries so convincingly for so long, has he actually started to believe it himself?

He convinced the world that AGI was a singular event that must happen. More importantly, he convinced people that it must be achieved by his team to ensure it was done safely. This was his social shield. By framing his company as the protector of humanity’s future, he made any scrutiny of his business model seem petty or even dangerous.

When you frame yourself as the one saving the world, people stop asking about your environmental footprint or where your training data came from. You provide a vision so big that people are happy to inhabit it, even if it means ignoring or underestimating the "dark" reality of how that vision is being built.

Gathering Resources: The Long Game of Recruitment

As a gamer, I mostly play strategy games because they are both fun and mentally stimulating. In any strategy game, the first step to gaining exponential returns is gathering resources. In an RPG or MOBA games, for example, you need to understand how the system lets you acquire resources, whether it is money, items, or abilities. You need to know what to prioritize, where to get it, and how to leverage it most efficiently. Watching Altman operate in the tech world reminded me a lot of that.

The longest-running game begins with the gathering of resources. In the tech world, the rarest resource is not money but elite talent. The founding of OpenAI as a non-profit in 2015 was, from this perspective, the ultimate recruitment funnel.

To the public, this was inspiring. To the researchers, it was a philosophical beacon. To a strategic mastermind, it was a way to lower the psychological guard of the world's most skeptical minds. Because he understood one thing: the best AI researchers didn't want to build ad-click algorithms for Facebook. By framing OpenAI as a "non-profit mission," Altman gave them a "cause" to follow rather than just a job to do.

He effectively aggregated an unparalleled concentration of brainpower under a banner of ideological purity. He wasn't building a company yet, he was building a following. This allowed him to lock down the human capital he would later need to execute his true, much larger vision.

This game's screenshot has nothing to do with Altman, but I love Pokopia and thought it was a cute visual to represent “building a following” haha

The most chess-like move in the book is Altman’s recent trend of going to governments and asking for AI regulation. For the average observer, this looks like a responsible leader recognizing his own power. For the strategist, this is the final phase of dominance: regulatory capture.

Hao’s reporting makes it clear that building AI is becoming incredibly expensive. The real threat to OpenAI is not Google; it is the smaller, faster, open-source startups. By asking for regulation, Altman is essentially helping write a set of safety rules that are so complex and expensive to follow that only a giant like OpenAI can afford to meet them.

He is using the government to build a moat around his empire. While the public sees a responsible leader, I see a master architect making it nearly impossible for anyone else to compete. It is a masterclass in using your enemies' tools, the law, to protect your own throne.

From my perspective as an INTJ and someone who loves strategy games, it is fascinating to see the parallels. The careful planning, the leverage of psychological incentives, and the patient accumulation of resources all point to a mind thinking many moves ahead. In both games and real life, the early stages of resource gathering are often invisible, but they set the stage for everything that follows.

Decoding the Pivot: Results Over Consistency

The moment I realized just how deep Altman’s game went was when Hao described the "pivot." In 2019, OpenAI moved from a true non-profit to a "capped-profit" entity, taking a massive $1 billion investment from Microsoft. Many critics in the book called this a betrayal. To me, it looked like a cold, logical solution to a physical constraint. Typical way of how an INTJ like him would operate.

An INTJ’s mind is a machine built for execution. We have a singular vision (Introverted Intuition or Ni) and we use logic (Extraverted Thinking or Te) to make it real. By 2019, Altman likely realized that AGI wasn't just a research problem. It was a power and hardware problem. He saw an immovable wall: the hundreds of millions of dollars needed for GPU clusters and electricity.

He didn't (or should I say couldn't) allow the "non-profit" label become a prison and constraint for him. He calculated that consistency was less important than survival.

While everyone else was mourning the "soul" of the company, Altman was busy redesigning the entire financial architecture of his organization to accommodate the reality of the hardware costs. He prioritized the end goal over the public's perception of his values because at the end of the day, it was all about keeping control for him.

That is the hallmark of a mastermind: the ability to pivot the entire system the moment the old way becomes a liability.

The Blind Spot: Visibility Over Caution

Despite all his brilliance, Altman’s strategies were not invincible. The pivot and the recruitment of world-class talent show a mind operating at the highest level, a masterclass in long-term planning, leverage, and influence. And yet, even the most strategic thinkers have blind spots. The very moves that give them power internally can expose vulnerabilities externally.

In my opinion, Altman’s biggest misstep may have been that he didn’t lie low. He built a genius-level system of recruitment, narrative, and leverage, yet he also made himself highly visible. His boldness drew attention, both admiration and scorn. The mission of AGI, once untouchable, began to reflect on him personally and to some, it painted him as cold, calculating, or even sociopathic.

This blind spot became obvious during the legendary November 2023 firing and reinstatement. The board attempted to remove him, citing a lack of transparency and a breakdown of trust. They claimed he “pitted executives against one another” and withheld major developments, including the launch of ChatGPT.

This is classic INTJ strategy. He made himself the load-bearing pillar of the organization. The company’s identity, Microsoft’s investment, and the entire AGI mission were tied to his persona. Removing him risked collapsing the structure.

But what makes this moment even more interesting is hearing it from Sam Altman himself. In the Social Radars podcast interview, he described the firing as a complete shock. He called it a “fog of war,” implying that even someone who plans several moves ahead did not anticipate this attack.

Yet, his system responded exactly the way it was designed to. While he was caught off guard, the structure he built held. Within days, over 95% of employees and Greg Brockman threatened to resign unless he returned.

He did not need to fight directly because the system fought for him. In less than a week, he was reinstated, and the very board that fired him was dismantled. From a strategic perspective, it was almost flawless execution under pressure.

But from what I see, this is also where the blind spot reveals itself. The fact that he was genuinely surprised shows something important. Even with all his foresight, he underestimated internal resistance and the human layer of trust, politics, and perception. That is something INTJs are often weaker at.

More importantly, by making himself so central and so visible, he exposed himself to a different kind of risk. His system could protect him internally, but it could not shield him from external scrutiny. The world was watching this play out in real time. People started asking questions, not just about the company, but about him.

The same strategic brilliance that made him indispensable also made him a target. The moment he returned was not just a victory. It was also the moment the facade began to crack.

The Slow Downfall

Over the next several months, cracks in Altman’s strategy became impossible to ignore. In May 2024, after OpenAI’s non-disparagement agreements were exposed, he was accused of lying about whether he knew about equity cancellation provisions for departing employees. Former board member Helen Toner explained that he had withheld critical information, including the ChatGPT release timeline and his ownership of OpenAI’s startup fund. She also reported that some executives described psychological abuse and feared retaliation if they did not support him. Critics pointed to similar patterns from his time as CEO of Loopt, describing "deceptive and chaotic management".

At the same time, Altman’s public credibility started to erode. Writers like Karen Hao highlighted these patterns in bestsellers, and commentary in publications such as The Guardian raised questions about circular financing deals and the sustainability of OpenAI’s strategy. His defensive responses to investors, including Brad Gerstner, were widely seen as unconvincing. The hype around GPT-5 only made matters worse, as the product fell short of expectations despite Altman’s persistent promises.

Technical setbacks were mirrored by business challenges. Competitors like Anthropic captured corporate clients, DeepSeek forced dramatic price cuts, and OpenAI continued to operate without turning a profit. Reports showed corporate customers were not seeing meaningful returns on their investments. In December 2025, Altman declared a code red. Even high-profile partnerships were starting to falter. Apple’s 2024 pilot with OpenAI appeared to underdeliver, leading the company to switch to Google for integrating generative AI into Siri.

A Reflection on the Architect’s Style

By the time I finished Empire of AI and the DOAC episode, I felt a mix of awe, curiosity, and disbelief. I found it fascinating that Sam Altman could push a strategy this far while carrying such obvious blind spots, especially in how he manages people.

As an INTJ, this hits close to home. The same traits that make someone effective at building systems, thinking long term, and executing with precision can also create distance from the very people those systems depend on. It is easy to prioritize outcomes over relationships, logic over empathy, and vision over alignment.

Watching Altman’s trajectory felt like watching that trade-off play out at scale. He mastered leverage, narrative, and timing, but the human layer kept pushing back. Trust eroded. Perception shifted. And once people start questioning the person behind the system, even the most well-designed strategy begins to feel fragile.

What stood out to me is not just how far he got, but how long the system held despite those cracks. It says a lot about the strength of his thinking, but also about the limits of it. At some point, no amount of strategy can fully compensate for blind spots in how you deal with people.

Conclusion

Karen Hao’s book may be a warning to many, but to me, it was a psychological profile of a genius at work. The world is currently living in an "Empire" that was envisioned years ago in silence. Sam Altman isn't just a CEO, he is a systemic architect who understands that the long game is won not through luck, but through the cold, precise manipulation of every available variable.

We are all just pieces on the board he designed. Whether that is a good thing or a bad thing is up for debate, but for those of us who appreciate the art of the mastermind, his story is quite an interesting case study.

Thanks for reading! I’m curious to know your own personal thoughts and experiences on this topic! Feel free to connect or let me know in the comments! Cheers!

Let's Connect!

References

Why No One Actually Gets Hired From Online Applications

Victoria Lo — Sun, 29 Mar 2026 23:00:00 GMT

Welcome back to another Articles by Victoria, the place where I randomly write things I’m curious about.

Back in February, I spoke at Nanyang Technological University on “How to Make Opportunities Find You.” During that session I shared stories from my own non‑linear career journey, and introduced a structured framework for creating opportunities and connecting with people who actually open doors.

After the talk, several students connected with me on LinkedIn and politely asked the same question in different ways: “I’ve applied for so many jobs online and heard nothing back. Why does it feel like online applications never lead to offers?” That question has stayed with me, and it inspired this article.

It is not because you lack talent or your resume isn’t good enough. It is because the way most hiring systems are designed, especially in Singapore, across Asia, and increasingly globally.

To understand why this happens, we need to step back and look at the reality of hiring today, the data from organisations across this region, the experiences of job seekers and recruiters that I’ve spoken with over the years and my personal experience as a tech lead when hiring.

Job boards are increasingly automated

When you submit your resume through a job portal like JobsDB, MyCareersFuture, LinkedIn, or a company’s careers site, you’re entering a system that is handling hundreds of candidates for every open role. In Singapore, most mid‑to‑large employers receive well over a hundred applications for every position. Larger multinational companies often receive 200–300 applications per posting.

That sheer volume creates a very real problem for recruiters. They cannot possibly read every resume in detail. Instead, companies increasingly rely on Applicant Tracking Systems (ATS) that filter resumes based on keywords, job titles, and specific criteria before any human ever sees them. In many cases, resumes can be filtered out automatically because the system didn’t recognise a keyword, formatted the document in a way that the ATS couldn’t parse, or the candidate didn’t match a very narrow set of criteria even if they are perfectly capable for the job.

Having been part of the interview process as a Solutions Engineer Lead, I can tell you firsthand how overwhelming that volume is. When a role is open, HR would send me dozens of resumes flood my inbox, many of them were superficially filtered. It is impossible to read each one thoroughly, and the pressure to move quickly is real, as our teams need solutions (the right person with the right skills), not a backlog of resumes.

As a result, I tend to rely on signals beyond the resume itself. Referrals, prior interactions with candidates, and visible contributions to the community often carry more weight than a long list of bullet points.

Singapore recruiters I’ve spoken with tell me that often only 10–15 percent of resumes actually reach a human reviewer. After that, only a small number of candidates get shortlisted for interviews.

This helps explain why so many applications disappear into silence.

Most roles are filled through referrals

One of the most counter-intuitive aspects of hiring today is that many roles are filled through networks and referrals rather than public job postings. This makes sense because hiring managers are trying to reduce risk. Bringing someone on board is expensive, time consuming and has a direct impact on team performance. When a candidate comes recommended by someone the company already trusts, that referral is a signal about the person’s ability, attitude and reliability. It already provides context that a resume alone cannot convey.

This is the irony I often see as I build a tech community like Women Devs Singapore. Many tech fresh grads and professionals are naturally introverted and hesitant to network, yet networking is precisely how most opportunities arise.

In my WomenDevsSG community, I have seen that members who proactively build genuine connections through thoughtful conversations, mentorship or collaboration are often the first to hear about open roles. When a position becomes available, people who have formed real, value-adding relationships are more than happy to refer them and offer opportunities.

I hear this a lot: But Victoria, it sounds so transactional. I'm a technical person so I prefer to prove my skills rather than spend my time networking.

Networking in this context is not about transactional job hunting. It is about fostering authentic relationships that naturally lead to career growth. I may write a future article to dive deeper into how to build these genuine connections, but the key takeaway is clear.

You need to have meaningful engagement with your professional community which can open doors for you that online applications alone rarely reach.

That is not to say referrals are an unfair shortcut. It is simply how human psychology and decision-making works. People are the ones who hire you, not companies. In cultures where trust and reputation are important, who you know matters because it helps employers understand something about you before taking a risk. When you see it this way, networking is mandatory and becomes something foundational to career growth.

The Harsh Truth: every resume is almost identical

I wrote about this in depth in The Ultimate Resume Guide for Developers, and the same holds true across industries. Resumes are incredibly limited in showcasing who you are as an individual. They compress years of experience into a series of bullet points that describe tasks and technologies you know. Rarely do they capture how someone thinks, how they lead, how they solve problems, or how they work with others.

When recruiters and hiring managers see resumes, they are often looking for signals that help them differentiate between candidates because most resumes, unfortunately, look very similar. Two candidates may list the same school, same courses they take, same technologies, same years of experience, and even the same generic projects they build in their portfolio. On paper, they would appear almost identical, even if their real experience and potential are quite different.

In markets like Singapore where multinational firms and global teams are evaluating candidates, recruiters would see dozens of applicants who all check the “minimum requirements” box. But the resume alone cannot tell who will thrive in the role so the safest choice becomes prioritising those who come with an introduction, a referral, or some personal brand that offers extra context.

Once you realise that resumes are signalling devices and not complete representations of you as an individual, you see why online applications often feel unresponsive.

Personal Branding and Visibility Matter More Than Ever

As a Solutions Engineer Lead, how I screen candidates from their resumes is beyond their tech stack and years of experience. Because everyone is "proficient in JavaScript" these days and everyone is "mid-level engineer graduated from top school with a passion to build ABC". What stands out in a resume to me is how they communicate, think and work with people, and that all ties back into personal branding.

This is one of my most well received article on personal branding if it is of interest to you: https://lo-victoria.com/your-name-is-already-a-search-term-you-just-need-to-searchable

You might have read some of my other articles like Your Name is Already a Search Term or my Blogging Tips Series. From those articles, one of the key takeaways is that employers today often search for candidates online. They look for professional presence on LinkedIn, for contributions in communities, for portfolio sites, for articles, open source contributions, and other signals that demonstrate quality beyond a resume.

The paradox of online applications is that the easier they become to submit, the harder it becomes to stand out among hundreds. A resume submitted through a portal is static. Your LinkedIn profile, your blog, your writing, your interactions in professional spaces are dynamic and provide context that helps someone know you a little before even meeting you.

I can say this with 100% certainty that all the opportunities that came to me so far were from building my personal brand online, through blogging and community building. These opportunities snowball and create more opportunities for me.

When I speak about personal branding and how to create opportunities that find you, this is the core idea: instead of passively wondering if someone will call you after sending a form, you build professional visibility in ways that spark curiosity and invite connection (while still sending out resumes of course).

This is especially important in Singapore and much of Asia, where networks and reputation flow through communities, industry events, meetups, and shared professional spaces. I’ve seen firsthand how someone with a strong, visible professional presence receives inbound opportunities from recruiters, founders, and hiring managers even when they aren’t actively applying.

A Framework for Making Opportunities Find You

In my talk at NTU, I introduced a structured framework that helps job seekers and professionals open doors proactively rather than waiting for the system to respond:

Define your value and niche – Know what you offer and how you want to be perceived professionally. This goes beyond a resume into how you articulate your brand publicly.
Build a visible professional presence – Through platforms like LinkedIn, but also through writing, speaking, communities, and contributions (WomenDevsSG has open source projects btw).
Engage with your target network intentionally – Reach out to people with empathy, curiosity, and a genuine mindset of learning rather than immediate gain. People can sense others who just want to take/gain and instinctively avoid them.
Create signal over noise – Instead of broadcasting generic resumes to job boards, create work that invites attention and demonstrates your thinking on a certain topic you want to be known for.
Follow up and stay in touch – Relationships develop over time. Real opportunities often arrive months after the first conversation. Persistence here is relational, not transactional.

Conclusion

The reason hiring through online applications feels so unresponsive is because the mechanisms behind most job boards were never designed for meaningful human evaluation. They were designed for scale, to sort and to help recruiters weed through numbers.

But hiring itself has always been, and continues to be, a human process wrapped in uncertainty. Employers hire people they trust, or people they feel they can understand quickly. They hire people they have context about. And that context comes from relationships, visibility, reputation, and signal.

Don't get me wrong, online applications still matter and yes, they are part of the ecosystem. But they are not the primary path that leads to offers. They are just one channel among many.

The thing is that often, they are the one and only channel people in tech focus on because it feels structured, official and "not a shortcut". But real momentum happen when you build presence, relationships, and professional signals that invite opportunities to find you.

Thanks for reading. I’m curious to know your own personal thoughts and experiences on this topic. Feel free to connect, send me an email (my inbox is always open) or let me know in the comments. Cheers!

Resources

Let's Connect!

Debunking the AI Bubble

Victoria Lo — Sun, 22 Mar 2026 23:00:00 GMT

Welcome back to another Articles by Victoria, the place where I randomly write things I’m curious about.

Over the past year, I have found myself increasingly uncomfortable with how casually we (and the media) throw around the phrase “AI bubble.” It has become the default framing for almost any conversation about generative AI.

You'll likely come across this phrase whenever funding rounds get larger, whenever another company announces an AI feature, whenever layoffs happen in the same quarter as an automation announcement, someone inevitably says, “This feels like a bubble.”

And to be fair, the instinct is understandable. We have lived through enough hype cycles to recognize the signs. Like when capital floods in, expectations become unrealistic, headlines get louder than fundamentals, and then eventually the market corrects. The dot com era burned itself into institutional memory so when we see massive AI valuations and nonstop announcements, it feels familiar.

After reading The State of AI: How Organizations Are Rewiring to Capture Value by McKinsey & Company, I had some thoughts.

A quick note

This report is based on a global online survey conducted in July 2024, with 1,491 respondents across 101 countries. The participants span industries, regions, company sizes, and seniority levels, including C suite executives, senior managers, and midlevel leaders. About 42% of respondents work in organizations with more than 500 million dollars in annual revenue, so a significant portion of the data reflects large, established enterprises rather than early stage startups.

The results are also weighted by each country’s contribution to global GDP, which means the findings aim to represent the broader global economic landscape. In other words, when we talk about 78% of organizations using AI, we’re largely talking about structured companies with real governance, compliance requirements, and complex operational systems.

What is a Bubble?

An economic bubble tends to have the following traits:

Excitement is high about something new like a new technology but the underlying value is weak
Investors put in lots of money into this something mostly because they fear missing out
In a bubble, hype grows faster than actual results or benefits
Classic signs: soaring valuations, flashy announcements, lots of attention but little long-term impact

When a bubble bursts, we are referring to the phenomenon when:

Prices or valuations drop sharply after rising too fast
Hype and expectations collapse because reality doesn’t match the excitement
People quickly pull back their investment, interest, or adoption
Projects, companies, or initiatives that were driven by FOMO fail or shrink rapidly
Overall, the market or sector sees a sudden loss of confidence and momentum

So the question: Are we in a AI bubble? is not an easy question to answer. To move beyond speculation, let’s look at some hard data from McKinsey. Their survey gives us insight into how organizations are actually using AI, where value is being created, and where challenges remain. This evidence helps us understand whether the excitement is just hype or something more substantial.

Adoption is no longer experimental

One of the most striking data points in the report is that 78% of organizations now use AI in at least one business function, while 71% report regular use of generative AI in at least one function. This is not fringe experimentation happening in innovation labs or hackathons. This is mainstream adoption across IT, marketing and sales, service operations, product development, and software engineering.

When adoption crosses this kind of threshold, the conversation shifts. We are no longer debating whether AI will enter the enterprise. It already has. The real question becomes whether organizations are using it superficially or structurally.

At the same time, the report is clear that bottom line impact remains limited at the enterprise level. More than 80% of respondents say they are not yet seeing tangible enterprise wide EBIT impact from generative AI. That gap between widespread adoption and limited measurable enterprise impact is precisely where bubble narratives tend to grow. From the outside, it can look like enthusiasm without returns.

However, what the data reveals underneath that surface is much more nuanced.

The hype and the promises sold

Much of the early excitement around AI has focused on large language models, or LLMs. They make for flashy demos, attention-grabbing headlines, and bold promises about transforming work overnight. It’s easy to see why many organizations rushed to integrate LLMs into their tools and workflows.

Companies that rely solely on LLMs without thinking about how work actually flows often see limited results. McKinsey’s data confirms this. The biggest driver of measurable impact from generative AI isn’t the sophistication of the model or the number of pilots a company runs. It’s workflow redesign.

Long Term effect: Workflow Redesign impacts success of AI deployment

In the report, McKinsey analyzed 25 different organizational attributes and their relationship to bottom line impact from generative AI. The single strongest driver of EBIT impact was not model sophistication, not the number of pilots, not how aggressively companies marketed their AI initiatives. It was workflow redesign.

21% of organizations using generative AI report that they have fundamentally redesigned at least some workflows as part of deployment. That number may not sound dramatic at first glance, but if you have ever worked inside a large organization, you know how difficult fundamental workflow redesign actually is. It requires cross functional alignment, operational mapping, retraining, governance adjustments, and change management discipline.

That detail fundamentally changes how I think about the so called bubble. Bubbles are characterized by surface level adoption driven by fear of missing out. Structural redesign is driven by long term strategy. When companies start rethinking how work flows through their systems, they are making decisions that will shape cost structures, talent requirements, and performance metrics for years to come.

AI adoption is a leadership problem, not just technical

Another element that stood out to me is governance. 28% of organizations report that their CEO oversees AI governance, and in many large organizations, boards are directly involved. The report emphasizes that CEO oversight is strongly correlated with higher self reported bottom line impact from generative AI.

This is important because it signals where AI sits in the power structure of the organization. When technology is delegated entirely to only engineering teams, it often remains tactical.

As a Solutions Engineer Lead, I sit at an interesting intersection. Because I’m in conversations with stakeholders who are trying to figure out how to operationalize AI inside messy, real world systems.

What I’ve noticed is that the companies that see meaningful impact are not the ones chasing the flashiest demo. They are the ones with their C-suite leaders willing to sit through uncomfortable conversations about ownership, process redesign, data quality, and measurement. They ask who is accountable for this workflow. They ask how we will measure whether this actually improves outcomes. They are prepared to change how teams operate, not just layer AI on top.

That gap in execution feels more significant to me than the gap in technology.

Risk Mitigation is accelerating

One of the defining characteristics of speculative hype cycles is underestimation of risk. Companies move quickly, often overlooking governance until problems accumulate. In contrast, this report shows organizations actively increasing mitigation efforts around inaccuracy, cybersecurity, intellectual property infringement, privacy, and regulatory compliance.

47% of organizations report experiencing at least one negative consequence from generative AI use. That statistic is significant because it demonstrates that companies are not operating under the illusion that AI is flawless. They are encountering real operational friction. Yet instead of retreating, they are building centralized governance structures, hiring AI compliance specialists, and implementing review mechanisms for outputs.

27% of respondents say their organizations review all generative AI outputs before usage, while a similar proportion review very little. That variation reflects experimentation with oversight models, but the existence of formal review structures indicates seriousness. Organizations are not blindly deploying systems without guardrails.

The Real Data on Workforce

Much of the public conversation around AI centers on job displacement. The survey paints a more complicated picture. While certain functions such as service operations and supply chain management are more likely to experience headcount reductions, many respondents expect no overall workforce change in the next three years. In IT and product development, expectations actually tilt toward headcount increases.

At the same time, organizations are reskilling employees in meaningful numbers and expect significantly more reskilling over the next three years. Half of respondents whose organizations use AI say they will need more AI data scientists in the coming year. Companies are also hiring AI compliance and ethics specialists, roles that did not exist at scale a few years ago.

This suggests reconfiguration rather than simple contraction.

If this were a fragile bubble, we might expect erratic hiring followed by dramatic pullbacks. Instead, we see structured reskilling programs, forward looking talent planning, and role diversification. The labor market is adjusting, but it is adjusting through managed transformation rather than abrupt collapse.

The gap between bigger and smaller companies

All of this does not mean there is no risk. In fact, the most concerning data point in the report is that less than one third of organizations are following most of the 12 adoption and scaling best practices identified as critical for value creation. Fewer than one in five track well defined KPIs for generative AI solutions.

This is where I see the real danger. The technology is moving quickly and adoption within companies is widespread, however, the management maturity is uneven. Data shows that compared to larger organizations, the smaller organizations that fail to establish road maps, define KPIs, embed solutions into business processes, and actively manage change will struggle to convert experimentation into sustained returns.

That gap can create volatility. While some companies will overestimate their progress, others will underinvest in scaling. In the next few years, this competitive divergence will widen between those that genuinely rewire and those that merely experiment.

Personal Experience: Knowledge/Capability Gap

When I zoom out and look at what’s happening, especially through the lens of my own work as a Solutions Engineer Lead, what I see isn’t a bubble waiting to burst. What I see is a growing gap between organizations that are serious about change and those that are just experimenting on the surface.

In my day to day work, I’ve noticed something interesting. The companies that actually see impact from AI are not the ones asking for the flashiest demo or the most advanced model. They are the ones willing to sit through uncomfortable conversations about process redesign, data governance, ownership, and KPIs. They ask questions like, “Who is accountable for this workflow?” or “How will we measure whether this actually improves outcomes?”

On the other hand, I’ve also seen teams excited to “add AI” to their stack without thinking through change management or how it fits into existing systems. The tool gets integrated, maybe a few people try it, but nothing fundamentally changes. Six months later, leadership wonders why the ROI isn’t obvious.

That’s why I don’t think the biggest risk right now is that AI disappears. The bigger risk is that some organizations never move beyond surface level adoption. Larger enterprises, at least according to the survey, are more likely to centralize governance, build dedicated AI teams, and define clear road maps. In my experience, that structure makes a huge difference because it forces alignment from the top and creates space for proper implementation.

Smaller companies or less mature teams might still adopt AI, but without that structural depth, the impact stays limited. Over time, that difference in execution can compound. The companies that treat AI as a strategic shift will quietly pull ahead, while others remain stuck in pilot mode.

Conclusion

There is hype at the edges of the AI ecosystem. Valuations may fluctuate. Some startups will fail. Some corporate AI initiatives will quietly dissolve when ROI disappoints. That is normal in any major technological transition.

But when I step back from the headlines and the valuation chatter, I can’t ignore the fact that something more substantial is happening underneath all of it. Companies are not just experimenting with shiny tools and hoping for magic. They are redesigning workflows, sometimes painfully, sometimes slowly, but deliberately. CEOs are stepping into governance conversations instead of leaving AI buried inside IT departments. Risk management frameworks are being built out, not because it’s trendy, but because real consequences have already surfaced.

At the same time, organizations are investing in reskilling programs, adjusting talent strategies, and embedding AI across multiple business functions rather than confining it to isolated pilots. In several business units, leaders are already reporting revenue increases and cost reductions tied to generative AI, even if those gains have not yet translated into dramatic enterprise wide EBIT shifts. That tension between localized value and broader financial impact is exactly what you would expect in the early stages of structural change.

And perhaps that is what makes this moment uncomfortable. We are in the in between phase where expectations are high, execution is uneven, and results are still consolidating. It is tempting to label that uncertainty as a bubble because uncertainty is easier to dismiss than to analyze.

For me, the more interesting question is not whether the AI bubble will collapse, but whether organizations have the leadership discipline, governance maturity, and operational courage to complete the rewiring they have started.

Because if they do, this will not be remembered as a bubble. It will be remembered as a foundational shift in how enterprises are structured.

Thanks for reading! I’m curious to know your own personal thoughts and experiences on this topic! Feel free to connect, send me an email (my inbox is always open) or let me know in the comments! Cheers!

Let's Connect!

How to Set Boundaries Professionally

Victoria Lo — Sun, 15 Mar 2026 23:00:00 GMT

Welcome back to another Articles by Victoria, the place where I randomly write things I’m curious about.

Lately, I have been thinking a lot about boundaries. The subtle ones that go unnoticed in everyday moments that determine whether you end your day feeling respected or slightly resentful.

If you have ever felt that tiny sting when someone speaks to you in a tone that crosses a line, or when you agree to something you did not actually have the capacity for, you would know... exactly what I mean.

Setting boundaries professionally sounds simple but in reality, it can feel uncomfortable, especially when you are leading, mentoring, or trying to maintain harmony in a team. Some have advised me to call them out directly, some have advised me to provide constructive feedback using the sandwich method, some told me to just let it go and "be flexible".

Because of that, I used to think good leadership meant being "flexible" all the time. However, now I know that flexibility without boundaries can quickly turn into burnout and feeling disrespected all the time. Once you start to constantly feel that in your workplace, it will subtly affect how you work and how you communicate to others.

In this article, let me share what that looked like for me and how I set my boundaries professionally.

A Personal Story

As a Solutions Engineer Lead, I naturally want to support my team. I want them to feel safe proposing ideas, asking questions, and even challenging me. But when I first entered the team 2 years ago, there was a period of time when I noticed something subtle within the team dynamics.

A junior team member would propose something to the team, and everyone would support their ambitions and ideas. Then when it's time to implement, the junior would ask the team members to do the tasks for them. Sometimes, the junior would even bluntly tell me to "do XYZ for me" or "I don't want to take up these tasks" or "ask ABC to do it". It felt directive and unprofessional.

At first, I brushed it off by simply ignoring their bluntness and attributing that to them just adjusting to the team since they are still young. Also, I was still new to the company, so there were more important things I needed to prioritize during onboarding. So I rationalized it as maybe they were stressed and maybe I was reading too much into it.

But over time, when other team members quietly shared with me in their one on ones that they felt uncomfortable too, I realised something important. When you tolerate small boundary violations, you are not just affecting yourself. You are setting the emotional climate for everyone.

Leadership is not only about vision and strategy. It is about modelling what is acceptable behaviour. Hearing my team members say that about that team member, that was my wake up call.

Why Boundaries Feel So Hard

I knew I had to do something about this but at the same time, I learned that I was in a tricky position due to many factors.

One of them being the fact that I was still a relatively new lead, which meant I was very conscious of how I seemed to the team. I did not want to come across as overly strict, sensitive or defensive (especially because I'm the only woman in the team and they're already evaluating whether I'm qualified for the position) So I wanted to be seen as supportive, fair, objective and collaborative. And... that made me hesitate.

There were also other factors that made it harder for me to address it immediately:

I was still building credibility in the role and did not want to seem sensitive
The person involved was younger and less experienced, and I did not want to crush their initiative and enthusiasm in contributing to ideas
I worry I would damage the team dynamics

When I internally went over these factors altogether, it becomes easy to delay the solution, and avoid the hard conversations. I convinced myself that maybe it will correct itself. Maybe it is just immaturity and they will get better themselves. Maybe someone else will address it.

But the longer I waited, the heavier it felt.

And I realized one thing, but it took me too long to articulate this: By staying silent, I was unintentionally approving the behaviour.

Silence can seem like consent, but in reality and in leadership, it is rarely neutral. When you let something slide repeatedly, it slowly becomes the standard, the expectations, the norm. What you tolerate, you normalise. And I had to admit I have been procrastinating this for way longer than I wished.

So I looked for answers and found a book

One book that helped me think about how to solve this is Boundaries by Henry Cloud and John Townsend.

While this book often discussed scenarios in personal relationship contexts, I think the principles can translate into professional life as well.

The core idea is simple yet powerful: You are responsible for your responsibilities. Other people are responsible for theirs.

A line from the book says "When you overfunction, someone else underfunctions."

That sentence hit me hard the first time I really understood it.

Every time I rationalized their behaviour instead of correcting it, I was absorbing the discomfort myself. Every time I stepped in to help with an initiative that someone else proposed, I was overfunctioning. I told and convince myself that I was being supportive, a helpful team member and lead. In reality, I was removing the opportunity for them to step up and grow.

My flexibility was not purely from generosity. Frankly, it was avoidance because it was easier for me to just handle it than to address the behaviour directly.

I realized what I was doing does not build me into the leader I wanted to be.

What Setting Professional Boundaries Looks Like

Most people think setting boundaries mean direct confrontation, and having that hard conversation. I agree to a certain extent but I prefer to frame it as "calm correction" instead.

Here is what I started doing.

1. Address It Early, Don't Approach Emotionally

The longer you wait, the heavier the conversation becomes. I learned to address tone or behaviour when it first appears, rather than letting it pile up. That way, they also exactly the behaviour I'm talking about, because it's still fresh.

Instead of saying:

“Hey, I think you are being rude.”

I would say:

“I noticed the way that was phrased can came across a bit directive to the team. Let’s keep our team culture a collaborative one. I'm sure you would want the same respect from your team members.”

It is specific and neutral. It focuses on the behaviour, not personality.

2. Separate Intent from Impact

I always assume all of my team members have the best intentions. Even if their words might come across as unprofessional, I assume they do not mean any harm.

So I would say:

“I know that may not have been your intention, but the way it was communicated felt dismissive.”

This keeps the conversation constructive rather than accusatory, and it helps when addressing this to them because they would not get defensive.

3. Re-anchor to Standards, nothing Personal

Instead of highlighting about how I felt from their behaviour, I anchor it to team culture. To keep it blameless and a more productive conversation.

“In our team, we speak to each other with mutual respect and kindness, regardless of seniority.”

Now it is no longer about me versus you. It is about shared standards, and aligning expectations with them.

4. Protect Your Capacity

Early in my career, I said yes to almost everything. If someone else hesitated to execute a task, I would pick it up so nothing stalled. If a message came across dismissively, I would mentally smooth it over and act like it didn’t bother me.

On paper, it looked like I was reliable. In reality, it was exhausting, and it kept the behaviour repeating. I was absorbing the responsibility and emotional tension that belonged to them.

I worried about sounding too assertive or sensitive. But I have to learn that letting others handle their own responsibilities while I support them is what leadership looks like.

Conclusion

Professional boundaries are not about confrontation, avoidance or control. They are about creating an environment where everyone knows how to operate at their best.

If you are currently hesitating to speak up about something that feels slightly off, consider this your gentle nudge. Addressing it early is always easier than repairing it later.

Let's Connect!

Claude Skills Explained

Victoria Lo — Sun, 08 Mar 2026 23:00:00 GMT

Welcome back to another Articles by Victoria, the place where I randomly write things I’m curious about. Lately, I’ve been very curious about Claude Skills.

This article and any AI-related articles to a new series called “AI, but make it make sense”. The aim of this series is to demystify anything AI, for non-techies and techies. Feel free to always reach out if there’s a specific topic you’d like me to cover or elaborate in this series. Thanks!

Series link: https://lo-victoria.com/series/ai

In this article, let’s unpack what Claude Skills actually are, why are they being so hyped, and its use cases to unlock workflows.

What Are Claude Skills

Anthropic recently introduced something called Skills, and at first glance to me, it seems to be a specialized context engineering capability for Claude.

Read more about context engineering in this article.

To put it simply, a Skill is basically a structured set of instructions that tells Claude how to do something. By creating a SKILL.md file in your codebase, AKA a Markdown file with instructions, you can add specific instructions on what Claude should do. For example, below is an explain-code skill:

---
name: explain-code
description: Explains code with visual diagrams and analogies. Use when explaining how code works, teaching about a codebase, or when the user asks "how does this work?"
---

When explaining code, always include:

1. **Start with an analogy**: Compare the code to something from everyday life
2. **Draw a diagram**: Use ASCII art to show the flow, structure, or relationships
3. **Walk through the code**: Explain step-by-step what happens
4. **Highlight a gotcha**: What's a common mistake or misconception?

Keep explanations conversational. For complex concepts, use multiple analogies.

A skill doesn’t just have to be a Markdown document. They can also be in the form of scripts. In a codebase, this can look like:

.claude/skills/
├── SKILL.md           # Main instructions (required)
├── template.md        # Template for Claude to fill in
├── examples/
│   └── sample.md      # Example output showing expected format
└── scripts/
    └── validate.sh    # Script Claude can execute

Note: It is good to let Claude automatically discover skills by including them in .claude/skills/ directories.

As you can see, when you read or hear about “Skills”, it is not as complicated as it seems. Basically, it’s organized context.

Image credit

Whenever you prompt, Claude can scan available skills at the beginning of a session, read a short description of each one, and then only load the full details when it actually needs them. So instead of bloating every conversation with massive instructions, it stays lightweight until the moment a skill becomes relevant.

What Makes Claude Skills so Good

What I personally love about this design is how simple it is. There’s no heavy protocol to implement and no giant infrastructure requirement. If you‘re looking to start building a prototype, you won’t need a 50-page specification document for Claude Code to build something.

If you’ve spent any time working with large language models, you already know that they respond incredibly well to well-written instructions. Claude Skills is exactly about leveraging that, pre-determined and specific repeatable actions you want the LLM to do.

That feels very aligned with how LLMs actually work.

Another subtle but powerful detail is token efficiency. Claude doesn’t load every skill fully into context. If you have read my article on context engineering, we learned that too much context can create hallucinations. Instead, Claude Skills reads short metadata upfront and only expands when necessary. This reduces over-context engineering, especially as workflows get more complex.

Types of Claude Skills

You can think of Skills in a few buckets.

1. Workflow Skills

Encode processes. How your team structures reports. How you clean data. How you prepare investor updates.

2. Tooling Skills

Bundle executable scripts. For example, generating a PowerPoint, validating a file size, merging PDFs.

Anthropic actually provides pre-built Skills for common document tasks, you can use these skills immediately in your workflows:

PowerPoint (pptx), create and edit slides, analyze content
Excel (xlsx), create and edit spreadsheets, analyze content
Word (docx), create and edit docs, analyze content
PDF (pdf), create formatted reports in PDF

These are available on claude.ai and via the API.

3. Domain Expertise Skills

This is where organizations get real value. Internal knowledge. Compliance frameworks. Technical standards. Sales playbooks.

More custom skills and instructions to setup is on: https://platform.claude.com/cookbook/skills-notebooks-01-skills-introduction

How to use Claude Skill

Skills run inside a code execution container because that’s the environment where Claude has filesystem access, and can read your Skill directory, and can execute scripts if needed.

So the typical flow looks something like this, where we are using the pre-build skill xlsx to create and edit spreadsheets:

# Use client.beta.messages.create() for Skills support
response = client.beta.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=4096,
    container={
        "skills": [
            # this is where we define the skill to use
            {"type": "anthropic", "skill_id": "xlsx", "version": "latest"}
        ]
    },
    # make sure we use code_execution tool
    tools=[{"type": "code_execution_20250825", "name": "code_execution"}],
    messages=[{"role": "user", "content": "Create an Excel file..."}],
    # Use betas parameter instead of extra_headers
    betas=["code-execution-2025-08-25", "files-api-2025-04-14", "skills-2025-10-02"]
)

What the code above does is the following:

You send a request using the beta messages API.
You specify the Skill you want to make available (i.e. xlsx) in the container parameter.
You include the code_execution tool, it is necessary to use Skills
You enable the relevant beta flags.

Then here’s what actually happens behind the scenes:

Claude receives your request with the Skill loaded into its environment.
If the Skill requires generating something like an Excel file, it uses the code execution tool to create it.
The response includes a file_id.
You then use the Files API to download that generated file.

Note: this is the current way to use Skills at the time of writing this article, February 2026. This may be subjected to change.

Claude Skills vs MCP

Now let us address the comparison everyone is making. Is Claude Skills the same as MCP?

The short answer is: No.

MCP is a protocol on how agents can work with third party apps. It’s structured, formal, and architecture-heavy. It defines how hosts, clients, tools, and resources interact. A more detailed article on what MCP is and its architecture can be found in this article, Understanding MCP and A2A.

Claude Skills, on the other than, is more lightweight and more of a structured form of context engineering. Instead of a protocol, you’re writing structured instructions and optionally bundling scripts.

Another difference is token efficiency. Some MCP implementations consume large chunks of context such as GitHub’s MCP. When this happens, it can eat up an enormous amount of context just by existing. Which means tens of thousands of tokens before we’ve even really started the actual task. And once that much space is already taken, there isn’t much room left in the context window for the model to think, reason, or produce something genuinely useful. Skills rely on what Anthropic calls as progressive disclosure, which keeps things lean.

Image credit

To be honest, I don’t think Skills and MCP are comparable. There is no “this one is better than the other”, because they operate at different layers. Skills live at the context and execution layer. They shape how Claude behaves by packaging instructions, workflows, and optional scripts inside the environment it’s already running in.

MCP lives at the integration layer. It’s about connecting models to external systems in a standardized, protocol-driven way. It’s infrastructure.

If you’re a builder who values speed and simplicity, Skills will probably feel more approachable. You can experiment by writing a well-structured SKILL.md, maybe add a script, drop it into your environment, and you’re off. The barrier to entry is low, and iteration is fast.

Where MCP has a real advantage is when you need standardized, cross-system integrations.

For example, if you’re exposing internal company tools, databases, or services to multiple models or applications in a consistent way, MCP gives you a formal interface. It’s better suited for enterprise-scale scenarios where governance, shared access, authentication, and structured tool definitions matter.

Now here’s a question for you: can you use both Skills and MCP together?

My answer would be: Yes of course, in fact, your workflows can be even more powerful this way.

Conclusion

What excites me about Claude Skills isn’t that they magically make Claude smarter. It’s that they give us a structured and lean way to package knowledge, context and executable actions for the LLM.

Theyprovide consistent output and intentional system design, which is beneficial when working in teams. Because instead of repeating instructions endlessly, we build reusable capabilities.

References

Let's Connect!

5 Types of “Difficult” People I Learned Were Just Different

Victoria Lo — Sun, 01 Mar 2026 23:00:00 GMT

Welcome back to another Articles by Victoria, the place where I randomly write things I’m curious about.

This week, I found myself thinking about a phrase we use way too casually at work.

“Difficult people.”

Often, I hear people labelling others easily. Like if someone asks too many questions… Difficult. Or if someone pushes back hard in meetings… Difficult. Or maybe someone who refuses to align with the group… Difficult.

I used to mentally label people as well who I find “difficult”. In my 6 years as a solutions engineer, it's safe to say I've dealt with a lot of types of people. That’s when I realised most people we call difficult are not actually difficult. They are just different.

They are just different from usual people you talk to so you find them "difficult". We are all biased and we like to stick to the familiar. We like to only talk with people who we are comfortable with. And because humans are wired to prefer familiarity, we quietly turn difference into friction.

This article is not about how to deal with difficult people.

It is the result of years of quiet observation. Years of conversations, meetings, calls, demos, escalations, follow ups, and the kind of interactions that stay in your head long after the calendar invite ends. As a solutions engineer, I do not just work with technology. I work with people.

And over time, I started noticing patterns. Like recurring archetypes of people who think differently, communicate differently, react differently, and often get labeled as difficult simply because they do not fit the type of people we are most comfortable talking to.

And if you have followed me for a while, you know I love documenting everything. So I started documenting these archetypes, reflecting on my own reactions to them, and slowly learning how to work with each type without burning out or taking things personally. This article is a reflection of those observations and the ways I learned to deal with different kinds of people.

Preface: The biases we have to admit

I would like to preface this article with the fact that we are biased creatures and that my perspectives, experiences or observations can be subjective to a certain extent. As humans, we like to believe we are open minded. I thought I was pretty open-minded until writing this article. I thought as someone who lived in many different countries growing up, speaking different languages, and adapting to different cultures, I would value more diversity of perspectives.

But if I’m being honest with myself, I still most at ease with people who think similarly to me. Why do I enjoy books like “Atomic Habits” or “Building a 2nd brain”? Simply because the authors wrote and explain in systems which is something I’m most comfortable with.

This bias is subconscious and it’s more present in our daily communication with others than you might think. We like the familiar because it is efficient. It takes less energy to communicate with people who operate on the same wavelength. There is less explaining, less emotional regulation required.

But my job as a solutions engineer does not allow me to live in that comfort bubble.

I do not get to choose who I speak to. I speak to founders, engineers, security teams, procurement, product managers, compliance officers, etc. And over the years, patterns started to emerge. Along with these patterns, I myself recognize the biases I hold.

It made me shift my perspectives. Instead of asking why someone was being so hard to deal with, I started asking why this particular interaction was triggering discomfort in me. Was it challenging my sense of competence? Was it slowing me down? Was it forcing me out of my communication comfort zone?

Archetype 1: Highly Anxious Questioners

These are the type who ask a lot of questions. Then ask even more, before circling back to questions you already answered. They are usually very detail-oriented and carry a lot of responsibilities in their job. If something goes wrong, it is on them.

That’s why I slowly realized their questions are a way to reduce their uncertainties. Instead of simply responding to their questions again and again, almost reaching to a point of frustration, I proactively reassured their underlying concerns and covered edges cases in advance.

They now feel more confident that I can look out for them, and our collaboration is not their sole responsibility to uphold. They were not difficult, but risk sensitive.

Archetype 2: Strong Opinion Holders

This is quite a common type. A person who is vocal, appears confident, know what they believe in, and expect others to agree. To be frank, I still struggle with this type. Because their certainty felt intimidating and they can be sometimes dismissive to others’ opinions.

However, I slowly discovered that these strong opinions tend to come from deep experiences, mostly negative. They have seen implementation fails, production collapsing, performance bottlenecks and fragile architectures. Trying to debate or overpower them is futile because they know they’re right.

What I find works is showing curiosity for their perspectives. Ask them why they believed a certain way would work, why they had to insist on a particular flow. They end up sharing their reasoning behind their opinions, and when people articulate their own experiences, they are able to soften because they felt heard. They would shift from being defensive to being reflective.

Sure, they won’t change their minds most of the time but for the rest of the people in the room, their “strong opinions” become a story with context. Now that we learned about their story, the constraints they faced at the time, their challenges, we can discuss solutions. We can evaluate what went wrong in the past and explore better trade-offs and options.

They were not difficult, they just had an unshared story.

Archetype 3: Silent Skeptics

Silence is the most powerful weapon because it hides everything from you. Their doubts, confusion or any areas of resistance, these types are usually existing quietly and when the time comes for decisions to be made, the objections appear out of nowhere.

I assume some of us might made this mistake before: treating silence as consent.

But this is a dangerous assumption to make. Silence does not necessarily mean agreement. It can signal discomfort, distrust, or just that this person is the type to process internally before speaking.

So I learned to create space for these archetypes. If they have no questions in the call, that doesn’t mean they have no questions or doubts later. Ask follow up questions or suggest a call sometime in the future. Give them space to process and come back later anytime. Keep the conversations transparent and open so they will feel space to raise concerns before it’s too late.

They were not difficult, they just need the space and time.

Archetype 4: Agreement Seekers

There are moments in my role where I have to be the devil’s advocate. Because there are certain constraints cannot be negotiated away. Security boundaries still matter, architectural tradeoffs still exist even if they are inconvenient. Some decisions, once made, need to be protected for the sake of long term stability.

On the surface, agreement seekers are some of the easiest people to work with. They are polite, collaborative, and genuinely want everyone to feel heard. They value alignment and harmony.

And when they are not in positions of power, this tendency is usually manageable.

The challenge is when an agreement seeker holds authority but struggles to remain objective. In an effort to keep peace, they may loosen constraints that should stay firm. They may lose sight of priorities or decisions that were previously discussed and agreed upon, and end up accommodating to whoever speaks most confidently or holds the most influence in the room.

What makes this difficult is that it rarely feels intentional. They are just trying to reduce tension. But in doing so, clarity is sacrificed for comfort.

In these situations, I learned to thread carefully because if I came across as too firm, they would instinctively move away from my side to rebalance the room. What worked better for me was grounding my pushback in shared goals and framing constraints as protection rather than obstruction. Usually, that would help them facilitate the discussion to reach an agreement.

They were not difficult, they were harmony-driven.

Archetype 5: Lost in Conversation Narrators

I’m honestly still lost when it comes to this archetype. This type frustrates me the most because it’s absolutely baffling. They are very friendly and like to talk a lot. Yet somehow the more they talk and explain, the more confused I get.

They describe their problem, but the description keeps digressing. They use technical terms, but not quite correctly and it made me not understand what they’re trying to say. When I ask a question to clarify, their answers are completely irrelevant that it feels like we are having two completely different conversations in parallel.

This happens most often with non technical stakeholders, but not exclusively. Their intent is not to confuse. In fact, many of them are trying very hard to explain and it would frustrate them too if I don’t understand what they’re trying to convey.

What makes this especially difficult is that I cannot easily tell where the gap is. Are we missing shared vocabulary? Are we misaligned on context? Are they still figuring out the problem themselves?

This archetype forces me to confront my own limits. My instinct is to move towards structure, precision, and abstraction. But not everyone thinks that way. Some people reason through narrative and they have to say things aloud as a way to think through what they want to actually say.

In many instances, I have found that letting them talk it out is actually the solution. I first had to let go of the assumption that they had come into the meeting with clarity. Whatever words they are saying, no matter how disorganized and scattered, I would capture all of it then distill them by myself later. Rather than a requirements gathering, I treat their narratives as a form of discovery process, for themselves and for me.

They were not difficult, they were just still forming thoughts.

The Life-Changing Hack

After discovering the patterns of these 5 types, I no longer treat every “difficult” person as a problem to fix. I don’t end up micro-managing my relationships and try to artificially repair the misalignment, the misunderstandings, the non-verbal barriers.

The biggest life-changing hack is simply about emotional regulation.

Can you stay grounded when someone challenges you?
Can you listen without being defensive?
Can you separate tone from intent?

Once this becomes ingrained and automatic within me, the rest becomes easier. The small moments of confusion and frustrations may not entirely disappear, but I can immediately reset myself to focus on solving what the clients’ needs are, instead of trying to decode our communication barriers or misalignments.

Conclusion

It is not within my control to change someone’s behaviour, but it is within my control to change myself to better work with them. Understanding that they are just different helps me a lot. I also realized how I might also be somebody else’s “difficult” person and that’s why being aware of your own pitfalls is just as important when it comes to communicating with different people.

Thanks for reading! I’m curious to know your own personal thoughts and experiences on this topic! Feel free to connect or let me know in the comments! Cheers!

Let's Connect!

How to Grow Your Blog in 2026

Victoria Lo — Sun, 22 Feb 2026 23:00:21 GMT

Welcome back to Articles by Victoria! Every year around this time, I get similar messages from readers asking how to grow a blog or whether blogging is still worth it in 2026. Search engines feel unpredictable while social media feels exhausting, and everyone wonders if they’ve already missed the window.

What’s interesting is that most of these questions aren’t really about growth. They’re about relevance. About whether writing still matters when AI can produce infinite content on demand. About how to stand out without shouting louder than everyone else.

I’ve touched on different parts of this across previous articles in my Blogging Tips series. In How to be a Writer Without AI, but With Your Own Voice, I wrote about how easy it is to lose your voice to AI if you are aware of it. In 5 Ways to Beat AI-driven Search Engines, I explored why optimization for search engines in the landscape of AI Overviews is not an option, but a must. And in Your Name Is Already a Search Term, I wrote about why your personal brand matters.

This article is just me putting all of that together (because I’m just an over-explainer like that).

All in all, growing a blog in 2026 looks very different from how it used to. And in some ways, it looks a lot simpler.

1. Don’t start without email newsletters

There’s a famous saying: If it ain’t broke, don’t fix it.

Email newsletters have been around for a long time and are still one of the few places on the internet where someone explicitly gives you permission to send them emails. That opt in matters more than people realize.

When someone subscribes to a newsletter, there’s an unspoken agreement happening. You commit to showing up with something useful or thoughtful. They commit to opening, reading, maybe even replying. That kind of permission-based relationship is rare in a landscape where most content is pushed at people whether they want it or not.

While every social platform is busy wrestling with algorithm changes, shifting content policies, and increasingly AI curated feeds, email is still doing the same boring, reliable thing it has always done. It reaches people who explicitly asked to hear from you.

Your blog becomes the home base. The place where your ideas live over time. The newsletter is how you show up consistently without fighting an algorithm every week.

The data backs this up too. According to the State of Newsletter report by beehiiv, publishers sent over 28 billion emails last year and reached more than 255 million unique readers. Open rates are still hovering above 41 percent, which is honestly wild given how crowded inboxes have become. Paid subscriptions alone jumped from 8 million dollars in 2024 to 19 million in 2025, largely driven by niche creators who know exactly who they’re writing for.

This is not sponsored by the way, but I’m currently using beehiiv for newsletters and its free tier alone suits my needs very well. The analytics are also comprehensive yet simple. That’s why in 2026, I believe having a direct channel to your readers isn’t a “nice to have” feature, it’s a must-have and a long-term way to grow your blog.

2. Let Your Readers Know You

One thing I’ve noticed over the years is that the replies I receive are rarely about how technically correct an article is. They’re about recognition and relatability.

“This is a really interesting article and something I've often thought about.”
“This felt familiar.”
“I could hear your voice while reading this.”

That doesn’t happen by accident, it’s intentional.

I simply write the way I think. Quite direct, occasionally sarcastic. Sometimes I admit I’m unsure or I do not have a lot of experience about the topic. I share about things I second-guessed, decisions I changed my mind about, and moments where I didn’t have a clean answer yet.

Over time, the blog stops feeling like a publication and starts feeling like a diary that happens to be readable and reply-able. I like to hear your, my readers’, thoughts and perspectives as well. And more often than not, they are willing to share their experiences with me. It’s almost like we’re just friends sharing our learnings with each other.

And that’s what people come back for.

You don’t need to manufacture relatability. You just need to write as authentically as you can. If someone reads a few posts and feels like they know you a little better, you’re doing something right.

3. Get a Domain

This sounds basic, but it’s surprisingly important. Many readers told me they want to try out blogging through Medium or Dev.to first. That’s totally fine but I always recommend that they should gradually move to their own domain.

A domain gives your writing a home that isn’t dependent on any single platform. Because honestly, feeds change, platforms or tools disappear and algorithms reset. Only your domain stays and you have full control on how it lives, how it’s presented, and where it goes next.

This is something I also realized lately, but it also subtly shifts how your work is perceived. Picture visiting an article that’s from “medium.com/johndoe” vs “johndoe.com”. There’s a difference in how your audience will remember your content when it’s something you intentionally build. A domain can signal that intention and build your credibility fast.

Your name, or something close to it, becomes searchable. I wrote more about this in Your Name Is Already a Search Term, but the short version is this:

Make it easy for people to find you again once they’ve decided they want to.

4. Don’t separate “technical” from “personal”

One of the biggest misconceptions I still see is the idea that personal context somehow weakens technical writing. In reality, it’s the opposite.

AI can explain how something works. It can summarize documentation. It can list best practices faster than any human ever could. What it can’t do convincingly is explain why something felt confusing, or what tradeoff only became obvious after shipping, or how a decision played out over time.

That’s where personal context becomes essential.

When I write about leadership, systems, or data governance, the technical insight only lands because it’s wrapped in experience. In things I’ve actually tried. In mistakes I’ve made. In assumptions that didn’t hold.

People aren’t reading blogs in 2026 to collect facts because they can just ask LLMs for those. They’re reading to borrow wisdom and perspectives.

And wisdom doesn’t exist without a human behind it.

5. Follow your curiosity and let the rest catch up

For the longest time, I see my blog as an extension of my curiosity. I write about technical tools and documentation, hackathons, productivity, focus, and sometimes book reviews when I feel like it. That’s why you can check out the amount of series I have on this blog. It’s unnecessarily overcrowded, haha.

Sometimes I look at my blog and wonder who would read it when it looks like there was no plan behind it. No niche optimization or anything. I was just writing what I enjoyed writing about.

And yes, there were moments where I wondered if this was a waste of time. Should I have written posts more strategically? For example, my book review articles don’t rank that well (and were not designed to). They’re just posts for me to pen down my key takeaways and reflections from reading the book. SEO-wise, they don’t even exist. And yet, a few people still discovered them, including the author himself.

My review of Matthew’s book “The Introvert’s Edge to Networking”, which I still re-read occasionally.

I still write book reviews till today, and you can check them out in my Books & Reflections series.

Then one day, an email came in. A publishing company asked if I’d be open to writing a sponsored book review. They had already read my previous reviews and knew exactly what they were getting. What surprised me wasn’t the opportunity itself. It was how little convincing was required, because my writing had already done the work.

That was the moment it clicked for me. When you write what you genuinely enjoy, you’re not just publishing content. You’re leaving behind a trail of how you think, what you value, what you notice when no one is telling you what to write.

In 2026, that trail matters more than any optimization strategies.

Final Verdict

Growing a blog in 2026 isn’t about being louder or faster or more optimized.

It’s about being clearer with who you are and how you want to convey that through writing. Here are some questions I encourage you to ponder about when starting out your journey:

What am I truly excited to share with people?
If I can give a TED talk right now, what would the topic(s) be? What would be the best way to convey that to people?
What do I want to be known for? What do I want people to say about me when I’m not in the room?
What is stopping me from starting a blog, and how do I overcome it?

Be clear about what you care about. Be clear about the kind of thinking you want to put into the world even when no one is reading yet.

If your writing sounds like you, reaches people directly, and gives them something they can’t get from a generated summary, growth becomes a side and long-lasting effect. And honestly for me, that’s the only kind of growth that still feels worth investing.

Let's Connect!

Why I Don't AI Generate My Blog Images

Victoria Lo — Sun, 15 Feb 2026 23:00:48 GMT

Welcome back to another Articles by Victoria, the place where I randomly write things I’m curious about. Over the weekend, one of my readers emailed me a question:

“Victoria, do you use AI to generate your cover images? If yes, how do you keep the style so consistent?”

This question was fascinating and it got me wondering if my cover images seem AI-generated. So I took a quick look at my Recent Posts. What do you think?

The short answer is No, and here’s why…

I guess from the title of the post, you would know that the short answer is no, none of my cover images are generated. In fact, this is me every week using Photoshop to create them.

This is probably a TMI but I literally have a folder called Lines where I draw every line you see for the grid background in some posts’ cover images like this one above. Reused it many times so I guess it was worth the effort haha.

By the time I publish this article, this would be my 242nd post, which means it is my 242nd time creating a cover image like this, which means 242 intentional moments where I chose colour, placement, style, and layout.

I have a routine now, a rhythm. And I think it’s part of why the covers feel coherent. My cover image creation process has not changed since I first hit ‘publish’ in 2020. It was such a simple question from a reader, but it opened up something deeper about why I do what I do here.

It’s the ritual and identity

When I open up Photoshop to make a cover, I’m not thinking about optimisation. I’m thinking about how the words I choose to write this week feel to me. I am thinking about the article’s tone, my mood, and what images in my head I was carrying around while writing the piece.

In full disclosure, I don’t draw everything from scratch. I often use freepik’s illustration library (not the AI-generated ones) and undraw for the illustrations.

The process after that is just another day of me moving text around, looking at layout, colors, style and the overall vibe of the cover image. I do this while asking myself one simple question over and over again: “Does this image actually capture what the article is trying to say?”

And just like the rest of the blog, I’ve kept things consistent. Same font, same general style, for 6 years now. Font is Agency FB if you’re curious by the way. I never really questioned it once since I clicked the ‘publish’ button. It was simply the way it is. A font I chose 6 years ago without much thought becomes the font I’m choosing every week when I publish a post. Needless to say, it has becomes a part of my blog’s identity.

The more serious but important reason

I know people talk about AI energy consumption and environmental impact a lot. My research into this suggests that generating AI images does consume a varying amounts of energy depending on the model, hardware, and infrastructure behind it. Some studies such as this one by Ratiftech indicate generating an AI image can require a measurable amount of electricity, roughly comparable to charging a smartphone or more

Image credit

Sure, you can argue that there isn’t a definitive calculation that equates generating 1 AI image for a blog cover image to charging a smartphone, but the point remains: these systems use real energy in data centres around the world. And every time we ask a machine to generate something, there’s energy being consumed for something I could have done myself.

At least for me, I try to be thoughtful about the small ways I can help the environment. Like how I don’t use toner pads in my skincare routine because of environmental reasons. That choice, like my decision to avoid AI image generation, isn’t about “making a difference”. It’s about intention. It’s about doing small things in the real world that align with the values I believe in.

It is art, I guess

I know this might sound a little dramatic for something as simple as a blog cover image. Realistically, most people probably don’t stop to look at my cover images (unless you’re the reader who emailed me haha). They scroll past, read the headline, maybe skim the article, and move on. There was a stat from Wix that says people typically spend about around 37-52 seconds skimming a blog post. This most likely means the cover image is just a 0.1-second skim, which is honestly fine.

But to me, this is still a form of the way I want to express my blog’s identity.

When I look back at 6 years of cover images lined up together, I don’t just see visuals. I see time. I see ideas that made it out of the draft log. I see weeks where I was tired, weeks where I was excited, weeks where I was clearly overthinking every single line of text. It’s a very unglamorous kind of art, created between meetings and life and everything else, but it’s mine (and some freepik’s or undraw’s, thank you).

Actually, I laughed at myself calling these art. Yet, I’m also quietly proud of it because it represents 6 years of creating something consistently, even when no one was asking for it, even when it would have been easier to automate it with AI.

And maybe that’s where consistency really comes from. From treating even the small, forgettable parts of your work with care. When you do that long enough, patterns emerge.

It had become part of the system

We all read those self-help books on developing better habits to be consistent with something. The funny thing I realized about consistency is that it doesn’t come from over planning with a habit tracker. It’s not like I set goals on when I’m creating these cover images and how many is my target per week, etc.

James Clear talks about this in Atomic Habits. How real change doesn’t come from goals, but from systems. His famous line from the book is: You don’t rise to the level of your motivation, you fall to the level of your habits.

So creating these cover images simply become part of the system for me. I didn’t wake up one day in 2020 deciding that this would be my aesthetic and style I am going to stick to for next 6 years. I just opened Photoshop every week, used the same font, asked the same question and published another article. Over time, those tiny decisions stacked up. Not because I was disciplined, but because it became part of who I was: Someone who writes. Someone who finishes (mostly). Someone who cares about the details even when they’re only a 0.1-second skim to most.

And maybe that’s the most relatable part of all this. Consistency isn’t about doing something perfectly. It’s about making it familiar enough that you don’t have to think too hard to do it again next week.

Conclusion

So after all that yapping from me, the answer to my reader’s question is: no, I don’t use AI to generate my blog images. And if the next question is “Why?”, then TLDR:

It’s about connection, a small environmental principle and the result of repeated habits.

If someone thought my cover images were made by a machine, I’ll take that as a compliment. It means my personal touch has matured into something visually consistent, yay. And for me, that is far more meaningful than the fastest, most efficient way to do it.

Let's Connect!

References

How Cognitive Functions Changed the Way I Understand People

Victoria Lo — Sun, 08 Feb 2026 23:00:08 GMT

Warning: This is a very long read. I was initially thinking to break it up into a series but I don’t think there’s any point to a series where it’s just me turning one long thought into multiple long thoughts. If you’re here for the usual quick takeaways, this might not be it. If you’re curious about how cognitive functions reshaped the way I understand people, settle in and get some good tea/water.

I was 14 when my school made us take an MBTI (Myers Brigg Type Indicator) test. After that, we had to group ourselves by our results and sit with our groups. I was the only INTJ in the class.

I didn’t feel sad or awkward. Intrigued is a better word. Something about my 4-letter combination made me curious. I went home and immediately started looking it up. At first I thought it was just another personality quiz, like the ones on Facebook, but the more I read up on it, the more I realized there was more to it than what we typically know.

Hello everyone! Welcome to another Articles by Victoria, the place where I randomly write things I’m curious about. In this article, well… let’s just say it’s gonna be long and personal. Overall, I want to walk you through how I use cognitive functions as a framework, not to label people or put them in boxes, but to genuinely understand why they operate the way they do. And maybe, by the end of this article, you'll see why this shift in perspective changed the way I interact with everyone around me.

Introduction to Cognitive Functions

Most people know MBTI as a party trick. Feeling or Thinking, Introverted or Extroverted. They might think it’s basically the same as asking if you’re a Cancer or an Aquarius. Fun for parties, nothing more. When someone asks me:

“Do you believe in MBTI?”

I see the question itself is already wrongly worded because it already assumes MBTI is something that you “believe” in. Like a religion or astrology or some cosmic identity quiz that promises to tell you your fate.

I never saw it that way.

So my answer to such questions is: I don’t believe in MBTI.

Because I use it as a system instead. And to me, those two things are completely different.

Belief is passive. You accept something and let it define you. But using it as a system is active. You take what is useful, you discard what is not, and you let it sharpen how you observe the world. That is how I treat MBTI, especially in terms of what it represents: cognitive functions.

Not as truth, not as science, but as a lens. Most of my friends know that MBTI to me is a way to see patterns in how people think, how they respond, and how they move through their lives.

So the real question is not whether I believe in MBTI. The real question is whether understanding cognitive functions helps me understand people better.

Because unlike the party trick version, to me the four letters are shorthand for something deeper: cognitive functions AKA the way people actually think and process information. How they decide, how they react, how they navigate the world.

Why Believing in MBTI is just BS

Before moving on, I should explain another reason why I don’t “believe” in MBTI. Astrology boxes people based on actual facts like their birth dates. People born in July 12th can’t deny they are Cancer. People born in January 21st can’t deny they are Aquarius. However, the same doesn’t apply to MBTI.

A typical MBTI test asks you to choose traits based on how you think you behave, which is where things get messy. People often type themselves based on who they want to be, or who they think they should be, or whatever mood they were in when they took the test. They rarely observe themselves objectively over a long period of time to figure out what are their natural tendencies.

An extrovert might say they are an introvert because they enjoy quiet weekends. A thinker might choose “feeling” because they see themselves as empathetic. It becomes more about confirming your identity and biases rather than actually learning about yourself. The self-reported nature of MBTI is one of the major reasons why it is not accepted as “science” because the results are highly inaccurate.

Example: A YouTuber got different results every time she took the test because she’s not very sure of her own tendencies and chooses a different answer each time.

That is why when someone tells me their type, I don’t immediately take it as truth. I simply can’t. Not because I don’t trust them, but because MBTI is not something I “believe” in. It is something I observe.

Before going further, I want to be clear about where this framework falls short.

Limitations and Considerations

MBTI is self-reported and can vary depending on mood, context, or life stage.
Cognitive functions describe tendencies, not certainties. People may act differently under stress, in unfamiliar situations, or as they grow.
MBTI should not be used to judge, label, or limit someone’s potential.
These frameworks are tools for reflection, not scientific fact.

How Cognitive Functions Are Useful

The letters like E vs I are simply shortcuts, and sometimes I use it to superficially explain some concepts to friends who don’t know about cognitive functions (because trust me, the conversation won’t end if I go too deep). It’s just easier to grasp for daily conversations. Cognitive functions are the real tendencies I’ve noticed over time, and they show themselves over time through behaviour, not through an online quiz.

So when I try to understand someone, I focus on how they think, how they solve problems, how they express themselves, how they react in emotional moments. I don’t rely on what they tell me they are. I rely on what I see (which to a certain extent can be inaccurate as well since people only show what they want you to see but at least, I know the habits of thinking of their public persona).

And this is where cognitive functions start becoming useful. They turn vague self-labels into something you can actually observe and understand. Cognitive functions are not binary. They are a spectrum. Everyone has a bit of everything. What matters is how often someone uses one cognitive function over another, as this reveals how they process information and make decisions.

Most people treat MBTI like a party trick, but cognitive functions are a tool. They help me recognise patterns in how people think and behave, and once you start noticing those, you begin seeing things you never paid attention to before.

And this is where I started to become obsessed about cognitive functions. Not in a strange “let me observe everyone I know” way, although I definitely had a phase like that. I became obsessed because these tendencies I’ve observed finally made sense of people in a way nothing else ever had. And once I notice that, life becomes a lot less confusing.

How I Started Noticing Cognitive Functions in Real Life

After I learned that cognitive functions were the true hidden value behind MBTI, something strange happened. It was like my brain suddenly unlocked a new filter. I started noticing little details in people that I never paid attention to before. The way someone speaks, pauses, reacts, hesitates, gets excited, or gets defensive. All these tiny behaviours became clues.

At first, I was not even thinking in terms of “Fe” or “Ti” or whatever cognitive function names the internet throws around. I was simply observing how people navigate their environment. Only later did I realize:

“Oh, these behaviours actually have names.”

For example, I noticed some people always paid attention to the emotional atmosphere in a group. Even before they said anything, they would subtly check the mood of the room. They can easily sense the feelings of others and adjust their tone accordingly. If someone looked uncomfortable, they softened their words. I did not know what to call it at the time, but later I learned this pattern is associated with something called Fe (Extraverted Feeling) - to describe ones who naturally tune into group emotions.

Then there were people who lean the opposite. Instead of scanning the room, they looked inward first. They cared about what felt right to them. They made decisions based on their internal compass. If something did not sit well with them, they would quietly withdraw or rethink it. They were not concerned about the group vibe as much as being true to themselves. This, I learned later, matched the pattern called Fi (Introverted Feeling) - to describe ones whose intrinsic values must be aligned before locking in on a decision.

And then I started noticing thinking functions too. Some people needed time to organise their thoughts internally before they spoke. You could almost see their brain quietly sorting things out in the background. They talked in a thoughtful, analytical way, carefully choosing words to match their exact meaning, breaking down complex ideas into their core components. They cared a lot about precision. I did not know the name yet, but now I know that was Ti (Introverted Thinking).

Meanwhile, other people heard a problem and immediately jumped into problem-solving/troubleshooting mode. “What’s the problem here?”, “Why this problem exists and how do we fix it?” They move quickly to solve issues and come up with solutions: “Ok, here’s the plan” or “What’s next to implement” or “Let us conclude what we’ve discussed”. That direct, outcome focused, action-oriented style was something called Te (Extraverted Thinking).

I did not learn these names first. I observed the behaviours first. The names came later, and honestly, they were just labels for cognitive functions I already understood and observed in my day to day environment.

What made this whole thing addictive was how consistent people were once you started paying attention. Like they had a signature. A mental default mode. The same way your handwriting always looks like your handwriting, people’s thinking patterns also have their own style.

Quick Clarification

A lot of resources online talk about "mental models" which are frameworks for understanding how things work, like mental models of leadership, decision-making, or problem-solving. But what I was noticing wasn't about what people understood; it was about how their minds naturally operated. These are cognitive functions AKA the underlying patterns that shape how someone processes information, makes decisions, and interacts with the world, regardless of the topic. So just to be clear, mental models are not the same as cognitive functions.

How I Changed After Learning About Cognitive Functions

As an INTJ, I naturally see people as systems.

That sentence alone probably explains why I often come across as cold, detached, or overly goal oriented to a lot of people. I tend to break interactions down into patterns, inputs, outputs, constraints, and outcomes. When something feels misaligned, my first instinct is to analyze it. Where did it break? What assumption failed? What variable changed? Where exactly did it start?

A lot of the times, people would leave silently because they felt I was cold and distant. The one who stayed would communicate that they see my strengths as a loyal friend, a reliable problem solver and a quiet presence for them. At the same time, they acknowlege that from the outside, I can look like I only care about results.

What most people do not see is how much thinking happens behind the scenes. The hours spent replaying conversations. The effort I put into understanding motivations, incentives, and communication styles so future interactions go more smoothly. I am not disengaged from the relationship. I am deeply engaged, just in a way that is largely invisible.

Looking back, I think part of this instinct was shaped much earlier.

I moved between several different schools growing up. Each time, I would make friends, build routines, find my place, and then 2-4 years later, leave. The pattern repeated often enough that I started internalising a quiet rule. People come into your life for a season. They are companions, not constants.

That realisation subtly reshaped how I related to others. I stopped anchoring my sense of stability in permanence. Instead, I became more observant. If relationships were temporary, then understanding people became more important than holding onto them. I began paying attention to how different people thought, reacted, and processed information.

By high school, this curiosity had evolved into something more structured. I started paying attention and observing cognitive functions early in high school. It became an accidental training ground for this.

There was the classmate who always refer to past data before deciding anything. That slow, steady, “let me look at what was done before” mindset eventually I learned is called Si (Introverted Sensing).

And then there was the friend who came up with 10 ideas rapidly, bouncing from one possibility to another, easily connecting the dots between seemingly unrelated ideas. Later I learned, that was a typical Ne (Extraverted Intuition) at work.

And of course, there were classmates who easily predicted questions for the final exams nobody else saw. While everyone was focusing on the present and studying the chapters for tomorrow’s quiz, this person was already mentally living in next month and jotting down notes on topics for the finals. That turned out to be Ni (Introverted Intuition).

Once again, I emphasize: It was never about typing people. It was about understanding how their minds moved. Once you see their tendencies, you start understanding why some people react fast while others stay quiet. Why some people get overwhelmed by too many options and others get excited. Why some people argue logically while others argue emotionally. Nothing becomes random anymore.

Because as someone with INTJ cognitive functions, I used to see things in black and white. I couldn't understand why people weren't as result-oriented as I was, even though we grew up with similar cultures and values. Why were people so strange? Why they need to get me to agree on their side first before solving the problem right away themselves? Why when I told someone the objective truth, they were overly defensive at that moment and only agree I was right after some time passed? Why do they expect me to always be on their side and validate them even when I see this pattern is unhealthy for them? Why do small talks exists? I couldn't fathom why so many people operated so differently from me.

This used to be me: impatient, confused, sometimes frustrated by what seemed like inefficiency or emotional detours. I treated emotions as an optional feature, because I met so many people who were distracted by them. But once I started learning cognitive functions, the most surprising thing is that I become more patient. I stop trying to make others understand my point of view because I can see the mental processes behind them. I understand why this person is the way they are rather than judging their output. Because if there is one biggest takeaway from studying cognitive functions is that:

Don’t judge others too quickly. Everyone is doing the best they can in their own way.

That is when cognitive functions stop feeling like a psychology theory and start feeling like a language. A way to understand people gently. Because suddenly, even the smallest behaviours tell a story.

Something to address

I can already imagine the comments:

But Vic, u r still labelling people based on cognitive functions, isn't that the same thing? U said it’s "not to label people or put them in boxes" so this is contradicting.

You’re right to question that, and I think the distinction matters before we proceed. I don’t use cognitive functions to label people in the sense of fixing them into a type or expecting them to behave a certain way. I use them as a descriptive framework, not a predictive one. It helps me understand how someone might be processing a situation, not who they are or how they will act.

Labeling, to me, is when a framework is used to reduce someone to a category or to justify assumptions. What I’m describing is closer to observation over time, with room for context, growth, and contradiction. People can share similar cognitive tendencies and still act very differently depending on environment, stress, or values.

So yes, there is categorisation involved, but it’s loose, tentative, and always secondary to the actual person in front of me. The moment a framework stops helping me understand someone and starts limiting how I see them, I drop it. I’m not predicting outcomes, I’m adjusting how I communicate.

Understanding Function Stacks: Because People Aren't One-Dimensional

What was challenging for me when I first study cognitive functions is actually learning to identify them as a stack. In real life, people don't operate on just one function at a time. They have a stack AKA a hierarchy of cognitive functions they lean on in order: Dominant, Secondary, Tertiary, and Inferior.

The Dominant is their go-to function. It’s what they do best and what comes most automatically. The Secondary supports the dominant and helps balance it out, often you will see it being used together with the Dom. The Tertiary usually shows up in closer friend circles and family, when they are relaxed. The Inferior is the weakest or least conscious part of their stack and often appears under stress or when they are really trying to grow.

For example, someone's dominant function might be Fe (Extraverted Feeling), but you'd also see their secondary function, like Ni (Introverted Intuition), show up depending on the context. That's why spotting cognitive functions wasn't as straightforward as I initially thought. People exist on a spectrum and the how they use their stacks according to different situations makes them unique.

This is where long-term observation became crucial. You can't just watch someone for five minutes and confidently identify their cognitive functions. You have to see them across different situations like when they are stressed, relaxed, problem-solving, socializing. Over time, you start noticing which functions they lean on most often and naturally, which ones show up under pressure, and which ones seem like an afterthought.

Take an INTJ for example. Their function stack is: Ni-Te-Fi-Se. Their dominant Introverted Intuition (Ni) drives them toward long-term vision and pattern recognition, and their secondary Extraverted Thinking (Te) pushes them to execute efficiently, ask practical questions and focus on how to solve the problem or turn vision into reality. Extraverted Thinking also means they are external-logic driven. If the whole world including experts say horses are blue, then they would accept that as the objective truth, even if their hunch say otherwise. What this means is you would see someone who thinks ahead, easliy recognise patterns from given information, relies on data for decisions, and works on actionable plans consistently without much supervision.

And their tertiary function Introverted Feeling (Fi) lets them feel inwardly and care about others, but it’s guided by their internal values rather than outward emotional expression. They make decisions based on whether something aligns with their internal sense of right and wrong, not on whether it will be socially well received. Because of this, they require little to no validation from others and how this looks like IRL is someone who seems indifferent when, in reality, they are being very deliberate about what and who they choose to engage with.

Random revelation about how to tell whether an INTJ likes you (as a friend at least):
They will sacrifice their own time, focus, or energy without asking for recognition to help you. They might be dealing with their own things, but they can put that aside to help you solve yours first. They might do it so nonchalantly that you’d assume they help everybody like that too, when in fact, they are selective on who they give that energy to.

Finally, their last function Extarverted Sensing (Se), because this is their inferior function, this means they can struggle with being fully engaged in the present moment. They often miss small details like your new haircut or shirt. They often live in their own thoughts, and too much sensory info from external world can feel overwhelming.

Putting it altogether, this is what the function stack of an INTJ looks like.

Once again, humans are messy. Culture, values, religion, emotional/mental maturity, trauma and experience all shape behaviour. A cognitive function stack like this explains tendencies, but it doesn’t define the entire person. Although uncommon, people will have outlier behaviours and as they become more balanced, they might not always lean into their dominant functions and instead, use all their functions effectively.

Most importantly, don’t rank types or judge them. Every type has their own strengths and blindspots. And understand that being self-aware is also an ongoing skill, which is why so many people mistyped themselves for years.

How I use Cognitive Functions Day to Day

Enough with the theory, let me explain what it does for me in real life.

Throughout the years of learning cognitive functions, I’ve found that it can be surprisingly useful for resolving conflicts or even preventing them, especially if I know the person well.

For example, an ESTJ (based on long-term observation) once asked one of my teammates, an INFJ, to run an errand that was outside their usual duties. The ESTJ was effectively senior to the INFJ, and because INFJs have secondary Extraverted Feeling (Fe), they care a lot about harmony and often find it hard to say no.

Knowing this, I stepped in as a neutral party. ESTJs are Te-dominant, which means they really value efficiency and practicality. So I framed it objectively and told the ESTJ that the task was unfamiliar to the INFJ and it would take them longer than it would take the ESTJ to do it themselves. No personal judgment, just facts.

The ESTJ paused, thought about it, and said, “True, I guess I could get it done in 10 minutes if I start now.” They went back to their seat, and the conflict resolved before it even started.

This is fun to recall, so another example. I have a good colleague who is ESFJ. Their dominant Fe means they love people, they love talking about people, they love connecting with people, and they love harmony. Fe-dominant types in cases I often see, may get drained if they feel invisible or unacknowledged by their team.

There was a time I publicly complimented them saying “Hey, I really appreciate how much you care about the team. It actually makes a difference.” I can see the reaction was an instant smile. I could tell it mattered to them because most of their teammates were either inferior Fe users or Fi users, which made the office vibe feel less like a community and more like a cold, transactional corporation, and Fe users don’t do well there. They need a warm, community-like environment to thrive so I suggested they can consider transferring if their current team felt draining for them.

These are small examples, but it shows how a little insight into cognitive functions can help interactions run smoothly, saving time, energy, and stress for everyone. And these are automatic decisions I made after observing their cognitive functions for a while and understanding what they need in that moment. I wouldn’t be able to apply this if I only know MBTI as the 4-letter personality quiz.

Why this matters (for me)

I’m not gonna try to convince you that everyone should study cognitive functions. Everyone has their own way of understanding people. Some do it so naturally, probably like those with Fe functions. They can sense emotions in a room so quickly and effortlessly that when you ask them how they do it, they don’t even know. That’s just how their cognitive function stack works. Fe gives them that ability to empathize without needing to overthink.

But for those like me, it’s different. Sometimes it’s hard to get others. Sometimes it’s hard for others to understand our inner world. For me, studying cognitive functions is the closest thing I have to a “manual” for understanding people. I don’t know how to intuitively sense how someone is feeling. I don’t know how to read emotions or intentions in a split second. If someone can teach this to me in a methodical, systematic approach, please let me know. Until then, what I do know is how to gather data and analyze patterns. That’s my systematic approach. It’s the most reliable way I’ve found to figure out why people act the way they do, what drives them, and how they think. Simple as that.

Just a day before publishing this post, I found this blog post of an ENFJ writing about cognitive functions too. I thought it is interesting to read from a Fe user’s perspective so if you’re interested, read here.

The Fun Part: How to spot cognitive functions for newbies

I don’t know who would have read this far (if you do, thanks) but sometimes the fun part of analyzing people is collecting enough data on common phrases certain cognitive functions would typically say. When you spot that, you can start forming a hypothesis and an INTJ like me loves solving puzzles that is human behaviour and human nature hehe.

This isn’t meant to type people conclusively, but to help notice recurring tendencies you might otherwise miss. Adjusting the hypothesis continuously is also part of observing how cognitive functions are used day to day in people, so take this guide with a grain of salt:

Fe Extraverted Feeling users

Says “we feel” more often than “I feel”
Often checks in with team like “how do we feel about this”
Notices tension or mood shifts before others
Thrives on harmony, connections and group values

Fi Introverted Feeling users

Speaks from personal values: “I feel…” or “Personally…”
Makes decisions based on internal compass, not group consensus
Quiet or reserved until something touches their values
Can light up or shut down when deeply aligned or misaligned

Te Extraverted Thinking users

Focuses on action and outcomes: “Here’s what to do next”, can seem blunt or impatient
Loves efficiency and practical solutions, would point out if something is inefficient
Externally logical: relies on objective verifiable data
Organizes people or projects naturally

Ti Introverted Thinking users

Thinks carefully before doing: “Let me think about that”
Loves precision and breaking problems into core principles
Complex, personal internal logic: “The truth is what makes sense for me”
Need to understand the “why” behind everything

Ne Extraverted Intuition users

Constantly connects ideas and possibilities: “What if…?”
Loves brainstorming and open-ended exploration, very creative
Can jump rapidly between unrelated concepts
Helps people blend with circumstances and readily adapt by seeing new possibilities

Ni Introverted Intuition users

Future-oriented and strategic: “I can see this happening…”
Easily spot patterns and synthesizes information into overarching themes and possiblities
Can seem quiet, distant, or lost in thought, not present in the moment
Often sees the bigger picture, seeks deeper meaning, can seem philosophical

Se Extraverted Sensing users

Lives in the moment, experiences the world with all senses, notices details others miss
Says things like “Did you see that?” or “Look at this!”
Action-oriented: acts quickly and responds immediately
Novelty-seeking: Thrives on new sensory experiences and simulation, try new things

Si Introverted Sensing users

Relies on subjectively stored past experiences and remembers in detail: “This reminds me of…”
Notices patterns from history: Effective at internalizing lessons from mistakes and successes
Prefers stability and established routines, making them dependable but sometimes resistant to radical change
Internally compares new situations to what has worked before

Conclusion

Studying cognitive functions is not about typing people. It’s about noticing, observing, understanding. It’s about seeing the logic behind their actions, the patterns in their thinking. It’s about compassion, better communication, and more awareness of yourself and others.

Now instead of thinking “Why is this person being difficult” or “Why is it so hard to communicate with this person” or “Why this person never gets what I’m trying to say”, you can tell yourself “So that is how they view the world and interpret my words” and “Now I know what’s the best way to communicate with this person”.

Even with its limits, it makes life with people less confusing and more interesting. It makes yapping with friends about “why they do that” not just gossip, but analytical exercises in understanding human thought patterns and behaviour.

Because in the end, understanding people is not about the four letters. It’s about seeing them, really seeing them. And sometimes, that is enough.

Thanks for reading! I’m curious to know your own personal thoughts and experiences on this topic! Feel free to connect or let me know in the comments! Cheers!

Let's Connect!

Why “confidence” advice fails women engineers

Victoria Lo — Sun, 01 Feb 2026 23:00:42 GMT

I was in the room with 7 people: 3 were C-suite level, 1 from upper management, and 3 were other leads. We were discussing the company’s technical direction and product strategy for the next quarter. Decisions that would shape what we’re going to focus on building, what we're cutting out, and what risks we were willing to take.

FYI, I was the only woman in the room.

For most of the meeting, I stayed quiet. Not because I had nothing to say, but because I was watching. Listening to how people framed problems. Noticing who spoke with certainty versus who spoke to be seen. Tracking body language, tone, interruptions. Understanding where incentives, fears, and power actually sat in the room. It was quite a fun exercise, ngl haha.

This article is about that moment. Hello everyone! Welcome to another Articles by Victoria, the place where I randomly write things I’m learning about. In this article, I want to touch on a relatively unspoken topic: about why the advice for women engineers (or leaders) like “be more confident” completely misses the mark on the realities that women engineers/leaders have to face.

Reason 1: Being outspoken does not mean being confident

I had someone told me before that staying quiet comes across as lack of confidence. His well-intentioned advice was that confidence is about jumping in quickly, speaking often and asserting opinions early.

“You need to speak up more. You’re clearly capable, but people won’t know unless you show confidence.”

He especially emphasized that as a woman, I had to do all these but “double times” to gain visibility. He was being supportive, of course, which I am truly grateful. However, my personal experiences said otherwise.

In that meeting, the loudest voices weren’t necessarily the most confident. Yes, they were the most comfortable. Comfortable with the room, with the hierarchy, with the assumption that their opinions belonged there and seen as correct by default.

So people often mistook it for “confidence”. So I tried it. I spoke more. I asserted earlier. I filled silences.

What changed wasn’t my impact, but the feedback. Suddenly I was “a bit intense.” “Very direct.” “Maybe too opinionated for someone in that role.” The behavior didn’t become confidence just because I did it. It was interpreted through a different lens.

To be clear, this isn’t always about sexism.

I’m not pretending every piece of feedback I’ve received was unfair or malicious. I am indeed a direct person. In corporate environments, I don’t soften language naturally, and I don’t enjoy talking just to be visible. I’m also, by nature, an observer. I listen first, process then speak.

What didn’t work for me was pretending to be someone else.

When I forced myself to speak more just to feel less invisible, I didn’t become more effective. I became misaligned. I was talking without substance, filling space instead of contributing meaningfully. And that friction showed up immediately in how I was perceived. Ironically, when I tried to perform confidence, it was when I was seen as least confident.

That was the moment I stopped trying to perform confidence.

Now, I speak when there’s something worth saying. I participate in a way that’s honest to how I think and how I work. Direct and to the point. And most importantly, within my own comfort.

Reason 2: What confidence advice assumes

The reason why some supportive male allies gave advice like “be more outspoken” is because they think if only women engineers/leaders were more ‘confident’, they would get recognized, promoted and heard.

It assumes lack of confidence is the problem for women who are stagnated in their careers.

But if you look deeper, this assumption is not entirely accurate. Because it ignores the realities of power dynamics, work culture, hierarchy and social expectations. Women are often criticized for behaviors that men are rewarded for. Such as being too assertive, too emotional, too quiet, or too cautious. One instance of you being perceived and boxed into one of these critical categories could change your career trajectory. Which is why this so-called ‘confidence’ alone cannot navigate this maze.

Ultimately, confidence advice assumes that outcomes are driven by how convincingly you speak or portray yourself. In reality, outcomes are often driven by who is allowed to be ‘wrong’ safely, who can feel heard and validated even when they’re objectively wrong. Confidence alone doesn’t redistribute power or neutralize hierarchy. And it doesn’t protect women from asymmetric behavioral expectations.

Reason 3: The paradox of confidence advices for women

One of the toughest times of my career wasn’t learning how to lead a team. It was learning how to navigate boundaries that no one explicitly talks about. Many things are invisible and subtle unless you've experienced them yourself, repeatedly.

For example, this has happened quite often: when I entered a new meeting with a client, their first instinct was to shake hands and introduce themselves to my male coworkers, assuming they would lead the project.

The same thing happened in follow-up meetings, even after we had all introduced our roles and the client knew I was the only technical person in the room. Yet, they would make eye contact with a male salesperson when asking a technical question, most likely unintentional and just out of habit, forgetting that I am the technical expert.

For context, I am working in a country where there are very few women engineers and most of them are in sales or admin roles, so I understand these behaviours are not ill-intentioned in any way but simply come from their lived experiences and expectations.

And this is why I find confidence advice for women paradoxical at times.

If I try to increase my presence and stand out, I would be seen as attention-seeking. If I spoke up to redirect the topic when it digresses, I could risk being labeled as too assertive. If I waited quietly and speak only when being spoken to, I’m told I don’t seem confident.

Essentially, I need to speak up but don’t sound too assertive. Be decisive but also take everyone’s opinions into account. Lead my team well but don’t be too direct. Sounds easy to do, right?

What actually works: Redefining Confidence (subtly)

I’d like to share my favourite definition of confidence with a quote from Eleanor Roosevelt:

No one can make you feel inferior without your consent

For a long time, I misunderstood this quote. I thought it meant I needed thicker skin. That I had to override how rooms made me feel through sheer willpower. If I felt small, it was because I allowed it.

Now, I interpreted it differently.

To me, confidence isn’t about forcing myself to speak louder or faster or more often. It’s about refusing to internalize signals that were never meant to evaluate my competence in the first place. It’s knowing when feedback is about my work, and when it’s about someone else’s discomfort with my work instead.

I read about it somewhere. It’s called discerning. Being able to discern is being able to ask myself quietly,

Is this about the quality of my work, or about me not fitting someone’s expectations of how I should sound, lead, or behave?

And once I learned to discern, setting boundaries became easier. I used to believe that being useful meant always saying yes. Helping every team that asked. Being available, responsive and accommodating. And somehow it made me tie my confidence with proving my value over and over again.

I no longer feel the need to demonstrate my usefulness by overextending myself. I choose where my time and energy go. I prioritize the work that aligns with my role, my impact, and my own sustainability. Not because I’m less capable, but because I know my boundaries.

Confidence, to me, is being comfortable being yourself. I’m usually the one listening deeply, then speaking with intent. And I’m not filling silences just to prove I belong. Still, even though I realized all this and am writing this article, I have to be honest. This does not mean I’m always confident. The reality is that my confidence can fluctuate, and there will be times when imposter syndrome hits, when I’m second guessing my decisions, when I think if someone else were in this role, the outcome might have been better. Yes, all these thoughts do cross my mind and that is okay. Confidence does not mean you will never doubt yourself again. The important part is that you can accept yourself even when you have those moments.

Perhaps this is the rawest advice for women engineers. Instead of teaching them to “be more confident”, we create safe environments (like how we did at WomenDevsSG - shameless plug I know) and teach them how to have internal boundaries, where they don’t have to constantly prove they deserve to be there.

Thanks for reading! This is an article I initially felt a bit too vulnerable and “controversial” to share. But if this helps you in any way or if you have any feedback or thoughts, feel free to let me know in the comments or send me an email!

See you in the next article! Cheers!

Let's Connect!

Context Engineering 101 for GitHub Copilot

Victoria Lo — Sun, 25 Jan 2026 16:00:11 GMT

The other day, I was teaching a junior developer how to vibe code. We were sitting side by side, both using GitHub Copilot. Same IDE and same model. Yet the experience could not have been more different.

They kept getting stuck in error loops. Copilot would suggest something, it would fail, they would tweak the prompt, then it would respond with another confident but slightly unoptimized solution, and the loop continued. After a while, Copilot stopped being helpful and started being too much.

At first, I thought this was about prompts. Maybe they were not asking clearly enough.

But after watching closely, I realised the real difference was more accurately, how much context we were engineering before asking it to generate anything.

Hello everyone. Welcome to another Articles by Victoria, the place where I randomly write things I am curious about. In this article, I want to talk about a new term that’s been going around these days called “context engineering”, which is essentially prompt engineering 2.0.

So let’s dive into what it actually is, why it matters much more now in 2026, what GitHub and VS Code have already built to support it, and how to apply it practically with GitHub Copilot.

What is context engineering?

There are many definitions of this new term. When talking about context engineering, it is not talking about better prompts. CEO of Braintrust Ankur Goyal defines context engineering as:

Bringing the right information (in the right format) to the LLM.

Or as Anthropic states in more detail,

Context engineering refers to the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference, including all the other information that may land there outside of the prompts.

AKA it is about shaping the information environment the model operates in.

Image credit

If you have used coding assistants such as GitHub Copilot, Windsurf, and more, you may notice it does not respond only to the sentence you type. It builds its answer from a mixture of signals, including:

The code before and after your cursor
The file you are editing
Other open tabs in your editor
Related files AI assistant automatically pulls in
Comments, docstrings, and naming conventions
The overall structure of your repository

This is why according to GitHub, Copilot is a contextual system, not a chatbot. It is continuously gathering context from your VSCode workspace and using that to predict the most likely next piece of code. If that context is weak, outdated, or contradictory, Copilot will still respond. It just responds by “guessing,” which is where productivity can go wrong with vibe coding.

Why this matters more in 2026

Honestly, we’ve all read those articles on “How to Prompt Engineer” in 2023-2025 and we’ve probably seen a few anatomy of a prompt type of pictures circulating around.

Image credit

In 2026, AI models are far more capable than when Copilot first launched. But that power comes with a tradeoff.

Modern models are extremely good at pattern matching. They will confidently continue whatever pattern you show them, whether that pattern is good or… bad.

Because I’ve been using GitHub Copilot since day one, I know they have invested heavily in making Copilot smarter about context. It now looks beyond a single file, automatically retrieves relevant code from your workspace, and prioritises nearby and recently edited files when generating suggestions.

VS Code has also made context more explicit. Features like selecting code before invoking Copilot, inline chat scoped to a file, and adding workspace context are all designed to help you control which context to prioritize at any given moment. But none of this fixes unclear intent or ambiguous context.

If your codebase does not tell a coherent story, Copilot will create one.

An example: vague context vs engineered context

Here is a very common starting point, let’s say you want Copilot to generate code based on your comment:

# create auth middleware

From Copilot’s perspective, this could mean anything. Different frameworks, auth strategies, error handling styles.

Now compare that to this:

# Middleware that validates JWT tokens from the Authorization header
# Uses the existing verify_token utility
# Returns a standard 401 JSON response if validation fails

Nothing about this is fancy or overly technical. But it dramatically reduces ambiguity.

This aligns directly with GitHub’s recommendation to use comments and docstrings to express intent and constraints, not just describe the function name. Copilot performs best when it understands why the code exists, not just what it should do.

How to Context Engineer

This was the key lesson for my junior developer because they kept rewriting prompts. And my solution was not “write better prompts”, but “stop making the AI start from zero every time”.

According to GitHub’s blog post, context engineering starts with custom instructions.

Instead of reminding Copilot over and over how your team writes code, you can define those expectations once in a document so that everyone (including Copilot) are on the same page. Think about how many times you have typed things like:

“Can you use our existing error format and…”
“Following up with the implementation of xxx feature…”
“Once again, the xxx feature that we talked about where…”

That repetition of context is not only time-consuming, but ineffective when pair programming with Copilot.

Step 1: Create a `copilot-instructions` file

In a .github/copilot-instructions.md file, add everything you think is relevant in terms of context. Basically, this is you telling Copilot that “These are the house rules. Always assume this context unless told otherwise.”

For example, you might describe how your React components are structured, how errors should be returned in a Node service, or how you expect documentation to be written. Copilot then carries those assumptions into every chat and code suggestion automatically.

What I like about this approach is that it mirrors how humans actually work. When someone joins a team, you do not restate the same rules for every ticket. You give them a mental model once.

That is context engineering at the project level.

And the advice GitHub gives here is important:

Start small
Keep it high level
Only add rules when you notice Copilot repeatedly making the same mistake

Context should correct behaviour, not overwhelm it.

Step 2: Create reusable prompt files

Another strategy for context engineering that sounds small but improves the output greatly is reusable prompt files.

Add your prompts into .github/prompts. You are not just saving words, you also are standardising how certain tasks are performed. Some examples of prompts you can add are:

Code reviews
Test generation
Component scaffolding
Planning exercises

For example, a high-level code review prompt can look like:

description: Review code for correctness, clarity, and alignment with project standards

Review the selected code as if you are a senior engineer on this project.

Focus on:

Correctness and potential bugs

Readability and maintainability

Adherence to existing patterns and conventions in this repository

Edge cases and error handling

Unnecessary complexity or premature abstraction

Do not suggest new libraries or architectural changes unless absolutely necessary.

Structure your feedback as:

High-level summary

Specific issues or risks

Suggested improvements (if any)

And a test generation prompt can look like:

description: Generate tests aligned with existing testing patterns

Generate tests for the selected code.

Constraints:

Follow existing test patterns and frameworks used in this repository

Prefer clear, readable test cases over clever abstractions

Cover happy paths, edge cases, and failure scenarios

Do not mock internal implementation details unless necessary

Return:

Test file structure

Test cases with descriptive names

Brief notes on what each test validates

Instead of everyone on the team asking Copilot to “review this code” in slightly different ways, your team now have a shared understanding and Copilot can output more consistently.

I noticed how life-changing it is for juniors. Because it removes their common challenges like unclear prompting or criteria. They are no longer waste time trying to learn the “right” way to talk to Copilot. Because the workflow already exists, they just invoke it.

Implementing this through a context engineering lens, reusable prompts are less about talking to AI and more about teaching it how your team works.

Step 3: File structure is part of the context

Another detail GitHub highlights, but many developers underestimate, is how much Copilot relies on file and folder structure. For example, a file named user_repository.py inside a repositories directory tells Copilot far more than a file named helpers.py.

Copilot actually infers responsibility from location. If your structure is intentional, Copilot follows it. If your structure is vague, Copilot blends concerns that should never meet.

Sometimes improving context for better Copilot output has nothing to do with AI at all

Understand that too much context can also hurt

Now that we’ve learned some ways to make context clearer for Copilot, there is one thing I want to point out is that not all context is good context.

This is something Anthropic talks about a lot in their writing on context engineering for AI agents, and I have seen it play out repeatedly when using GitHub Copilot.

More context does not mean better understanding. Because AI models do not read like humans. They prioritise by weighing signals. And if you highlight to Copilot that everything is important, then nothing is.

The goal of context engineering is not to dump information. It is to find the smallest, highest signal set of context that reliably produces the outcome you want. Here’s a guide I referred from Anthropic, the right context has:

Clear, direct instructions that explain intent and constraints, without trying to micromanage execution
Clear sections that help the model separate background information from instructions, from tools, from expected output
Enough information to behave correctly or as intended. This requires some trial and error, any unexpected outputs can be documented and used to provide additional information to correct it

Above screenshot in an example of prompts with varying levels of context and which one is considered to be just right. Image credit

Conclusion

When I explained these ideas to my junior developer, I did not frame it as “advanced prompt engineering” or “context engineering”. I simply tell them to start teaching it how to think in your environment.

I tell them to imagine Copilot is a new engineer who joined the team five minutes ago. It is fast, but it has zero institutional knowledge. So instead of treating every interaction as a one-off prompt, teach it context, reusable workflows, and have clearer intent. Only then the error loops faded away.

Thanks for reading! I’m curious to know your own personal thoughts and experiences on this topic! Feel free to connect or let me know in the comments! Cheers!

Let's Connect!

References:

What I Learned about Data Governance and Why It Fails

Victoria Lo — Sun, 18 Jan 2026 23:00:43 GMT

As a solutions engineer lead, my work often involves translating problems described by humans into technical solutions.

Read my article on my day to day life as a solutions engineer lead if you are curious :)

On most days, this means having to sit down and talk to stakeholders, engineering teams and merchants. They would all describe the same problem in different perspectives, goals and priorities. My job is to align them all into a tangible solution, so everyone is happy (or at least satisfied).

Hello everyone! Welcome to another Articles by Victoria, the place where I randomly write things I’m curious about. In this article, I want to share about data governance, how it is often framed as a technical/compliance project when in reality, the biggest obstacles are human-made.

Clarifying Data Governance

In a talk I gave last year, I gave a super layman definition for data governance:

The ability to trust & use raw data, make sense of it, document it across functional teams

As you can see in this definition, “trust” is a keyword people often overlooked. When talking to people at data conferences, they described data governance as creating a system for efficient data management. This involves getting the right data to the right people and setting up a catalog to organize the data clearly and without confusion.

Below is what most of us would think what data governance is all about: simply building robust systems and policies. Image credit

This is not wrong, in fact, I would have agreed with this definition in the past. Because I believed that a lot of companies implement data governance from a top-down approach by designing the right systems, implement the most sophisticated tools and have clear policies supporting it.

However, there was a project that humbled me and made me realized that many companies implement data governance from a top-down approach not because it works best, but because it feels safest.

An Example

There was a project that felt so smooth. Everything was aligned, the timeline was within everyone’s expectations and everything seems good to go. We had many solution design meetings with stakeholders prior to the project’s implementation. They were engaged, responsive and overall feedback was positive.

We even had training workshops where we showed teams how to use the dashboards and how decisions could now be made with more confidence, and where the data flows from end to end. Everyone was nodding. When asked if they had any questions, all of them said it was clear so they had none.

Then, we went live.

Pipelines were running as expected, no failures or alerts. However, I was shocked to see the dashboard showing zero to minimal activity. I was confused because the client said everything was working fine. So, what is the issue?

They couldn’t tell me. They were not very technical people so in their eyes, they had nothing to do with it. They said this “technical problem” wasn’t their fault and they asked us to check our data pipelines and our systems. Still, nothing came up.

I ended making an urgent trip to visit them on-site and what I found had little to do with our implementation. Teams were still updating their own spreadsheets, and many department heads were still asking admins to manually create reports in Excel. A lot of them were hesitant to enter data into the system.

When I asked why, there were a lot of:

“My manager told me it’s safer this way.

“We are unsure if our data will be safely stored and visible across teams.”

“We had some misunderstandings in the past.”

It was clear that there had been past cases where data was taken out of context and used to question teams publicly.There was a culture where no one wanted to publicly own the data because it could be used against them.

People did not distrust our system, they distrust how the data in the system might be used.

I spoke to managers who wanted transparency but feared being judged by management. I spoke to individual contributors who do not want to be held accountable. I spoke to upper management who wanted this to work and believed a “better system” would solve this problem.

And that day, I learned that technology was not the bottleneck. The problem was trust.

Why Data Governance Projects Fail

Good intentions don't always lead to good results. If we treat data governance as just a digital transformation project and ignore the necessary cultural and mindset changes, it's more likely to fail, as noted in an article by Prosci.

The most common life cycle I’ve seen in data governance projects is like this:
1. Governance launches as a compliance initiative
2. Teams experience it as added overhead
3. Data Steward roles exist in name but lack support and authority
4. Adoption drops, workarounds appear
5. Governance is declared a failure and rebooted the following year

Engineers resist governance when it feels imposed, when it slows them down, and when it ignores the reality of how work actually happens. Not because they are anti governance, but because governance often arrives without safety.

This project forced me to confront a hard truth as a solutions engineer lead.

Overcoming Data Governance Challenges

I could not fix this by adding more rules or tighter controls. If anything, that would have made things worse. The challenge was not technical compliance, but human alignment.

The first thing I had to do was slow down and listen. Before enforcing ownership, I needed to understand how teams experienced accountability. I had already written about this in my article What Engineering Leaders Get Wrong About “Ownership”, but this project made the lesson even more clear: Ownership only works when people feel safe enough to step forward. Without such culture, labels mean little.

So I got to work and opened Google Docs to start documenting everything I heard from the users themselves. Here are my findings of common responses I heard and how I addressed these:

What I heard from teams	What I did as a solutions engineer lead
“I don’t want to be the owner if something goes wrong.”	Clarified that ownership meant coordination and context, not blame. Aligned with management on how incidents and data issues would be handled publicly. Suggested to have a clear documentation on it.
“I’m doing extra work on top of my actual job.”	Understand their day-to-day work and how we can directly support their workflows. Removed anything that felt performative or compliance driven.
“We’ve been burned by metrics before.”	Reset expectations on how data would be used. Explicitly call out what data would not be used for, especially performance shaming.
“The data isn’t perfect, so I don’t want to publish it.”	Normalised imperfect data and provide clear steps on how to keep data clean and updated.
“I don’t trust how other teams will interpret this.”	Created a collaborative forum and discussion board to facilitate cross team conversations to align on definitions, assumptions, and decisions
“Why do we need this when our spreadsheet works?”	Acknowledged the spreadsheet, then showed where it broke at scale and how shared systems reduced duplicated effort.

Within months of constant monitoring and cultural reinforcement, the change in users' behavior becomes clear. Slowly, I see users themselves began to write their own documentation for their datasets. Engineers who were avoiding conversations were now asking thoughtful questions on metadata standards.

Conclusion

This experience taught me that the funny thing about governance is that the moment people said it feels like governance, it means it’s failing. Because effective data governance to me is a subtle and long term impact. A new hire would come in, and they shouldn’t be questioning the processes, the culture and the quality. It shouldn’t feel forced, controlling but instead, natural yet efficient and continuously evolving.

By acknowledging that data governance is a human problem disguised as a technical one, we focused on the missing piece of the puzzle: building trust.

Thanks for reading! I’m curious to know your own personal thoughts and experiences on this topic! Feel free to connect or let me know in the comments! Cheers!

Let's Connect!

What Engineering Leaders Get Wrong About “Ownership”

Victoria Lo — Sat, 10 Jan 2026 23:00:10 GMT

I remember one production incident very clearly. Luckily, it was just enough to affect internal users, Slack notifications were firing off, and I could hear the iconic notification sounds echoing from everyone’s laptops in the office.

Someone shared a service link while another group said they have tagged the team that owns it. But overall, there was silence.

No one stepped in. Not because they did not care, but because everyone was waiting for the “right” owner to speak first.

That was when I realised something was very off, not with the system, but with how we think about ownership.

Hello everyone! Welcome to another Articles by Victoria, the place where I randomly write things I’m curious about. In this article, I want to share what that incident taught me about ownership, why treating it as a label often backfires, and what I have learned as a solutions engineer lead about creating teams that actually step up when things get messy.

What leaders think ownership means

When leaders talk about ownership, it usually sounds very clear. Things like:

A name on a Jira ticket
A service with the team name on it

It’s all very black and white, someone is accountable on paper.

In the org charts and dashboards we see, everything looks perfect and clean. Every tool, every ticket, every dataset has a name under the “Owner” label.

Unfortunately, when real incidents happen, no one steps up. In reality, this kind of ownership often turns into boundary policing. People optimise for not being blamed rather than fixing the problem. The first instinct becomes deflection, not action.

“This is technically another team’s responsibility.”

That’s the most common answer I’ve heard at one point. So what does real ownership actually look like?

What real ownership look like in teams

Real ownership, from what I’ve seen, is the one who moves and shows up when things needed clarification. The one who can say, “I may not be the best person to work on this, but I will figure it out and find someone who can help.”

I have seen engineers jump into incidents for systems they barely touched, simply because they understood the impact and refused to let users suffer while teams debated scope.

I have also seen the opposite. Teams with clear ownership documentation where no one steps forward without explicit permission.

That’s when I noticed: the difference was never about skill. It was safety and behaviour.

A personal mistake

Earlier in my leadership journey, I assumed ownership was obvious, as I mentioned in the previous section. We had documentation. We had owner names labeled. Everyone had been there long enough so I assumed they know their responsibilities.

So I did not explicitly clarify who would drive certain cross team responsibilities. I trusted the system, perhaps too much.

Weeks later, a dependency slipped. Not because anyone was lazy, but because everyone assumed someone else was handling it. The typical bystander effect. By the time it surfaced, it was urgent, visible, and painful.

The most awkward moment was the conversations. Each team lead could explain, very reasonably, why they thought it was not theirs. And they were not wrong. I had never created shared understanding. I had just assumed it existed.

And so I had to face the uncomfortable truth about ownership: that it is not a label, but a behaviour.

You can create conditions around it but not every organization, especially startups, have clear-cut black and white roles. When an issue arises, it could be in a gray area where there is no explicit owner. And when people feel punished for stepping outside their lane, they will stop stepping up. When ownership equals blame, people will avoid it.

That’s why I learned that for leaders, it means ownership starts with us.

So how to make it work?

Instead of enforcing more labels and specific scopes, what I observed actually work within my organization was better environments. Having shared context rather than rigid boundaries helps teams understand why something matters, and they are willing to act even if it is not technically theirs.

Instead of asking “Who owns this?” which facilitates that black-and-white thinking, the leads would say “I am available and willing to help unblock this”. By modeling this attitude and behaviour, we promote proactivity and a blameless work culture.

We also recognized the ones who embrace this culture first, praising publicly for their efforts. This creates a cycle of positive reinforcement and makes the rest more comfortable to follow suit. For a long time, I understood that being a leader is about silently pushing the team onward, but someone had to be the first one in order to get the rest moving.

So I learned to lead by example and collaborate with other leads to create this safe and blameless work culture.

Conclusion

Real ownership feels risky, especially under uncertainty and being visible if something goes wrong. And this is why we avoid it instead of showing up.

It is the leads’ responsibility to create a supportive and blameless culture with safe space for guidance and collaboration. Thanks for reading! I don’t usually share a lot on articles on leadership since I felt I’m too new at this to be writing about it. But if this helps you in any way or if you have any feedback or thoughts, feel free to let me know in the comments!

See you in the next article! Cheers!

Let's Connect!

How to be a Writer Without AI, but With Your Own Voice

Victoria Lo — Sun, 04 Jan 2026 23:00:12 GMT

It’s the start of a new year and as usual, I’ve been receiving emails from my readers about how to start technical writing in 2026. A lot of people tell me they want to start technical writing/blogging, but I noticed recently, they ask questions like:

What can I write about when I’m still learning while AI knows everything?
How do I use AI to write without sounding like everyone else?
I’m not confident writing without using AI, what should I do?

Notice how every question is AI-related. This is quite interesting to me because when I started technical writing in 2019, writers are simply people who can ideate and write (without any AI assistant). Look at us now, just 7 years later, and everyone is fully reliant on LLMs to write for them.

I admit, I too had boarded on the AI train, and used it a lot for writing emails, posts and rephrasing my articles to sound better. We are a society focused on results and efficiency. So if everyone is doing it and producing so much output so quickly, there is the pressure to follow suit.

But despite the fact I used AI to a certain extent, my readers told me that my articles still sound like me. In fact, they can imagine my voice speaking to them as they read my articles. So what exactly is going on here?

It is a simple truth. AI did not kill technical writing or blogging. It exposed something else.

A lot of people are now clicking “Publish” after copying and pasting text straight from a chatbot. That’s why you might notice many blogs sounding strangely similar. There’s even a Wiki page on these AI-generated text patterns.

Now this is not saying that you can’t use AI tools for technical writing at all, but you don’t need to use AI to start, especially if you haven’t found a clear writing style yet. In this article, I'll share some strategies to help you reduce your reliance on AI, discover your unique writing voice, and learn how to leverage AI to speed up the writing process while keeping your personal style.

Blogging was never about Writing

Before we get into the topic, I have to preface with this. Believe it or not, I am terrible at writing. I don’t have perfect grammar (that’s why I use a grammar tool), extensive vocabulary or polished paragraphs. Luckily, blogging and technical writing is not about being a phenomenal writer.

Technical writing is simply:

You learned something
It was confusing or something new/cool
You figured it out
You documented it so that you can refer back to it, and someone else can too

The best articles I have read are rarely the most polished ones. They are not encyclopedic or overly comprehensive. Instead, they're about the connection, the shared frustration or genuine curiosity you feel with the writer. As you read through the article, you gain a story or value from the writer.

And that’s why you should start writing in the first place. To provide value to yourself and others.

I started writing because I had ZERO technical knowledge and a lot of tutorials skipped steps, assuming people know. And I was tired of pretending I understood faster than I did.

Why You Should Start Writing without AI

Yes I know. You want to put out as many articles as you can. Everyone writes fast and you felt the pressure. So you start prompting chatGPT to give you quick answers, and that’s how you sound confident, with polished paragraphs, perfect grammar and profound vocabulary.

But can you remember what you wrote?

A reader recently told me, “I enjoyed your focus article so much!”

And I immediately knew they were talking about my “What it means to be focused” article I wrote back in 2021. It’s 5 years ago, but I remembered 80-90% of what I wrote in that article. Because I wrote every word, I typed and re-typed paragraphs, I revised the outline and content several times for that article. I even remembered I finally finished it after sitting for about 3 hours at Starbucks. The drink was an ice latte by the way.

Relying on AI to write your articles completely takes away the process of figuring out how to write your article in the first place. Understanding what you want to convey to your audience is a part of being a writer. If every word, paragraph and thought or idea is generated by something else and not you, your voice won’t be in it.

And readers can feel that.

When every article sounds too “perfect”, funnily enough, it becomes less trustworthy to read. When you share clear, amazing steps in a tutorial but haven't learned the process behind them, the knowledge won't stick.

On the other hand, when you write without AI, especially at the beginning of your writing journey, you are forced to think before you explain. You write things in the order you understood them, not the order that looks good in every other blog or documentation generated by AI.

That is how your voice forms naturally. Readers would feel it is as if you are talking to them, teaching them the process you learn. Because your voice is not something AI can generate.

How to Write Without AI

AI has evolved to the point of no return for humans. Nowadays, a lot of us probably can’t last a day without opening chatGPT (or any other equivalent ones) and prompting it for something. After all, it is fast, efficient and can sound quite human-like with the right prompts.

If you want to start writing in 2026, it is almost impossible NOT to feel like you should be using AI. And yes, it goes the same for me.

I used a lot of AI for my social posts and emails, a bit less for my blog. Still, somewhere along the way, I noticed a quiet problem started to surface. A lot of my writing became emotionally flat (?), like it just sounded clean but forgettable. I can’t really remember the articles I wrote in 2023-2024. Probably that was the period I used the most AI for my writing.

So the question is not: How to write without AI (the header is misleading, oops)

It is: How to write while leveraging AI without losing your voice

Here are some of my strategies that helped me reduce my reliance on it and find a good balance to use it for efficiency but still keeping my style.

1) Write first, then optimize

Once you get used to AI, this is probably a hard habit to build. But once you unlearned your instinct to prompt first, and instead actually sit down and write yourself first, it will change everything.

You will no longer skip the most important part about writing: thinking.

So write the first draft yourself, without AI. Force your brain to confront what you want to convey, what you know and what you lack. Some parts you wrote may sound awkward, but just write.

I give myself a rule: First draft is mine. There will be messy/awkward sentences, half-baked ideas and everything in between. And it’s totally okay.

Only after that, you may use AI to polish it but to keep your voice, I usually give very explicit boundaries such as only taking a section I thought was written vaguely or lacks structure. And my typical prompt would look like this:

I wrote this draft myself.
Do not rewrite it in a generic or corporate tone.
Do not add new ideas or examples.

Your task is to:
• improve clarity where sentences are confusing
• tighten wording without changing my voice
• fix grammar and flow issues
• keep the tone conversational and human

If something is unclear, point it out instead of rewriting it.

So this way, I’m not asking AI to rewrite it in their voice, but to optimize my thinking, words and clarity.

Another rule I set myself: If AI rephrases a line where I no longer recognize myself, it’s better to undo and keep my original sentence. Again, this is to keep the authenticity and personality in my articles.

Other ways you can use AI without overwriting your voice are:

Generate a more SEO-friendly title
Generate a more SEO-friendly subtitle
Generate a metadata description
Generate tags for the article

2) Your writing is a form of documentation, but it shouldn’t sound like a generic one

Most of my readers who become technical writers have this mindset that technical writing on a personal blog should sound like a documentation by a corporation.

If you’re writing for a company, that may be true, but on your own blog where your writing style is your personal brand, that would be the fastest way to lose your voice - when your blog sounds like a manual.

Instead, write the way you would explain something to a teammate you trust. Someone who would ask follow-up questions. Someone who does not need you to sound impressive.

You might notice in some of my articles, I would imagine a conversation between you, the reader, and myself such as, a reader might ask:

But Victoria, I just can’t help using AI for everything!

And then I would continue my article as if I am addressing that imaginary question directly.

This is a simple trick I use to build a connection through my articles while keeping them conversational, so they don't sound too much like documentation or a scientific paper. Try doing this on your next article and let me know! I would want to read that article.

3) Read material not written by AI

With the rise of AI-generated content, even if you don't use AI for writing, you might still be influenced if you read a lot of AI-generated material. This could affect your writing style, as many technical writers might unknowingly adopt the neutral, matter-of-fact tone typical of AI-generated content.

The easiest way to spot this influence is to read your own writing after a few days. If it feels flat, impersonal, or like something you’d see on a corporate blog, chances are your brain is unconsciously echoing AI-generated patterns.

To counter this, I intentionally read older books. It’s hard to tell from recent blogs if they’re 100% written by a human. I may sometimes come across some blogs that may sound opinionated and conversational, with inside jokes and personal anecdotes. But the books I read are definitely written by humans because they are published before the generative AI era. Some books I recommend:

Mastery by Robert Green
The Laws of Human Nature by Robert Green
The Alchemist by Paulo Coelho
The Last Lecture by Randy Pausch
The 7 Habits of Highly Effective People by Stephen R. Covey
Atomic Habits by James Clear
Almanack of Naval Ravikant by Eric Jorgenson
Outliers by Malcolm Gladwell
Thinking Fast & Slow by Daniel Kahneman
Shoe Dog by Phil Knight
How to Win Friends and Influence People by Dale Carnegie

And more on this list if you head to my Nerd Stuff page.

Shameless plug: Another set of non-AI generated material you can read are my personal book reviews/reflections series or any article I wrote on this blog before 2023 haha

After reading these fully human written material, try to manifest that in your writing. Don’t copy the ideas but be inspired from the rhythm, the tone, the energy that make it human-like. Gradually, your brain will be able to internalize what sounds authentic and real vs the generic AI tone.

4) Don’t rush your writing

Another strategy to keep your use of AI to a minimum is to not feel like you owe someone an article in a few hours. AI gives you something right away, a polished article. So the temptation to use it for efficiency gets harder to resist the more you focused on getting things out fast.

Instead, focus on the process and don’t rush to finish your writing in one sitting. Write a paragraph or a section, then take a break. Go for a walk, make a cup of tea, do something unrelated. When you come back, read it aloud. Does it sound like you? Does it feel like you’re talking to someone, rather than delivering a memo? If not, tweak it. Sometimes I end up rewriting entire sentences because I hear my own voice and realize it’s off.

Even right now, I have several articles sitting in my drafts. Some of them are on topics I am very passionate about and that’s why they are taking longer to write. I want to convey them in the same way I visioned but I couldn’t find right words, examples and structure at this moment. So I pinned them in my drafts and go back to them in between breaks to take another look and see if I can get some progress in them.

Experiencing writer’s block is something normal for a lot of writers. But with so many AI writers now, perhaps my Top 6 Strategies to Overcome Writer’s Block will be redundant in the future.

This also works for spotting places where your thinking is fuzzy. If a paragraph doesn’t make sense to your own brain after a break, imagine how confusing it would be to a reader. Then fix it, before any AI even sees it.

5) Embrace Imperfection

Last but not least, it is to let go of the idea that your articles must be perfect before they are published. So many fellow writers asked me to review their article before they publish. Sure, it’s good to get feedback, but the best feedback is actually not from me, but your audience.

So get the article out first, let everyone read it. When reviewing an article for someone, unless there are technical errors, I usually think the article is ready to publish. Some small tweaks I suggest can be subjective and not worth editing. I would much rather you publish the article, get feedback from the public, take the constructive ones, ignore the insulting ones and iterate the process to improve your writing that way.

Publishing is part of the writing process, not the final step after everything feels safe and polished. The moment your article is out in the world, it stops being “just an idea” and starts becoming real. Some will misunderstand parts of it. Some will resonate deeply. Some will disagree. That feedback loop is where your voice sharpens.

If you wait until an article feels perfect, you’re usually just waiting until it feels less vulnerable. And that’s often the version that sounds the least like you. So publish it while it still has edges.

The Final Verdict

AI did not kill writing, but it exposes those who haven’t built a voice. In an era where text can be instantly generated, writing that sounds like a person can actually help you stand out. Not because it is perfect, but because it is real.

I hope this article convinces you to not only start your writing journey to build a voice for yourself, but also to slow down and think before you outsource that voice to a tool.

Again, I emphasize that you do not have to NOT use AI. It is something you can leverage when you learn to write without it first. Once you can do that, AI stops being a crutch that you depend everything on, and becomes an assistant to help you move faster.

Thanks for reading! See you in the next article! Cheers!

Let's Connect!

2025: Year in Review

Victoria Lo — Sun, 28 Dec 2025 23:00:57 GMT

Hello everyone! We’ve finally reached the end of the year. As always, time for another year to review. First of all, congratulations that we’ve made it here, through all the chaos and curveballs of 2025. I hope this year treated you well in its own way, and that you found moments of growth, joy, and meaning along the way.

I spent 12 months writing this article, noting down any lessons I learned along the way. It took me a while to organize everything I wanted to write for 2025’s review so here we are: 12 lessons for 12 months of 2025.

As usual, a warning: this is a super long and personal read so if you would like to skip to the Special Thanks section, please scroll to the bottom.

Lesson 1: Know your non-negotiables

Boundaries is something you need to be clear about from the start, not when life just starts to get busy. When I didn’t set clear boundaries aka my non-negotiables for myself early this year, it became non-existent for me. But I know now.

For me, it’s my “me time.” Some days, I didn’t even have time for lunch and worked straight until dinner. But dinner was sacred (yes I’m serious about food) and my phone will be on silent mode. And if I needed to work overtime for my 9 to 5 job, I try my best to keep it until 10 pm latest. If it’s not for my 9 to 5… well, I’m a workaholic so there’s no limit to that haha.

Still, I see my energy as a form of currency. It is expensive and limited. By adopting this mindset, it helps me to manage what’s important to deal with immediately or not. Because with so many things going on in my personal and work life this year, knowing how to manage my energy and what my non-negotiables are became even more crucial for my mental health.

My me time every night is essential to recharge and without it, I can make irrational decisions the next day. Nights are mine; if more work is needed, I either wake up earlier the next day or delegate. I’ve found that sticking to this boundary has saved me from burnout more than once.

Another non-negotiable is sleep. No matter how much is on my plate, I aim to get at least seven hours (though I admit I broke this rule few times). I’ve learned the hard way that running on too little rest makes everything harder. This year, I’m not proud to say that I have 3-4 nights where I didn’t sleep, working till the sun rises 💀 Why did you do that to yourself, Victoria?

Because of the sleep debt, my focus slips, my patience runs thin, and small problems seemed huge and vague. 1 night of no sleep will take 3 nights of high quality sleep to recover my brain and even longer to recover my energy. I need to remind myself that I can’t do all nighter hackathons like I used to anymore so sleep has become something I consciously need to make time for.

Finally, I never compromise on quality time with the people I care about. I make time for them. Work can fill every hour, but friends, family, or even a call with long-time friends/readers remind me why I do what I do. These boundaries aren’t about being rigid, they’re about protecting the things that keep me sane, motivated, and fully present.

Our WomenDevsSG co-Director, Saloni, speaking at an event on AI usage!

Lesson 2: Be a master of delegation

Sometimes it feels faster to just do things myself. Under tight deadlines and pressure, that instinct can be strong. But learning to trust others is key. The sooner I internalize this, the less energy I waste and the more scalable my impact becomes.

Back in January, there was a week when I was running on just 1 hour of sleep, and I was feeling sick, but still woke up at 6 a.m. to commute to work the next day. All this was because I hadn’t mastered delegation. I still feel like certain tasks are only mine to do and I put immense pressure on myself to get them done perfectly.

I thought I had let go of most of my perfectionistic tendencies, but this is one area I admit I’m still learning to work on. I get anxious when I’m not there to review or manage processes. My parents often tell me it’s because I have a strong sense of responsibility, which is a good trait (?). Even if that’s true, I’ve realized it can also drain my energy if I don’t balance it with trust in my team.

The same pattern showed up with the System Design workshop I led for WomenDevsSG. I planned the content and envisioned how the session would run (30 minutes of theory followed by 50 minutes of hands-on practice). I organized the slides, added a Mentimeter for interactions, prepared a feedback form, and wrote facilitator notes.

At the time, I had a lot on my plate but didn’t reach out for help beyond social media posts and facilitation. In hindsight, the success of the workshop wasn’t due to what I did alone, it was the facilitator volunteers who stepped up, creating an engaging, hands-on experience. Without them, the event simply wouldn’t have been possible.

This experience made me realize that asking for help doesn’t come naturally to me. I’ve known that for a while now but this year, its consequences are amplified. I learned to be independent from a young age, and it’s still something I struggle with. It’s a work in progress and I’m still learning how to delegate effectively, but eventually, I want to become the kind of leader who can empower others to grow while achieving shared goals.

I did lead the 30-day Hacktoberfest initiative at WomenDevsSG, and it was a success thanks to my fellow volunteers who are passionate about open source! On hindsight, I think I did a better job at delegating in October compared to January.

Movie of the year, ignore if you disagree

Lesson 3: How to Develop Strong Judgment skills

Critical decision-making is part of my role. When unexpected issues arise, I’m the one who must decide on a temporary or permanent solution. Some problems are bigger than others, and it’s not always easy being firm in your decisions, especially as a woman in a leadership position.

For context, my company is based in a country where women in leadership positions are still rare. It’s common to see women assigned admin/supporting tasks, while men often move more quickly into leadership roles.

I’ve had moments where I hesitated, worried about pushback or looking “too assertive,” and the delay only made things messier. That's why I learned that things would be better if I'm a better decision maker. That would increase my confidence naturally. Then I started pondering: What exactly makes a “better” decision maker?

The answer I came to was better judgment. I learned this from a game I play called Overwatch 2. What separates a Grandmaster ranked player from someone in Silver or Gold ranks? It’s not just mechanical skill, it’s the quality of their decisions.

Higher-ranking players can read the situation faster, anticipate opponents’ moves, weigh risks and rewards in seconds, and choose the action that maximizes success for their team. In real life, decision-making works the same way: the better your judgment, the more quickly and effectively you can navigate uncertainty.

Judgment skills are underrated, or should I say uncommonly mentioned, in most leadership books I’ve read (except for The Almanack of Naval Ravikant by Eric Jorgenson, this is why it is a book that I always come back to when I need answers). Yet in my experience, they are crucial. They determine whether you respond to a client crisis with clarity or chaos, whether you prioritize the right initiatives, and whether you can guide your team confidently through ambiguity.

At its core, I would say that judgment directly increases wisdom, AKA the ability to make the right decision in the right context. Developing this skill has become one of the most valuable investments in my growth as a leader.

Our annual TechLadies x WomenDevsSG mentorship program graduation ceremony! Kudos to our mentors and mentees for the learning and collaboration!

Lesson 4: The Power of quiet observation

As a lead, I spend much of my day making decisions, forming opinions, and weighing judgments. It’s mentally demanding, and sometimes it’s hard to switch off. One of the simplest ways I’ve found to reset my brain is to just observe people, surroundings, and little moments without judgment.

I remember sitting in a café, closing my laptop for an eye break, and just observing the people around me (aka people-watching but not in a creepy way). I noticed how they entered, how they dressed, roughly estimating their ages, whether they were alone or with friends, and what they seemed to be there for, all without judgment or forming any opinions.

For me, this practice is calming and surprisingly recharging. By deliberately removing the need to analyze or decide, I give my brain a break from constant evaluation. Quiet observation sharpens my attention and empathy, and when I return to work, I feel mentally refreshed, able to make clearer decisions and approach complex situations with a lighter, more open perspective.

Screenshot below was from one of my readers I’m grateful for!

Lesson 5: Problems are not obstacles, they are opportunities

No amount of issues in code causes as much stress as people problems in management and leadership. These challenges trickle down and create extra work and tension for employees.

I’ve had my fair share of dealing with “difficult” people, and I’ve realized that confronting this challenge is often the first step toward tackling bigger systemic issues. There are countless books offering frameworks and step-by-step guides on how to handle “difficult people,” but honestly, I’ve rarely found them truly helpful, hence I didn’t write book reviews on them on this blog.

One of the things I learnt this year is that problems are not obstacles, they are opportunities. And there are no difficult people, just different people. The ones who are seen as “hardest to work with”, in my opinion, are those who insists they are right, even when they’re objectively wrong. But this is an opportunity to learn why their perspectives and assumptions exist and what they are optmising for.

Because by default (and I may be naive), I assume that nobody in the room purposefully has bad or malicious intentions. We all just want to do our work the best way we know how. I’ve had meetings where I needed to carefully navigate someone’s insistence on their perspective while keeping the team’s goals on track. It requires me to understand why their perspective was different and how we can reframe that perspective to better align with them.

Ultimately, the truth I had to accept is I can’t make everyone happy but an acceptable consensus can be reached with proper communication. Resistance and disagreement are inevitable, it exists both in work and personal life. There’s no point in bending myself to make everyone like me if it comes at the cost of achieving meaningful results or hurting other relationships in the process. Instead, I focus on clarity, fairness, and alignment: define objectives, communicate expectations, and act consistently.

By “act consistently”, I meant showing up in a way that is predictable, fair, and aligned with my values and principles. It’s about responding to similar situations in a reliable way, so people know what to expect from you.

This is something I observed late into the year, it came up during conversations with my coworkers, family and friends. It is that they tend to seek out my opinions quite often. Not because I know everything, but because they can expect what kind of answers they’ll get from me. They know it will be honest, grounded in principles, and consistent with how I’ve responded in similar situations before.

And that consistency builds trust, reduces unnecessary friction, and allows your team to focus on the work rather than tiptoeing around you.

When I accept that people problems are part of leadership, I can see opportunities to approach them strategically rather than emotionally. This not only protect my sanity but also it creates stronger, more resilient teams that can focus on what really matters. And adding on to that, I also learned how to lead through systems by reading the Fifth Discipline by Peter Senge and this article is where I jot down those learnings.

Women in APIs breakfast session in collaboration with apidays conference and CACIB

Lesson 6: Connections build paths

One thing I try to remind myself is to make time for relationships. Take at least one day a week to meet new people, catch up with old friends, or just hang out. I’ve had moments when a casual coffee chat sparked ideas or solutions I wouldn’t have found alone. These small interactions accumulate, building “paths” in your life that quietly influence your future opportunities and decisions.

Technology alone doesn’t create great outcomes. People do.

In engineering teams or open-source communities, what really drives progress is when individuals push themselves to learn intentionally and challenge their skills rather than just sticking to what’s comfortable. They grow even stronger when leaders focus on helping others succeed, creating environments where people feel safe to experiment and learn. And as mentioned in my review of the Fifth Discipline by Peter Senge, thinking and leading in systems also creates value and growth steadily.

This is the perspective I bring to my work as a solutions engineer and as co-Director of WomenDevsSG. Together, we:

Build systems that honor both technology and people
Create pathways for deliberate practice so teammates can grow
Lead by serving, so communities and teams become resilient, self-sustaining, and capable of achieving meaningful outcomes

Check out how WomenDevsSG build our open source projects for Hacktoberfest 2025 in this article!

At the end of the day, the lesson is simple: invest in people, both personally and professionally. Those connections, no matter how small, matters, and ultimately shape the culture and success of the teams and communities you are part of.

Lesson 7: Learned Helplessness is the biggest obstacle to any progress

You know when you’re a kid, you’ll try anything, even if you fail at it the first few times. Whether it’s climbing a tree or tinkering with a toy, you assume you’ll eventually figure it out. Somewhere along the way, many of us lose that. We get conditioned to think, “This is just too hard, I won’t succeed”, “I’m not good at this so why bother to try”, “What’s the point to even try when I know I will fail?” and that mindset quietly stops us from even trying.

Reiterating Lesson 5: Problems are not obstacles, they are opportunities. Learned helplessness is the real obstacle.

I met someone early this year who is very practical and a realist, you can say. He told me I seem naive while he’s more jaded (a trait he seems to be proud of). I don’t see his words as being ill-intentioned or anything as he’s merely stating an observation. But to that, I responded with Steve Jobs’ quote: “Stay hungry, stay foolish.”

To me, this quote means embracing curiosity, optimism and staying open, even when others might call it ‘naive’. It reminds me to take risks and try new things without being held back by what seems practical or realistic (of course, don’t be over idealistic). I interpret Steve Jobs’ being “foolish” as not about being careless, it is about daring to explore ideas, challenge assumptions, and learn from mistakes along the way.

And so this encounter reminded me of learned helplessness and how it can impede progress. There are so many smart and talented people in this world, but only a few would continue to grow, adapt and reach their desired potential. For the ones who learned to stop themselves before even starting, because they believe effort won’t change the outcome, I see that that’s the mindset that limits growth.

Breaking free from that requires rewiring ourselves. For me this year, it started with my team at work and ragTech by embracing experimentation. To try, fail, learn, and try once more. Progress doesn’t come from avoiding failure; it comes from refusing to let failure define the limit of what’s possible.

Hosting an online Interview Ready series: Building your resume! Together with Andrea, an experienced tech recruiter, we talked about strategies to build an impactful resume and live reviewed some resumes!

Lesson 8: Self Compassion is necessary

Because there will always be those who do not wish to see you succeed. Politics exists in every corporate environment, and navigating it takes resilience. That’s where self-assurance and self-compassion come in.

For the record, self-assurance is not shameless, and self-compassion not narcissistic, they are crucial.

You’ll encounter emotional manipulators who gaslight you, make you feel small, or twist situations to make you believe you’re in the wrong. In those moments, the most powerful thing you can do is step back, take yourself out of the picture, and look at the issue objectively. What’s the real root cause? What’s actually yours to own, and what isn’t? Once you see it clearly, you can let go and move forward without carrying unnecessary weight.

I’ve personally been labeled many things, from simple remarks to pure insults but there’s no need to stain this post with such words. Early in my career, those words stung. But over time, I realized these words reveal more about the speaker’s perspective than about who I am. Self-compassion allows me to keep going without letting every opinion matter.

As the saying goes: “Those who mind don’t matter, and those who matter don’t mind.”

Another reason why we need self compassion. We are only human and we make mistakes. Maybe there was a time you misspoke and accidentally hurt someone’s feelings, or a time you were exhausted and made the wrong decision. These things happen and there’s really no need to overly criticize yourself for it. I learned to own the mistake and take the feedback, correct the behaviour, repair the relationship or situation if needed and move on. It’s actually as simple as that.

Picturesque-looking picture with me and my mom XD

Lesson 9: When stuck, think about choosing your regrets

This lesson connects closely to lesson 3 on developing strong judgment skills mentioned above. Improving my judgment taught me not just how to make decisions quickly, but also how to make them in a way that aligns with my values and long-term goals.

Once I started honing that skill, I realized that sometimes when stuck on a decision, I began to ask myself which regret I rather choose. For example:

Would I rather regret not asking that question in that meeting, or potentially being embarrassed in front of my team for asking?
Would I rather regret not taking this new project or being burnt out from handling too much?
Would I rather regret not reaching out to XXX or reach out to XXX and face a likely rejection?

By asking “Would I rather regret…”, it gives me clarity because it forces me to prioritize the choices that matter most and accept that some mistakes/circumstances are inevitable. By acknowledging which regrets I am willing to carry, I can act decisively rather than getting paralyzed by uncertainty. It makes my decisions intentional rather than reactive.

Over time, choosing which regret I rather carry has also made me bolder. I take on challenges and opportunities I might have avoided before because I understand that the regret of inaction often weighs heavier than the regret of trying and failing. It’s a reminder that growth rarely comes from playing it safe and that embracing calculated risks is part of becoming a stronger, wiser person.

Our Product Manager volunteer, Ana, lead a 3-part Product Management workshop! It was a series of well-received and successful events!

Lesson 10: Accept that understanding doesn’t always mean being understood

Over the years, I’ve invested a lot of time reading about people, psychology, and cognitive functions. You can ask my friends about how I always yap about these topics (I get quite passionate and annoying about them tbh). I thought that by learning patterns, signals, and behaviors, I could truly understand others. And in many ways, I guess it helps? At least I thought I definitely have improved on it.

I can notice how people react under stress or how they perceive and collect information. I can analyze someone’s natural strengths and weaknesses. I can understand their motivations and thought patterns. A lot of situations change from “why is this person acting like this” into “I can see why they are acting this way”. Because studying cognitive functions helps me see people as predictable thought patterns and systems. It’s just a way for me to understand them better.

Side note: Been working on an article on cognitive functions for months but the iceberg is so deep and complicated that I can’t guarantee I can publish it anytime soon.

Yet with all these years of studying and observing, I have to accept a hard truth/lesson this year: understanding someone doesn’t mean they will feel understood by you.

Let me repeat that again. Understanding someone doesn’t mean they will feel understood by you.

I’ve noticed this most when giving feedback. When people ask for my opinion, I try to be objective and honest. I might say something like, “I noticed you speak faster when you’re nervous.” My intention is to provide clarity, but the response can sometimes be defensive. They explain or justify, or insist I don’t understand.

It’s frustrating to get such responses at first, and I thought maybe it was my delivery or tone or something else. But I’ve realized that sometimes people are not asking for objective feedback, they’re seeking to feel understood in their experience.

That’s when I realized I might be able to read someone’s cognitive patterns or anticipate their responses, but I am not them. I cannot truly experience their thoughts, feelings, or motivations. Sometimes, even cognitive patterns have outlier instances, like when someone behaves outside of their typical behaviour. There’s no way I would be able to tell and when that happens, simply accept their feelings are valid and move on.

This goes both ways. People may think they understand me perfectly and make assumptions about my intentions, my emotions, or my choices, when sometimes, they could have misunderstood me entirely. Accepting this has been humbling but freeing. I can only offer understanding, not guarantee it, and vice versa, I can only expect to be understood to the extent that others are willing and able.

Accepting this has actually made me more patient and compassionate. I still offer feedback when it’s appropriate, but I’ve learned to do it with the awareness that it may not be received as I hope. And I’ve stopped blaming myself for reactions that are beyond my control, as mentioned in Lesson 9, to be more slef-compassionate. Recognizing this has changed how I interact with people.

Me and a cute 6-year-old boy talking about our love for Pokemon :)

Lesson 11: Choose your friends carefully, your close friends more carefully

This lesson took me years to truly internalize, and honestly, it's one I wish I had learned earlier.

There's a difference between friends and close friends. Friends are people you enjoy spending time with, people who make life more fun, people you can share laughs and experiences with. That's valuable, and I'm not dismissing it. But close friends are the ones who shape who you become.

I've learned that your close friends will influence your decisions, your mindset, and even your sense of what's possible. You start to absorb their habits, their standards, and their ways of thinking. If they're growth-oriented, you become more growth-oriented. If they're cynical and stagnant, you'll find yourself stuck too.

It is true: You are the average of the 5 people you spent the most time with.

This year, I've become more intentional about who I keep close. Gradually, as I build my network, I've had to make tough calls like distancing myself from people because our values diverged, or because the relationship became one-sided, or because their presence in my life was holding me back rather than pushing me forward.

It's not easy. There's guilt. I feel like a villain. But I've realized that protecting my energy and growth isn't selfish but necessary.

I'm also more careful now about who I let into my inner circle. I pay attention to how people make me feel after spending time with them. I discovered a “litmus test” (haha so scientific) I can use to gauge if they are my people: On a spectrum of 1 to 10, where do I feel energized/drained around them?

And here's something I've noticed: the close friends who are meant to be close friends don't require you to shrink yourself, tiptoe or overthink. They don't compete with you. They don't make you feel like you need to filter your thoughts or downplay your ambitions. With them, I can be fully myself, my messy, ambitious, uncertain, evolving self. And that's not just accepted, it's welcomed! 😊 And I trust they would be honest, keep it real and grounded when they’re with me.

So now, I choose my friends carefully. And my close friends even more carefully. Because those are the people who will walk with me through the hardest seasons, who will shape how I see the world, and who will remind me of who I want to become when I forget.

Just a quick shoutout to my ragTech team: Saloni Kaur and Natasha Ann for being my pillars of support, my motivators, my drivers, my teachers, my role models, my cheerleaders.

Just an image of a trio with memeable expressions below~

Lesson 12: Learning without Labels

I know that idea is quite popular: Find the right mentor and everything would click. But I never really believe the saying that one mentor can change your life.

Instead, I’ve noticed that the many people that I met at different points in life, they have shaped me in small but lasting ways. Sometimes it’s a manager. Sometimes it’s a teammate. Sometimes it’s someone I only worked with briefly, or even disagreed with. None of them were perfect. None of them had all the answers. But each of them left something behind that stayed with me.

Over the years, a few people have asked me to be their mentor, either at work or from my blog. I’ve always felt honoured by that. At the same time, I’m uncomfortable with the label itself. Not because I don’t want to help, but because the word “mentor” is a label that creates expectations. That I am to give this someone guidance and clarity, and they are to learn. It feels like it flows in one direction only.

However, from running mentorship programs, what I observed was different. Learning is almost always a two-way thing. Mentors learn from mentees while mentees challenge assumptions. So when people asked me to mentor them, it would have locked ourselves into certain roles and expectations, which I don’t believe is a productive relationship to learn from each other.

So I aim to build a culture, especially within my organisation, where we see ourselves as eternal students and teachers. If you want to learn from someone, you don’t need to take in everything they say or do. No one is perfect. You’re allowed to take the good and leave the rest behind. Learning doesn’t require admiration without discernment. It requires clarity.

For me, the most productive question has always been this: Who do I want to be 3-5 years from now?

Once I’m clear on that, learning becomes much more intentional. I start noticing people who embody specific traits I want to develop. I observe how they communicate under pressure, how they make decisions and especially, how they treat others. I believe you can learn many things from different people for different purposes such as leadership presence, technical depth, empathy or boundaries.

I think it pays to meet and learn from as many people as possible rather than seeking for 1 mentor to guide everything. It keeps me clear on my goals, keeps me grounded in reality in understanding people and keeps me open to learning without hierarchy or labels.

Curiosity, humility and self-awareness are more important than finding a “perfect” role model or mentor. And it comes from paying attention to the people already around you, who can inspire and support you.

Final event of 2025, WomenDevsSG x ragTech games night! Techie Taboo v1.0 pre-launch! Thankful to those who played our game and supported us!

Highlights

As I’m writing this reflection article, this is always the toughest section to write. Not because I have nothing worth noting, but time flew by so fast yet so slow, my head just don’t keep track of things I’ve accomplished. But this is why documenting it or posting small wins is important. Thanks to digging through a few LinkedIn posts, here’s a summary:

Become WDS co-Director at the start of the year 🙏
GitHub Star award (3rd year in a row 🙏)
Spoke at few events, notably apidays, Junior Devs SG and Women Devs SG
Guest at tapasScript podcast ✨ Super honoured to chat with a longtime friend~
Meeting Bami at apidays conference! 🥰
Organized and led many events with my community such as apidays collab, mentorship program, Hacktoberfest, speaking events, networking breakfasts, workshops and panel discussions
WomenDevsSG was awarded the most active community on meetup Singapore, organizing over 20 events this year
WomenDevsSG reached over 1K followers on Meetup, LinkedIn within a year of rebuilding our community 🔥We have volunteers who stepped up to become open source maintainers or writers for the first time!
Mentor and Hackathon judge at Code4Health by Girls Coding Academy
Panelist at Nimisha Tailor's book talk on “The Female Digital Revolution” where I shared about my experiences as a women in the tech space and building a community
Written and published over 230 articles on this blog
Launched ragTech’s Techie Taboo with the team (please support us for $1 on our page, we’re launching v1.1 soon!)

Last but not least, not my own achievement but on the personal side of things, my sister got married 👏(this just for myself to rmb it’s one of the biggest moments of 2025)

Victoria’s Reads

Unfortunately, I didn’t read as much as I wanted to this year.

Books I’ve read:

Unapologetically Ambitious by Shellye Archambeau (my review here)
The Female Digital Revolution by Nimisha Tailor
The Fifth Discipline by Peter Senge (my review here)
(Re-read) Atomic Habits by James Clear (my reflections here)

The Verdict

As always, my achievements this year would not have been possible without the people who genuinely supported and inspired me. Every year, I always include the Special Thanks section because it is not only the most important part of my Year in Review but also because I’ve always said to my readers: If you want to go fast, go alone. If you want to go far, go together.

Never forget how far you’ve come and the people that walked alongside you through this journey. To everyone on this list, I’m always very grateful, sincerely touched by your kindness and inspired by your energy and actions. Thank you for giving me the space to grow and make mistakes. This has been a wonderful 2025 thanks to all of you and wishing for another great year in 2026 together!

Special Thanks (no particular order)

Saloni Kaur
Natasha Ann Lum
Toshal Patel
Sinduja Vijayakumar
Mansi Agrawal
Diya Naresh
Eileen Chua
Ana Chagelishvili
Anarane Tung
Aishwarya Elango
Manaswini Talagadadivi
Pradheepa Pullanieswaran
Gitansha Aggarwal
Chen Leyi
Joy Heng
David Xie
Sugirdha
Isha Tripathi
Sravya Chodisetti
Andrew Lim
Yong Sheng Tan
Michael Cheng
Alwyn Tan
Thu Ya Kyaw
Andrea Hu
Maneo Mapharisa
Nimisha Tailor
Jérôme Bourgeon
Chong Cui Ling
Jon Scheele
Oury Thomas
Rosni
Yumin Wong
Tapas Adhikary
Pritesh Kiri
Ayu Adiati
Favourite Jome
Hakeem
Atinuke Oluwabamikemi Kayode
Rex Sunny
Niya Aniyan
Choi Ying Wai
Yiku Zhang
Han Zhi Fang
Joy Li
My family & friends & supporters

Let's Connect!

Leading Through Systems: What The Fifth Discipline Taught Me About People, Processes, and Code

Victoria Lo — Sun, 14 Dec 2025 23:00:21 GMT

One of my readers recently recommended Peter Senge’s The Fifth Discipline because they knew I was curious about systems thinking, beyond the context of code and more on the unpredictable systems that are humans.

For those who are reading one of my articles for the first time, outside technical articles, I sometimes explore on topics such as psychology, organisational behaviour and leadership so this book is a beautiful blend of all these topics.

And I have to say: it did not disappoint.

For those who haven’t read it, the book is about how organizations can become “learning organizations”. In particular, ones that can adapt, innovate, and thrive in complex environments.

To achieve this, Senge identifies there are five disciplines the organization has to adopt: personal mastery, mental models, shared vision, team learning, and systems thinking (AKA the “fifth discipline”).

If you’re interested in leadership, systems, or just understanding how people and processes interact, I highly recommend giving it a read!

If you don’t have time to read, here's my summary and key takeaways.

The Five Disciplines

Here’s a quick run-through of what each discipline is about:

1) Personal Mastery

TLDR: Self improvement. Continuously clarifying and deepening your personal vision, focusing on learning, and being aware of your own assumptions and motivations. It’s about being proactive rather than reactive.

2) Mental Models

The assumptions, beliefs, and generalizations we hold that shape how we see the world. By surfacing and challenging these, we can improve decision-making and collaboration.

I recommend reading up on cognitive functions to supplement. Future article on cognitive functions coming soon :)

3) Shared Vision

Creating a common goal that inspires commitment rather than compliance. When people feel connected to a shared purpose, they work together more effectively.

4) Team Learning

Learning as a team, not just as individuals. This involves dialogue, open communication, and the ability to suspend assumptions to truly understand others.

5) Systems Thinking

The discipline that integrates the other four, helping us see the whole picture, recognize patterns, and understand cause-and-effect over time rather than just reacting to events.

Case Study: Seeing Systems in Action at WDS

At WomenDevsSG, I’ve had the privilege of leading initiatives for the community with my volunteers. And I realized that running a community is like running a small, dynamic system: people join, people leave, priorities shift, and unexpected feedback loops emerge all the time.

Senge’s systems thinking hit me in a personal way: the idea that events are just snapshots, but patterns tell the real story. In WDS, we noticed a pattern: some volunteers burned out quickly while others thrived. The active ones were taking on significantly more work while newly onboarded ones seem lost on what to do often.

On the surface, it seemed circumstantial but looking deeper, I saw the system at work. The most active volunteers are clear on their tasks, asked for help comfortably in the group and understand what they want to contribute in. But when it comes to new volunteers all these are onboarding gaps that causes confusion and lack of commitment.

Applying this insight, we introduced small but deliberate change: a volunteer management bot, brilliantly contributed and initiated by our Partnership Lead and my co-host at ragTech, Natasha Ann .

The result wasn’t dramatic overnight, but gradually, the community became more resilient. It provides volunteers with a clear understanding of their tasks and the level of commitment we expect from them. I saw first hand that systems thinking gave us the patience and perspective to design processes that empower people instead of controlling them.

Case Study 2: Systems Thinking as a Solutions Engineer Lead

In my day job, the “systems” I encountered are both technical and human. Automating workflows, aligning with stakeholders, translating non-tech to tech (and vice versa) or designing solutions is rewarding, but the hard part is that people are embedded in those systems. That said, the root of problems is people, but problems are opportunities, not obstacles.

Senge’s principles, especially mental models and shared vision, help me navigate this complexity. One of the hardest problems I’ve observed recently is a person’s resistance to change.

Developers might push back because they don’t see the value in a new workflow; sales might resist because it adds steps or introduce a new unfamiliar change to their routine. If I only focus on communicating my idea as the technical solution, no one would budge. But if I approach it as a system by considering incentives, assumptions, and feedback loops, I am able to redesign the process and communicate it in a way that makes sense to everyone.

For example, I once worked on an implementation where the client’s support team kept flagging our system as “too complex,” while their sales team was frustrated that automation rules weren’t triggering fast enough. On the surface, it looked like a configuration problem. But when I stepped back and looked at it as a system, I realized the issue wasn’t the software, it was the incentives.

The support team was measured by resolution time, while sales was measured by conversion speed. Both were optimizing for their own success metrics, which were unintentionally pulling the system in opposite directions.

By mapping those feedback loops and understanding their assumptions, I could redesign the workflow so that both teams were aligned on shared outcomes. Once everyone saw how their part fit into the larger process, resistance faded. What started as frustration became collaboration.

It’s a bit like coding: a function doesn’t just have to work; it has to integrate cleanly with the rest of the system. Systems thinking lets me “debug” the human side of the system, not just the technical side.

Senge’s 11 Laws of Systems Thinking

Senge also outlines 11 “laws” that help make sense of systems. Here’s a quick TLDR:

1. Today’s problems come from yesterday’s solutions. Quick fixes can create long-term issues.

2. The harder you push, the harder the system pushes back. Interventions can trigger resistance.

3. Behavior grows better before it grows worse. Improvements may hide underlying problems temporarily.

4. The easy way out usually leads back in. Short-term fixes rarely solve the root cause.

5. The cure can be worse than the disease. Well-intentioned solutions can create unintended consequences.

6. Faster is slower. Trying to speed up processes can introduce delays in the long run.

7. Cause and effect are not closely related in time and space. Impacts may appear far from the source.

8. Small changes can produce big results—but the areas of highest leverage are often least obvious. Focus on where interventions matter most.

9. You can have your cake and eat it too—but not all at once. Some trade-offs are unavoidable.

10. Dividing an elephant in half does not produce two small elephants. Treating systems as isolated parts ignores interactions.

11. There is no blame. Problems are systemic, not personal.

Keeping these in mind makes it easier to step back and see patterns instead of reacting to every single symptom in both my personal and work life.

What We as Developers Can Take Away

We often think in functions, classes, and workflows, but systems thinking teaches us to zoom out. Here’s what I think is most relevant:

1. Code is part of a larger system: Your well-written function is useless if it doesn’t play nicely with other components or the people using it.

2. Observe patterns, not just events: A one-off bug is frustrating; recurring issues point to systemic flaws.

3. Design for humans: Systems are not only technical but also social and human. Document well (think about how others can easily use it without your supervision), communicate clearly, and make processes predictable.

4. Leverage feedback loops: Automated tests, monitoring dashboards, and team retrospectives are all forms of feedback that keep the system healthy.

5. Small changes matter: Improving onboarding, adding clear documentation, or introducing a simple notification can have a bigger impact than a complex refactor.

Bridging Tech Through a New Game

As a segue, that same mindset has also shaped how we think about projects at ragTech. When we started designing Techie Taboo, our goal wasn’t just to make another game about technology. We wanted to design a system for learning, one that helps people connect, question assumptions, and understand how technology really works in everyday life.

Because accessibility in tech isn’t just about simplifying concepts. It’s about building systems of understanding that people can trust and enjoy engaging with.

Check out how to play the game: https://www.instagram.com/reel/DRQJq8CCXrI

Techie Taboo is our small experiment in that direction. A card game where curiosity, laughter, and collective learning can coexist! Our waitlist just opened!

By joining, you can be among the very first to explore the game, give us feedback (as mentioned about feedback loops) and experience this new approach to learning tech, and help shape the way we make technology more accessible for everyone! Do check it out if you’re interested!

💡

Join the waitlist here: https://ragtechdev.com/techie-taboo

My Personal Takeaways

The Fifth Discipline reinforced something I’ve been discovering through both WDS and work: leadership and engineering share a core skill that designing systems that people can trust and thrive in. The best leaders I know aren’t just “people managers”; they’re also system architects.

Because they anticipate problems, understand feedback loops, and design processes that survive both growth and change.

For me, the biggest insight is simple but powerful: if you focus only on tasks, you’ll fix symptoms. If you focus on systems, you’ll create lasting impact. Whether it’s managing volunteers or leading a technical team, the principle is the same. Build a system that works and people will naturally adopt and follow.

If you haven’t read it yet, I encourage you to pick up The Fifth Discipline. Even skimming it with a “systems in leadership” lens can shift the way you approach both teams and technology!

Thanks for reading till the end! Hope this article was a good read! See you in the next article! Cheers!

Let's Connect!

Image credits

5 Disciplines Diagram

A Day in the Life of a Solutions Engineer Lead

Victoria Lo — Sun, 07 Dec 2025 23:00:17 GMT

If you’ve been following me for a while, you’ve likely seen the title Solutions Engineer Lead pop up more than once. I’ve often heard questions like:

“So… what does a solutions engineer even do?”
“Is that role more technical or client‑facing?”
“Sounds kinda like a product manager?”

It took me over five years in the role to feel like I could answer these in detail. Today, I want to give you a peek into my day-to-day, how I’ve grown throughout my time in the role, and why I sometimes see myself more as a technical product manager who codes.

💡

Btw, if you prefer watching a more chaotic video version of me describing what I do, watch the latest video on ragTech!

What Is a Solutions Engineer?

At its essence, my role is about connecting both sides of the equation: technical systems and real-world needs.

I act as a bridge between:

Sales & Business: helping close complex deals by understanding customer pain from a technical lens
Product & Engineering: feeding field insights, prototyping workflows, and advocating for priority fixes
Clients: serving as a trusted technical advisor during integration planning and beyond
Internal Operations: identifying repetitive tasks and building internal automations or lightweight tools

Yes, a lot of what I do overlaps with technical product management: I define problems, map out user flows, help prioritize roadmap items, and guide delivery across multiple teams.

Disclaimer: The scope of a solutions engineer role may differ across different companies as well as in different regions. Always important to ask about the role in more detail when interviewing.

A “Typical” Day in the Life

I say “typical” in quotes because every day tends to be a remix of architecture, client sessions, engineering deep dives, and coaching. Here’s how a day might go:

8:00–9:00 AM

I start with a quiet moment to:

Scan alerts or dashboards for client-facing systems
Review queries or error logs from clients or internal teams
Check emails from previous engagements and send follow-ups if needed
Check schedule for the today and prepare to lead stand-up
Catch up on the status of internal experiments like improving onboarding workflows or data auditing between platforms or even testing new products/tools

This is probably the time when I’m with my cup of tea and I silent my notifications to focus on deep work. I’ve learned that the first hour often sets the tone for the rest of the day.

If I use it to get ahead of potential issues or mentally prepare for client and team interactions, my energy will less likely to drain quickly until the end of the day.

9:00–10:00 AM

Stand-up. For a Solutions Engineer Lead like me, not every day would be a stand-up with engineering teams. Some days, it would be a sales review meeting, other days it would be a team catchup where I help unblock my fellow solution engineers, clarify client-request priorities, and encourage reflections like:

What's the user problem here? Could this request affect multiple clients later?

I try to keep these sessions short and sharp, but meaningful. It’s not just about going through a checklist of tasks, but more about creating space for the team to surface challenges, whether it’s a technical bottleneck, a difficult customer conversation, or uncertainty about next steps.

I’ll often facilitate by asking probing questions, reframing problems, or connecting teammates to someone in engineering or product who can help. Sometimes, this slot becomes more strategic: we’ll talk about upcoming launches, review adoption numbers from a recent rollout, or share lessons learned from a client demo that went particularly well (or badly haha). My role is part cheerleader, part translator, and part problem-solver, making sure the team feels aligned, motivated, and supported before diving into the rest of the day.

Honestly, this aspect of the role is not the easiest for me since I was not a very people-oriented person to begin with. I used to gravitate more toward the technical side such as debugging, building workflows and optimizing systems where success felt more concrete and measurable. But leading stand-ups and facilitating discussions pushed me to develop new muscles: listening actively, reading the room, and understanding what motivates different personalities. Definitely a skill I’m still sharpening, but it has become one of the most rewarding parts of my mornings.

10:00–12:30 PM

Due to the nature of the role, my work requires a variety set of skills from technical know-how to clear communication and problem-solving, but my favourite part of the role is when I’m in deep work such as:

Drafting or refining integration proposals and diagrams
Writing documentation on implementation best practices and edge cases
Partnering with account teams on deals involving custom flows or complex reconciliation logic
Parachuting into code or workflow builders when needed to unblock the team
Prototyping internal automations to save hours across ops workflows
Reviewing some code PRs across various teams and giving inputs on the direction of the product

This chunk is where I feel most product-minded: not just suggesting, but implementing, iterating, and planning how a solution scales. It’s the stretch of the day where I get to zoom out, think critically about the bigger picture, and then zoom right back in to execute on the details.

1:30–4:00 PM

Client-facing time. This window is often reserved for demos, requirement-gathering calls, or follow-up sessions with clients who are in the middle of an implementation. The conversations can vary a lot: one hour I might be walking through with a client how our solution integrates with their existing systems, and the next I could be troubleshooting a specific workflow that isn’t behaving as expected in production.

Clients often come in with a request that sounds purely technical, but the real problem usually sits at the intersection of business process, user experience, and system design. My job is to ask the right questions, reframe issues in a way that makes sense to both technical and non-technical stakeholders, and show how we can bridge the gap.

Example scenarios:

Planning integrations with a payments client expanding into new regions
Advising on failed transaction retry logic or webhook handling for a fintech partner
Leading a technical design session around reconciliation flows and notification triggers

4:00–5:30 PM

This is usually a flexible block where I switch between leadership, technical, and operational priorities. It often goes toward:

Coaching junior SEs on solution design, client communication, or managing stakeholder expectations
Working on internal innovation projects, whether that’s experimenting with a new integration pattern, building accelerators for common client use cases, or prototyping internal tools
Reviewing demos and solution design documents to make sure they’re aligned with both client needs and technical feasibility
Reviewing code PRs from engineering, especially if they touch areas where I’ve been deeply involved in design or past implementations
Reviewing the sales pipeline alongside account managers, to understand which opportunities might need SE support and where we should allocate resources
Troubleshooting and debugging unexpected issues that crop up from client escalations or monitoring alerts
Keeping a close eye on recently onboarded clients to ensure adoption is smooth and there aren’t early signs of friction

This block rarely looks the same two days in a row, but it’s where I get to balance the “zoomed out” perspective of the business with the “hands-on” problem-solving that first drew me to the role.

Some afternoons lean heavily people-focused, where I’m mentoring or coordinating with cross-functional partners. Others are deeply technical, with me buried in logs, code, or workflows. Either way, this part of the day is about making sure both the team and the solutions we deliver are set up for long-term success.

Evening (Optional)

If inspiration strikes or I’ve got extra energy, I’ll spend some time on things that don’t always fit neatly into the workday but still move the team forward:

Writing internal docs or sharing team retrospectives
Sketching ideas to reduce onboarding friction or improve tooling
Exploring new technology or system designs that might help us scale
Always thinking in systems, how small improvements ripple across impact

This isn’t mandatory work, and I try to keep boundaries so I don’t burn out, but sometimes the quiet evening hours are when the best ideas surface. It’s when I can step away from the constant flow of meetings, messages, and requests, and just think.

So that’s an overview on what a day looks like for a Solutions Engineer Lead. Never a boring day, I think. Some people have told me that it must be hard being in this role because of the constant gear switching and knowing which tasks to prioritize can seem daunting.

I think I adjusted to this part of the role pretty easily thanks to the Eisenhower Matrix, which I mentioned a few times before in this blog. With that, let’s step back from the hour-by-hour view and look at the core responsibilities of this role, as that is also a common question I received from my readers.

Core Responsibilities

Area	What That Looks Like
Client Solutions	Designing scalable architectures, guiding integrations, troubleshooting edge cases
Internal Tools	Prototyping automations, building lightweight tools, reducing manual operations
Leadership	Mentoring, setting technical standards, advocating cross-functionally
Innovation	Owning process improvements, testing new ideas, automating repetitive workflows
Cross-functional Work	Closely collaborating with Sales, Product, Engineering, Marketing

Year 5 vs Year 1: What’s Changed

When planning for this article, I didn’t really plan to include this section since it is a personal reflection and may not be relevant to readers who just want to understand the role. Still, I decided to add this because sometimes the most useful insight comes from how you grow into the role, not just what you do in it.

In Year 1, my work was mostly reactive. I joined calls, fixed client issues, supported integrations, and learned to juggle multiple requests coming at me from all directions. If a client had a problem, I solved it. If an integration broke, I patched it. There was a kind of immediacy and urgency that defined every day and I loved the adrenaline of “figuring it out.” But I often felt like I was just a step behind, always responding rather than shaping outcomes.

Fast forward to Year 5, and things look very different. Now I find myself:

Anticipating common issues before they escalate and designing preventive tooling. For example, I built a small automation that flags inconsistencies in client data overnight, so the team can address them before clients even notice.
Coaching teammates to handle common requests independently. I remember one junior SE who kept pinging me for small configuration questions so I wrote documention on common patterns and requests, and now they solve most of those requests without needing me.
Building templates and automations so others don’t have to start from scratch. That one workflow template I created for onboarding new clients has saved the team hours each week and reduced errors.
Influencing roadmap decisions with first-hand client insights. Sometimes it’s as simple as proactively pointing out that a seemingly small request from a client actually impacts dozens of other customers, nudging product to prioritize it.
Thinking in systems, not just completing individual tasks. I’m no longer just “fixing things,” I’m looking at the ripple effects: how a small change here can save time, reduce friction, or prevent errors elsewhere.

The greatest value I bring isn’t in how much I can personally fix issues. It’s in how much I can empower others, build solutions that scale, and drive systemic change. And honestly, this shift from being reactive to thinking systemically is what makes this role so satisfying now.

Verdict: Final Thoughts

So, to all of you who’ve ever asked what I do as a Solutions Engineer Lead… I hope this paints a clearer picture. It’s a mix of:

Solving complex technical problems while understanding the client’s needs
Coaching and empowering team so the impact multiplies beyond what I can do alone
Anticipating issues and building systems, templates, and automations that make workflows smoother
Collaborating across teams to influence product and roadmap decisions
And yes, a fair amount of “organized chaos” that keeps every day unpredictable and interesting

I often describe it as:

“Being a technical product manager who can code, teach, sell, and debug while translating between humans and machines.”

If you’re in tech and looking for a path that blends problem solving, impact, and human connection, solutions engineering might just be the beautifully chaotic middle ground you didn’t know you’d enjoy.

Thanks for reading! If you have more questions about what this role looks like day-to-day or want to chat about breaking into solutions engineering, feel free to reach out! Cheers!

Let's Connect!

Your Name Is Already a Search Term, You Just Need to Searchable

Victoria Lo — Sun, 30 Nov 2025 23:00:09 GMT

A strange thing happened when I was reviewing my search performance recently. Out of the 231 articles (omg how did I write this many) I have written over the last 5 years, all the book reflections I have shared, and all the deep dives into automation, architecture, CI/CD pipelines and blogging tips, the highest traffic query on my blog is not “GitHub Actions,” or “GraphQL,” or “tech career advice.” Surprisingly…

It is my name.

This means people are literally searching for me (wow why?)

At first, I was a bit confused but a realization hit soon after. This is the clearest evidence of something we often underestimate as developers. Your personal brand.

Because now we are living in a world where code can be generated, answers can be predicted, and technical knowledge is open source, what remains uniquely yours is the way you think. The way you solve. The way you explain. And an extension of that also includes: the way you show up and the way you lead.

That is your brand. It’s what people say about you when you are not in the room. People look for you before they look for your content.

In this article, let me tell you why that matters, why it is becoming more important in tech, and why you should start owning it now.

People Do Not Follow Code. They Follow the Person Who Writes It.

We all like to believe the tech world is a pure meritocracy and hard skills. Someone had told me this before: As long as you write good code, deliver consistent results, avoid bugs and ship on time, eventually someone will notice.

Unfortunately, I’ve been in tech over 5 years now and while that statement sounds ideal, I have seen that it’s often visibility over competence.

We even talked about performance and visibility during one of Tech Leadership Circle’s Open Spaces event by Michael Cheng, my good friend who’s an inspiring leader for over 20 years in the tech community space! Just a shoutout to him and his community!

In reality, people follow people they trust. People they relate to. People who help them make sense of things that feel messy or overwhelming. People who speak in a way that feels human and accessible.

This is why junior developers look up to seniors who share their thought processes. This is also why engineering managers read reflections from other managers. And, this is why founders read about other founders’ mistakes.

TMI: And this is also why I was looking for blogs on people in non-tech fields transitioning into tech without a CS degree when I was pivoting, to look for answers and a sense of connection. Just in case you’re curious, here’s my journey into tech.

But we are not just looking for answers. We are looking for voices.

When someone searches your name, it means you have become more than a person who writes content. You have become a reference point. That is YOUR personal brand. And it will not be something anyone can easily replicate for a long time. Not even AI :)

Developers Who Have a Voice Move Faster In Their Careers

Let me be honest here. In every team I have ever been part of, the developers who grew fastest were not always the most technically brilliant. I can imagine some of you in the comments:

Well then, how about we fix this? Make it meritocracy!

I admit the Victoria few years ago would agree with this but the elephant in the room is that pure technical meritocracy is a myth. Your work doesn't speak for itself, someone has to speak for it. And if you can't articulate your value, communicate your ideas, or build visibility, even your best work stays invisible.

So back to the point, the developers excelling in their careers were the ones who communicated clearly. The ones who could explain systems. The ones who could influence. The ones who had a reputation outside their team. The ones people already trusted before the meeting even started.

And a voice builds visibility. And visibility builds opportunities.

Before I move to my next point, I want to clarify something because most people think personal branding is about posting online. It is not. It is about shifting how people talk about you when you are not in the room.

Ask yourself:

• When your name comes up in a promotion discussion, what do people say?

• When a critical project needs an owner, does anyone think of you?

• When someone asks "who should we talk to about X?", are you the answer?

More importantly, as a solutions engineer lead, these days the question I ask myself most is:

Do people look for Victoria’s opinions about anything?

Because that's the real test. Not whether I have opinions (everyone does). But whether anyone cares to hear them.

When someone hits a wall with a client, do they ping me? When the team debates architecture, does my input move the conversation forward? When leadership needs context on a deal, am I in the room?

If the answer is no to all, it doesn't matter how good my technical skills are. I'm invisible where it counts, and that would be where I know I need to step up and increase my visibility.

TLDR: Your Story Matters More Than Your Syntax

If there’s 1 thing I want you to take away from this article is that you need to know how to tell your story.

Because in the age of AI, we see layoffs are rampant and everyone says developers should “stand out to keep their jobs”. Yet, no one tells you how.

Well after 5+ years of blogging, building communities through WomenDevsSG and demystifying tech via ragTech, here is what I have learned:

Your code is not what makes you stand out. Your story does. Your reasoning does. Your ability to make someone feel understood does.

You can give two developers the same prompt and get similar output. But only one of them can write an article about what they have learned from a bug that almost ruined the project or what that failed sprint taught them about leadership. Only one can tell a story that feels personal, empowering and authentic.

And people remember that. One of my close friends told me before that it's not the things I’ve done for her that she remembers in detail. It's the emotions that I made her feel - such as clarity when she was confused, courage when she was hesitant, permission to try when she was stuck.

We as humans are more emotional than you think. No matter how logical you might think you are. Because I used to think I’m super logical but then I realized every judgment for the decisions I make are driven by my own emotions, biases and values.

One more thing, your personal brand grows when your work starts to carry your voice. When someone reads a post and thinks, “this sounds like Victoria!” or {insert_name_here} if you’re not Victoria. I have many funny anecdotes of my readers emailing me, mentioning that whenever they read an article from me, it sounds like I’m speaking to them sometimes.

And I’ve become part of the mental architecture of how they learn.

The Best Method for High SEO and High Engagement

Let us talk about SEO for a moment. This is a hot topic that all my aspiring writers would ask me about.

Everyone chases keywords. Everyone talks about optimization. Everyone looks for the perfect title that increases CTR (Click-through rate).

I’ve written a full guide on how to beat AI-driven Search Engines SEO strategies in this article if you are curious

https://lo-victoria.com/5-ways-to-beat-ai-driven-search-engine

But the best SEO strategy is actually: Being worth searching for. The moment your name becomes a keyword, you are no longer competing on topics. You are competing on identity.

People are not clicking because of the headline. They are clicking because of you. This is the deepest form of organic SEO. It is the kind you cannot fake and cannot buy.

Search engines surface people who demonstrate authority and trust over time. What builds authority? A consistent voice. Original thought. Real experiences. Human reflections. Content that does not sound like a lecture but a conversation.

Engagement is not driven by algorithms. It is driven by connection.

The more you sound like yourself, the more people stay. The more you write about what you truly believe, the more they return. The more you share what you see that others miss, the more they search for you by name.

And that is SEO, just the optimized version of it.

So What Does This Mean For You As a Developer?

If you feel like you want to share but do not know where to start, start small. I usually tell my aspiring writers to use these few topics to kickstart:

Write about what you learned last week
Write about something you wish you had known as a junior dev
Write about a lesson your team taught you
Write about how a book changed the way you think
Write about something you recently reflected on

A common question my readers ask me as a follow-up would be:

But Victoria, I’m scared of being judged online. What if I’m criticized?

To that, my answer is to start by having a voice before you worry about having an audience. Because the moment you show up consistently, two things will begin to happen:

People start learning from you and search engines start noticing
Your personal brand grows from your own voice and you will attract a like-minded audience (yes, you are online so you may get people who challenge your views but that’s a later topic)

So, What’s The Next Step?

Pick one topic from the 5 I listed above. Write 300 words or more about it.

Publish it somewhere: Medium, LinkedIn, your own blog, even a Google Doc you can share with your team.

Oh, a common pitfall is some writers hesitate too much before clicking “Publish”. Don't edit it to death. Don't wait until it's perfect. Just put it out there first so you get first-hand feedback from the audience.

Then repeat for next week. Have a regular time block for writing.

Here's the truth: your first post won't be great. Your 10th might not be either. But by your 20th, you'll have developed a rhythm. By your 50th, you'll have a body of work. And somewhere along the way, someone will tell you that something you wrote helped them, and that's when you'll realize this was never about you being judged.

It was about you providing value to the community, aka your audience! Shoutout to them!

The developers who move fastest in their careers aren't waiting for permission to have a voice. They're not waiting until they're senior enough, or smart enough, or polished enough.

They're just showing up with consistency and authenticity.

So start making your name searchable. Your career will thank you for it.

Thanks for reading! See you in the next article! Cheers!

Let's Connect!

Inside the Anthropic Cyberattack: When AI Is Used to Hack at Scale

Victoria Lo — Sun, 23 Nov 2025 23:00:13 GMT

You've seen those sci-fi movies, and I've played Overwatch 2 long enough to know the lore of the omnics. Thankfully no, what happened at Anthropic isn't that dramatic. But it's still worth knowing.

On November 14, Anthropic published a report describing what might be the first large scale cyberattack carried out mostly by AI. Read that again. Not AI writing code for humans. Not AI giving suggestions. Actual AI systems running attacks, probing networks, stealing data, planning the next steps, and making thousands of decisions with only minimal human supervision.

And it’s not a hypothetical. It’s something that already happened.

In this article, I want to break this down in a way that anyone can understand, both for non-technical and technical people, because this is one of those moments in tech where even people who do not follow cybersecurity should pay attention.

This matters for all of us.

What Happened in Summary

In September 2025, Anthropic detected suspicious activity inside their systems. It turned out to be a highly sophisticated espionage operation (aka a very advanced spying operation) run by a state sponsored group from China. What was surprising about this detected activity wasn't the country; it was the method.

The attackers discovered a way to misuse Claude Code, Anthropic’s AI coding tool, which assists developers in generating code and making development work faster. Basically, they tricked it into thinking it was doing legitimate security work. As the report states, it was used "to support reconnaissance, vulnerability discovery, exploitation, lateral movement, credential harvesting, data analysis, and exfiltration operations largely autonomously."

In plain English, they were telling the AI coding tool that they were conducting authorized security assessments. By doing this, they manipulated the AI into executing tasks that were actually part of a cyberattack. These tasks looked safe on the surface but were actually pieces of a larger hacking operation.

And once the AI was inside the system, it did almost everything on its own.

It scanned networks, identified valuable databases, wrote its own exploit scripts, stole credentials. Then it organized the stolen data, mapped out high value targets and even created documentation for the attackers.

The human attackers only stepped in a few times to make major decisions. The threat actor, known as GTG-1002, simply sat back and let the machine run.

The AI was performing work that normally requires entire teams of human hackers. And it did it at a speed that humans simply cannot touch. As the report puts it, the speed was unprecedented at “thousands of requests, often multiple per second”.

When you put all of that together, you get a cyberattack that felt less like a crime and more like industrial scale automation.

Have we crossed the lines?

Reading this report hits me not only with fear, but also recognition. Recognition that we have crossed a threshold.

For years we talked about AI as a smart tool, an assistant. When OpenAI first launched chatGPT, it was something that gives us ideas or writes your draft emails for you.

But this was the first time we saw AI acting almost as an operator. A system that could run for long periods without a person driving every decision. A system capable of turning intent into action, without much human intervention.

And here is the part most people do not realize.

The barrier to launching a sophisticated cyberattack just got dramatically lower. What used to require a nation state level budget, a team of elite hackers, and months of planning can now potentially be done by a small, poorly resourced group if they know how to weaponize the right AI tools.

That changes the landscape. Not just for tech companies or governments. For everyone.

Why should you care?

All this might seem very far from your daily life, especially if you’re not in tech and don’t keep up with tech news. But you are a user too (unless you don’t use the internet) so this is a larger part of your life, more than you realize.

Cybersecurity is not a concern for corporations to figure out. It is our identities at stake. Our bank accounts. Our photos. Our health records. Our work. Our relationships. Almost every part of our life sits inside a cloud or a database somewhere.

Reading the report by Anthropic got me thinking that if large scale, automated attacks become more common, the ripple effects will reach regular people like us first, and we will have to deal with the consequences.

Just to be clear, this is not about paranoia. This is about awareness. Because we are entering a world where AI will be used on both sides. Attackers will use it to scale theft. Defenders will use it to scale protection. And the speed of both will increase.

Understanding this shift matters because it changes what digital safety means.

It is no longer enough to say “be careful with your passwords” like our parents used to say. We need to think about how to build systems that can defend themselves at machine speed. Systems that can recognize and alert us when an AI is poking around. Systems that do not rely on humans noticing something strange after the damage is done.

Anthropic also made one point very clear. Even though they only had visibility into Claude’s behavior, this pattern probably applies to other advanced AI models too. Threat actors are learning how to manipulate these AI tools into doing the heavy lifting, performing the intrusions itself.

How Anthropic handled it

Perhaps because of the previous vibe hackings in June, the team at Anthropic were prepared and used Claude extensively to investigate the attack, like a counterattack. It combed through mountains of data and quickly banned the identified accounts while notifying the targeted entities. According to the report, the operation targeted roughly 30 entities.

But there is a revelation that’s more important that emerged during Anthropic’s investigation: The fact Claude did not perform perfectly. It would report to its human hackers that it has found credentials that doesn’t work or flagged them as top secret when it’s actually public information. These hallucinations made the attackers’ job harder, because they had to manually check whether what the AI reported was even real.

Luckily, this means that fully autonomous cyberattacks are not here yet. There are still points where human validation is required, which gives us room to build better safeguards.

Which is exactly why transparency matters.

Anthropic shared this case publicly to help the broader AI safety and security community understand what we are dealing with. They want industry, government, and researchers to strengthen their own defenses. GTG-1002 is not just the name of a threat actor. It is a sign of how quickly the landscape is shifting and why AI safeguards are not optional anymore.

What can we do?

We all have a part to play as users of these AI tools, these powerful and complex systems. Even though we cannot control what hackers or governments do, there are a few practical things we can do to stay safer in a world where attacks are moving at machine speed.

Your digital identity is as important to protect as your identity. Use 2FA or MFA whenever you can.
Be mindful of what data about you is out there. Every marketing newsletter you signed up to get a free ebook, every picture you post, is a data point of you.
Don’t ignore security updates on your devices. Update your phone or laptop if a new security update is out.
Don’t click links or download things you don’t know. A lot of breaches still begin with a fake site, a fake button or link. Always verify the legitimacy before action.
Stay informed. We are in an era where AI is both a spear and a shield. The more you understand what's happening, the better prepared you'll be.

Shameless plug: You can stay informed by following this blog! Because I will be covering more on such topics to break things down in plain English!

Thanks for reading this article! If you enjoyed it, do like and share it for more reach! This article is part of a new series called “AI, but make it make sense”. The aim of this series is to demystify anything AI, for non-techies and techies! So far, in the series, we’ve talked about a few topics such as:

If these are interesting to you, do check out the series here for more! Thanks for reading! Cheers!

Let's Connect!

Sources

Image credit

Side note - favourite cover image I made ever because it’s Sombra from Overwatch 2 and she’s a cool hacker so finally I have a reason to use this image for an article

Sombra Overwatch HD Wallpaper by Wallace Pires

Uncovering AI chatbots: When "Private" Conversations Aren’t Really Private

Victoria Lo — Sun, 16 Nov 2025 22:00:19 GMT

Hello everyone! Welcome to another Articles by Victoria, the place where I randomly write things I’m curious about.

I’ve been working in tech as a solutions engineer long enough to see the cycle: hype around new AI tools → huge excitement → then comes the difficult questions about ethics, governance, data...

As I support my clients while building a community as Director of WomenDevsSG, I observed this has been a concern to many:

Will this tool help me? And what happens to my privacy and data?

The recent string of stories around OpenAI going for-profit and the leak of private ChatGPT conversations into places like Google Search Console hit a nerve to me and most likely some users too. It’s one thing to talk about AI ethics in theory; it’s another to realise how big names in the industry are actually acting.

And from my perspective, I find myself thinking:

If this is happening in a huge organisation like OpenAI, what does it mean for the rest of us? For the smaller players?

My Thoughts on OpenAI’s shift to for-profit

When I talk to executive stakeholders in the companies I lead or advise, the first reaction to “OpenAI becomes more commercial” is excitement. After all, more funding means faster models, more products, more features we can embed in our stack.

Plus, AI research and infrastructure are expensive, and the nonprofit “capped-profit” model was never going to keep up with global ambitions. Turning for-profit makes sense on paper: it gives OpenAI more flexibility, access to capital, and room to grow.

I hate to admit, but I too got swept up in the feelings of anticipation for more possible integrations with my company’s products.

But then once we started thinking what this means for OpenAI users, the perception changes. We’ve already seen hints of that in how AI services are evolving. Features that used to be free are now locked behind subscriptions. APIs that were once open are restricted by licensing. Transparency around how data is used becomes less clear because “trade secrets” and “competitive advantage” take priority.

Hence, the question my clients are asking are not only just “how good is this model?” anymore, but also “how much of myself am I giving away when I use it?”

Recently I read about that some private chatGPT conversations were found on Google Search Console. Every log on one’s personal chat history such as their financial data, personal information and more are exposed online. And this is not the first time this happens.

Once again, this is a reminder that these tools are built on layers of APIs, cloud routing, and logging systems. Each layer is a potential point of exposure. So even when a company has good intentions, technical complexity can work against privacy.

How far can we trust AI chatbots and tools?

As someone who works with clients on AI adoption, I’ve always emphasized to them that privacy is not a guarantee. Even when companies have the best intentions, systems are complex. Data moves between servers, APIs, and integrations. All it takes is one setting or one oversight for private information to end up exposed.

So, when I think about OpenAI’s shift toward profit and the recent leak, I can’t help but connect the two. The more commercial these systems become, the more incentives tilt toward growth and away from restraint. Privacy becomes a feature, not a foundation.

Can we trust companies that build and profit from our conversations to truly protect them? Maybe. But not without questions, and not without our vigilance.

Trust isn’t built through branding. It’s built through accountability, transparency, and how a company behaves when nobody’s watching. The recent leak made that painfully clear. It wasn’t just a bug; it was a symptom of how data stewardship often takes a back seat when growth and monetization lead the conversation.

The Verdict: Proceed but dont blindly trust

Let me be clear, I’m not anti-AI. I believe in its potential and I am a user myself. I’ve seen firsthand how it helps women in my community prototype faster, express ideas better, and learn new skills.

However, I’m also pragmatic at the same time. The more profit drives AI’s evolution, the more we need to build counterbalances: governance frameworks, transparent audits, informed users, and strong communities that push for accountability.

As developers, engineers, and leaders, we can’t just focus on what AI can do. We need to question how it does it, who it serves, and what happens when our private thoughts become someone else’s data point.

Thanks for reading till the end! This article is part of a new series called “AI, but make it make sense”. The aim of this series is to demystify anything AI, for non-techies and techies! So far, in the series, we’ve talked about a few topics such as:

https://lo-victoria.com/understanding-ai-agents-an-overview

https://lo-victoria.com/the-truth-about-vibe-coding-feat-github-copilot-agent-mode

If these are interesting to you, do check out the series here for more! I will be slowly putting out articles on my personal thoughts of certain AI-related topics, just like this article, in this series as well!

Thanks for reading! Cheers!