I connect engineering execution, architecture, security and the business, and I’m looking for a senior engineering leadership role to do it.
Ka Lun Chan (KC) is a San Francisco Bay Area engineering leader. As co-founder and CTO he built a startup from the ground up to 400,000+ users and an acquisition, then served as CTO of a media publishing platform. Earlier he was VP of Operations for a voice services company. He now leads architecture and delivery for government and startup clients through Yippify, and he still writes code.
View my experience Request my résumé Connect on LinkedIn Contact me
091
092
Each result links to the work behind it.
30+
Built and led a global team of 30+ engineers, VoIP specialists and designers as co-founder and CTO, then led fully remote teams as a fractional CTO.
The founder-CTO roleAcquired
400,000+ users across South America, Asia and Africa, millions of dollars in transactions, and multimillion-dollar revenue. I led the technical due diligence and stayed on the board after the sale.
Founder story~30%
Re-platformed a media publishing portfolio onto AWS, where right-sizing, scaling on real demand and database fixes contributed to about 30% lower AWS costs.
How the cost came down+50%
As publishing CTO, organic traffic, social traffic and social engagement each grew 50%, with page speed and structured content treated as platform features.
Publishing case studyPublic sector
Applications behind public-sector small business certification programs, engineered to security authorization: FedRAMP-aligned environments, evidence for the Authority to Operate, and Section 508 accessibility.
What public-sector work taught me8M+
Ran software engineering, QA and network operations behind 8M+ VoIP minutes a month, after integrating carrier infrastructure across 2,000+ collocations.
The VP of Operations role093
Companies rarely need more engineering in general. They need one of these fixed.
What worked with five engineers stops working at twenty. I put in the few practices that let a bigger team move without me in every decision: written architecture decisions, clear ownership, reviews that teach, and engineers growing into leads.
Grow engineers into leadersSlow delivery usually starts upstream of the code. I look at how work is defined, how big each change is and how many meetings sit between a decision and a deploy, then shrink stories and pull requests so releases stop being events.
Small, safe changesI treat debt as a financing decision. I map which parts of the system slow the roadmap or carry real risk, put a cost on them in terms the business uses, and modernize in increments while the product keeps shipping.
When technical debt becomes a business problemI size infrastructure from measured demand, not from fear of the next spike. That means right-sizing, autoscaling where the data supports it, infrastructure as code and deploy automation, so the bill follows the business.
Plan capacity before it becomes a costI started in network security, writing router access control lists and supporting a managed firewall service. Today that shows up as authorization checks, audit evidence and accessibility written into acceptance criteria, not bolted on before a review.
Security from ACLs to applicationsI can take a board conversation about cost and risk, turn it into an architecture decision, and then review the pull request that implements it. That range is why founders and small leadership teams bring me in.
Why I still write code094
I supported the network before I designed it. Each role added a layer: operations, product, a company, then the business around the engineering.
Yippify
Public sector, startups, founders
Media publishing platform
+50% organic & social traffic
Global communications platform
400k+ users · 3 continents · acquired
Voice services
8M+ VoIP minutes a month
National broadband network
2,000+ collocations nationwide
095
The longer version, with the signals I watch, is my leadership operating manual.
096
The tools matter less than knowing when each one is worth its cost. Where each capability was earned.
When technical debt is a reasonable shortcut, when its cost starts landing on the business, and how I decide whether to refactor, replace, rewrite or leave it alone.
Why too many meetings slow engineering teams down, what they are often compensating for, and how leaders can balance collaboration with focused delivery time.
Why user stories cause so much confusion: different roles, too much or too little detail, stories versus technical tasks, story mapping and acceptance criteria everyone can use.
Speed to market matters, and so does quality. An engineering leader on risk-based process, cutting scope before quality, technical debt, and AI.
AI makes code cheap to write and no cheaper to understand. Five levels of verification depth, matching them to risk, and what it means for juniors and engineering leaders.
From startups to public-sector certification systems: what FedRAMP, Authority to Operate, Section 508, Plain Writing and continuous monitoring taught me about engineering that must be demonstrably secure, accessible and maintainable.