Yenny Cheung: becoming AI-native

00:00Host

Combinator

00:02Yenny Cheung

Hi, how's it going?

00:03Host

Good, welcome to the Swig podcast. Uh

00:06Yenny Cheung

Thank you for having me.

00:07Host

Good to see you again. we've met, I don't know if you remember, we met at a Lift Dev event in I think in Germany or in London, I'm not sure.

00:15Yenny Cheung

Yeah, that's right.

00:16Host

And since then I've been following your career, very interesting moves and companies. and now you're at the Bluefish AI.

00:26Yenny Cheung

Mhm.

00:26Host

That's right.

00:27Yenny Cheung

Can you tell us a bit more about yourself? Like a few you a few seconds of introduction and about Bluefish and what you're focused on at the moment.

00:35Host

Yeah, definitely. My name is Yennie Cheung. I'm currently VP of engineering at Bluefish AI. What we do, we're the Fortune 500 marketing platform and we are hinged upon the AI channels. So our product provides visibility, favorability, different a set of metrics to help our customers find out how they're faring in the new geo and AEO world when previously it's just SEO. We can see that search is really changing the landscape dramatically over the past two or three years, right? So we're well positioned to capture that opportunity.

And for myself, my career, I spent my time working for B2B category creating companies, scaling companies from series A all the way to series D plus. And so I've seen a couple of times first hand what kind of engineering bets is necessary for what stage. And Bluefish is a very exciting opportunity. So happy to tell you more about what we're trying out.

01:39Yenny Cheung

Very cool, very interesting. So in in the prep discussion we had, you told me you're already 40 engineers at Bluefish, right? Growing fast. And that AI is already your biggest code contributor. so I'm interested to know what does it mean in terms of your day-to-day? How does it actually look like for people who are you know, moving and evolving towards AI nativeness? How does it How does it look like?

02:07Host

Mhm. Yeah, the team has grown really fast from 12 engineers at the time we have one big team to 40 and we have several teams now with their own workflow, right? So, a lot of the AI usage is already baked into the SDLC in the software development life cycle. So, from like all the way from product and design taking up problem areas, doing prototyping, getting early feedback to the way we would do specs, right, together. Both on the product side as well as engineering side to use that as a companion, right, to define how good would look like for these documents.

All the way to feeding that in, you know, spec-driven development, into code generation, into development, as well as to code review. And then also in terms of deployment and we also adopt some of the practices there. So, I would say day-to-day there are multiple touch points for AI, but it's done in a way where it helps us work, right, instead of us working for the AI. That's how we would want to view it.

03:19Yenny Cheung

If you're already there, that's already a great progress. I think a lot of us are still working for AI, so good to learn about that. so, when did you realize it wasn't just about, you know, adding new tools in the SDLC, but actually changing how the whole team, right, thinks and works?

03:38Host

Mhm. So, very early on in the AI hype, there's talk, especially from the investment side, right, that AI is going to just replace our jobs. Well, you and I as well. But it's really exaggerated. You know, the whole company now run by one person or, you know, half a person and so from that thinking from an engineering mindset, for me it's always thinking about that what what problem set is this agentic coding paradigm trying to solve and what are the areas that we can automate and do a good job of and what not, right?

So, quite soon enough in Blue Vision our organization along with technical leadership, we see that the opportunity there is still the same as how we would do engineering management before, but from a different perspective. What I mean is that the problems have always been there. For example, code review quality control or how can we make sure that we have better documentation? How can we make sure we have the the code the code that we have written matches with the spec spec that we have laid out to solve, right? Or the business requirements. These are problems that exist in the past, but now there's just an entire way of solving it.

Now, instead of just a point solution that happens when there's smaller pockets of innovation and disruption, this one feels like it's actually changing the way work can be done at all of these stages. So, that's why that's how we approach that thinking. But it actually doesn't deviate too much from the way traditional engineering management would think about in solving problems and doing it in such a way that we look at bottlenecks, right?

05:32Yenny Cheung

All right. So, let's talk about and we'll go back into the actual process of evolving towards these processes, but I'm I'm curious about the mindset.

05:43Host

Mhm.

05:44Yenny Cheung

And the cultural aspects of this shift because, you know, you're you're quite a new newer like a new company, but still this whole new SDLC is is is rather new as well.

05:56Host

Mhm.

05:56Yenny Cheung

So, were there any folks at Bluefish on your team who couldn't make the shift or needed help in that transition?

06:04Host

Yeah. I would say the DNA of Bluefish helps with change fairly well. And that's also one thing we have done well and how we have created the culture and how we have hired. So, intrinsically folks are open to that. That said, like we're also very conscious in creating a culture where we use AI and not AI uses us. I'll elaborate that a little bit more. You know, the class of thinking of AI just replaces our job, right?

06:39Yenny Cheung

Right.

06:40Host

I think in a way that feels like we're just giving AI control and let's see what happens and let it find out, right? But our way is actually more controlled. And the way we think about AI is how can we actually hit the same set of KPI, but with better tooling?

06:55Yenny Cheung

You like

06:55Host

So, in this frame of in this framework of thinking, then I see less that there are folks might not be able to catch up to the AI wave, but more like do people have the level of curiosity and also the tolerance for change to learn new things. And that's something that I would have required of all engineers and not specifically just for AI.

07:22Yenny Cheung

Yeah, for sure. do you have also like existential discussions about the role developers and you know, this kind of like stress of like FOMO of the new technologies, you know, coming up every other week?

07:35Host

Yeah, like whenever we have a team meeting, that comes up on you know, is there a world where we can really let AI do end-to-end development without as much human in the loop and discussions like that? Where we have landed on at the moment is more we for code that goes into production, we still need human in the loop and we still need to have that discipline to make sure quality is high with human input. But then we have also created some pockets.

For example, we do demos or we do prototypes and things that are more separated out in the platform or in the application that we're willing to Okay, then we put in some hardcoded material in there provided that it doesn't interact with like compliance or security concern. So, that's how we think about that.

08:26Yenny Cheung

Understood. So, when we talked previously, you told me about different stages, right? Of evolution of how do you take an engineering organizations toward this process of evolving towards AI native- nativeness. So, if you were to break it down into these stages, what would be the crawl, walk, run, if you will, of AI modernizations for engineering teams? And what does it look like?

08:53Host

Yeah. for me, the crawl phase would be earlier usage of AI tooling and you have many different versions happening locally, right? people want to try Cursor. Okay, we use Cursor. Someone used Copilot The other one uses Copilot, for example. And people are experimenting and trying to find the norm of what works well and what doesn't. but there isn't any rules around that or centralization, I think. And then for the walk phase, this starts to come into being where we start establishing new rules, right? Okay, we see that a skill is useful for code review. Let's do one for TypeScript, one for Python.

We bake in all our thinking of how good looks like into that so that we have some standardization. We agree to use that as a team in part of the process and we can agree with that in within multiple teams, not just within one team's process. And then for a run, I would say this scope expands also to other departments. For example, with we also work closely with our business teams, right? They also advise our customers. They're very close and they do automation. So, how can we also establish a framework of governance with other departments? Now, they also want to write code some apps, right?

What do we do and what's our role in engineering and to figure out that step?

10:20Yenny Cheung

How How often do you break and rebuild some of these processes that you're now establishing? Is it like a very fast iterations or you have time to see it coming and then rethink

10:32Host

I would say. If you ask me like what Everybody's like processes like I don't think I have a good answer. Like we we still have different pockets. Like some in the phase one, the crawl phase. Some, you know, some processes are more in the walk phase or already where we have some agreement and then we're still figuring out the run step.

10:53Yenny Cheung

Yeah, and that brings us to another questions which is measurement in general, right? We we want our works to be measured and have like clear KPIs. So, how do you actually measure that? How do you know it's working?

11:07Host

Yeah. It is pretty early to say something. One thing that I One of the frameworks that I saw being quite helpful is one from DX. So, they break down the measurements into three bigger buckets. That's also how I would think about measuring that within the organization. One is on the utilization. So, how many people actually use the tool? It's pretty simple. Like we look at the code contribution as well. but that is more a leading indicator to see, okay, there's some degree of adoption. And another one is impact. That one actually doesn't deviate too much from the aura that we historically have.

I still track the same set of KPI on deployment frequency, on change failure rate, on that set of metrics. plus a few additional ones. For example, we do have monthly surveys asking our engineers how much time does AI improve your productivity. So far, we have some findings. Only 25 I know, only a 10% of our engineers mentioned the productivity gain is under 25%. So, I think people view that like pretty favorably. And the last set of metrics would be on cost. That's also something that we're keeping more of an eye on. There's this token maxing phenomenon. Also saw the situation uh

12:35Yenny Cheung

[laughter]

12:36Host

And maybe some other companies you know, struggling with this this pillar now. That's something that we're also monitoring. We definitely see the cost going up there. so, we're not any We're not implementing much control yet, but that's something to monitor.

12:53Yenny Cheung

Right. so, I want to combine two questions they had. And once one of it you already answered somehow is about the the the human judgment in all that process, right? So, where where is it still very important and and prominent for you? And also, with the pace of things, right? Code is going up very fast. It's being written very fast. How do you keep things from going out of control if there is a way to to call it this way?

13:22Host

Yeah. That's that's also something that is pretty much on our minds. The way I think about this, AI sometimes lacks the taste. Like when you're writing, right? When we're writing, like for example, publishing to LinkedIn. Well, we do that first iteration and just put in the right places. Yeah, right, exactly. And that's the same for code as well. And so, all of these measures that we're doing to give it an MD or to, you know, have a code review skill is to tune or help the AI acquire that bit of the taste. And you can do a SharePoint presentation in 15 seconds, right? With with Claude.

But what comes out of it is often times a bit tasteless, in my opinion. Right? It's like 80% correct, but like that 20% is just not there. So, that's that's what we're, focusing on. I still think that that adjustment of taste and that deviation of 20% is what we try to minimize, right? When we use AI tooling.

14:30Yenny Cheung

I I recently saw a post on social media saying we're in the worst era of design because everybody's using AI-generated designs and all the, like, the flyers look like, uh,

14:40Host

[laughter]

14:41Yenny Cheung

A bit, right? It's like imagine that I had to code as well. But we did do some adjustment in the process. So, previously, we have a more free-flowing RFC process where okay, I trust the engineer to pick the right people to review and so on. But gradually, I also noticed that every day we started having two, three RFCs, actually. [laughter] Like the speed is quite fast. And like you say, sometimes it also starts spinning out of control.

So, now we we are creating a bit better governance to make sure we have a review process a bit more in place to make sure that we actually spend a bit more time on that step and we can save more time actually in the coding part cuz that's not really the bottom neck. It's solving the right problem in the right way. And that is something I mean AI can help you flesh out the RFC, but you need to have a clear thinking to give to the AI to help you do that, right?

15:41Host

All right. So, part of the podcast idea is also for having, you know, and as you're talking I'm thinking about other engineering managers who are, you know, who will be watching and learning from that. so, we're we're all trying to like learn one from the other. if there is something that you would say in terms of guaranteed way of an engineering team would fail, right? In their quest for AI modernization. what not to do, right? In that can be a managerial aspect of how to deal with people or a process that you've tried and it's like a a assured failure. Do you have something in mind for that?

16:24Yenny Cheung

I think I wouldn't let the phase of just let let everybody do what they want go for a very long time.

16:36Host

Mhm.

16:36Yenny Cheung

I do think that engineering management's role is to facilitate the storming phase of teams. Right now, I see that as a storming phase, right? People figuring out how to best use the tool in the most productive way. So, our role is to provide that guidance. We should be setting up this this governance framework and set out guidance on what is a good thing to do and what is a not so good thing to do quite fast and react to it very fast.

17:02Host

Right.

17:03Yenny Cheung

So, I would say

17:04Host

It's finding the balance between, you know, giving freedom to your people and being innovative and so on and having the framework that keeps things in order in a way. Am I wrong?

17:14Yenny Cheung

Right. Like if we have a two or three people team, then yeah, maybe every day can be five coding and you can iterate very fast. Everybody can just put things into the product. We are 40 people and we serve Fortune 500. They cannot just see a five coded feature out of nowhere with no communication with other teams. So, we still have to we have to kind of recreate the process as we go because the speed of things happening is faster. Then how can we make sure we still communicate to the customer what value they're getting from our features faster in a more automated way?

Or we have seen some business teams now also doing their apps to help with their productivity. How much governance, like what how do we differentiate the ownership pattern? How much engineering should be responsible for? How much they should be responsible for maintaining also the applications that they built? These are things that we need to set governance framework on day after day then, right? And not just let it for Okay, just let it run loose. Right? And see see what happens, right? I think that is not a not a the greatest idea to let that out for too long.

18:21Host

And you told me you actually hired someone full-time to help drive this process. And so, can you let let tell us what, you know, what made you realize you needed that person? what what's their role? How's their impact is being measured?

18:36Yenny Cheung

Yeah. So, I have seen a couple of cases of that in some companies. For example, as for example, in Plana and also other teams I I know, they started having an AI platform or AI productivity team to more full-time dedicate to automation and developer productivity. that's an idea that I'm I'm I feel very positive about because that allows the person to have the time and space to think deeply about, you know, how do we set up the right incentive framework that we discussed, right? often times if it's after thought, it doesn't quite work. And hence, we open up this role. And I've seen that trend actually picking up as well.

Now, what are they supposed to do? It's to I I can even share right in our interview process we did a path to production exercise.

19:37Host

Yeah.

19:37Yenny Cheung

Where they talk about in their past experience with AI or without how they have optimized the flow for engineers. So, it's really a developer productivity DX type of role that we're looking for. Now, last time I also alluded to that hiring this person has been challenging. And I was very particular about like the kind of profile I'm looking for. Because on one hand, this person needs to have change management experience. You're We're setting rules as we go. And we often times that means we need to say no, or that means we need to come up with new strategies on how to navigate situations and create possibilities.

It's you know, there's a lot of nuance into handling people, collaboration, and how to convince other people. So, this person ideally should have management experience or at least strong leadership sense. But at the same time, they also have to be really hands-on

20:36Host

[laughter]

20:36Yenny Cheung

Because then you got to you know, implement solutions as you go. And you cannot just rely on other people to do that for you. So, that's what we explicitly looked for. And yeah, we we found someone there.

20:50Host

But you

20:51Yenny Cheung

[laughter]

20:51Host

I think when I talked to the recruiter, she's like, "Do you Do you really expect we can

20:57Yenny Cheung

[laughter]

20:57Host

Find someone like that?"

20:59Yenny Cheung

Okay. I guess you knew what you wanted. so, what are the thing I'm I am assuming there are many of those, but what are the things that you haven't the thing you haven't figured out yet in this change, right? Is there something on your mind specifically that you are struggling with?

21:16Host

Yeah, I think now we're trying to tackle the open point on how our positioning should be with regards to other departments innovation and applications and automation state built. So, internally I'm confident. Like over time we keep on doing this bottleneck analysis. We keep cracking at automation. That's something engineers are historically good at doing. And we have hired some strong foundation engineers with strong foundation. So, I'm not too worried. But the one that we really need to create maybe new new innovation on how we would govern is with other business teams.

21:59Yenny Cheung

Mhm.

21:59Host

In no other world possible before that they could have built apps themselves without maybe sometimes talking to product engineering. They just have solutions. [laughter] So, how we you know, how how can we one best support them, but at the same time also help us to make sure that we reduce risk in times of security in terms of compliance, right? So, we we need to have a degree of some some some Like we we need to be able to know what's going on, right? And be part of that process, but at the same time in a non-blocking way. That I don't think that we have a very clear answer across the industries on how to do that at scale yet.

And that's something we're actively trying to figure out, right?

22:51Yenny Cheung

That's super interesting what you're saying and basically you have much more than 40 engineers in the whole organization.

22:58Host

[laughter]

22:59Yenny Cheung

All right, interesting. All right, to like to end this discussion, you started by telling us about your you know, your career path. So now [clears throat] it's interesting for me to like have your two cents on how your your job, your engineering manager, you know, is evolving and how do you personally take this change and you know, now you have to manage people and AI and processes. You rethink everything you've learned, right? The same way engineers need to like rebuild themselves around these new technologies. There is a rebuild of the engineering manager in terms of what do they need to manage and what to care about.

So can you like tell us a bit more about that in a philosophical way?

23:45Host

Sure.

23:45Yenny Cheung

[laughter]

23:47Host

I I can always talk philosophically.

23:49Yenny Cheung

You're good.

23:49Host

So like I mean there are two two perspectives, right? One is in terms of the engineering culture we want to create. Second is how we use AI in our personal workflow and also helping us become more productive. So on the first area I think more of our attention actually get put into how can we incentivize the right things to happen in the organization? Because we see a lot in the news like one organization goes completely AI-pilled and then you know, almost like every every one is like forced to do AI in a certain way and or maybe even doing a lot of labeling to to get this to work, right? So there like some extremes as well.

And having AI taking over, I think our approach as of the current moment, right, is still how can we encourage engineers to do good work. And we are deliberately not prescriptive as to what tooling they should be using, but we provide everything. Like we have learning sessions, we have guides on how to set up all the MCPs. Everything is out there for people to adopt, but in the end we still want to emphasize good work, business outcome, customer outcome is the most important. And that's something we really want to emphasize. Because of this taste topic we we discussed.

25:17Yenny Cheung

Yes.

25:17Host

Right? Like we we I don't care about like whether how much token Well, unless you really blow it up, right? How much token you use, but in the end is it good work, right? That's what we care about. And we spend a lot of time thinking about like how do we best convey that, right?

25:32Yenny Cheung

Yeah.

25:33Host

So, that's one thing. Hm?

25:35Yenny Cheung

What is good, what is taste? That's the good interesting questions that you have on your mind all the time.

25:41Host

Right? Because it can also exacerbate the bad. I think that's what this AI does, right? So, how can we emphasize the good and paint a picture of how good looks like? And that's almost like tool agnostic. But of course, I'm very about the good use of AI can help people become good, right? But setting the right bar and communicating that bar remains our focus. And the second area is how can we become more productive? Then Yeah, we also use a lot of CP. I I also have I have a daily digest now inspired by James Denier's personal newsletter, I think. He mentioned some advice advisory council or some automation.

I also have that where it gives me the top five things I should pay attention to in email, in Renola, in GitHub, in Jira. Like I don't have enough hours in a day to look at the work of 40 engineers anymore. Like 40 engineers 5 years ago is just very different from today. So, that has helped me have a better grasp of the organization. And that has also helped our EMs in, you know, creating processes and communicating.

26:56Yenny Cheung

All right, Ginny. Thank you so much for joining the podcast. I have personally learned a lot through your journey, and I think it's going to be We could do the the same podcast 3 months from now, probably different answers. And

27:10Host

[laughter]

27:11Yenny Cheung

And probably we'll be like, "No, this is all nonsense now. This is a new era."

27:15Host

The Now everything is recorded, so we can check.

27:18Yenny Cheung

All right. Sounds good.

27:20Host

Thank you so much, and see you soon.

27:23Yenny Cheung

Thank you as well. Thanks for having me.