Jessica McKellar is a software engineer and serial entrepreneur who co-founded Ksplice, Zulip, and Pilot. She is known for her technical leadership in the Python community and her work teaching programming to incarcerated individuals at San Quentin State Prison. This profile gathers her practical insights on engineering management, open source software, and building equitable hiring pipelines.

Visual summary of operating lessons from Jessica McKellar.

Part 1: Startups and the Founder's Journey

  1. On serial entrepreneurship: McKellar treats repeat founding-team work as an execution advantage: trust, values alignment, and complementary ownership let the team move faster on the next company. — Reference: First Round podcast on McKellar building three companies with the same co-founders
  2. On finding a co-founder: "Trust and shared history reduce the friction of decision-making in the chaotic early days of a new venture." — Source: Stanford eCorner
  3. On early-stage focus: McKellar starts with the immediate customer pain, not the imagined future architecture: find the loudest problem, see if people will pay, then build around what the work actually requires. — Reference: First Round podcast on Pilot validating the bookkeeping pain
  4. On acquiring users: "Your first customers are rarely acquired through scalable channels; you have to do the manual work of talking to them directly." — Source: SFELC
  5. On iterating: McKellar shows iteration as direct contact with the work: do the service manually, watch the process, write software against the checklist, and expand when customers pull you forward. — Reference: First Round podcast on Pilot manual service and customer pull
  6. On risk tolerance: "Moving from a stable engineering role to a founding position requires a shift in how you evaluate failure and upside." — Source: Medium
  7. On market selection: "It is often easier to build a company in a space with high complexity and unsexy problems, like accounting, because fewer people are willing to do the hard work." — Source: Amy Vetter Podcast
  8. On building Ksplice: "Updating operating systems without rebooting required us to dive deep into kernel internals while solving a very practical downtime problem for administrators." — Source: Wikipedia
  9. On transitioning post-acquisition: McKellar treats acquisitions as useful but temporary chapters when the founding team still has another problem it wants to solve and another company it wants to build. — Reference: First Round podcast on Ksplice, Zulip, Dropbox, and Pilot
  10. On founder longevity: "You have to genuinely enjoy the people you work with if you plan to spend a decade building multiple companies with them." — Source: Stanford eCorner

Part 2: Engineering Leadership and Scaling

  1. On management transitions: "Moving from individual contributor to manager means your output is no longer the code you write, but the effectiveness of your team." — Source: SFELC
  2. On hiring engineers: "The best technical teams are built by evaluating a candidate's ability to learn and adapt, rather than their current knowledge of a specific framework." — Source: Techies Project
  3. On engineering at Dropbox: McKellar frames engineering leadership at scale around three jobs: support people directly, coordinate execution across teams, and keep improving the organization as it grows. — Reference: First Round Review on McKellar engineering leadership at Dropbox
  4. On cross-functional collaboration: "Engineering cannot exist in a vacuum; product, design, and engineering must be equal partners in defining what gets built." — Source: SFELC
  5. On technical debt: "You have to be honest about which corners you cut for speed and have a deliberate plan for when to pay that debt back." — Source: SFELC
  6. On empathetic leadership: McKellar makes management personal: understand each engineer's day-to-day blockers and longer-term growth goals, then shape work around both. — Reference: First Round Review on McKellar supporting engineers day-to-day and year-to-year
  7. On building Zulip: "Real-time communication tools need to balance immediacy with the ability to do deep, focused work without constant interruption." — Source: Wikipedia
  8. On incident response: McKellar uses postmortems to create learning, not blame: give the team time to understand what happened and turn it into process changes other teams can use. — Reference: First Round Review on McKellar running instructive postmortems
  9. On aligning engineering with business: "Technical leaders must be able to translate architectural decisions into business outcomes for the rest of the executive team." — Source: SFELC
  10. On delegation: McKellar treats delegation as a requirement for scale: leaders have to trust tech leads with architecture and execution instead of staying in every code review as the backstop. — Reference: First Round Review on trusting tech leads and stepping back from code

Part 3: Open Source and the Python Community

  1. On the Python ecosystem: McKellar sees Python's strength in its community as much as its language design: the ecosystem grows when it welcomes beginners and broadens who feels invited. — Reference: OpenSource.com interview on McKellar and Python community outreach
  2. On Twisted: "Event-driven networking in Python requires a mental shift, but once understood, it unlocks the ability to build highly concurrent applications." — Source: O'Reilly Media
  3. On open source governance: "Maintaining a large open source project requires as much community management and dispute resolution as it does code contribution." — Source: PyCon US
  4. On Python's evolution: McKellar's Python work points toward a language community that keeps renewing itself by teaching beginners, supporting contributors, and maintaining serious open source projects. — Reference: PyCon 2014 speaker profile on McKellar in the Python community
  5. On documentation: "Good documentation is the difference between an open source project that thrives and one that is abandoned by frustrated users." — Source: O'Reilly Media
  6. On community health: "A programming language community is only as healthy as its ability to welcome and mentor absolute beginners." — Source: PyCon US
  7. On corporate open source support: McKellar's open source lesson is practical reciprocity: projects thrive when experienced contributors make room for new contributors and maintain the support systems around the code. — Reference: OpenSource.com interview on Twisted, beginners, and open source support
  8. On learning Python: McKellar teaches Python through hands-on entry points: give beginners a real workshop, a supportive room, and a path from first program to continued practice. — Reference: PyCon 2014 profile on McKellar teaching beginning Python programmers
  9. On the Python Software Foundation: "The foundation exists to protect the intellectual property of the language and to fund the grants that keep the community growing globally." — Source: PyCon US

Part 4: Criminal Justice Reform and Education

  1. On teaching at San Quentin: "Teaching programming inside a prison demonstrates that intellectual curiosity and the capacity to build exist everywhere, regardless of circumstances." — Source: Stanford eCorner
  2. On the justice system: "We cannot look at the statistics of mass incarceration in America and conclude that the system is functioning properly." — Source: PyVideo
  3. On hiring the formerly incarcerated: "Giving someone a software engineering job after they leave prison completely changes their economic trajectory and reduces recidivism to near zero." — Source: Amy Vetter Podcast
  4. On The Last Mile: "The curriculum has to be rigorous; we are not lowering the bar, we are providing access to the education needed to clear it." — Source: SCALE
  5. On reentry challenges: "The technical skills are often the easy part; the harder part of reentry is navigating a society that places countless administrative hurdles in front of formerly incarcerated people." — Source: Collective Freedom
  6. On tech industry responsibility: "Tech companies have the capital and the hiring demand to make a massive dent in the reentry crisis if they are willing to update their background check policies." — Source: Amy Vetter Podcast
  7. On offline programming: "Teaching web development in an environment with absolutely no internet access forces you to get creative with offline documentation and local servers." — Source: SCALE
  8. On human potential: "When you write code, the compiler doesn't care about your background or your criminal record. It only cares if the logic is sound." — Source: Stanford eCorner
  9. On fair chance hiring: "Reviewing a candidate based on their recent commits and interview performance rather than a past conviction is just good business." — Source: Amy Vetter Podcast
  10. On continuous advocacy: "Criminal justice reform requires sustained, unglamorous work, from teaching weekly classes to showing up for parole hearings." — Source: Collective Freedom

Part 5: Diversity and Outreach in Tech

  1. On the Boston Python Workshop: "If you want to change the demographics of a technical community, you have to deliberately design introductory spaces that are welcoming to underrepresented groups." — Source: PyCon US
  2. On beginner environments: McKellar shows that beginner-friendly environments are designed, not wished into existence: workshops, follow-up project nights, mentoring, and clear materials make people stay. — Reference: OpenSource.com interview on Boston Python beginner support
  3. On imposter syndrome: "Many talented engineers struggle with feeling like frauds because our industry glorifies an unattainable myth of the innate genius programmer." — Source: Techies Project
  4. On structural barriers: "The pipeline issue is often cited as an excuse; the reality is that many tech companies have broken hiring funnels that filter out non-traditional candidates." — Source: Techies Project
  5. On actionable diversity: "Putting the word 'diversity' in a mission statement does nothing unless you are actively tracking metrics and changing how you source candidates." — Source: PyCon US
  6. On accessible tooling: McKellar's own open source path shows why tooling and documentation matter: a first contribution is easier when the process is explicit and reviewers are patient. — Reference: OpenSource.com interview on McKellar's first Twisted contribution
  7. On representation at conferences: "When a beginner attends a conference and sees no one who looks like them on stage, they implicitly learn that there is no path for them to lead." — Source: PyCon US
  8. On community support: McKellar treats community as infrastructure: recurring workshops, project nights, and mentoring turn a first exposure to programming into an ongoing path. — Reference: OpenSource.com interview on Boston Python workshops and mentoring
  9. On inclusive language: "The terms we use in our codebases and documentation signal who we expect to be reading them. Updating legacy terminology is a small but necessary fix." — Source: PyCon US

Part 6: Product Development and Customer Empathy

  1. On solving real problems: McKellar validates problem choice by listening for pain that is both loud and valuable: Pilot came from repeated conversations with operators about finance and accounting friction. — Reference: First Round podcast on finding Pilot's customer pain
  2. On the Pilot origin story: "Every business owner we talked to hated managing their own books. We realized we could apply engineering principles to a very human, paper-heavy problem." — Source: Medium
  3. On avoiding over-engineering: "If a simple Python script solves the customer's problem today, do not build a distributed microservices architecture." — Source: SFELC
  4. On talking to users: McKellar does not let founders outsource customer empathy: the people setting product direction should stay close enough to hear the pain directly. — Reference: First Round podcast on founders staying close to customers
  5. On product constraints: "Constraints in the user's workflow are not obstacles; they are the exact boundaries that define how your product should be designed." — Source: SFELC
  6. On building trust: "In financial software, a single error breaks trust entirely. The product must be relentlessly accurate before it can be fast." — Source: Amy Vetter Podcast
  7. On internal tooling: "At Pilot, our biggest advantage is the software we build for our own accountants. Making your internal team faster directly improves the customer experience." — Source: Woodard Report
  8. On prioritizing features: McKellar prioritizes expansion when customers pull for it and the team can protect service quality; growth should not jeopardize the trust that makes the flywheel work. — Reference: First Round podcast on customer-led Pilot product expansion
  9. On design systems: "A predictable, boring user interface is vastly superior to a beautiful, confusing one when the user is trying to accomplish a stressful task." — Source: Medium

Part 7: Financial Infrastructure and Automation

  1. On the state of accounting: "Small business accounting is largely run on spreadsheets and manual data entry, making it ripe for software-assisted automation." — Source: Woodard Report
  2. On AI in finance: "Artificial intelligence is going to replace the tedious categorization work so accountants can act as strategic advisors, rather than replacing the accountants entirely." — Source: Amy Vetter Podcast
  3. On democratizing back-office operations: "Founders should be focused on building their product, without worrying about whether they calculated their payroll taxes correctly." — Source: Medium
  4. On the concept of a 'CFO in a box': "The goal is to give a five-person startup the same financial visibility and strategic advice that a five-hundred-person company has." — Source: Medium
  5. On software-enabled services: "A pure software-as-a-service model fails for bookkeeping because the user avoids learning the software; they just want the problem handled." — Source: Amy Vetter Podcast
  6. On parsing financial data: "Integrating with thousands of different banks and payroll providers requires incredibly resilient data pipelines to handle the inevitable edge cases." — Source: Woodard Report
  7. On accuracy in automation: "When a machine learning model categorizes a transaction with low confidence, the system must elegantly hand it off to a human expert for review." — Source: Amy Vetter Podcast
  8. On the future of bookkeeping: "The ledger of the future will be real-time, completely programmatic, and directly connected to the operational metrics of the business." — Source: Woodard Report
  9. On standardizing financial formats: "The lack of standard application programming interfaces for many financial institutions forces fintech companies to build extensive abstraction layers just to get basic transaction data." — Source: Woodard Report

Part 8: Career Evolution and Personal Values

  1. On studying chemistry at MIT: "My background in hard sciences taught me how to approach problems rigorously and systematically, a skill that translates perfectly to debugging software." — Source: Amy Vetter Podcast
  2. On entering software engineering: "I learned to program relatively late compared to the stereotype, which proved to me that computer science is a skill you can acquire at any time." — Source: Techies Project
  3. On aligning work with values: McKellar treats values alignment as operating leverage: the founding team can make hard decisions faster when they agree on the company and culture they are trying to build. — Reference: First Round podcast on values alignment in McKellar's founding team
  4. On long-term focus: "Career progression is rarely a straight line; the most valuable experiences often come from side projects or volunteer work that initially seemed unrelated to your job." — Source: Techies Project
  5. On curiosity: McKellar looks for the kind of curiosity that becomes ownership: give technical people harder problems, the right guardrails, and room to grow through the work. — Reference: First Round Review on matching engineers to complex problems and growth
  6. On managing burnout: McKellar manages sustainability through the work system itself: protect maker time, remove distractions, match people to motivating projects, and keep happiness and productivity visible. — Reference: First Round Review on happy productivity, maker time, and motivation
  7. On taking risks: "Leaving a secure, high-paying job to start a company is terrifying, but staying in a role where you are no longer learning is a slower, quieter kind of failure." — Source: Medium
  8. On measuring success: "At the end of your career, the number of successful exits you had will matter far less than the number of people whose lives you materially improved." — Source: Stanford eCorner
  9. On legacy: "Whether it is through open source code, a startup, or teaching in a prison, the goal is to build structures that outlast your direct involvement." — Source: Stanford eCorner