👋 Hello and welcome to this week’s edition of ✨ Community Wisdom ✨ a subscriber-only email, delivered every Saturday, highlighting the most helpful conversations in our members-only Slack community.

A big thank-you to this month’s community sponsor, Chameleon. Tired of disruptive onboarding tools? Chameleon lets you guide users with inline, non-intrusive messaging that feels like part of your product, not a band-aid for bad UX. Deliver beautifully designed nudges tailored to each user’s journey, enhancing adoption and engagement without interrupting their flow. Chameleon is giving away a one-year Reforge membership at chameleon.io/lennys—check it out!

✨ Upcoming community meetups ✨

Upcoming community-organized meetups—click the city name to RSVP:

• Arlington. March 13th. Thanks to @Zhe L!

• Austin. March 27th. Thanks to @Kirsty Finlayson (Chameleon team)!

• Austin SXSW. March 11th. Thanks to @Andy Keil - Austin!

• Bangalore. March 13th. Thanks to @Ani!

• Boise. March 19th. Thanks to @Jill Nebeker!

• Boston. March 18th. Thanks to @brooke (Chameleon team)!

• Brooklyn. March 25th. Thanks to @Pulkit Agrawal (Chameleon team)!

• Budapest. March 12th. Thanks to @tamas!

• Chicago. March 19th. Thanks to @Shivam Malhotra!

• Delhi. March 18th. Thanks to @Arunesh!

• Denver. March 25th. Thanks to @Pete Medina (Chameleon team)!

• Detroit. March 20th. Thanks to @Esther!

• Grand Rapids. March 11th. Thanks to @Alex Fergus!

• Houston. March 25th. Thanks to @Joseph Mapula!

• London. March 20th. Thanks to @Zareef Anam!

• Los Angeles. March 11th. Thanks to @David Jorjani!

• Madrid. March 18th. Thanks to @Ashley Duncan & @Giulia Camargo (Chameleon team)!

• Mexico City. March 26th. Thanks to @Nai!

• Minneapolis. March 12th. Thanks to @Charles Edward Buchwald!

• Munich. March 20th. Thanks to @Lukas Gerhardt!

• Philadelphia. March 11th. Thanks to @Keriann Sabatini & @Kamilla Yunusova!

• Phoenix. March 20th. Thanks to @Justin!

• Pune. March 22nd. Thanks to @Gaurav Joshi!

• San Francisco. March 18th. Thanks to @David Jorjani!

• Santa Barbara. March 12th. Thanks to @Joni Hoadley & @Cody Landstrom!

• Santa Cruz. March 26th. Thanks to @Patrick Mottram!

• Seattle. March 13th. Thanks to Monali Agarwal!

• Sofia, Bulgaria. March 11th. Thanks to @ilia!

• Toronto. March 13th. Thanks to @Raf V. !

• Vancouver. March 11th. Thanks to @Andrew McNeil (Chameleon team)!

Can’t find your city and want to host one? Just DM @Riya in our Slack. It takes 10 minutes (i.e. pick a date and location), and you get to meet awesome people from our community. Learn more here.

🎙️ New podcast episodes this week

Notion’s lost years, its near collapse during Covid, staying small to move fast, the joy and suffering of building horizontal, more | Ivan Zhao (CEO and co-founder): Apple, Spotify, and YouTube

The creator of WordPress opens up about becoming an internet villain, why he’s taking a stand, and the future of open source | Matt Mullenweg (founder and CEO, Automattic): Apple, Spotify, and YouTube

💥 Top threads this week

1. Designing great performance review templates

Q: Doing performance reviews for a small team this week. As I sit down to craft a template I can use, thought I would ask—do you have one that employees actually love? Need something that creates an ownership culture that moves fast and is efficient with resources even as the headcount doubles this year. Was going to ping ChatGPT, but maybe you all are smarter (it tends to spit out generic things, and I want something that’s qualitative and quantitative in measuring performance as well as human). ↗️

—Neesha Mirchandani

Daniel Heo-Lu: Does this client have a career ladder? I try to base this off the career ladder.

Neesha Mirchandani: No—and that’s part of the challenge. Some jobs don’t have career paths. But some like that—they don’t want to worry about managing people.

Here’s what ChatGPT gave me:

• Managers: Rate each statement on a scale of 1-5, where:
  1 = Rarely demonstrates this
  3 = Meets expectations
  5 = Consistently exceeds expectations
  • Employees: Before your review, complete the Self-Assessment section honestly and thoughtfully. This is your chance to reflect on how you show up and where you want to improve.

  Company Values in Action
  
  Positive Energy & Problem-Solving Mindset

• Brings solutions, not just problems.

• Faces challenges head-on and proactively finds ways to improve.

• Contributes to a work environment where others feel supported and energized.

Manager Notes (optional): Goes on for 4 more sections…

Daniel Heo-Lu: For me, the most important thing is that what is used for the performance evaluation is:

• Consistent with company values

• Clearly articulates prior and future expectations (usually career ladder)

• Consistent with prior feedback

• Attempts to structure and quantify performance where feasible

So my main question is, what has been communicated with these employees prior with regard to performance expectations? If they’ve received no prior expectations and prior feedback, I would address that first…

Joni Hoadley: One thing you might find useful is a role canvas. I created one to use as a guide for (a) onboarding new hires and (b) conducting perf reviews. I think you might find this helpful to create a dialogue with your direct reports. Send me a DM if you’re interested. It’s free.

2. Balancing oversight and autonomy with junior team members

Q: I am trying to assess a situation with a new team member on my growth-marketing team. Let’s call her Kelly. Kelly has transitioned from another business unit into my team and has done fairly well in her previous business unit when it comes to delivering output. Kelly is young and joined as a fresh graduate, she worked in an IC capacity and previously reported to the CEO.

After joining my team two months ago, I have given her 3 key areas to plan and execute. She has created her own strategy and worked on executing it. There have been 5-6 instance where I have given my input or asked to look at something that we plan on putting out. She has found this an interference and feels I do not trust her. Over here, my intention has been to stay informed or offer help as opposed to progress updates, however that didn’t come through. I am having trouble in figuring out if this is a micromanagement issue or a miscommunication. Where does the balance lie in these situations? Would love to hear thoughts. ↗️

—Maya

James Conway: Couple of thoughts...

1. Try to have an open and transparent conversation about the level of delegation you are working at. I’ve suggested the concept previously for different scenarios, and there may be some relevant discussion, so I’ll link the threads (here and here)

   • This is where you can agree ahead of time what you need to review and at what stage, so she doesn’t feel blindsided or attacked by your input.

2. Consider structuring your feedback in the format “do, try, consider”: see this.

3. Try agreeing on a weekly status report format that she pushes to you, ideally before your regular 1:1. I’m a big believer in being open and transparent about progress and pains ... reduces surprises. Here’s a format that might work. The key message she might need to internalise is that she is responsible, but you are accountable (to the CEO) for the successful execution of her work. If she’s reassuring you that she’s got her stuff together, you won’t ask questions that may put her on the defensive.

These are all concepts I’ve used independently but never all together at the same time.

David Jorjani: This, to me, sounds like communication style differences that go unnoticed mostly because of different personalities or cultures. At this point, we don’t know if the message was fully received and/or where the gap is. I think you are sharing more interpretations than facts. I’d suggest having a “difficult conversation” kind of conversation. When X, you/I did/said Y, and that led to Z. My hope was A. What happened here? Since you are the person of authority and she seems to be talented and driven and hopefully without agenda, it may help get to the bottom of this.

Ashwin: We have a variation of PPP called PPE—Progress, Plans, Escalations. In this manner, you can check on how her plans have actually turned into progress (make sure it’s timebound) and whether she is mature enough to “look beyond the curve” and escalate to you in a timely manner.

Joshua Herzig-Marx: In addition to all the great suggestions above, I’ve found it’s often difficult in high-growth tech orgs to give context around suggestions or feedback. Specifically, there’s a broad range of feedback one can give, ranging from “Here’s a random idea that popped into my head, do with it what you want” to “This is an area I consider myself an expert, and the issues we’re dealing with are existential to the company.” Dharmesh Shah developed the concept of flashtags as a simple way to convey that context (@Lane Shackleton discussed in his interview with Lenny). Doing something similar can be very helpful, especially when these are new relationships.

Joni Hoadley: Hey Maya, sounds like a case of misaligned expectations rather than straight-up micromanagement. Kelly’s used to working independently and reporting directly to the CEO, so she probably sees any check-ins as interference rather than support. Meanwhile, you’re just trying to stay informed and help where needed—it’s just not landing that way. Totally get it. One thing that could really help here is creating a “How I Work” document—basically, a personal operating manual. This is something both of you could do to get ahead of potential friction and make sure you’re on the same page. It outlines how you each like to work, communicate, and give/receive feedback.

HOW I WORK—What I believe about work:

• Autonomy is key, but alignment is equally important.

• No ego—best idea wins.

• We move fast but always with purpose.

My leadership style:

• I trust my team but stay engaged where I can add value.

• I try to ask the right questions rather than give all the answers.

• I appreciate proactive problem-solving.

Communication preferences:

• Slack: Great for quick updates and decisions.

• Email: Good for detailed thoughts, not urgent matters.

• 1:1s: A space for coaching, support, and feedback—not just status updates.

How I give feedback:

• I like to be direct, but I always aim for constructive.

• Feedback is a two-way street—if something isn’t working, I want to hear it.

How I like to receive feedback:

• Honest and specific. If something I’m doing isn’t working, tell me!

What I appreciate in a team:

• People who take ownership and bring solutions.

• Clear and proactive communication—no one likes surprises.

• A sense of humor—work is serious, but we don’t have to be serious all the time.

Here’s a link to a thread about personal “read.me” type of documents that I think you will find useful. At the end of the day, you both want the same thing—solid work without unnecessary friction. A little up-front alignment should smooth things out. Hope that helps!

Stepa Mitaki: Hi guys. I remember there was a Community Wisdom (probably) issue discussing the idea of creating your personal “How I work / How to work with me” document to share with your team. Including the community’s experience and examples of it. I can’t find that issue via search. Could anyone help me out here to find that issue?

Mounica Veggalam: Consider that Kelly might be tuned in to a particular type of listening. You intend to help, but she’s receiving that as interference, perhaps activating or triggering her. This is a case of intention (offering help) not matching the impact (interference). Even if you figure out whether it is a micromanagement or a miscommunication issue, it might be worth investigating this as an area of development for yourself so you can handle such situations with various personalities in the future. I say that not because you might be doing something wrong, or because Kelly is wrong to have that type of listening. We all have some version of that. The best way to soften people’s listening is to actively look out and be responsible for your impact. So what to do in this case? Here are a few questions I suggest sitting with:

1. “How might Kelly be hearing what I say?”

2. “In what ways can my words be interpreted as interference? What can I take responsibility for?”

3. “What are Kelly’s goals in her development? What does she want out of working on this team?”

4. “Is there a conversation here towards those goals?”

Considering she’s a recent graduate, I suggest that there is no conversation here. This is more of a mental note to help you understand Kelly better before giving her any feedback. I would celebrate her for putting her voice in and asking what she needs from you when she feels interfered with. See if you can follow her request, or what you can do to accommodate her request. This last piece will help you shift focus on developing her instead of talking about what you or she might be doing “wrong.” Often, fresh graduates need to have their ideas and voices heard by someone. I guess that most would be figuring out how to belong to the team, get recognized for their talents, how to not screw up etc., even if they might be a little arrogant/direct about it. If you want to be a leader who develops people, you’d want to see more of what’s going on for them and guide them slowly to empower their voice in ways that others can hear them as well.

Joshua Herzig-Marx: So much good advice in this thread, which points to one big challenge: all of this is deeply context-dependent. Happy to chat if that’d be helpful.

Maya: All of these are really helpful, thank you, everyone.

3. Rebuilding vs. refactoring

Q: We’re a small B2B SaaS company that has been in the market for over 20 years. We’re in the position of having an old codebase on old technology. Because of that, the engineers on our team have been saying that new AI tools can’t help us move faster.

The owners in the company have now come to me as the PM to ask if we could just rebuild the core platform using third-party tools that weren’t available when we started (Stripe, WorkOS etc.) and then use new AI tools to basically rebuild our existing tech on top of that.

I’ve started exploring tools like Lovable, Supabase, etc., but they feel to me more like party tricks in a way—cool to get something up and running fast, but not something you’d use to build your business.

I’d really love to hear some engineering takes on this outside of our org.

And I’m curious if anyone else has taken considered (or done) a rebuild of an older platform on completely new underlying tech and lived to tell the tale.

If you asked me if we should undertake this last year, I’d have said no, the total refactors never work. But with today’s tech, it doesn’t sound as insane. ↗️

Daniel Bartholomae: Doing total refactors at startups that have built themselves against a wall is kind of my thing, so happy to give pointers. First of all: Most AI tools are not good for creating a long-term SaaS software, only for prototyping, but that might change. And some (so far: Cursor) already are but require devs who actually know how to code to work with them. I would also still see the same patterns for a total rewrite that were relevant before. They basically boil down to:

1. Don’t replace the full thing, but pieces.

2. Make sure that each piece is small enough to be fully built in a few weeks.

3. Make sure that each piece is then used in production, and the old thing it replaces is no longer used.

4. Do not add new features as part of these steps—if you do want to add new features (and most companies will), do that as explicit steps in between.

You’ll need both a great PM and a great technical person to find the right pieces. But then these kinds of refactors can work. And I do agree that a codebase that is AI-first is a huge competitive advantage nowadays.

Miroslav Pavelek: Please consider—how much is the complexity driven by technology and how much by business rules? Consider this scenario, which may be applicable in your case:

• Imagine you have 20-year-old codebase and each month you create one or two new business rules (logic) based on some specific request or some edge cases. So now you have something between 240 and 480 business rules.

• On the new system, you can implement only 50 of them for MVP, and each year you can make only 50 new ones (so twice faster than previously!).

• Is this scenario feasible for you? If so, go for it, if not, consider it deeply again.

Sri Ram: Don’t think using AI will suddenly make this faster. You have to bring engineering on board with this. Looks like in your case, engineering is not on board with this. Might be your stakeholders, and you should give the business context to your engineering and influence them on why you need to restack etc.

Peter Berg: Super high-level, I’d say a full rewrite from scratch is almost always a mistake. And also would say I wouldn’t really expect AI to materially accelerate development, your intuition around that stuff feels accurate to me. Do think there’s a possibility an incremental refactor could make sense.

If you need a fractional eng leader to come in and give you all an unbiased assessment of how to move forward, I’m Pete, I run this company Forward, we’d be happy to help with that.

Jeff Lindquist: “Our engineers are saying that AI tools can’t help us move faster”—this line immediately makes me think that you’re probably using the same words to say different things. What exactly are your expectations when you say engineers can use AI to speed things up? What exactly do the engineers mean when they say the AI tools can’t help them?

Abdussamad Bello: I don’t believe rewrites will kill a business, it really depends on the skill set of the migration team, project management, testing. I have worked in a team where we’ve had to migrate several large codebases.

• flask->fast-api

• blevesearch->elastic search

• vue2->vue3

• monolith to serverless

In your case, I would advice quickly testing out database REST API generators like DreamFactory, Kong, Hasura, Prisma and internal tools like Budibase, Retool, Superblocks for a start, so you can use the API to rebuild the UI. Here is a good read.

Jack Timonen: We have been working with a couple of B2B SaaS companies that have been in the same position as you have. Short-form case studies here. Ping me if you would like to learn more or discuss with the founders directly.

OP: First, thanks to those who replied. I appreciate the feedback.

Jeff Lindquist— The owners of the company are seeing people whip up apps quickly using AI tools and have this feeling like “Why aren’t we doing this? We need to do this to keep up.” The engineers are saying that type of thing can’t just be done on an existing, older codebase like ours.

Like, let’s say we want to add a feature that involves basic CRUD operations. A quick form lets you add a few fields of data that need to be stored in a simple relational database table, retrieved by user ID, updated if necessary, and deleted. It would be nice to be able to spin something like that up quickly with AI vs. needing to hand-code everything. It’s not complex, but with our custom design system and non-standard core platform, AI couldn’t do it “how we do it.” Does that make sense?

So I think the idea is that we need to start over with a modern codebase where these tools can actually be used to speed up development.

Sorry if I’m not explaining that well, but hopefully that provides some context.

Sri Ram— Re: engineering being on board, I don’t think they’re against AI, but if we were to rebuild from scratch, they’d want to use our existing set of programming languages, which the owners view as outdated and not the way forward if we want to modernize.

Peter— I’ll DM you.

Miroslav— I appreciate the thoughts about complexity. One of the reasons starting fresh is so appealing is that our core users have really evolved over time, and there’s so much complexity in our current system that could just be tossed out if we started over.

Jeff Lindquist: Yeah, so what is it about the current codebase that the tools don’t work? Are the engineers suggesting to rewrite it in order to get those benefits, or are you hearing the engineers saying that and thinking, okay, we should rewrite? I don’t really understand what about your existing setup doesn’t let you take advantage of the AI tools, though. Feels like the engineers need to give more detail than saying it’s an existing older codebase. What stack are they developing in? Frankly, AI is more suited to “older languages” because there’s more to train on, and I find AI is getting it wrong a lot for new languages that are updating frequently. Based on just this, I’m on the fence between owners’ expectations being unrealistic or that the engineers just don’t actually know how to use the AI tools. On the topic of rewriting the codebase: It’s super-interesting because, as @Peter Berg said, the general consensus is rewrites are a red herring that more often kill a business than save it. I legitimately don’t know if that’s changed now that building scaffolding is far quicker than before, though—I mean, to some extent it must have.

alexa: This is kind of being glossed over, but your leadership is seeking technical evaluation from someone outside the engineering department. This approach creates certain dynamics worth considering as discussions continue.

Peter Berg: I think it’s worth noting a few things:

• Engineers usually care deeply about the day-to-day experience of working in a particular codebase

• Legacy systems makes their day-to-day experience bad

• Legacy systems make it harder to develop new features

• Legacy systems can also make it easier to introduce bugs

• Most engineers aren’t well equipped to evaluate the business value of fixing or incrementally refactoring a legacy codebase

• The larger in scope and scale a project is, the more difficult it is to estimate how long it will take

• A full rebuild from scratch is typically a multi-year project that requires a team of engineers, especially for old, larger codebases. AI hasn’t changed this

• If you really do need to refactor a large, old, legacy codebase, typically the best way to do that is going to be to identify sections of the app that can be broken out into independent front ends and/or APIs and rebuild the thing in pieces slowly over time

Sebastian: “...the engineers say that this kind of thing can’t just be done on an existing, older codebase like ours.”

TBH, I think AI tools like Copilot or ChatGPT might sometimes even work better with old technologies than newer ones, due to the knowledge cutoff and amount of training data there is for new frameworks. For example, most LLMs don’t produce good modern NextJS (a popular frontend framework) code, because they haven’t seen the newer approaches that are used. This can be compensated for by good integrations like the one Cursor has. It basically reads a part of your code and can then determine how the code should look. Of course, this also works with older code bases, though. On the other hand, if you want to use tools like v0 but don’t use Tailwind or shadcn/ui, then yeah, this might not work. That said, we use all the fancy new stuff, but don’t really use v0 to produce UI components. These kinds of AI tools are great to create prototypes, but using them to write production code hasn’t really worked out for us. I’d also like to point out a few things about rewriting old codebases, since I have extensive experience with this: It can be a huge effort, and not just in terms of development effort. You have to think about which features to keep, which to rework, and which to throw away. You also have to consider what to do with your existing customers. Can you migrate them to the new codebase without significant cost? Or would they be willing to pay for the migration? Can you keep them on the old code without significant effort (both from engineering and support)?A rewrite can pay off for the right reasons, but potentially using some AI tools might not be a good one.

4. Having a part-time co-founder

Q: I’m curious to learn from the experiences of full-time founders who’ve worked with part-time co-founders (people who have chosen to be part-time due to different family/other constraints in the initial period):

• Has this work setup actually worked for you?

• Are there any recommended guidelines to go about this from your personal experiences that you could kindly share based on what has worked and what had to be improvised/refined?

• Are there any tips/guidelines/book recommendations from publicly available resources that you could kindly point me to?

• Any gotchas/do’s and don’ts, points to keep in mind when working in such a setup?

• How do you recommend going about the equity split in such a work setting, given the risk the other co-founders could be taking is relatively limited? (Imagine the setup where they’re working Mon.-Fri. on their full-time job and they have hours in between on weekdays and/or weekends towards the startup idea). ↗️

—Mohnish

Christian Sino: I have this kind of setup. Too many questions. 1. Yes, it did, and it kind of still does, but expectations need to be adjusted at times 2. and 4. You need to set up clear expectations of how many hours and when they are going to be available. And based on that, you need to understand and share to the team how the progress will be. Are you comfortable going slower? Be aware that some days/weeks, they are not going to feel enough motivation/energy to work. You are going to have that, but you are still going to make some progress each week. Also, what are their intentions if things start to go well? E.g. Enough revenue, investment etc. What if things take longer than expected? They almost always take longer than expected, especially in that type of setup. Is your personal financial runway enough to anticipate that? Share that and share what you would have to do. 5. Then, after all these are laid down, you can discuss equity. Equity split can be tricky, but for sure you are taking more risk than they are. Share that and maybe set up a vested schedule for equity. Keep in mind things are going to go slower, so vesting only based on time passing by might not be an issue for them. What if their work is lower than expected? Not answers, but things to consider.

Gautam Banerjee: It’s not going to work if you’re going for VC investment. No investor is going to bet on founders who don’t fully also bet on themselves.

Mohnish: Thank you very much, @Christian Sino 🙂 I really appreciate your valuable insights about this, especially as someone having firsthand experience with this sort of a setup. I’ll definitely keep all your above points in mind, as I’m currently speaking to someone who cannot immediately go full-time and I’m exploring if things can work out between us to be potential co-founders in this setup, and especially points like vested equity are key things to keep in mind for them to also showcase their dedication and commitment to the startup for the long term.

@Gautam Banerjee, your reasoning is very nicely put. I do know that investors normally prefer full-time team members, and with your answer I now understand this so much more better as to why, especially in the context of a fully dedicated team, thank you very much for your insights.

David Jorjani: Most important is to set expectations and boundaries clearly and get comfortable having difficult conversations to adjust course. Seems like a special circumstance, and it’ll be hard to get it right the first iteration. Build “retros” into the relationship. I don’t think there can be one resource that covers everything you need to cover in this situation.

🤓 Top finds

1. The future of the internet is likely smaller communities, with a focus on curated experiences via Guy Peled

2. 50 things we’ve learned about building successful products via Gautam Banerjee

3. A Vision for Product Teams | Silicon Valley Product Group via Rishi

4. I’m a Scientist Who Has Been Studying “the Dress” for a Decade. There’s a Key Takeaway We All Could Stand to Hear. via Anuj Adhiya

5. Meta keeps ‘block’ lists of ex-employees—and even help from a VP can’t get you off them via Ashwin

😂 Meme of the week

Have a fulfilling and productive week 🙏

If anyone in your life would benefit from this newsletter or community, consider giving them a​ ​g​i​f​t subscription 💞 There are group discounts, gift options, and referral bonuses available.

Give a gift subscription

Sincerely,

Kiyani 👋