Multi-OEM, cross-timezone, technically-rooted. I've delivered complex embedded programs across Japan, the US, and Europe — and learned that the hardest problems in delivery are never technical. They are human.
I didn't start as a project manager. I started as someone who built things.
After three years developing telecom systems and software at VNPT and Samsung, I joined LG Electronics Vehicle Solutions in 2016 — first as an embedded software engineer on GM's AVN head unit, then as a technical lead on telematics platforms for GM, BMW, Honda, and Toyota. By 2022 I was leading a 20-person engineering team across multiple OEM programs spanning Japan, the US, and Europe.
"The projects that struggled rarely failed because of the plan. They failed because of the people inside it."
Nearly nine years inside one of the most process-driven, safety-critical environments in software taught me where delivery actually breaks down. It's rarely the plan. It's the people inside it — someone not heard, not growing, managed like a task. That's what I became a PM to fix.
Since April 2025 I've been a project manager at FPT Automotive, running a Cluster project and bringing the same discipline I developed at LG into a new program environment. I carry deep technical fluency and a decade of automotive delivery into every project I run.
Real projects. Real constraints. What I did and what I learned.
The team already knew about the bug. Nobody said anything — not because they didn't care, but because nothing in the environment made saying it feel necessary.
The integration kept failing — but the root cause was never technical. It was a process that served the organisation's structure rather than the product's needs.
"The team already knew about the bug. Nobody said anything — not because they didn't care, but because nothing in the environment made saying it feel necessary."
A crash report came in from the OEM with reproduction steps attached. The team diagnosed the issue within hours. The fix shipped the same night. But the real finding came the day after, during the retrospective: the bug had been flagged internally months earlier. It was left alone. Nobody escalated it. Not because the team didn't care about quality — they did — but because the environment hadn't been built to make surfacing risk feel safe, or even necessary.
I ran a 5-why analysis with the leads. The answer wasn't process failure. It was environment failure. Engineers assumed someone else would own it. There was no clear path from 'I noticed something' to 'this gets looked at.' So concerns sat in heads rather than backlogs.
We ran a full codebase scan after the patch, found and closed 1–2 additional instances of the same category of risk, and then rebuilt the team's risk surface. A technical lead was embedded in every project with a direct mandate: surface what the team is worried about. In daily syncs, I started asking directly — not 'is there anything to flag?' but 'what are you most uncertain about right now?' Technical debt grooming became fixed scope, not optional. The OEM raised no further escalations on this issue after the patch was accepted.
Surfacing unspoken concerns isn't a one-time initiative. Culture change is slower, less visible, and never fully done. But it is the only work that prevents the next midnight call.
"The integration kept failing — but the root cause was never technical. It was a process that served the organisation's structure rather than the product's needs."
The program was distributed across functional teams — middleware, application layer, communication stack — each running multiple projects simultaneously. Nobody was accountable for the whole. Integration delays were predictable. The structural problem was visible to everyone. What was missing was a response within the constraint.
We built stub code to test each module end-to-end against spec before integration. In practice this moved defect discovery roughly 1–2 weeks earlier in the cycle, and integration-phase bug counts dropped by around 20% compared to what we had seen previously. I moved to one developer per project where possible — not because context-switching was inefficient in principle, but because ownership was missing. When someone could see a module through from start to integration, they thought differently about it.
We ran sessions to help the team understand where they sat in the V-model — not as theory, but as a map of who depended on their output. Fewer surprises at integration. All three OEM programs delivered.
Process that serves organisational convenience rather than product progress is an active drag. You may not change the structure, but you can ask if your team's process is moving work forward. Redesigning within constraints isn't insubordination — it's the job.
He was technically one of the best on the team. He was also someone most engineers quietly avoided. The problem wasn't his skill — it was that the environment around him had never been built to surface it.
The customer kept adding requests. Management kept absorbing them. Nobody was saying the one thing that needed to be said: every change has a cost, and someone has to own it.
"He was technically one of the best on the team. He was also someone most engineers quietly avoided. The problem wasn't his skill — it was that the environment around him had never been built to surface it."
His reputation made teammates nervous. He worked alone, responded poorly to process requests, and his directness read as dismissiveness. I started with 1:1s — not to address the behavior immediately, but to understand it. What I found: he cared deeply about quality and was frustrated by what he saw as unnecessary overhead. He wasn't resistant to work. He was resistant to process that felt disconnected from outcomes.
I publicly acknowledged his technical contributions. I created space for his preferred working style while coaching teammates on how to engage with his personality. For a while, that was enough. Then a PM escalated — he had stopped updating tickets and wasn't responding in chat. I had a direct conversation: his reasoning was coherent (status updates felt like overhead), but he hadn't considered the ripple effect on a multi-timezone program where his silence created blockers for people he never met.
After that conversation, he started updating tickets. He began asking teammates whether they needed help before closing his own work. Engineers started seeking him out for reviews. In the sprints that followed, roughly 20% of the blocking points the team had been sitting on were resolved directly by him. The change wasn't in his skill — it was in the visibility of that skill. The environment had been redesigned to make his capability accessible.
Difficult behavior usually has coherent internal logic. Understanding is half the work. Talent that can't be accessed isn't an asset — it's friction. The PM's job is to close that gap.
"The customer kept adding requests. Management kept absorbing them. Nobody was saying the one thing that needed to be said: every change has a cost, and someone has to own it."
I joined midway. The baseline was a 4-person OTA team, a vague spec, and a Tier 1 Japanese customer with an onsite SME who had direct access to management. Scope creep arrived not as a single decision but as a steady accumulation — each request reasonable in isolation, each one quietly absorbed.
The first move was visibility. Every new request got mapped against capacity with explicit tradeoffs surfaced to management: if this comes in, this goes out. For ad hoc requests, I negotiated timing rather than the request itself — which defused tension without creating precedent. I established a change control forum that brought developer, tech lead, tester, and SME together in the same room with data: impact, effort, risk. The decision didn't disappear. It moved to the right level.
When a wave of critical defects hit simultaneously, the team worked overtime to ship. I held documentation until after release, pushed the test team to write reproduction cases concurrently, and formally escalated the resource constraint with evidence. The escalation wasn't a complaint — it was a proposal with options attached. Critical defect counts came down by approximately 80% from their peak.
Scope creep is rarely a planning failure. It is a communication failure — the accumulated weight of costs never named, risks absorbed silently. The baseline is an agreement, not a constraint. Every change is a renegotiation. The PM's job isn't to absorb quietly — it's to make cost visible and put the decision in the right hands.
Every team I've worked with already had what it needed to succeed. The knowledge, the drive, the capability — it was there. What was missing, when things went wrong, was never talent. It was the conditions to use it.
Frameworks, JIRA, gate reviews — in any complex organisation, process is non-negotiable. But I've seen teams drown in overhead while nothing progresses. The right process at the right phase moves the build forward. When it doesn't, I challenge it.
People rarely fail because they lack skill. They fail because something important was never said — a doubt, a dependency, a misread expectation. The real work of delivery happens in the space between people, not in the tools they use.
Five patterns that define how I approach projects, people, and pressure. Consistent across every context.
The most costly mistake a project manager can make is to impose structure before understanding the system. Before any plan takes shape, I invest time in observation — studying how the team communicates, where decisions actually get made, and where latent friction exists. Only once that picture is clear does a meaningful kickoff become possible: roles defined, objectives aligned, risks surfaced on day one. Speed without that foundation is not efficiency. It is exposure.
Understand the system before you attempt to improve it.
Research consistently shows that teams perform best when they feel supported rather than monitored. My approach to daily communication reflects that distinction. Touchpoints are brief, purposeful, and structured to surface issues before they compound. The meeting that could have been a message is a symptom of poor communication design — not diligence. The goal is a team that moves with clarity, not one that moves under observation.
Presence without pressure. Contact without control.
When delivery timelines are under pressure, the instinct to accelerate is understandable but often counterproductive. The more disciplined response is to ask a harder question: what can be removed without compromising what actually matters? Organisations frequently conflate the original plan with the intended outcome. They are not the same. Scope is a variable. The outcome is the commitment. Distinguishing between the two under pressure is where experienced judgment becomes most visible.
The outcome is the commitment. Everything else is negotiable.
Delegation, when it fails, rarely fails at the moment of transfer. It fails in the absence of preparation that should have preceded it. Effective delegation requires deliberate investment — structured training, consistent feedback, and a clear-eyed assessment of an individual's readiness before ownership is extended. Without that foundation, delegation is simply redistribution of work, not development of people.
Delegation without preparation is offloading with a different name.
Stakeholder confidence is not built through communication volume. It is built through consistent follow-through, over time, without exception. My approach is straightforward: commit to what is achievable, deliver without requiring reminders, and surface problems early — always paired with a proposed resolution. Trust, once established on those terms, becomes the most durable asset a project manager can hold.
Under-promise. Over-deliver. Let the pattern speak.
Heard from the
people I've worked with.
Add a recommendation from a manager, peer, or stakeholder here. One to two sentences from a real person carries more weight than any self-description.
A second recommendation goes here. Pull the key sentence directly from your LinkedIn recommendations — no need to use the whole text.