Time flies—it has been 2.5 years since relocating from Singapore to Australia and 1.5 years at an Australian SaaS company. Though I had experience moving from China to Singapore 10 years ago, this transition took longer to adapt to. It was not only because I became a parent, but also because the cultural differences between Australia and Asia are more significant.

A Challenging Time

My husband received a job offer in Sydney just before Covid while I was working at the fast-growing Shopee. Back then, without our little one, everything seemed simpler, and we eagerly decided to embark on our next adventure.

However, Australian visa processing was suspended for over two years. Like many couples, we welcomed a new family member during this special time.

When we finally arrived in Sydney, we faced multiple crises: soaring rental prices, doubled petrol costs, and a shortage of childcare spots due to increased demand from the childcare subsidy policy, labor shortages, and higher birth rates. This forced me into an unwanted year as a housewife, watching our savings dwindle each month.

When I finally secured childcare and started job hunting, both the market and I were at the low time. I had two years of broken sleep and minimal coding practice. Layoffs were still common and opening head counts were still little.

SafetyCulture offered me an opportunity to excel. Later I learnt that I was their only front-end hire in that year.

On-boarding Challenges

Our engineering team is divided into customer-facing teams and platform teams. All the teams are quite lean. Inevitably, a team sometimes lacked dedicated platform engineers when people were sick, on leave, or positions remained unfilled.

I was replacing an engineer who had returned to Europe. She could only onboard me remotely in my evening hours or asynchronously. Other the engineers were either lacked context about the six-year-old messy front-end code base or on leave.

Moreover, the outdated documentation and legacy code created unnecessary confusion. After all, the on-boarding documents hadn't needed updates for a year company-wide and over two years in our team.

Before this, I was in a large web team. On-boarding ran smoothly with well-maintained documentation and plenty of mentor resources.

Fortunately, a kind engineer from the platform team appeared unexpectedly to help. I soon learned that people here readily assist others, even at the cost of their own time—my first culture shock.

In Asia, engineers tend to be reserved, especially those who aren't tech leads or managers. Most prefer coding to talking. Cross-team assistance was rare, and sacrificing time to help others wasn't celebrated in the organizational culture—only delivering impressive features was.

Encouraged by the feedback-welcomed environment here, I took some notes and chat to the platform engineers. Only a few months after, the massive mono-repo documentation was beautifully revamped, earning praise widely from new hires.

The Flexible (or Messy) Process

Another aspect that confused me during on-boarding was the process. Each lean engineering team reports to an engineering manager, who reports to a director. The organization gives teams maximum flexibility to establish processes based on their business needs. Everyone is encouraged to shape the team through initiatives that gain team consensus. While this increases ownership and enables quick adaptation, it can disorient newcomers.

In my first few months, I often felt uncertain about next steps, and no one seemed able to clearly define which situations called for which actions.

Surprisingly, everything functioned well, with everyone displaying strong self-motivation. This contrasted with my previous experience, where managers or leads would define most processes, refining them over years based on feedback to reduce ambiguity. Most engineers would simply follow established procedures.

Here, when dealing with ambiguity, we're not only encouraged to discuss with others but expected to contribute our own perspectives. Though decision-making takes longer, it leads to better solutions for various scenarios and ensures all voices are heard. This workplace values active communication over static documentation.

Re-understanding Engineering Manager and Leadership Roles

While many leading IT companies started to separate engineering and management career tracks years ago, this was my first experience with such a system.

I happily chose the engineering track due to my exhausting experience of managing technical responsibilities alongside team members without actual managerial authority.

Yet it wasn’t a simple split.

Task assignment and workload balancing become shared responsibilities between engineers and managers based on individual interests, particularly when multiple engineers maintain the same platform and team goals aren't assigned to specific individuals.

Engineers need to put in significant effort to demonstrate the value of technical work when competing for priority against tech debt and product roadmap items. This is especially important since managers, even those with engineering backgrounds, may not fully understand the technical details of our work.

The glue work is not reduced from our responsibilities. Instead, these essential activities - like mentoring others, improving documentation, or facilitating technical discussions - are actively recognized and celebrated within the organization. This represents a significant shift from environments where such work might go unnoticed, as the company culture here places high value on these contributions that help strengthen team cohesion and knowledge sharing.

Re-understanding the Product Manager Role

Product managers here operate differently. They focus on high-level product strategy rather than details— determining the product roadmap, priorities, and scope.

Instead of PM, engineers will take the lead, carving detailed plans including milestones, tasks, acceptance criteria, edge cases, and handling options.

Initially, I struggled to identify the right person for discussing issues and solutions. It wasn't a simple if-else scenario: UI/UX for designers, business logic for PMs, resources for project managers, and technical issues for tech leads/managers.

After all, people in the same role work differently—some PMs focus on high-level strategy and delegate details to designers, while others take a more hands-on approach when the team needs decisions. A crucial skill is identifying the right "team" for efficient collaboration without disturbing others unnecessarily.

Re-understanding the Quality Engineer Role

We use a quality engineer assistance model where multiple teams share one QE. This means QEs don't verify everything or conduct team regression testing. Engineers take greater responsibility for testing and rely more on automation. We rely on CI/CD pairing with diff coverage for faster delivery, while QEs help identify essential test cases and establish quality goals and metrics.

The shift from strict, process-heavy quality control to this trust-based system affected me deeply—like a child's first independent outing. Each PR brought anxiety: Should I request QE testing? When? Are my test cases sufficient? What if I miss critical edge cases and cause production issues?

Reviewing other engineers' PRs made the responsibility feel even more daunting. And eventually it pushed me to write better tests and accelerate development by removing QA bottlenecks. When issues arise in production, we have clear processes for both urgent incidents and non-urgent customer reports, encouraging quick responses and continuous improvement.

Re-understanding Engineering

Back-end developers, SREs, and database engineers regularly create technical design documents with detailed architecture diagrams, data structures, and API designs. However, for the Front-end work, documentation typically appears only for ambitious projects, usually with rough diagrams beforehand and explanatory documents afterwards.

I had no experience writing Front-end technical designs or RFCs. This stems partly from my Chinese education background, where a notable book criticized the lack of training in research and proposal writing.

Frontend developers often lack of motivation to craft formal technical design in favor of quick feedback, moving straight from proof of concept to implementation, and expectation of fast delivery.

After several technical discussions, issue investigations, conversations and observations with our talented Back-end engineers, I've grown to appreciate how technical design and investigation documents help solve complex problems, document decisions, track progress, and support career advancement in cross-functional teams.

The struggling writing process was time consuming but allowed me to dry-running ideas in all scenarios and refine again and again rather than implementing and refactoring code with double, triple or even more efforts. And I find it pushed me to learn new things everytime, much more than coding.

Here are some common documentation topics I found easy to start with:

• comparing and choosing third party library, tool chain
• naming conventions
• learnings

And some often skipped and sometimes more difficult to write:

• common utility or component design
• state structure design
• refactor and migration plan
• complex implementation with trade-offs, other options and why

Afterwords

Fundamentally, all the work remains, but instead of having dedicated project managers, we've distributed those responsibilities across multiple roles. Engineers now occupy a more central position in the organization with expanded capabilities and responsibilities—though this comes with the trade-off of spending less time coding. That updates my understanding of engineering culture.

This has been a fascinating learning journey, though it took me considerable time to find the right words to describe my observations. After 10 years in the industry, I'm delighted to see that ways of working continue to evolve.