Back

Office Hours: I’m a serial entrepreneur, software architect, technical advisor, and investor in startups. Previously worked at Apple, ex-cofounder at Notion, first engineer at LoungeBuddy, and I paint. I’m Jessica Lam. AMA!Featured

Hi everyone!

I’m Jessica Lam, serial entrepreneur, software architect, and oil painter. I’m a technical advisor that aims to help promising startups mitigate execution risks early on in engineering and product.

I've led engineering from company inception to scaling to acquisition at multiple startups, operating as founder CTO or comparable technical roles. My speciality is engineering GSD, I enjoy the challenge of optimizing on multiple vectors of engineering excellence x product goals x business deadlines.

When Loungebuddy was acquired by American Express in 2019 we were a small team of 5 engineers building 5 separate products being used worldwide and in the world class Centurion lounges. We had a robust architecture that scaled, and it was an interesting experiment implementing the ideals of “small team of A players” in those 4 years from the very beginning.

Similarly at Notion, when it was just the 4 of us at the time in 2014, each of us was proficient in wearing multiple hats, moving at breakneck speed.

I believe the best thinkers are the ones able to synthesize from a wealth of perspectives. That requires having sufficient understanding in many related or completely unrelated fields of interests. The dispersed perspectives and information are crucial for increasing the number of possible frames for evaluating data in any situation.

Early in my career, I had a lot of opportunities to work in very different work environments and that has helped me figure out how I want to learn and develop my edge. I kicked off my career at NCSA at University of Illinois - Urbana Champaign as a student programmer. NCSA was the birthplace of innovations such as the Mosaic browser, it was a great environment to be exposed to a lot of cutting edge research and genuinely smart people.

In parallel, in order to meet my education expenses, I started doing freelance web development. Since I was doing a minor in graphic design along with my computer science degree, I had the necessary skills to execute entire projects from start to finish. Through this I was able to not only develop my design skill, but also be comfortable doing full stack development. Instead of looking for a job that fit my interests and skills, I made my own way. This has proved to be a valuable skill - knowing that when what you want isn’t there, you can be the one to make it.

When the iOS SDK first came out around 2009, I was working at Sony Pictures Imageworks Interactive as a staff web engineer. Since iOS developers were not a thing yet and I was obsessed with Apple, I found ways to pitch iOS projects within the company while learning the framework on my own. Eventually we got greenlit for an official Sony Pictures iOS app after a design contest within the company. After submissions by various designers and employees within the company, the design I submitted actually won. The same skeuomorphic film reel interactive UX also later got us access to iPad hardware access pre-release for testing in Cupertino.

Whether this was instrumental in my subsequent job offer from Apple, I will never know, but what it did instill in me was knowing that the idea that “Jack of all trades, master of none” is utterly false. Having deep understanding and striving for excellence in different areas builds a systematic understanding that feeds into, and informs many other areas.

Working at Apple was very different from any other places I’ve been. I met some of my favorite people there, whether through serendipitous encounters in Caffe Macs or on the job, and it was a privilege to work with some of the best of the best. This really set the bar for what craftsmanship excellence can look like.

After Apple, I briefly worked at 23andMe before joining a former Apple coworker and one of my best friends in starting a company for collaboration tools, and thus started my startup rollercoaster ride that brought me here today.

Ask me anything about

  • early-career optimization
  • working at startups vs. large corps
  • starting companies
  • iOS engineering, full-stack engineering, services architecture, scaling, code review
  • technical leadership at the implementation level
  • “making your own door” vs. knocking on doors
  • lean engineering teams, scaling decisions, avoiding common engineering pitfalls
  • startup risk-mitigating while outcome optimizing
  • Jill of all trades, master of many
  • Oil painting and art

or anything else!

Thanks so much for joining us @kangaroo5383!Elphas – please ask @kangaroo5383 your questions before Friday, February 18th. @kangaroo5383 may not have time to answer every questions, so emoji upvote your favorites 🔥👍🏾➕
Hi Jessica! That’s such a great career trajectory! Love how you’ve continued to stay technical through all of it. I’d love to hear your thoughts on technical leadership at a startup - what, in your opinion, should that mean at the various stages of a startup? How does that translate to hiring at those stages? How does one stay on top of newer tech as senior engineering leadership?
> How does one stay on top of newer tech as senior engineering leadership?This is an interesting question - I think by having a wealth of mental models from various other contexts is helpful to me in getting up to speed quickly in terms of understanding framework intentions. For example, when swiftUI came out, it was obvious that they took some patterns from declarative UI of React/ ReactNative, so before having to read much of the documentations, I had some conceptual models to hang onto. I think a lot of it for me was finding similar patterns but also be observant about how they are different and why.> what, in your opinion, should that mean at the various stages of a startup? How does that translate to hiring at those stages?Great question! In early startup, small team, you'd want people who can GSD (get sh*t done), the importance of knowing where the 80/20 is. For example, if some weird edge case is happening for 10% of your users but that's only 1 person, it shouldn't take up 2 months to refactor the foundational issue - until if / when it becomes more of a problem. Since the biggest risk is product-market fit, you want to optimize for quick iterations of product hypothesis. I think generally if you have a decent team, you shouldn't need more than a couple engineers (depending on their skillset) in most startups pre-revenue. The most likely hiring fail is when people hire too many incompetent engineers by trying to offset previous bad hire with someone else to help them finish the work. This is also where I come in a lot of time as advisor - especially working with non-technical founders, to assess if it's a function of bad hires (it happens more often than you think) OR if it's from a lack of product prioritization.In terms of hiring, I tend to favor "problem solvers" over "people who know things". Because things can always be learned, but clear thinkers who solve problems by understanding the context and broad understanding are amazing teammates regardless of the stage of the company. In fact, I find people who specializes too much or have a narrow understanding and experiences to be quite high risk.
Love your story, Jessica, and love your callout about being a generalist! Would you talk more about learning how to learn, and how you prioritize learning even as you're building/managing day to day work?
Hi Sarah, I love this question as I'm a huge fan of the topic of learning how to learn.I have a few principles that I've found to be effective1. CuriosityI believe that curiosity is a muscle, the more you use it, the more it grows over time. One way to practice is to always ask "why" and "how" on any topic you're either personally interested in or related to some work that you're doing, sometimes there might not be a definitive answer, but even so, having a probabilistically likely answer or a range of possible causes is always a great way to build understanding. I think this is one way to develop your personal interests as well as creating a wealth of knowledge of causes and effects for modeling the world.(curiosity reading rec: https://amzn.to/3oZtUXE )2. Aiming to be accurate instead of being rightBe your own biggest critic, always refining understanding, backtesting with new information. One thought exercise I like to do is to play a game of "what if". Take something that I'm confident is "right and true" then go "what if this is wrong, in what context can this possibly be wrong, what is the likelihood of this being wrong, and if so, how will that affect my projections" I've found Ray Dalio's Principles to be very similar to the ones I've been using, and he goes into more depths: https://amzn.to/3ByTYho3. Talking to "smart" peopleFinding people who have interesting way of thinking about and looking at the world is really helpful in building more mental models. These mental models are helpful in building more accurate understanding of the world. I think of them as "functions you run reality on". When you make observations about the current state, the more mental models you have, the more subsequent projections and inferences of future state and cause and effects understanding you can build. Mental Models: https://amzn.to/3I2ZVFz4. Always be better than you past selfIn most every decision, I always try to think of as many alternatives as possible and see if I think of a better solution than what's already "known". Even if after all the thinking, it becomes evident that the 1st or already known solution was better, I gain something by having to think through new ideas as well as having a better grasp of why it was better.5. Expand on the edgesThe reason I picked up a lot of the skills I have is because they were connected to what I was already doing and I strongly dislike "being blocked" or not understanding. For example, I studied more graphic design outside of school because I needed to understand why some design turns out well and why others are terrible. (Turns out there are some basic principles and systems to get to at least "not bad"). I ended up doing a lot of system design and architecture because the optimal complexity management is understanding how the front end and backend are expected to interact and being able to encapsulate information in the right places can mitigate communication overhead. Additionally, have a broad understanding in everything from typography line-height settings to AWS terraform config feels empowering to me in this sexist industry as I know that when I get push back about anything, I can adequately counter as needed.6. Put yourself in places where you're forced to learnI'm not sure if it is good advice, but for a long time, especially in the beginning of my career, I went with the motto of if something feels too comfortable or easy, it's time to move on. For example, I really loved the team at Sony Pictures and the people I worked with - especially my boss and mentor Bob, who arguably changed my life in many ways, however leaving for SF and Apple really did pushed me in many ways, some good, some bad, but overall a lot of learning and interesting opportunities.
Hi Jess, being part of your early career at Sony, i enjoyed following your career trajectory and seeing all your achievements. As a fellow generalist myself going from java to android to parenthood to react to now leadership, i think you put it perfectly. There is no Master of None but an ability to think beyond the constraints of the problem. As someone relatively new to management and technical leadership, what advice would you give in nurturing that same mindset within your team and organization. In the fun (flip) side of wanting to learn too many things, how do you stay motivated without distractions?
Hi Archana! Good to see you here :) Unfortunately I don't have much to say about the team aspect beyond try to hire VERY good people and keep them engaged? I usually work directly with founders these days and I already screen for very motivated learners, so I guess that's the cheat code? When organization grows, there's this fascinating thing where it really does take after their founders perhaps through implicit culture forming....
Thank you for sharing your story, Jessica! I'm a non-technical founder working on a mental health concept (possibly pivoting) with a MBA and background in digital marketing.What would you say is important to non-technical founders who consider working with a technical advisor? Would you say requiring a functional UX prototype is baseline? How important is it for founders to develop functional expertise (such as UX design concepts) in their product differentiation? I'm still talking to users at the moment and deciding what should go to into my minimal vial product. How did you and your co-founding team decide the MVP functionality for Notion at the beginning?
These are some great questions Jacqueline! I think each early team is different and it really depends on the skillset and personal edge each person has. The optimization in skills you'd want to have in the team can be best described as "broadest coverage possible with enough overlap so people understand each other".So for example: Because I have UX, design, some product, in addition to the engineering experiences, I prefer to work with teams strong in business and product (where their product sense with their industry understanding is stronger than mine). That way, I can take high level directions and translate them into UX / design / implementation while I do engineering planning as a lot of the modeling work can informs UI and UX in mapping out the relationship of concepts.However if you are working with someone who's only focus is engineering, you would need more support in the design, and even that is a bit of a gradient. For example, I know several great engineers who can create compelling visual experiences that aren't even in the original design so they can be just given simple wireframes to extend existing design, however there are also engineers who can't match the design even if they are given...In general, I think to be a successful non-technical founder, you'd just have to be a clear thinker who have deep understanding of your space. Product thinking is a system of understanding (note not just "knowledge"), just like UX and business is a system of understanding. In terms of building, being able to prioritize is an outcome of having deep understanding of what is important (and why and why now). In the early days of Notion, I would say Ivan is the one with the vision that decided on the MVP aspects very thoughtfully. We essentially just had a system of blocks and definition of how they are to interact with each other and how they are "typed". The fundamental questions were more conceptual, such as not having cyclic relationships via transclusion etc - which I don't think necessarily applies to most consumer products, however the general principle of having deep understanding in order to prioritize what problems needed to be solved first is crucial to success.> What would you say is important to non-technical founders who consider working with a technical advisor?Most important is having a clear picture of why you think you'd want / need a technical advisor, and having a clear vision and understanding of the market and company trajectory. I think the specifics for UX vs. not, etc aren't as crucial. With the work that I do, sometimes it's about assessing team / hiring, other times it's architecture design, sometimes it's even implementation, so it really depends on context.
Amazing to have you here @kangaroo5383 ! I’m the Chief of Staff and the fifth hire at a start up 🚀 I love the comments around Jill of all Trades and Master of Many - I think it’s spot on! 🙌🏻
Thank you Michelle!
Wow! So impressive. What do you believe sets successful startups apart from the unsuccessful ones?I’m building cutting edge products and would love 30 minutes of your time to hear what could be done to push us over the edge
> What do you believe sets successful startups apart from the unsuccessful ones?There's a lot to unpack here, but in general - clear thinker with deep understanding, low ego/always learning, ability to convince (hiring / users / investors). Then repeatedly do it with inhuman amount of perseverance!
Hi Jessica, Loved reading your career trajectory. Super inspiring. I struggle with the "jack of all trades" part as I have worked and keep working with a variety of technologies. I know this is a strength but I struggle reminding me how powerful this is when I think about roles where I am in the middle of the two extremes. Can you talk more about things you have done or perspective changes that can help? I added the book recommendation to my list.What are your recommendations for acting as an advisor or CTO for smaller companies? Things like skills to how to set boundaries and the right expectations.Thanks!
Hi Catherine,I think some benefits are: optionality, optimization, and robust systems of patterns.Optionality: As someone that values agency highly, I believe that you're not truly making an "optimally free" choice, unless you know as many choices as possible. So by gaining an understanding in various technologies, you can better discover what you like.Robust systems of patterns: I think once you start diving into various topics, you start to realize different (and sometimes similar) patterns in how various places solve conceptual problems. Those patterns are then helpful in solving new problems. This is similar to the mental model comment below (https://elpha.com/posts/jangc137/office-hours-i-m-a-serial-entrepreneur-software-architect-technical-advisor-and-investor-in-startups-previously-worked-at-apple-ex-cofounder-at-notion-first-engineer-at-loungebuddy-and-i-paint-i-m-jessica-lam-ama#l8x0vnme )Optimization: By having an adequate understanding across various topics, it's more likely that you can find the right optimization. This is especially crucial for working with smaller companies as the challenge of doing a lot of things with limited resources is all about knowing what to optimize and where. I've noticed that when people have very limited skillsets, they tend to over-engineer in what they know (backend for example) while neglecting the complexity introduced in the larger system (at company level). As a concrete example - a backend engineer who've ever really done backend, could be spending a week normalizing the database to the "academically correct" configuration, without considerations how the extra abstractions make it harder for front end to consume the data, while delaying the feature launch which then impacts a company marketing target. Everything has a cost, the optimal state is when you optimize tradeoffs across everything.The more you know, the more you CAN know and understand, so perhaps the opposite of Dunning-Kruger effect?