The Agile Within

Selling the Vision! A Product-to-Sales Journey with Seth Carpien

Mark Metze Episode 106

What happens when a traditional salesperson collides with Agile principles? 

Seth Carpian, Chief Growth Officer at Tricon InfoTech, takes us on his transformative journey from being the sales executive who promised anything to land a deal to becoming a trusted advisor who understands the realities of software development.

The turning point came when a delivery colleague essentially told Seth to stop overpromising to customers. Rather than getting defensive, Seth embraced the opportunity to learn, spending years understanding lean product journey mapping and Agile principles. This knowledge transformed his approach to sales, allowing him to have more intelligent conversations with CTOs and CIOs that built genuine trust rather than just securing short-term wins.

Seth shares powerful insights from his unique perspective of having worked in both sales and product leadership roles. The conversation tackles the thorny issue of technical debt head-on, with Seth explaining how "bubble gum and popsicle stick" solutions might temporarily satisfy a customer but ultimately breaks in multiple places when touched.

For sales professionals looking to adopt an Agile mindset, Seth references Patrick Lencioni's concept of the "ideal team player" who is hungry, humble, and smart. While hunger and emotional intelligence are common in successful salespeople, humility—the willingness to acknowledge what you don't know—is often the missing ingredient that prevents true Agile adoption.

Whether you're in sales, product development, or leadership, this episode offers crucial insights into creating healthier relationships between business development and delivery teams, ultimately leading to better outcomes for customers and more sustainable success for organizations.

Connect with Seth on LinkedIn:
linkedin.com/in/sethcarpien

Support the show


Follow us on LinkedIn:
https://www.linkedin.com/company/the-agile-within

Speaker 1:

Welcome to the Agile Within. I am your host, Mark Metz. My mission for this podcast is to provide Agile insights into human values and behaviors through genuine connections. My guests and I will share real-life stories from our Agile journeys, triumphs, blunders and everything in between, as well as the lessons that we have learned. So get pumped, get rocking. The Agile Within starts now.

Speaker 1:

Before we dive into today's episode, I'd like to take a moment to thank our sponsor, Impact Agility. Impact Agility specializes in training and coaching through scrumorg and proconbonorg, empowering teams with cutting-edge tools and techniques. Their classes are designed to deliver actionable insights, whether you're a scrum master, agile coach, delivery manager or organizational leader. Whether you're a scrum master, agile coach, delivery manager or organizational leader, At the helm is president and founder Matt Domenici, who has guided over 50 organizations toward professional agility. With his hands-on experience, Matt helps teams and organizations take ownership of their processes and outcomes, unlocking their full potential To explore free learning resources, check out their training schedule or book a free consultation. Visit impactagilityco Once again. That's impactagilityco, Well.

Speaker 1:

Welcome back everybody. This is your host, Mark Metz, at the Agile Within. I hope you're having an absolutely fantastic day today here in the US. Spring weather has sprung in my part of the country. Here in the southeastern part, we had some rain come through, some pretty nasty storms, so wash some of that pollen away. That is very common at this time of year, so everything becomes bright yellow. There's more to follow, I'm sure, but I have a guest today, and that guest is Seth Karpian, who comes from Winston-Salem, North Carolina. I want to say welcome, Seth, Welcome to the Agile Within.

Speaker 2:

Hey, mark, thanks for having me today, excited for our conversation and chat today as our icebreaker question.

Speaker 1:

We always like to ask if I were coming to Winston-Salem for a day and had never been there before, Seth, what's one thing that you would say that I absolutely couldn't miss doing?

Speaker 2:

Based on the fact that we are talking on St Patrick's Day. I think the one thing that a lot of people need to know about Winston-Salem is that downtown we have a bunch of breweries that are actually fantastic to walk around to and visit. When people think of Winston-Salem, they don't think of the downtown, and when I moved here back in 1999 to go to Wake Forest University for business school, there was nothing. Winston-salem has really grown into a business and social city and it allows you to really go down there and visit all the different areas rather than having to drive one place and then drive to another. So go to Winston-Salem, go downtown, park your car, have an afternoon or an evening of it and then take an Uber home.

Speaker 1:

Well, winston-salem is not too far for me. I say not too far, maybe four or five hours I'm guessing something like that from Columbia. So next time we make the trip up I'll definitely have to look you up, seth.

Speaker 2:

Absolutely Happy to show you around. I'll Uber home too.

Speaker 1:

That'd be fun, All right. Well, Seth is a chief growth officer at Tricon Info World Tech and they have a global presence. He is also a father of four, he's an avid sports fan and he is a product mindset enthusiast. We want to talk about Seth's journey as an agile sales leader. We don't talk about the sales side that much, but give us a little introduction into your journey, maybe where you started.

Speaker 2:

Yeah, and I think actually, mark, you and I met years ago when I was working with this company. It was a company based out of Winston-Salem called Small Footprint and it was a custom software development company. I was in a transition point in my career at that time and the, the CEO at the at that time offered me this role as the sales executive at small footprint. I had no idea what custom software development was. I had no idea what a digital product was, what Agile was or anything and anything, and I had to really learn a completely new business. We worked with enterprise and small to mid-sized companies with building out their custom software, but we also would go in and help them learn how to build things the right way. So I always go back to this story and if you've heard me talk before, you may have heard this story. After about six months working at Small Footprint, I'm walking down the hallway of our small office and my delivery colleague on the delivery side I really do believe that if he were bigger than me, he would have grabbed me and thrown me up against the wall and said you need to stop. And I was looking at him and I'm like stop, stop, what? So if you are not in sales I think you know where I'm going on this, especially if you're in product or technology.

Speaker 2:

What salespeople are notorious for is telling a customer that they can have something, whether it's with a budget that they make up, whether it's within a shorter period of time than the team can actually build something, or whether it's something that doesn't even exist.

Speaker 2:

And I spent six months doing that. So when he pulled me aside and said that to me, he said you need to stop. I said fine, teach me. So I spent the next I guess probably six and a half years learning what was necessary to build digital products in the right way understanding the questions that need to be asked, understanding lean product journey mapping, but also to be asked understanding lean product journey mapping, but also and I think that was very important which has changed the way that I do things in my career is really understanding what is agile and what it isn't, and that it is not the same to anybody, which I think was critical to the career path and ultimately made me more successful in sales, because I was able to talk about things in the right way rather than being a used car salesman. That just kind of made things up and I could talk to CIOs and CTOs and chief product officers and stuff like that. So it really changed who I am.

Speaker 1:

I fully sympathize because it's it's a different position than what your typical engineer has to deal with, because you're dealing with customers and customers want a product and customers have money and they want to give money for what they want, right? Sometimes it's, it's very urgent and they're like we will give you this large sum of money if you can give us this Right, and to stop and have a conversation unless you've been there, that's a hard conversation to have. Sometimes you really do have to have a gut check and, let's face it, for sales it's, it's in short term, it's to your advantage, right?

Speaker 2:

Yeah, yes, no, it really is, and it's getting away from that that mentality of the short term versus the long term. I equate the selling what I sold and what my company does today, similar to financial services. So, being a financial advisor, people are working with you because they trust you. You're not selling anything tangible, right? So if you're not selling anything tangible, they have to trust you in order to work with you and invest with you. Much so, when it comes to software development, they have to believe that your company is going to actually deliver on this. So if you can have a much more intelligent conversation with them, you show them that you understand what it takes to actually build something, they're going to trust you and they're most likely going to work with you and your company. The people that I'm talking to are smart. They know that. If I tell them and I'm going to date myself here, mark I think you're, you know you're, you know you, and I can agree to this. Now we're going back probably about 11 years at this point.

Speaker 2:

The big thing at the time was mobile mobile apps, right? And, if you remember, everybody wanted a mobile app. Now, whether or not it actually solved the problem didn't matter. They just wanted something. So if I'm talking to a CIO or a CTO and saying, oh yeah, the team can develop that mobile app in about two weeks and we'll do it for $5,000. They knew that I didn't know what I was talking about. They knew the complexity that it took to actually do things. But if I could have the conversation and say, hold on, hold on a minute, okay, you want a mobile app? Well, talk to me. What problem are you trying to solve? Right, what is the business outcome that you were trying to achieve? Okay, well, this sounds complex. This sounds simple. Well, let me bring in one of my technical team, let me bring in a product person from my team to dig into that a little bit deeper. That enabled me to have smarter conversations, which then had people trust me even more, because I understood what I was talking about. In the end.

Speaker 1:

Yeah, so as I think about that quite frequently, in sales you've got customers and they come to you and they're looking for bids. So they have some number of of clients that they are looking to work with and they want to to get bids from those clients. And you know, I would think if I'm, if I'm a customer and I'm coming to Seth and Seth is really interested in my business and what I want, and I'm comparing that to three other customers and they're just, they're yes, men or yes, women, right, Yep, we can do that.

Speaker 1:

No problem, yep, it'll be there. When we deliver in six months, yep, it'll be there. Who am I really going to trust to be a true partner in this? I feel like, again, I'm coming from the engineering side of the world, but that is the type of person that I want to deal with, not just someone who is going to say, yes, we'll make it happen. You can have all the confidence in the world, you can be incredibly persuasive, but are you really building that trust and talking about short-term versus a long-term play? I would hope that after after that process, then they're going to be a reference for you and customers going to say, hey, I worked with this seth carpe and dude, tell me how that went, what was, what was that process like?

Speaker 2:

yeah, no, you're 100. Right, yeah, and I will tell you now that that was three companies ago and in in current role, I actually connected with and talking to and, you know, doing some business, potentially doing some business with people I knew from back then Because I was honest, then I knew what I was talking about, then I could have those right conversations and those relationships have been maintained throughout time, you know. So it's important, right, there's one of my favorite authors and I'm a big fan of Patrick Lencioni. Right, and Patrick Lencioni, I could talk about all different books and all types of things, but he had this one book called Getting Naked and right, and the idea behind in that book was really about being very honest and open and forthright with people, because it does build this trust, not only with customers but also with your team, and that's a whole other podcast. Right, I really took that to heart and I wasn't trying to get that quick deal Now.

Speaker 2:

Does it take a little bit longer for deals to happen in that way? It does, but ultimately it sets up the company, which should be your ultimate goal, the mission of the company, in order to be successful. I'll never forget a quick story about because this is about Agile, this podcast, right? So there was someone who I had met down in Charleston, south Carolina, who I had several conversations with, and this guy, to kind of give you an idea of what type of person he was, he was an alligator hunter. People would actually get him to go with them when they got the license to hunt a certain number of alligators in South.

Speaker 1:

Carolina.

Speaker 2:

He would go with them. So he was kind of a tough dude, very forthright. I think that gives you an idea. We're sitting down having a beer one day and I made this comment about Agile as a framework and he looked at me and he goes what are you talking about? I go Agile's a framework, right.

Speaker 2:

He goes, no, no, no, agile's a set of principle. There's a methodology, there's a belief around it. But then there are different pieces of Agile. You know, like we were talking about SAFe earlier, we were talking about, you know, scrum, kanban, whatever it is. Those were the frameworks. Before that point, I had been going and talking to CIOs about Agile framework and I always wondered why they were giving me this weird look or why conversations won't continue after that, because I had no idea what I was talking about until somebody set me straight and then I was actually able to have that and eventually it led me to the point where it's like, hey, no, company is not going to be the same thing, because all you're following is a certain set of principles and maybe some guidelines, but it's going to be different. And I think that's the best part about Agile as well.

Speaker 1:

So, seth, I do have to make one admonition to you. I have read the book by Patrick Lincioni that you're talking about Getting Naked. Yes, and I had a physical copy of the book. And I was sitting on the couch reading that book and I could tell by the look on her face something wasn't quite right. I said, honey, something going on. She's like what are you reading? We looked at the book together and I showed her. So yeah, very provocative title for sure.

Speaker 2:

Yeah, I still get looks if I bring it up and no one has ever heard of it. It's always that look like getting naked. Well, hold on, I think this is the wrong conversation. Hold on, I think this is the wrong conversation.

Speaker 1:

So, seth, what do you do when you've got a client and this is a very high profile client, maybe even, let's say, it's one of the biggest clients that your company has dealt with Sure, and they're saying I appreciate this conversation around Agile and the set of principles, that's all well and good, but we need a system. In six months, are you going to deliver it for us? And you know good and well that your system, that what you have, is not what they have, and it's going to take some work to get there. But they're trying to put the pressure on you, putting the spotlight on you a little bit here.

Speaker 2:

But, seth, what do you do in those situations, putting the spotlight on you a little bit here? But, seth, what do you do in those situations? Gosh, what do you do? I mean, you have the hard conversation, right? Or it's not necessarily a conversation, it's more along the lines of okay, well, hold on. What are you trying to achieve, right?

Speaker 2:

And how do you know, in six months, that this is going to be to building products, right, products it's. You know what is the, the POC, what is the MVP? Have those things been designed? Have you validated this thing? How do you know that this is exactly what you need, and why do you need it in six months? That's another question, right? So why do you need it? So you have to ask those questions.

Speaker 2:

Let me back up for a second, though. There are ways to ask the questions. There are. Hey, you know, if you want to be truly agile, we want to iterate and we want to test, we want to fail fast, we want to know what we don't want really, really quickly.

Speaker 2:

But here's the reality. At some point, at some times in some companies, it does not matter, they have to get it done in six months. This is what they want in six months, and if you can't do it, you're not going to be working with them. But you know what? Yep, you need to walk away Because if it is not someplace that you can succeed, it's not going to be worth it in the long run. Anyway it's not. Oh, hey, we're going to get and I speak from experience because in those first six months, hey guys, we got to get in there. We got to build this thing. In three months, we got to get this thing done. Come on, let's do it. Close the deal Done right. Ultimately, you create failure for yourself because you're not setting the expectations and a lot of times you're probably going to end up failing or it's not going to be a sustainable product. So you got to be careful about that. Sometimes you just have to walk away if you're not doing it the right way.

Speaker 1:

And, let's face it, some of these things, these are extenuating circumstances and you have to recognize that, because you may have a situation where you have somebody at the top and they're well-progressed in their career and they have this one final objective before they go off into the sunset, and it's this you want to have this system live in six months. I really don't care. We've done our due diligence, seth. You just need to deliver. Sometimes those are tough and they don't want to engage in those, in those discussions, and you can get a lot of pressure from your company, right, because a lot of money is on the line. Um, but if you're setting yourself up for failure I say this because I'm an old guy, so I lived through the two thousands boom when all these systems were going to supposedly just absolutely die, when everybody was counting for two digits for the year, right right, exactly, yeah, and everybody was like do we want to spend thousands, if not millions of dollars to upgrade our system, or let's just buy a new system that already has the capability built into it.

Speaker 1:

And, like you mentioned, this was customized software. It wasn't centralized SaaS product. This was back in the old client server days yeah, yeah, the office, sometimes until the next morning on multiple occasions trying to get these, get these customers live. And and it wasn't until years later that I had a boss that really brought it into focus for me. And and he asked me, he said do you really think, if you really sit and think about it, are you doing your best work at five o'clock in the morning? What types of mistakes are you going to make when you're doing that? And I had a conversation with somebody else about this and it was like, hey, if you're building a house and you want to custom build house and you're putting pressure on them, you know this is your dream house, right? And you're saying I want it done in six months and you've got contractors working around the clock, what do you think you're going to walk into?

Speaker 2:

Yeah, I mean corners right. People are going to cut corners. They're going to try and figure out a way to get it done. You're going to open it.

Speaker 1:

It's going to fall. You know you're going to go to flush the toilet and toilet falls over. I mean it's. People are like they're going to cut corners because they have to get it done based on time. So anyway, sorry for the long diatribe on that. I agree?

Speaker 2:

No, it's true and it's interesting. So you and I have been talking a lot like from my perspective, about being, you know, a partner with with your customers and going in turn, you know, going in to help them do these things. So after I left small footprint, I actually went. I worked with two companies as a product leader, so I was actually on the inside trying to lead and deliver these things. I was fortunate in my first role as a product leader that I was somewhat isolated, that I could work with the team and we set things up the right way and we were actually delivering very well went from a you know, if the customers were on a scale of one to 10, from happiness, zero being unhappy and 10 being extremely happy, they probably were at a one when I first went in and I would I would argue that they're probably about a seven or an eight, you know, by the time I left. So, having that, I felt really good about going into another role and I was like I can do this. I have changed the way that people are thinking internally, but there are still companies out there that, regardless of what you share with them or what you tell them the right way to do things. They still want it done.

Speaker 2:

I always use this example. You have somebody, a stakeholder, come to product and engineering team and say, listen, I need a blue button. I need a blue button for this customer. Okay, well, let's talk about why do you need that blue button? Because you know what? I have a pink button right here that does exactly the same thing as the blue button. Can we use that? No, no, no, no, no, we need the blue button. Oh, and, by the way, I need it next week. No, no, no, we need the blue button. Oh, and, by the way, I need it next week. Well, because of everything else that we're working on for you, we have a brown button and a, and, you know, a purple button too. Which one of these are we going to get rid of? Well, I need it all, and I still need the pink button or the blue button. Sorry, I'm confusing the buttons, but I think you get the point right.

Speaker 2:

I'm with you. It's this idea even from inside, internally, there are so many struggles and they hope that if they can bring someone in from the outside, that they'll actually start listening. And that's not always the case. So I say to people, if you want to be in product engineering or even if you want to be in sales, really take a very hard look at the organization and are they going to be willing to build things the right way, or are they just going to be chasing that dime you know, for a customer, or you know, or to please the board or you know, the CEO of the company? Those companies are going to struggle, but those that are willing to do things the right way, I think, end up in a much better place when they, when, when they understand the consequences of changing and pivoting and not building things for the right reasons.

Speaker 1:

When you say building things the right way, the engineering mind starts popping up, because one of the things that I see is with engineers, they like to do things the right way. I can say that because I was a former engineer.

Speaker 2:

Right.

Speaker 1:

But there is this negotiation that has to go on. Yes, because there is a business. This isn't a lab project, this isn't a school project. This is a business that has to be run. And sometimes you find yourself in the situation of well, hey, we need this done in a week, a week, we can't do it in a week. Our architecture is not built that way, so it's going to take us six months to transform the architecture the right way. We don't have six months. This won't be marketable in six months. So what do we do?

Speaker 1:

And so this is where I like to use the term technical debt, because I think that word gets thrown around so willy-nilly so many times that it loses us. But this is a situation where I like to use it because we are consciously making a decision to take a shortcut or short-term gain that we have to be able to have time to undo that later and do it the right way. So that's a good compromise to say, hey, well, maybe we can give it to you in two weeks. Is that okay? Perfect, if we go from one to two weeks, I can live with that.

Speaker 1:

Okay, great, if you do that, you've got to give us the next two weeks to be able to not make this a pain next time. Because you know what, if we don't the next time you ask me to do this, it's really going to become a major pain and you're not going to like the estimate that I give you so many times. People are open to that and you know again, engineers, I am one. You know you want to build things the right way and it's like no, I will not do that. I will stake my job and reputation of I will not do that and you shouldn't, but maybe in this case you should. If you can agree that you have to promise I mean sign in blood that you're going to give me time, not in a couple of months or a couple of years, but the next week. You're going to give me time to undo the work that we did.

Speaker 2:

Mark, if you meet a stakeholder that will actually agree to that and sign that in blood, I'd love to work with that person, because I can't tell you and I know you've heard it too how many times okay, we'll just get this done this one time and the next time I'll give you the more time to do it. And it's as though it's this short-term right, short term memory loss. It's just, the conversations are forgotten. I can't tell you. Well, you know, sue Bob, we had this conversation a month ago and you said that if I did this for you, that you were going to give me, you know, more time because I had to hard code the same. This is one thing I've kind of learned. So if I'm not an engineer, so if I'm off base explaining this, you got to keep me. Keep me true to this If I hard code something and then something else has to be built that also needs to be in that system but is affected by that hard code, you have to unravel that.

Speaker 2:

You have to unravel what you have hard coded in order to build the thing that needs to be added to it.

Speaker 2:

Or, I also like the term. This is one of my favorite terms I used to use all the time spaghetti code Right Because you have bubble gum, and you have bubble gum and popsicle sticks right In order to build something that someone needed quickly. So you fix it on one page and then it breaks four other pages Because everything was so intermingled and not built the right way, because you did it just to meet a need right away and I'm going to say eight times out of 10, they're not going to give you the opportunity to unravel it. So that's when I also realized, if I'm in business development and when I was in product leading product, that I had to be honest because knew in the long run it was going to hurt me and I'll be honest, it did it. Did you end up blaming product and development for things not getting done when you tie the hands of product and development together In order to not build it the right?

Speaker 1:

way. That's interesting because that has been a successful approach of mine. You have to be very disciplined and you have to be very determined with that. Which is basically what I would say is if, let's say, if you're working in sprints, right, it's like hey, if you give us, we'll give this to you in this sprint, right, and it's not the best way to do it, but it's going to create some debt and, like any debt, you don't want it to grow over time because at some point you become upside down. So you got to give me the next two sprints to undo what I did, to do it the right way. So it's up to you.

Speaker 1:

However you want to do it, you can wait for three sprints to get it done, or we'll give it to you with a, with a bandaid or bubble gum, like you said, but the next two sprints are going to be off the table and I've been successful in that. But I know that that's just my experience. But when you put it that way and so really you're giving people options People don't like to just be told no, there's no humanly way possible. We're not going to do it. Give somebody, even if they're not the best options, at least you have options, right.

Speaker 2:

Yeah, no, I agree, and I just think it depends on the organization. You're with right. As I said, my first foray into being a product leader, I was able to do those things. I just think the reality is not every company is going to be that way and I think, depending on who you are and what you want to do and where your career is, you need to make sure what the mentality is of that company, of that organization, or that you are going to be working with a leader that will support you in that endeavor, because if you don't have that leadership support, it's going to be an uphill battle for you and that's where you're going to struggle a little bit.

Speaker 1:

You know, that's a really good point, because I could very well see that going on to well, I got painted into a corner, but if I go up to the CEO, the CEO can have that leverage for me and the CEO can undo that agreement that you felt like you were forced to have. So, yes, you have to know who you're working with and know your organization for sure 100%. So, seth, this 30 minutes has gone by so fast and I've got so much more. It's like we could probably stop recording now, and then you and I could have another two-hour conversation about this going forward, because I'm so into this topic. But you are amazing. You are almost a unicorn of a salesperson with an actual agile and product mindset. You would be an absolute dream to work with. What about those listeners out there that haven't built that yet? What advice would you give to team members on how to support their salespeople to get them more into an agile mindset or a product?

Speaker 2:

mindset. Yeah, I mean, listen, it's not easy, I'll tell you right, I think you have to have people that are wanting to continue to learn. You have to have people that are willing to listen. So, actually, let me sum it up. So Patrick Lencioni, back to him, had a book called the Ideal Team Player and in that book he talks about hungry, humble and smart. Hungry, I mean, if you're successful in sales, you have the hunger, right, you're going out there and you're trying to get things done. Smart, you have to have EQ. You have to understand your audience and who's around you and read them right. That's that EQ. But I think the most important piece in order to help business development salespeople understand this space and be able to think differently is they have to be humble. And they have to be humble to know that, hey, maybe they're not doing something the right way, which is what my colleague at Small Footprint taught me. Right, I wasn't thinking the right way and I had to say, okay, I need to learn. So you can bring in people who can help them understand the basics of building technology and why it's complex and why it's difficult. You can do all these things about teaching them what is the long tail, right? You know you want to. If you take a long-term approach to this, you're going to ultimately be successful and you can teach people a lot of things and provide them, show them how they can benefit more from this, but they have to be willing to take it on. I will say, unfortunately, one of the things I've also learned when you're trying to show somebody how you're trying to help them, they don't always see it that way. It's like this your house, right, Listen, you need to put a fire extinguisher in your house on different floors because if a fire happens, you need that fire extinguisher to put it out and save your home. I have found and one of my career coaches, I had this conversation with them we were talking about this and you find that a lot of people don't really react to that. What they do react to is your house is on fire. You better go get a fire extinguisher. This thing's going to burn down, right? So taking that approach sometimes will help people to understand it more.

Speaker 2:

Back to the humble piece. I have a colleague that I worked with in my first foray into product, and this person was working in comms and communications transformation within the technology group. We had conversations about how I had transformed my team from basically may have been waterfall into more. You know thinking with an agile mindset, right product mindset and things of that nature. And so when I was talking, I said you, you can actually do that across your organization. Your communications people, the PR people can all follow the agile principles. You can. You can have roadmaps, you can iterate, you can have two week sprints and in some cases it's, it's.

Speaker 2:

I say all that to you can turn your sales organization into something like that. You can have stand ups on a daily basis to talk about your pipeline. You can have, you know, you have your roadmap, you have your deal pipeline right. All of these things can be taken from the. You know the things that you use, the tools that you use in order to help facilitate the agile principle or the framework that can also help to educate them. But I've been going back to this a lot because I've been talking about product, I've been talking about agile software development, all of these things. There are tools that you can use in order to try and change the way that people think, but it doesn't always work. It's not always going to work and when we understand that and we accept that we can try to push and change as much as possible. But if you need to fix it, sometimes the right people aren't on the bus or you're not in the right situation. So you need to either try to change it, accept it or move on.

Speaker 1:

The tools help us. They're good, but they're not always going to be the solution. So if you don't have the right mindset and the right people, sometimes it's just not a good fit. Yeah, 100%.

Speaker 2:

Determine what your non-negotiables are, and then that will help you determine your career path too.

Speaker 1:

Well, Seth, I've really appreciated this. Thank you so much for coming on to the show. I've appreciated this conversation. Yeah, let's do this again sometime.

Speaker 2:

No, I appreciate it, Mark. Thanks for having me on here and allowing me to just kind of talk and share what's in this mind of mine, which is a little bit scary sometimes.

Speaker 1:

Hey, if our listeners out there want to get in touch with you, what's the best way for them to do that? Seth?

Speaker 2:

Yeah, just find me on LinkedIn. I'm there. Or you can go to the triconinfotechcom I'm on there if you want to reach out to me there. But LinkedIn profile is probably the best way to get in touch with me.

Speaker 1:

All right, great, we'll put a link to your profile in the show notes to make it easy for our listeners. So that's great, seth. Appreciate it so much, buddy.

Speaker 2:

Yeah, thank you, mark. Thanks for having me on, I appreciate it.

Speaker 1:

All right, everybody that brings it in to another episode of the agile within. We'll see you next time. Thanks for joining us for another episode of the agile within. If you haven't already, please join our LinkedIn page to stay in touch. Just search for the agile within and please spread the word with your friends and colleagues Until next time. This has been your host, mark Metz.

People on this episode