Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
/foundations: the art of uncovering why
42 Plays6 months ago
In this episode, we sit down with Steve Berardelli, leader of Callibrity's Foundations practice, to explore the art of uncovering the why behind every client need. With over 20 years of experience developing enterprise-level software and building strong cross-functional relationships, Steve shares his expertise on how understanding the core problem sets teams up for success—and why creating a thoughtful plan doesn’t mean you abandon the need to be agile
Recommended
Transcript
00:00:00
Speaker
The thought that you can get together for a week with a room full of people and and get down to precise detail 12 weeks out, 16 weeks out, a year out is is honestly kind of silly. i can I can see forward maybe, you know, a month, two months with some clarity. But, you know, and then when I start taking steps forward, I learn some things. I adjust some things.
00:00:22
Speaker
certain things get thrown out other things come to the like like the fore and that's how it should be. Getting those things into your sort of cadence of this linear we're done with discovery now we build for six months and then we're going to unleash it on the public.
Introduction of Hosts and Guest
00:00:49
Speaker
Welcome to the Forward Slash, where we lean into the future of IT. I'm your host, Aaron Chesney, with my beautiful co-host, James Carmen. Our guest today is Steve Veridelli from Caliberty, one of our cronies. Steve has been creating enterprise solutions for over 25 years. Helping teams perform at optimum levels is his passion, and we're lucky to have him here at Caliberty as our foundation's practice lead.
00:01:14
Speaker
Hello, Steve. Hello. So today we said we were going to talk to you about Discovery, which reminds me, you know, I was watching Discovery with my son last night and it was a, it was a show on the ah humpback whales and he let out this loud yawn and I looked over at him and he was like,
00:01:43
Speaker
Well, I'm just speaking in whale and I'm like, well, you're doing very well. Very, very well. Wow. That was a lot of setup. there but Watching the Discovery Channel. i said Like that was. Yeah, that's wow. Wow. eron That was did like, how did you make that up on your own? you think if no No, I actually didn't. That came from somewhere else. Yeah. But you know, there's not, there's not a whole lot of dead joke material on, on the subject of discovery.
00:02:38
Speaker
Okay. So who's the Steve guy? Yeah. did Did he cover like everything in your intro? As he told us everything there is to know about Steve Ghirardelli and you're not, it's not Ghirardelli like the chocolate. If it was, I would not be working. Yeah. That's right. My chocolate fortune.
00:02:57
Speaker
and you'd probably be a few hundred pounds heavier. I would probably because it true yeah' would not be my spelt 172. Okay. What else? So what else do we need to know about, about Steve? Like what, what do you, what do you like to do, Steve, in in your spare time? and i My copious amounts of spare time. Uh,
00:03:17
Speaker
Well, I, I, I go to the gym just about every day. I like to get my exercise in, like to stay healthy if I can. Uh, I like to cook a lot. So, um, always looking for new recipes right now is soup season. So I probably make honestly two or three giant pots of soup every week because we go. Yeah. Well, you know, I gotta feed some people here. You know what I mean? I understand. So yeah. Yeah. Yeah. Yeah.
00:04:01
Speaker
um you're your motor vehicles it's true you know he's always had like cool motortcycles cool cars um well what was that thing that you had the um the the one that i think you just got rid of oh no i didn't get rid of it yet oh you didn't get rid of it yet what what is that thing it's called vanderho yeah yeah that thing is i mean it's that that screams
00:04:32
Speaker
ah motorized toy the the Yeah, I do. I do one enjoy driving quite a bit of all sorts of vehicles. that you just get rid of the
Steve's Journey into IT
00:04:49
Speaker
So what about your career? Like, how did you get into this field? Is it what did you go to college and study computer science or something like that? Are you traditionally? No, I am one of those weird cats that seem to be more prevalent in our field. And
00:05:08
Speaker
It's an interesting path. right like so I thought I was going to be in advertising because I really liked ah the creative side of it. right and I did that for about five years after college. I knew you were a mad man. Yeah. yeah um it yeah After a while, it was it's you know it's a bunch of sales. and While I don't really mind i like the excitement of getting new accounts and coming up with the creative plans and and and I used to love writing the script and doing the commercials and all that stuff. It just wasn't as fulfilling. And one of the, I did some work with a very small web development company called Magna Soft, like two or three people at this place, right? And they needed somebody to run projects for them. And I said, okay, ah because we had been doing some work with them and they were developing some some custom websites for us.
00:06:04
Speaker
So I started working with them being a more or less a project manager and got involved. Just, you know, we have deadlines, right? Staying up till three in the morning, trying to help any way that I could to get this thing out the door meant, oh, I kind of learned how to write a form.
00:06:22
Speaker
ah ah you know in HTML so learned a little bit there. It's one way that I could help. So I started doing that and realized like, oh, this is really cool, actually. You know what I mean? I i love writing a little bit of code and whatnot. So when it came time for them to say, hey, Steve, you know do you want to come work for us instead of what you're doing now?
00:06:46
Speaker
I made a deal with them and I said, look, if you teach me how to write code, I will come work for you. And I even took a small pay cut to do so. Absolutely a pivotal moment and the smartest thing ever did in my life, honestly. um And it it is one of the great things about it is when you really figure out what makes you tick and then you just run at it. It's amazing how that will transform your life. and being here at Caliberty as a foundations practice lead. I mean, I have the best job on earth. Honestly, I get to work with a lot of great people, helping them grow, helping them expand their skills, helping them find their passion much the same way that people helped me when I was younger. So, you know, could not be, uh, just more engaged, more happy doing what I'm doing. Yeah. And you and I have crossed paths with, uh, some legendary mentors.
00:07:42
Speaker
Oh, for sure. For sure. You know, it's funny when you have somebody that just believes in you, when even you don't even necessarily believe in yourself or know what you're capable of. Amazing things can happen in that space. That is definitely, of all the people, you know, I interviewed a lot of people for this company and like,
00:08:08
Speaker
different backgrounds, but like, you know, you hear a lot of like electrical engineering, mechanical, any kind of engineering leads into it. Right. Advertising is not up there on my list of no but the ones I hear a lot about. Exactly. That's unique for sure. ah Exactly. And you know, the the funny thing is, right, like, it's, the technology is, is I think, a common thing that we all share, right? Like, we love to play with new technology, love to get in there. And I did realize, when I when I started writing code,
00:08:39
Speaker
like a light bulb goes off and I'm like, oh, this is what I'm supposed to be doing. Like I need that puzzle in my head all the time, right? And James, you and I have talked about this. sometimes you fall in love with the problem. right and And there's nothing quite like it when you spend, man, a couple of days thrashing about a problem and it's beating you up, right? And you're frustrated. And and something my dad used to tell me is like, well, you
Problem-Solving in IT
00:09:08
Speaker
know when you're frustrated, it's a good thing because it means you're learning something. And he's absolutely right. you know And you have that moment where it might be you know two in the morning
00:09:19
Speaker
Any kind of you have this realization like oh wait i think i got it any run to your computer and it's one beautiful line of code that solves everything.
00:09:30
Speaker
And all at once you're thinking, why didn't I see this you know before? But wow, it's an amazing feeling when when you solve a problem, a really difficult problem. And one of the best things about what we do is the people and the teams. And it is why I'm so passionate about people and and leading those teams. Having a team work together on some really difficult problems and coming up with solutions together, nothing quite like that feeling.
00:09:59
Speaker
I will say though, when when that when that lightning strikes and you get that idea, make sure you towel off before, because waters and computers don't mix. I know you're excited that you've got the solution, but safety first. That's that's that today's PSA. Towel off before you put that idea into your computer. Close optional, as long as your webcam's off, Frank.
00:10:24
Speaker
Well, it's funny because what people refer to that as is is the Eureka moment, right? That's your Eureka moment. And that comes from Archimedes. He was taking a bath. And it's funny you did mention that because he the story has it. Yeah. He jumped out of the bath naked and ran out into the street. Eureka. i've Right. Like that's that's the story. So yeah a lot of times, too, it's it's when you walk away from the problem long enough for your the the tension of trying to solve the problem fades away. So you know, calming things, baths, showers, you don't rest it, you know, getting ready to close your eyes for the night. Any, you know, those types of, um, things that calm your mind all of a sudden that's, that's when the lightning strikes, right? Because that's, you've allowed yourself to relax and, um, you know, let, let go of that. I've actually used meditation before when I've got a problem, you know, to, to,
00:11:23
Speaker
clear my mind and and allow those those random thoughts and solutions to come in. It wasn't terribly effective, but you know but anything like that, sometimes and sometimes it's just talking the problem out. yeah ah right I know a lot of us have had like little figurines on our desk and stuff. where and we We literally called it rubber ducking because you would have like a little rubber duck on your desk that you would talk the problem to the rubber duck and in just in the act of verbalizing that problem, the solution comes to you. So it's another great technique for that. For some people, you know, they go fishing. For other people, they do other things like that. I've always found that like having, like you said, right? Something where you have to concentrate on something else.
00:12:17
Speaker
really pays off and letting those thoughts percolate, letting things come to fruition, right? For me, ah you know, to back to driving and and riding motorcycles, but for me, that motorcycle was, wow, therapy. You know, you you oftentimes get to the end of your day and your brain is just turned into a pretzel. That ride home, letting that wind just blow all the cobwebs out of my brain,
00:12:41
Speaker
had such a way of clearing my head and letting those things just sort of percolate. And sometimes it comes to you immediately. Sometimes it comes later, but it, it allows for that, you know? So I think anybody, anything we can do, you know, you, you can't grind away at it a hundred percent of the time. You know, you have to take those breaks. You have to refresh. You got to unplug a little bit. Well, yeah. Cause if you, if you're pounding away at it nonstop,
00:13:10
Speaker
Yeah. And not taking any breaks, your anxiety level will increase absolutely and that's going to form a blocker to new thoughts because all you're thinking about is, is the negative and you get the snowballing effect, right? Absolutely. Right. you like And then, and then little things that we're working, we'll start to break it and say, it's kind of weird how that happens, but you, you start overlooking simple things oh yeah ah in steps that cause more errors to happen.
00:13:39
Speaker
And when you take that step back and come back to it, and it can be just a five minute break. It could be just a walk around, you know, take a, take a quick five minute walk. We used to do that at sound gauge all the time. Hey, i let's go for a walk yeah and let's go stretch. Let's, you know, right something and, you know, go get a cup of coffee and and talk to a buddy or something like that. Take that little mental break.
00:14:06
Speaker
come back, sit down on edit, you know, you've got to re-engage, which is about a 15 to 20 minute exercise. And and sometimes through re-engaging, you're like, oh, well, I forgot to hit build, right? yeah How many times, honestly, cause you know, I mean, I'm not that bright. How many times have I looked at a problem that I was struggling with, read the same log message 10 different ways from Sunday?
00:14:33
Speaker
And you get stuck in that rut. We're like, that should just work. Why doesn't it work? It should just work. Try it again. And I'll try it a hundred times with the same damn result. it really You know, and you have to take those breaks, right? Like I, I had a, uh, one of my managers, uh, Jay was great for that. Like he would come to town and we would go for a walk for like an hour and just talk about anything other than work.
00:14:59
Speaker
And it was amazing, honestly. Like it it helped me so much to get out of my own head, to get a little bit of clarity of thought when I got back a little refreshed. I remember like Pedro, he used to put his head down every afternoon for like 15, 20 minutes and go to sleep. Yep. He took his siesta every day. Every day. And it is, it is amazing what that does for your, your mental clarity. when And we even got to the point where we knew Go take your siesta. go take your cs ah we come back to this in 15, 20 minutes. so he was brazil he was ah well He is Brazilian.
00:15:52
Speaker
um and and so it was ah It was like, yeah, in in my country, we take an afternoon nap. I'm like, all right. Well, then by all means, do what you need to do. right Right. I couldn't agree more, man. We we have such a weird ah notion of work ethic in this country.
00:16:11
Speaker
You know, and I was trying to, it's funny, cause I was talking to my son. He's an engineer at Rivian and he was getting a little stressed out, right? And I was talking to him, I said, well, tell me what your day looks like. He's like, well, I get up at six o'clock. I'm hitting my emails and doing this and doing that. And I'm like, whoa, brother, like you need to give yourself a little time to wake up. Like, I don't know if that means having a cup of coffee or going out for a run or doing whatever I go, but you need to like,
00:16:37
Speaker
Give yourself time to percolate those thoughts. you know like An old colleague of mine used to call it feet on your desk time, where he would say, put your feet up on the desk for 30 minutes before you get started and just let your thoughts come. And little things will come to you, right like, oh, I need to do this or I don't need to do that. did It just has a way of setting you up for the rest of the day.
00:17:00
Speaker
I was going to say that, you know, these, these techniques for trying to spawn ideas and keep your motivation going require a lot of self discovery. But, you know, discovery, discovery for ourselves, isn't the only thing that we need to do discovery for. We also need to do it for our products, right? We sure do.
Discovery in IT Projects
00:17:19
Speaker
We sure do. What even is discovery in our world? Like what what, what is that? I mean, discovery is, you know, trying to get your head around.
00:17:30
Speaker
you know Any of our clients right that come to us with problems that we need to solve for them, we're going to build something to solve it. right I tend to want to know what I'm building to some degree before I get started. Otherwise, we're we're just swimming in circles. It's a lot of rework. It's a lot of expense. It's a lot of just you know misdirection and lack of communication. and and ah you know a lot of bad things happen, not the least of which they spend inordinate amounts of money and don't really realize the value that they were looking for. So some period of discovery to flesh out like, oh, what what is it we're trying to accomplish here? Why is that important? And what does that even look like? right What does that vision look like? How do we deliver on that? Spending some time upfront to do that, you know and and I know for God's sakes,
00:18:25
Speaker
the Agileistas are going to scream, right? But Steve, that's not agile. Thank you, Aaron. Thank you. On cue. Perfect. On cue. But it actually is. I'm sorry. Agile doesn't mean you have zero plans.
00:18:41
Speaker
Agile means, you know, forget about the capital A agile, but being agile means being able to pivot when you need to. Having a plan doesn't negate that. Having a plan means I've thought things through, I've identified some risk, and I've probably thought about like, oh, if I run into this problem, how am I going to pivot? How am I going to mitigate that risk? Right?
00:19:03
Speaker
It doesn't mean I have some plan for the next 12 months and I blindly put my head down and do exactly what it says, checkbox by checkbox, and pick my head up and say, here you go, success.
00:19:16
Speaker
Yeah. And that's, and that's one of those things too, where when, whenever you find yourself asking the question, you know, is this agile, go back and read the manifesto, right? Does it blatantly say don't plan your work? No, it says that the best plans are around self organizing groups. Right. And so it even kind of leans into, yeah, you still need a plan. Yeah. It's, it's just.
00:19:44
Speaker
make sure you're self-organizing about it. Make sure it's iterative. Make sure that it's flexible enough to work with your change in directions that are going to come as part of the work process. Right. Be fluid, right? Yes. Yeah, absolutely. And I think a lot of folks would would would argue, I don't know if I necessarily agree with them, but I want to throw it out there, that like,
00:20:12
Speaker
The activity of that that discovery and and trying to uncover what problems are we solving and all of that sort of stuff, that that's a more creative endeavor than than is the software developments. There's almost like this tale of two projects. well All the work that needs to get done to create that quote, story, right user story, and then all the work to take the story from where it's been written down to working software. but What do you guys think about that notion that it's really, it's it's a it's a dichotomy there. is that Is that true? Is that a false dichotomy? What is that? I don't think it's a false dichotomy. I mean, there are different skill sets involved. There's different focus involved. Yeah. And I've worked both sides of that too. yeah um and And I know Steve, you probably have too, but where you do have to be in a different mindset because you're looking more at
00:21:06
Speaker
user experience and market needs and, and what sales wants and trying to leverage all of these different requests for what your project is solving. that's right And you're not thinking about the how, but the what, what do we need to put out there to solve these problems? And then that second, that second part of it is now I'm going to break that down into the how, and that's where I'm going to bring in my technology folks and It's like, okay, how are we going to tackle this, this, and this? And these are the most important things to focus on. You know, let's get a high level picture of what we're going to do. And I always use the analogy of we're not telling you exactly how to get there, but we're going to say we need to go from Detroit to LA. Yeah. You know, how do we, where, how are we going to start? Right. Right. We're going to, we're going to start heading West. That's a great start.
00:22:04
Speaker
yeah It's not even just the what, but like the why. Because you know if if we've got a team of craftsmen building the solution out,
00:22:16
Speaker
There are a million decisions every day that are made that aren't even vocalized, aren't even necessarily visible, but people make decisions every day on what direction to go, solutions and how to implement them and all those things. If they have a good understanding of the why behind the what, they're going to make better decisions. It's gonna be much more fluid. You're not gonna have as much back and forth and up and down the chain and and all of those misses that you typically have.
00:22:47
Speaker
And, and with that same vein as to why is, you know, what's important and why it's important. And if you can, if you can capture and convey those things to your team, that's going to, that's going to fuel those decisions because you're going to find out things that, you know what, I did it this way because, and they're going to be able to justify their technical designs, their architecture decisions in, in that kind of thing.
00:23:15
Speaker
and they're gonna be able to relate that back to your customer with confidence. Right. Any good, you know, the the whole notion of it's two tracks, right? That doesn't mean that we completely isolate ourselves and run down these two tracks independently without ever communicating. That does happen, but it's not ideal, right?
00:23:42
Speaker
Yeah, absolutely happens. The best that I think we've ever done this, Aaron, was on some of the projects that we've worked on together, where it really is, you know, you, if you're playing the role of maybe a product owner, you have a responsibility to express the value of what we're doing.
00:24:02
Speaker
As a technician, I have the responsibility of expressing the value of the things I wanna do, because sometimes they're different, right? And you'll hear engineers say things like, oh, they're never gonna understand this because it's so technical. They're never gonna let us do this. Well, then you haven't done your job on, because it's always this or that. Which thing do I do next? What provides the most value for our users and and the team? That's what I wanna be doing every step of the way.
00:24:30
Speaker
so you have to be able to figure out how to communicate together so that you can make those decisions together. and From the other side, from the product side, they're going to come with a lot of ideas that are going to be expensive to implement or the laundry list is just so long. and You've got to negotiate that scope and you have to be able to talk to your technical team yeah to you to slim that down and get an iterative yeah approach to how is this going to be delivered? So I always call that like initial product requests, the, you know, the Ferrari, like we want a Ferrari, we want fast, we want sleek, we want it red. Right. And then as you boil it in, in the technical teams, say yeah, well, we can build you the Ferrari if you want it in five years and spend a billion dollars. Yeah. We can do that.
00:25:26
Speaker
Now, but if we, if we understand what you're actually looking for, it's like, why do you want to fry? Well, I need to look cool going from home to the office. That's five miles away. Then it's like, okay. So the most important thing is to get from home to the office. yeah well ah Maybe we start off with a bike. It's a short enough distance. You can ride a bike, right?
00:25:53
Speaker
So let's start with that. It's got, it's got a couple of wheels. It's got a seat and a way to steer and get you there. Yeah. We won't release that out as the final thing, but that gets us to step one, you know, and then you start building off of that. Okay. Let's, let's make it four wheel bike. Let's let's put a motor on it, you know, and you start building it out and eventually you get something to where there's the compromise between it's not quite the Ferrari, but we have something that works that gets us from pointing to be that.
00:26:22
Speaker
um I'm okay with putting out in front of customers, and then you have a roadmap out to get closer and closer to that Ferrari vision of the
Minimum Viable Product and Feedback
00:26:30
Speaker
product. There are a couple of keys there on what you just mentioned, Aaron. like Number one, don't let perfection be the enemy of good.
00:26:41
Speaker
right put something out there that is of value, not not only because I want to establish that feedback loop with users, because um I'll tell you, they will have very different ideas on what should come next and what the value is of this or that. Projects that I've worked on in the past where we did not take that approach and spent millions of dollars on a whole raft of features for this platform,
00:27:09
Speaker
And then somebody had the bright idea to say, hey, we should probably do an audit and see like what features are actually being used. And we found out that 80% of them weren't even touched. Utterly mind-blowing when you consider how many years, how many dollars, and how much just just effort and brain power go into these things. And it really got me to the point where when you get this whole list of requirements,
00:27:39
Speaker
I start to question things, not only like, okay, how important is this compared to the other things? How much is that worth? Because a lot of times, like you mentioned earlier, Aaron, boy, that sounds great. It's going to cost this much to build.
00:27:54
Speaker
Is it really only representing like $10,000 in additional revenue, but we just spent a million on it? That doesn't make sense. Right. And some, and sometimes it's the short sightedness of, well, you know, this, this feature is not really important to us. And then you put it out in the market, you find out, Oh my gosh, they love this feature.
00:28:14
Speaker
and they want more of this. but So why wouldn't you say something like, let's do a little bit of discovery. Let's figure ourselves out. Let's figure out what like what's the minimum thing we can get out there to start getting feedback on. And let our users work with us to tell us what's valuable and what ideas they have on what they'd like to see. Because there's nothing worse than putting your head down for a year putting it out on the market and realizing, oh man, we were wrong on a few key things and nobody, but nobody wants to buy this thing. And it's happened. The best, one of the best experiences I ever had was James, when you and I were working together on, oh, I think we were talking about like in platform messaging or something. And we're sitting in this conference room with a bunch of VPs.
00:29:05
Speaker
Bunch of product owners, right? And they're there's they're all smart people trying to do the best they can, right? Like good ideas and whatnot. And we're sitting there taking a lot of notes and thinking, oh man, okay, I gotta estimate like eight million stories here to figure out what we're gonna do. And James here picks his head up and says something like this, like, ive I've got one question. Like what is the single most important thing you're trying to get out of this?
00:29:33
Speaker
And they said, I really just need to like notify users of this, right? Not all the bells and whistles on how you craft that message, not all the bells and whistles on like all these fancy bleeping sirens and things like that, but very simply, I need to get a message in front of people.
00:29:52
Speaker
and light bulbs started going off around the room. And all of a sudden, we could do this thing literally in like a couple of weeks. It was very simple at first, but what it did do was help them. How do I craft that message, right? if it Is it, I dropped this in a file somewhere and it gets picked up? Great, easy, right? So much less expensive than this grand vision that everybody was putting together.
00:30:16
Speaker
And sometimes it does take somebody to take a step back and think like, what's the goal and why, right? Yep. And that's, and that's a perfect example of that, that, you know, Ferrari scenario, right? They brought the Ferrari and we're like, Oh my gosh, this is going to be so expensive.
00:30:34
Speaker
but Well, they had visions of like, you know, red red satin jackets with Ferrari on the back and those little fingerless driving gloves and stuff like that, right? With the knuckles cut out, knuckles hanging out. Driving around with supermodels, yeah. And who doesn't? anyone who Who doesn't have that vision? with her it's it's If you play the game, if I won the lottery, right? Exactly. I mean, I want my life to be a white sink video. Why not? Yeah, sure.
00:31:04
Speaker
I wouldn't tell anyone about the memes that are going on. like there I wouldn't tell anyone if I won the lottery, but there would be signs, right? Right, yeah, there would be signs.
00:31:14
Speaker
but Right. So I got a question now. So yeah I know that this has kind of been that age old struggle, right? So product business people always want the Ferrari and they want all the bells and whistles and then they come to us. Sage wise software engineers and with you can't do that. Right. So that's a little, little self-serving for us. You know, I could throw myself off in that story, but am I being naive to think that I know that has been a problem. Has the software engineering industry somewhat moved past it? Are we a little more sophisticated now? Have product folks understood that notion of like, I got to get MVP out there, something out there that I can start start you know getting my users interacting with to learn more, you know take more of a hypothesis driven approach? is Are we there yet?
00:32:03
Speaker
I don't think we're there, but I think we're on the way in a lot of regards, right? Like at least when you say and MVP, for instance, James, more people understand what you're saying and why, right? and It's human nature though, right? Like when when I'm buying something, especially if I'm spending a lot of money on it, I do a ton of research. Like if I'm buying a car,
00:32:28
Speaker
I do a lot of research and I start looking at options. And of course, when I look at options, of course I want that option, right? Do I want a heated steering wheel? Heck yeah. Now I can't live without one, right? Do I want ventilated seats in the summer? Yup, I sure do, right? I mean, it doesn't have to be like that, but but when you see the list, of course you want those things. And it's human nature when you put so much time and effort into this vision And you'll see that a lot of times where they've got this whole list for the Ferrari of things that it needs. And we can't release until we've got all this stuff done. The M gets bigger and bigger. And for those of you that don't know, when we're talking about MVP, we're not talking about most valuable player, which is the standard. We're talking about most valuable product or minimally viable or minimal viable product. So, um,
00:33:24
Speaker
But that's him important, right? Like it it really does mean like, okay, what is the least amount that we can do to provide value and a return on this investment and start walking down that path and that path. And another reason like why having a discovery is so important because it helps you flush that out.
00:33:43
Speaker
When you get to that point, now we're doing the least amount possible to get value into the market, to get that turnaround time with your users, to get that feedback. And that feedback is everything. And for for the edge Least is out there, one of the most valuable things you can have when you start a project is a prioritized backlog. Absolutely. Right. And the way you get to that prioritized backlog is understanding your MVP yeah and what is the most important thing? What gets you to that first release? Cause if you don't have that first release and you're just working a backlog of stories, it's like, I have stories. I'm working them. I'm working them. When do you draw that line and go, okay, now let's release it for the first time. Right. Right. And you need, you need to have that kind of information in, in the back of your brain to go in, into just even to know, yeah, we're striding good. We're doing good.
00:34:40
Speaker
we we're we're You can do the things like burn downs and things like that, because now you know. And knowing is half the battle. ah It has a funny way, right? Like when when you when you do take the time, you start to realize because you're taking more time to break things down. And when you do that, funny things happen. I can release much more often.
00:35:10
Speaker
because I've broken these things down into pieces that provide value that stand on their own. And when I do that, that means, oh, guess what? Now when I release, I have less moving parts, less blast radius, less impact. I'm still putting value out there. But if something goes wrong, because it's so ah recent, I have a chance in hell of figuring out what went wrong very quickly. And our time to resolution is that much quicker.
00:35:40
Speaker
And again, it's the return on the investment. You know, somebody's writing a big check for this. I would rather start putting money back in their pocket as early and often as possible. You know, I had another thought on this as I was listening to you about, you know, understanding it upfront. This is, this is also like a shift left type of thing, right?
00:36:04
Speaker
That if if you shift the understanding to the left and get something that's testable that you can put out in front of a customer, a user, whatever, whatever your end audience is supposed to be, just as like a test, a paper test, it could be a Figma model or something like that. It's like, what do you think of this? Um, you can actually start getting feedback very early in your, in your process and who wouldn't want to know that, Hey, you know what? If we do build this feature, it's, it's, it's testing. Well, they they seem to like this. They can't wait for it to come out. I know we've done some of this with a UX testing early on. And I've actually been in the room when he usually goes, is this available now? Right. Right. Which is like the best question you could ever get. I was like, no, no, it's, it's, we're, we're, we're just testing this to see, you know, if it's something that's wanting to know that, yeah, we want this, this is great.
00:37:02
Speaker
you know, type of thing. The thing, you know, even more so than just being clear on what you're building through discovery, and identifying risk and how you're going to mitigate and things like that, you tend to start thinking about like, okay, what does success look like? And how do I measure it? And I give enough thought of that upfront to know like, okay,
00:37:25
Speaker
cant Is this testable? Can I test this? How do I make sure that I'm confident in the things that I'm putting out there? But also, what things do I need to measure? Let me get some benchmarks in place immediately and then gauge myself against that. So as we move, I know if I'm going in the right direction or if I'm losing ground, right? And make adjustments and a lot of it, the things that you think through during discovery,
00:37:51
Speaker
also tend to lead into discussions about, okay, how does this team work and what are our agreements and things like that? Because I want to be very fluid. I want to be able to pivot on a dime if I need to respond to market needs, if I need to respond to other risks that happen to come to fruition and things like that, right? it It really has a way of keeping you light on your feet, able to respond quickly to needs and changes and things like that.
00:38:21
Speaker
much better when you have a plan, but also realize like the first step we take that whole view changes and we may need to adjust. Also, you know, to to piggyback on on that. Thought is is part of going through that think exercise of, you know, how do we make this accessible? You get away from that. What I used to call the um the three-word requirement or the one-line requirement. so you know Some of us have been around projects a lot early on, you get like the spreadsheet of one-liner requirements. These are all the things we need in the product. yeah and It's like, what is this? What does this mean? and When you start digging into those individual things, it kind of forces them to go back and go, well, what was it did I mean by this? Absolutely.
00:39:15
Speaker
and they start to They, they start to think about, well, what do I really want? It's another light bulb moment. And that helps you then figure out where to ask the questions. You know, so you ask, what is this thing? It's a kind of a why question. Why do you need this? That's right. Um, you know, why is it important? Why, you know, you could start going through your five wise, you know, cause we always talk about the five wise. If you can.
00:39:46
Speaker
If you can get through a requirement with five wise, then most likely they understand it well enough to know that it is actually needed. Yeah. But if you can only get to one wine, you've stumped your, your person making the request is probably a garbage requirement. Or, or you know, just need some more thought that one more thought, right. It will, it'll be one of those either. It's like, well, you know what? We really don't need that. Let's toss that. Or it's like, you know what? Let me.
00:40:14
Speaker
Let me go ask some other people on this. Let me go think about this some more and I'll get back to you. Those are usually the two avenues those things take. and you know you you You mentioned something earlier and about shifting left and and it applies in so many areas.
00:40:30
Speaker
it It is not to say, okay, now we're going to do like you know four weeks of discovery upfront and then never do anymore because now we're in build phase, now we're in this phase. It's never quite that linear, right? right it It should be a continuous flow. I do want you know our product and those requirements to come a little bit before build,
00:40:55
Speaker
But those conversations need to happen together. We need to understand each other together. And we need to be able to say things like like we said earlier, right? Like, oh, I see that this is important to you and why and what you think it brings to the table for you. It's going to cost you $10 million. dollars And you probably didn't realize that because, you know, why would you, it's not your forte. Uh, maybe we can come up with a better solution together just by bringing it up and talking it through. And oftentimes we do, you know, yeah, it's all about moving feedbacks. Loop loops left, I think is really the key, right? So it it should go from like.
00:41:30
Speaker
a verbal discussion about a problem yeah to okay maybe let's draw some pictures on a whiteboard or on ah a napkin for goodness sake, right? And then let's do a Figma, as Aaron was saying, like you get higher and higher fidelity as you go along. Like if I was going to do a sculpture, well, how would you like a sculpture of a person with no arms? And and oh, it sounds pretty cool. Well, well um I was thinking maybe it might look like this and draw a picture. And then and I go get a big old slab of marble and I stand it in their foyer and say,
00:41:56
Speaker
What do you think of that, though? that's That's a lot, right? It's like, yeah, can we maybe half size that? right yeah then And then I start. car but it But it is it's about that kind of the low the lowest fidelity thing you can do in order to get feedback on what you're trying to do. Absolutely. That's where the sophistication, I think that's where people skip over those those intermediate fidelity steps and they try to go immediately into building software. Software is expensive to build. Figma is not, right? I mean, building Figma itself was hard, but but but building Figma diagrams and stuff like that, and I use Figma as an example just as a tool, but it's that rapid prototyping, the really low fidelity stuff, and it can be just a whiteboard. Yeah, and we've had lots of tools for doing that. We had Balsamic, and there was another one in between there that we used, but basically having some way of representing
00:42:49
Speaker
this is what we envision the flow of the user to be. and Usually, like my first crack at this is like a low fidelity flow chart type thing that's just boxes with words and a little user on the left-hand side that shows this is kind of the path that we want the user to take. and and Then I can take that information and start growing down and attaching these you know higher fidelity images to.
00:43:15
Speaker
and um to that point, you know, there's a lot of different tools that you can use and find one that works for you and and go with it.
Adaptive Planning vs. Static Planning
00:43:24
Speaker
It always makes me sad when I see, you know, a whole technology organization getting together for two days and working on a plan out all of the work for the next X amount of weeks. And then they go, oh, rah, rah, rah, go. And then there's There's nothing in, in a lot of times what happens is then you have your little, you know, small conference room meetings. That's like, yeah, all that planning that we just did the last, you know, three, four days a week or whatever. Yeah. That's not going to work. We need you guys to focus on this now. And it's like, why didn't we just do this little meeting?
00:44:06
Speaker
yes Instead of that giant spend to bring everybody in from out of town and get them all in the same room and get it catered for 120 people. exactly Why are you spending all that money when when these are the kinds of things that you should be doing for planning? Just by doing it continuously, have these meetings on a regular basis.
00:44:32
Speaker
You know, every couple sprints, let's get together and say, okay, yeah, what are the next things we need to be looking at? right but you know let's Let's start our discovery on this next important thing that we want to add to the product. Do just the right amount of all those things on a continuous basis, right? And it it has a way of focusing everything that your team does together, right? You're able to address, or you're able to pivot,
00:45:00
Speaker
you're able to have those conversations because the conversation honestly is everything, right? Because that's where the understanding comes from. The thought that you can get together for a week with a room full of people and and get down to precise detail 12 weeks out, 16 weeks out, a year out is is honestly kind of silly.
00:45:22
Speaker
i can I can see forward maybe, you know, a month, two months with some clarity. and But, you know, and then when I start taking steps forward, I learn some things, I adjust some things.
00:45:34
Speaker
certain things get thrown out, other things come to the light like the four. And that's how it should be. You know, we getting those things into your sort of cadence and how you do this practice makes a lot more sense to me than, you know, sort of this linear we're done with discovery. Now we build for six months and then we're going to unleash it on on the public. Well, and anybody that's old enough to or or had the Um, the experience of using the rational unified process as a, as a planning tool, right. We'll understand that as if you hold to the strict rules of what they say to do, you are not coding until every bit of your planning is done and you've exhaustively planned everything. Right. And anybody that's been through that process.
00:46:34
Speaker
realizes that by day and sometimes even day one. Yeah. By day through easily within the first week. Within the first week. Your documentation is complete garbage. Right. Because you've already had to pivot because of something unforeseen in your planning course. And and that's just it though, right? Like you you should be focusing on making sure that we're able to pivot as we need to be, right?
00:47:02
Speaker
you I mean, success is not checking off every box on this like thousand line spreadsheet and then picking your head up and saying, oh, cool, we're done. Yeah, I think the the natural byproduct, what we saw in the in the past when we did do that approach and we went through all of the hassle and investment and all of that and did all of that upfront work was when we saw, oh, this isn't what we want any longer, you know, three days into the project. We were like, hold on a second. We invested millions of dollars to come up with this plan. Exactly.
00:47:34
Speaker
Whether it's like that you know we can't give up on the plan we put down so just keep on doing it so in the end you're like forced to go down this road and finish it to completion and say we did what we all do you know we spent millions dollars to make this plan so we have to do it.
00:47:50
Speaker
at the end the end of the day it's not what the user needs it's not solving the problem that the users actually have so it was nobody's happy at that point yeah and that's not where the value is there's no value like who cares if you had some plan and you did every line item on that plan right.
00:48:09
Speaker
ah Customers don't it it's it's it's yeah it's it's more of a. it's more of a see what I can do you know for product owners to say, see what I can do here with this giant list of features. I know Steve and I are envisioning the same person in our head right now. I know we are exactly. I might be envisioning the same person. I remember being in a room with Aaron being yelled at by ah this person asking us to promise, can you now promise me that I will get every single feature on this thing by this date?
00:48:45
Speaker
Yeah. And I said, no, I'm never going to say something like that to you. I couldn't six weeks ago. I can't. li from yeah So, all right. So like alright we, we good well go ahead here. I was just going to say that that's not to say that, that, that process didn't give us some jumps. I mean, some of the documenting techniques, um, that were used in the rational use, my process are still viable tools for code analysis. Um, and, and diagramming.
00:49:15
Speaker
certain things, but, you know, use them appropriately and kind of pull pull those gems out and and use them as in your tool belt. any Any process. So like, you know, waterfall has such a bad name these days, right? But it's not all bad. Everybody gets all hung up on it. Like, are we agile or are we not? Or that sounds like waterfall or not. I really don't care. Be agile. Don't do agile.
00:49:43
Speaker
Right? Concern yourself with constantly improving and doing what's best at that moment in time. If something didn't work, you can always change it for the better. Get used to that.
00:49:56
Speaker
Well, Waterfall has a bad name on purpose. I mean, it's that it's iss true. like It's so bad TLC wrote a song about it. You know what I mean? like That's how bad Waterfalls were. You don't want to be chasing them. That's how pervasive that thought of how bad Waterfalls are is TLC. I think your timeline might be a little bit reversed on release dates. Just go with it. He's rolling. Is it over when the Germans bombed Pearl Harbor? no so No, it's over when we say it's over. James, are you are you proposing that TLC is... is where We're... We're the pioneers in our industry. former south We're the pioneers. They are. The original Edge Leastas. Oh, I love it. All right, so how do we know... Okay, we we know waterfalls bad. Yes.
00:50:53
Speaker
And of course, now agile is bad. Right. Don't say it. We're not going back to waterfall because everybody knows that's not it. And everybody's saying agile is bad. ah So this this whole notion of planning, we know that we we believe that it does pay benefits. How do you, how's the best way to balance it? When do you know the discovery that you're doing is it's enough. And and before you go into like.
00:51:16
Speaker
the bike shedding or boiling the ocean, whatever you know analogy you want to use. How do you know when enough is enough? and let's let's actually start let's Let's start slinging some code now. I think when you've gone through this process, you've talked it back and forth amongst you know your your engineers, your product folks, the business itself. right When you get your head around, okay, what are the what's our big outcomes that we're looking for and why? And what does that mean for us? You start to develop that kind of a roadmap to say, okay, this this might be the MVP that we wanna produce. Here's why it's the MVP. Here's the value that it's gonna bring for us. And here's here's the least amount that we can do to start providing value. Here's the least amount we can do to start getting feedback to help us course correct along the way.
00:52:10
Speaker
kind of like your point, Aaron, like, oh, we're going to California. I'm making a million decisions between here and California. yeah ah Giant ball twine. Gotta stop to see that. I want to and i want to see the 50 foot cowboy. you know ye Yeah, absolutely, man. But I think when you know enough that you can deliver a piece of value to that will also get you some feedback that's useful to help you guide your next steps. I think that's when you start. So there is honestly always going to be a certain amount of ambiguity and that's okay. It's a question for me, at least in my experience of how much are you willing to absorb of that? And that always comes back to, okay, what's the valuable piece that I'm putting out there and what does that do for us?
00:53:00
Speaker
If I think that that's worthwhile and that I can deliver a piece of value for the money that just got invested. And if that also leads me down a road of like, okay, now I have something that's meaty enough where I'm going to get some feedback. That's going to help figure out the rest of this as we go. Great. Let's start. Yeah. And, and with that, I totally agree with that thought of.
00:53:25
Speaker
I, this is, this is our starting point. This is what our first release looks like. If you have that idea, I mean, really that could be your, your stepping off point. We know what this first release looks like. Right. When you know what that looks like and you can speak to the, the what and why of that and tell the story and then be able to kind of foreshadow what the next things are.
00:53:53
Speaker
Right. But very loosely, it's like, and then from there, we can extend it out to this or this, whatever we see as our, you know, you can, you can lay out a couple contingencies based on feedback. Right. And, and have that conversation to everybody's in the room is nodding. If if you're not getting nods in, oh, this is great. When can we start? Then you, you might need to go back and and rethink some things. And it may take two or three times to go, okay, this is what we're thinking. It's like, yeah, I'm not sure about this. But you're having that, you're having those conversations before you actually built something. And so now you can actually pivot on your designs and your thoughts and in your feature sets based on just having a little bit of plan out out front.
00:54:48
Speaker
having that, and and those of you that and remember when triple eight did the triptychs, you kind of have your, your initial laid out plan of the road you're going to take. And you're like, yeah, but you know what, you're really going to want to go through here because you're going to want to see this. yeah right Okay. Let's go back and reroute that a little bit and and do that. Yeah. Um, yeah, yeah, yeah. and So, and you may have,
00:55:18
Speaker
an iterative process for this design to go back and go, okay, yeah, this makes sense. Let's go ahead and fit this into the MVP. But if we want to release by this date, we got to let something drop. So what's our least important thing that we can drop to get this in. And you start negotiating that timeline, uh, especially in, in domains where, where dates are important, you know, they're like, we, we all worked at Cengage together.
00:55:47
Speaker
That fall release was the most important one. In July, we had to have our stuff out the door so we could have it in instructors hands so they could start planning their courses for the fall semester.
Importance of Timelines and Negotiating Scope
00:56:00
Speaker
It was the most important thing. So we were time box into whatever we're going to do needs to release in July. So we had to do a lot of scope negotiation yeah on, okay, what's the most valuable thing that we need to get in here? And it's like, okay, if we put this in.
00:56:16
Speaker
This is going to have to come out or we're not going to hit this July date. Right. And once we started working with product and they started understanding this, things went a lot smoother and a lot faster to be honest. Sure. Yeah. One of my favorite exercises during those conversations is like, you know, take the, take the Ferrari analogy.
00:56:36
Speaker
I would draw a picture of ah of a skateboard. And people get mad at me. And they usually are doing a discussion. they're They're like mad at me when I'm doing this. But there's there's a method behind my madness, right? I'm i'm not advocating that, yes, the skateboard is is the solution. its But saying putting putting the picture of a skateboard on the on the whiteboard and saying, tell me why this isn't good enough. Articulate to me the reasons why you can't take a skateboard to work and you need it. Why can't this work for you? Oh, well, sometimes it's raining on my way to work.
00:57:04
Speaker
Okay, there we go. Now we got another understanding of what I'm understanding my users more. Or they may be like, no, I could probably use some exercise. Exercise is good. Maybe a bike will work or, you know, whatever, right? Like now you're starting to understand people a little bit more. They're, they're telling you more instead of like, well, I just, I just need this. You you know, the the salesperson said, wouldn't you love to have a car that goes 200 miles an hour that you can go to work with? but course I would. Yes. Sure. Why would do you need that yeah why wouldn't you, you can But that usually gets people really angry, like, are you kidding? Who would go to work on a skateboard? Like, well, I know, I actually know people that go to work on a skateboard. I sure would say yeah i know you know exactly who I'm thinking about, too. um But like, that those conversations are really good because it it tells them, you're forcing them to tell you why this isn't the minimal that they're looking for, right? it It fleshes all those things out, James, and and and something you just said,
00:58:01
Speaker
one of the other reasons why you want to figure out, okay, what, what is the minimal that I can launch with? What questions am I trying to answer? Cause oftentimes there's still risk involved and I need to answer some questions and de-risk. And sometimes that means putting something out there and doing some testing. Maybe you're doing AB testing, maybe you're doing any number of things to de-risk and figure that out, right? Yeah, absolutely, man. So how do you,
00:58:31
Speaker
How do you go about, you know, you mentioned the the risk in, you know, because there are some things that are very sensitive that you just can't have out there. yeah ah How do you address the impact of those types of things? So a lot of times in those conversations, as we're fleshing things out during discovery,
00:58:55
Speaker
I'm usually looking for not just, hey, what do you want to build and tell me more and let's get more detailed on that. A lot of it is like what I don't need to do, what I shouldn't do, what risk is out there and how do I address it and what happens if it does happen, right? Let's say the internet cuts unplugged, wow, what do we do then? You know what I mean? And what does that mean for us to our bottom line? What does it mean for user satisfaction? All those things.
00:59:26
Speaker
those Again, getting to those conversations like James just said, you you learn an awful lot about your users, about the business and and all parties involved. right So pulling pulling that together as much as I can. And again, like sort of defining how we're going to do this together. What's our cadence? How often do we talk and what are we talking about during those times? right
00:59:57
Speaker
pooling your product folks, pooling your engineering folks together for those conversations is key. It really is, right? To keep that understanding flowing, to keep each other abreast of any changes that's going on. Because a lot of times, let's face it, sometimes it's very technical things that will get you know that will ah hamstring you, right? And you need to pivot on those things alone. If you're not talking those things through, not only Like, for instance, like your product folks won't understand it, but they won't trust you. And I don't know how many times I've sat in conference rooms and listened to product folks say, well, engineering can't deliver. It's because they're not talking. It's because they're not talking and they're not including each other in those decisions.
01:00:52
Speaker
So that's, so in the inclusion now, obviously you can't include everyone because then you're, it's not a continuous flow. You that's a, that's a stop break in and and then have to start up again. So in the, kind in this kind of continuous planning, as I like to call it sir type of scenario, who should be in the room for discovery?
01:01:20
Speaker
So I, I typically will start that with, you know, a good product person or consultant and a technical lead. And who are they talking to? They're talking to, you know, our, our, our, our, the business or the users, if possible, to get any feedback we can get. Um, usually product person will represent that, but if we can take that one step further and make those connections, I'm always in favor of that.
01:01:47
Speaker
But isn't that the UX guy's responsibility to talk to the customers and find out what's best? ah Well, yeah. But if if so, you know, it's like, you know, how many degrees of separation do you want in that understanding? So I always like some of the best projects I worked on was where myself as a software engineer got to sit in on those sessions with like when we were doing accessibility for one of our products.
01:02:16
Speaker
Having a blind person sit there, come to the office and go through our product while I watch, rather than get the translation from a UX person or a product person, I may see things that I didn't realize. I may be able to ask questions that they didn't think of. I think that's really important to have those different areas represented in that discovery.
01:02:41
Speaker
Are you saying that users sometimes use your software or in in ways that you had not foreseen? Are you kidding me? do I know, it's crazy, right? yeah Do what I tell them to do. yeah I wrote this feature with this exact floating wind. That's how every user will do it, right? What are you doing? yeah and yeah but it But it does, right? like like those Those connections and that understanding, as much as possible,
01:03:10
Speaker
I like to eliminate barriers. I like to cut out the middleman and just be right there in the thick of it. That's a great thought. Yeah. for you i Doesn't mean the whole team, right? Although, you know, maybe you rotate them in and out. Maybe, maybe you do have a session where the whole team, it sounds whatever makes sense. Right. We would usually, um, when we involve technology with UX testing, we would usually have that revolve because I think there's benefit.
01:03:39
Speaker
for everyone on your team to at least see yeah one of these sessions where you're interviewing a user, seeing what they're doing, yeah because then they understand why certain design elements matter. Right. Absolutely. Absolutely. i would I'm going to coin Carmen's law right now.
01:04:02
Speaker
The length of time it takes for feedback, direct feedback from your users to the software engineering team themselves is inversely proportional to the delight that those users will have with the product. right It's Carmen's law, right there. It's one of them. but I take the requirements from the users to the developers. You can't have developers talking to users. I'm a people person.
01:04:25
Speaker
yeah But but there's there's a lot to be said for Carmen Voix here, right? Like the shorter iterations, the shorter feedback loops really do matter, you know? Really, really matter quite a bit. And and if you can get... ah I remember having this conversation with one of my teams,
01:04:47
Speaker
you know You did the typical two week sprints and that's fine. But they were struggling every deploy, right? Like, oh, we're tripping over the same rocks and we're doing this and we keep missing and blah, blah, blah. I said, you know what? Why don't we try something? Let's try going to one week sprints.
01:05:03
Speaker
And surprised by the amount of pushback I got because, well, we can't have this, you know, these meetings every week. When are we ever going to build anything? I'm like, well, yeah, but you're building less perspirant. So it shouldn't, you know, it all kind of balances itself out. And.
01:05:22
Speaker
You know, James, I've said to you before, right? Like nobody got improved their batting average sitting on the bench and it holds true here too, right? But more often we do something, the better we get at it. So all of a sudden, every week when we're doing a little bit of discovery, we got there quicker. When we're doing a little bit of retro, we got there quicker. When we're, you know, making these small gains and small improvements every single week.
01:05:47
Speaker
everything smoothed out. We got much more predictable. right i mean The goal, honestly, the goal is not to go as fast as humanly possible. It is to be predictable because then you can plan, the business can plan, and your users know when to expect things and will trust when you actually start delivering when you say you're going to deliver. right and If you look at historically all the success stories in the DevOps space,
01:06:17
Speaker
It's always those companies that have pushed themselves to do it more often, absolutely not less. None of them went in and go, well, we went for a one month release to see how much we could actually fit in and still do it. It was, no, we, we pushed the boundaries to do 10 deployments in one day, right? right And that's, that's where we found the growth. So the idea of, well, we can't do it at two weeks. How are we going to do it in one week? that's Right. that That's a common misconception because when you force yourself to do it in a short amount of timeframe, you start weeding out all of those unimportant steps, oh yeah things that can be deferred. Your process becomes very tight, very predictable, like you said, and you have the confidence in being able to say, yes, we can do that. Yeah. and And it has a funny way of, you know, if you have a very manual process,
01:07:17
Speaker
If I have to do that all the time, I'm going to find a way to automate that stuff. You know what I mean? If you're worth your salt as a developer, you're absolutely right. I don't like doing the same thing over and over again. If I don't have a lazy, or if you find out only two people on a, on a team know how to build a release, right you know, it's like, Oh, well we got to fix that because yeah, spread that love. If we ever, if if these people ever get promoted or moved to another team, we can't build a release anymore.
01:07:47
Speaker
Well, you know, while we're on the topic of like DevOps type things, or even, you know, product things, the more you can involve people in those things, it has a funny way of like, I've got some of our consultants right now who have realized, wow, I really like automating things and the DevOps side.
01:08:08
Speaker
So, you know, luckily we have a fantastic practice of platform engineering that I hook them up with. And I think part part of my goal in foundations practice is to help people find where their passion lies and to chase it. So, you know, I got an opportunity early, early, uh, when we started working together, Aaron, to work on a lot of like build an automation. What a flipping riot that was. I'm not. Oh my gosh. Yeah. I remember those days.
01:08:38
Speaker
That, as a matter of fact, I think that's what you were working on when we first met, uh, was, it was, uh, build and build automation. Cause we, we, there was no way we were doing deploy automation at that point in time. It just, it was just build automation and. Yeah.
01:08:53
Speaker
and because we didn't even have that at that time, yeah the whole continuous integration flow and stuff. It it's ah it was an interesting interesting space to learn and grow and really find that like I really love doing that kind of work, you know making that stuff to streamline so that it becomes non-dramatic to do it so that you can really, really focus on what value we're bringing with these features and what we're building and how do I do that better, right? Not how do I spend like a whole day trying to get the supply out the door and pulling the various levers and triggers to make it right again, right? Right. Yeah. So one thing that's it's pretty interesting, I don't know, the observation I've seen of the industry over the last probably three, four, five, maybe years is there's, you know, when we were working together at the same age before, like,
01:09:49
Speaker
There was this emphasis on you know kind of all scrunching everything into one body, one person,
Hyper-specialization vs. Full-stack in IT
01:09:54
Speaker
right? Oh, we're the full stack engineer, or I'm a DevOps. like I need to be able to do all of my build automation, deployment automation, front end, back end, database, all of that. I'm the unicorn. Everybody has to scrunch everything into one. And now there's like this it's almost like counterculture now in our industry of like, I just want to write some code. I don't want to know networking. I don't want to know Kubernetes. I don't want to know the, like, so there's like this now that's like the the pendulum is swinging the other way where people are just like, I just want to specialize again. I don't, yeah I love coding. I don't, I don't love Kubernetes. I don't love this other stuff. I don't love product. I don't love talking to people. Like it's interesting where we'll land on that, but there's absolutely that whole, you build it, you run it thing. The current, the the modern engineer,
01:10:40
Speaker
largely is starting to pull the retract and pull away from that. Well, and that's, that's where it's going to be important for, you know, people like Steven, a little bit myself to be able to put these processes in place. So they don't have to think about it. Right. Because if if I'm spending, if I'm spending 80% of my time doing operation side work and instead of you know, even split or even more so on the coding side. right And that process has to change. That's, that's your feedback loop. But that's the whole idea of shifting left. It's not to put more work on the developer is to raise the flags of this process isn't working. We need to change it. And it's amazing how much, when you focus on that for a little bit and get it streamlined,
01:11:29
Speaker
how much more throughput you have because you're not doing those stupid things. Yeah, repeatedly. Right. but Yes. but Well, it's funny because our ah software engineers, good ones, a certain aspect of your your your being, of of not wanting to trust anything kind of goes against this, like you just said, yeah the the motivation behind trying to scrunch everything into one body wasn't necessarily to try to get more work out of some people i'm sure there were some people that thought that way but by and large that wasn't it was more about him yeah yeah yeah it was ah it wasn't about it was more about empowerment and getting out of your way and allowing you to be more you have more agency in your day to day work. where
01:12:10
Speaker
But of course, we don't trust anyone. So we think it's the pointy-haired bosses that are you're just trying to make me do more work and get more out of me for and not pay me more money. We're a very cynical group of folks. it It really is, though, trying to put, at least the way I always looked at it, right? Because I remember having some teams where only one guy could write performance tests and only one guy can handle deployments. And I just kept thinking in my head, like, okay, if he gets taken out by a bus,
01:12:37
Speaker
We're dead in the water and that's not a good place to be. Right. Let's share that a little bit. You don't have to be the expert, but you should be able to like move the ball. Right. Right. If something happens, we should all be able to like be fluid enough that we can cover for each other where needed and keep moving forward. Yeah. You're running back, but you know, maybe you should watch the ball once in a while. Exactly. Right.
01:13:01
Speaker
and And it really is like, not that I want you to do everything, but I want you to be able to cover as needed so that, because let's face it. Yeah, James, you can write code. If that goes nowhere, there's no value in it. Code is a liability for God's sakes. Yeah. I wrote an article a while back.
01:13:20
Speaker
I love the title. I thought it was, you know, novel and awesome. Did you think it was brilliant? Yeah, I thought it was brilliant. it was It was something along the lines of like, when you're focusing on busyness and not the business. Right. So trying to make sure everybody's busy at all times, yeah instead of really focusing on the actual business. It is cute, isn't it? That's that's like a little fluffy kitty. I just want to you know, yeah, yeah cuddle with it Well, onenet but it's interesting I had a I had a client one time where we we suffered from this whole hyper specialization stuff where it was up um I'm the database guy and i yeah I'm the this person lady, you know, and and I do this and it was
01:14:02
Speaker
the stories would be like, it was like an assembly line, right? And if you, if your stuff got back and then it got to the QA people and all that backed up and we all just kind of sat around with our arms folded QA people, they need, they need to catch up with us and nothing could go across. So I forced the team. We're not, we're not all working. We're not working on multiple stories. yeah We're working on one story and the management was like, wait a minute. People aren't going to be busy all the time. yeah I know. I know. Right. Well, that's okay. The people who are going to stand around and not do anything.
01:14:32
Speaker
that but take care of that come, you know, annual review time. Remember that one of these people standing around not pitching in and like, Hey, can I help write some tests? Or maybe I can help with database scripts or whatever, right? And it it did help. and That hyper-focus, the whole team had to get one the whole thing across the finish line.
01:14:50
Speaker
And then we go to the next one. It did help build that because all what we would do is go go to the planning session. We were like, well, this is the story. These are the things that need to be done. And then we would all just scatter into our own little corners and never talk to each other again. So it it helped build that teamwork. And and but so sometimes you got to go extreme in your daily standups. You hear a lot less of I'm blocked waiting for this. Yeah, I'm blocked waiting for that. Exactly. I'm blocked until I get this. Yeah. Because it's like,
01:15:21
Speaker
We'll go get it. Yeah. Right. Go just do it, yeah man. Yep. You become more, um, self-reliant on being able to produce work. And that's, i and I agree that that is the value in being full stack and full stack doesn't mean I'm an expert in every single part of the stack. right I have the tools I need in order to be able to, to at least muddle through and get this out the door if needed in a pinch, I can help out.
01:15:51
Speaker
And I always, I always hate hearing the labels of, well, they're a backend developer or they're a front end developer, or they're a mobile developer. And it's like, no, I know enough to be able to help out when I need to. Right. So I don't, don't just throw a label on me. What's my forte? Yes. It's backend code. Absolutely. But I absolutely can put a screen on a mobile app.
01:16:18
Speaker
I absolutely can put a button on ah on a React page. you know it's there there's There are levels of things. It's like none of us started out being senior developers in anything. We all started out as junior programmers in something and that became like our first language, our strength. Then we expand our skill sets from there and we dabble in other things. One of the things that we have to do as technologists is to continue to learn new things, right? Well, that is usually pet project type work or, you know, doing a Udemy course or watching YouTube videos in order to learn how to use these different technologies. But when somebody comes to you and is like, do you know how to do this? It's like, I can probably figure that out. Yeah, for sure.
01:17:14
Speaker
There's more value in that than being, Oh yeah, I've done that for 10 years. Well, okay.
Continuous Learning in IT
01:17:20
Speaker
Well, and it is, you know, one of the best things about what we do for a living is that you learn something every single day and a lot like discovery. That's one of the reasons why I always enjoy the discovery process and because you're learning so much about the thing that you're going to be intimately involved with going forward. Right. Yeah, it's important.
01:17:44
Speaker
All right, well, we've gone a long time talking about many different things. Uh, and I want to bring up. And and hopefully this, this, this new topic doesn't send us off into a rabbit hole. It takes us another hour of conversation, but I wanted to introduce a new segment that I call I remember when.
01:18:08
Speaker
Oh, shall I get my Put on your comfy robe and your slippers and maybe a glass of bourbon. ah Reach back into the past and pull a tech memory that you thought was really cool at the time.
01:18:48
Speaker
So I can I can start. Well, of course you came up with the idea. So right. Well, well i I didn't I didn't I just thought of it when I was talking about it. There was this thing and I still have it here in, in my desk drawer. Cause I still think, Oh, this is still cool. Um, it was a USB device that would read the position of your hands and you'd be able to manipulate your desktop with your hands. yeah kind one and And I'm like, yeah, it was something like that. It was V something. but but And.
01:19:25
Speaker
And I'm like, wow, that's really cool. This could be a game changer. Used it for about half an hour and was like, Hmm, my arms are tired and it doesn't read my hand position very well. yeah So it's going in the desk drawer. So I'm, I'm thinking now that I'm talking about, uh, like, I don't know why I'm still hanging on to it. I haven't plugged it into a system for at least 15 years. Wow.
Gaming Setup Experiences
01:19:55
Speaker
Yeah, there, you know, there's a few things that come to mind. One kind of a similar thing. I used to play a lot of like, uh, racing games, right? On PlayStation, Xbox, you name it. And I was just infatuated to get like a wheel and pedals for this thing. Now, mind you, I did not have a desk set up like a lot of people do. I sat on the couch, right?
01:20:25
Speaker
And I finally get the steering wheel and pedals and get set up on my couch and it is just not optimal at all. Then I tried to set up like ah like sort of a desk, right? I had a ah chair that I moved to and had a board that I would put across the armrest and try that and that sucked.
01:20:48
Speaker
And finally, like i just i mean I used it maybe for a month here and there trying to make it work and it just never worked. And I realized like, no, you know what? This old controller of mine is exactly what I need because I can kick back, it's relaxed, it's comfortable. I'm not working extra for it. You know what I mean? Kind of like some of the Wii games where, oh, this is really cool.
01:21:11
Speaker
you know you want You want to do the the track and field thing and you can run. Well, do I really want to run? No, man. I want to sit on the couch and play this game. but You took the U-turn right before I did. I actually went farther with the stupid racing game thing. I went and bought one of those play seat things. Oh, no way. It's like, oh, yeah, yeah. I went all in and I didn't have like all the monitors around, like some things you see, but it, but I did buy a place in the sink, took up a whole bunch of room. yeah It was kind of cool for like, yeah right you know, forza was fun. Well, you know,
01:21:45
Speaker
Yeah, this is a good game. I wanted to build one of those things James. Yeah. Cause I, you know, you can find plans anywhere for like, you know, uh, plastic tubing and build one yourself and stuff like that. Uh, but wow, that's a lot of work. yeah I want one. That's like a convertible. So I can go from work mode to play mode and like, you know, like swing is swinging in the stuff so that, you know, the focus is more on the wheel.
01:22:13
Speaker
in joystick type set up. yeah and And then I can push it out of the way when I need to work. Right. Well, now we have VR so much, much easier. I don't know if I, yeah, the games I play don't support VR yet. No. and alex man I know it does. I was really hoping it did because it's, you know, like kind of a first person type simulator. It would be really nice if I could turn my head and look out the side. Yeah. Yeah. Yeah. um But.
01:22:44
Speaker
Okay, so we had, we got Steve's, we got mine.
Revisiting Data Structures and Algorithms
01:22:49
Speaker
What's James James? So you you put me on the spot and I'm trying to like think of it like the but the best thing I come up with is just like, what I've been doing on the side now is kind of just like going back to basics, man, like back to data structures and algorithms. And I'm like, I remember when like you're doing computing for computing sake, not business problem. Like you're like,
01:23:09
Speaker
I'm writing a bubble sword like whatever. right so um i've I i've really enjoyed that work. like I think I just did a red black tree or something like that. and It's like, wow, this was this was awesome. and The novelty of that in college and learning this yeah the first time was really cool. I really enjoyed kind of going back to the basics. I don't know if that qualifies for a remember when, but that's the best I could come up with on short notice. Yeah. i've I've done that with old old languages. like I remember doing all these things in another language is like, what if I tried to port them to a modern language? Oh yeah. I'm going to Kotlin. That's, so it's kind of me helping me learn Kotlin. and yeah's i'm doing Yeah. Yeah. Matter of fact, I've got a, I've got like some books that I keep close, like this one, the basic, basic book, which has a bunch of algorithms from basic. Um, and I'm like, Oh, what if I, what if I put those into like,
01:24:04
Speaker
React or Python or something like that, you know, and it's the same kind of, same kind of deal. I used to have one and I think I let somebody borrow and I never got it back, which was, um, technology interview questions.
Real-life Programming Challenges
01:24:18
Speaker
And then it had all of these like interview level, um, like ive got the green one cracking the interview, cracking the coding interview or something like that. Yeah.
01:24:30
Speaker
and in And it had things like, you know, write a bubble sort, write, you know, a prime factor ah factorization um application, write, you know, these things. And I'm like, these are really cool. And some of those are, those are great brain exercises for opening it up your' your thinking and, and maybe shining some light into some dark corners that you need a little more learning on.
01:24:55
Speaker
Well, it's kind of funny when you, like James said, when you go back to basics, right? like it I remember having a basic course in college and it was, I mean, I'm old, dude. So what I would do is have this five and a quarter inch floppy that I would write my program on. I would print it off on a spool printer in the student union. I would bring it in.
01:25:21
Speaker
And I remember going in and I had like, you know, a 15 page printout all connected on the spool and it didn't work. And I couldn't figure out why. Now, any modern IDE would be like, hey, you're missing a semicolon, right? But, you know, we didn't have that. And so I walk in, talk to my professor who was a really cool dude. You know, he's like a drummer in a band. He had long hair. He was really cool. I'm like, Tim, man, I'm stumped. I've been looking at this thing for like the last three days. I don't know what the hell's wrong with it.
01:25:50
Speaker
He unravels this whole 15 pages, gives it a quick scan. He's like, oh, right there, man, you're missing a semicolon. I don't know how he does it. Right. It's a late thing. You know, I just can't get this motor to work. I don't know what, well, the Carl here is a whiz with these movers. You know, what's, what's wrong with the car? I know what's wrong with it. I ain't got no gas in it. Yeah, yeah right yeah yeah theres ra got no gas and you got no gas in ah yeah there, you know, there are those things it was like, I ran into that just yesterday. Um,
01:26:26
Speaker
I was struggling like, why, why is this not running? It's, I mean, I'm looking at it. This is, it's a very simple, like mapper type thing. I've got, I've got the right annotation. I've got the the field in the right place and it's just not, it's still coming back. No, I'm like, look at it. I'm looking at, I'm looking at my, what the heck? And I'm like, all I needed to do was do a clean build of it. And I'm like.
01:26:52
Speaker
Oh, for Pete's sakes. You know, I was like, I spent half the day trying to figure out why this, you know, I'm putting in, in ah you know, like I'm debugging it. I'm like trying to go to the line and it's like, it's skipping over the line. Why is it skipping over the line? That makes no sense. I'm like, Oh, clean build. All right. Everything's green done. Good old map struct. That's right. But yeah, that's, uh, that's fun.
Lightning Round Questions
01:27:22
Speaker
Um All right now for the most important segment of the podcast The lightning round the lightning round
01:27:50
Speaker
All right, so the way the lightning round works is we're gonna ask you a series of questions. These questions are very important. So take your time, think about your answers. We will rapid fire these back and forth at you for about 10 questions, more if we think you deserve them. So James, would you like to start us off today?
01:28:14
Speaker
i Absolutely. When people stand up for a standing ovation, are you usually one of the earlier people to stand up or one of the later people to stand up? Later. Name a primate besides monkeys and apes. Chimpanzees. Excellent. Would you rather wake up to an air horn blowing in your ear every day or wake up and have to run four miles every day? Oh God.
01:28:46
Speaker
If I could wake up with an air horn and then run four miles, that would be optimal. That'd be the better. OK. So so it's there's no or there. It's an and. That's right. Sourdough or wheat. Sourdough. Better for you. If Tupac appeared before you right now, what's the first thing you would ask him? I'd say, did you hit him hard? Well done. Yeah, thank you, sir.
01:29:15
Speaker
Godfather or Star Wars? Godfather. We would have also affected Star Wars.
01:29:27
Speaker
were What type of milk do you put in your cereal? 2%. 2%. Favorite type of muffin? Blueberry. That's a hard-hitting question right there. I'm i'm glad that he had an answer that quickly. yeah that's Without a doubt. Do you Instagram your food? No, I'm old. I Facebook it.
01:29:56
Speaker
Oh, that's got to be the best answer I've heard. Yeah. Oh, climb a mountain or jump from a plane. Oh Jesus. Climb a mountain.
01:30:09
Speaker
Yeah. I don't know. Why would you jump out of a perfectly good airplane? Right.
Podcast Conclusion
01:30:16
Speaker
What's the lamest, I don't want to do air quotes because there's quotes here, dessert that people try to pass off as a dessert. i i Wow. That's a good question. I have no idea. I don't really dessert. But when people like bring out their dessert and you're like, Oh wow, that's, that's phoning it in, isn't it?
01:30:36
Speaker
yellow Jello Yeah. I think that's ah that's an excellent answer. Now for the hardest one of the round, say something cool. Ice. Excellent. Excellent. All done. All right. That concludes this episode of the forward slash where we lean into the future of IT. t Make sure you subscribe to this podcast for future episodes. I'd like to take thank our guest, Steve Baradelli. we're talking with us about discovery and all things related to that and then a couple things not related to it. I'd also like to thank my beautiful co-host James and all of our production staff that make this podcast possible. I'm Aaron Chesney. Thank you and stay curious.