Running an AI-native engineering org

1. FFFiona Fung0:00

   There's something in the way I move that keeps him on that road. Hey, folks. Do y'all hear me okay? Okay. I've, I, I swear this is not a Claude Code thing, but do you guys mind if I take a photo?

2. SPSpeaker0:17

   [laughing]

3. FFFiona Fung0:17

   'Cause, 'cause Boris and Jared had their session at 2:00, and I really thought this was gonna be empty. I'm like, "There is just no way people would still be coming in from that session," so. Oh my gosh. Whoo.

4. SPSpeaker0:29

   Whoo.

5. FFFiona Fung0:29

   Thank you. Prom- I promise me and Boris don't just do selfie wars all the time. [laughs] But good afternoon, and thanks for attending. So yeah, my name is Fiona Fung, and I lead Claude Code and Cowork engineering and product, so I work really closely with Boris and Cat. And before Anthropic, I had led and grown teams at Meta and then also Microsoft. And so for today's talk, this is kind of like overall agenda, but the whole idea is, what are some of the lessons I learned in helping Claude Code and [laughs] Cowork kind of like grow and as we're building out this team? And, uh, kind of like what things I... And it, it's interesting. It's lessons I learned even if I think about my time at Meta or even Microsoft, but even Anthropic. Like it's funny, I did this slide deck maybe like a month ago, and als- already I've had to [laughs] change some of the content 'cause, for example, when I started this deck, there were no routines, and that, even like that way of working was different for me. And so yeah, like we really wanna, like I wanna kinda cover five themes that I've noticed. One which is the bottlenecks have moved. They've shifted. And so when bottlenecks shift, what are then some of the team norms that we had to rewrite within the Claude Code team? I also wanted to show a little bit about all these team norms we had to rewrite, how we rolled them out, and also what are some of the proof, uh, some of the, you know, like some, some signals that I get of, "Oh yeah, we're trending in the right direction." And, uh, it's always gonna be important for me to have a look at to see is it still serving us trending in the right direction. And then I'll end it with a few kind of like questions that I still have for myself, and then also some suggestions for you to maybe take an action item back, uh, to your teams to have conversations together. So with that, the first section, the bottlenecks have moved. I call it the shift. But you'll probably hear me repeat this kind of subtitle text a lot, which is what served you prior may not serve you any longer. And when, actually, even when I think about, um, experience, whether it was like at Anthropic or Meta or Microsoft, the constant growth mindset is just a muscle that has served me really well, and especially right now when the rate of ch- I don't know if y'all are feeling it. The rate of change is just a little bit crazy, right? Like I remember the first time I started doing some vibe coding was last year, and it was still making some, some, you know, bugs, and I'm like, "Ah. Why, why are you using constants everywhere? That's not good engineering practice." And now it's, it's, you know, just become so much more capable. But that's, that's what I- I'm seeing as this interesting shift of when the bottlenecks moved, how do you think about adapting, uh, in terms of everything else around that bottleneck? So maybe y'all are feeling this too, but like for years, engineering bandwidth was the expensive thing. Like coding throughput was really expensive. And when you think about all the processes we have of shipping software, a lot of it was around... Hi, welcome. There's a chair. Take away those reserved tags. There's no one sitting [laughing] there.

6. SPSpeaker3:22

   [laughing]

7. FFFiona Fung3:22

   [laughs] There you go. And there's another one right here, sir. Welcome. Um, but yeah, like all of that, like even when you think about how we used to do planning, like remember we used to do like waterfall and then agile. Everything was used to be because engineering bandwidth was really expensive. Actually, I'll take a little segue here. This is not the first time our indu- like when you think about our industry, we've always had to adapt. Like I'm gonna put you all in a time machine. Come back with me all the way to the year 2000. That was when I started my career. I worked on Visual Studio, and we were shipping Visual Studio 2005. And I kid you not, in those days, if folks remember, we used to ship software on like CD-ROMs. Before CD-ROMs, it was actually floppy disk. And so I still remember VS 2005, there were really hard deadlines. We had to hit those deadlines 'cause we had to [laughs] get the software to the manufacturing lab to print on the CDs, to put in the boxes, to ship in the stores. And so when you, when you even think about then when we were able to distribute software online, that also changed how we ship software. And so that's what I'm finding really interesting of this, this new, you know, shift that I'm seeing is engineering bandwidth. It's no longer the expensive thing. So for example, on the Claude Code team, for sure coding is rarely the slow part anymore. Um, and I would say it's not even that it's not the slow part, it's just also the throughput has really, really increased. So it's not only like, "Yay, we're now all getting to build more." It's just the amount that we're generating has also changed a lot. And so what we saw was, you know, when your, your bottlenecks shift from kind of the coding and the actual act of typing, like if you remember, it used to be writing code was expensive or writing tests or refactoring. I remember all of these conversations of, "We have to schedule some time to do refactoring." "Oh, but we have to do product work, and this is expensive. When are you gonna find that time to do it?" All of that has shifted now that it's no longer the bottleneck. And so when that happened, [laughs] sometimes I noticed the bottlenecks end up shifting towards other areas. And so what happened? Like for example, verification, review, cross-functional partners, security. Because coding is no longer the bottleneck, and also we're doing so much more of it, these are some of the new bottlenecks that we're seeing. So it's really always us asking, "Is this code correct? Who reviews this code?" That's like probably one of the top questions I get from all fellow eng leaders, like, "How are humans keeping up with how you guys are doing like code reviews?" And interestingly, also how is it maintained? Because now it is also a lot easier for us all to generate a lot of code, so also thinking about that maintenance cost too. So with that, these were some of the processes that I noticed quietly stops working, and I love that phrase quietly stops working, 'cause I don't know if you all, like, a lot of times we all put in processes hopefully for a reason, right? Like we're thinking, "Hey, there was a gap here and we wanna improve."But what I've found over the years is rarely do processes kill themselves. We tend to just layer more and more and more processes on. Like, I remembered on one team, we had so many SLAs. Like, there was a P0 bug SLA, a, a high pri- like sev review incident. Like, anyways, there were so many SLAs. After a while, I'm like, "Oh no, we need to stack rank priorities," [chuckles] so that all the engineers knew which SLA was gonna be even more important. And I remember even at that time, I thought, "Hey, we should start thinking about what things we should defrag a little bit." But, um, yeah, so these are the processes [chuckles] that might have served you. If you remember, again, it's that line of what may have served you may not serve you any longer. But, like, the planning norms. We used to spend a lot more time, you know, pre-planning because coding time was expensive. Uh, code ownership, there used to also be a lot of questions of, "Who, who, who wrote this code? Who owns it?" That's a little bit of an odder question now. Uh, code reviews, what we'll get into a little bit. Team makeup is interesting, too. It's not only, like, roles are blurring, right? Like, so betw- like, engineers can also now, now have AI to help augment non-engineering roles. My non-engineering partners are also all shipping code. So what happens when roles start blurring and you don't have those, you know, uh, like, the silos anymore? And then that also goes to knowledge share. Knowledge sharing and onboarding and everything is another signal that we're noticing at Claude Code, how we used to do things change a little bit, too. And so, you know, in the first section, we talked about the shift. So within the Claude Code team, what are some of the norms that we have to rewrite? So I want to share some of those with you, and then, you know, hopefully some of them will resonate with you or you might find helpful. And so [chuckles] number one is code review. Uh, like, h- human judgment of, like, who actually needs it. And we'll kind of go through all of these, but, you know, like, the onboarding has also changed, how we do planning. You heard, um, me talk about, like, planning a lot. Hiring, especially with roles blurring and kind of team makeup, how that has changed for us, too, and also org shape. That's kind of one of my favorite spicy topics. I'll, I'll share this story with y'all of when I started proposing that at Anthropic. I love my recruiting partners. They're awesome, but I remembered, you know, one recruiting partner really did think I was crazy. Um, so I want to share that with y'all, too. So how have planning changed, but also technical debates? Planning, we do a lot less of it. Like, I, I would also s- and also the timing, I call it, like, JIT planning almost, like JIT compiling, because even when I first joined, I'm like, "Don't we need a six-month roadmap?" And, you know, we put some effort in. We wrote it. It was pretty good for three months, and then I came back o- over the new year and, and so many things had changed already. So I realized, wow, six months [chuckles] roadmap just seems like a little bit too long. So again, it's how do you make sure you kind of, like, do just the right amount in the right time? Because again, prototyping and code generation is just not the bottleneck that it used to be. The technical debate one is a fun one, too. [chuckles] So in technical debates, code wins. I'll share with y'all, when I first joined the Claude Code team, I wanted to do a refactoring. I wanted to, like, get to learn about the code base, and me and Boris had a healthy technical debate of, you know, which, which way to go, and I almost leaned into my old toolbox. I almost tapped him on the shoulder to go, "Let's go to that room and have a whiteboard, and we can..." And I'm like, "Wait, wait, wait, wait a minute. Nowadays, I can just generate all the different options we've been discussing." I generated three PRs, and the cool part about that for the technical debate is I really cared not only about the implementation of the API, but also the impact to all the callers into the API. And so when I can have Claude help me generate the three different versions, it allowed us to have a debate of not only implementation, but also impact to the colleagues. So I think that's another really interesting kind of pivotal change. Um, so yeah, like, you know, when building is cheap, arguing expensive, again, how does that shift your team norms a bit? I do wanna call out this makes it even more important to make sure you set up team culture for how you think about alignment. For example, what totally won't fly is because code is, you know, so much [chuckles] faster for us to generate, it shouldn't be, like, the last person who check-in wins. You know? Like, "I'm gonna stay up at 3 PM to submit this PR. Set up a routine so that I get the last word in." So definitely a no-no. That makes it even more important to make sure you have good team culture that can have open, honest technical debates, but also a good team alignment. Ah, so I talked a lot about kind of what we reduce in, in planning. On Claude Code, we definitely have reduced the design doc before every code ritual. I would say certain teams and for definitely certain scenarios, it's still really important to think about design docs, especially as we're doing, like, kind of, like, async discussions. But on Claude Code, most of our discussions is, like, instead of a doc, a PR. That's kind of, like, one of the word we have of, "Hey, we've got an idea. Go prototype." That's the other thing. We don't really do a lot of product reviews because the landscape is changing fast. So let's prototype. Let's actually get a lot of internal ants using it, and I'm really a big fan of shipping it out to all of you and then hearing all the excellent feedback so that we can really... And, and again, like, that, that has changed our planning ritual to be a lot less design docs, and mostly [chuckles] discussions are in PRs or prototypes. Um, so we reduced that, but what did we double down on? And I think this is an area where we actually need to do more and continue being better. It's the verification. 'Cause again, it's like the throughput is different, um, and there are new ways to break. So how can you scale out? And I call it kind of shift left. Like, in the old days, you would get code out and, and I would love to- for me to find bugs before any of you find it. And what's better than [chuckles] me finding a bug is actually what I call shift left, like mo- more automation, so we catch it earlier to the source. So that is something that I think we need to continue to double down on. And the other thing that's interesting is also because roles are blurring, for example, my designers, like, I would love to have more [chuckles] confidence that when I checked in this code, I don't break something. Like, I remembered I fixed a, I, I fixed a bug in resume or something, and the next day, I was catching up on Boris's, you know, threads, and I saw someone tag him of, "I'm noticing a bug." I remembered having that sinking feeling. I don't know if y'all have, like, [gasps] Did I just catch a bug? [laughs] Like, so because of the throughput, like I just really wanna make sure everybody, regardless of roles, just has a lot higher confidence, um, for the change that they're putting in. Who made this change? And so my advice here is, again, because a lo- all our, all our [laughs] PRs are assisted by Claude, it's a little bit of an odder question. And so for us, what is more helpful than just that question is wh- what I call, like, double-clicking into it. Like, so in the old days when you used to ask, "Who made this change?" what question are you really trying to answer? Are you looking for who caused this regression? Definitely don't wanna blame, but just wanna know [laughs] who was the last person that touches code that might have caused this break. Or are you looking for an expert to answer a customer question, or are you looking to gain context? So whatever is that double-click question, also think about is there a way you can automate. It's funny, I mentioned I had to change a slide deck. When I started this talk about a month ago, part of my every morning is I would, you know, bring up my desktop code and go into here's the customer feedback channel, and I kinda wanna ask it to summarize and, and that was just a morning ritual I would do with my morning cup of coffee. Now it's routines, right? Like, I can set that up, and then even better than what [laughs] I had done before, which was how I kick it off, I'll be like, with my morning cup of coffee, I always get to kind of a pretty good overview. So that's my point of, like, code ownership is, is a little bit more fuzzy, but on the flip side, double-click to what question you're really trying to answer, and seeing how Claude can actually help you with those. How do you keep up with code reviews? So I'm really glad if y'all saw, uh, the keynote this morning. Kat talked about it. We definitely [laughs] leverage heavily Claude code review. Now, what's interesting is going to be where do you trust Claude, like a lot, but then where do you still want a human? And so for sure, like, you know, and actually Claude also, as Kat showed y'all, the, the, Claude also does a great job babysitting PRs, and so we definitely have Claude handle all the style and then lints and PR feedback requests, even, like, maybe catching some bugs and fixing them before it even, uh, does the full commit, and also, uh, adding tests. That's what, like, really what we've leaned heavily into Claude for. But where I still definitely want a human is that expertise. It's all about trust but verify. So for example, legal review, I always definitely wanna make sure I'm getting my legal partner still. Uh, it's, you know, like risk tolerance. So for example, trust boundaries and security-sensitive code, I still wanna make sure I'm pulling in the experts. Um, the other area which, which is kind of fun is also that product sense and taste. Like, I remember one of the hobby, like one of the fun things I like to, to use Claude for is I like to decorate Claude for the holidays or the seasons, and I remember last, uh, holiday, I wanted to update Claude in the terminal to, you know, give him a little holiday theme, and I asked Claude Code to me turn Claude into a snowman. Claude wasn't that good at ASCII art in those days, and I [laughs] remembered asking, that's where product sense really comes in, I asked my design partner, "Hey, can you review this for me?" And she gave me such good feedback. She's like, "You turned Claude into, like, the Mr. Peanut character." 'Cause I was trying to-

8. SPSpeaker15:31

   [laughing]

9. FFFiona Fung15:31

   ... make him snowmatch. I'm like, "Okay, I'm gonna do something more simple," so Claude was, like, ice blue with snowflake. But keep in mind kind of that product sense as well. Which leads me to what should my team makeup be? Because roles are blurring, Claude is augmenting. I'll share with you on Claude Code, there's two profiles for engineers that I've really heavily indexed on. One are, like, creative builders with product sense. Usually, you'll see these are, you know, the dreamers. There'll be a big sense of curiosity. You're really passionate about, "Oh, here's a problem. Here's a, maybe I could, you know, ship a product that solves that problem." But then there'll be a lot of iteration to make sure you're delivering a delightful experience. Um, the other one is deep systems expertise. So when I first joined Claude Code team, I noticed actually we were pretty good with product generalists and creative folks, but we were missing folks with, like, distributed systems expertise. And when you're building things like Claude Code Remote to ensure we can run Claudes everywhere, you really still need, um, those expertise-ers. So I would say, you know, whichever software engineering leads you're part of or, or supporting, think about those hard parts of where you might wanna continue to still double down. But for sure, what I index less, less on is raw throughput because thanks to the models, we're just a lot more, uh, efficient. The cross-functional gaps is another interesting one. So for example, I remembered I, I wanted to do an update to how we do survey responses, but I didn't have a dedicated content designer to work with me. And I'm a [laughs] engineer. My writing skills are quite terrible. I s- I struggle to write things in a short and succinct form. I don't want the surveys to, like, you know, overload you all in the terminal of, 'cause every line space is really important. But that's where Claude, like in the old days, I would be, "Who is a group of content designer I can work with and I can kind of give changes back and forth?" But now Claude has really helped me to augment that role and was a really good content design partner for me to kind of like make sure the verbiage is, is good and succinct. And on the flip side, like I say, a PM, our PMs code a lot, which is really fun to see. So again, like I, I would say with Claude, like you have non-traditional coders now being able to do more engineering, but you also have engineers that we can also now lean in to do things that was traditionally, you know, like not on the technical side, but more where the content or design. So it's very interesting. I found that Claude and AI has really augmented roles kind of like all around. This was a spicy one. Uh, so I'm def- like, I remember when I first joined Claude Code, everyone's like, "Okay, you're gonna grow the team by a certain amount." And I could tell recruiters were still using the typical, you know, 10 ICs to one manager, and then how do you start thinking about nesting? Um, I really have leaned into keeping it really scrappy. And actually maybe I would step back too, whether it's at Anthropic or Meta or Microsoft, whether it was like Visual Studio or Facebook Marketplace or AR/VR devices or Claude, like what I have found to really help me ship great product-It's heavy, heavy, heavy dogfooding, especially for leaders, where nowadays it's actually fun. I can still be in the code, but for a while it wasn't. And when you can't get your hands on the code, I would always make sure I have maker time so that I'm actually using my product days in, days out. And so that's why I wanted every manager on Claude Code to start out as an IC first, and also, like, earn some street cred with the team and, and really learn how to be an effective engineer. Uh, and, and then I really structure the org to be as flat as possible 'cause I want us to be super agile. This was just [laughs] ... My, my recruiters had some concerns, 'cause I remember they said, "You want to hire managers and they will start as an IC first? No manager will be interested in that." I'm like, "Well, this is what dogfooding on the Claude Code team's about, and this is what I expect, and if someone's not interested, it's better for us to do, uh, earlier separation." But also, again, this is, like, there's no way I would've been able to ramp or be able to do code 'cause my time is, you know, there's just a lot of context switching without Claude. And so for those of you in the room who are managers, I really, you know, like, encourage y'all to kind of like lean in. It's-- I'll, I'll be honest, for, for a long time at Meta, I would still try every year to do one PR, uh, a year just to ... But the, the code, the, the workflows would always change. Like, I, all the internal tools, like, by the time I learned one command, it would've changed. Nowadays, I don't even [laughs] remember Git commands. I just always ask Claude to, to help me out, out with all of that. Knowledge sharing. What becomes your new source of truth? So for example, on our team, on Claude Code, the code is a source of truth. That's why I would go back to when I'm, like, answering customer requests, I just have my desktop, Claude, uh, Claude desktop, Claude Code, and I have all my, you know, like, uh, local repositories to actually answer a lot of customer questions. So for us, just having that code base be the source of truth also, like, prevents some of the lag that you might have had before of how to keep up the documentation, you know, correct with the code. But I would say this is where it's like, do what makes sense for your team. So for example, if you still have a lot of really good specs, check those into the repositories and then have Claude lean in to help, you know, like, "Hey, you know, like, take a look at how ... Verify my code execution still matches what I expect on the spec." And so how did we roll it out? 'Cause these were, like, I had just gone through some of the norms that we had changed, and I think it's interesting. There's a blend of what do we kind of like mandate as team norms, like make sure you're gaining alignment with the team, and then where do I really enable each, you know, like we have pods within Claude Code. Wanna make sure I enable each pod to do what makes sense for them as well. So in terms of the balance, in terms of forcing function, it's align with the teams on the must-dos. So these are a few of the core Claude Code team principles that we really live and breathe. And by the way, if you remember, again, I'll, I'll go back to that growth mindset and always think about is something still serving you. We keep these up to date. So every few months we'll be like, "Hey, is this still having, you know, the same effect or serving the purpose that we wanted when we started it?" So for example, and I should replace this slide, it's not every engineer uses Claude Code. You know, that's obvious. It's actually every Claude Code team member, including cross-functional partners. And actually, we all use Cowork quite a bit too. Uh, Claudify everything you can. This is one thing where we're like, "You know what's better than one of us doing it? Having Claude." So always think about h- is there some way for you to automate, whether it's verification, more shift left. But always be thinking what you're doing something right now, is there some way that Claude could actually help you do it? And the last one's my favorite, explicit permission to kill old processes, 'cause again, processes will kill themselves. But as you're supporting teams, it's really important to always get that fast fee-feedback for your team of what are the things that, you know, like, are we sp- we're spending a lot... I'm actually, I remember when I first joined Claude Code, we used to do standups, and then the team got a little bit big, so then we had a spreadsheet. We, we would all put up our, you know, like, weekly proce- uh, progress. And all of a sudden we're like, "Oh, wait, we should just do a s- a, a, a skill," right? Like a, a standup script so then we can just run Claude and all of us can always be very, be much more kept aware of what everybody else is doing. So that's just an- another example of one day I remember looking at the spreadsheet going, "Wait, does this still make sense anymore?" So always question and always look to defrag and kill old processes. What I wanna make sure that I leave a lot of room for pods to adapt, it's, uh, for, for each team really has a lot of high agency for how, you know, they do triage or leverage Claude to do triage, any planning rituals or standups, how they think about on-calls, and also which workflows to Claudify first. So we don't usually mandate, "Thou shalt automate this." We have some suggestions and learnings, but always give room to your team, especially they may be, you know, touching on different, uh, problem areas. So if I zoom out, what were the three things I prioritize on, you know, I, I, when I joined Claude Code that I felt has made the biggest difference? Keeping the team as flat as possible, um, like managers really suppo- pods up work, but really keep it agile. So for example, on Cl- on Claude Code and Cowork, we have one overall team mission. 'Cause sometimes when you start creating pods, each pod then wants maybe to set up their own mission, and then anytime you have to shift, it might be take a lot of time to, to walk people through that. But it's really as flat as you can. I felt that served us really well. The Claudify everything better than you doing it, uh, see how Claude can help you. It really frees us up to do more of the harder work. And again, the processes, they do pile on, so I encourage you to kind of like work with your team to see what are the processes that actually you should be able to let go. So does it actually work? I can't go into the explicit numbers, but I think these are three general kind of metrics that you can look at as you're rolling out, you know, changes on your team that might start steering you to, yeah, this seems like it's kind of, uh, starting to be successful. The onboarding ramp-up time, that has dramatically reduced. Uh, so that's an interesting thing of like how soon an engineer or a designer or, you know, like a PM can start being effective on your team.Uh, the PR cycle time shortening. I think this one's interesting to double-click into a bit 'cause it's, it might actually help you identify a gap that's not just in terms of lack of AI adoption, but where the rest of the pipeline might be struggling to scale. So for example, again, as, as we're now, like, you know, just putting in so- through so much more code, sometimes the product infrastructure, can build and CI still keep up with the amount, uh, that engineers are checking in. Uh, so both of those should go down, but then what should go up a little bit is Claude-assisted commits. For example, for us, it's by default every commit is Claude-assisted. I don't think I've seen a non-Claude-assisted commit probably in the last four months or so. Um, but hopefully these three things are, are kind of like metrics that you can kind of take a look at, at your team and see how it resonates. I would also say, though, um, outside of just number of commit, also think about the end goal. Like, if you zoom out, what is the product that you're trying to make more delightful for users? Or what is the problem you're trying to solve? 'Cause sometimes you see it on all the headlines of, "This company said x percent of code is now generated by AI." I think throughput is great, but really think about how you measure what it is that you're actually really trying to solve. Like, for example, we really wanna make sure we're keeping an eye on quality and reliability, so those are some of the things that we're paying more attention to as well. Okay. So my last section is to audit your own efforts. I'll share with you transparently, actually, I still have a couple of questions that I am still asking myself. Um, the iOS and Android org is a very interesting one. Like, when engineers can now more efficiently kind of flex across different mobile platforms, does a more traditional way of, you know, uh, having an iOS team and an Android team still make sense? That's something that I'm still kind of thinking through. How much do you push that fully automated review? Again, like, when do you kinda strike that balance between fast enough and we lost something important? It goes back to the trust but verify. And what's interesting is you even might have heard today in earlier, Dara and Daniela's talk, the model capabilities do s- keep improving. So also, even if you might need to do more verify than, than trust for a certain section of work, that might also change with the next model, so that's why it's always important to reevaluate. And roles are blurring, so how do you make sure that everybody feels equally, uh, productive? So if I were to, uh, leave you with one, you know, thing to take back of is, you know, pick your noisiest workflow. And by noisiest workflow, it could be most expensive. What's something that, you know what, you [laughs] yourself might be dreading, or even your team might not really look forward to it? And ask, is this still really serving what's the purpose of there? Like, actually, I'll share another funny story. There was a team I was on where we used to have this weekly review. It's a very expensive review, like 50 people, you know, in this large room. And then I noticed everybody's on their laptops except for when it's their time to give status report. And then they're, they pop their head up, say the status, and then go back down. And I'm like, "This is a very expensive meeting." And I just asked that simple question of, "Why are we having it?" And just that one question, everybody's like, "Yeah, it's true." [laughs] And so we canceled it. So that's why it's always important to, to think. And, and so yeah, like I, I figured this might be something fun for you to take back and look and see what's one piece of workflow that you might consider can you either automate or maybe even is it still, you know, proving, uh, is it still serving its intended purpose? So with that, that's the end of our talk. I'm like, three minutes. [laughs]

10. SPSpeaker27:59

    [audience applauding]

11. FFFiona Fung28:01

    Thank you. Thank, um, thanks a lot for, thanks a lot for attending. I really, really for sure thought this room was gonna be empty, so thanks for-

12. SPSpeaker28:11

    [laughs]

13. FFFiona Fung28:11

    ... not having it by myself. And I'm around here today and tomorrow, so if you have any questions or wanna chat more, feel free to introduce yourself. I'm happy to chat. Thank you. [upbeat music]

Episode duration: 28:37