Forward Deployed Engineering, Lean Teams, and AI Adoption

Amir: On this episode of the show, I have with me Ash Pembroke. She is the managing director of AI strategy at Accordion, and we're gonna be talking about the forward deploy role and what that looks like, what's it like leading a team of forward deploy engineers, and exposure to business, and dealing with lean teams, and a whole bunch of other stuff if we have time with Ash.

So I'm excited for this one. Ash, thanks for joining the show.

Ash: Thank you for having me.

Amir: Absolutely. All right. Before we start, Accordion, what do you guys do there?

Ash: that's an interesting question. So the origin story of Accordion is an interesting one. It is a financial services consulting firm that really started, and continues to serve private equity-backed businesses almost exclusively.

And so I think what we do really well is understanding the office of the CFO, value creation plans, and working on really tight timelines, which I think is is an interesting value proposition when you think about kind of how you build a technology and forward deploy team in this day and age. So it sort of lends itself to, um, how we're delivering now.

Amir: Awesome. All right. this episode we're gonna be talking about the forward deploy engineering role. Obviously, probably one of the most popular positions now in the market. Everyone wants to hire for them. it is slightly different everywhere. I think it's just like, um... It was like a data scientist, uh, early on.

Data scientists slightly had, a different flavor at every org- I guess when, you know, for you, forward deploy engineering, tell us, you know, just for as a starting point, what does the job entail?

Ash: So it's interesting. I think we-- I don't believe that there is, like, one unicorn engineer who can do everything, at least not in my recruiting, uh, sector, right?

So if I'm in Fang, maybe I can find a polymath who's also a poet and, um, you know, has patents out on, like, Fang software and can do everything. W- the way that I think about it is that you've got one sort of deep area in technology. So like maybe you came up through data science and data engineering, maybe you came up through, um, full stack engineering, maybe application strategy, enterprise architecture, but you've got a kind of horizontal understanding of either like a domain in the business or an industry that makes you super dangerous.

So the people that I tend to love working with in this role, and I'm like, "I wanna copy more of you," they are overachievers, they're incredibly curious, and in some instances they've already had like a career in technology and project management, and maybe they did something before in industry that had nothing to do with technology.

So, um, I think you just have to have one dominant technology pillar and then an interest and aptitude to really move, um, outside of working with just tech and wanting to solve problems that are, that are really difficult to untangle, um, with technology alone.

Amir: So, you know, well, definitely the forward deploy role is popular across every org that is in AI right now.

I guess, you know, from the standpoint of leading a team of forward deploy engineers, I mean, you've held other roles within technology. how is leading an FDE team look different to you than what you've done in the past?

Ash: I think two things. One is, um, leadership flexibility based on the aptitude and skill set of the team.

if I look back at my past lives and you really understand the shape of what you're doing and what the pyramid of, like, the scrum team needs to look like, maybe you're running a complex program, right? So you're doing a, a large data migration, or you're refactoring an application or doing some modernization work.

You sort of have these standard roles, right? You're like, "Oh, well, I know what the architect is gonna be responsible for. I have this, like, DevOps human. I know what they're gonna do, and I got a front-end engineer, I got a back-end engineer." This is ... I know some of these have become antiquated, but if you think about technology work in wh- what character do I play on stage?

We have kind of established roles, and what I think is really challenging right now is that we are essentially taking fractional allocation of multiple people and maybe some dedicated allocation, and we're smooshing those down into, like, two to three individuals on these FTE teams. And l- I think like at the beginning of, you know, when I decided to be a data scientist, that was a really hard job description to write.

Like, what do you need to be good at? I think depending on the work and depending on the team, you as a leader need to flex to meet the needs of the individuals on that. So as an example, like, I've got a, a really wonderful team, um, at a customer right now. They're in- we've got someone who's really great in infrastructure and somebody that's really good at, like, traditional, like, hybrid BA product data science work.

They work together really well, but then every once in a while, you know, I'm like, "Well, what value do you bring?" Uh, you know, they're like, "Can you just interface with this executive person with us and, like, help us with the decks? Like, we don't know how to communicate what we're doing all the time in the language that she wants."

And so in that project, I'm supporting them in maybe translating what they're doing and saying, like, you know, "This is, like, really good technical work, but the strategic value of this is here," and this is sort of more junior team. With a more senior team, I might actually be pushed more into design work.

They might say, like, "Hey, Ash, y- you've done a lot of, you know, media product development, so what do you think as, like, a user? Like, give me feedback on wireframes. Like, how would you think about this?" So I think as a leader, it's, it's encouraging everybody in the right way to safely blur into a capability set that they may have waited in a traditional career path a few more years to acquire.

So I'm sort of forcing people earlier in their career to understand architecture. I think that's a challenging question for, for them, and so how do we blend... I need to regress a couple of steps in terms of probably how hands-on I am and really meet them where they are. And then for more senior teams, sometimes they're just like, "I need you to own a section of the backlog."

And I'm like, "Got it, chief." Like, that's that's my job today. So it's really... I think it's a lot of fun because it is so fluid, um, but that could also just be, like, weaponized neurodivergence talking on my behalf, and other leaders may be like, "I really don't like how fluid this is." So, you know, your mileage may vary.

Amir: Absolutely. I guess when you're looking at this role and, things have changed within development, right? You know, we, for the longest time with SaaS, we necessarily didn't need a forward deploy engineer 'cause here's the product, work around it, use it, get comfortable with it, make some adjustments.

now we're in a position where we're like, you know what? We can actually get really personal with the team. We can actually customize, personalize, which is how applications were built, well, pre-SaaS 20, 30 years ago. with that, happening in the market right now and with that nuance of understanding the business and understanding impact and not just focusing on code, uh, I mean, is that where we're gonna start seeing the real value of those AI transformations, getting into the subject matter expert areas, really understanding the, the job itself, not just here's, here's the product, we got you the requirement, yeah, good luck with it?

Ash: That's interesting. I think it might depend on the size of company and the sector. So I, like, I was lucky in that I got to build some things before they became commoditized in SaaS. And so some of the best work that I will say I've ever done in my career was, you know, building algorithms to run e-commerce engines on websites that we were working on before that became just a feature of CMS systems or, uh, e-commerce systems.

So this-- I think that there's possibly, to your point, a resurgence of some of that where it's like, well, a SaaS tool would get you 80% of the way there or maybe 60% of the way there. Let's go claim that next 10, 15% to work for your business. What I think is gonna be challenging, though, is that we have a generation-- I'll put on my PE hat and then also my tech exec hat.

We have a generation of people running businesses that are so used to SaaS being both a process enforcer and a value creation play. They're like, "I know the shape of what a CRM can give me, so I'm gonna screw in a CRM. I know the shape of an ERP," et cetera, et cetera. What I am-- obviously, I build stuff for a living, so there's some survivorship bias in who works with me.

But I'm seeing more and more operating partners start to challenge that playbook and say, "Okay, so if five years ago I would've put in these three logos or these three acronyms, what if I just have a data warehouse and a series of agentic orchestration tools and Could I optimize a commercial function like this?

And the truth is that I think the answer is sometimes yes, depending on the size of the company. But if you've got a lot of organizational complexity, like just think about how difficult it would be to hire for somebody to be a, I don't know, commercial operations leader, like rev ops. A rev ops leader is gonna expect you have a CRM.

They're maybe gonna expect a CDP and some other stuff. And so I think where I'm seeing the most traction right now is taking process optimization and use cases that sit outside of any one tool and saying, "Let's assume you make n- not another dollar investment in SaaS this year, and you see if you can just keep everything where it is and totally revolutionize your process."

If you can do that and you think about SaaS as the, the gated facility where sub-agents run and run really well and have strong permission structures, that is a lot of the work that my team is doing right now. And then usually what happens after that is the, whether it's the commercial team or the finance team says, "Yeah, I'm actually not really understanding the value of this tool anymore.

You've abstracted it behind all of this stuff. I'm no longer logging into it as often. What is it doing?" And so then I think the conversation becomes pretty challenging because there's a lot of technical investment in the last 10 to 15 years in these systems. And so if it's an AI native company, the conversation is usually like, "How can we bypass it?"

If it's a really large company, it's, "How do I turn on things and workflows that augment my existing implementation?" But there's this like mid-market messy situation where I think you can choose your own adventure, but unless you're in a transformational state, the adventure might be a little bit painful and you may decide that like operationally it's, it's just not worth it.

Um, I did... I don't know if that clearly answers your questions, 'cause I think it really depends.

Amir: Yeah, no, I, you know, I think that's a, I think that it does, and I think it kind of leans into, you know, I, I think S- SaaS for the most part had, has had issues with the last mile, right? I mean, it is, you know, we build a lot of features, get a lot of features in people's hands, but there's a certain amount you adjust to the applications you have.

I mean, it's just, it's, it's actually been the way technology's run for the last, you know, ev- forever. And, and now we're, we're finally to a point where it's like we can actually talk about getting tools in the hands of people that really mirror and reflect the natural language of their job, which so far has been, a challenge.

when you think about that, you know, that, that, that shift from, you know, we have to take, uh, a natural language, we have to convert it into some type of application. Now we're going, we can take natural language and we can carry natural language a lot further through a lot of the tools.

We're still at that messy middle. We're still seeing a lot of movement in terms of how, these applications and, results are, coming to market. I guess when it comes to expectations of when you sit down with a- with your stakeholders and you're working with them, uh, has their expectations shifted at all from the way applications were delivered before?

Are they still kinda... are they, bought into the hype a little bit more? I guess, just kinda curious about that.

Ash: Well, I think it, I think it depends. So I would say there are CIOs and there are CTOs, and I mean that in, like, the kindest way possible. So a lot of leaders in the CIO function are meant to mitigate risk.

So they're like, "Info sec, how are we gonna keep our company secure? How are we gonna manage cost? How can we service the business?" And I think a lot of my customers that are more like-minded in, in that way, they are looking for things that are easy for them to own and maintain. So like, "Yeah, I love this concept of an FTE," and like, "Ash, come in and give me a roadmap where you're using some agent force, like on the Salesforce platform.

You're using some things out of the box from a commercial tool. You're doing some things over here." But the roadmap needs to be, what I really need is, like, centralized orchestration and an understanding of what is doing what in my company. That is the most important thing. And so, yeah, we'll build some custom stuff, but we're really gonna orchestrate a lot of best of breed.

And so that's kind of one philosophy. And so I think you have one type of F... That's a kind of FTE that's like a very enterprise architecture savvy, what is, what does the knee do? What does the thigh do? What does the foot do? Kind of having a information framework about how leadership will understand some of the things that they propose.

So, like, I can't have an FTE that goes into that leader and says, "Hey, we're gonna just, like, rebuild Salesforce. We're gonna vibe code it this weekend." Like, can you? Should you? Different things. Where I think, you know, more CTO-minded individuals, and I think this depends on the industry of the company, they're looking at things and they're saying, "Well, if I actually, if I, if I abstract what this company is," this company is maybe like a SaaS company, "we're really focused on, like, channel and partner sales, so we're commercial engine with a product.

How do I optimize my commercial engine custom to what I wanna do?" And so those leaders are thinking about things like, "Can I run my entire company from Slack?" Like that's a, I think that's a challenging and, I think, interesting commercial hypothesis to have. And so when they're, they're interested in breaking more things and trying things that are maybe less established as patterns, I think you're bringing a very different kind of engineer to that individual, because that person is going to be on the hook for building a scalable system where you've got all the things that you would have in that earlier pattern about orchestrating agents or having good strong data lineage and controls for cost and security, but they're going to be designing a, like, centralized cockpit for the business that's agentically enabled.

That's like an OS question. So like, that's a first principles conversation. And so I tend to try and, one, like I think both are incredible roadmaps and opportunities to deliver use cases within, but you bring a v- you bring maybe a more of a polymath to the second, um, the second approach, and you're bringing somebody that's more like systems design and process-oriented to the first.

And so I think it's just, I'm always thinking about myself as a matchmaker. I'm trying to find the right problem self set for the right intelligence on my team. And when you matchmake effectively, the work doesn't feel like work. It feels really fun and challenging and interdisciplinary. So it's, um... I feel a little bit like a, I don't know, like a matchmaker.

Like there's a bunch of speed dating when we do our staffing. I'm like, "How do you feel about healthcare plus ambient AI, plus maybe imaging?" And someone's like, "I'm intrigued" on Slack. And I'm like, "I-- boy, do I have... I have the problem for you. Let's come talk."

Amir: That's interesting. I, I guess a question for you.

Wh- when you're looking at the attributes, I mean, we kind of touched on some of them, attributes of what makes a, a... All right, well, I guess maybe two questions. What makes for a really good forward deploy engineer? And, and the second question I see a lot is software engineers who want to move into that space and like, "Well, what do I do to- Mm-hmm

to, to, to actually be able to move into those type of roles?"

Ash: I think somebody who, um... So I think there's, there's a challenge. When you are doing software delivery with a lot of technologists, the precision that you have to use is very high. So sometimes when you're working with the business, you cannot communicate at the same level of precision.

Like you... I might say, "Hey, we're gonna build, um, you know, a, a data pipeline. That data pipeline needs to function like this." You know, we're, we're using a combination of tech, tech process, specific examples. If I'm communicating what I'm building to a business user, I just say, "This is how we're gonna get data into the data platform.

I know you're, you don't necessarily care about that, but there's two ways we do that. We're gonna have a batch process and a real-time process. There are limitations on what you're gonna be able to get real time. Let's talk about that." You have a... You have less precision when you work with the business, and so you have to be able to manage risk really well, because they're not gonna be able to prescribe exactly what they want to use.

You're gonna have to bring, like, a first pass at that to them, and I think product has done that for a really long time. And so I see a lot of product managers that maybe they graduated from being in engineering, and they're like, "Oh, I'm back, baby. I have the time to do both." And that, that to me is... If I think about the three-legged stool of how we deploy, we think about, like, the expert, the engineer, and the architect.

And so that person to me that comes from product is really good at embedding themselves in the business to be the expert. They could be user experience oriented. Maybe they're like, "I really love Figma, but now with, like, Figma and Claude, I'm, like, very dangerous." That's one archetype. I think the other archetye, archetype is, um, like the, the architect.

So someone that is, like, a systems thinker and has been responsible maybe for a portfolio of applications coming together is, is deeply considerate of security and the way that things come together and communicate, and is always interested in thinking about, like, stage gates, cost control, um, decision rights, like really thinking about the system.

It, that is like another archetype that we pull from. And then the, the last archetype is more fungible, where you're actually maybe like you've got stronger domain expertise. So I had a gentleman that I had hired, um, on our team who was a, uh, he was an engineer at Exxon for a long time, and so he had done a lot of like lower level, uh, programming on things in the field, like IoT devices.

And he got into cloud, and he was one of the most incredible streaming ... If there was a streaming, streaming data problem, like what we're, we're solving is actually really large sets of data, especially if they have any sort of hard science information in it. It's not just like invoices and paperwork, it's like signals from recording devices or things like that.

He has a brilliant mind for thinking about like, "Well, everything's a 4A conversion problem. Like, so what, what am I gonna do?" So I think it, I think it just depends, but, you know, you have these sort of dominant areas where people are coming from, and the question is, to me, can I organize them on the project where maybe the product sort of expert person's a little bit weaker on the data side, so who do I pair them with?

Who thinks about like data and systems? And maybe they both have never really worked in a, a SaaS ecosystem, so they might not know as much about what they could expect from a CRM or a CDP that's a commercial use case, so I'm gonna pair them with an architect who understands that. So it's more about like, do we have the right brains at the table to think about how we solve the problem in multiple dimensions, and can they collaborate?

Like, is the vibe vibing? Um, if you can hit on all of those, you get really, really great lead teams.

Amir: I, I guess a question comes to mind. I mean, you obviously have been in management. You're leading a forward deploy team. For, for you, has your role, uh, uh, in leadership changed or evolved now that you're in this forward deploy role?

I mean, has, has, have you had to make any adjustments? Is it, is it still leveraging the same skill sets? Have you had to work on new skill sets?

Ash: Yes, and I think in a really good way. So if you were to ask me how much time, um... So I, I had a role at a previous firm where I did more like strategy work for CIOs.

So like, what's our roadmap gonna look like? It was tech advisory, right? That is a very academic, um, oriented role. You're not like engineering anymore. You're taking your experience and you're putting it on slideware, and you're justifying spend to board level folks, which I could still do. What I find really empowering about what we're doing right now is There are areas where I would've felt pretty unconfident from an engineering perspective, but I can pick up a healthy amount of backlog if it's data science, ML, or data engineering related.

And so there are times where we don't have the right individuals to staff, or we need somebody to actually, like, pick up a shovel. And so I find myself more able to do that in these FDE roles than I might have been able to do it without some of the coding assistance and other tooling that we have now.

So I think I am closer to the work than I've been in a while, and I find that to be far more liberating, because I think I got into doing this 'cause I like data work. Like, I liked it. I was good at it. And so to be sort of promoted out of the work that you really love, yeah, you still need to learn how to lead teams, and I think you need to be a, a reasonable leader, and if you're in consulting, sell things that are achievable and not totally crazy.

But I think it is a loss for a lot of us because it was a large, it was a large part of the creative outlet of our job, was doing the work. And so I tend to maybe be a more hands-on leader in that way. Sometimes my teams don't like that, just to be very clear, 'cause I'm like, "Why are we do- what? What? What?"

You know, then, then you're in there. But if you can get past micromanagement and still get excited about picking up a shovel every once in a while, I think the FDE model allows you to get closer to the work in ways that are really interesting, because every meeting that you have is with an executive at the business.

So if I'm gonna design a solution and validate that with my team, I'm in that meeting with them. Like, we're talking about it. It's not like you just show up to quarterly reviews and... No, like I'm, I'm in sprint reviews, and we're talking about stuff that is important, and because of the productivity tooling I have, I have time to still do the other half of my job, which is selling the next wave of work.

But that's my personal, uh, adjustment, what I like to do. I think that, you know, your mileage may vary, and my boss might have some things to say about whether or not I'm using my time properly, so we'll let him be the final arbiter of if that's a good idea or not, but that's what I like about it.

Amir: Absolutely. guess maybe a, a final question for you, 'cause we, we've kinda talked about the, you know, proximity to business. We talked about just a, a, a different exposure to the stakeholder, different views of the solution. I, I guess one thing that, that traditionally happens in technology, there's always some kind of, of lag from, "I need something," to, "Here it is in your hand."

I guess with AI things are moving quickly. We're seeing agentic, uh, solutions that can bring, uh, uh, features and products and capabilities faster into the hands of the stakeholder. I, I guess for, for the time aspect, maybe two different questions. One, when you're dealing with solutions that potentially hit stakeholders' hands quicker- Right

um, what, what do you see there? Obviously, uh, we still have to go through development, we still have to go through testing, uh, adoption, all of those things. But from the standpoint of time, if we are able to get a solution in the hand of an end user faster I, I guess for that aspect are, are, uh, are you seeing advantages?

Are the stakeholders then taking it and using it as quickly as we've gotten it to them? Is there still the traditional, you know, adoption cycle? Are there still some hurdles for them to actually get into, into practice?

Ash: Mm-hmm. So it's interesting. I was listening to a podcast, um, the company Sauna has one.

Um, and they had an economist on, and his position was the biggest bottleneck to AI value creation is the inertia of the business. And so I think that's a really in- like I, I... The way he phrased that, I liked inertia of the business a lot. Um, it's Tyler Cowen, it's the Strange Loop Podcast in case anybody wants to listen.

But I have observed that as well. You've got a sort of rhythm of the business, whether it's in technology or whether it's in a public company, you sort of live and die in, in quarterly, you may month and close. Like, you've got these fre- sort of built-in frequencies within which people are used to making a decision, and then everybody like goes on PTO in August.

And so I think what is confounding is I will show up with a team and I'm like, "Okay, we can do a lot in 16 weeks. Let's, let's go." And I think the challenge... That's why communication I think is a really big deal in Forward Deployed, which we should rebrand by the way, but we'll work on that later. Um, your ability to communicate crisply so that people feel confident in making decisions and understanding their impact is really important.

In the traditional life cycle, there's like a strategy exercise, then you get a slide that is a roadmap, and they say, "But we need to do the mobilization phase next. In the mobilization phase, we're gonna wireframe." The rapidity with which you can land a team, create a backlog, start prototyping, pressure test that prototype in a real process flow.

So wire things up. You're using like... It's not future, uh, im- implementation, but it'll work in terms of pressure testing, whether it will blend or not blend. That's actually happening really fast, and so it requires you to bring every tool in your user experience, product, and communication tool set, and strategy tool set to bear to get business alignment to make decisions at that speed.

And it is not- uncommon for our customers to say, like, "Hey, I-- we love you guys, but we're, we just, we need to revisit this decision we made last week. We thought about it more, and we don't know if we made the right decision." And so I don't have a good answer for the speed of decision-making. What I can tell you is that I have friends that are...

They're building agentic companies because they don't believe that humans can actually operate the business at the speed that agents can make decisions. And we've seen this in, like, distributed marketing systems for a long time, like programmatic ad serving or dynamic creative or whatever. You don't have a person, like, watching the toggles.

No, the system algorithmically optimizes itself. And so you might not like the outcome, but you don't have-- very few people are gonna have the sort of three-dimensional capability to operate at this speed. And so I've heard people say that this is actually gonna be a forcing function for certain folks who are just not going to be able to operate it at certain speeds.

And so when you remove some of that slower decision-making or you increase the frequency of business, that might alienate certain people from being able to work at certain companies if they increase their operating cadence, right? Like, I've got customers that make decisions every 90 days. I've got customers that make decisions every four business days.

There's like a go, no-go. And so that's a cultural phenomenon. I, I think the jury's still out on whether the 90-day company or the four-day company long term makes the better decisions. But from a market capitalization perspective, there's a hell of a lot of investment going towards businesses that are speeding up their decision frequency.

Now, that if you are bad at making decisions or you have a, an incorrect macro hypothesis, you'll just run into the wall faster. But I, I think at least from a technology perspective, we've always rewarded, at least in our culture, the startup mentality, which is that, like, speed beats ... Like, you can make a couple of mistakes if you're first to market, you could fix that.

And so, uh, I don't know what, where we're gonna go from here, but I can tell you that, like, I've seen, like, real AI hallucination. And so like, that, that is a very real impact to the human experience at working at this speed. It can be very overwhelming. Um, so yeah.

Amir: It, it is interesting 'cause I feel like, um There's a lot of room for AI to have a huge impact.

I do think there's a, there's a speed of-- There's a speed factor here. I, I'm still not sure, um, because I still think there's a long way to go for agents to actually be in a position to make decisions at an enterprise level. I mean, we're still not quite there, but I think, like every technology, it has to start somewhere, and we need to see benefits, results, and more tooling will be built and everything will be easier.

There'll be ecosystems built. Obviously, you know, in the last twenty-four months, we've seen this explode, and there, there's got to be that cycle of technology that we go through. I mean, we've seen it with everything, so I can't, I can't imagine we're not gonna see that. I, I guess from your standpoint, and maybe this will be just last question 'cause I know eventually you gotta get back to working.

Um, when you're looking at agentic and you're looking at the speed in which tooling is, is, is accelerating and making things easier, are you seeing the organizational infrastructure necessary to deploy these agents? Are, are they also coming up to speed? 'Cause when I talk to leaders, they're like, "We still have concerns around guardrails, you know, security, privacy, uh, observability.

Those tools are still not there for us to feel 100% comfortable." But it's also like you also have to figure out what you need 'cause this is not what you've deployed for the last twenty years in, in other applications.

Ash: I think they're, uh, the risk tolerance varies widely, and that usually is tied to, um, I'd say technology literacy.

Like, I've got a CTO client and he was a data engineer, and he's like, "Yeah, we've got a- observability is solved. Identity management is solved. We have a strategy for how we wanna, you know, log our agents. We've got a strategy for how we manage process and human identif- identification with interaction. We have a different system for how we think about a framework, not a system, a framework for how we wanna think about giving decision rights in certain platforms, um, higher level orchestration agent versus lower level agents and SaaS."

Like they, they're really thinking about how they wanna rationalize solving problems. And so those individuals are like, "Yeah, let's go. I know how to roll things back if things get a little bit out of hand." It-- I think this will put a lot of pressure on folks that are generally like a little bit skeptical of technology, and so the market will, will reward eventually, like someone will, will win.

I think some of the early implementations will be super difficult to maintain in their current patterns because the tooling wasn't effective and integration maybe was an issue, or we put the wrong... We, we sort of put the wrong part of the thinking sequence in the LLM and not in the database. There's a lot of use cases like that where we...

I've seen companies try and like magic away foundational investments like a semantic layer or thinking about security and identity management. But assuming that they did think about that and they are interested, I think the What I would like to see is a technology leader that thinks about setting up the foundational infrastructure to allow the business to do a lot of that last mile automation themselves and own it.

And then that then puts a lot of pressure on people in those roles. 'Cause like we, like at our company, we've got, um, uh, our tech team is very gracious and will give us all access to Anthropic and other tools, but that's different than me having admin rights to push a certain set of like enterprise AI skills to all the, to the instances and accounts of folks that are using Claude on my development team.

And so this kind of radical... Nobody knows the work better than the person doing the work. So if someone's gonna automate an accounting workflow and say, "This is what good looks like," it's gotta be an accountant probably. So I think this concept of how do you get to a technology disposition where it's safe for somebody that's maybe not so technical to do their own last mile work and be a product owner of an agent, I think that to me is the, that's the kind of pattern I'm trying to convince my clients to enable.

Um, because I don't think that I... I think if IT is the bottleneck and central entry point for a lot of this from a use case perspective, it's never gonna happen. Um, so how do we federate that back out into the business safely is, um, is what we do a lot of thinking about.

Amir: I, I, I like that a lot 'cause I think the appetite you mentioned and the risk tolerance, I mean, that's, that's...

I, I think we've seen, uh, a- and there's been so many stories out there about, um, you know, failed projects on AI and what hasn't worked well. But also, I, I don't think people really value you have to actually go through the experience of something not working out. I mean, I, I don't know what technology, um, you'd get right the first time out.

I, I think even, uh, when the cloud was there and we were trying to see people migrate their on-premise to cloud solution, there was a lot of issues and a lot of failure 'cause it was complicated- Yeah ... and not quite straightforward. So I, I kinda sometimes find it, uh, amusing that people, uh, you know, choose what to focus on when, you know, something of this magnitude.

And, and every company definitely is seeing this as a potential advantage to their business. And again, y- you know, being a f- a forward deploy engineer, kinda, kinda tie it back, you're getting in there with the business and making a material impact in areas that technology hasn't been able to go before, and that's, that's hard.

That's not gonna be easy.

Ash: Well, and the way I think about it, too, and this sometimes gets very, uh, a certain kind of person very motivated to take a risk, is I, I just say like, "Listen, if you b- do you believe that this is gonna be a huge revolution in human productivity and the way that we do, like, digital work?"

Which has become a lot of work. And they're like, "Yeah, I do." And I say, "Okay. Are you a centrally planned economy person, or do you believe in the market?" And usually, if they're American and they're in a certain industry, they say, "I believe in the market." I say, "Okay. So do you wanna centrally plan your transformation and pick like two use cases, or do you wanna get to a point where you look at all the people working in your company and you make a couple of big strategic bets, but you allow a groundswell of things to be elevated because people are literate enough, they've got safe platforms, they have data in the right places so that they can use these tools to optimize their, their own workflows?"

It might seem like it's fragmented and it might seem like a lot of technical debt and spaghetti, but if you set up your infrastructure the right way now and those patterns have consolidated in the last year or so, I think we should be thinking about this as- You aren't gonna make the right decision in one steering committee for 5,000 people.

So how do you federate out some of that risk to end users? And if... And so I think that having that conversation has gotten easier from a risk management perspective, but, um, and that's why a lot of our forward deployed engagements, people just say, "Can you train me how to use this? Like, I don't really understand how to prompt."

And I'm like, "Well, maybe the job, maybe the skill of the future is curiosity and persistence," and some of the other stuff kinda comes along with that tenacity. But yeah, it's, it's an interesting time to be, um, working out in the field. I think having a, um... Being humble and then trying to have, like, a maybe more humanist approach is always helpful as well.

Amir: Absolutely. Love it. Ash, fantastic stuff. Uh, I feel like, I could keep throwing questions at you and you'll, have an answer, but, I know you gotta get back to it. I guess if somebody does have a follow-up question, uh, and if forward deploy engineering is really hot right now, what's a good way of connecting with you?

Ash: Oh, LinkedIn, um, always probably the best front bo- uh, mailbox for me, and then I'm pretty sure that my contact info's on our company website as well.

Amir: Absolutely. Definitely appreciate your time. Thank you for being on the show.

Ash: All right. Cheers.

Amir: Absolutely. All right. That's it for this episode. Be back again, different guest, different topic.

Until then, two things: one, love it if you could share this episode with somebody else that could benefit from it. I know forward deploy engineering is, is huge right now, so Ash talked to us about what the role looks like, the actual experience of being out in the field, dealing with the business, leading a team.

We talked about time and some of the advantages of being really close to the business. We covered a lot of stuff, so, uh, hopefully you'll share this with somebody else who could also enjoy listening to it. Also, like, subscribe, comment. Let me know how the show's going for you. Until next time, thank you and goodbye.