Travis Isaacs | Building an AI-Native Team: 5 Lessons So Far

Speaker 1

Okay, y'all.

Who who feels like you just took a nice deep drink off of a giant product fire hose? It's a lot. Right? Is anyone else in this audience thinking how the hell do I get that library room?

Or is that just me? Because that room looked cozy. I wanna go lay in that. I'm gonna go take a nap in that room.

Okay. Listen. We gotta get on with this because this is a really cool thing user testing has done. They have not only given you guys a glimpse into some of the amazing products.

Hopefully, you got a snap of that QR code that you are going to be able to dive in and use directly. But they're also bringing folks just like you who are doing the hard things and they are getting the things done and they're bringing their best practices directly to you. And that's why I am going to be introducing mister Travis Isaacs, who really does sit at that intersection of how to make his team AI native. So come on.

Speaker 2

Thank you all so much for being here. I am super excited. There are a couple of things that you should know about me. One, I am a radical optimist, maybe annoyingly so.

Two, the production team told me no busy patterns or bright colors on my jacket.

But more importantly, I lead an amazing global team of researchers, product designers, and industrial designers for Cisco.

We build collaboration experiences that span hybrid work, customer experience, and in room workspaces.

Another thing you should know about me is I have spent the last year obsessively transforming my organization to create more leverage. And what I mean by leverage is, how do we maximize our impact through what we work on, how we work, our culture, and our talent? And I have learned that how hard you can push is often amplified by where you stand.

It goes without saying, things are super different than they were even a year ago. I'm a product designer by trade. I spent the first twenty years of my career learning every technique, every new tool, everything had to be perfect.

And now, I find myself in a world where anyone can rent a factory for twenty bucks a month.

And, like, it only makes dupes, and it's kind of just okay, but it feels like that doesn't matter.

Not only that, there are big implications for AI. I'm not here to get you to take a position.

So I found myself having to make a choice. In fact, no choice was not an option.

Do I usher in ruthless automation?

Do I hope that it all blows over and we'll all come to our senses and go back to the way things used to be?

Or do I lead?

And I'm making a choice to lead.

Now, the next thing you should know about me is I am a big fan of learning out loud.

In fact, most of my career, I never wanted to be a leader or a manager at all. I actively avoided it.

And I feel like it's a muscle that I've had to build. It's a skill that I've had to learn.

And a big part of that is failure. I have made a ton of mistakes becoming the leader I am today.

This talk came to be, and this is I am not making this up. I had dinner and a Kraken game with the user testing team and Eric. And I was telling him about how much I was struggling going through this, and they were like, that would make a great talk.

So I wanna share this with you, because my assumption And everyone in this room, you're either a people leader with the same struggles, or you're being asked to transform by your people leader, and they suck at it. I was him. I was him.

I wanna ground us in a couple of things. When I say transforming my organization to AI native, what do I mean?

And the simplest definition I can give you is, one, the behavior shift.

Your efforts shift from make to supervise.

Output.

Gone are the discrete handoffs, or the phase one, phase two. Everything is a loop, and the frequency and amplitude of that loop only gets faster.

And most importantly, at least to me, is craft. Taste and judgment are applied through discernment rather than manipulation. No more hands on keyboard, hands and scissors. It is really about telling something something else what to do.

And that brings me to my first lesson.

The bottleneck that I found was mindset and not tools.

And I realized the irony that we're at an enterprise software conference and we're talking about tools.

So, what did I do?

I focused on the tools.

I rolled out everything in my org. We have Codecs, we have Figma Make, we have Cursor. And in fact, when I would poke around on my team, it's like, what do we need to get moving? And there was always another tool.

That did not fix it. The team did not become AI native because we rolled out these tools in my org. And this is when I discovered mistake that I had made.

While I was focusing on procurement and licensing and rolling out tools and reducing the friction there, my team was telling me that they needed something different at this moment.

They needed a resolution in the tension that they were feeling between what I'm asking them to do and craft.

They wanted to be assured that their value was no longer tied to that hands on keyboard making.

And most importantly, they wanted a safe place to land. When you feel like the ground is moving underneath you, then the last thing that you want is a new tool.

But most importantly, the mindset shift was the biggest gap. This moving from this mindset of maker to supervisor is not easy.

Part of what really helped here was actually defining what craft means in this age.

When you're the human in the loop, what are you bringing to the loop?

Well, you're bringing empathy, a genuine understanding of feeling and emotion.

You're bringing context, situational awareness. You know your product. You know your customers. You know business.

You're bringing creativity. You're adding new and novel ideas, unexpected connections, and transforming outputs into surprise and delight.

You bring taste. You know what style and judgment to apply to what it is that you're building. You get to define what good looks like and tell the agent when it's done.

But most importantly, you have the unique ability to turn your work, your output, into storytelling that inspires people, aligns, and drives change.

Lesson two.

Stop funding hope.

And this was a hard one.

And this almost went viral in my company for the wrong reasons.

What I don't want you to take away from this is that I'm not a hopeful person. I am a big believer in blue sky thinking, big bets in seeing what emerges.

And so my hope was that with enough collective experimentation, a path forward would emerge.

It didn't.

Every person in my team, as they started experimenting with AI tools and how they might augment or reinvent their work style with AI, they went through this same arc.

When you're a maker, just making something feels like progress.

And I saw this feedback loop happening over and over, where if I just pull the handle one more time, I'm gonna get something. And that something is progress.

And so, the hope was that if you prompt, you can prompt your way to good. Just one more prompt, I'll tweak it, it's will be good.

You can't.

In the craft era, in the pre AI era, you can call it what you want, there were laws of the universe that dictated how fast you could go.

And the way we work, how we've honed our craft, created processes, they're bound by those laws of the universe. There are plenty of checkpoints along the way that when you drifted off course, there's something to knock you back on course.

However, today, you can go the wrong direction super quickly.

In fact, the only limit to going the wrong direction is how much you're willing to spend on tokens.

So, I hope that speed would make up for the lack of direction.

Nope. It did not.

So I had to I had to give it a name. This is a real slide from an all hands in my organization.

But we had to declare it. We have to stop funding hope in all forms.

And we have to make big bets that start with defined adoption signal. And most importantly, we have to say no without those things. And you could imagine the design leader telling the product engineering leader, nope, this is hope.

I'm not going to do it.

And so, I had to reframe the mindset here. We had to go from open ended exploration to targeted outcomes.

We had to stop treating activity or getting any output as progress and start thinking about how do we get to decisions. And those decisions are what define our progress.

And most importantly, I had to get a handle on the fragmentation, on the wildflowers, so that I can create cumulative leverage that spans my entire organization.

Lesson three. Don't manage the shift, model it.

Back in February of last year, my team rolled out Figma Make. This is really the first sort of agentic tool that we had access to.

And I created an event called Make Something Week. We set aside time for people to participate.

We gave them prompts. And the whole premise of this was, let's just see what emerges, and more importantly, who emerges.

And as you can imagine, the wildflowers bloomed. It was an amazing, an amazing event.

I also strongly felt that if I do these things, if I model these behaviors, it will spread. My team will see if he can do it. He's a busy VP. We can do it.

They didn't.

Then I thought, they just need to learn GitHub.

We're writing all this code.

It needs to go somewhere. We need to learn how to think like a developer.

Nobody understood why.

So then I thought, Okay, we just need some more tutorials.

And I wrote these by hand. I'm very proud of myself.

And if I write these tutorials, my team will get over the hump, and they will self start.

They did not.

My last bright idea. I'm gonna write some sample code. That will totally fix it.

And I don't know what I was thinking. I was getting kind of desperate, if I'm being honest with you.

But it's hard to argue, right? It's hard to argue that any of these were the wrong step.

If you look at them in isolation, they seem like the right thing to do, or they seem like puzzle pieces in a larger puzzle, that all of these things have to happen.

But what really got my team to self start is establishing a new contract with them.

I had to tell them, don't do this for me.

Do this for you a year from now.

Are you still in this industry? Are you still at Cisco?

It's a responsibility that you have to take. And that might seem threatening. And it's not. I promise you.

It's about being clear and being candid with the team.

I started by saying, well, we can hope that this blows over.

That would be the worst thing that I could do for my team. So instead, I was honest with them.

Not only that, but I reformed my team around four strategic mandates. Two of them are top secret. You can't see them.

But I also made this someone's role. I made it a role.

I made OKRs around it and said, this is your job to go and do that.

Now the team knows that I'm serious.

This helped to give the org structure and connect some dots for the team. But now, I needed to address the peace of mind part.

Lesson four. The people you're worried about aren't resisting.

They are looking for a path.

At this point, there were several who I call pioneers in my org.

Thriving.

Threw out the playbook. They were dexterous with any AI tool. They were writing code. They were checking in pull requests. They were killing it.

However, I mistook those signs of their success as a validation that I'm doing a great job.

So where are we so far?

We started with let the transformation emerge, let the wildflowers bloom.

Then I went to, well, if I just have a strong point of view and I model it, and now I have early successes among my pioneers, so surely, success will spread.

You know where this is going. It didn't.

In fact, the opposite happened. My worst nightmare, actually.

What I learned is comfort doesn't transfer. In fact, it divided my team. I had a two tier organization. That's my biggest nightmare.

I can't build a team based on a couple of pioneers. I need everyone to be successful. So I had the inspired and fluent, and I had the people who were waiting for a path.

I had to shift my mindset.

I had to stop asking, how do I get everyone excited about AI? Why aren't they excited? And instead, I had to reframe it to, does this work for someone who's not already comfortable with AI?

The lesson here is that early success isn't adoption until those people who are not comfortable can follow it repeatedly.

Lesson five.

The values your team executes against are the ones you reward, and not the ones you announced.

And if you're a people leader, this is a tough one.

We need to hold up the mirror and look at ourselves for a moment.

And this is where I realized I was the problem.

There's a big difference between what you say and what you do, and what signals you give to your team.

What you praise, what gets your attention, who you give shout outs to, mistakes that you let go, the things you ask about in a design review, your team sees all of it, and they turn that into connection and meaning.

And they execute against those.

I want to talk to you about a real design review I had about six months ago.

I run design reviews across my team every single month, back to back to back. Fantastic.

And I had two teams back to back.

Team A, they showed this super polished prototype. They spent months making it. They built it in Figma. Every detail was perfect. It was cinematic. Every corner was deliberately rounded.

And the celebration was the polish. And the celebration was, we're now at a point where we can get feedback. We can get feedback.

Team B, they should be It was honestly a little bit of a train wreck.

But what the difference was is that they had built this in Cursor.

And they weren't waiting for that moment to get feedback. They had already gotten the feedback. They got it to enough fidelity that they could validate and derisk this solution.

Team B is what behavior I want to model in my organization.

When I asked team A, hey, why didn't you reach for Figma Make, Cursor, or whatever?

And their answers were, it made a lot of sense. We tried it. We couldn't get the polish we want. The nondeterminism is really annoying.

So, we went back to what we know.

And it struck me that there's this association between something that's beautiful is good.

If it's polished, it's ready.

If you built it fast, that's impressive.

And if you're certain about your design decisions, it's strategically aligned.

So I had to change those signals.

I had to change them such that we move on from beautiful and we talk about useful.

We stop focusing on polish and we start focusing on testing.

We let the idea of the allure of being fast go and talk about learning.

And instead of always being uncertain, we should assume that we're wrong, but our output is about de risking our choices.

Don't be like me here. Don't mistake evidence of change for the conditions of change.

Now, don't have a last slide. I said this was the journey so far. I'm still in the middle of it. I haven't figured it out yet. I'm thinking about lesson six right now. I'm hoping that the user testing team will invite me back so I can tell you about it.

But that has been my journey so far.

Thank you, and good luck.