Starting Out: From Technical Training to Business Reality

I walked into the a B2B industrial automation company office in July 2013 with seven years of entrepreneurial experience and approximately zero idea what actual corporate work looked like.

By "entrepreneurial experience," I mean: I'd built game automation systems generating SGD 2K monthly at age 18. I'd flipped consumer electronics for SGD 100 profit margins at 19. I'd learned sourcing, pricing, risk management, and customer relationships through direct competition with actual money at stake.

None of that prepared me for sitting at a desk, wearing business casual, taking notes in a meeting about training schedules across seven countries.

I was hired as a Sales & Service Engineer at a B2B industrial automation company, a distributor of industrial automation and technical equipment. The role was technically focused but commercially oriented: train regional customers (distributors and engineers) on complex equipment, troubleshoot technical problems, support service contracts.

By the time I'm writing this, in October 2014, I've been here for more than a year. Looking back, the first three months were humbling.

The Transition: Entrepreneurial Skills Meet Corporate Reality

Here's what was different from my previous experience:

The Timescale Changed

Hardware reconditioning: Buy, fix, sell in 7 days
Game automation: Iterate in hours or days
a B2B industrial automation company sales: Three-month sales cycle, six-month implementations, annual support contracts

This was disorienting. In entrepreneurship, you get feedback immediately. Broke something? You know today. Customer unhappy? They tell you this week. At a B2B industrial automation company, decisions took time. Approvals took time. Everything had longer cycles.

The Complexity Increased

Console repair was technical but straightforward (fix hardware, test, sell)
a B2B industrial automation company equipment was complex systems with multiple components, integration requirements, regional customization
Supporting customers meant understanding not just the equipment, but their business context, regulatory requirements, regional differences
A "simple" installation might involve electrical engineering, site planning, software customization, and training-all in different languages across different countries

The Stakeholders Multiplied

Hardware reconditioning involved me and the customer (simple)
a B2B industrial automation company work involved distributors, regional managers, end customers, technical teams, commercial teams, compliance, and executives
No decision was purely technical. Every technical decision had commercial implications. Every commercial request had technical constraints.

The Risk Profile Changed

Lost SGD 100 on a broken console? Frustrating, but manageable
Sold someone incompatible equipment because of miscommunication? That's a financial hit and relationship damage

The stakes were higher. The visibility was higher. The need to get it right increased substantially.

What Was Actually The Same

But here's the thing: underneath all the complexity and timescale changes, it was the same work.

Problem-Solving Approach Didn't Change I started with technical training to distributors across APAC. Some engineers didn't understand the equipment. My job: Make them understand.

This was the same as explaining game automation to myself-take something complex, break it into components, understand the underlying logic, then teach it. The domain was different. The methodology was identical.

Assessment Skills Transferred One of my early wins was solving a "technical problem" that had stumped other engineers. The customer said the equipment wasn't working correctly, multiple service calls hadn't fixed it, they were about to reject the installation.

I flew to the site, watched the equipment run, and realized: The equipment was working perfectly. The customer's understanding of what it was supposed to do was wrong. The previous engineers had tried to fix "broken equipment" when the issue was "incorrect expectations."

I spent an afternoon explaining what the equipment actually did versus what they thought it did. Problem "solved" (no repair needed, just clarification).

That's the same assessment skill I used hardware reconditioning: Look at what's actually happening, not what people think is happening, and respond to reality.

Relationship Building Remained Central At a B2B industrial automation company, I wasn't the most technical engineer in the company. But I built strong relationships with distributors and customers because I:

Showed up when I said I would
Explained things clearly without jargon
Actually cared if they understood (not just if they signed the contract)
Followed up even after the deal was closed

This is the exact approach I used selling consoles: Show up, stand behind the product, maintain relationships, build loyalty.

Systems Thinking Persisted My job included designing training programs for regional distributors. I could have just written documentation and scheduled classes.

Instead, I designed training as a system:

Initial training: Hands-on for key technical staff
Self-paced materials: For reference and secondary learning
Mentorship: Pairing experienced distributors with newer ones
Support channels: Clear escalation path for questions
Feedback loops: Tracking which topics confused people most, improving those areas

This is a system. Build once, benefit indefinitely. It's the same philosophy that drove game automation and hardware reconditioning. Now it was applied to organizational learning instead of technical problems.

The Growth: Learning Corporate Operations

Year one at a B2B industrial automation company was disorienting. By year three, I understood how corporate operations actually work.

What I Learned: Technical Training

How to make complex systems teachable:

Break technical content into mental models people can hold
Use analogies from their domain (not abstract engineering concepts)
Hands-on practice before theory
Multiple reinforcement (show, explain, practice, reinforce)
Test comprehension and iterate based on what didn't land

This became valuable later when I was training regional teams at a global medical aesthetics and technology company on medical device operations or designing e-commerce automation workflows that non-technical people needed to understand.

What I Learned: Client Management

Understanding that every technical problem is actually a business problem:

Why does a customer care that this equipment works? (Not because of technical excellence, but because it impacts their business)
What's their real constraint? (Not always technical-often budget, timeline, resource availability)
What are their unstated needs? (They might ask for training, but actually need reassurance the equipment was worth the investment)

This transformed how I approached technical work. I started asking "what outcome do you need?" instead of "what's the technical problem?"

What I Learned: Regional Coordination

Working across Singapore, Malaysia, Philippines, Indonesia, and beyond taught me:

Same equipment, different contexts (regulatory requirements vary, customer sophistication varies, support needs vary)
Cultural communication differences matter (directness appreciated in some countries, considered rude in others)
Local distributor relationships are assets (partners who know their market, not just distribution channels)
Speed in one region is constraint in another (what's "fast" in Singapore might be "unrealistic" in Indonesia)

I was learning how to operate at regional scale. This became directly valuable when a global medical aesthetics and technology company put me in charge of standardizing RMA processes across APAC in 2022. I already knew from a B2B industrial automation company that you can't impose a standard; you have to adapt a framework to local reality.

What I Learned: Selling Complex Solutions

a B2B industrial automation company didn't sell simple products. It sold solutions involving equipment, integration, training, support, customization. The sales process required understanding customer needs deeply, identifying what could be standardized and what needed to be custom, and building business cases.

Some of the technical customizations I designed became standard product offerings. Not because I was brilliant, but because I was solving real, repeated customer problems. When the same customer need appeared in three different countries, I'd design a solution, and eventually that solution would become part of the standard offering.

This taught me valuable lessons about product development: The best product improvements come from solving customer problems, not from engineering brainstorming.

The Foundation Emerging

At the time, I didn't fully realize it, but those three years at a B2B industrial automation company were building a foundation for everything that came after:

Technical Credibility I learned that if you genuinely solve technical problems and understand the systems deeply, people trust you. This became valuable in corporate environments where credibility is your most valuable asset.

Regional Operations Thinking I learned to think about operations at scale-multiple countries, different contexts, local and regional coordination. This prepared me for later roles where regional standardization was critical.

Problem-Solving Framework I developed a consistent approach: Observe the actual situation, understand what's really needed, design for the common case with options for customization, implement with support.

Business-Side Thinking I was no longer just a technical person. I was starting to understand: What makes a project successful? (Not technical perfection, but delivering what the customer needed within their constraints.) How do you build sustainable relationships? (Through reliability and genuine help, not just sales.) How do business operations actually work? (Through relationships, understanding stakeholder needs, and systematic process improvement.)

The Larger Context

I didn't know it at the time, but a B2B industrial automation company was the bridge between my entrepreneurial experience and corporate work.

Before a B2B industrial automation company:

I'd built businesses (game automation, hardware reconditioning)
I'd learned business fundamentals (sourcing, pricing, customer relationships, risk management)
I had entrepreneurial instincts and systems thinking

After a B2B industrial automation company:

I understood corporate operations
I'd learned how to operate at regional scale
I'd developed credibility in technical and commercial contexts
I'd learned that business fundamentals don't change (whether you're hardware reconditioning or selling complex industrial equipment)

Everything since has been applying these lessons at larger scale:

2016-2019 (a regional medical devices distributor): Medical device operations with bigger budgets and more regulation 2020 (COVID): Supply chain restructuring with family-run electronics trading enterprise's survival at stake 2020-present (a global medical aesthetics and technology company): Enterprise-scale operations across APAC

Each role built on the previous one. a B2B industrial automation company was where I learned to operate in corporate environments without losing the entrepreneurial mindset that made me effective.

The Reflection: Work as Craft, Not Career

Looking back at my first corporate role, what strikes me is: I wasn't motivated by career progression.

I didn't take the a B2B industrial automation company job because it would look good on a resume or position me for the next step. I took it because I wanted to understand corporate operations and learn from people more experienced than I was.

That's the difference between work as career and work as craft:

Career-focused thinking: How does this help me get promoted? How does this look to my manager? What title should I push for?

Craft-focused thinking: Can I solve this problem well? What will I learn? Can I build systems that outlast my involvement? Am I improving?

I've never optimized for career because I had financial independence early. The SGD 2K monthly from game automation meant I didn't need this job. That freedom meant I could focus on doing excellent work rather than playing politics.

At a B2B industrial automation company, that translated to: I didn't care about being "Senior Engineer" or managing people. I cared about solving customer problems, building training systems that worked, and understanding how regional operations functioned. The satisfaction came from the work itself, not the title.

That orientation-caring about craft over career-became increasingly important as my roles became more senior. I'm never competing with peers for promotion or visibility. I'm focused entirely on building excellent systems and doing my duty well.

It sounds simple, but it's a competitive advantage in environments where many people are optimizing for the wrong thing.

The Takeaway

If you're making the transition from entrepreneurial work to corporate employment (or vice versa), here's what I'd tell you:

The domains change. The fundamentals don't.

Everything I'm good at in corporate work-problem-solving, relationship building, systems design, regional coordination, business understanding-I learned in entrepreneurship. Everything I learned in corporate work about process, scale, and operation I've applied in entrepreneurial ventures.

The transition isn't about becoming a different person. It's about applying your existing strengths in a new context.

I came to a B2B industrial automation company thinking I had to "become corporate." What I actually discovered: My entrepreneurial instincts and problem-solving approaches were exactly what was needed. I just had to understand the different timescales and stakeholder dynamics.

Three years later, I left with:

Corporate operations understanding
Regional coordination experience
Technical credibility across multiple systems
Business problem-solving confidence

And the same core skills I'd been developing since age 18.