Latest / Pre-Sales Pathways / Decide if FDE is right for you | Rosemary Momoh, Lorikeet

Transcript

Decide if FDE is right for you | Rosemary Momoh, Lorikeet · Pre-Sales Pathways

• Chris: FDE is the hottest role in tech right now. What does the role look like at Lorikeet Keats specifically? Rosemary Momoh: So I run discovery, scoping, demos, after signature, I am hands-on building agents, building integrations, then taking it live. Chris: It can be quite difficult to draw the line with the customer, at this point, I need to step away. Rosemary Momoh: I think this is where experience definitely comes into play. There's pain, there's impact, there's urgency, there's strategy, and you sort of need to be thinking consistently across those buckets. Chris: Do you see the forward deployed engineer motion replacing solutions engineering? Rosemary Momoh: I don't think all SEs are going to become FDEs. Fundamentally though, a lot of AEs are doing more hands-on demos. As an SE, you need to spend a lot more time in understanding and building. Chris: For SEs who are thinking about making a move similar to the one you have, what's a piece of advice you would have for them? Rosemary Momoh: Make sure you understand what the role actually is at the companies. The stage of the company definitely determines what ends up being the actual day-to-day of the role. Chris: Hi Rosemary, good to see you. Thanks for joining us today. Rosemary Momoh: Hello Chris. Glad to be here. Chris: It will be no secret to you, FDE is the hottest role in tech right now. So I'm sure you get a lot of people asking about it, a lot of interest in it. You will be our inaugural episode on the topic. So really, really excited to kick things off. yeah, the role, mean, the title can mean so many different things at so many different companies, right? I'm sure you've experienced that. So maybe a helpful starting point for the audience would be you just giving us a bit of a sense of What does the role look like at Lorikeet Keats specifically? Rosemary Momoh: Yeah, I think that's definitely the perspective I can provide. the FDE Ruler Laura K is blessed to be hands-on in many things. so we are both the SC and implementation. And customer success all in one, definitely with multiple partners in that lifecycle. So I run discovery, scoping, demos, in line with in partnership with my A's who are very capable. I think we can definitely dive deeper into like some differences between being an SE prior at other companies and that Laura K in that FDE role. after signature, I am hands-on building agents, building integrations, into customer systems, and then taking it live. in that, taking it live after that. LoriKate also has what we call a forward-deployed product manager role that is essentially my customer success counterpart. So they own the account, take things end-to-end while I'm there for you know technical help, escalations, so and so. at LoriKate, we started at product. now we're actually under go-to-market. I will say that. The FD rule at Lower Keith is also very hands-on in the product. So regardless of whether the reporting lines have changed, product influence is a big role. My CEO beats evals, evals, evals. So he expects us to, if you do something once, how can you ensure that you're not doing this again in the pr a second time, or how can you ensure you can do it in a much faster way? So I am blessed to be, I think the FD rule is blessed to be, if you want to learn everything about building agents, taking a customer from end to end, starting discovery and knowing what it looks like on the other side, that's essentially what that rule alaric is. Chris: Yeah, so full customer lifecycle, you're responsible for the technical aspects. You've got the account executive working with you and then you've got the other for deployed product manager role that we can come onto that sort of evolved a bit on the post sales side of things. There's a lot going on there. What would a typical sort of sales cycle look like? And you know, there's day to day activities like in pre sales would you mentioned preparing for demos, but would like customers typically want to pilot the product, would you be involved in those sorts of activities as well? Rosemary Momoh: Yeah, that's a good question. I liked it. I think it's very interesting how it's been run at Laurie Keats. Obviously, you know, Chris, most times previously you are brought in either after the A tells you, Hey, I've done first discovery or, you know, here I've had a conversation, here you go and Here's what's expected. I think a lot of the A's allure kit are very pretty tech savvy. I tend to come in probably not the first call, maybe not the second one. I'll say that's a process that's always in motion and continuously being like either improved or we're trying to figure out is this the best way to run it? but most times Customer has already seen a demo before I come into the conversation. They've already gotten a feel for what Lurykate looks like, and that's because our AEs are pretty good at not to be the CLUD person here running a cloud skill that helps them set up a demo. and we've got many skills that are customized for those use cases. so most times I'm coming in after one or two discovery sessions, or they've definitely had a demo and we have a scoped pilot in place. So we are Precious resource. so I want we want to be involved when we can be best maximized and when there is a clear idea of what should LaureKeep prove out? How do we plug into their systems? And I'd say that's the observation today in comparison to running pilots previously, sometimes they were live integrations, but most days today the customer just wants to see their data, they want to see how things run. They want to be they want lorry keys integrated, even though the scope is is a small one. So I'd say that's when I tend to come in, however long that pilot needs to take. Not however long it needs to take, but you you get my drift. it's a scoped one. It's one that we can say week one is this or month one we can prove X out. Chris: it's interesting because you mentioned a couple of things that parallels there. I've seen a lot of other AI native companies. So the AI is being a bit more tech savvy. And then to your point with the pilots, maybe SEs historically are used to doing a proof of concept where you're kind of proving that the technology could work, or maybe you do put some users in there, but it's often not production systems with production Rosemary Momoh: Yeah. Chris: data. But certainly that was my experience at Glean, right? It's like customers Rosemary Momoh: Fix that. Chris: wanted to see the real data in there. So you're doing effectively a production pilot with the customer. So let's say your AEs have handheld them up to that point, maybe they've done the demo, you're then responsible for running that scoped pilot and then it goes into post sales and you would continue to engage with the customer beyond that stage. Rosemary Momoh: Yeah, exactly. We do have recently we've got like a segmentation model. So some Chris: Mm-hmm. Rosemary Momoh: strategic accounts will get, you know, the FDE, the FDPM from exactly that pile up to post sales. Some other accounts might get it on a weekly basis, or we just do a month check-in after a go live. That is sort of the ideal end state, you know, the strategic ones where they're strategic because of revenue, or they're strategic because of what the scope of the work actually looks like, or some accounts are just more self-serve, so don't necessarily need the FD touch consistently once we've built the implementation and taken them live. It might be a weekly check-in, maybe it's a monthly, or maybe it's actually every quarter. obviously. escalations, bug report bugs should be prioritized and those would typically run through the FDE over to product. But I'd say it's a pretty mixed bag model based on the scope of work, the use cases that the customer is exploring with us and you know how we've segmented those accounts. Chris: Yeah, makes sense. And you mentioned the fact that the FDE org used to sit in the product organization now has moved over to go to market. And you also alluded to that sort of feedback to the product organization. I think to a lot of people, that would be one of the more obvious differences between the FDE role and the SE role as it traditionally was. I certainly always felt that frustration in the SE organization that you could put sort of... feedback in, but you didn't really feel like you had all that much influence over the direction that the product went. I would love to hear any thoughts you can share on that. what does that process look like as you're working with a customer? If you find something, maybe it's like a unique requirement or something that hasn't been done with the platform before. What does that actually look like and what's the tie-in to product? Rosemary Momoh: Yeah, that's a that's a very good question because I think that's that's probably the bulk of my day. The bulk of my day is ideally We've enabled them enough to start testing things out and just that also building more use cases in line with what we already pushed live. most times that is I validate that it's either a bug or an improvement, or it's this is like awesome feedback that would actually unlock, or it's a new system that we need to integrate with, but once we do, would actually add value. I think I tend to go like what needs to be true for this to be live? Like, is this Yeah, I guess what needs to be true between how urgent is this, how big of a problem is it, what the what's the impact on subscriber versus not just the subscriber and not just the customer, but what the what's the impact going to be across our product? if it's a bug, obviously it's a bug. This doesn't work right, this needs to be fixed. If there's a feature request, it's a bit more nuanced as you as you know. at Laurie Keats, I'd say it's it makes bag. Many times it's absolutely okay to just go into the production code and submit PRs. we are very heavy ship, ship, ship first, ship what you can do. if something goes wrong, it can always be rolled back. obviously things are assigned to teams, so today it looks like I file a bug report. sometimes it's here's my attempt at what the fix should look like and here's what I think should be improved. Please take a look and review. Or I feel strongly that this is the fix and I'm going to push it and tests will be run, maybe get a reviewer to take a look. one of the stories I always like to tell. this is actually not me, but we had a session with one of our customers and during the call, they literally went, this UI doesn't look that great in real time, submitted a PR. maybe an hour later, just we essentially went, Hey, do you wanna refresh that? And you know Chris: Amazing. Rosemary Momoh: And it was like it was live because yeah, great use case, great feedback, makes a lot of sense. We can push this through. Lori Keat is also very we've got a lot of RFCs, someone puts in an opinion piece out, people share their thoughts. we do like a bit of back and forth, but I would say that loop of getting things to product is a pretty smooth one. of course, when again gets to How much of this should we actually take life and how much of this should be improved? That's where the conversation can get as comfort related as possible. Everyone has opinions. similarly, I I think trying to figure out how to frame this. Similarly, they'd actually even want more from us. Like we've got what we call like a coach, AI and AI, it's like a coach tr an assistant that our subscribers use. And most times we're working to get that as good as possible. So I'm okay with it replacing me, to be honest. But to get it to do that, it's you use this AI assistant to arrive at this outcome. Why didn't it help you there? Why did it not do what I was able to do? What are the gaps there? What are the gaps in the product that need to be improved for that to do to work better? yeah, hopefully that was helpful. I'd say it's a pretty close, like tight knit loop of course to the extent that we can then go from opinion customer feedback to it being live varies based on the use case. But we are a why not try it first and see what happens versus no, this doesn't make any sense. Even if it's if it's small add-on, it's a small tab, we're very much a feature flag. Let's just turn it on for them and see what adoption looks like and see how that performs and then use that data to inform. Whatever whether it's whether it's going to be rolled out across the board or not. Chris: Yeah, yeah. And so just so I understand correctly, this could be a feature that's specific to an individual customer that you're working with. You would get that into the product. It would sit behind that feature flag and maybe it's just enabled for that initial customer. But then there would be a process to decide, actually could this feature or capability benefit the broader customer base in which case it gets incorporated into the core product. Rosemary Momoh: Exactly. Chris: Yeah, so very different from the SE role in that, don't know many SEs that were actually building and contributing to the core product. So quite Rosemary Momoh: Yeah. Chris: a lot more hands-on, quite different motion. Rosemary Momoh: Definitely very hands on. I almost like honestly, if I take a step back. it has been a lot more heavy in production than what I was used to. I think because it's now my day to day, it's easy to forget just what that gap actually used to be. I've worked at companies of different sizes and you know when I worked at PayPal, there's just a different way of doing things. You've got feedback, you submit a juror ticket, you need to gather evidence across the board, you need other team members to bring even more examples. And then that can go into, I don't know, three months, six months in the roadmap, not because it's not important. but they're just other competing priorities and because there's that, you know, sort of staggered process, it can take a while to make it up there. I think a Laura C were very much a Don't wanna say what's the worst can happen, but if it's asked if it's if it's been asked by once and there's evidence to support it, why not? and then we can learn in real time based on how that works for one or two subscribers. We have got a Slack channel with our subscribers too, so there's usually a bit of here here's something we're test testing out. Do you want to actually be one of the pilot customers, give us your feedback? And there've also been times when, you know, we thought something was going to be a lot more impactful and actually even though the first use case was supposed to be so. it's not that big of a pain or it's impactful but in a different way and that's iterated on constantly. So yeah, I think I didn't I didn't sit with actually I can be very deep in and most times I'm so deep in the product and that feedback loop is quite a tight knit one. Chris: Yeah, interesting. And I'd like to go back to the sort of engagement model, because you mentioned some of the other roles. So the account executive will be, I guess, familiar to people, but as you said, there may be a bit more tech savvy. But you also mentioned the role for deployed product manager. And that's what I wanted to drill into, because I think FDE has got so much attention that it's almost drawn away from some of the other roles. And at Palantir, at least, the four deployed engineers would sort of be joined at the hip. with a deployment strategist who's more like, I guess, a product manager parallel. So could you help us maybe understand that role in a bit more detail within Laura Keat and what your relationship with that role would look like? Because I think that's an interesting role and interesting profile for a lot of people who are currently in an SE role with that sort of skill set. Rosemary Momoh: absolutely agree. I think even when I was coming back to do I join Lori Kate? I did look at the forward deployed product manager role, in part because I've held SE roles, but I've also been a technical account manager. I've done incident management. So I think for me, I'm more of a FDE plus plus plus plus whatever additional role. So I did actually look at that also. and Last time we spoke, Chris, that was a very clear delineation. in Europe actually we're attempting to pilot different versions of either having FDEs wear FDPM hats more from time to time, or have a very clear scope. Those are both being run. Once again, Lori Kate experiments and trying things out. So those are both being run in parallel. But the FDPM role I'd say is if I was to put the clear lines in the sand, which actually I will s isn't always the case at LoriKate is I own the technical side. The FDPM is responsible for the commercial and the strategy. most times that strategy is done together, right? In strong collaboration. But day to day is, here is a list of to-dos or month by month here are the goals. The FDPM is responsible for also a lot more of the relationship management and getting those outcomes live. Our FDE role is responsible for What needs to be true from a technical aspect to get this outcome successful and actually done. If I take a step back, I would say that role steps in at handoff, right? So the FDE is sort of across both sides of the of the coin. At handoff, that role is sort of when the FDPM then comes in. So you can we can say the account manager for that account. in parallel to the SC role, there's definitely a lot more. I'd say the SE, that FDPM role would probably differ across companies. a technical one would possibly be very close to what a classic SE role is if you're quite a technical FDPM. You're thinking of commercials which as an SC you owned, right? You're not just responsible for the technical, but you're tech responsible for the technical. We you need to think in terms of what's the pain for this customer, what how do we highlight this? We've got X num amount of time. What needs to be true for them to really see the value, you can't do that without having a coverage commercial mindset on, right? Even when you think of success, right? During pre-sales, you're already talking about here's what being successful with us looks like, here's what needs to be possible to get that done. That's commercial, that is strategy, and that's also technical. so I think that there are a lot of parallels to the SE to FDE. I would also say that there's actually a lot of parallel to the SE to FDPM role and it's one that depending on what floats your boat or where you want to go deeper or go further in should actually also be be considered as an as an SE. Chris: Yeah, definitely. Yeah. So anyone who's listening, if you're looking just at FD roles, make sure to check out the deployment strategist role or the FTPM role or whatever, however that's described within the organization. But yeah, the idea of requirements, gathering, scoping, stakeholder management, a lot of that will be familiar territory to SEs and maybe something that they would be drawn to in a new role. Rosemary Momoh: Yeah, I think recently I've been reacting strongly to the, engineers who can speak to customers. And it's like that's what Chris: Okay. Rosemary Momoh: SEs have been this entire time. So sometimes we don't need to reinvent the wheel, you know. I I know a lot of companies, even Laura Key tend to they seem to weigh the consultant background, but SEs Chris: Yeah. Rosemary Momoh: have always been doing that. That's exactly the hat we've won for for a long time. So I definitely see it as a natural parallel to a natural move. Chris: Yeah, one question I did have there as well in terms of things SEs will be familiar with, I guess one concern SEs will have when they're thinking about working more post sales, whether it's entirely post sales or like doing a blend of the two is historically a lot of SEs would have maybe been on paper at least pre-sales, but would get pulled into things like customer support or whatever it is, some aspects of implementation, It can be quite difficult to draw the line with the customer, with the boundaries of, hey, at this point, I need to step away. right? Because I've got other customers that I need to look after, I've got pre-sale stuff to look after. Is there any sort of advice you would have, you know, or how have you found that transition? Because FDE is so much more post sales, in particular in your role, you've got to balance that pre-sales and post sales. Any advice or thoughts on how people do? draw those boundaries or people who are worried about constantly getting pulled into stuff post sales. Rosemary Momoh: For anyone listening, if you have any tips, please send them my way after I've answered this question. Chris: You Rosemary Momoh: I'd say I think this is where experience definitely comes into play. This is probably the you sort of need experience, you need to be at the company that's supportive, you need to have some level of structure in place. No days the same. I I have very exciting, very exciting days and very busy days. fundamentally I think the company having a decent structure around what is the right engagement model. Lori Key is series A, so I say that as someone even at a company at a very small, very early stage with small number of employees, there still needs to be some level of structures to as an FDE, at this point in time I'm spending 20% of my time in this account. At this point in time I'm spending 80% of the time on this specific to-dos in this account, right? Close to the end of a deal cycle, close to the end of when you want to push, push, push, important, very early on, you need to figure out I I tend to do a and I'm sure it's not going to be new to anyone, right? There's pain, there's impact, there's urgency, there's strategy, and you sort of need to be thinking consistently across those buckets. What's most painful, what's most urgent? That will always like be at the top of the table. But you need be careful Chris: Yep. Rosemary Momoh: to not just jump to reactive when reactive isn't always the best use of your time, right? The fact that you're getting pinged by three pe three people at a company doesn't necessarily mean that that is the most urgent priority. Obviously having good customer experience and knowing how to engage is an interesting delicate balance, right? Communicating, hey, definitely understand this is a priority for you, but it's also important to me, but I need to set the right expectations because I know actually if I take a step back across my portfolio of accounts or across even the to-dos I have to do for you, this more strategic work will actually push things further than this quick quick ask from from you. So I think having the balance of pain, urgency, strategy, impact and knowing early on, and if I if I take a s if take yet another step back, I don't know how many step backs I've taken so far, Chris. but it's always good to have expectations, account plans, scope Chris: Yeah, of course. Rosemary Momoh: of what needs like What's the success look like to you very early on? And I think that starts at pre-sales, right? Making sure that's consistent. If anything is deviating as you're working with the AE, as you're then slowly engaging with the forward deployed PM, because we're going to close these deal. You need to start coming in and understanding, or you're owning all of that. I think that helps to keep you honest, but also helps you make sure your priorities are in the right place because we all agreed and we've agreed for the past three months that this is our this is the priority. Interesting use case that pops up because now everyone's talking about it is great, but you need to be able to then come back to saying, Hey, remember we had these things that were more urgent, more painful, action going to be more impactful. So while this is a cool use case and I don't disagree, how do we and how do you as an FDE ensure that you are able to communicate that and bring that back? And sometimes, right, for some roles the FDPM can own that. I'm want to own that because I know what the work is going to look like and I'm the one that's going to be doing the work. all of this to say a combination of having some level of structure and being at a company where you know that those exist. is very, very important in parallel as an FDE, making sure you have your framework, whatever that is, for being able to prioritize, being able to manage your time. But honestly, time is limited. So are you putting your time towards the most impactful thing? That's what anyone cares about, either the customer level, either at the prospect level, either at the accountant level, in the company, are you spending time on the most impactful and most painful thing? will be the simple question to just underline every day when you look at your list of things to do. Yeah. Chris: Yeah. And I really liked that idea of coming back to what you're working on and the prioritization and categorizing things into those four buckets that you mentioned. And that was something honestly, I struggled with Gleam when we were running pilots with customers. Sometimes you would get these users who were really engaged, which was great, but they would just consume so much of your time. They would really want to like explore a particular use case in detail and build something out. And you had to really question. is that going to be the most effective use of my time for the customer success? And obviously you're across a broader book of business, right? You're still in a commercial role. So it's definitely Rosemary Momoh: Exactly. Chris: a balancing act. Rosemary Momoh: And it's also interesting when you think of even enterprise versus smaller businesses. You've got actually the enterprises so big, but they have a lot more support. So even though the work is a lot, they're not asking as much from you versus a smaller customer that also has a lot of requirements and use cases, but you're actually doing significantly more. So it's interesting to always see sometimes that the biggest accounts might not always be the most demanding, but you need to also be on top of that. strategy, making sure when someone asks you, hey, what's the impact for the next quarter, what has been done, what needs to be done, you're able to speak commercially because ultimately that's what's important. Chris: Yeah, makes sense. One thing I'd like to touch on is you mentioned some of the roles that you've done in the past and you've come from a solutions engineering background. Having made that move from SE to FDE, which is one a lot of people are going to be thinking about, what sort of helped you and are there any aspects of the SE role that you miss? Rosemary Momoh: Any aspect of the SE roles that I miss? I think that's a good question. what carries over, I think, discovery will always Chris: Yep. Rosemary Momoh: be, you know, if very early on being an engineer, you're working through tickets and you have the scope of here's what's broken, what needs to be fixed. as an FD. You're not thinking that way as or you shouldn't be. You're thinking more from a what did we talk about? What are your business pains? what needs to happen, what does success look like for your team? You know, I think when you think of the SE, you're looking for your champion, you're thinking for how to connect product value to what's most important to the customer. That still should resonate, and I think that's definitely carried over. scoping is actually at the same should be better at scoping out what it takes to get stuff done. Remember you'd get asked, well, how long will it take to get this live? I see you're selling to me now, but well by the time we hand this up to a partner, by the time we try to implement it, is what you're saying actually true? you even get better at being able to scope now. And I think I'd say the customer trusts me more because, hey, I'm going to be the other person on the other side. So I'm not lying to you. I have no incentive to lie because I'm still responsible. So I think the pre-sales muscle is probably the same, knowing how to read a room, knowing who is going to be your champion for actually pushing things live, right? You still hit blockers, not necessarily from a sales standpoint as an FDE. It might be blockers from getting their engineering team to push things forward or getting them to make some APIs available. or getting them to just be more hands on, just being able to read the room as to who is going to be my go to person to get this work unblocked. Or actually it's you need someone even more higher up to provide additional resources because the team that's available is not sufficient. I think that's also that also carries over. what is new, definitely ownership. as I said before, you own when you say three weeks, that number's either real or you've not created a time bound for Your capacity as an FDE. So you need to pay attention closely to that and making sure you can see things through. and that might be the new muscle to build as an as an FDE. what I miss, I think I'm trying to find the right word. The word is The wins come faster as a actually depends. It depends. But the but the your definition of a win honestly varies. I think part of why I like the Lurie Keat role is doing both. So the win is coming in, okay, a deal goes through. but an integration is taking pretty long. So like What's the win there? I think as an SE, it's very clear where the starting points are where the end points are. I will say I miss that. as much as the FDE muscle now is thinking quicker, you're just in motion all day. and I am somebody s who also sometimes loves to focus. Like as an SE, I had time to think about a deal from like all the different angles, go as deep as possible into my competitors, learn the industry, set up demo accounts, like as an FDE. In my SE capacity, I'm still doing that, but you sort of have to get creative with how quickly can I get this information? how quickly would I be able to explore all this from a different angle, but also assess my product? On one hand, because you're so deep in, you can immediately speak to the gaps when you pick up someone else's or you're comparing against the competitor. but I will say I do miss that. ability to just focus in for hours and explore, there is just a lot more like dynamicity and it it doesn't switch as cleanly as an as an FDE. another one is if I said this was I was going to do this in four hours, as an SC, nine times out of ten. It's not about the doing it in four hours. Even if I spent six hours, it was probably relation like what's the word? Every hour spent is adds onto the information you're gathering for this deal. and while it might take a while for the deal to close and you don't have control over that, there is a bit of more control over I've put this block on my calendar. And unless an A sends me a message or puts a last minute meet in without prep, right? We all know that. Other than that, like there is a There's more control over I can achieve this today. you can spend four hours debugging and hey, it's still not fixed. Or it's fixed Chris: Yeah. Rosemary Momoh: in a different way. I'll say I definitely missed that ability to just consistently scope out today is going to look like this. And most times I could expect that the day would go that way. Not the case. Yeah. Chris: Yeah, I definitely found that or something related quite jarring when I was involved in doing implementations and pilots alongside the pre-sale stuff is, for me, if I were trying to debug something and it's not really my background, I was quite new to it. I needed a big block of focus time to get into that, one, at least maybe two hours uninterrupted work to really go through the root cause and everything. And I found that quite difficult to balance with the demands of... Hey, we've got a new prospect or a live opportunity and they want a last minute meeting. We've got this new stakeholder. We need to quickly jump on a call. We have to travel, right? You have to go and meet customers and that travel time. so I found balancing those two different ways of working on the other hand, being available, drop of the hat to do pre-sale stuff with heads down, trying to get things fixed and sorted. Like said, it's not always that obvious how long it's going to take to do it. I found that really difficult switching between those two different modes of working. Rosemary Momoh: And depending on the day, well yeah, I I got to do all these things today, it was exciting. Other days it's like, who what exactly did I do today? I have been trying to build this practice though up. If something's taking you longer than an X amount of time, it's okay to just ask someone else, like no dumb questions. If it's taking too long, it's probably not your fault and you shouldn't spend much time trying to, I think when you have that engineer mindset, you just want to fix and I can do it. I can probably come up with this solution I can probably figure it out. But yeah, as you said, you're managing so many other things, you need to also be okay going This is taking thirty minutes, it's not immediately clear what other resources do I need to pull in because those other resources are also available to you. But sometimes you are the resource, so you need to figure it out. Chris: Yeah, yeah. Rosemary Momoh: Yeah, a thousand percent. I I don't I wouldn't say that it's honestly something I've mastered. So I said, I would appreciate just any extra insight, even from you, based on your experience juggling these, but that's what I I'd say I miss. yeah. Chris: Yeah. Yeah. And on that contrasting things to how they used to be in that SE role, as I mentioned, I've heard some common threads here from other conversations in terms of these AI native companies, AAs being a bit more technical, Rosemary Momoh: Mm Chris: whoever's responsible for, you know, owning the technical side of things, maybe being involved in pre-sales and post-sales. And, Rosemary Momoh: Yeah. Chris: you know, do see that direction of travel beings or like... universally true or Do you see the forward deployed engineer motion replacing solutions engineering? and that traditional sort SaaS setup that we're used to or do you think is a bit more nuanced than that will depend on company and stage and that sort of thing. Rosemary Momoh: I I don't know. I think it's a bit more nuanced. I feel like this is what the next couple of years are going to show us. I think specifically these next couple of years are an interesting time for our role. I think it's it depends on the company. I'll I'll leave with that. I'd say it also probably depends on what value the product is provided. today it's not just Okay for us most times because we're in a competitive, Lori Kate provides concierge support concierge end to end for a lot of our customers. That's a space where a lot of companies also operate in. So proving out what's true, what's real? This isn't just about demos, is bread and butter. that said, I think we have been taking a look at is there a different way to also show That this works. That's not always this end-to-end pilots and end-to-end integrations. Do I see more of FDs, the SE role becoming FDs or not? I don't know if I'm controversial. I don't. I think I started my career being more post-sales and moved to pre-sales and back, I guess, doing both. I think the roles call for similar but different. And it's sort of up to you to determine what exactly about being an SE you enjoyed. If it was a technical death, then yes, go on and pursue more of the FDE role. If it was the strategy and the why, I'm not entirely convinced. like I said, take that with a grain of salt that simply moving like all SE rows divergent into an FDE role is going to be what happens. Not to say that FDE roles and I'd say my version is probably a lot of the strategy and the why in line with the how to. but you did more of the why and the strategy as an S E. So I I personally don't think that the SEs are going to just become FDEs. I think the SE role differs even even at our time. It differed on based on the company, even today. some SC roles were a lot more hands on and lot more architecture implementation focused than others. So I think it's going to be nuanced. I go I think there's going to be a lot more variation. Fundamentally though, a lot of AEs are doing more hands-on demos. more detailed demos. We've got AEs that deploy builds today. I think As an SE, to still be as strong in your career, you need to spend a lot more time in understanding and building. I think it just gives you credibility whether or not your role is requires that of you. Today, it definitely gives a lot more credibility. But the strategy and the why and making sure that's consistent, not all FDE roles require that level. Yeah, sorry. Chris: Yeah, I like the point that it's not totally binary, right, that you're either Rosemary Momoh: Yeah. Chris: working the strategy and the why or the how to the reality is there's a balance of both, but you're used to getting quite a lot of that in the SC role. And because you're doing more of the how to in the FDE, inevitably, some of that's going to need to be to be pushed out. Rosemary Momoh: Yeah, and my other controversial take is also depends on how much you care about the best way to get things done. Today there is a I want the outcome, I care about the right way to do the outcome, and that's what's important to me. The nuanced of, you know, should we optimize for X and should we make this the most optimized solution that's for an FDE to figure out as an SE that wasn't necessarily the most important thing to to get a deal done or to to get a win. So I think being outcome focused as an SE will never hurt you in any way. Thinking more in terms of like output and thinking more in terms of what needs to be what's the right way is not necessarily as important as how do we show the most value always. yeah, I I think it's nuanced. That's my that's my take. But I would definitely we'll see how the next couple of of years go. Chris: Yeah, definitely. And I agree. I don't think it's all going in a universal direction. Definitely it's evolving. And like you said, AEs across the board do seem to be getting more technical, but I don't think there's any one direction that all the companies are taking. I'm going to switch things up Rosemary now to a few quickfire questions. And the first one, and for people who haven't seen your LinkedIn, you have a really, really interesting sort of career background and professional history. You started in medicine, you did some time in papers. in incident management, then you've been in SE and now FDE. So many interesting moves there, but is there one that you would call out as the most meaningful move in your career? Rosemary Momoh: at the time it didn't, I wasn't quite sure if it was. but it was probably the quickest in the quickest span of going from deep into problems and thinking ticket by ticket, problem by problem, to What do big systems look like? What what can go wrong and how can things go wrong really bad? or great. so I'd say most meaningful today would actually be that incident management role. I had sort of gone from being hands-on, handling support tickets and like integrations, to then being responsible for Managing incidents in real time, but also running postmortems, but also managing uptime, holding engineers t engineering teams accountable for why did this go wrong, how do we ensure it doesn't go wrong again, and what needs to be done to make sure the platform is more stable, reporting up to leadership at a very young age as to we lost two million from this incident, here's how I'm gonna make sure we don't do that again, but also actually being the person that protected the rest of the team. engineers support, implementation, and all of that. yeah, it was it was definitely I'd say most meaningful. There was a lot of hat switching, which I'm probably leaning on today. And that's probably the muscle that's like reactivated when I get my customers now as an FDE asking for for different things. But I definitely had to Chris: Interesting. Rosemary Momoh: learn prioritizing. I had to learn how to think, not just from one account, but now literally responsible for the entire platform. And that was at Braintree and then reporting into PayPal and also being responsible for Braintree actually taking up a significant amount of that traffic. There was a lot of main page at 2 a.m. of trying to figure out what team owns this. You can only know that when you now start understanding like behind the scenes, what are the systems, how do they connect. Obviously make sure you have a good incident management system and matrix and all of that in place. But there was definitely a an art to you're in a call with 10 engineers and everyone's going deep into the details and you sort of have to be the one that goes, it's been 10 minutes. Chris: Yeah. Rosemary Momoh: Can we just stop the bleeding and then we can all talk about the nuance and figure it out later? And I think that muscle is probably part of what I apply today of it doesn't have to be the best solution for it to work and for it to be the right next step. And then you can spend more time figuring out what perfect looks like. So that was it. I would say that's it. Not to discount any of the other roles I've been in. I've been in fantastic roles. but it was quite early on in my career, and I think that's probably shaped a lot of what my trajectory then looks like. I don't know that I can just go back to being one problem trying to buy find the best solution in that one problem for weeks. I probably Chris: Yeah, yeah. Rosemary Momoh: would always like what's the business impact, what is the value, what's most urgent, but also how do we get creative with getting things to work as opposed to getting things to be amazing. Because Chris: Yeah. Rosemary Momoh: that's what the business actually cares about. Chris: Yeah, incident response was a very popular use case for us at Slack and for people who get frustrated not being able to prove an ROI, there's nothing better than an e-commerce website going down and hemorrhaging millions of dollars. On that Rosemary Momoh: Yeah. Chris: topic of things going wrong, is there a failure that you've had in your career that you've learned from that you would like to share? Rosemary Momoh: mm. Maybe this one is going to be more a bit more meta. but very early on I tried to wear the startup hat. I have then I'm not a startup. So what almost ten years later, I'm sure there's an interesting paradigm to that. very early on I yeah, tried to wear the startup hat. I was hands-on being an engineer and I definitely managed a lot of I tried to manage a lot of things and tried to do a lot of things. I don't know that I failed. but that said, it's I think it's probably significantly shaped my career more than I know. I went through a lot of questioning whether or not I could even be an engineer. I questioned whether or not I was good at my job. I questioned whether or not I was smart enough. I don't know that I did that role amazing. So that would probably be the failure for me. My next role was you know, integration. So there was a bit of there was some shyness around can I really do this engineering job well because I I didn't do it great before. there was probably a combination of burnouts there. There was probably a combination of not having enough support. But I would say there was a lot of immediately thinking I needed to prove myself so early on in my career, not ask for help quicker. not even pushback or saying no quicker. yeah, that role was a bit of a Things happened but I don't know that it was actually a successful one for me. and it probably goes on to for me to question can I be an engineer? Can I even be smart enough? And then coming my way back to now being an engineer and seeing if I can do the engineer startup. There there Chris: at a reasonably early stage start up as well, right? So yeah, clearly didn't put you off. Rosemary Momoh: There's a parallel there. but yeah, I definitely didn't I don't think I aced that role. And I don't remember feeling successful and I don't remember feeling like I could do it. Chris: one question I did have For SEs who are maybe in a position thinking about making a move similar to the one you have, moving from the world of solutions engineering or maybe pre-sales more generally into FTE. what's a piece of advice you would have for them? Rosemary Momoh: So people that are considering the SE move to FD move? I think the first one is pay attention to sort of two things, either what you want to get better at or what you're already good at. and using that to help determine what your next stage is. I think you tend to do better at what you do consistently. And or if you're noticing something that you know, the good old imposter syndrome is always in the room with many people. If you have some imposter syndrome around specific things, that's probably the muscle to try to flex more and to explore more. I think that should influence whether or not you make that move to the FDE role. on account of you, I also think that demand is real, like whatever the design of the role is. You want to go where the demand is and you want to pay attention to where the trends are. So when you go from what do I want to get better at, what am I really good at? What's the demand? and finding that convergence I think should influence that decision to move to an FDE role. So today the demand is very strong and like the FDE move, but the demand is also very strong in so many other roles in the industry. we've explored the deployment strategist role. We've explored account management roles. There is Applied AI with more generalist requirements. There is a go-to-market engineer. So I don't necessarily think that SC to FDE is always the right path. But if the shape of the FDE role is what you want to get better, what you've always been interested in, you know, a lot of SEs are tinker tinkers. You know, you just want to go deep and build more. And hey, here's a product idea I've had, and you build a small demo, you take that to product, you find yourself doing that consistently. I think the FDE. Mm-hmm. should be considered if you've always gone. I don't even know what happens after I sell this deal, or you try your best to follow up, but you're not always across things. What's the reality of the customer I'm selling to? I think it's enough to say I spend time in the product, but it's nothing as real as actually being responsible for when the product is good or when things break. If that's something that you consistently find yourself being curious about, then absolutely moving to the FDE. role is a good one. any other tips for that move? I'd say just Make sure you understand what the role actually is at the companies. The stage of the company definitely determines what ends up being the actual day-to-day of the role. So stress test, speak to as many people as possible, ask as many questions. I think that's actually even more important than just going, I want to be an FDE. What does the FDE role look like at this company? How are they supported? Is there any structure to that model? What is my growth going to look like? And what will compound? Because once again, you get better at what you do consistently and if that's what you want to get better at, you want to make sure you're getting And better at the thing that you actually want to want to get better at. yeah, I think that's what I have. Chris: Yeah, I love it. I'm hearing, have a broad perspective. Yes, consider the FD role, but other roles like deployment strategies, go to market engineer. There's lots of stuff out there. Go where you want to get the growth and make sure you look into what does the role actually look particularly with FD because so many people are using that label now, right? Getting really clear on what does that actually look like at that company and be prepared for it's probably going to be a moving target, at least in in startups, we're still trying to work this out. Final question I had for you, Rosemary is if there... was a single dream job that you had outside of your current role as an FDA, it could be anything, what would it be? Rosemary Momoh: Well I think the people that know me closely, I've probably talked about this. I would be a writer chef in one, on an island, owning like a little speakeasy spot where people can come, play some music, read books, and The menu differs based on how much effort I want to put in and how much time. that would probably be my idea. I'd spend my day riding, spend my evenings, yeah, at what I at the the speakeasy spot I own, trying out different foods and different recipe, but actually just being a place for people to just come connect and be together. Yeah. Chris: Amazing. That sounds idyllic. When you first said chef, it conjured up memories of my first job. was a waiter and I remember we're walking into the kitchen thinking, everyone is so angry. I wouldn't Rosemary Momoh: No. Chris: be able to, I really like cooking, but I could never be a chef. Maybe it's the incident management in you wants to get into the kitchen. Rosemary Momoh: terms though once again I would own it right so I maybe I'd be the play chef and the other people can do the but yeah the Chris: There's not many dishes coming out the kitchen. Amazing. Rosemary Momoh: writer chef owning my my spot where people can come and I can yeah play around with the menu or play around with what today's program looks like is probably my ideal. Yeah wrong. Chris: I love it. Well, I hope to get an invite once it's finally set up. And Rosemary, thanks so much for the conversation. It's been amazing hearing so much about this role that there's so much excitement around, actually getting concrete around what that role looks like and how you've moved into it. So thank you so much for your time. Rosemary Momoh: Of course. Thank you.