Syam SundarGet in Touch

Bengaluru · Business Operations & Founder's Office

I turn messy operations into systems that run without me.

Nine years, one habit: find where something's being left to guesswork, and make it explicit before it costs someone else.

See my workGet in touch
9+Years in Ops
50+Systems Built
20+Teams Led
10+Business Functions

How I work

The same three moves, whether it's a startup or a conference.

Move 01 — Diagnose

Find the real mess

Most “operational problems” are actually three problems wearing a trench coat. I go find the other two before I touch anything.

Move 02 — Build

Build the system

Not a slide about the system — the actual working thing. A script, a pipeline, a playbook someone else can run without me in the room.

Move 03 — Hand off

Make it run without me

If it only works while I'm watching it, I haven't finished.

Selected work

Three times I took something chaotic and made it a system.

Each one follows the same shape: what was in front of me, where it stopped making sense, what the trace found, what changed — and, honestly, what I'd do differently.

Setting:
An early-stage startup
Role:
Founder's Office

What was in front of me

A role kept getting refilled. Each time, the explanation was the same: this one wasn't the right fit either.

Where it stopped making sense

After the third repeat, instead of starting another search, the question changed from “who's wrong for this” to “what's actually happening here.”

What the trace found

Traced one feature through its full lifecycle — the original requirement, the design that came out of it, and what actually shipped.

Laid side by side, the three didn't match. A requirement had changed mid-discussion, and the change never made it into the design brief.

What shipped was being judged against a target nobody had actually been given.

Try it yourself — walk the chain

Click each step, in order, the way the trace actually happened.

What changed

One review step, added: check shipped work against both the requirement and the design before judging the output. The mismatch stopped — not because anyone worked harder, but because the handoff finally had a check on it.

What I'd do differently

I'd add that review step after the first repeat, not the third. Three cycles is two more than it should take to stop trusting the easy explanation.

Process designRequirement traceabilityPeer review
Event:
AORA-GARC APSA 2026
Scale:
~600 faculty · Coimbatore
Role:
Sole technology & operations owner

What was in front of me

An international medical conference. Four days, multiple halls, about 600 faculty. No tech team — just one person handling the entire technology and operations layer.

Where it stopped making sense

A 36-page agenda locked inside a CorelDRAW export. Registrations split across a ticketing platform and a master tracker that didn't agree with each other. Faculty communication that had to go out one by one, or not at all.

What the trace found

Reconciling registrations meant walking every record between the ticketing platform and the master tracker — category moves, add-on swaps, comp registrations, each one a small mismatch to resolve by hand first, then by script.

One handoff almost failed outright: transport for a guest arriving at midnight, one message, no fallback — sent, then nothing, because there was no second checkpoint if the first one didn't land.

broken hereTicket9 record

Category, add-ons, comp status as sold

Master tracker

The event's working source of truth

Reconciled record

What was actually true on the day

Every mismatch lived in the gap between what was sold and what was tracked.

What changed

Bulk faculty communication automated through the Gmail API and Apps Script. A Python and PyMuPDF pipeline that split certificate PDFs and pulled names by OCR. 53 run-of-show decks generated straight from the parsed agenda. A live hosting outage escalated and resolved mid-event. A four-day, multi-hall conference that ran on systems one person could actually operate.

What I'd do differently

I'd build a second checkpoint into any handoff that touches a person directly — confirmation, not just a message sent and trusted. One almost went wrong for exactly that reason.

Gmail APIGoogle Apps ScriptPythonPyMuPDFOCRSeleniumWordPress
Where:
Prezantim (rebrand)
Status:
Building now

What was in front of me

Every conference reinvents the same wheel — website, registration, badges, comms, run-of-show, certificates — mostly by hand, mostly from scratch, every time. The operational knowledge evaporates the moment the event ends.

Where it stopped making sense

The AORA-GARC build proved the pattern works for one event. The question underneath it: does the next conference have to start from zero, or can it start from what the last one already learned?

What the trace found

The instinct that shows up everywhere else — make the invisible visible — applies just as directly to an industry that keeps losing its own institutional knowledge between events.

What changed

Packaging the AORA stack into reusable software — event websites, registration, attendee apps — so the next conference starts at 80%, not zero. Early stage, stated honestly: this is where the operator work becomes a product.

What I'd do differently

Too early to say — that's the honest answer, and the more interesting one is what this becomes over the next year.

WebRegistration systemsAttendee appsFigma

Origin

Nine years, five promotions, one habit that never left.

What actually held his attention at Bosch wasn't the engineering — it was the traceability. Customer requirement, safety requirement, system requirement, implementation, test. Nothing depended on memory. Every decision had a reason you could point to.

One Friday evening, a small change — a signal resized from uint8 to uint16 — looked harmless enough to skip a second look. It broke another module's assumption silently. His mentor and colleagues came back into the office to fix what one line had broken.

“That wasn't the moment I learned to be more careful. It was the moment I understood why traceability, reviews, regression testing and explicit dependencies exist. Until then they felt like process. After that evening they felt like respect for everyone else's time.”

That's the habit that never left — whether the dependency sits in software, in a team, or in a company.

Philosophy

“If I can't explain what I'm working on to my parents in simple words, I probably don't understand it well enough myself.”

Not because they need the details — because if the purpose doesn't survive translation into plain language, the complexity was probably standing in for understanding.

Nine years, five promotions

  1. 2026 →Conference Tech & OpsPrezantim (building the product)
  2. 2024–26General Manager, Founder's OfficeCalifornia Software Co.
  3. 2024Sr. System Software Engineer 2Tessolve
  4. 2022–24Lead EngineerVitesco Technologies
  5. 2020–22Senior Software EngineerBosch
  6. 2017–19Programmer AnalystCognizant

Beyond the work

This section is still being written — on purpose. Everything else on this page is true and specific; this one isn't ready yet.

Contact

Two honest reasons to reach out.

For hiring teams

Ops, strategy, or a founder's office

Looking for a senior operator — Chief of Staff, Business Operations, Founder's Office — who builds the systems, not just runs them.

Schedule a call

For event teams

Running a conference or event?

I build the technology and operations layer end to end — registration, comms, run-of-show, certificates — so the next one starts at 80%, not zero.

Start a conversation
Reach me directly
Based in
Bengaluru, India