Looking for CTO/Tech Leader perspectives: How do you drive engineering rigor or is there a need in non-software orgs without alienating functional teams? (UK, Manufacturing)

Posted by Neither_Soup6132@reddit | ExperiencedDevs | View on Reddit | 11 comments

This might not be the perfect sub for this, but hoping to get some insights.

I’m based in the UK, working in a manufacturing organization that doesn’t sell software or operate like a tech company. Recently, the company brought in a new CTO to oversee both the IT and Data teams. The CTO comes from a fast-paced startup/product background and has a very product-centric mindset—something that doesn’t quite fit with how things typically function in our industry, where the focus is more on operational efficiency, compliance, and continuous improvement.

Early on, they made comments about both teams being “cost centers,” which has rubbed people the wrong way—especially considering the significant impact we’ve had on cost savings. There are clear examples: • We automated a quality tracking process that used to take a full-time technician several days a week. • A digital maintenance scheduling tool we built in-house saved a site from needing to hire additional coordinators. • IT also implemented a centralized inventory scanner integration that reduced loss and shrinkage by 30%.

Despite these wins, the CTO has been pushing for the org to hire dedicated software engineers—but hasn’t been given the budget. That’s led to mounting pressure on existing team members—many of whom use scripting languages like Python or VBA in Excel—to take on formal software dev tasks. The expectation is creeping into areas like version-controlled deployment, test coverage, documentation, and architecture standards.

When folks express hesitation, the CTO frames it as resistance to “growing beyond their comfort zone” or “not wanting to do more than what’s in the job description.”

The thing is, most of us are open to growing—just not without proper support, compensation, or recognition. Right now, simple automation is being escalated into full SDLC territory, and there’s no clear plan or structure for how that transition is meant to happen. We’ve gone from being a support function to being expected to ship production-grade software.

Morale is taking a hit. A few people have already left, and many are quietly job hunting.

Would love to hear from other CTOs or tech leaders—particularly those in non-software organizations like manufacturing or logistics: • How do you introduce software engineering best practices without alienating teams who weren’t hired as devs? • How do you make the case for growing technical capability while still respecting role boundaries and existing value? • Is there a better way to bridge this gap without burning out functional teams?

Appreciate any perspective.

[-]

colmeneroio@reddit

Your CTO is making classic mistakes that kill technical initiatives in traditional industries. I work at a consulting firm that helps non-tech companies modernize their operations, and this "Silicon Valley mindset in manufacturing" approach fails constantly.

The "cost center" comment was incredibly tone-deaf given your clear business impact. Calling teams that delivered 30% shrinkage reduction and automated quality processes "cost centers" shows they don't understand how value creation works in manufacturing.

Here's what actually works for introducing engineering rigor in non-software orgs:

Start with incremental improvements to existing workflows. Don't jump from Python scripts to full SDLC. Add version control to existing automation, then basic testing, then documentation standards. Build up gradually.

Respect domain expertise over pure technical skills. Your team knows the business processes, compliance requirements, and operational constraints. Pure software engineers don't, and learning that takes years.

Create hybrid roles with proper compensation. If you want manufacturing technicians to write production software, pay them like software engineers. Otherwise you're just adding responsibilities without recognition.

Focus on business outcomes, not technical purity. A VBA script that saves $200K annually is more valuable than perfectly architected software that takes 6 months to build.

Build internal champions gradually. Find people who are excited about leveling up their technical skills and invest in them first. Don't force it on everyone simultaneously.

Your CTO needs to understand that manufacturing isn't a startup. Compliance, operational stability, and risk management matter more than move-fast-break-things mentality.

The talent exodus you're seeing is predictable. Most experienced manufacturing technologists won't tolerate being pushed into roles they didn't sign up for without proper support.

Consider having senior stakeholders push back on unrealistic expectations before you lose more good people.

[-]

Electrical-Mark-9708@reddit

This is a great answer! OP needs to ask why they’d bring in a CTO who is a startup/product type personality. The CEO and board have a motive.

[-]

Tacos314@reddit

"cost center" is such a red flag. I hate when I see a company put development as a cost center when it's latterly the source of income

[-]

Duathdaert@reddit

It's a manufacturing company. They manufacture stuff and sell it. By definition anything that's not involved in the sale of those goods is going to be a cost centre in that kind of organisation where the software isn't the product. Like it or lump it, it's just reality.

Debate the merit of telling teams they're a cost centre sure. But reality is that as far as the organisation is concerned they are and they will therefore expect to see a direct contribution to reduced costs, maintenance etc etc

[-]

severoon@reddit

The "cost center" comment was incredibly tone-deaf given your clear business impact. Calling teams that delivered 30% shrinkage reduction and automated quality processes "cost centers" shows they don't understand how value creation works in manufacturing.

I wonder about this take. A given part of a business is either a cost center or a profit center, this is just expressing a fact. The context in which it's said could mean different things to different people, but that's neither here nor there. If the employees were looking for something to take umbrage at, this could suffice even if it wasn't meant that way, but in this case management is in a bit of a bind—if the listener is determined enough, they're going to find a way to get offended no matter what you say.

I tend to think that it's likely it was just meant more as a statement of fact, which OP appears to agree with:

Early on, they made comments about both teams being “cost centers,” which has rubbed people the wrong way—especially considering the significant impact we’ve had on cost savings.

…then proceeds to list all of the ways in which the teams are, in fact, cost centers, effective though they may be.

The implication may be what folks are responding negatively to, but that may not be justified; it may be something they don't want to hear even if it's intended to give insight into how management is thinking (which is something employees often say they want … until they get it).

That implication is that there is a tacit assumption that scaling investment in a profit center of the business will scale revenue, while scaling investment in a cost center generally inversely scales with total costs. IOW, if investing 100% more in a profit center results in 10% increased revenue, and there's no ceiling on that math, it often makes sense to put as much as you can into the profit center. If doubling investment in a cost center halves costs, you quickly get to a point of diminishing returns. This is a fact of life when you work in a cost center, and something everyone should be aware of. No business is ever going to say "okay, it's time to go buck wild!" That's a thing that can only happen in the profit centers.

We’ve gone from being a support function to being expected to ship production-grade software.

This is an absolutely unreasonable expectation. There's no way a team with the background you describe is ever going to be able to create a reasonable software shop and all that entails without some kind of guidance from subject matter experts. It's a separate skill set that requires a lot of experience.