Ka Lun Chan
Section050

About

Engineering depth.
Leadership that scales.

I’m KC. I’ve spent 23+ years building software, taking a SaaS business from inception through acquisition, and leading engineering teams.

I’ve owned the code, the production problem, the product decision, and the business consequences. That experience shapes how I lead: stay close enough to understand the work, and build a team that can take it further.

Start a conversation

The work doesn’t end when the code ships.

Engineering and operating production systems taught me to care about what happens after launch. Building products added another question: does this actually solve the problem for the person using it?

My work grew across software and product engineering, architecture, cloud infrastructure, and distributed systems. I learned to connect implementation choices with reliability, delivery, and the team that would have to maintain the result.

Building a company changed how I build software.

I co-founded a SaaS company, built the product from inception, and led engineering through acquisition. Responsibility for both the product and the business made the consequences of technical decisions much clearer.

Architecture affects cost. Technical debt affects delivery. Reliability affects customers. Complexity affects who we can hire and how quickly they can contribute. Infrastructure choices show up in the margins.

I still bring that perspective to a design review: what does this decision make possible for the business, and what does it ask the team to carry?

Inside the platform’s growth
Users served
400k+
Continents supported
3
Company outcome
Acquired

I didn’t stop being an engineer when I became a leader.

Moving through technical leadership, engineering management, and CTO responsibilities gave me several views of the same work. Engineers, product, QA, operations, executives, and customers can have different priorities. My job is to make those tradeoffs understandable and help us decide together.

I can discuss strategy and organizational risk, then go deep into an architecture review, a PostgreSQL query, an API, or an AWS production problem. I still review code and investigate difficult failures.

Technical depth helps me ask better questions. It doesn’t give me a reason to take the keyboard away. I want to provide context, remove obstacles, and help engineers make good decisions themselves.

Remove the single point of failure.

We design resilient software. Leadership should follow the same principle.

If every difficult decision, escalation, or explanation still needs me, I haven’t scaled the organization.

My goal is to develop people who can eventually replace me.

  1. Systems

    Resilience beyond one component.

    Design for failure and make recovery possible.

  2. Teams

    Knowledge beyond one engineer.

    Share context, document decisions, and distribute ownership.

  3. Leadership

    Decisions beyond one manager.

    Develop people with the judgment and authority to act.

  4. Community

    Opportunity beyond one generation.

    Help the next person gain experience, then make room for them to lead.

From asking for answers to owning decisions.

I’ve mentored engineers at different career stages and across distributed teams. The useful work goes beyond syntax: breaking down ambiguity, investigating a problem, understanding business context, communicating tradeoffs, and recovering from mistakes.

I want people to challenge my thinking and become better engineers and leaders than me. Their growth creates room for them, for me, and for the organization. I consider a capable successor a leadership success.

More on mentoring engineers

  1. Ask me what to do

    We clarify the problem and its business context. I provide enough structure to get started.

  2. Show me what you’re thinking

    Bring the investigation, what you tried, and what is still unclear. We work through the reasoning together.

  3. Tell me what you recommend

    Explain the options, the tradeoffs, and your recommendation. My answer is open to challenge, too.

  4. Make the decision

    You own the call, communicate it, and follow through. If something goes wrong, we learn and recover without taking ownership away.

  5. Teach someone else

    Share the context and help the next person build their judgment. Knowledge and leadership spread through the team.

Good judgment has to turn into delivery.

Make the tradeoffs explicit.

I’ve worked across SaaS, customer-facing platforms, legacy modernization, government technology, and AI/ML products. Government work in particular demands speed alongside security, compliance, accessibility, reliability, and complex business rules. Process has to help us deliver.

Whether the work involves Python and Django, Rails, React and Next.js, cloud architecture, or an LLM system, technology is a tool. The outcome is the goal.

What problem are we solving? Which constraints matter? What is the simplest architecture that can reliably support the outcome? And what will the decision cost the people maintaining it later?

Explore my technical approach

Leadership shouldn’t be surprised by engineering.

I look for clear requirements, real ownership, and work small enough to review and release safely. Architecture, technical debt, quality, and operational risk belong in delivery planning.

Leadership needs to know what is progressing, what is blocked, why a timeline changed, and which decisions need attention. That should be a clear conversation, not an exercise in decoding a backlog.

Engineering works as a whole: people, decisions, delivery, and production feedback. When those parts connect, teams can act earlier and executives can make informed choices.

How I run engineering

Create opportunities. Make room for the next person.

Three junior cyclists gain riding experience together on a wooded road
Experience grows through practice, support, and opportunities to take the lead.

I put substantial time into cycling through Berkeley Bicycle Club, junior development, volunteering, and race organization. Mentoring young cyclists comes from the same place as mentoring engineers: offer guidance and real opportunities, let people gain experience, and give them room to become more capable.

I help organize Berkeley Omnium, bringing together the Berkeley Hills Road Race and Berkeley Streets Criterium. All proceeds go to six East Bay NICA teams, helping support the next generation of cyclists.

A race is much more than race day. Volunteers, racers, juniors, collegiate athletes, sponsors, officials, and organizers all contribute. I enjoy working with that team. We make something possible together that none of us could deliver alone.

The racing and the community behind it

The common thread is simple: leave the system, team, or community stronger, with more people ready to carry it forward.

For the full career history, find me on LinkedIn. Consulting engagements are available through Yippify.