Jim Johnson: Welcome to AI Actually. This is our 19th episode. We are ⁓ the finest source ⁓ of keeping up to date in terms of going on in ⁓ Largely ⁓ from our team at Answer Rocket, plus occasional guests. We've got Shanti sort of deep in the engineering lab. Someone pulled him out of that today. ⁓ ⁓ one of our sort of semi regulars, Nicole, who actually does real work, ⁓ here with us again and Stew who is, ⁓ sort of periodically checking in with us, part of the stellar family. ⁓ but sort of super excited to be here. ⁓ I think today we, you know, today we want to address a topic that's out there in the market and, and people are talking about, I think it's sort of originated.
Nicole: .
Jim Johnson: maybe with the hype cycle around Palantir. We want to have a discussion about the concept of the forward deployed engineer and what it means. ⁓ You know, I'll try to avoid sort of going too far into a joke here, but you know, it seems like LinkedIn's caught fire as it relates to the concept of the forward deployed engineer. And now sort of every software engineer is calling themselves a forward deployed engineer. We want to roll around in this and talk about what it really means. and what we're seeing in the market. ⁓ That said, let's just dive in. Stew, I know you're sort of out there on the edge in terms of ⁓ bringing value to some clients and wanted to get your perspective on what this means, maybe what the world thinks it means and we think it really means and where this is headed.
Stew: Yeah, I mean, as we know, one of the problems you have when ⁓ a term becomes popular is then ⁓ it gets overused and taken over by ⁓ everyone. So we were joking earlier that, you know. everyone now has changed their resume to be a forward deploy, know, scratched off like crypto engineer and then, ⁓ you know, ⁓ whatever was next. then, ⁓ you know, is now throwing in forward deployed engineer. But I think that also speaks to the value, you know, there usually when that happens, there is some sort of underlying thing that has driven it to be popular and recognized. And I, you know, I think The reality as you pointed out is ⁓ with AI now, roles are merging together. And there was actually, ⁓ it reminds me of, ⁓ I was listening to a Mark Andreessen podcast recently and he talked about how the best product managers he knows, the best product developers he knows and the best designers he knows are all convinced that they don't need the other two roles anymore. You know, and, ⁓ and they're probably all right to a level because it's much more, you know, the value is, is starting to converge on being able to put all these pieces together. Cause you can have the AI take care of a lot of the details, but the big picture, what am I actually trying to achieve? What is the process I'm trying to run? ⁓ stays consistent. So I think this is, to me it's exciting. And you know, Nicole and I both came up through the world, I think on the front lines, actually, you we called them solutions engineers or technical consultants or all sorts of other things for many years. And, you know, we were always hamstrung to an extent because we would be on there on the front lines, working with clients, trying to solve problems, deeply understanding the domain. There was always a lot of information lost as you tried to bring that back into the product team. So to me, it's just very exciting that ⁓ the people who are really good at that and on the front lines, understanding customer problems now actually have capabilities where they can ⁓ take on more of that themselves and solve problems.
Shanti Greene: Yeah, something, something I've thought about is, a lot of us talk about the junior software development role going away. And when you start thinking about why that is, it's not just because LLMs are good at writing code. When you think about what senior software engineers had done is they had started understanding the business and understanding the users of their software product and what they needed and had started picking up parts of the product roles because they really got what they were building and knew why they were building it.
Jim Johnson: Awesome.
Shanti Greene: part of the reason that they're going to be more successful with AI is they're able to better spec what they need, not just because of their actual software development capability, but because they have picked up the business capability as well. And I think that's also what we're seeing, that those senior folks who are being really well empowered by AI tools are the ones who understood the business, can start writing some of the specs and actually understood the value of product to begin with and spectrum of development.
Nicole: I think that's right. I think I agree with everything that Shanti are saying here. And this is ⁓ one ⁓ challenge I have with this term is it's ever we call it a forward deployed engineer. ⁓ so everyone who is sort of peripherally listening to that assumes this has to be a software engineer filling that role. But the theme between both Stew and Shanti statements is they need to understand the business. So I would argue that in this world where AI has come so far and what AI does well is build the code. What AI doesn't do well yet is understand the business. It is that consultant who is that forward deployed consultant who is bringing the business value into the solution. And I think to Stew's point, there's a converging of roles here where this forward deployed consultant can build out the prototypes work with the customer to make sure they're targeted at solving that correct business problem, and then work in the back end with the engineers to do what they do well and productize that. I think the key, so I think you can have two different sort of profiles to become this forward deployed engineer type. You can have the consultant type who is natively business first, who asks the right questions to get to the right business value. and is technically aware enough of AI solutions to build prototypes. Or you can have the software engineer, to Shanti's point, who is more senior, who understands they're not just following the orders their product management wrote for them in a JIRA ticket. They're actually understanding the context of the business problem that they're trying to solve. I think both of those profiles work in this forward deployed role.
Jim Johnson: Bye.
Nicole: So the problem I have is that everyone calls it the forward deployed engineer. I think it's much more a forward deployed consultant ⁓ that's required today.
Shanti Greene: Nicole, it sounds like you're describing the business analyst role. They were the bridge between technology and the business. And sometimes they wrote light code. They did some initial analysis. That role seems to exist. guess we're re...
Nicole: 100%.
Jim Johnson: It went of vogue because of Agile. The BA of got into a strange place, but I ⁓ hear you're saying. I think it's sort of relevant here again.
Shanti Greene: ⁓ okay. Yeah, that sounds like what that job was supposed to be.
Stew: I think there's a couple of things though in defense of the forward deployed engineer. There's a couple of points I would like to make. one is I think if we look at, ⁓ we can all think good or bad things about Palantir. ⁓ I'm certainly not a fan boy for Palantir, but they popularized the term and I've listened to a lot of their, ⁓ you know, things around this term. I think there's one element of this role that I think is very important and it does require architect or engineering level skills. And that is the best for deployed engineers or solution engineers or whatever we want to call them are good at not only solving customer A's problem, but at helping generalize that problem. and abstracting up a layer so that you can build something that then advances your capability to also help customer B, C, D, and E over time. And that's a lot of the actual flywheel at a lot of these companies like a Palantir that popularized the term. ⁓ So I do think some engineering and architecting skills are necessary. The next thing though, is I think What we see in our head when we talk about a software engineer, it probably really needs to change. let's just think about the term engineering. So we don't expect the engineer who's working on the bridge to be the one ⁓ putting in the bolts or welding or ⁓ whatever the heck else you have to do to build. pouring the concrete with all the things you have to do in order to build the bridge, right? They've helped design that work, they're overseeing that work, ⁓ but it's always been a skill we see as an abstracted skill, right? From the actual physical work of doing it. Now lot of engineers are really good at doing physical work as well, and that's true in software. But I think we need to rethink what we mean by engineering. And I think it is... I think the best people in these roles, even if they can't sling, you know, C++, you know, are still have those engineering capabilities in terms of being able to think very ⁓ systematically about the solution they're building and really have a clarity in their mind around where the abstraction points are, et cetera.
Jim Johnson: Making the transition, sort of how work gets done, getting it done this way, it's readily apparent that a team of three or four can move mountains now. If they have that right blend of skills and you sort of look at the Venn diagram, maybe we're gonna get to a point where a team of one can move mountains. ⁓ and have all the requisite functional domain knowledge of the business and domain knowledge of the data and the AI skills and enough IT skills and maybe enough of that sort of the backend wiring it up gets abstracted away as well here as we move forward and a team of one can do it. But a team, a small team can move mountains. ⁓ We have the good fortune of working with sort of mid-cap, mid-sized companies that are trying to sort of change the world. And that's a lot of fun. We also work with a lot of large organizations. I think there may be organizational challenges, organizational structure challenges in large companies that they're not necessarily aligned.
Nicole: you
Jim Johnson: with how work can get done this way today, because they've been constructed to sort of have deep specialization and division of labor and constructed around processes and the fluidity associated with how this work can get done is a different animal. Any thoughts or reactions on that
Shanti Greene: One of the that the large companies, ⁓ especially that have large software practices can afford to have is what one my favorite architects referred to as the sunny engineer, the software developer who has their niche and when everything else lines up around them is great and can be very productive. but isn't quite able to think outside the box and fix things when they start breaking in new and unforeseen ways. That's what's happening with agentic development. Things are breaking in new and different ways. And we're customizing software for an application all the time. Everything we're building is pretty unique. And then to Stew's point, we try to abstract it, try to reuse components of it, but we can keep custom building. So the engineers who fall into these newer roles have to be a little more flexible in how they think about problems. A lot of the what you learned in school, the best way to do it kind of works, but not quite. And the smaller the company, the more nimble you have to be to be able to adapt to those environments.
Stew: Yeah, I think too that I want to emphasize, I think you made a point that's really should be emphasized and brought home more, which is the way you engineer an architect changes a lot because of how certain things have become easier. It used to be, you had to spend a lot of time upfront, really architecting a lot of things because if you didn't get that right, back in cost of fixing it once you had the final solution was so high. I think things are now swapping where ⁓ the better thing to do is to go solve the customer's problem in the best, fastest way you can. even if it's this ugly house of cards on the back end, because that is really almost like a spec, right? That suddenly becomes like, okay, I might not have solved it in the best prettiest way, but this is a solved problem. And, you know, these were my inputs, these were my outputs, that's, you know, that they were both acceptable.
Nicole: Yes.
Stew: AI is really, really good once you have that defined, cleaning up ⁓ everything in the middle, ⁓ right? And kind of re-engineering it to be in a better way. And so I think that, and this probably is one of the reasons why that forward deployed engineer is even more valuable is I think there's just a much higher premium to go out, solve the problem. And then we can come in and clean it up. And it's inverted from the way software worked for a long time.
Nicole: I think that's exactly right. And I think that's why I think that the technical consultant can be that forward deployed person building that. And then we come at the back end. some engineers are going to come in, if they don't deeply understand the business problem, they're going to solve the wrong problem fast. That doesn't do anyone any good. We want business forward, ⁓ people who ask the right question to focus on the right problem to create that. version one that you're describing, Stew, and then come to the back end and solve it. I want to come back to the point that Jim made about ⁓ large enterprises and the challenges with their organizational structure, having teams that have specific skills and they're very siloed. I will say even as a small organization, it's been a challenge to converge those skills. So there is... ⁓ This is not something to be glossed over. This is something that every organization is going to have to face and embrace in order to succeed going forward. And it's not a small challenge. It is, you need every single person in your organization. I want to go back to your original point, Stew, about product managers don't think they need the other roles. Engineers don't think they need the other roles. No one thinks they need the other roles anymore, but that's only if... every role is leading with an AI first approach. And I think it's the transition of the organization to that AI first approach that really ultimately delivers the value. And it's difficult for these large enterprises that are so instantiated.
Jim Johnson: Well, there's whole career models and progression structures and compensation structures and just it's all been constructed.
Nicole: Uh-huh.
Jim Johnson: to sort of, many years ago it was all constructed around the waterfall model and then sort of lot of people sort of embrace the agile model and throw in the mix of sort of multi-geography, onshore, nearshore, and it becomes harder and there's not necessarily clarity of the career model that says, hey, if you're starting over here as a sort of deeply skilled ⁓ engineer or architect, how do you sort of incorporate these other things? Or if you're starting over here as a person, how do you incorporate these other skills because they do start to merge together and ⁓ how do we sort of reward that, address that, and value that in a way that it's clear that that's what we're trying to achieve. there's a whole, there's decades frankly of
Nicole: Yeah.
Jim Johnson: structure that's been in place to do it a different way. And it's going to be sort of hard. And maybe some of this will just sort of happen as a normal course of events, and it's happening behind the scenes. And those people who are sort of stepping forward are the ones who are saying, OK, I'm going to go embrace. I'm going to deeply understand what the business problem is and bring my engineering skills and bring my AI skills, or vice versa. But there's not a defined progression for people yet at this time.
Stew: I think too, we have to look at why a lot of the organizational structure of, these companies. And I was going to make the same point. ⁓ Nicole did when we were talking about the big companies, I was like, wow, I don't, you know, I'm not sure that a lot of the middle companies aren't in terms of, aren't suffering from the same problems, just maybe at a different scale. But I think a lot of, ⁓ a lot of the way these organizations have built up over time has been to protect. Highly valued finite resources and at most companies there's tremendous amount. Even just like take a software company as an example, which I spent a lot of time working with software companies. Software companies have spent, have built up enormous infrastructure to protect the software engineer, right? Because everything was always bottlenecked around that element of the process. That's no longer really the bottleneck, you know? And ⁓ so you would spend like literally, you know, even now still spend longer in a meeting talking about what the roadmap should look like or what a spec should be or, having six people deep dive into one thing. It's kind of like, well, you guys had six ideas on how this could be done in the time we just spent arguing about it. We could have done all six and, and tested them against each other, you know? And so it's a lot of it is, is of the organizational bit. A huge part of it is that everyone's role is different.
Shanti Greene: Yup.
Stew: and they are emerging. the reason why the engineer, the product manager, and the designer don't think they need the other two is because no one's role is the same anymore. The definitions of the roles are changing. But I also think another element to this is the bottleneck points are changing. And so much of our organizational structures are built around protecting the old bottleneck points instead of solving what are becoming the new bottleneck points and tying it back to the forward deploy an engineer. The new bottleneck point, the most important, biggest new bottleneck point is clarity on what actually solves the problem we're trying to solve. ⁓ And so I think that's where forward deployed engineers or consultants are really important. Go ahead,
Nicole: I would argue it's clarity on the problem we're trying to solve rather than how to solve the problem.
Stew: I agree. Yeah. It's a better way of saying it. I agree.
Jim Johnson: Well, and the problem is being redefined because to simply say, hey, you know, in supply chain or hey, in marketing, this is sort of always been the problem. And now we have a new tool. We've got an opportunity to sort of totally rethink it ⁓ from a business process standpoint, how work gets done. The problem may not even be the same problem anymore. And sort of people who can think about how this could work in a world where you have unlimited intelligence.
Nicole: Yes.
Jim Johnson: unlimited capacity sort of labor and described in the right way here in the digital world, at least right now, ⁓ until Elon Musk delivers all of his robots. ⁓ That's sort of the opportunity to redefine it and people who can think that way. That's a different thing. The one other thing I would come back to, though, on this mid cap versus large organization point, I do think there is in some cases in smaller companies, a ⁓ you'll run into people who sort of wear a lot of hats or are used to wearing a lot of hats. there is sort of an, there's not the calcification of organizational structure that is an additional burden, I think, in embracing this that you might have in a large organization. So it doesn't mean that they're not starting from a challenging point. It doesn't mean that, you know, it's not obvious that you have somebody with all the skills, but there may be a little more fluidity there that...
Stew: said. Well, I think the other thing is that at that, the biggest difference to me, that's a big difference at these ⁓ middle sized companies. The biggest difference to me is, leadership, right? It's at a certain size company, there's just no way for any human to really understand all the things that are going on in the business. I think at a more middle sized company, those top 10 people in the company. actually have a really good grasp, right? If they're good, they have a really good grasp of what's happening in the business. And they obviously have the power and the scope of control to make change quickly, you know? And to me, that's the biggest thing is ⁓ working with these companies is when you get the right, when those leaders are really committed. especially the ones that have built the business, understand the business deeply, things along those lines, they can move mountains at a way that would be very hard even for the best CEO of a Fortune 500 company, because there's just, what it takes to move that mountain is so much different.
Nicole: I think that's right. think, you know, the other interesting thing ⁓ we were talking about, don't remember who said something, but here, ⁓ Stew, Jim, something you guys were saying was making me think about ⁓ how all of this ties into this sort of broad challenge it's not just solving the problem, because if you ask five different people in an organization, the same set of questions, you're going to get five different answers on what the challenges are. So it's the person who can synthesize a new way to approach that problem who's going to win. But now the challenge becomes change management because you really in order to solve these problems as systemically as you want to to make them lasting business value delivered. you really do change the way we're approaching these things. And in order to change, we're still dealing with people at the end of the day. And people, me most of all, people struggle with change. And so we really do have to have that aspect of change management considered in delivering these solutions.
Stew: And it's scary. You know, it's, it's, it is legitimately, I mean, I think anyone, you know, we've literally have said every world is changing, you know, to some degree, you know, and people like comfort, a lot of our, ⁓ and I mean, even, even the best people that are most open-minded that aren't, you know, just trying, you know, trying to sabotage things to keep their job or whatever we want to make up in our head. It's just, ⁓ it's a.
Nicole: That's right.
Stew: It's a big change and, and, and there's ⁓ a lot of these processes that had built up, ⁓ have been built up, you know, to, ⁓ over many years to, ⁓ protect, know, you know, because lots of mistakes, you know, every little thing in that process came in because there was some issue that caused it and we solved it. So there's a lot of comfort built up in these processes.
Nicole: That's right.
Stew: A lot of it hard won comfort over years. then so to tear that apart is it is scary. There's nothing not scary about it. But it's, but it doesn't mean it's not necessary.
Shanti Greene: Yeah, but the nature of work, the nature of everything we've done has changed in the last three years. We're just doing such different things that the resistance to change at this point is kind of futile, just like whatever it was that the boring sad resistance to futile. Yeah.
Nicole: you
Stew: Yeah. Yeah. Yeah.
Jim Johnson: Resistance is futile. Yeah. ⁓
Nicole: I like it to borg.
Shanti Greene: Yeah.
Stew: And yeah, yeah. And we can all wish it. You know, we can all wish me, you know, ⁓ it's like social media or smartphones or whatever. Right. We can all be nostalgic and say like, wow, our life would have been a lot better without social media. May or may not be true. There's pros and cons, but you can understand the perspective. I'm sure at some point, a lot of people will say, wow, you know, life was better without AI. It'll be, you know, there'll be pros and cons to that. But ⁓ it doesn't matter, it's here. You ain't changing it.
Shanti Greene: Yeah, I think the only thing that's going to slow AI adoption is if the cost increases dramatically. If somehow it becomes cost prohibitive to use, maybe we would see adoption slow. But I think what I can do just bifurcating and creating more haves and have nots that are further and further apart.
Nicole: Yeah, that's right.
Jim Johnson: Hey Stew, I want to come back to something you said around business process. know, 30, 40 years ago, the Germans in the form of SAP... tried to solve the business process challenge by in essence saying, this is the way you do order to cash. This is the way you do sort of all the set of processes, receivables, AP, et cetera. And said, you do it this way, move on to SAP, done. And a trillion dollars later, over three decades of... SAP integration work for people to sort of work around that because in the large enterprise, there's never a single business process for anything. There are in essence infinite exceptions and sort of thinking through that has always been the challenge. And to me, that the knowledge of how things get done, how work gets done in the enterprise, whether it's a small company, large company, that knowledge is gold right now. And, and the, the who sort of starts there and can work through it because it's not one way. It's never one way. It's always an infinite number of exceptions and to your point and guardrails and gates and everything else, it's sort of been hard won over the course of decades. ⁓ But the person who understands that and can sort of embrace the AI opportunity here in terms of what we call forward deployed engineer or whatever, the medium depth generalist. is going to have their day in the sun here for sure.
Stew: There's a hidden point that is an outcome of what you just said, I think, which is, you know, the reason why SAP standardized everything and the reason why most companies try to standardize wherever they could, right? Was because...
Jim Johnson: unsuccessfully, but they cried.
Stew: Building software has always been incredibly expensive, right? So I, as an enterprise would come in and say like, well, know, my business, my customers really would like to operate this way, but building that solution is so hard and so expensive that I'm going to standardize in this other way that's sub-optimized, but it works. The paradox here, and this is kind of the bull case for... why I don't think AI is going to destroy a lot of software engineering jobs or a lot of these other types of jobs. It's just going to change things is if the reality has always been that the real world's super messy. Every enterprise you go into because they're solving a different challenge in a different way than someone else has a way to do it.
Jim Johnson: 100%.
Stew: And what's happening and you see that you see this every good software engineer I know right now is working way harder than they've ever worked in their life. Every good business consultant I know right now is working way harder than they've ever worked in their life. A lot of good companies that are embracing AI are hiring, um, and not kind of just wholesale shedding.
Nicole: you
Stew: ⁓ staff or if they are shedding staff is more because they're reconstructing their workforce to get the skill mix right. I think it's, ⁓ and the reason for that is it's now more possible to solve those million little exceptions, right? Like, like, and so, so, and I think what you're actually going to get is an explosion of, of
Jim Johnson: The variations absolutely.
Stew: You know, that one problem that never would have made sense for me to, we all see this in our personal lives where we now like, buy code something for something stupid we wanted to do or whatever. And it's an app for one person because it's, can, ⁓ and it's not cost prohibitive. And that's why I think this is, I think we're, we're under worried around how much everyone's job has to change in the skill acquisition problems and things along that potentially. But I think we're over worried around.
Nicole: you
Stew: it killing demand for jobs. ⁓ think the people with these skills are going to be in very high demand for a long time.
Shanti Greene: Yeah, it's interesting to see how many different tasks, projects people will try to pull off. Like if you understand how good the AI products are and how to use them, it just means that you can do more things and then you really want to do more things because you can. So everybody I know who's really into this field is just super busy now because of that. They're like, well, I could do these 10 things, which you never would have even tried to do eight of them before.
Stew: Well, and the opportunity cost is so much higher. You know what I mean? it's like, you know, I think this is the AI psychosis that I think people that are getting good at this are is like, ⁓ I've got the psychosis and I can't go to bed until I start an agent on five hours of work or because the opportunity cost of not doing that is tremendous. You know, like. ⁓
Shanti Greene: Yeah. Well, I was like, sometimes I run out of like, what should I be building? I should clearly be building something. have these tokens that are going unused.
Stew: Yeah, exactly.
Nicole: Yeah, I love your point there, Shanti. I think this is one of the things that I always come back to. ⁓ I have two kids, one just out of school, one who's just finishing up college. you said there, the people with, or one of you said, the people with the skills are in high demand. And I think this is something, chasing a squirrel a little bit off topic here, I think this is something where the universities need to catch up. because we keep hearing the junior engineer is dead. It's not that the junior engineering role is dead. It's to the point of this whole discussion, it's evolved. And what the universities are doing today to their students is they have all these AI policy, AI use policies, don't use AI. And I understand they want to, university is about learning how to learn and we need to instill those base skills. But the universities, I think, are it's incumbent upon them to teach these AI skills. You know, as you were saying Shanti, we're all doing 10 projects where maybe eight of them weren't possible. I literally did a landscape design app for myself ⁓ and I showed the outcome to my landscaper who I paid to give me an actual plan that would work. And she's like, I'll pay you for this app. I'm not a software engineer, but she loved it. ⁓ We are all, those of us who are really embracing this AI first thing. We are so excited about what's possible. That's why I think we're working 10 times as hard. But again, coming back to the universities, this is where I think they need to empower these kids with these skills so that they will be in demand like the rest of us who are AI first.
Shanti Greene: Yeah, I'll throw something in there. So I teach in the master's program at Wash U St. Louis. I was teaching a applied analytics course there and we had some enrollment issues. So I ended up with two students for a course in this graduate level program. Like, well, what should we do to make this interesting? There's a bunch of new agentic data science tools that I don't have time to try out on my own. So every week I like I need you guys to go deep onto deep note. I want you to try to do this entire project end to end and let me know where you get stuck. Now I want you to do the same thing, but in hex and just go through these different tools. Now we'll use some of them together. Then we'll go through, was it your prompting that was bad? Was it that the tool is actually bad at data engineering? And a lot of what they're doing is generating some of the Python or say, now we can actually go through that and say, did it pick the right method? How did it compare them? And for their final project, they're like,
Stew: Awesome. That's amazing.
Shanti Greene: Here's what we're going to do. One of you is going to go do this on Gemini. The other one's going to do it on Claude. And we're going to see which model can solve this entire problem end to end. I want to see the presentations at the end, and I want them to all be AI generated. And let's see where this thing goes. It was lot of fun. Yeah.
Stew: That's awesome. That's really cool. Yeah, it's awesome. I think the other thing with not to divert too long on the education topic, but I think there's the other one is learning these skills around the tools and what is capable. And I think universities are probably well suited for that if they change in the right ways. Like Shanti's example is awesome.
Nicole: That's right. I love that. We need more of that in school. Agree.
Stew: But the other missing piece here is how do you learn that business? How do you learn the business, especially in this world where a lot of the junior roles are really, know, lot of what the way people learn the business in the past as they came in and did these things that are now AI is good at. And that to me is the biggest challenge. I think you might go back to more of like an apprenticeship. model, you know, where you, know, and basically it's almost like Shanti's two folks there are almost proving that right. And in a way it's almost like an apprenticeship of, of like, you know, Hey, sit here and watch me solve these problems and help understand these things and, kind of absorb the way this business really works is, is really a, it's probably more and more a model. versus you coming in and learning the business by creating spreadsheets that are now automatable or whatever.
Nicole: school ahead.
Shanti Greene: Yeah, one of the things we loved doing in the Innovation Hub back in the door, the days, and we do an answer rocket as well is on the data science side. do a lot of these just long working sessions where everybody jumps on their call together. One person is sharing their screen and doing stuff and everybody else is just kind of watching them throwing in comments, which feels super awkward at first. Now we've a bunch of us who've been together for a while, been doing it for five or six years, but every time somebody new comes into that group and we're.
Stew: .
Shanti Greene: like, cool, share your screen and then six people will stare at you and make a bunch of side comments to each other while you're trying to do something. It's, you know, it's weird for them, but it really does get you to that some of that apprenticeship part, you get to watch how other people work, which is very difficult to do with everybody being remote. So senior people end up kind of being isolated because they don't need that. So they can do a lot of that stuff on their own. But if you
Stew: I love it.
Shanti Greene: bring the group in with you without trying to slow you down by just having them kind of observe and be part of it. You can bring the whole company up.
Jim Johnson: Okay, that's cool, but terrifying for someone like me who's sort of computer use skills are inversely proportional to the number of people who are in the meeting and watching. So let's, let's bring it all back around. So we sort of, there's a lot of what's old is new again, in terms of business process and BAs we sort of solved for the educational system today, which is awesome. Also. ⁓
Shanti Greene: Mm-hmm. You
Jim Johnson: We've sort of acknowledged some of the organizational challenges, especially maybe in large enterprises. ⁓ But I think the unifying and clarifying point here is the... And maybe universities should love this in terms of the Renaissance person. I won't use the Renaissance man anymore. I'll say the Renaissance person in terms of a balanced set of skills. And I think ultimately my sense in listening to this group and sort of what, you know, out there research and reading is that's gonna matter a lot. And we're at a place right now where the mix of business skills, the mix of AI skills, the mix of some technology skills. This is sort of a, and then what you can do with that mix of skills is we've never been able to do before. So it's an awesome opportunity, whether we call it the FDE, the Forward Deployed Engineer, there's a lot of baggage in that, we've all agreed. ⁓ But this is sort of a really interesting jumping off point. How do we transition our workforce, our team members, our organizations to embrace it? We'll see. We can talk a lot more about org change. But thank you. Episode 19 in the can guys. Thanks all. Appreciate it.
Shanti Greene: That's been fun. Have a good one. See ya.
Nicole: Thanks everyone.
Nicole: .
Jim Johnson: maybe with the hype cycle around Palantir. We want to have a discussion about the concept of the forward deployed engineer and what it means. ⁓ You know, I'll try to avoid sort of going too far into a joke here, but you know, it seems like LinkedIn's caught fire as it relates to the concept of the forward deployed engineer. And now sort of every software engineer is calling themselves a forward deployed engineer. We want to roll around in this and talk about what it really means. and what we're seeing in the market. ⁓ That said, let's just dive in. Stew, I know you're sort of out there on the edge in terms of ⁓ bringing value to some clients and wanted to get your perspective on what this means, maybe what the world thinks it means and we think it really means and where this is headed.
Stew: Yeah, I mean, as we know, one of the problems you have when ⁓ a term becomes popular is then ⁓ it gets overused and taken over by ⁓ everyone. So we were joking earlier that, you know. everyone now has changed their resume to be a forward deploy, know, scratched off like crypto engineer and then, ⁓ you know, ⁓ whatever was next. then, ⁓ you know, is now throwing in forward deployed engineer. But I think that also speaks to the value, you know, there usually when that happens, there is some sort of underlying thing that has driven it to be popular and recognized. And I, you know, I think The reality as you pointed out is ⁓ with AI now, roles are merging together. And there was actually, ⁓ it reminds me of, ⁓ I was listening to a Mark Andreessen podcast recently and he talked about how the best product managers he knows, the best product developers he knows and the best designers he knows are all convinced that they don't need the other two roles anymore. You know, and, ⁓ and they're probably all right to a level because it's much more, you know, the value is, is starting to converge on being able to put all these pieces together. Cause you can have the AI take care of a lot of the details, but the big picture, what am I actually trying to achieve? What is the process I'm trying to run? ⁓ stays consistent. So I think this is, to me it's exciting. And you know, Nicole and I both came up through the world, I think on the front lines, actually, you we called them solutions engineers or technical consultants or all sorts of other things for many years. And, you know, we were always hamstrung to an extent because we would be on there on the front lines, working with clients, trying to solve problems, deeply understanding the domain. There was always a lot of information lost as you tried to bring that back into the product team. So to me, it's just very exciting that ⁓ the people who are really good at that and on the front lines, understanding customer problems now actually have capabilities where they can ⁓ take on more of that themselves and solve problems.
Shanti Greene: Yeah, something, something I've thought about is, a lot of us talk about the junior software development role going away. And when you start thinking about why that is, it's not just because LLMs are good at writing code. When you think about what senior software engineers had done is they had started understanding the business and understanding the users of their software product and what they needed and had started picking up parts of the product roles because they really got what they were building and knew why they were building it.
Jim Johnson: Awesome.
Shanti Greene: part of the reason that they're going to be more successful with AI is they're able to better spec what they need, not just because of their actual software development capability, but because they have picked up the business capability as well. And I think that's also what we're seeing, that those senior folks who are being really well empowered by AI tools are the ones who understood the business, can start writing some of the specs and actually understood the value of product to begin with and spectrum of development.
Nicole: I think that's right. I think I agree with everything that Shanti are saying here. And this is ⁓ one ⁓ challenge I have with this term is it's ever we call it a forward deployed engineer. ⁓ so everyone who is sort of peripherally listening to that assumes this has to be a software engineer filling that role. But the theme between both Stew and Shanti statements is they need to understand the business. So I would argue that in this world where AI has come so far and what AI does well is build the code. What AI doesn't do well yet is understand the business. It is that consultant who is that forward deployed consultant who is bringing the business value into the solution. And I think to Stew's point, there's a converging of roles here where this forward deployed consultant can build out the prototypes work with the customer to make sure they're targeted at solving that correct business problem, and then work in the back end with the engineers to do what they do well and productize that. I think the key, so I think you can have two different sort of profiles to become this forward deployed engineer type. You can have the consultant type who is natively business first, who asks the right questions to get to the right business value. and is technically aware enough of AI solutions to build prototypes. Or you can have the software engineer, to Shanti's point, who is more senior, who understands they're not just following the orders their product management wrote for them in a JIRA ticket. They're actually understanding the context of the business problem that they're trying to solve. I think both of those profiles work in this forward deployed role.
Jim Johnson: Bye.
Nicole: So the problem I have is that everyone calls it the forward deployed engineer. I think it's much more a forward deployed consultant ⁓ that's required today.
Shanti Greene: Nicole, it sounds like you're describing the business analyst role. They were the bridge between technology and the business. And sometimes they wrote light code. They did some initial analysis. That role seems to exist. guess we're re...
Nicole: 100%.
Jim Johnson: It went of vogue because of Agile. The BA of got into a strange place, but I ⁓ hear you're saying. I think it's sort of relevant here again.
Shanti Greene: ⁓ okay. Yeah, that sounds like what that job was supposed to be.
Stew: I think there's a couple of things though in defense of the forward deployed engineer. There's a couple of points I would like to make. one is I think if we look at, ⁓ we can all think good or bad things about Palantir. ⁓ I'm certainly not a fan boy for Palantir, but they popularized the term and I've listened to a lot of their, ⁓ you know, things around this term. I think there's one element of this role that I think is very important and it does require architect or engineering level skills. And that is the best for deployed engineers or solution engineers or whatever we want to call them are good at not only solving customer A's problem, but at helping generalize that problem. and abstracting up a layer so that you can build something that then advances your capability to also help customer B, C, D, and E over time. And that's a lot of the actual flywheel at a lot of these companies like a Palantir that popularized the term. ⁓ So I do think some engineering and architecting skills are necessary. The next thing though, is I think What we see in our head when we talk about a software engineer, it probably really needs to change. let's just think about the term engineering. So we don't expect the engineer who's working on the bridge to be the one ⁓ putting in the bolts or welding or ⁓ whatever the heck else you have to do to build. pouring the concrete with all the things you have to do in order to build the bridge, right? They've helped design that work, they're overseeing that work, ⁓ but it's always been a skill we see as an abstracted skill, right? From the actual physical work of doing it. Now lot of engineers are really good at doing physical work as well, and that's true in software. But I think we need to rethink what we mean by engineering. And I think it is... I think the best people in these roles, even if they can't sling, you know, C++, you know, are still have those engineering capabilities in terms of being able to think very ⁓ systematically about the solution they're building and really have a clarity in their mind around where the abstraction points are, et cetera.
Jim Johnson: Making the transition, sort of how work gets done, getting it done this way, it's readily apparent that a team of three or four can move mountains now. If they have that right blend of skills and you sort of look at the Venn diagram, maybe we're gonna get to a point where a team of one can move mountains. ⁓ and have all the requisite functional domain knowledge of the business and domain knowledge of the data and the AI skills and enough IT skills and maybe enough of that sort of the backend wiring it up gets abstracted away as well here as we move forward and a team of one can do it. But a team, a small team can move mountains. ⁓ We have the good fortune of working with sort of mid-cap, mid-sized companies that are trying to sort of change the world. And that's a lot of fun. We also work with a lot of large organizations. I think there may be organizational challenges, organizational structure challenges in large companies that they're not necessarily aligned.
Nicole: you
Jim Johnson: with how work can get done this way today, because they've been constructed to sort of have deep specialization and division of labor and constructed around processes and the fluidity associated with how this work can get done is a different animal. Any thoughts or reactions on that
Shanti Greene: One of the that the large companies, ⁓ especially that have large software practices can afford to have is what one my favorite architects referred to as the sunny engineer, the software developer who has their niche and when everything else lines up around them is great and can be very productive. but isn't quite able to think outside the box and fix things when they start breaking in new and unforeseen ways. That's what's happening with agentic development. Things are breaking in new and different ways. And we're customizing software for an application all the time. Everything we're building is pretty unique. And then to Stew's point, we try to abstract it, try to reuse components of it, but we can keep custom building. So the engineers who fall into these newer roles have to be a little more flexible in how they think about problems. A lot of the what you learned in school, the best way to do it kind of works, but not quite. And the smaller the company, the more nimble you have to be to be able to adapt to those environments.
Stew: Yeah, I think too that I want to emphasize, I think you made a point that's really should be emphasized and brought home more, which is the way you engineer an architect changes a lot because of how certain things have become easier. It used to be, you had to spend a lot of time upfront, really architecting a lot of things because if you didn't get that right, back in cost of fixing it once you had the final solution was so high. I think things are now swapping where ⁓ the better thing to do is to go solve the customer's problem in the best, fastest way you can. even if it's this ugly house of cards on the back end, because that is really almost like a spec, right? That suddenly becomes like, okay, I might not have solved it in the best prettiest way, but this is a solved problem. And, you know, these were my inputs, these were my outputs, that's, you know, that they were both acceptable.
Nicole: Yes.
Stew: AI is really, really good once you have that defined, cleaning up ⁓ everything in the middle, ⁓ right? And kind of re-engineering it to be in a better way. And so I think that, and this probably is one of the reasons why that forward deployed engineer is even more valuable is I think there's just a much higher premium to go out, solve the problem. And then we can come in and clean it up. And it's inverted from the way software worked for a long time.
Nicole: I think that's exactly right. And I think that's why I think that the technical consultant can be that forward deployed person building that. And then we come at the back end. some engineers are going to come in, if they don't deeply understand the business problem, they're going to solve the wrong problem fast. That doesn't do anyone any good. We want business forward, ⁓ people who ask the right question to focus on the right problem to create that. version one that you're describing, Stew, and then come to the back end and solve it. I want to come back to the point that Jim made about ⁓ large enterprises and the challenges with their organizational structure, having teams that have specific skills and they're very siloed. I will say even as a small organization, it's been a challenge to converge those skills. So there is... ⁓ This is not something to be glossed over. This is something that every organization is going to have to face and embrace in order to succeed going forward. And it's not a small challenge. It is, you need every single person in your organization. I want to go back to your original point, Stew, about product managers don't think they need the other roles. Engineers don't think they need the other roles. No one thinks they need the other roles anymore, but that's only if... every role is leading with an AI first approach. And I think it's the transition of the organization to that AI first approach that really ultimately delivers the value. And it's difficult for these large enterprises that are so instantiated.
Jim Johnson: Well, there's whole career models and progression structures and compensation structures and just it's all been constructed.
Nicole: Uh-huh.
Jim Johnson: to sort of, many years ago it was all constructed around the waterfall model and then sort of lot of people sort of embrace the agile model and throw in the mix of sort of multi-geography, onshore, nearshore, and it becomes harder and there's not necessarily clarity of the career model that says, hey, if you're starting over here as a sort of deeply skilled ⁓ engineer or architect, how do you sort of incorporate these other things? Or if you're starting over here as a person, how do you incorporate these other skills because they do start to merge together and ⁓ how do we sort of reward that, address that, and value that in a way that it's clear that that's what we're trying to achieve. there's a whole, there's decades frankly of
Nicole: Yeah.
Jim Johnson: structure that's been in place to do it a different way. And it's going to be sort of hard. And maybe some of this will just sort of happen as a normal course of events, and it's happening behind the scenes. And those people who are sort of stepping forward are the ones who are saying, OK, I'm going to go embrace. I'm going to deeply understand what the business problem is and bring my engineering skills and bring my AI skills, or vice versa. But there's not a defined progression for people yet at this time.
Stew: I think too, we have to look at why a lot of the organizational structure of, these companies. And I was going to make the same point. ⁓ Nicole did when we were talking about the big companies, I was like, wow, I don't, you know, I'm not sure that a lot of the middle companies aren't in terms of, aren't suffering from the same problems, just maybe at a different scale. But I think a lot of, ⁓ a lot of the way these organizations have built up over time has been to protect. Highly valued finite resources and at most companies there's tremendous amount. Even just like take a software company as an example, which I spent a lot of time working with software companies. Software companies have spent, have built up enormous infrastructure to protect the software engineer, right? Because everything was always bottlenecked around that element of the process. That's no longer really the bottleneck, you know? And ⁓ so you would spend like literally, you know, even now still spend longer in a meeting talking about what the roadmap should look like or what a spec should be or, having six people deep dive into one thing. It's kind of like, well, you guys had six ideas on how this could be done in the time we just spent arguing about it. We could have done all six and, and tested them against each other, you know? And so it's a lot of it is, is of the organizational bit. A huge part of it is that everyone's role is different.
Shanti Greene: Yup.
Stew: and they are emerging. the reason why the engineer, the product manager, and the designer don't think they need the other two is because no one's role is the same anymore. The definitions of the roles are changing. But I also think another element to this is the bottleneck points are changing. And so much of our organizational structures are built around protecting the old bottleneck points instead of solving what are becoming the new bottleneck points and tying it back to the forward deploy an engineer. The new bottleneck point, the most important, biggest new bottleneck point is clarity on what actually solves the problem we're trying to solve. ⁓ And so I think that's where forward deployed engineers or consultants are really important. Go ahead,
Nicole: I would argue it's clarity on the problem we're trying to solve rather than how to solve the problem.
Stew: I agree. Yeah. It's a better way of saying it. I agree.
Jim Johnson: Well, and the problem is being redefined because to simply say, hey, you know, in supply chain or hey, in marketing, this is sort of always been the problem. And now we have a new tool. We've got an opportunity to sort of totally rethink it ⁓ from a business process standpoint, how work gets done. The problem may not even be the same problem anymore. And sort of people who can think about how this could work in a world where you have unlimited intelligence.
Nicole: Yes.
Jim Johnson: unlimited capacity sort of labor and described in the right way here in the digital world, at least right now, ⁓ until Elon Musk delivers all of his robots. ⁓ That's sort of the opportunity to redefine it and people who can think that way. That's a different thing. The one other thing I would come back to, though, on this mid cap versus large organization point, I do think there is in some cases in smaller companies, a ⁓ you'll run into people who sort of wear a lot of hats or are used to wearing a lot of hats. there is sort of an, there's not the calcification of organizational structure that is an additional burden, I think, in embracing this that you might have in a large organization. So it doesn't mean that they're not starting from a challenging point. It doesn't mean that, you know, it's not obvious that you have somebody with all the skills, but there may be a little more fluidity there that...
Stew: said. Well, I think the other thing is that at that, the biggest difference to me, that's a big difference at these ⁓ middle sized companies. The biggest difference to me is, leadership, right? It's at a certain size company, there's just no way for any human to really understand all the things that are going on in the business. I think at a more middle sized company, those top 10 people in the company. actually have a really good grasp, right? If they're good, they have a really good grasp of what's happening in the business. And they obviously have the power and the scope of control to make change quickly, you know? And to me, that's the biggest thing is ⁓ working with these companies is when you get the right, when those leaders are really committed. especially the ones that have built the business, understand the business deeply, things along those lines, they can move mountains at a way that would be very hard even for the best CEO of a Fortune 500 company, because there's just, what it takes to move that mountain is so much different.
Nicole: I think that's right. think, you know, the other interesting thing ⁓ we were talking about, don't remember who said something, but here, ⁓ Stew, Jim, something you guys were saying was making me think about ⁓ how all of this ties into this sort of broad challenge it's not just solving the problem, because if you ask five different people in an organization, the same set of questions, you're going to get five different answers on what the challenges are. So it's the person who can synthesize a new way to approach that problem who's going to win. But now the challenge becomes change management because you really in order to solve these problems as systemically as you want to to make them lasting business value delivered. you really do change the way we're approaching these things. And in order to change, we're still dealing with people at the end of the day. And people, me most of all, people struggle with change. And so we really do have to have that aspect of change management considered in delivering these solutions.
Stew: And it's scary. You know, it's, it's, it is legitimately, I mean, I think anyone, you know, we've literally have said every world is changing, you know, to some degree, you know, and people like comfort, a lot of our, ⁓ and I mean, even, even the best people that are most open-minded that aren't, you know, just trying, you know, trying to sabotage things to keep their job or whatever we want to make up in our head. It's just, ⁓ it's a.
Nicole: That's right.
Stew: It's a big change and, and, and there's ⁓ a lot of these processes that had built up, ⁓ have been built up, you know, to, ⁓ over many years to, ⁓ protect, know, you know, because lots of mistakes, you know, every little thing in that process came in because there was some issue that caused it and we solved it. So there's a lot of comfort built up in these processes.
Nicole: That's right.
Stew: A lot of it hard won comfort over years. then so to tear that apart is it is scary. There's nothing not scary about it. But it's, but it doesn't mean it's not necessary.
Shanti Greene: Yeah, but the nature of work, the nature of everything we've done has changed in the last three years. We're just doing such different things that the resistance to change at this point is kind of futile, just like whatever it was that the boring sad resistance to futile. Yeah.
Nicole: you
Stew: Yeah. Yeah. Yeah.
Jim Johnson: Resistance is futile. Yeah. ⁓
Nicole: I like it to borg.
Shanti Greene: Yeah.
Stew: And yeah, yeah. And we can all wish it. You know, we can all wish me, you know, ⁓ it's like social media or smartphones or whatever. Right. We can all be nostalgic and say like, wow, our life would have been a lot better without social media. May or may not be true. There's pros and cons, but you can understand the perspective. I'm sure at some point, a lot of people will say, wow, you know, life was better without AI. It'll be, you know, there'll be pros and cons to that. But ⁓ it doesn't matter, it's here. You ain't changing it.
Shanti Greene: Yeah, I think the only thing that's going to slow AI adoption is if the cost increases dramatically. If somehow it becomes cost prohibitive to use, maybe we would see adoption slow. But I think what I can do just bifurcating and creating more haves and have nots that are further and further apart.
Nicole: Yeah, that's right.
Jim Johnson: Hey Stew, I want to come back to something you said around business process. know, 30, 40 years ago, the Germans in the form of SAP... tried to solve the business process challenge by in essence saying, this is the way you do order to cash. This is the way you do sort of all the set of processes, receivables, AP, et cetera. And said, you do it this way, move on to SAP, done. And a trillion dollars later, over three decades of... SAP integration work for people to sort of work around that because in the large enterprise, there's never a single business process for anything. There are in essence infinite exceptions and sort of thinking through that has always been the challenge. And to me, that the knowledge of how things get done, how work gets done in the enterprise, whether it's a small company, large company, that knowledge is gold right now. And, and the, the who sort of starts there and can work through it because it's not one way. It's never one way. It's always an infinite number of exceptions and to your point and guardrails and gates and everything else, it's sort of been hard won over the course of decades. ⁓ But the person who understands that and can sort of embrace the AI opportunity here in terms of what we call forward deployed engineer or whatever, the medium depth generalist. is going to have their day in the sun here for sure.
Stew: There's a hidden point that is an outcome of what you just said, I think, which is, you know, the reason why SAP standardized everything and the reason why most companies try to standardize wherever they could, right? Was because...
Jim Johnson: unsuccessfully, but they cried.
Stew: Building software has always been incredibly expensive, right? So I, as an enterprise would come in and say like, well, know, my business, my customers really would like to operate this way, but building that solution is so hard and so expensive that I'm going to standardize in this other way that's sub-optimized, but it works. The paradox here, and this is kind of the bull case for... why I don't think AI is going to destroy a lot of software engineering jobs or a lot of these other types of jobs. It's just going to change things is if the reality has always been that the real world's super messy. Every enterprise you go into because they're solving a different challenge in a different way than someone else has a way to do it.
Jim Johnson: 100%.
Stew: And what's happening and you see that you see this every good software engineer I know right now is working way harder than they've ever worked in their life. Every good business consultant I know right now is working way harder than they've ever worked in their life. A lot of good companies that are embracing AI are hiring, um, and not kind of just wholesale shedding.
Nicole: you
Stew: ⁓ staff or if they are shedding staff is more because they're reconstructing their workforce to get the skill mix right. I think it's, ⁓ and the reason for that is it's now more possible to solve those million little exceptions, right? Like, like, and so, so, and I think what you're actually going to get is an explosion of, of
Jim Johnson: The variations absolutely.
Stew: You know, that one problem that never would have made sense for me to, we all see this in our personal lives where we now like, buy code something for something stupid we wanted to do or whatever. And it's an app for one person because it's, can, ⁓ and it's not cost prohibitive. And that's why I think this is, I think we're, we're under worried around how much everyone's job has to change in the skill acquisition problems and things along that potentially. But I think we're over worried around.
Nicole: you
Stew: it killing demand for jobs. ⁓ think the people with these skills are going to be in very high demand for a long time.
Shanti Greene: Yeah, it's interesting to see how many different tasks, projects people will try to pull off. Like if you understand how good the AI products are and how to use them, it just means that you can do more things and then you really want to do more things because you can. So everybody I know who's really into this field is just super busy now because of that. They're like, well, I could do these 10 things, which you never would have even tried to do eight of them before.
Stew: Well, and the opportunity cost is so much higher. You know what I mean? it's like, you know, I think this is the AI psychosis that I think people that are getting good at this are is like, ⁓ I've got the psychosis and I can't go to bed until I start an agent on five hours of work or because the opportunity cost of not doing that is tremendous. You know, like. ⁓
Shanti Greene: Yeah. Well, I was like, sometimes I run out of like, what should I be building? I should clearly be building something. have these tokens that are going unused.
Stew: Yeah, exactly.
Nicole: Yeah, I love your point there, Shanti. I think this is one of the things that I always come back to. ⁓ I have two kids, one just out of school, one who's just finishing up college. you said there, the people with, or one of you said, the people with the skills are in high demand. And I think this is something, chasing a squirrel a little bit off topic here, I think this is something where the universities need to catch up. because we keep hearing the junior engineer is dead. It's not that the junior engineering role is dead. It's to the point of this whole discussion, it's evolved. And what the universities are doing today to their students is they have all these AI policy, AI use policies, don't use AI. And I understand they want to, university is about learning how to learn and we need to instill those base skills. But the universities, I think, are it's incumbent upon them to teach these AI skills. You know, as you were saying Shanti, we're all doing 10 projects where maybe eight of them weren't possible. I literally did a landscape design app for myself ⁓ and I showed the outcome to my landscaper who I paid to give me an actual plan that would work. And she's like, I'll pay you for this app. I'm not a software engineer, but she loved it. ⁓ We are all, those of us who are really embracing this AI first thing. We are so excited about what's possible. That's why I think we're working 10 times as hard. But again, coming back to the universities, this is where I think they need to empower these kids with these skills so that they will be in demand like the rest of us who are AI first.
Shanti Greene: Yeah, I'll throw something in there. So I teach in the master's program at Wash U St. Louis. I was teaching a applied analytics course there and we had some enrollment issues. So I ended up with two students for a course in this graduate level program. Like, well, what should we do to make this interesting? There's a bunch of new agentic data science tools that I don't have time to try out on my own. So every week I like I need you guys to go deep onto deep note. I want you to try to do this entire project end to end and let me know where you get stuck. Now I want you to do the same thing, but in hex and just go through these different tools. Now we'll use some of them together. Then we'll go through, was it your prompting that was bad? Was it that the tool is actually bad at data engineering? And a lot of what they're doing is generating some of the Python or say, now we can actually go through that and say, did it pick the right method? How did it compare them? And for their final project, they're like,
Stew: Awesome. That's amazing.
Shanti Greene: Here's what we're going to do. One of you is going to go do this on Gemini. The other one's going to do it on Claude. And we're going to see which model can solve this entire problem end to end. I want to see the presentations at the end, and I want them to all be AI generated. And let's see where this thing goes. It was lot of fun. Yeah.
Stew: That's awesome. That's really cool. Yeah, it's awesome. I think the other thing with not to divert too long on the education topic, but I think there's the other one is learning these skills around the tools and what is capable. And I think universities are probably well suited for that if they change in the right ways. Like Shanti's example is awesome.
Nicole: That's right. I love that. We need more of that in school. Agree.
Stew: But the other missing piece here is how do you learn that business? How do you learn the business, especially in this world where a lot of the junior roles are really, know, lot of what the way people learn the business in the past as they came in and did these things that are now AI is good at. And that to me is the biggest challenge. I think you might go back to more of like an apprenticeship. model, you know, where you, know, and basically it's almost like Shanti's two folks there are almost proving that right. And in a way it's almost like an apprenticeship of, of like, you know, Hey, sit here and watch me solve these problems and help understand these things and, kind of absorb the way this business really works is, is really a, it's probably more and more a model. versus you coming in and learning the business by creating spreadsheets that are now automatable or whatever.
Nicole: school ahead.
Shanti Greene: Yeah, one of the things we loved doing in the Innovation Hub back in the door, the days, and we do an answer rocket as well is on the data science side. do a lot of these just long working sessions where everybody jumps on their call together. One person is sharing their screen and doing stuff and everybody else is just kind of watching them throwing in comments, which feels super awkward at first. Now we've a bunch of us who've been together for a while, been doing it for five or six years, but every time somebody new comes into that group and we're.
Stew: .
Shanti Greene: like, cool, share your screen and then six people will stare at you and make a bunch of side comments to each other while you're trying to do something. It's, you know, it's weird for them, but it really does get you to that some of that apprenticeship part, you get to watch how other people work, which is very difficult to do with everybody being remote. So senior people end up kind of being isolated because they don't need that. So they can do a lot of that stuff on their own. But if you
Stew: I love it.
Shanti Greene: bring the group in with you without trying to slow you down by just having them kind of observe and be part of it. You can bring the whole company up.
Jim Johnson: Okay, that's cool, but terrifying for someone like me who's sort of computer use skills are inversely proportional to the number of people who are in the meeting and watching. So let's, let's bring it all back around. So we sort of, there's a lot of what's old is new again, in terms of business process and BAs we sort of solved for the educational system today, which is awesome. Also. ⁓
Shanti Greene: Mm-hmm. You
Jim Johnson: We've sort of acknowledged some of the organizational challenges, especially maybe in large enterprises. ⁓ But I think the unifying and clarifying point here is the... And maybe universities should love this in terms of the Renaissance person. I won't use the Renaissance man anymore. I'll say the Renaissance person in terms of a balanced set of skills. And I think ultimately my sense in listening to this group and sort of what, you know, out there research and reading is that's gonna matter a lot. And we're at a place right now where the mix of business skills, the mix of AI skills, the mix of some technology skills. This is sort of a, and then what you can do with that mix of skills is we've never been able to do before. So it's an awesome opportunity, whether we call it the FDE, the Forward Deployed Engineer, there's a lot of baggage in that, we've all agreed. ⁓ But this is sort of a really interesting jumping off point. How do we transition our workforce, our team members, our organizations to embrace it? We'll see. We can talk a lot more about org change. But thank you. Episode 19 in the can guys. Thanks all. Appreciate it.
Shanti Greene: That's been fun. Have a good one. See ya.
Nicole: Thanks everyone.
