This is Technology Bytes, episode 154 for February 15, 2026.
Technology Bytes is a microcast where I share brief bytes on interesting technology.
Enjoy, and here we go.
Once again, I’m going to talk about something that I don’t know a lot about.
I do know how it impacts me and my job, but it’s still a tough subject, and that is software development.
In this case, it’s software development in support of a production environment.
I work in an environment where we are putting logos on items, garments, hats, backpacks, and then shipping that to our customers.
So that is the production environment in which I work, and all the software that we use to do those jobs is written by our development team in-house.
That is the cool thing about where I work.
I really like the fact that we kind of control, not kind of, we do control our own destiny, and so I am able to go to the CTO and say, this is what I’m thinking about, improvements that might help the software do more for our production environment, and then we get a chance to talk about it, I get a chance to write it up, and then it gets put in the queue for work to be completed at some point.
And so here recently, our company has hired a second dev person with some pretty significant experience so that our CTO can really look at the innovative part of our business, how do we push it forward, and then this other gentleman can look at how do we make incremental improvements to what exists to help production do more.
Both development paths will help production, there’s no question about that, but there are things that are in place right now that should take smaller amounts of development time to help us take smaller steps in improving production, while the innovative steps might take a little bit longer and we may have more impactful changes to production based on the way we’re trying to go as a company and what the software dev team does to support that.
How does it look?
Does the dev team drive production or does production drive the dev team?
Well, they’re very closely related.
We will sit in a room as a management team and say, here’s ways that we think we can improve production.
We want to try to shorten lead times, we want to try to do whatever it is that we’re trying to do, improve our throughput, and then work on efficiencies after that.
And what does that look like?
And we kind of talk through that and then the dev team looks at those goals and what we’re trying to accomplish and says, what does the software need to do to support the goals of the company?
So very much hand in hand because the dev team is involved in the initial conversation, they go off and start working on the software, we give them input on what they develop, and it is very much a hand in hand type operation.
As of late, development has been relatively slow.
I think most of that is because the stabilization, the incremental steps of improvement team is led by a person who has only worked for us for a month and doesn’t fully understand how the company operates in the production environment.
You know, we take them through it, we try to explain it, and so he’s getting the picture, but that causes development to slow, where if my CTO was doing the development or one of the other gentlemen in the team that has been there for some time, the development time would be significantly shorter.
But they are working on a different mode of development than the support stability incremental improvement team.
Recently, the management has made a decision, the upper management has made a decision to have the dev team focus on one part of the process from start to finish and get all of the development necessary for that operation to work at the level that we expect it to.
While I understand that that seems like a pretty good idea, if the entire development team is in that environment and unable to help in the stability and the incremental improvements, then we are twiddling our thumbs or working things manually outside of the system to make the improvements that we feel are necessary, not knowing when the development team is going to catch up to us.
I really like the two-prong approach where we’ve got the innovative side of the house, and I think them looking at process steps end to end makes a lot of sense.
It really gives them a real focus.
But if the stability and incremental improvement team is pulled into that as well, then we are stuck with underperforming software.
And that makes me a little bit frustrated as the person in charge of all of the production at the company.
I’m struggling with trying to get that picture.
Thankfully, this beginning of this week coming up, I’ll have some time to talk to our CEO and president and owner and hopefully get a bit of a clearer picture.
I’m going to fight for some of the small increment things that I need because we’re collecting data from the production environment that is not being recorded properly.
And when we are asking our managers, when I’m asking my managers to manage production based on data, I feel they need the best data that we can provide to them.
Now, I don’t think we want the development team to work on the final picture of the data.
I think that’s going to come through those real concentrated look at processes from beginning to end.
But I think taking what we have and making it good and making it correct, which I don’t think takes a lot of development time, is going to be significantly helpful to the managers who are asked to manage those processes.
So it’s a really give and take.
I’m a little bit frustrated sometimes.
I get what we’re trying to accomplish and I like that as well.
I think there’s somewhere in the middle that I think we could meet and be more productive.
So the interesting thing that has happened just recently is my boss has asked me to read a book called The Phoenix Project.
And The Phoenix Project is exactly about how the development team manages their process procedures and work and throughput, much like we do in production.
So it’s interesting that I’m reading a book about how to develop software properly, how to schedule it, how to manage it so that we get the most throughput, just like I’m trying to do in the production environment at the time that we’re making this change.
It’ll be interesting to see as time goes how that all plays out.
Well, that is all I have for today.
If you have comments, questions, or suggestions, you can send them to technologybytesatmarigfamily.com.
As always, I want to thank you for listening to the Technology Bytes Microcast, and I look forward to the next time we are together taking another bite of technology.
