
Left to Our Own Devices · 2025-01-22 · 38 min
Key moments - from our scoring
Substance score
39 / 100
Five dimensions, 20 points each
JB Baker brings decades of experience from Seagate Technology, LSI, Intel, and other hardware giants to discuss the current state and future of computational storage. The technology aims to reduce data movement, power consumption, and infrastructure costs by pushing computing closer to storage devices, but faces adoption barriers stemming from the disconnect between who purchases (OEMs, integrators) and who benefits (end users). Scale Flux, the company where Baker leads marketing and product management, was instrumental in establishing computational storage standards through SNIA (Storage Networking Industry Association) six years ago. A major challenge emerged when industry standards bodies began addressing security implications - programming at the device level introduces potential attack vectors, though immutable functions can mitigate risks. Beyond technical challenges, Baker explores product management philosophy rooted in psychology and organizational dynamics. Drawing on experiences ranging from zero-based budgeting constraints at Intel to the resource-flexible startup mentality, he emphasizes starting with customer pain points rather than cool features. His leadership approach, informed by Taekwondo coaching principles (praise-correct-praise), prioritizes building team initiative and ownership over micromanagement. He cautions against hiring from desperation and stresses that understanding customer 'why' before 'what' separates successful innovation from feature creep.
Computational storage moves computing tasks closer to where data lives, reducing data movement between storage devices and CPUs/GPUs. This saves power, reduces costs, and improves infrastructure efficiency, but adoption has been slow because end users see the benefits while OEMs integrating the devices struggle to capture margin gains.
Allowing programs to be loaded or changed on storage devices creates potential attack vectors, similar to loading untrusted applications on a CPU. Early deployments lock functions upfront as immutable to avoid security risks while industry standards bodies work on verification and authentication mechanisms.
Hiring mediocre candidates when under time pressure requires more micromanagement and creates more problems than it solves, deepening the resource crisis. Instead, focus on core attributes like initiative and problem-solving ability, even if domain knowledge is lacking.
This model involves acknowledging what an employee did well, providing specific correction areas, then praising their improvements. It builds confidence and initiative rather than discouraging action through constant criticism, which leads to learned helplessness in psychology.
Large corporations operate under zero-based budgeting and must defend existing product lines, limiting risk-taking and speed of decision-making. Startups can pivot quickly, allocate resources to promising ideas, and avoid legacy constraints, enabling them to outpace incumbents in market capture.
Our reviewer’s read on each dimension, with quotes from the episode.
The computational storage section offers genuine industry-specific insight on buyer-beneficiary misalignment and the chicken-and-egg software problem, but the back half of the episode devolves into generic management platitudes (praise-correct-praise, don't hire from desperation, set goals) and motivational sports analogies that add little for a B2B operator.
you get a disconnect between who buys the product and who realizes the benefits
it's the end user... that is seeing the benefits of lower latency and lower power consumption... But typically those devices are going to be integrated into a server or a storage array. And so you've got an intermediary in there
The computational storage framing is field-specific but the product management section leans heavily on Simon Sinek's 'start with why' without attribution or extension, the Apple anecdote is extremely well-worn, and the leadership and sports-to-business parallels are standard podcast fare with nothing contrarian or first-principles.
start with why instead of starting with what?
you've given me the what? Give me the so what?
JB Baker is a credible VP-level practitioner with hands-on experience at Seagate, LSI, Intel, and now a computational storage startup, and he demonstrably helped create the SNIA standards body - this is genuine operator experience, not a career podcast guest - but the conversation does not draw deeply enough on his most differentiated knowledge to push the score higher.
we were part of kind of the creation of that term and a whole industry standards body through the Storage Networking Industry Association... That was six years ago now
at lsi we were doing a new product class, you're starting from zero, you're not defending territory
The episode names Scale Flux, Seagate, LSI, Intel, and SNIA and references a six-year timeline, but hard metrics, revenue figures, and named case studies are almost entirely absent; the Apple competitive-analysis anecdote deliberately withholds the second company name, and the product examples stay at the level of vague analogy rather than concrete data.
through the Storage Networking Industry Association. That's a mouthful. Snea for short, around computational storage. And how do we put some standards around it... That was six years ago now
we need to shift from 128 to 256 bit encryption. Well, did they really need that specific feature
Questions are broad and multi-part ('what key leadership lessons have you learned and how do they differ between corporate and startup environments?'), the hosts frequently interrupt with extended personal anecdotes that consume guest airtime, there is no meaningful pushback on any claim, and segues are openly telegraphed as devices rather than emerging from the conversation.
what key leadership lessons have you learned and how do they differ between corporate and startup environments?
I was about to say that thing, uh, about initiative, that it also creates ownership because the person who initiates also wants to own the thing. So it's kind of a, uh, double edged sword
Computed from the transcript - who did the talking, and the words that came up most.
We sat down with the Seagate, Intel, and ScaleFlux veteran to discuss innovations in storage technologies, emerging threats, and cybersecurity.
Transcribed and scored by The B2B Podcast Index.
Speaker A: Hi, this is David.
Speaker B: And this is Shlomi.
Speaker A: And you've tuned into Left to Our
Speaker B: Own Devices, the product security podcast. All right, so, uh, today's guest is a seasoned leader in B2B product development and strategic planning with a remarkable career spanning corporate giants and innovative startups in the computer hardware and data storage industries. Currently serving as Vice president of Marketing and Product Management at Scale Flux. His impressive resume includes senior leadership roles at Seagate Technology, lsi, Intel, and, um, more. Renowned for his analytical decision making, strategic foresight and ability to promote innovation. Is also an endurance sport enthusiast. We'll have to talk about that part. Tackling Spartan races and triathlons with the same determination he brings to his professional life. I hope. J.B. baker, welcome.
Speaker C: Thank you. That was quite a flattering intro.
Speaker B: We try. We definitely try, but with you it was quite easy with, uh, such an interesting background. So maybe we can start talking about emerging trends in computational storage in general with you being kind, uh, of a veteran of this industry. So computational storage is a rapidly evolving field, as we know. Can you explain its significance and how it's reshaping the data storage industry? What challenges and opportunities do you foresee as this technology becomes more and more mainstream?
Speaker C: Yeah, sure. I mean, so computational storage, the concept behind that is to move some of the computing tasks closer to where the data lives and why. The benefit there is reducing data movement, which then saves on power, saves on cost, and makes the entire infrastructure more efficient. That's kind of the very high level, simple. What the heck is computational storage in the first place? The deployment of computational storage has certainly been very challenged at Scale Flux. Coming into Scale Flux, we were part of kind of the creation of that term and a whole industry standards body through the Storage Networking Industry Association. That's a mouthful. Snea for short, around computational storage. And how do we put some standards around it for programming things down at the device level and managing security. And that was six years ago now. But at the same time, computational storage kind of got this overweighted with inflated expectations of how much you could program down at the device and how much you could offload things from the core, the central processing unit or CPU or even, you know, now the GPUs. So it kind of got, people got a little bit of bad taste in their mouth for it was complex to use. And part of that, that challenge there was uh, something that actually I've seen, uh, in other industries as well. And I remember case studies from, from business school where you get a disconnect between who buys the product and who realizes the benefits. So, you know, going to a different industry, for example, like or for your home, right. You might look at solar panels. If you buy solar panels for your house, but then you're going to move out in two years, or you're not sure that whether you're going to stay for 10 years to get the ROI out of it, then there's a disincentive for you to buy it, even though you know it's a good choice. Or in a builder industry where there was a much more efficient air conditioner, right, but the builder was paying for the air conditioner. And then if they couldn't raise the price of the house to offset the extra cost of the air conditioner, the buyer, you know, the person who's going to live in the house is going to see the benefits of lower bills. There's that disconnect and it's hard to get adoption. Well, we have that in the. For computational storage as well, where it's the end user, you know, that person who is going to be running their applications out in the data center or for their enterprise that is seeing the benefits of lower latency and lower power consumption and more efficiency. But typically those devices are going to be integrated into a server or a storage array. And so you've got an intermediary in there who's trying to figure out, am I going to get more price and more margin out of this new technology. And then another second challenge that's kind of unique to this is a chicken and egg thing for the software, because as a hardware developer for these computational storage devices, we're providing a platform that enables that efficiency gain. But unless the software has been refactored to take advantage of this emerging hardware, the end user isn't going to see the benefit. And so a lot of software vendors want to be hardware agnostic. You think about software defined storage, and they want to be able to run their application on any hardware and not be beholden to some unique class of hardware. So those are some of the challenges that have come into play. And then at scale Flex, what we really focused on then was let's make it easy, right? We need to take something that can be broadly applicable and make it transparent so that people don't have to refactor their software. You don't have to rewrite code or do something unique to take advantage of the features, plug it in and see things improve. That was the kind of the pivot that had to be made from the initial kind of product concepts into how do we get it deployed. And how do we start to get broader adoption?
Speaker A: Uh, that's interesting. I'm wondering when we talk about storage, and I've heard this from several of our customers, that when they're trying to comply or they have to comply with regulations coming from the security world, that if they're going to tie their server in as a main part of the product that they're launching or the service that they're launching, then that storage also has to come under the regulations of compliance. So can you talk at all to the security side of that challenge?
Speaker C: Yeah. So from storage, we've got good standards in terms of the encryption and data protection for, uh, protection for data at rest or in flight. And all of those are going to be standard features of drives. When it comes to computational storage, when you enable programming or loading and changing of programs down in the device or in an ssd. Now you've introduced a potential security opening, right? Because you're saying instead of things being fixed up front, now here's another way for somebody to introduce a program which could potentially be introduced by a malicious actor. But it's, it's kind of the same as with your just loading an application onto your, your main processor for the server. You've got to integrate, introduce those checks and verifications. And so that was something that came to light as we started talking through the industry standards bodies around how do you program down there? So the first issue was simply how do we package programs and how do we identify that there's a resource there to program? And then once we kind of work through that now it's how do you secure that, how do you make sure that there's a, uh, that this is a verified program that's going to run? And so there's still work going on to resolve that. And again, that's for those programmable resources. And that's where if we've locked the function upfront such that it's immutable, you don't introduce that potential for a security risk. So that's again, the first deployments are let's avoid the security risk and do immutable functions.
Speaker A: So thanks for that. That gives some really good background. I'd like to shift now into more of your background and talk about the lessons from leadership that you've learned over the years. So you've multiple leadership roles in some of the biggest names in tech and also in startups. So what key leadership lessons have you learned and how do they differ between corporate and startup environments?
Speaker C: That's a pretty broad one. Probably a couple of things that come to mind here. And this is really not just from how I've acted, but in watching and listening to people that I've worked for and worked with and across different companies and then even our customers and suppliers. And I would have to say, let's see, number one, the best leaders and managers that I've worked for have been great at building loyalty and a sense of team. We always have to focus on outcomes for the company, right. And generating profits and growing the business. But at the same time, those leaders really focused on growing the people, managers and leaders who are looking to help you in your career and help you grow your skill set and get you into the right place that where you're going to be happiest, because then you're going to be most productive. So that's one thing is as a leader, it's great to set high expectations and drive for results for the company, but that also means you're going to get more results for the company if you get more results from your people. And also with those leaders, they recognized where they were the experts and where other people on the team were the experts. And being the leader doesn't mean that you have to be right 100% of the time or be the most knowledgeable about every single topic. It means you got to recognize who knows the most and who has the best information and leverage that information to make better decisions for the company. I think on the lines of that developing the people and managing the people and building that team atmosphere, it was something that I've observed from those leaders, but it was probably best put into words through the, uh, Taekwondo master we had when my family was taking Taekwondo together. And that was part of the whole program was coaching. So even though you're a student, as you advanced in the belts, then you would lead classes and they taught you how to lead classes. And the simple lesson was praise. Correct? Praise. Praise. So with that employee or with that student going up to them and, um, saying, hey, I really like this aspect of what you're doing. For this thing, we need to improve in a certain way and then as they make the changes, provide some more praise. So it's very easy. And I definitely got caught in this early in management of focusing on what needed to be fixed and pointing out the problems and, you know, here's what was wrong. Here's what was wrong. Hey, fix this, fix this. That gets to be pretty depressing for your people. From psychology, you mentioned the psychology earlier that can introduce if all you do is focus on the negative and focus on what was wrong. It leads into what's called, in psychology, learned helplessness, where the employee feels that no matter what they do, it's going to be wrong. And so it kind of discourages action and encourages people to just not do anything because it's, they're going to be wrong and they're going to get punished for it. So shifting to focus on, hey, I really appreciate the effort that you put into this draft. I, uh, could see that there was a lot of effort in here and there's some great points. These are some areas where we need to improve and giving them specific ideas on how to improve and then that builds their confidence that, hey, my boss appreciates me. And being appreciated is one of those things that all of us want, whether it's at home or at work. And so that just helps keep them active and with the people. If they won't take initiative, you're not going to get the most out of them. I had a boss say this as what's the number one thing that he looks for in people? And it's initiative. And that has stuck with me because it really, again, that was a key word that codified that attribute, uh, that you're looking for somebody who's going to take action and look for things to do as opposed to sit there and wait for you to tell them what to do.
Speaker A: Yeah, I agree with you completely. It's, uh, you know, it's interesting because I've been managing also for quite some time and I think one of the things that I like to see also in my people, no question, take risk, innovate, take responsibility, meaning, you know, you take ownership and that ownership is really important and you will have that ownership. Because Shlomi can tell you, I tell the guys I don't want to micromanage anyone and if I have to, that means I'm spending my time where I shouldn't be spending my time. And if you take responsibility and you take ownership and you do the best you can, then you will succeed. And if you need help or if you need positive comments to, like you said, this looks great, let's maybe take it a little bit further, you know, in the, in that direction and, and always motivating and always really, you know, getting people gung ho about what they're doing.
Speaker B: I was about to say that thing, uh, about initiative, that it also creates ownership because the person who initiates also wants to own the thing. So it's kind of a, uh, double edged sword. But a double edged, a Reinforcing cycle. Like it's a good thing.
Speaker A: Yeah, exactly. You said it in the psychological psychology,
Speaker C: instead of a vicious cycle, a positive reinforcing cycle. And I gu. There were two other things. One, just on the general leadership thing, and that is don't make decisions from desperation, particularly hiring decisions. I've been in that situation multiple times of gosh, uh, we just have so much to do. And I'm pulling my hair out. That's why I keep it really short, so I can't get a good grip. It is. And you're pulling your hair out because you have too much to do and there's no way you can get it done and you're stressed and you've got that wreck open and you just can't seem to find a good candidate. And hiring somebody who is not a great candidate only digs your hole deeper because to your point there, David, uh, you spend more time micromanaging or fixing problems that they created than you saved time by having them be there to begin with. You can't always hold out for perfect. Right. Because that perfect candidate probably doesn't exist. Based upon whatever you wrote for your job description, there's probably, you know, only a handful of people in the world that would meet every aspect. But make sure that they're a good fit for you, for the company, and that they've got those core attributes that you care about. You know, if they've got the initiative and the problem solving capabilities and the ability to learn, that's going to overcome some lack of domain knowledge and that's. They're going to be helpful for you.
Speaker A: I'll give you the flip side of that, which is that if you have someone in place who's doing a mediocre, uh, or worse job, then don't continue with them. Because if you let them go, it'll be better for them, better for you, and you'll find someone more quickly who will do a much better job because you'll be put into a position where you have to.
Speaker C: Yes. Yeah, there's definitely a. If you're not feeling enough pain, then you don't act. New technologies, too. If your new technology doesn't solve a pain point that your target customers, uh, are really feeling, that is one of their top pains. They just, they don't have the incentive to move. You know, they're like, I'll just stick with what I'm doing today.
Speaker B: And that is a perfect segue to my next question. Very, very nicely done, JB I don't know if it was on Purpose or not. But I did want to ask you about driving innovation. So throughout your career you've launched a lot of uh, groundbreaking products. We talked about SS before we started recording and then others. And you also developed strategic roadmaps for those products. So how do you balance the need for innovation with more practical constraints such as market demands, resources, security? Of course.
Speaker C: Well, you definitely, I mean, you know, in the prior one you asked about how's the difference between big corp and a startup. This is probably where I've seen the biggest difference is that willingness to take risk kind of in the way that you view constraints in the large corporations. I always experienced kind of uh, the zero based budgeting. That was the intel term where hey, your budget is X and you can start working. You know, line up your resources against that budget, put as many programs as you want, but don't exceed that budget. And then by the way, next quarter we'll probably come in and cut your budget. Uh, that's not just an intel thing, but that was across other companies too, was how can you do what you already said you were going to do with fewer resources? In the startup world it's a little more of like, what do we want to do? Let's line up all the things we want to do and then we'll figure out how to put resources behind them. As long as they're all great projects and they're really going to hit the market, we'll grow our budget, we will grow our resources, we will invest to develop those. So it's a bit, uh, that's a very different mindset for me of that resource constrained to the what can we do? Flip side. But in terms of balancing those and driving innovation, it's definitely not an easy task because you're looking at uh, not just what do we think is cool but what is going to, as you said in the prior one, what's really going to solve a problem? What's really going to move the needle for our prospective customers? And again, this is a little bit different for large corporation who has an established market position versus a startup when you're coming from zero revenue, whether it's as a startup or like at lsi we were doing a new product class, you're starting from zero, you're not defending territory, you're not, oh, uh, what do I have to support from the prior generation of products and carry that forward because my existing customers are going to require that whether they maybe they've outgrown the need for it or not. Think of how heavy Microsoft operating system has become over the years as they tried to carry forward legacy features and then eliminating legacy features is a really real, real big challenge to get people off of those versus starting fresh. So you've got that balance or that difference between a startup, uh, or an innovative product category where you don't have that legacy and the carrying forward and how do we innovate and build upon those. But it's always that balance of what does a customer say they want versus what do they say they need and then what's the real problem that they have? Because uh, I've experienced this and I'm sure you guys have of uh, whether it's personal or professional, they say they, they need a new feature, you know, a new security feature. We need better encryption for example. We need to shift from 128 to 256 bit encryption. Well, did they really need that specific feature or was there a different problem that they were trying to solve? It was for there perhaps the problem was I need to reduce my opportunities for people to pierce my data protection. Well, you could have solved that with the better encryption or maybe there was a different feature that could have been deployed that solved the problem more thoroughly. And so it's not just listening to what they say they need but digging into why they need it and how they plan to use it. That's really going to help you in reading the tea leaves to say this is where we need to innovate.
Speaker A: Yep.
Speaker B: Right.
Speaker A: So you know, it's interesting what you said about previously about the large companies versus the smaller ones. And I always think, think of I, I've been in some very large organizations also on Wall street, also in one of the big defense manufacturers out in California and the Last I guess 20 something years I've been in startups so I've seen the difference like really big. And I think once, you know, when we're talking about these big companies, I don't know, I, from a psychological point of view I think of them as being stable entities that uh, are, you know, they're trying to mitigate risk and they will not be. They might have a small group of people that their job is strictly to innovate or to look for new things ignoring everything else in the organization. But the general mainstream attitude is innovate but don't go too far. Right. Whereby the startups, why did they succeed? Because you know we have this expression, uh, changing an engine in midair. So they start, they go forward and they pivot when they need to pivot and they do it quickly. And which is why we see some of the online banks taking over customers in thousands from the traditional banks. Or we have. I like to use the example of a friend who. So I have a friend who's on the board of a bank and his son created a online trading platform, social trading platform. And he was at a board meeting, the father was at a board meeting for the bank and they, they were talking about how many new customers they had that month. You know, there were a few hundred. And he started laughing and he said, what's so funny? He said, my son has 15,000. You know, it was a few hundred versus 15,000. It's like, okay, uh, and it's global and this is local. So I think that's one of the other things and that's also part of how we look at product management. So getting into that area I'd really like to understand. With your ext of experience in product development, lifecycle management, what advice would you give to emerging product managers trying to navigate today's complex text landscape and how can they push forward, you know, without being locked into too many things that are, let's say too many risk averse managers or you know, the DNA is not set for innovation.
Speaker C: Yeah, you know, some of, some of, aspect of what you said is it's going to be constrained by the corporation that you're working in and what the uh, culture is there and their decision making process. And that's where you know, at a startup the decision making process is a lot faster. You know, there are fewer layers to go through, fewer, fewer people to convince. There's a lot more of the, we believe we have enough information to make this decision. So there's that side of it. But across the, whether it's been a startup or a larger corporation or a startup division within a large corporation. What I've seen in high tech and it probably goes across industries is we all want to work on something cool. Right. Just turning the crank on, oh, let's make the prior generation, uh, 10% better. It's not hard to get excited about that. Hard to get, whether trying to get your customers excited about it or get your engineering team excited about it or your, your go to market team excited about it, you tend not to want to focus on those and everybody leans towards, oh, this is cool, this is really cool. But there's that temptation to focus on it just because it feels cool and not necessarily because it actually solves a problem. So that's where as a product manager I think the number one mantra that I would recommend for folks is start with why instead of starting with what? And by that I mean start with asking why does this feature matter? Why does this product matter? To whom does it matter? You know, what, what part of the market cares about it? Which type of user cares? Why should we build this product or feature? Why will they need it? You know, what is the benefit that they're going to. And I just used what, but what's the benefit that they're going to derive for it? That uh, would just gets to why they would, why they care. Why are they experiencing this problem answering those questions. We're going to get something that's exciting for people to use when we start with the what's the features? You know, and maybe a more generic thing, uh, for me, for SSDs, a lot of times what we end up, okay, the very visible features like how many iOS per second is this drive going to deliver? How many terabytes of capacity does this drive have? What is the very simple metric on its latency where these are kind of spec sheet things that a. I can't say uneducated, but uh, a buyer who doesn't understand the deep depth of the technology, that they line these products up against each other and they say, oh, better, better, better, worse, better, and maybe they're just buying on who has the most green checks. Those kind of features don't get into what's the benefit of a user. You know, why should we invest millions of dollars to get an extra 10% on this metric on the iOS per second, or an extra 20% capacity into this form factor instead of just saying, hey, let's get product out faster, you know, we could save millions of dollars in product development and maybe it doesn't change how much revenue and margin we get from this product whatsoever. So making sure you start with the whys instead of just what's going out of our industry and into, uh, you know, I watch football and there's always truck commercials on there. 400 horsepower versus, you know, the highest towing capacity in the industry. Well, does your buyer really care about that? I'm sure that the buyer cares about some of those aspects. But if you're not lining up the features against what a customer needs and uh, a benefit that they're going to derive, then you're just putting up some kind of hero number. That, sure, maybe that convinces folks, but you probably overspent on your development, uh, and made the problem harder for your engineering team.
Speaker B: Yeah, I couldn't agree more. I think another thing you're doing. If you're starting with the what is, you kind of force everyone to the spec sheet. And if that's what you're doing, then it's so easy to compare to your solution and compete with your solution because you're competing on numbers. Whereas if you figure out the real problem and you tell the story of the product the right way, you can do wonders. And you know, there are countless examples of this. The most famous is of course, Apple versus what everyone else is doing in the tech industry in the past 20 years, how they present their products. But there are so many other examples. I couldn't agree more. And, uh, before I say bellum, I spent 10 years helping founders try to figure out their positioning and build their brand, etc. And the first thing I would always do is I would sit them in a room, I would make them write down all of the features and all of the technical what's, as you call them and convince me for each and every one that it solves a real problem and what problem does it actually solve? And if it didn't, it would go out the room and we didn't even discuss it. I would tell them, okay, put it in the spec sheet and forget about it. Like, uh, it's not, it's not in my realm. So I completely agree with you. It's an underlooked problem and probably the most important one. And the reason that some tech giants become giants and others are not.
Speaker A: I think that, by the way, is also based around the fact that quite often, especially product people, when you ask them what is the benefit, they give you the feature and they don't explain the benefit of the feature. And then it comes to the question that I ask, which is also what? But it's so what? Exactly.
Speaker C: You just said exactly what I was
Speaker A: going to say until they get to the point. There we go.
Speaker C: Yeah, because that was the, you know, we do our product presentations, right? Or a part of the product life cycle of here's all of the feature landing zones for the product and you know, there'd be the summary of, of all the features and it's like, okay, you've given me the what? Give me the so what? So why does this feature matter? The exact same phraseology that you use.
Speaker A: David, it's great talking with someone who has this experience.
Speaker C: You mentioned Apple and that just reminded me of a story that I had heard from a guy that's been a serial entrepreneur and brought multiple companies out to ipo. And he came in and he talked about having visited kind of over the course of just a couple of, of months, Apple and another vendor, another major vendor, I won't, I won't throw them under the bus, but at the unnamed vendor they were looking at, what are all my competitors doing? What are the features they have? What do they want? What are they doing? And they were looking sideways and at Apple. He went into Apple and listening to their product definition and he's like, you know, you realize that company B has a higher spec for this feature or has this other feature that you guys don't have. Aren't you worried about that? They're like, yeah, I'm sure they do, but what I care about is what my customers want. So it was a. Yeah, you have to be aware of what your competitors are doing, but don't define your product just on we're going to be better than the competitors on these features. How are you going to better address your market and your customers? And that's the focus and that's where you're looking ahead instead of looking to the side and looking behind 100%.
Speaker B: And I think this is also true in sport, which is my way to create a segue to the last question.
Speaker A: You do that really well. Shlomy.
Speaker C: Well, I tell you, in the sports it's very easy for me to look ahead because I'm usually near the back.
Speaker B: Good one. Maybe you can finish up with that because it is fascinating. So outside of work, you're an endurance athlete tackling spartan races and triathlons. So I'm curious, how does participating in these physically demanding activities influence your approach to leadership, to teamwork, to problem solving? Um, um, I'm sure it does. I'm curious how.
Speaker C: Yeah, I mean, it's, you know, I had to shift. I've always been a. I mean, all through high school and stuff as a competitive athlete, not necessarily the best, but competitive. And as you get older, you can't necessarily go out and play football and basketball as competitively. So these endurance things don't beat up your body quite as or they beats you up in a different way. But, you know, it's really about setting. When I look at now like a longer triathlon or Spartan races, you can't just show up and do well or show up and expect you're not going to get injured or show up and expect you're going to have a good time unless you've prepared and with that preparation. And this is kind of where parallel for work is set the goal, know that you're going to, you know, sign up for it. Uh, Sign yourself the goal. Take accountability. You mentioned accountability earlier. So make yourself accountable for it and then put a plan in place to give you the best chance of succeeding at achieving that goal. You can't guarantee that you're going to succeed because there's going to be things that are going to hit you, whether in your training, maybe there's a random injury. And as I've gotten older, then it's just like, how did pull my calf walking down the stairs? And in the business world, hey, something shifted in the market. Suddenly there's an oversupply in your industry that nobody, that people didn't predict. And so you have to pivot. And uh, that throws a wrench in your whole plan. But, you know, put that plan in place. Seek coaching where you need it, you know, for, for triathlons. I had a buddy who got me into that a few years ago and I went back, I'm like, well, I, I can swim because I've swum since I was a, you know, knee high to a grasshopper. I didn't know how to swim, like swim, swim properly. And I went to the pool and I hopped in and I swam two laps and I thought I was going to drown. And so seek coaching. Get somebody who can teach you how to swim properly and efficiently. Or at work, if there's a topic that you don't know about that's critical to your project, get coaching. Get a consultant. Get somebody within your company, somebody in your network to just take some time with you and talk to you and learn from them, YouTube videos, etc. And then, uh, adjust when things go wrong. I mentioned the injuries that, that can screw up a, a plan. So for training is, hey, if I pulled my calf, well, I can't run, but I can bike. So maybe you crank up the biking aspect and tone down the running. Same thing at work. You know, a, uh, critical bug happens in the firmware when you're getting ready to launch. We got to pivot. You know, maybe it's we, we launch without a certain feature and that becomes, uh, an upgrade feature for a secondary release or we have to cut different SKUs from the product for an initial release to satisfy a, uh, new customer that has come in and we need to pivot and focus on them to get the best benefits and then celebrate the successes. You know, so if you put in place your plans, even if you didn't set a new PR personal record for a certain race, you finished, you completed, you did well, Go celebrate with your team and your coaches and then move on. To the next one. You know, set a new goal and work, uh, to achieve that, persevere. So it goes back to that accountability, setting those goals, setting the plan and just slogging through it. There's plenty of days I'm sure you guys have experienced where you wake up in the morning, it's like, oh gosh, I just really don't want to work on that project. But the same thing with, with the training is like, I just really don't want to go do a 20 mile endurance run on Saturday. It's cold outside, let me just have some coffee and watch, watch sports. But you know, holding yourself accountable, eating, uh, the, I forget who's which guru's phrase this is, but eat your dead frog. Do that thing that, that's sitting on your shoulder, just that you don't want to do. It'll make you feel better and then, then you're, it lightens the load and you can go on and get other things that you want to do done. And you're. Removes that stress from you if you just take care of those annoying tasks and get them off your plate. Cool.
Speaker A: I like it. And I think you're right. I think it's always best to get rid of the ones that, the ones that you might not want to do at this moment, like getting up at 5:00 in the morning and going out there doing 10 miles much. Uh, you're going to be running, but once you finish, you come back, you have a great breakfast, you feel like,
Speaker C: uh, yeah, you feel, it's like, oh man, I'm so glad I did that. You know, and just like you mentioned that, that tough conversation with an employee who maybe they're, they're just not cutting it. Have the tough conversation, you know, otherwise you're just going to be stressed all week, all day, you know, all month. On gosh, this guy just isn't cutting. They're not doing this or not doing that. Have the conversation with them. Um, maybe it's just they need coaching and having that frank, open conversation will move the ball forward and it relieves that stress from you and then lets you be more productive, um, in all your other activities.
Speaker B: So, yeah, I love that. And I think it reminded me of, I saw once a story about a woman, an older woman who crossed the English Channel by swimming. And when they asked her how she did it, she said, I prepared. And she was like, the answer was obvious to her. I just prepared. Uh, I think it's exactly what you're saying, that at the end of the day. You know, if, if you have a goal and you. And you set it and you prepare for it, and this is probably the hardest part, and not give up throughout the way you can get there. And it doesn't matter what your limitations are. So I guess that older lady had much more limitations, but she didn't care about that because she prepared, so she prepared longer, but you're still prepared. If there's one thing I'm taking away from this conversation, it's that among, uh, many other things. So I want to thank you for coming on and for giving us the professional, technological, personal, uh, insights. I think, you know, this podcast a lot of times kind of swerves away to the more technical side, but this has been a, uh, much more engaging and inspiring conversation about things that are bigger. So thanks again for coming on.
Speaker A: Lessons in Management. Excellent.
Speaker C: Yeah, well, I appreciate the opportunity. And yeah, most of my conversations, my day is focused on all of these technical conversations and we drill down into features and benefits. And so being able to take a little shift and talk about more management and leadership aspects has been nice for me too.
Speaker A: Great. Thank you for being on the show.
Speaker C: Thanks, guys. Left to our own devices is brought
Speaker B: to you by Cybellum. To learn more, visit Cybellum do.
Speaker C: Mhm.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.