Are you a technology professional looking to connect with like minded people?
We have a thriving community of CTOs discussing these episodes and more.
Click HERE to set up a call and learn more about becoming a member.
About The Speaker:
Casey Kleindienst is an expert at Supply Chain Management and current serves as a Management Professor @ Cal State Fullerton
Check Casey out on LinkedIn: https://www.linkedin.com/in/ckleindie…
Nickolai: [00:00:03] Welcome back to the studio, I am your host, Nickolai Walker. Our in studio guest today is Casey Kleindienst. He’s the director of Supply Chain and Management. Now, in our last episode, we left off, where talking about the first 100 or 90 days of a new employee at a company. So I want to pose this question to you, Casey. The first 100 or 90 days of a company comes with, as you said, the benefit of no responsibility for what was done prior to you and because of the trust placed in you and your reputation. But post one hundred days or 90 days, whatever, during that time, you’ve made decisions that can now be judged. So can you tell me what’s more beneficial as in regards to tracking success in the first 100 or 90 days? Is it metrics or time or both?
Casey: [00:00:47] Whenever possible metrics are helpful because they take the subjectivity out of it or push it over to the side, there’s always going to be subjectivity . And there’s just a little piece that’s objective that says, you know, this is some measurable results that we did even in your business. And any service time is the most important metric, time. So start time, ending time, cycle time, wait time, move time. And if you can apply, time measurements, to everything, you’re going to clearly understand performance. You’re going to clearly understand the health of your business, your activity and time is this universal metric. You know, it’s it’s better than and it’s better than dollars. It is because it doesn’t rely on the nature of the process. And you don’t even have to know the process if you understand it’s performance based on time. And so the way to start that is just is is take the most important things and start tracking them relative to time,
Etienne: [00:02:05] Because time is the unit that doesn’t go away. Time will be there tomorrow
Casey: [00:02:12] And it doesn’t care what the nature of the work is. And here’s what I know about time. If you crush time, you know, even in project management, they call crashing the schedule crash And project management is a technical term. It means I took the critical path and it shortened it when you crashed the schedule. That’s the most important thing there is in project management to shorten the delivery time. It’s more important than meeting the budget because projects have something waiting for them at the promised delivery day, and that’s the stakeholders are waiting to take on the results of the project. So knowing that you can be you can apply that to any any small process, large process it thinking process, you know, creative process and see how it performs based on time. And you can’t just make decisions on single data point. So you’re going to have to start looking at a connection of trends. And I can appreciate that, you know, 3M, the post it company, they’re competitive advantage was their innovation in materials that nobody else could match. 3M then wanted to squeeze more profit out and so they used Six Sigma as a way of managing research and development, you know, creative thinking. And it failed. Couldn’t do it because their isn’t creativity isn’t necessarily linear.
Casey: [00:04:03] You don’t know when you’re going to become creative. You have to give that space. And you know, you budget for that. You set aside research money and then that’s where that money goes. It’s like training. You don’t necessarily get an effectiveness out of all training, but you still do it because you need to message what you know and you need to try to develop people. And so we spend money on training. And that isn’t that dollar for dollar exchange. But research is for me is you know, it’s what big companies do because just on the scale of it. So when someone says you can’t put a clock on me developing this, that’s true. But even artists know how long it takes to paint a canvas. You know, a friend of mine that I’ve known since we were teenagers, has tried working as a janitorial supervisor, but he didn’t care for the working you know So he learned to paint. And so he’s been supporting himself for the last 60 or 50 years painting. And he gets like $15k for a canvas. And his stuff is everywhere and but he knows how long it takes to paint something.
Etienne: [00:05:48] But but there is this tremendous. Resistance in the software development space to. Give estimations of how long things will take,
Casey: [00:06:01] It begs the question, does the developer actually get done then and could he have worked on it longer? Because, you know, it’s like, Where does the artist know that that was the last brush stroke? Once you do this , you could just go at it instead of fighting this. go with this and say, you got 18 hours. Give me the best you can do in 18 hours. After 18 hours, you’re done. Give me the product no, then make it nine. Make it 2 whatever you think. Give me the best you can do and what you think is a reasonable amount of time because we’ve got nothing to lose.
Etienne: [00:06:54] I feel like I feel like what you’re saying. I can hear those words, but I feel like they don’t apply to software development. Maybe the size of the canvas is the issue. So it’s almost like every ticket or every bug or every thing that has to be worked on is me writing lines of code after I have assessed the situation, which I use my creative brain to then solve the problem. So the size of the mini canvases is not really known ever. I have to assess the issue. Maybe then I decide on the size of the canvas, which is still a something that can’t be perceived with the eye. It’s still a estimate. Then I start writing the code and I realize, oh shit, I’m running out of canvas, I need more canvas. So it’s like every single thing, every single ticket, every single task that. We’re giving to our developers is just you just cannot estimate and yet there’s this constant drive for when will it be done? Why isn’t it done yet? How do we get it done?
Casey: [00:08:12] Because here’s the thing. Nobody knows where the last brush stroke is. So you’re going to define it. You’re going to see. You tell this artist, OK, I want you to paint something for me, but I only want a thousand brush strokes after a thousand I don’t want anymore. So give me your best. Because you can. Because you can you have every right to do that. There’s nothing there’s nothing holy about about somebody that is creating art when you need, you know, a house painted. I don’t want a mural. I want my house painted. There is no art listen. There is no art. There is no art. We do everything as well as we can. If you start creating art and you set that aside from pedestrian work, then then you will never have art.
Etienne: [00:09:08] And also and also, depending on the pressure, you might compromise on your solution.
Casey: [00:09:15] You could you could do that. You could correlate it to gardening projects. What I’m saying is that person, you can determine whether that person is capable or not by watching him when he’s not coding. That means that he’s going to reveal himself on how he codes by all the things he does when he’s not coding and how he does one thing is how he does everything. And that’s what I mean about there is no art. We do everything we can. An artist doesn’t become creative in front of the canvas and then he’s not an artist after that. He’s an artist because he’s you know, that’s in his mind all the time, and that’s a hard thing to learn. That’s a hard thing to understand, because we think that , you know, we step up to something and all of a sudden we can change who we are into this, you know, some some skill. Well, it doesn’t work that way. So you know, because what you want to do is you want to really assess your people, you want to assess your capability.
Etienne: [00:10:36] Ok, but this is where I think the this is where I think the correlation is made, which I think is the incorrect one, which is correlating software development projects to construction projects. When really you should correlate them to gardening projects
Casey: [00:10:58] Now, are we talking about bells and whistles, are we talking about functionality because you know, which is this fully featured, are you you know, are you applying like German engineering to it? When it doesn’t need German engineering. It needs no engineering, it just needs to be done. If it takes that long to do, what you’re saying, you don’t even know how long it takes. So some days you projects come in quickly and other days your projects take longer or is it all longer?
Etienne: [00:11:48] No, I just think that it’s generally all longer. I don’t think it’s ever I think that we are in a difficult situation where the simplest of tasks are just more complex than even the coder thinks it is. That’s very seldomly oh, I mean, it happens where something is just so well architected or specked out or API’d that it’s like, oh, wow, I thought I was going to spend all day on this. This just took me one line of code. Right. I think that that does happen, but in general, even when I sit down to say, OK, I am going to to now work on this piece that is important for the project and is generally more complex than I think it is, or more more things have to be considered.
Casey: [00:12:42] And are you less competitive because of this or do you find this across the industry that every software development department has the same thing going on?
Etienne: [00:12:57] I think it’s across the industry. I think systems are becoming more complex. It might be becoming it might be that it is becoming simpler to launch a MVP’s or software frameworks, but you’re doing it in a more complex situation. So if we used to be coding for a green screen Unix dumb terminal, you’re now coding for multiple devices across multiple languages. I mean, it’s so I’m just saying that you launched your startup, you get your success. Great. You’ve tested that 100 people have tried this and 99 of them want this and are willing 98 are willing to pay for this. But now you have a situation where now you’re staffing more people, you’re wanting to go further, you’re wanting to actually take the validated idea, and you now want to turn it into a sustainable, growing scaling business. And that’s where I think. You know, now you’re hiring experts to uncover the complexities of what it does, what it takes to get things done, you know, if you were Amazon and you had one warehouse, awesome. But now you’re you have tens of thousands of warehouses and now you’re trying to predict which products are going to be in, which are going to be ordered, in which region, so that you can pre stock those warehouses you’ve just made. You know, it’s easy to do two days shipping to people that are within two days of a one warehouse radius. Now now you’re like, oh, I’ve got to grow this. I’ve got to make this a real thing. Well, now you’re doing it across the planet. The same simple value proposition, but just to more people and the problem has now become infinitely more complex. But you’re the CEO, you’re the CEO who says, well, you made it work for one warehouse. Why can’t we make it work for ten thousand? Well, no the problem is it’s not the same problem at all.
Nickolai: [00:15:14] Thanks again for joining us here in the studio. And thank you to our guest, Casey Kleindienst, as a director of Supply Chain Management. And he is also currently a professor at Cal State Fullerton. So if you need more information on him, check out his LinkedIn. As always, please check out 7CTOs dot com and please subscribe to the podcast here available in iTunes. As always, we will see you next time with another interview from Mr. Kleindienst.
Are you a technology professional looking to connect with like minded people? Sign up to get connected with 7CTOs!