[00:00:15] Ghazenfer: 

Hello, everyone. My name is Ghazenfer Mansoor. I’m your host from Lessons from the Leap Show where I interview entrepreneurs, startup founders, business owners, technology leaders, SaaS founders, CTOs.

We explore their business journeys and discuss how they create innovative software solutions for their enterprises. This episode is brought to you by technology rivers, where we bring innovation through tech and AI that solve industry problems. We’re a software development agency where we provide two main services.

First, helping businesses in process automation. We help them improve their business operations through AI and technology. And secondly, we work with startups, entrepreneurs, and product owners, helping them create innovative software products, Saas, web mobile apps. Most of our work is focused on healthcare industries where we assist health tech companies in developing HIPAA compliant web and mobile apps. Interested in working with us? Go to technology rivers.com and tell us more about your project. 

Our guest today is Joe Hubert. Joe is an innovative tech solution provider who builds a career on turning complex business challenges into streamlined business solutions. Has a seasoned technical manager, systems analyst and solution architect.

He brings years of online experience in database designing, system integration software development to the table. Currently, he is at the forefront of helping people and organizations navigate AI literacy and adoption, ensuring businesses can harness their emerging technologies effectively. What sets Joe apart is his unique ability to break the gap between technology and business needs.

Where fostering a collaborative, psychological, safe environment for his team. Known for his servant leadership approach and committed to staying ahead of industry trends. He is frequently called upon to lead cross-functional initiatives that drive real organizational value. Joe, thank you very much for joining our show. Welcome. 

[00:02:26] Joe: 

Hi. Sure thing. I am looking forward to having this conversation. 

[00:02:30] Ghazenfer: 

Cool. So you have had a career spending over three decades in. Software, architecture, solutions and leadership. Looking back, what key decisions or leaps have helped shape your journey? 

[00:02:46] Joe: 

Right. So, my career, I started off as a software developer, at startups in small companies for the most part, where roles and responsibilities are a bit more dynamic. I was on a number of projects where that were just perceived as unsuccessful because the team wasn’t delivering what was expected. And it was frustrating for both sides. Both sides mean like, you know the leaders and the product leaders having the requirements, the need and the software developers trying their best to develop that.

Early in my career, I didn’t recognize the issue, but as I’ve been through this, went through this pattern a number of times, I recognized that the problem was the developers weren’t getting the guidance and direction at the level of detail that they needed to be successful, and it isn’t too surprising that this should happen.

I mean, because there’s different skill sets and different personalities and vocabularies on both sides. So just seeing that and then transferring or evolving my career to be more of that role, which you can do in a smaller company, you can sort of find your role. I’ve seen these kinds of efforts become a lot more successful and effective, and both sides are happier.

So just, I would say being part, being in those situations and eventually recognizing them really shaped, how my career evolved. 

[00:04:13] Ghazenfer:

Thanks, as we were exchanging messages earlier on LinkedIn, so you shared a great analogy about football, that players win games and coaches lose them. How does that analogy show up in the world of software development?

[00:04:29] Joe: 

Sure, sure. So at some point I did realized that developers can pretty much do anything. The developers I know are capable of anything realistically, they can deliver anything. They usually don’t hit a wall technically, just like, you know what? I just can’t do this. Not saying that could never happen, but that’s typically not what it is.

It’s typically they aren’t given that the problem is not framed up well enough. And I explained this to some colleagues not too long ago, my thoughts on this, my philosophy on this, saying that I think developers could do anything. If there’s a failure, it’s usually that they’re not given enough support and guidance.

And my colleague said, it’s like an old football saying from a coach, players win games and coaches lose them. And that may not be a hundred percent true, but the idea is that there’s the doers and then there’s the people that have to support and drive the doers. 

And if there’s a failure it could be more the responsibility of the leaders that are supposed to give the right and necessary direction to the people that are taking care.

[00:05:41] Ghazenfer: 

Yeah, that’s an interesting point. As part of our work we also help fix many broken projects. Many times customers come to us and there’s an existing product that they’re unable to launch. It’s not completed. It has so many different issues. And many times it seems that the reason is not necessarily the developer, which in many cases there are but majority of the time we have seen it’s not the right direction or right requirement.

You know, in software garbage in, garbage out. So that is also one of the challenges. So why do you think it is so common for business leaders? To unknowingly give insufficient guidance to the dev teams? 

[00:06:34] Joe: 

Right, right. So first of all, I don’t think it’s deliberate, on either side because that wouldn’t make any sense. It wouldn’t make sense for leadership or any type of person in that position to deliberately make a team ineffective. I don’t think it’s deliberate on the development side to be like, you know what? I’m just going to, I’m gonna do what they told me. I know it’s not enough information. I think that often since that gap.

Can be significant due to things like that, personality, vocabulary, whatever. I think it won’t be recognized in a lot of places, that they don’t recognize there is that gap and there may not be. It’s a blend of a skillset, right? That can speak development enough, that could speak business product enough to know how to bridge that, how to ask the right questions.

So I think that the prevalence of the problem is due to the fact that. With those two necessary sides that are needed to deliver something, there’s enough of a difference that they can’t even recognize that they’re not on cases. 

[00:07:36] Ghazenfer: 

And some folks argue that agile means we don’t need super detailed requirements upfront. What’s your take on that? 

[00:07:45] Joe:  

So that’s interesting. Yep, yep. So usually I’m following an agile process that the company’s about if something like it, and it makes sense, I think, I think in general. The agile process makes sense. And I would, I would follow some flavor of that going, going forward, because iteration, especially with a lot of, there’s a lot of reasons that iteration makes sense now.

But to your point, I think, take it too far, it can foster the mentality of, you know what this is the fourth time we’ve tried it and it’s still not right, but that’s okay. That’s what this agile thing is all about. We’re just gonna keep. Iterating until we get it right. And that’s probably taking the idea too far in that, you know, not putting enough discipline on really defining what you’re supposed to do.

You don’t wanna do the, the monkeys on the typewriters waiting for the novel to come out. So, I think it’s, it’s possible that the agile mindset might make that iterative process a little too acceptable in some cases for people unless it’s, you know, inappropriately, acceptable. 

[00:08:51] Ghazenfer: 

Yeah, it’s a tricky balance because as we all work in the software, so we also see that, so on one side, agile, yes, help you have the right path because you’re getting a clarity, getting a feedback quickly, but at the same time, that can go out of hand and it could be expensive.

And especially for the startup projects. So we came up with this methodology, which is, we call it an agile startup, fairly methodology, which is a small piece of project you created more like a traditional way, complete all the requirements, everything finalized, end to end design. But that doesn’t mean for the whole big project, but a very small scope, like could be two to three months.

And then do a project. So basically you could have a bigger agile sprint, but each agile sprint would have a very defined scope so that the founders know exactly how much money they’re spending. So do you see anything like that in terms of how you balance this thing? 

[00:10:06] Joe: 

Well, yeah. I mean, sure there’s, I think what the whole scope management  idea you have is key you need, there has to be an agreement that we’re not gonna shoot for the moon. 

We’re not gonna get everything all at once. That usually leads to conversations between the development side, that the product side of, you know let’s help prioritize let’s see what makes sense.

And this is a spectrum because, It’s all, you know how much resources, how much time, how much money, do you have? How quickly do you need to get so many features to the market to be competitive versus can you take time? So managing the scope is key. The parameters around how you manage that, what has to be done, and how much time can really vary situationally by organization, by type of thing you’re doing.

But the key is to give that attention and have that agreement with everyone involved. We have to be reasonable on how much we can take on a certain timeframe to be successful. 

[00:11:11] Ghazenfer: 

Okay. Yeah. I was gonna ask you if you have any playbook for diagnosing, where the communication gap is because you have worked on many failing and struggling projects, it seems like you’ve pretty much covered already somewhat. But yeah, if you wanna add that would be great. 

[00:11:29] Joe: 

Sure, sure. As far as, yeah, as far as having somewhat of a playbook to manage that gap, I’ll start with, this discussions start with the product and the leaders, not with the developers, you know, isn’t because that’s the, what comes from there and the approach I take is usually I got a use case narrative type of approach.

You know, considering the system or the features or the integration, whatever. What are the participating roles? Of the users or possibly systems, and we’re not looking for job titles, we’re looking for roles as far as what type of scope of functionality they’re supposed to do. Identifying those roles, identifying the important actions, use cases each role does, looking at those most important use cases by role and, and detailing them out, asking the right questions, getting the right answers.

Again, this takes some type of skillset to know what the right questions are, know how to understand yes and no from the people giving the direction and then the reason I think this use case narrative approach is good. It’s understandable. It’s something that could be signed off by the owners

They look at it, it’s understandable, yeah. What the user does with how the system responds. What the rules and behaviors were, it can make sense to them. Yes, this is what I’m talking about. It’s a little bit easier to determine if something’s missing, if you have it, this is everything the system’s gonna do is something missing.

And then that’s also a good framework to start working on the design or the developers. What are the object models, the design models, like where are the rules? Like what types of things to do. So I think taking that for me in general, taking that use case narrative. Is an effective way to represent things completely and clearly and have a good vehicle that both teams could work with consistently.

[00:13:27] Ghazenfer: 

That’s really a great point. I think that could be a good recipe for a successful project following that. So we have created a process where we call it like. A blueprint process. And we said, Why does every project need a blueprint process? And we take the analogy of a house.

If you’re building a house, how many times would you just start and then keep changing? So it is gonna, it is gonna cost you a ton of money and not the house that you want. Yes, you will get to that state, but probably 10 times the cost. You can’t afford that. So just like the house before starting, you have a clear blueprint of what would be built.

The foundational things, everything, and then up to some limit, you can make changes later on. So that’s very important in the software and you clearly touched that, and that’s really a good point. 

[00:14:24] Joe: 

That’s great. Absolutely. I agree with the analogies are always good because people can understand something that you’re familiar with and it’s a good way to frame it.

[00:14:33] Ghazenfer: 

Right. So, what’s the moment in your leadership journey where taking a people first approach paid off in a technical setting? 

[00:14:46] Joe: 

Hmm, that’s an interesting one. So, by people first, I’m assuming you’re meaning like really taking into account the personal interaction and appreciation level. Yeah making this as far, I don’t know if I can really tie directly to a technical.

But personal interaction is key. No matter what our profession is, we’re people, we want to be respected, treated, understood as people. So especially developers. Developers seem to typically have the aptitude of wanting to be given some mission and then pleasing and achieving it.

So being able to manage developers, keeping them secure, you know, secure in the sense that even if they make some type of mistake, it’s gonna be dealt with appropriately, not without overreaction. So just getting, building up enough trust so that the developers will be comfortable and doing what they can do best.

Give you their honest, open inputs, not hearing any type of overreactive negative feedback. This whole trusting that sets up a good relationship. It makes developers more effective and it makes them more willing to want to help out and cooperate when you need to. Another analogy I’ve used is in the marvel, in the superhero movies or whatever type of movies like that, there’s the leaders that lead with fear, intimidation, and consequence.

They usually happen to be the, the bad guys on the side, whatever they go, you know, they’re, that could be effective for short term because if somebody’s really afraid or somebody fears consequence, you can, you might have some control versus the leaders that lead with, trust, example, you know, guidance or the, the Captain America type guys.

And the difference is those, they both can be effective. But what you notice is when things go bad for the negative leader. They’re not gonna have the people following them. However, when you build it up on trust and responsibility, you will have the follow so to kind of answer your question is if you can build the appropriate relationship with developers that is made of trust and guidance, they’re gonna stick with you, which is key when a technical challenge is so great that you need that extra push.

[00:17:23] Ghazenfer:

Well that’s a good point. And I remember you talking about servant leadership and psychological safety and, your comments pretty much resonate with what you talked about psychological safety and the servant leadership. Yeah. So I’m gonna pivot a little bit to a newer staff.

So you started obviously as a developer in the early nineties, and now you can consult on generative AI and LLMs. What has been the biggest transformation in technology that you have personally experienced during this whole? 

[00:18:05] Joe: 

Yeah, so yeah, I’ve seen a number of them, you know, the evolution of where software lives from a small PC to a network to the internet and how we deploy things.

So that was a big change, you know, from things being internet available was a big change. I have a feeling this AI part we’re going through right now, it feels like it’s going to be possibly the biggest, we’re gonna have to look back a little, but this is definitely, a very monumental shift.

This can require a lot of thinking, a lot of ways of addressing problems differently, teams differently. So it’s obviously a real significant shift in what’s happening in technology. 

[00:18:52] Ghazenfer: 

Cool. And in your experience, do you see any common challenges technical managers face when they move into leadership roles and now obviously with ai, that part is also gonna be significantly changed?

[00:19:09] Joe: 

Sure, sure. Well, technical professionals moving to leadership roles can, there’s a lot of work that can happen there. I think there’s a lot of technical professionals that aren’t well suited and just don’t want to be suited to the manager role. They wanna do their thing, they want to be in their laboratory and build this amazing thing and just focus on that and not be bothered with personal issues and everything.

As far as how, so I don’t know for that particular thing, unless you’re thinking of something different that I’m not catching for that particular evolution of the technology person to a manager role. I’m not sure if that’s one of those things that AI has the biggest influence on. AI is suited for some great things, AI is not well suited for the human nuance and, and things that may be important in that transition to management I think. 

[00:20:07] Ghazenfer: 

Yeah, yeah  that’s fine. I just wanted to hear your point of view on that side. So, you worked with both startups and large enterprises. What do you think each can learn from each other in terms of innovation? 

[00:20:32] Joe: 

Yeah, so right on the large company, on the larger side, there’s more rigor and discipline typically. And just oversight in governance, which can be good on the smaller side, there’s more agility, more aggressive, more fast paced. So, both attitudes have the emphasis is situationally dependent on the market, on what’s going on.

But, I think both sides could serve from a balance. Sometimes the overhead of just the governance and the management and the, whatever the red tape around things is just there. Because of inertia, it’s always been there and it’s the way we do things.

So, that’s probably that, that makes it, that leads to it or it indicates something being unnecessary. I think, yeah, I think that companies that have too much of that have to understand, do we really need all this still? And for the smaller companies that are very fast paced and maybe I’ve been with companies that probably a little too fast paced and a little bit reckless with some things know that as things scale, as customer size scales as, as things scale, you probably have to start putting more discipline process.

And regulating things better, as you grow. So, I think both sides just need to look at what the pros are, the benefits of those different approaches, what the challenges are, and just understand what’s appropriate for your situation as you, as you grow and change. 

[00:22:21] Ghazenfer: 

Yeah, that’s good. Do you have any prediction of where the AI is taking the world? Where do you see that in the next few years? Like. The future of the solutions architect, the technical managers. 

[00:22:39] Joe:

Right, right. In the very short time frame, I hope that we realize we still need engineers and engineering discipline for these projects. When the vibe coding thing first hit, the immediate reaction was software development is done.

Software developers, that’s no longer a career, we don’t need that anymore. I think that’s tampering down. I think people, I think there’s that opinion seemed to be coming from people that had no appreciation of the software development lifecycle and probably didn’t have a vast experience with the tools.

I have both and I’ve been using these tools and it’s not time to get rid of software developers, the engineering discipline around us. And looking at, looking at what’s being generated. I am seeing a bit of a reaction of, everybody calm down a lot and a lot of posts on LinkedIn such from people that have that background and software development lifecycle from people who have been trying these tools and see where the shortcoming is.

I kind of think that if the chainsaw was invented today, there might be some content creators. And maybe company leaders that would say, now everybody can be a lumberjack. So, whatever. It’s, it’s not, there’s still, there’s still going to be a need for software development. The way I see this evolving is, I think right now these language models, these models are built on language, but for the most part, these, these, especially these code generators, they’re built on language patterns to really be better.

And less fallible and less prone to things like hallucination. They need to be more concept based. The model underlying doesn’t have to be a  pattern of, you know, tokens, that arey ou can predict the next one based on the embeddings. It has to be more about this conceptual understanding, rule-based, conceptual.

That’s how we think, that’s how we generate code, building on concepts, not on language patterns. So I think that’s gonna be an obstacle that has to really progress. 

[00:24:57] Ghazenfer: 

Yeah. I’m glad you mentioned that point of vibe coding. You are absolutely right. We have been approached by multiple people.

Yes, it’s a good starting point to create a POCs, but once you have it, now, what do you do? That’s when these people are getting back to the world post, because now you need somebody to take that into a real MVP. So, and that’s  a very common need. So I also think that it, so the changes that in the past you were creating sketches and handwritten requirements and all of that.

Now people who can articulate, well now people who. We have a good sense of what they want. They started elaborating more and creating the initial version, the initial concept in these vibe coding tools like lovable. And, and so that’s a good starting point, but without, but after that you still need right the actual real integration and, and the code and like. Yeah, compliance related, whatever are the different things. There are a whole lot of things you need to do after that. Sure. And developers will continue to be. 

[00:26:20] Joe: 

And I’m a big fan of the tools. I think the AI tools are great and they can really help with productivity for developers.

In addition to the points you’ve mentioned, they’re good in that early phase, just like AI is good at going through vast amounts of data effectively and quickly. Right. I could see even a seasoned developer being stuck on something, putting in a stack trace into this, you know, whatever, huge dump of errors and things and the AI being able to crunch through that and point things out that the developer says, oh, you know what this class was deprecated, or whatever it is.

Or recognizing that they might have some conflict that still takes expertise on the person’s side, but they’re using that, that ai, something that can do what it does Well crunch through large amounts of data quickly and, and guide them better. So I like it, I think they’re valuable. They will be valuable developers should adopt them. But yeah, it’s still an assistant to developers from my perspective. 

[00:27:25] Ghazenfer: 

So, I have one or two more questions, but before I ask that, I just wanted to point people to your website or LinkedIn or anything. I want people to have the opportunity to connect with you afterward.

So, if you would like to, is there a way people can contact you afterward if they have any software they want to talk about? Any struggling projects they wanna fix? 

[00:28:01] Joe: 

Sure, sure. I do like connecting with people on LinkedIn. I’m just like Joe Hubert on the profile. There is one word, no numbers, I do, though I like to use, I try to use LinkedIn effectively.

I don’t wanna have connections like a bunch of baseball cards. So if I do, if somebody sends me an invitation and we have, you know, a common background or enough commonality that it makes sense, I’ll connect and I’ll say, please, you know, I’d love to have an intro conversation. I don’t like it when someone asks me, Hey, you’re connected to this person.

I’m like, you know what? I have no idea who that is really. I don’t like to do that. So, yeah, I do like to connect with folks on LinkedIn, but I always try to really make it an actual connection and some type of rapport so that it makes sense to be connected. 

[00:28:51] Ghazenfer: 

And I would recommend our audience to mention the lessons from the leap podcast so that you know how they find out about you.

So one other question. So the world is changing with AI and obviously now, people are debating whether software development is still a good field or not. You touched on it a little bit. But what advice would you give to anyone starting the computer science career like, traditional development versus anything specific within computer science.

They should specialize. Should they go in, should they do something else, so Any recommendations? Any thoughts? 

[00:29:38] Joe: 

Yeah, I do. That’s, yeah, I wish I could put together a lot of thoughts on this, but I, something’s come to mind. So early in my career, I think I was scared by every news story that said, predicted a drastic change or that something was changing.

It happened a lot, you know, and you can’t react too quickly, Opinions and news headlines will change quickly. So I would say, take everything with a grain or multiple, several grains of salt, keep an eye on it. It’s always good to listen, but don’t make decisions based on every little thing you hear.

Take things into account, take them as different data points, a lot of things have changed and AI is definitely gonna change something. Pay attention to it as a software developer base, pay attention to it and see where things are going as much as you can. Keep in touch of where it’s going. It’s gonna be part of the equation.

I don’t think it’s going to, I don’t see it making software development software developers irrelevant and obsolete. And there’s gonna be, a lot of people are writing about this in detail why that can’t happen? Or just like, doesn’t logically make sense based on, you know, eventually who’s going to, where’s the model gonna get if these models are learning from patterns, who’s gonna keep making the patterns as things change and evolve?

But anyway, and then I also tell the developers to keep an eye on the news. Yes, do this, be ready, be adaptable. So, as these, as the model changes, this AI is the current big thing, there might be another big thing down the road that you have to pay attention to and be ready to adapt as it suits, as it’s necessary for your career.

So be ready for that. Be ready to go with the flow. And then in the case of AI. We know that it falls short in being human right now. So even absent AI, what I’ll tell developers or just anybody starting their career is to continue to take good care of the coworkers, the people that we report to you eventually, the people that you report to be that kind of dependable.

Dependable person that people want to work with. ’cause they can count on you because they like working with you. That’s who people want to bring along with them as they move along with their career. That’s who people wanna recommend to friends with these people. So, just keep with that too and that differentiate yourselves from the AI. Assure  that that reliable person that, um, people can work with, and count on when things get tough.

[00:32:14] Ghazenfer: 

Be proactive. Have a social part, soft skills. So thank you. Excellent.

[00:32:23] Joe: 

Don’t get too scared too quickly. 

[00:32:27] Ghazenfer: 

And, and would you like, on a similar note, like for solutions architects or technical managers. Obviously everybody’s career is gonna be impacted because those advisors are also valid for those people because you can’t be doing the same thing as you were doing in the past. So what skills they should prioritize today to be on top of the game

[00:32:51] Joe: 

Right. So as far as the managers and the higher level people skills are concerned, I think it’s to learn how to take a lot of viewpoints and put them in perspective. So there’s gonna be people with different viewpoints and different perspectives of what it is, what this AI represents.

And try to find where the, you know, the truth is always somewhere in the middle. And try to see if you could determine where that truth probably is, even though that’s a bit of a moving target as things evolve. And also just keep learning. Learn how to, especially using these types of these technologies, learn about them and other things.

Learn about the different areas where they’re applicable. So even in the AI world, there’s chat box, there’s agents, there’s research, deep research agents. There’s different types of ways of using these. So understand what that landscape looks like.

What type of tools each do, what type of use cases each one addresses. So just get a broad understanding and use whatever vehicles or videos or articles you can do to get that. Keep up with that understanding.

[00:34:03] Ghazenfer: 

Thank you, Joe. Thank you for all of these advices.Thanks to all the listeners who are listening to us. So we’ve been talking to Joe Hubert who has shared some excellent nuggets for anybody working in software development, for anybody who’s struggling with their projects getting to the edge.

So thank you Joe, for sharing everything. Is there any final word? Anything you wanna talk about before we wrap. 

[00:34:32] Joe: 

No, no. It’s great talking with you Ghazenfer, maybe some, we’ll see how this vibe coding stuff, how the mood changes and maybe we can regroup and talk about how that’s going in some more detail at some point.

[00:34:46] Ghazenfer: 

Absolutely, absolutely. Sounds good, thanks Joe. It was such a pleasure having you on the podcast. Thank you.