Music
Hey everyone!
Thank you, I didn't expect applause.
Well thank you so much for joining me today.
I'm excited to speak with all of you about, you know, some lessons I've learned
as I've been leading Cloud Code and Co-Work.
So actually, first I should do an intro.
So yeah, my name is Fiona Fung,
and I lead engineering and product for Cloud Code
and Co-Work.
And before Anthropic, I had also built and led teams
at Meta and Microsoft.
So with that, let's dive into some lessons
I'm excited to share with all of you.
Hopefully, maybe you'll find a couple of tidbits
that may be helpful to you.
So there are five topics I really wanna cover today.
The first is the bottlenecks have moved.
And so when the bottlenecks have moved and it shifted,
what are all the team norms that we felt,
oh yeah, we have to rewrite some of these
because it's changed.
How we rolled it out, I'll talk about like
how we rolled out some of these update team norms.
And in terms of the proof,
what were some signals that I feel,
okay, this has given me confidence
that we're trending in the right direction
and maybe I'll help you as well.
And lastly, I'll leave you all with maybe a topic
for you to all take back to your team
to discuss, because I love to hear about whether any of this resonated.
So with that, let's touch on this first topic, which is the shift.
So the bottlenecks have moved.
And you'll notice there's that little subtitle there of what served you prior may no longer
is one of my favorite sayings.
Like, actually, I think this is the muscle that has really helped me, whether it was
anthropic, but also before at the other companies, always being of that growth mindset.
Like, you know, from all the talks this morning,
you see a rate of change is just increasing.
And so I found it's always helpful to look at
what are either team norms that you've set up for your team
or team processes, and always ask yourself,
is it still serving its purpose?
So for years, many years,
engineering bandwidth was an expensive thing.
And when you think about how did we all do
software engineering, everything was around
kind of like protecting this resource, right?
Like, we want to do a lot of planning
is we want to make sure when we're building
that we have high confidence that we're building the right thing
or we want to do reviews.
There's a lot of action around when engineering bandwidth
was a limiting factor.
And maybe I'll pause there.
When you think about our industry,
this is not the first time that the bottleneck has shifted.
I'll take you all back in a time machine with me.
We'll go all the way back to the early 2000s.
And if you all remember, so back then I had just joined
Microsoft as Work and Visual Studio.
there was no such thing as cloud.
It sounds crazy now, right?
Like now cloud is so ubiquitous.
But back then there was no cloud.
And I remembered how we built Visual Studio
was this one server room, and everybody
had to be on call for a week.
And then you just go into this room,
and I remembered the whole build process.
It was a queue.
We can only merge six PRs at a time.
And anytime one of the tests would fail,
you have to debug which of those PRs caused that failure.
So back then, that was actually a big bottleneck.
And then now with Cloud and with Continuous Build,
that bottleneck has also shifted.
So this is just another shift for us
to think about of when coding is no longer the bottleneck,
what changes?
And so on the Cloud Code team, coding
is rarely the slow part anymore.
And so that's why all the upstream and all the downstream
kind of like processes, we felt like we've
had to change a little bit.
So as an example, what were some of the old bottlenecks?
like writing code, writing tests, refactoring.
In fact, I'll share a story with you all.
When I first run Cloud Code,
I wanted to onboard and fix some bugs.
And I thought, you know what I'm gonna try?
Test-driven development.
I remember that was a really big thing a while back.
You know, the idea is write the test first,
make sure it fails, then do the change,
then now you already have a test.
But it was kind of like eating broccoli, you know?
Like even though I actually really do love broccoli,
But I use that as an example.
But I remembered, it feels like getting broccoli
to write the test first, because it's not always
the most enjoyable part of the process.
And I remember always itching to build a product
and get to playing around with it.
And so now with Claude, I remembered the first bug.
I'm like, you know what?
I want to try test-driven development again.
Let's write the test, but first it will fail.
Let's verify it fails, because that's
how I could verify the test is actually testing something.
And then I remembered making the bug fix,
and then we already had a test.
And I remember that first experience, test-driven development
was actually so much more fun and so much more pleasurable.
It kind of took the tax out of test-driven development.
So that was a big a half for me.
Refactoring is another fun topic.
Like, I don't know if you all have felt this before,
but I've been on teams before where
we have to either do some big refactoring
or some software architecture cleanup.
And it's always a debate of when would we find time
to do this work.
This work that we know is so important,
But it always has to come off at the cost of trading time
to build product.
So again, thanks to the models and with cloud refactoring
is also no longer a bottleneck.
So now when those shifts happen, what
am I starting to see that as the new bottlenecks?
Verification, that's a big one.
A lot of it's because the bandwidth just increased so much.
We have to pay even more attention to, is it correct?
And I'll talk about this in a little bit.
But also when roles are blurring and more people
are checking in changes, we also want
to make sure everybody feels confident that their changes are correct. Who reviews? That's
a really popular topic. And also, how is it maintained? And this one is interesting because,
again, the throughput is now so much more, also have to think about, you know, the cost
of maintenance as well. So these were some of the old processes that we felt quietly
stopped working. And I love that phrase, quietly stops working. Because actually, if I step
back any time, you know, hopefully when somebody puts a process in place, it's to solve a
problem. But very often we forget to audit to go wait. Are those processes still required
or is it still serving its purpose? So, for example, what were some of the things that
we had to change? Planning norms. When coding is no longer, you know, the bottleneck and
not as like, and you have like much more coding bandwidth, how did we rethink through planning?
Ownership is also another interesting question.
Almost all the cloud code commits now are also co-authored by cloud.
I don't think I've in the last few months ever saw a commit that wasn't.
A code review is a good one.
Like that's a lot of questions I get a lot as well.
Also, team makeup.
Roles are blurring.
What are the skill sets that we're thinking, hey, you know what, these are actually skill
sets we're kind of like doubling down into.
And also knowledge sharing.
happens when maybe documentation is no longer your source of truth.
So given some of those shifts, these are some of the team norms that we had to rewrite.
We talked about code review and actually Cat this morning and the talk really talked about
clock code review as well.
That was a really, like that's how an amazing tool for us to make sure we're also doing
the right thing.
Onboarding has also changed.
I'll share with you all my onboarding story planning.
I've talked about this already, when coding is no longer bottleneck, how does that shift
our planning?
Hiring and also orkshape.
Orkshape is a fun one.
We really want to keep everybody more agile and flatter orgs, but every manager on Cloud
Code actually started as an IC first.
So with that, how have our planning and technical debates changed?
So in technical debate, code wins.
It's like building is cheap, our game is expensive.
I'll actually share with you all, like I remembered,
you know, as I was onboarding,
I also wanted to do some code refactoring.
I was kind of like, hey, what's some refactoring
that we think is good to do, but we haven't yet done.
And I remembered, me and Boris had a couple
of debates of approach.
And in the old days, I remember, and I almost did this.
I almost said, hey, Boris, let's just go to this meeting room
and go to whiteboard and whiteboard it out.
Almost did it.
And I'm like, wait, if, you know, with thanks to Claude,
I can actually generate, I remember generating
three different versions of the PRs.
And actually, that's what me and Boris used to have
a really good technical debate, because I wanted to not look
at how the code was implemented, but also impact
to the colleagues.
Prototyping is another good one.
So now, like any time we're really having an idea,
go ahead and prototype.
And let's actually go ahead and dog food it,
and then we'll try.
I remember many years ago also having this prototyping
conversation on another team I was at,
because there was a debate.
There were kind of two camps.
One camp of prototyping is great.
It allows you to move quickly, to build kind of like a war
skeleton and get a feel for the product.
But on the other camp, I think there was a concern.
Well, prototyping, you're kind of doing it with speed.
You're cutting corners.
And there's concern of what happens
when you show a prototype that kind of works.
And then maybe you get hung up on it.
You don't want to throw the code away.
And then you end up trying to ship that thing.
It's not built to scale.
Again, with Cloud, now actually prototyping
is a great way to get started because we could iterate and learn.
And then thanks to the model's help,
we can also then actually scale out a prototype to production
a lot faster.
So what's one thing we reduced on the Cloud Code team?
I might have been on teams before.
Maybe y'all as well, like design docs,
like really in-depth planning and design docs.
Most of our discussions actually happen in PRs or prototypes.
And again, that's just because the engineering bandwidth
is now increased and coding is no longer bottleneck.
What do we really want to double down on?
Verification.
And this is something that I want to make sure
me and our team keeps doing better as well.
Because now, with all the bandwidth,
these are more important to how do you verify quality?
And I call this shift left.
So for example, what's better than you running?
It really sucks for me when I hear from our customers
and developers and you all run into a code.
I'm always like, ah, I wish we caught it first.
But you know what's actually better than me running into the bug first?
Us having automation in place to actually catch it closer to the source.
So that's something that we're really constantly looking at as well of how to make sure we
keep shifting left and automating more.
Who made this change?
This used to be a question that a lot of folks would ask of, hey, who was the last person
that touched this or who's a code owner?
And now I encourage you all, like if you find yourself asking that question, to get to the
root of the question.
Like, what are you trying to answer?
Is it, are you looking for someone that cause a regression?
Are you looking for someone to answer a question?
Are you looking to gain context?
And is there a way that Claude could actually
help you with that?
Kat actually talked about routines as well, like earlier
today.
That's one of the routines I have set up.
Like, automatically, in the morning,
I like, over my morning cup of coffee,
I like to review all the feedback
in our various feedback channels.
So I have a routine that will go through to kind of amalgamate
all the feedback from me and help me to identify themes.
How do you keep up with code reviews?
Before we actually shipped Cloud Code Code Review,
this was a question that I would get all the time.
And now I can share that answer with you all.
Definitely, Cloud Code Code Review
is one tool that has really helped
us to make sure we keep up with the coding bandwidth.
And so where Cloud is really good, right?
Like the style and lint, obvious bugs.
Any time that you actually have, like, if there is a spec,
I encourage you to actually check the spec into your code base,
because Claude is very good about verifying against spectrift.
But it's still really important to still
have a human in the loop.
So where do we find even in code reviews
is really important for humans, still?
Legal reviews, anything that is actually about risk tolerance,
so especially when you look at trust boundaries,
it's all about that trust but verify,
and where humans bring a lot of the needed expertise.
Product sense and taste is another fun one.
So last December, I wanted to update Claude and our CLI
to give Claude a little holiday theme.
And I was ambitious.
I wanted to turn Claude into a snowman.
I coded up an example, and I asked her designer,
hey, can you go ahead and review this for me?
And she gave me such excellent feedback of, no,
this looks nothing like a snowman.
You turn Claude into Mr. Peanut.
I don't know if Mr. Peanut's an American brand.
And in the US, we have the Strat peanuts.
and their mascot is this little peanut character.
And I was like, holy crap, that's totally right.
I thought it was a nomad, but you're right, it's a peanut.
And so that's where humans also live with that product sense.
It's really important to keep that expertise in the loop
as well.
Now, what should my team make up be?
Because roles are blurring, and clog is augmenting.
And so when it comes to engineering,
these are the two profiles that I now really focus on.
One is creative builders with product sense.
And then another is deep system expertise.
And so this is definitely like the hard parts.
Want to make sure that we can still have that trust,
but verify.
Maybe I'll talk a little bit about product sense.
When I gave this talk in San Francisco,
afterwards a lot of engineers came up
to ask me a question of how do I build this product sense muscle.
So I figure I will share with you all of what I have found
helpful, and it's helpful for me.
And maybe it will resonate with you all.
Like for me, it's this muscle that you build
with, it first starts with dog fooding.
And especially for managers, actually,
like making sure you're spending time
using the product that you're building
and your team is building.
In fact, most of the time, any time I join a new team,
like that's one of the first things I do,
I'm like dog fooding the product
to make sure I understand it.
Cause this way you really start feeling your product
in your bones.
And you remember, you always ask yourself,
wait, when I was building this product,
what problem were we trying to solve?
Like, what experience was I trying to enable for our users?
So with that in mind, dog-fooding is a really good way,
especially for managers who, before a cloud,
you may not have time to be in the code base anymore.
But yeah, like, actually, anytime I join a team
and I would dog-food, a lot of team members
would always come up to me and say,
it's so awesome to see you using our product,
because you really care, because that's a way
for you to experience the work as well.
So for me, product sense comes from a lot of dog-fooding,
and then also iterating, shipping,
and then going out to speak to customers.
One of my personal passion projects
is working with small businesses.
I love small businesses.
I feel small businesses are the lifeblood that
forms our community.
And we actually just announced Claw for Small Business,
which is a project I'm so excited at.
But I have a lot of friends that run restaurants,
and they work incredibly hard.
And so I met with a lot of them to onboard them onto Co-Work.
Because I wanted to see how, like outside of enterprise,
with small businesses, how do our users actually onboard?
And I got such valuable feedback.
It's actually really humbling to see
where in the onboarding flow there
were so many things that we could have been doing better.
So I really encourage you all to dog food your product.
So then you really, I call it like feeling it in your bones,
because it really keeps you giving you
a sense of what your product is doing.
If not, after a while, you might find yourself making
product decisions.
That's all just based on either metrics or dashboards
or PowerPoints.
Definitely dog food, dog food, dog food.
Or as we call it, an anthropic ant food.
So filling cross-functional gaps with Claude.
This is interesting because I actually see this for all roles.
So for example, designers on Claude code team, previously,
anytime we wanted to make polish or UX fixes,
designers would go ahead and create that red line
and then hand it off to engineering.
And it's always a wait because engineering is always
about I have to build this product,
after the fix is bug, when will I time to actually do this polish?
Designers on Cloud Code actually use
Cloud to make a lot of those polish fixes,
so then it really closes that iterative loop a lot faster.
And again, this goes into why it's so important
to do the verification.
On the flip side, for me, for example, one time I was fixing
a bug and I needed a little bit of content help.
I don't know about you all, but as an engineer,
I tend to be very verbose.
And when I'm like, if you ask me to write a very short sentence
to describe what something's supposed to do.
I tend to go too much into the weeds.
But Cloud was a really great content design partner for me.
And so that's what I found really interesting on Cloud Code
team.
For all roles, Cloud is actually augmenting all the areas
where you may not be as strong.
So this was the manager slide that I was like, oh,
this was maybe a good spicy topic.
But when I first joined Cloud Code,
this was one of the first things I changed.
I was like, hey, I was working with a recruiting team
to go because I believe so much in dog fooding.
And on Cloud Code, we're using Cloud to build
Cloud, we're using Cloud Code to build Cloud Code.
And so every manager start is an IC first.
I actually felt this worked really well
because enabled managers, before you
have to worry about the responsibility of supporting
people, actually having time to roll up your sleeves
and get into the code base and learn what it's like to be
an engineer on the team.
Maybe I'll also touch on, this is also a great time
that if you're a manager to actually get some maker hours back
and actually get back into the code base,
because the onboarding is a lot less daunting than it used to be.
Actually, even before Anthropic, there
were different roles I've had where I've switched between manager and IC.
And I think every time I switched to an IC,
it really helped me build up the engineering toolbox.
But that onboarding was always a little bit,
that slight hesitation, because it could be daunting
if you haven't done it in a while.
But speaking for myself, I remember when I onboarded to Cloud,
it was such a different experience.
And actually, that's where I'll go into next.
So in terms of knowledge sharing,
what becomes a new source of truth?
So when I was onboarding to Cod,
the code is our source of truth.
And so again, like in the old days,
anytime I joined a new team,
I'd meet with all the engineers to,
I still do meet with all the engineers on the team,
but now we talk a lot more about what's on top of minds.
And because before I would always do these tech deep dives.
And now, I actually did my first, you know, like TechDeep dive just with Claude,
like because Claude is really good at answering all these questions I have.
So even when I was doing that first bug fix, I remember asking Claude,
hey, before I dive into this bug fix,
can you actually teach me a little bit about the surface area
and also what about all the areas around that bug as well?
And so for Claude code and co-work team, or code is a source of truth,
I would encourage all of your teams, like if whatever is your source of truth,
whether it's a spec, you might actually change that into a skill that you check into the
code base.
Like whatever you can make sure becomes your source of truth, keep it in the code base,
because this way you can actually keep it up to date.
Because that's the other thing, when coding, you know, bandwidth is so much, you know,
like so much more, it also makes it easier for any documentation that also isn't part
of the update loop to get out of date.
So how did we roll out all these changes on the Cloud Code team?
There were things that was really important that we aligned as a team.
And then there's also, I want to make sure, we also give space for bottoms up, because
each team is focused on different things, and there might be, you know, like different
tool chains or anything that resonates more with each team.
So what did we align with kind of like the teams as a must-do?
These are some of our Cloud Code team principles and what we call forcing function.
And this slide is out of date.
Like I shouldn't put every engineer, every teammate uses Cloud Code and also co-work,
So like us using our product day-in-day has been really important.
Clarify everything we can.
And so like anytime we have a question of, you know what, yeah, I'm doing this.
What's better than me doing it?
Can Cloud do it for me?
Because then it actually frees up more my bandwidth for other problems to solve.
And my last one is explicit permission to kill old processes.
Again, it's the even our team principles and even processes as we put on.
Even after a few months when we notice, hey, is this really serving some tender purpose?
We really always give ourselves permission to always critique
and make sure to always revisit.
And bottoms up, there's a lot of freedom for team or pods
to adapt.
So for example, how Cloud shows up in Team Triage,
or any teams like planning rituals or standups,
or which workflows get cloudified first,
that is a lot of bottoms up.
So I found this balance of make sure
you align with the team in terms of what's important in terms
of team culture and also update those as you go.
but then leave some room for each pod to adapt.
So if I zoom out, what were the three things
that I prioritize for Cloud Code and Co-Work
that I think has worked really well?
Number one, it was keeping the org agile
and as flat as possible, having managers also
support pods of work, but also really
get into the co-base and be directly
responsible for parts of the product as well.
Number two, that's our Cloudify.
So if Cloud can do it, Cloud should.
So that's always a question we're asking.
And maybe that's the other interesting, too.
Like this morning, you heard the talks about the models.
The models are improving at an amazing pace.
So sometimes we might find even if Claude wasn't good
at doing something two or three months ago,
now with a model update, it's actually gone really good.
And this is why, again, it always goes back to that whole,
like always revisit and always have the growth mindset
because the models are also improving really fast.
And again, people don't delete processes on their own.
they tend to pile up.
I remember I was on a team where we had so many different SLAs.
There was an SLA for P0 bugs, an SLA for incident response.
And after a while, I'm like, with all these SLAs,
I need a stack rank list to actually have,
because even the engineers are coming to me going,
there's only 24 hours in a day.
Like, which SLA am I supposed to do?
But that's why it's always so important to audit.
I remember at that time, I'm like, you know what?
We really should be auditing.
Are all these SLAs still really necessary?
So now for the proof. What are some signals that we're seeing, like, is it actually working?
So these are some numbers that I find is helpful that I wanted to share with you all. And so
these were some of the shifts we've seen as we've been kind of improving our workflows.
Onboarding ramp up time goes down. I think that's actually a really good signal of, like,
we used to have this thing of, like, what's the span of time it takes for the engineer
to land their first PR.
The onboarding ramp up time and also costs to other team members we know this keeps
going down.
Like, I even, like, a lot of times, sometimes when a person joins a team that asks me a
question, I'm like, that's a great question.
We should ask Claude.
Like, that's how we kind of, like, Claude has really helped us to onboard and answer
a lot of questions.
Which is also why for the managers, it's why it's fun for me to actually get back to the
code base.
Because in the old days, I would actually feel bad because I feel like, oh, I need to
to learn this area.
I'm going to ask an engineer and take time away from their day
because they're all so busy.
But now thanks to Cloud, I don't feel
like I'm wasting anybody's time.
The PR cycle time should also go down.
But this one's interesting.
It's important for you to not just look at the end to end,
but actually break it out into what
are all the different funnels in terms of a PR.
Because if your PR cycle time isn't going down,
it might not mean you're not adopting AI.
It could be other parts of your queue
is actually getting jammed up because of all the throughput.
So for example, are your build NCI systems keeping up?
So for pericycle time, I think it's actually really healthy
to break it down into all the different chunks
and seeing which of those you might be able to improve
or automate.
And lastly, Clawed Assisted Commits Go Up.
As I mentioned, I don't think I've ever, like in the last few
months, I've not seen a commit that wasn't
assisted by Clawed.
But if I step out, I would say what's even more important
than just throughput is whatever you and your team
are trying to solve, whatever the product or problem,
find some way to measure that.
Because outside of just throughput,
hopefully we're also making meaningful change
to make the product better or improve quality.
OK, so now it's time for me to maybe share a little takeaway
home exercise that might be fun for you to take back
and go have discussions with your team.
But first, I want to be really transparent.
I still have questions as well.
So I'll share with some of those that we're still
working out through the Cloud Code team.
So for example, do you still need separate iOS and Android
orcs?
That was more of the traditional org approach.
If you would usually have one for iOS, one for Android.
But now with Cloud and enabling our engineers
to go flex across different mobile platforms,
we're thinking, hey, do we really still
need two separate mobile teams?
How far do you push for the automated reviews?
We always want to make sure we're striking that right balance
between speed and fast enough.
and make sure we're not losing something important.
And roles are blurring.
And how do we make sure everybody is productive?
And that's why we're right now looking through,
verification is a big one, so that, hey,
as we're going through, make sure everybody that makes
a change has confidence in their change.
But also, what are all the different parts
of the workflow too?
Like I'm working with my designers.
We actually just announced Claude design.
Also thinking through, how can we make sure
that we're also improving the workflows of all the functions
on the team?
So with that, this is what I would love to leave you all with.
Pick your noisiest workflow.
Or it could be just some workflow or team meeting
that you don't particularly enjoy,
or it's really high tax on the team.
Like, I remember I was on another team
where we would have this really expensive weekly meeting,
and I noticed everybody's on their laptop.
And, you know, except for when they have to pop their head up
to give status, and then they go back to their laptop.
I'm like, this is when you count, you know,
like how many people's in this room?
This is a very expensive room.
So I always, like, kind of like pick a workflow
and always ask yourself, is it still serving its purpose?
Or if it's really expensive, is it something
that Claude might be able to help you with?
And kind of do this one step at a time.
And with that, thank you so much for listening to my talk.
It's been a pleasure.
Thank you.