Upkeep: Green Dashboards Don't Mean Your Plant Is Actually Running Better

Breaking the Bottleneck is a weekly manufacturing technology newsletter with perspectives, interviews, news, funding announcements, manufacturing market maps, 2025 predictions, and more!

💥 If you want to chat, feel free to reach out at aditya@machinafactory.org.

🏭 If you were forwarded this and found it interesting, please sign up!

This newsletter is brought to you with support from our partners: Jiga, Industry 4.0 Club, Ironloop, and T51.

You were a process engineer at a membrane plant watching technicians walk back and forth to desktop terminals just to log work orders. What was the moment you decided to build the fix yourself rather than wait for a vendor to solve it?

I wouldn’t say there was one big dramatic moment where I just woke up and decided, “I’m going to go start a company.” It was honestly more the accumulation of seeing problem after problem in the physical world, and at the same time realizing that if you wanted to actually build something in that world, everything moved painfully slowly.

I went into engineering because I loved to build. One of the things that hit me pretty quickly working in a manufacturing plant was that in the physical world, even when you know exactly what should be better, making a change can take months or years because you are dealing with real equipment, real processes, real constraints, real safety considerations, and a lot of inertia. At the same time, I was seeing all these very obvious workflow problems around me, especially for technicians and frontline teams, where the software clearly was not built for how they actually worked. Watching someone walk back and forth to a desktop terminal just to log a work order sounds small, but it reveals how disconnected the software was from the real job.

What pulled me in was that I’ve always enjoyed tinkering and building. Once I started teaching myself to code, my perspective changed entirely because, for the first time, I had a way to see a problem during the day, build a solution that night, and potentially release it the next morning. That was completely different from what I had experienced in the plant, where the cycle time for change was so long. So it was not really one moment so much as a growing realization that there were all these problems in the physical world worth solving, and software was the fastest tool I had ever found to actually go solve them.

You talk about shifting maintenance KPIs from “work orders closed” to “uptime impact on margin.” What’s the most compelling example you’ve seen of a customer actually tying maintenance data to revenue? And for companies earlier in their data maturity, what are the first steps to getting on that path?

One of the examples that stuck with me the most was visiting a manufacturing customer who said something insightful: they did not actually care about PM compliance or closed work orders as the end goal. That may sound surprising coming from a maintenance organization, but their point was that those metrics alone can drive the wrong behavior if you are not careful.

What they had seen over time was that when you tell teams the goal is to close more work orders or hit a certain compliance percentage, people get very good at optimizing for the check box, and you can end up in a culture where everyone is creating activity and green dashboards, but not necessarily creating better plant performance. In other words, you can make yourself feel productive without actually moving the business. What they did instead was tie everyone back to production outcomes, so maintenance, operations, and reliability were all fundamentally being measured against the same thing, which was keeping the plant running, driving throughput, and supporting the output of the business. Once you do that, the conversation changes because maintenance is no longer isolated, measuring success in a silo; it directly connects to what the business actually cares about: production, revenue, and margin.

To me, that is the right mental model. Maintenance metrics still matter, but they should be understood as drivers of business performance, not the end state themselves.

For companies that are earlier on this path, I actually think the first step is less technical than people think and much more organizational. Before you get into AI, dashboards, or complicated data models, you need shared goals. If maintenance is measured one way, operations is measured another way, and reliability is measured a third way, then by definition, you are going to create competing behavior. Maintenance reduces downtime now, reliability reduces downtime in the future by improving how assets perform over time, and operations is driving the day-to-day output of the plant, but all 3 functions really need to understand how they connect to the same business outcome. Once you have that, the technology becomes much more powerful because you are now using the data to drive a single scoreboard instead of 3 different ones.

You’ve said many plants are still running technology from the 1990s. What’s the single biggest non-technological barrier keeping them there, whether cultural, financial, or regulatory? And what go-to-market strategies have you found actually break through that resistance?

I think the biggest barrier is that the cost of disruption is much higher in the physical world. Because of this, people are a lot more cautious, and honestly, they should be.

In software, if you roll something out and it is a little messy, that is frustrating, but in a plant, a warehouse, or a facility environment, when something breaks, the consequences can be much bigger. You can affect production, create safety issues, or slow down a team that is already stretched thin. Consequently, many organizations stick with bad systems not because they love them, but because those systems are familiar, and the pain of change feels more dangerous than the pain of living with the status quo.

So yes, culture is part of it, but I think just calling it “cultural resistance” undersells what is really happening. The physical world moves more slowly because the downside of getting it wrong is real. That is why old systems survive way longer than they should.

From a go-to-market standpoint, the thing that works best is not leading with some giant abstract transformation message and trying to force it top down. What I have found works much better is finding the early adopters inside the business, the people who are naturally curious, ambitious, and frustrated enough with the way things work today that they actually want change. Every company has these people. They are usually the ones who are trying to do more, trying to improve things, and are constrained by old tools. If you help those people win, and you give them something that actually makes their life better and produces a visible result in the real environment, then they become your champions. That is when adoption starts to spread in a much more durable way, because now you are not selling hope, you are showing evidence.

UpKeep Studio lets local site managers build their own apps with a no-code AI builder. How do you prevent that from creating a new mess of fragmented, inconsistent tools across a multi-site operation? How do you balance flexibility at the factory floor with the need for enterprise-level structure?

That is honestly the whole point of Studio. We repeatedly heard from customers that every business and site operates differently, with unique workflows. Much of the software they receive forces them to contort their business around the tool instead of letting the tool adapt to the business.

Now with AI and modern tooling, it has become easier than ever to build apps or prototype workflows quickly, and that is exciting, but that is also exactly where the mess can start if you are not careful. The easy part now is building something fast. The hard part is everything that comes after: How do you deploy it into production? How do you ensure it scales? How do you manage permissions? How do you keep the data model clean? How do you prevent every site from spinning up random disconnected tools that break consistency across the organization?

That is why Studio matters. Yes, it gives teams the ability to build and move fast, but it does it on top of UpKeep’s architecture, infrastructure, data model, and permissions layer, which means you are not just creating random one-off apps floating around outside the system. You are building on top of a shared foundation and shared source of truth. In my mind, the balance is that local teams get the flexibility they need because they have unique workflows, while the enterprise still gains structure, consistency, governance, and scale.

That was the vision from the beginning. We did not want customers to have to choose between rigid software that does not fit their business and total chaos, where everyone builds their own disconnected tools. Studio is meant to give them flexibility without fragmentation.

As the U.S. pushes to reshore manufacturing, what does the maintenance technician’s role look like in a facility designed from the ground up to be highly automated and AI-integrated? For generative AI specifically, what guardrails should be built around “Autonomous Actions,” such as those in Nova, for the technology to be effective in safety-critical environments?

I think the technician becomes more important, not less. I believe much of the mainstream conversation around AI misses this point because it is too software-centric and not grounded enough in what work in the physical world actually looks like.

AI is not going to climb a ladder, it is not going to turn a wrench, it is not going to walk a site and notice something feels off in the way an experienced technician does. In safety-critical environments, there is still an enormous amount of judgment, physical presence, situational awareness, and real-world accountability required, and I think that remains true for a long time. What AI can do, though, is make that technician dramatically more effective by helping prioritize, helping triage, surfacing patterns earlier, automating the administrative layer of the job, and helping the team make better decisions faster. So instead of replacing the technician, I think what it really does is elevate the role and increase the leverage of the best people.

That is why I actually think this is one of the most exciting moments for people in the industry. The winners will be the technicians, supervisors, operators, and reliability leaders who learn how to use AI and software to augment themselves and move faster, not those who assume this technology is just hype and ignore it.

On the guardrails side, especially in safety-critical environments, I think the wrong way to think about autonomous actions is as unchecked automation. The right way to think about it is in terms of layered trust. There are some things the system should absolutely be able to suggest, some things it should be able to prepare, some things it should be able to execute with approval, and some things that should always remain gated by a human. You need clear permissions, clear audit trails, and a very clear understanding of what the system did, why it did it, and what data it used to reach that conclusion. In these environments, explainability matters, accountability matters, and human oversight matters. So I think AI becomes incredibly powerful here, but the near-term model is not “remove the human,” it is “make the human far more effective while keeping the right safety and trust boundaries in place.”

To contact Ryan, reach out to him on LinkedIn here. He’s always open to chatting and sharing valuable insights.