Arguing Agile

AA218 - Palantir's Forward Deployed Software Engineer - Revolution or Rebrand?

• Brian Orlando • Season 1 • Episode 218

Share episode

Today we're examining Palantir's "Forward Deployed Software Engineers" - and separating fact from the hype!

Everything old is new again! Move over companies that have been doing this for decades such as SAP, IBM, and countless consulting firms!

https://blog.palantir.com/a-day-in-the-life-of-a-palantir-forward-deployed-software-engineer-45ef2de257b1

Listen as we break down Palantir's 2020 blog post about their Forward Deployed Software Engineers (FDSEs) and discover what these engineers actually do versus what the marketing claims...

Key topics covered:

  • What FDSEs actually do, day-to-day
  • How this compares to traditional consulting roles
  • The difference between software configuration and software engineering
  • Why embedded customer roles aren't new
  • Career advice for aspiring technical professionals

If you're interested in understanding the reality behind tech industry buzzwords, this is your episode!

#ProductManagement #SoftwareEngineering #TechCareers #Consulting #Leadership #AgileCoaching

LINKS
= = = = = = = = = = = =
YouTube: https://youtu.be/SGvJK-aruJ8
Spotify: https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3
Apple: https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596
Website: http://arguingagile.com
= = = = = = = = = = = =
Toronto Is My Beat (Music Sample)
By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)
CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

have you ever heard of a little company called Palantir? I have. They may or may not be evil, but we're not talking about that today. Don't get excited. We're not judge of Yeah, yeah, we would never do that. Not on a Tuesday this article's from 2020, but they were hailed in the media for having forward deployed software engineers, calling them out as like a model for a great way to work with your engineers where they, we work directly at the customer and I can't remember exactly the article I read, but it was like, you agileists should be like, lauding them for working directly with the customer and it's closest to the roots of what y'all are looking for. And, I looked at it and I said, should I be impressed? When I first read this article, I didn't come away with the impression that this is groundbreaking stuff that this is not anything new, but the terminology is Right. Ford deployed software engineer, you're not behind enemy lines or anything for god's sake. Sure, sure so they've just added this kind of vernacular around it, but also the, the crux of it is these engineers are again, another vernac embedded with customers. Where, where, where was it that we've seen this before, right? In the past where engineers would go out with the salespeople and work directly with the customers, even in the early lifecycle. Oh, don't sales, right? Don't say that on Reddit because they were very vehement about they, this is not a sales engineering position. We're gonna read the article and get into that the article is on blog.palantir.com. I'll put a link in the show description. All right, so I put the article on the screen. It's called A Day in the Life of a Palantir Forward deployed Software Engineer. It's from November 2nd, 2020. It's quite old. I mean like in terms of following the current trends blogosphere, it's like 15 ice ages ago at least but it starts off by saying Brian is a forward deployed software engineer. That's me, by the way. Brian is a forward deployed software engineer at Palantir, currently focused on delivering data integration solutions to a US Department of Defense customer. We sat down with Brian to learn about the FDSE role in his day-to-day life at Palantir. That's what the whole article is gonna be about. So what is this role? What do these people do? Okay. You're a forward deployed software engineer. What is that? Forward deployed software engineer, FDSE, or quote, Delta is a software engineer who embeds directly with our customers to configure Palantirs existing software platforms to solve their toughest problems while a traditional software engineer or dev, that's, they didn't put SWE on here. SWEeee. My, my favorite. My favorite. Yes. Shortening of dev focuses on creating a single capability that can be used for many customers. F DSEs focus on enabling many capabilities for a single customer. We are deployed across many industries and problem domains, so the breadth of projects we tackle is large and always evolving. Since joining Palantir, I've had the chance to work across cyber healthcare and defense. So he's a sales engineer, like a post-sales engineer. What, what do they used to call? The people that came in after sales sold the contract, but the people that had to set them up because they would you would sell the contract, but then people would come in and have to set you up and get you functioning before the, they would cash a check. Are the, is that the sales engineering team or It was professional services team. It a number of different different titles so, so sometimes they were called pre-sales engineers, uhhuh because you hadn't quite pinned the contract at that point. Sales engineers, because they go out with the sales team. And do this stuff again, not before the contract signed necessarily, but it starts before the contracts signed. So maybe they'll go out to like exhibitions or conferences or whatever, and set up a demo. When a customer comes in and they're interested, they engage with the customer, not at the high holistic sales level, but deeper in, in their data, in their, in their company. Yeah. So if you have technical folks in the audience that are engaging with these people, they can actually talk the same language, right? Mm-hmm . used to be called sales engineer, right? Or pre-sales engineer, some variation thereof. Presale , pre-sales is before the contract is signed. And then whatever comes after presales is like good luck kid. You're on your own. It's just professional services of which the company puts in the contract you get a certain number of hours or months What do they used to call hypercare after the main period is over? That kinda stuff. When I was at a utility I worked with teams from Deloitte and IBM and pwc, and there was another place teams from all the big consulting firms I don't think I ever, I don't think I work with a McKenzie team. I don't think. And they all had people like this. Oh I'm sorry. The other one was, s-A-P-S-A-P was the other one. And they embed people like they, they make a sale and that sale is like, I get like vendors like IBM, stuff like that. They don't, well, IBM's a bad example, like vendors like Deloitte. They're not selling you any technology. They're selling you professional services to implement something. The SAP folks, on the other hand, they are selling you technology like you lease and services, they call it solutions, and services , and you get basically the people that they have there on site with you need them to be experts at their database design when they add modules and integrate their tables with your tables and tell you exactly what primary keys to go with and stuff like that. It's like you could do it on your own. You could learn to do it on your own. It's a tough road with complex systems like SAP for example, it so it's difficult to get there quickly without this help which is why these companies and SAP P is a great example. They don't just sell you the software, right? They sell you a solution. So the software is part of it, but also some services are part of it where these people are embedded. As the article says with the customer to synthesize and customize a solution to solve the customer's specific problems yeah. But if you look at the actual software that, that comes out of the box, it won't solve anybody's specific problems necessarily. Alright, let me continue with the article 'cause it's not really a long article. Iterating closely with customers across the various industries requires a unique and broad skillset ranging from software development to data engineering to customer engagement and creative problem solving , if this person is sitting in the room, I would like to poke and prod and say, really? Tell me a little more about your. Data engineering that you do at this customer? Like is it like setting up ETL pipelines and doing transforms and stuff like that at a broad, massive scale? Or are you like taking in a spreadsheet once in a while? Like what kind of data engineering are you talking about? Like how much of this is like sales bluster? Mm-hmm. And how much is like actual real work? Okay. I need to address questions like what products are we deploying for this use case? Why are we deploying them? How will we spin up workflows that utilize these products to address the customer's specific needs? As f DSEs, not only do we need to be able to answer these questions, but we actually implement the solution in collaboration with end users. Okay. I dunno, I don't, nothing new there that really like shakes my, no, I mean the qualities that these people bring aren't just the technology that their company is offering or technology in general, even Right. A key quality is really just listening to the customer, understanding their pain points. Mm-hmm. And then figuring out how they can be solved using a mix of technical pieces. Right? Yeah. Starting with your own company's technology. Yeah. But then anything else that might be needed. I mean, that sounds like a consultant with like a proprietary package of software that comes with them so I'm a consultant and I've got a bunch of software and services like that come with me that I can draw on. I told this story when we were prepping for this episode. I used to work for a company that had this particular software package called Gateway. And Gateway was exactly what it was. It was the gateway between a bunch of external services, APIs, mailboxes, yeah. Fax machines, like dozens of things, right?. And you can configure this gateway service with like a million plugins. You can make it as complex as you want, but you could also make it as simple as you want hey, just monitor this email inbox.. And whenever someone sends me an email, grab it and orchestrate it through the workflow pipeline of like if it's got this, then do this. If it doesn't have that, then do whatever , this is a lot of that kind of thing I've got this software, it's really powerful, but by itself, if you don't put any inputs and outputs, it doesn't do anything. It doesn't do anything. Yeah. And also If you just put the simplest inputs and simplest outputs, you're not gonna get any real leverage with the system where if you know how to configure it, it can really relieve a lot of pressure for your users. You know? Yeah. I mean, , those are very, very common back in the day these predictive sort of workflow analysis and management type of tools and quite, a lot of it actually, now that I think about it. It was not necessarily to do with the proprietary software that a vendor brings, although that was at the center of it, but around it there's a lot of other bits and pieces, right, that you can. Some of it was free, some of it was just other proprietary software. Like for example, you might have needed Adobe or something like that so this was very, very common. But it's interesting you said that sounds like a consultant because in this article they're refuting that, oh, here we go. In the next section, lemme start right away. It says, is an FDSE similar to a consultant? No, not really. I think one of the things that differentiates us from consultants is how technically creative we can be while also delivering solutions quickly in the hands. Hang on, hang on. Wait, wait. I almost jumped in there. Did you see the shot at consultants there in the hands of an FDSE Palantir's products, Foundry and Gotham. Why is your product named Gotham like really Batman? The place where all the evil people live that Batman beats up. That's what you need, Gotham City does., Does Batman live in Gotham City or does he live in Gotham Suburbs? Because I need to know these things like this. Nevermind. I know, I know. But he has quick transportation. I do know that. He does. He does. Our ready built playgrounds that empower us to be flexible and efficient in how we solve problems. Unlike consultants, we can pull most of the pieces together out of the box, meaning we don't need to reinvent the wheel for each customer and spend years of creating a patchwork solution. This sounds like someone who's never been a consultant. Exactly. Instead, we can focus on composing the right architecture of features to supercharge users this way, I'm creating software that makes my customers more uniquely able to do their jobs. Oh boy. Oh boy. Oh boy there's a lot wrong with this. First of all, it doesn't sound like he's creating software. He's configuring software. Yeah, he's setting up software and second of all I don't know any consultants that. Don't use outta the box stuff. Like very few consultants are out there like truly creating custom stuff. And also like you can tell this article was written in 2020 'cause like consultants now are just using chat gpt to, yeah, let's just give them the benefit of the doubt that this was pre AI or chat GPT. But you know, there are a couple of jabs in here on consultants saying that they're not technical or necessarily have that prowess to put these things together. I was gonna say only just call it or what it is only 'cause I worked in consulting for a short time. Can I say that?, Watch out with this kind of attitude. There's consultants that are out there that are gonna eat your lunch, man yeah. Careful. Yep. Agreed. Absolutely., I completely disagree that consultant, this is not a consultant role. You are consulting with the customer. You, yourself said you're embedded with them. Right? So what are you doing working in a vacuum,? Right. You're consulting now , the technical aspect of it.. Consultants do have technical jobs, especially these ones that are putting together bits and pieces and synthesizing a tailor made or bespoke solution to solve the customer's unique problems, I used to do that for years when I was working in the publishing sector, right? There was a core piece of software that didn't do anything much if you just took it out of the box, and implemented it because every customer had a unique circumstance with their backend systems, the ERPs, the financial systems. So you had to do this work, and if you're not technical, you couldn't do it even if it meant doing things like. Writing scripts to make all of this work right. Not necessarily compile code or anything like that, they would have to be updated all the time. No, this is writing scripts and training them in how you're doing it so they can be self-sustaining going forward. Yeah. That's interesting that he left the, the training piece. I, I wonder if we're gonna hit that. He may have it. The training piece I don't recall it though, so we'll see. Because I think that yeah, I, we gotta write that one down for a note to look back later. I'm interested if when he leaves or his assignment. Is over I wonder if like the company's just out on its own. they no longer can change the Palantir products. Probably, I mean these guys will probably wave the change request flag, right? Yeah. And say buy more hours. I wonder I, I guess the business model is what I'm wondering about. I wonder if, i'm wondering how close this is to the SAP business model where basically like, they're not really they don't really encourage you to learn the table structure and change it yourself and stuff like that. They really want you to call them and then they come in and do it. It's the same as if you ever work on a IBM series. I like, they don't really want you adding RAM to the box. They don't really want you, like they want you to call them , A guy will come out with a suitcase with the RAM and put it in like this is exactly, the tactic, I guess to have the customer sign up for a maintenance contract. Right?. So then makes sense. They'll say, well, call us. We'll take care of it. It's covered under your maintenance, or only this much is covered. or you go to a platinum maintenance tier. Then we cover a bit more that doesn't shock me that they're huge with the government because that seems like a sales pitch that would go over well for the government is like, you absorb no risk. Right. You know, you call us when there's a problem, we'll send the man with the suitcase out and they'll fix everything. It's all on our dime. You know just like the old IBM consultants that would come out and all the rest is on them, you don't pay anything. The SLA says we'll be out there in a certain number of hours or whatever depending on the, the support tier. Yeah I guess the customer can rest assure that the job will be done in a timely manner and it'll be done Right. Because the experts are doing it right but meanwhile, the experts like, and then now we change the screen over to the experts. And the experts are like a dude going like, alter table, insert column. Sorry, I don't really have like any hangup with SAP or anything. It's just, well I remember clearly being at a work center that like heavily used SAP and it was just like, it was this big black box. Yeah. It was a big black box and everyone treated it like, ooh, like the, we gotta have, gotta get the SAP teams time. And it's, it was a big thing. And when I actually sat down, 'cause , that part of my career was like I, I was like just coming online with like agile ways of working. I was just kind of like discovering what path I went oh, what do Scrum Masters do and what does this do? And I'm like, what does, what is the actual discipline, agile coaching? How can that add value? And stuff like that. I was like just learning about that kind of stuff. So I was going, I was like. Going and sitting with the SAP people when they were doing their work, just like sitting over the shoulder in the cube Hey, don't you have something to do? I'm like, no, not really, my job is to make sure that this is done right. And then go back and tell my boss or project manager or whatever that like, I got the thing done even if getting the thing done was just sitting behind the person doing the work, making sure that it was done right. Because like, I got a whole team that's blocked from testing this thing until you get the new table structure done. So , no, I have nothing else to do. It was like one of those work centers, with stage gates and milestones and check boxes and I, I remember sitting behind the SAP person and they were doing basic sequel insert column Sure. Into a table. I'm like, this is SAP. And then he was like, yeah, but you gotta know what column. And he had a big ERD diagram in this cube. I'm like. Just share that with us. This is not, I mean, yes, you need to coordinate who's changing tables or whatever, but anybody can do this work. This is easy. This is just sequel you know. Oh, Brad, it's more complicated than that. I understand. You got a million modules. You gotta know what Right. What the right module is to buy.'cause there's a lot of money involved the CRM module does this, the natural gas module does this, whatever. I understand. But it like the actual technology. But under, under hood, it's basic T SQL statements, man. Sure. But this is different. This is, this is the, boy, the camera's rebelling on me when he is like, you're doing, you're being too sassy. All right. Fine, fine. Let's move on. Why did you choose this role versus a traditional software engineer? Role? Software engineer. SWEeee. He says, I chose to be a forward deployed software engineer because of the rapid cycle between creating solutions and seeing them in action. At this point, I don't know if this is anything other than like corporate propaganda that we're reading at this point. Is there anything in here that's not propaganda? The instant feedback of iterating hand? Actually, here, let me change some words in here, om, and let me see if it, sure. Let me see if it strikes you differently. Okay. Why did you choose to be a scrum master? I chose to be a scrum master because of the rapid cycle between creating solutions and seeing them in action. The instant feedback of iterating hand in hand with a customer means you can create something very impactful in a short amount of time. Wow, I'm sold. That works, doesn't it? Yeah. I'll, I'll take two to go. absolutely. But when we, again, like this, is this the funny thing about I did it in the episode with Ed, the extreme ownership. I'm doing it again, maybe at this point. What I'm, I guess I'm signaling to you, we need to have an episode completely on like, hey, if Agile's over big a Agile is over, like there's a path forward. let's talk about a career counseling episode. Yes. Of like, let's talk about some path forward. Okay. Business, leadership, entrepreneur, solopreneur, a program manager. A lot of people are jumping and ship to product. A lot of the podcasters in the space are jumping to product, right? Like there's a path forward. I just took his language out with whatever they're trying to propagandize and change it, and it totally fit. So I'm just saying like, this stuff is, it's in the zeitgeist. Mm-hmm. It's not going away. Sure. But companies are seeing it and it's like, oh, let me grab that language and add it to my vernacular. He says, I also like a unique mix of autonomy and unpredictability in the role I am given. Oh, oh boy. If you like that, you work at any bank, I've given the opportunity to work on projects that interest me. Those projects always throw unique challenges my way. I'm constantly learning and adapting, for instance, despite having no prior exposure to the cyberspace, upon joining Palantir, I was immediately thrust into a large cyber project. Oh. That has nothing, not, not like consulting in any way, shape, or form. Not at all. I had no experience in this, but they billed top dollar and threw me into this project to get up to speed, I needed to learn the ins and outs of foundries cyber offering and discover the particular technical challenges facing the customer all while gaining general cyber expertise. Talk about drinking from the fire hose, exclamation point. This is corporate propaganda. I didn't realize when I started reading this, but yeah, I guess I should have. Listen, this is no different than a software engineer who's been tasked to work on a cyber project without any prior experience. They'll be drinking from a fire hose too. This is no different. You're still learning fast on the job. I mean, how, how is this unique? I think it is different than being a software engineer. Again, another episode in the making right here which sort of lines up with vibe coding and sort of also lines up with ai. Oh, right, right. It's different than being a software engineer because, you don't get to be like Captain Kirk flying on a Starship Enterprise coming in like telling a civilization you should be good to each other and not be a planet of mob series or whatever and then flying off and then never coming back and being like, Hey, what's, what's going on? How is this, how are you guys doing? Software engineering, when you're like completely greenfield, you do whatever, blue ocean, whatever you wanna call it, where like you come in, you start with a blank slate, you're flying, you're programming new stuff, new fields. Oh totally. I got this. That's a lot different than I got 500 API endpoints. Anybody could be using any of them at any moment. My database has ballooned to 90 tables, right? There's no one person that knows all of them.'cause they were added over the course of wherever. Like that's, that's a lot different software engineering than this. I completely agree with you. I mean, the only side of, I would say that's kind of on this FDA, whatever it's called for FDSE you are doing all this without prior expertise. You're learning on the job in front of the customer, so it might carry a risk there Of losing your credibility. Right. You're supposed to be any consultant, even though they say no any consultant. Yeah, absolutely. But you know, this is that role, right? You're forward deployed with a customer you're embedded with, and now there's a risk, I believe that where you're learning stuff, you're looking stuff up, right? Yeah. and if it's in front of a customer, you might run that risk , I mean the nice thing about consulting, usually your consulting houses, , they have some sort of Managerial structure. there are people you can go back to either senior consultants or other people In the firm that you can reach out to. And, there's help there. That's the nice thing about being a consultancy which is exactly what he says next. Oh. Oh, is it? Okay. Is it this to get up to speed, I need to learn the ins and outs. Okay. Next paragraph. He says, he says, to meet the challenge, I leverage mentors and members of my team, spent a lot of time talking to customers who know the subject matter best and did some independent exploration. Now, although I'm not working on cyber anymore, I still frequently contribute to cyber initiatives across the company because of my newfound experience and interests. See, , I like what I'm interested in when I'm reading this is all the in between the cracks kind., Yeah, yeah. Kind of stuff is like, how often do you get pulled off of your customer to do something else, to go fight a fire on another customer and then like, I wanna hear some stories about that. I'm more interested about the consultancy, the management of the internal consultancy of Palantir, which again, I gotta think under their org structure is just like operations or professional services or some kind I know like those are not Vogue anymore, , that's the way all companies did their software in the first 10 years of my career. It was like the COO ran all of operations, which, in which, which involved all of professional services. Sales probably was a equal pillar, but sales and professional services. There probably was some kind of contention between the sales engineers and the . Operations Engineers. Engineers, yeah. The support engineers, whatever you wanna call 'em. Yep. Yeah, I agree. It was exactly that structure. Back in the day you had under operations, customer support, but smaller companies, just the ones I was a part of as a person who went out with salespeople doing exactly what's described here in this article. I took calls in the morning, like I'd get to work early in the morning about seven, put the coffee on, and then sure enough the phone would ring because one of our customers had us on speed dial just to talk about stuff. Yeah so not necessarily you know, talk about issues they're having or anything. Just thought, Hey, I have this report I was thinking about jazzing it up. Any, any suggestions, that kind of stuff. My point is, you are not done when you leave this role, you don't really leave this role mm-hmm. In a smaller company.'cause you don't have that handoff to a customer support department. Yeah. You're always the conduit with that customer and you're moved on to another customer. So to your point, sometimes customers will call you and say to to, even if they call the, the support hotline, they'll say, Hey can I talk to Owen? Because he knows our system, right? So we circumvent all of this explanation about what they're doing, et cetera. So it's bigger overhead on this person. It'd be interesting if we want to take customer service and support. Just what we're talking about now, offline to another podcast. I got a couple of people in mind that I could reach out to. Sure. That would be good for that because, this article we're reading about the forward deployed, sorry, I forgot what it's called now. Forward deployed software engineer. Forward deployed software engineer. Right forward deployed software engineer. They're not really software engineers. They're engineers. I'll give 'em that, right they're customer support engineers sales engineers but I mean like software engineer, like I think about a software engineer, of course software development. I'm not convinced yet. I could be convinced that they're definitely deeply, deeply technical. And maybe a lot of them want to move into a software developer, full-time engineer role eventually. But what I'm reading in his corporate propaganda, it leads me to believe that I haven't, he hasn't said anything about software engineering yet The story you just told, where the customer calls. Yeah, maybe they're a problem child, maybe they got issues or whatever they call you and then you scramble your team, get the team together, do whatever. There's nothing that he just outlined other than like being the single point of contact for people to like, walk up to their cube and grab 'em. I was at a work center one of my previous work centers. We had a team of engineers and they tried to make sure that the senior engineers had divvied up the customers where a particular customer always got the same senior engineer, so the people that picked up the phone and tried to solve the customer's problems. Like this equivalent, but in customer support not parked at your site forever the people that picked up the phone would try to solve the problems. They might be different people, they might not be the same person all the time, but if they couldn't figure the problem out quickly, they would escalate to a senior engineer. And the senior engineer for that customer that called would always be the same person so it's, it's like what he's talking about in his position is I, I'm trying to figure out if this model is any different from a model that I've seen in my previous experience, and I have yet to see anything in this article other than I ship the person off and I send 'em to work for that customer exclusively, which is it to me seems just to be a matter of financial. I financially can afford that as a company. Again, he's not, this is like, this is corporate propaganda, so I don't know how deep he's gonna get into that kinda stuff. It's like, that's the stuff I would like to know. From my perspective like from my experience in other companies, I have seen, okay, we got a big customer. I wanna make sure that they always have this person who initially set them up. And every time they call, they're gonna get this person. Like maybe they don't get the person initially. But it always rolls back up to this person.'cause they know that person. Everybody knows that person at the company. That's exactly how it was in my experience when I was doing this stuff i'd always be alerted, Hey this is usually customer support, right? They'll answer the call after I moved on to a different customer, right? Sometime later they would answer the call and then they would tap me on the shoulder, right? Yeah. We were in the office, so they'd say, have so and so on the phone. Would you like to? Right. Can I transfer to you? Right. I would say you need if, if I'm an executive at that company, I want some kind of system that alerts you that says like, Hey, Om your customer called in to customer support today. Brian and customer support has him on the phone right now. Yep. Maybe you wanna pop into customer support or mean whatever for a remote. Maybe you want to dial in and, and just like pop in and be like, Hey guys, what's going on? Everything good? I would want to proactively alert you that we're talking to your customer, but again from my experience , this seems like a lot of other models I've seen. Yeah. Just not called this specific forward deployed software engineering I agree with that it goes , far enough in history for me where the executives at my company would occasionally, not always, but occasionally say, this customer is important. We need this really good take, good care of 'em strategic. So yeah. So give them your SkyTel pager number. That's how back it goes skyTel pagers and they would call, and I would know, I would give one customer a code. When you page me, page me with 9, 9, 9, then I know it's an emergency. Email me or page me with ones something like that and you could do that different numbering things for different customers, but yeah, I mean, every customer wants to feel like they're talking to the one person they know, who knows their environment and their, their configuration all right. Let's try to skim as much as we can. He says what's a typical day in life for you? He says, I work remotely. I'm working on a project for one of our DOD customers. Where I'm creating new functionality on top of our Gotham platform. That's right. Our Gotham platform. Typically a chunk of my day is spent designing, writing and testing workflows. Oh. So similar to my gateway product I always talking about. That's exactly right. So he is not Desi, he's not writing or developing new code as a software engineer would. Right? Another portion is spent configuring Gotham to unlock new functionality within the platform. This could involve configuring new data models or working on stability improvements and upgrades., I also reserve some time each day for comms, emails, meetings, and standups overhead. It's called overhead. I generally try to limit the time I spent in meetings by asking myself, does this discussion have to be a meeting and do I have to be there? Well, this should have been an email I won't even, I like that's, yeah. Most people at the company take a similar approach and at leads a situation where every meeting I attend ends up being a. Ends up being a productive use of my time. The remainder of my day is spent on a variety of tests, learning about other deployments, meeting new coworkers, or working on miscellaneous shared projects. That's interesting. Meeting new coworkers. Does he meet the new coworkers by email? Anyway, sorry that, that was me attacking him for no reason. He's saying daily video conference standups often end up in yoga What are some of the technical challenges you encounter? Every FDSE, by the way, I still have yet to reach any of the se problems he's talking about tackles technical challenges on a day-to-day basis. Here are some examples of technical problems I've worked through during my time at Palantir. All right, here we go. He gives some bullet points. How do I build scale and maintain a terabyte scale data pipeline feeding a mission critical operation workflow. I wonder how old this article is. Okay. It's 2020. Like terabyte scale data pipelines are common now , my intent was not to be hostile with this article, but the style of writing is making me hostile. It's giving me hives, the style of writing. Any flow of data on a long enough timeline is a terabyte scale pipeline. Just want to point that out., What does that mean? A mission critical operational flow. He's talking about scaling things up, is what I get out of this. I think he's talking about the amount of data that comes into the pipeline. There are very few data pipelines I've ever worked with that don't get up to the terabyte level. Yeah, exactly so, okay. How do I configure our platform to support specific data and workflow access controls for our customers based on unique regulatory and compliance requirements? Okay. Data and workflow access controls means if a US person's data comes through the pipeline, you're not allowed to have that in there so you need to be able to filter us persons out of this data pipeline when we're analyzing the Middle East yeah so he, what he's doing here, he is configuring specific data and workflow access controls. This is like, it's just, it's rules on a data pipeline. Like this is not, I would expect him to probably even be able to farm this out to a junior person. Seriously. I don't know the economics of Palantir, so I dunno if they're they send one engineer to this site of like 500 people, and say like, look how much we're supporting you. We, we have a full-time resource. A resource, yeah. Full-time resource. I'm like nails on a chalkboard. I'm trying to, I'm trying to give om the heebie-jeebies over here. I'm getting that. It's this language, with the barely filter over the top of it. He says does my solution encourage self-sufficient collaboration and discovery within the platform, unlocking additional value for the client? Is my solution flexible? Will it be resilient to modified access control requirements in the future? Okay. That was a lot of words. I don't know if any of them meant anything. How do I design, build, test, deploy, and maintain a unique workflow to allow a particular, again, this goes back to the workflow product I was talking about. it seems very similar. That's all he's doing is. Putting together workflow. This is software configuration. This is not, I mean , this is like a, I would say like get a good start in software development as like a tester or like a help desk or something like that. And then transition over to this do this for a while to do like highly technical work very logical, highly technical work. And then do this for a while until an opening opens up on one of the software development teams. Then you move over to do real software development work where you're actually working in code. Yeah. It seems like a good career path. Yeah, absolutely. I think it makes sense for somebody to, if they're coming into the field, . To follow that path he says he builds this workflow for non-technical customers to visualize and interact with high noise data. How can I generalize this feature to fold into the base platform so that other fdsc and clients can benefit from my work? So he, he's configuring flows of data, a workflow. For the data through the application. Okay how do I investigate a production software outage? Identify root cause of the issue to deploy a fix and monitor the stack for stability while coordinating communication between product teams, our deployment team and the customer. You put in trouble. That's basically customer support work. Yes. Customer support work yeah, yeah. Okay but he's not a sales engineer. No, he's an FDSE. What is the most challenging aspect of your role? Directing. Directing focus is challenging at times. Did he just say directing focus? I did given the ever-changing landscape of our products, capabilities and our clients' needs, we are blessed with a nearly infinite number of problems to be solved. I need to consistently identify the most valuable thing to be working on, regardless of expertise or comfort level with the subject matter, execute against it. Everything's on fire all the time, is what it sounds like. Yeah, exactly. But I mean, this is really, I mean, everyone does this, right? Prioritize what you're working on he likes the variety of the role. Okay, good. I'm, I'm amazed this got left in the corporate propaganda. Like Yeah. You're, you're so busy that the, like the thing that you find most challenging is that focused, everything's changing all the time. Like that the software is changing all the time. The customers for nerd changing all the time the things you have access to is changing all knowing, knowing enterprise software like, like Gotham probably is like the software and the configuration setting settings are probably changing under your feet. Like the sand is probably shifting under your feet. All the time and you probably don't get a lot of notice about it 'cause of the size of Palantir. So that could be exciting. I get it. The regulatory changes are there too. I also don't like the politics shifting under your feet as well. It's probably happening in this company the size, right? Anyway, he's gonna wrap things up, he says, to wrap things up, what advice do you have for future squeeze from a technical perspective? My advice is to learn to work with systems architectures and code bases you are not familiar with. Really, that's revolutionary right there. Revolutionary. He joined with with hard way background. He had never worked on common software tools like Spark or microservice architectures. Really? He never worked on microservices. Wow. More generally, find a mentor and invest in a relationship with them. Having someone in your corner who you can turn to for guidance and ask for help and navigating career is invaluable. This sounds like someone who works as a consultancy, I have to say. In a consultancy. You do need someone in your corner. You need someone to go back to. And if you don't have that person in the consultancy, you're not gonna last in that consultancy for very long This was interesting. I really wanted to know more about this model 'cause they've been blasting this model out. I watched a podcast recently where they were talking about this model and on that particular podcast. I can't remember what it was they were attributing a lot of success to this and portraying this role, the forward deployed software engineer it was some kind of like monumental, like breakthrough in thinking. And I'm just, I was listening to it going this sounds like what most smaller software firms do they have a dedicated engineer to a big customer. They're willing to like whatever revenue it takes, like it's strategic, so like a margin or revenue or whatever, like doesn't count. Right., Making that customer happy is the most important thing. This role of having people embedded with customers is nothing new. This goes back a long, long way. Right? Yeah. Yeah so, I don't know why this is suddenly become vogue as a role. It's just, it's just another dressed up sales engineer role. Really, at least to me. It's not a sales engineer. He says clearly in the article, it's not a sales engineer anyway. Okay. We believe them! All right, if you enjoyed this podcast, don't forget to like and subscribe. Remember every like. Counts every subscription counts. A comment on, on LinkedIn when I post the podcast, that helps too for our engagement. And thank you everyone for listening. Awesome. This is great. Thank you all. sorry, I didn't read the. The comments here. I think all the people who have trouble understanding the gist of what Palantir does, should read this blog post. It's excellent. Can I put my thoughts in here without creating an account? Oh. Oh, no. I have to create an account. You have to create an account. It's making me sign up for a medium account. All right. Here we go. We created an account on Medium for the Arguing Agile podcast. So now we get the comment. Here we go. Interesting read. We were so happy to create a podcast you know what, I'm gonna put a dash in here just so people think that this was written by chat. GPT. Here we go. Oh, M dash. You need an M dash. Oh, is it, is that, was it M dash two dashes like this? No, no. It's, it's a, it's a single dash. It's a special character. You can do it in Word in ation. Oh, I can't, I, sorry. I'm, I'm typing with the keyboard on a laptop, so that's s not gonna work for me however, we're chuckling, chucking, chucking, chuckling at the, we, we, we are not consultants. That's all right. Spell check's. Got me disclaimer followed by a description. Of exactly what consultants do, exactly what consultants do betting with clients, solving their specific, specific problems. Problems, and dealing with customer engagement, that's implementation 1 0 1. Honestly, I probably could stop there. That's in, that's like, that's, that's enough heat right there. The position seems light. Sorry, I spell light. LITE. Sorry. I That's how it is okay. Alright light. Sometimes on the podcast, om is like, that's, that's the pro, that's the queen's language. That's the way it's works. And I'm like, oh. Oh no. This position seems light on actual SSWE work, like coding, architectural design and building existing systems. Not that there is anything wrong with that anything wrong with being a specialized consultant? It's valuable work. And we've all been there. This is cool. There you go. Respond.