Before I worked in software engineering, I worked with rural hospitals.

My first role was customer-facing at an electronic health records company, helping hospital teams adopt new technology. It was challenging in all the ways you might expect. These were busy people doing important work, often with limited resources, and we were asking them to change the way they operated every day.

If our customers didn’t take to the technology right away, it wouldn’t stick. And it would have been easy to assume the issue was the people using it; that it was their fault for being so resistant to change. But the longer I worked with those people, the less satisfying that answer felt.

Most of the time, people were not resisting technology just to resist it. They were trying to do their jobs inside systems that didn’t make the right action easy enough. The workflow asked too much of them, the tool didn’t match the reality of their day, and the “better” way technically existed but took too much effort to follow.

That experience shaped how I think about software, management, and engineering. When a workflow breaks down, instead of seeing it as one person simply not getting it, I see a system that wasn’t built for how people actually work.

My path into engineering started pretty naturally from there. I began querying data to help with my own workflows. Then I moved into more data science and data engineering work. Eventually, I made my way into software engineering.

What pulled me further into technical work was the ability to take something manual or repetitive and build a better system around it. There is something deeply satisfying about seeing a painful process become faster or simpler because someone took the time to understand where the friction was coming from.

Now in a leadership role as Director of Engineering at Paperless Parts, that’s still one of my favorite parts. But instead of only thinking about the system I need for my own work, I get to think about systems for larger groups of people:

• How does our team make decisions?
• Where do engineers get stuck?
• What slows them down unnecessarily?
• What can we build internally so people can spend more of their time on the work that actually deserves their attention

The work beneath the work

Those questions are also very connected to what we build at Paperless Parts.

Our customers are manufacturers quoting complex, custom work. Their teams are moving through technical files, customer requirements, pricing decisions, and a lot of institutional knowledge. Some of that work should take real thought; you want experienced people applying judgment to the parts of the process where seasoned judgment is critical.

Ariella and fellow Paperless Parts team members at General Stamping & Metalworks for a customer onsite.

But too often, that work gets buried under manual steps. If you have to search through too many places for the right information, click through too many screens, or carry too much of the process in your head, the system is making your job harder than it needs to be.

The same is true for engineers. There are parts of engineering that should take time. Creative problem-solving isn’t something you want to rush just because you can.

What I’m more interested in “rushing” are the parts of the job that drain our team’s energy without adding much value. Loosely defined workflow handoffs that create bottlenecks. Duplicating work (that could’ve been automated to begin with). Constant context-switching can make it hard to think deeply about the problem in front of you, and deep thinking is a pretty critical mode for the nature of our team’s work.

My goal is to help our engineers spend less time fighting the process and more time building. Before we chase any new technology or process, I come back to the same three questions:

• Where are engineers losing time?
• Where are we asking people to hold too much in their heads?
• Where would a better internal system help the team move with more confidence?

It’s similar to how we think about the Paperless Parts platform for our customers. We talk a lot about reducing clicks, but the larger goal is reducing the mental effort it takes to get to the right information and make a good decision.

Nobody wants to spend their whole day clicking around or waiting for things to load. People want to do the work they’re good at.

Using AI where it actually helps

There is a lot of pressure right now for teams to use AI. But “use AI” is not a particularly useful instruction on its own. It’s too broad, which can lead people to spend time applying AI to problems that were never really their bottleneck in the first place.

To stay practical about it, our team has been building what we call our DevX AI framework. This forces us to look at the actual friction points in our software development lifecycle and ask where AI can help. That might be testing, code review, or just helping engineers get a better starting point for research.

As a manager, I’m not in the code every day in the same way an individual contributor is, but I use AI quite a bit to organize my thoughts and speed up research. It helps me get through the first pass of certain tasks faster, which gives me more time for the parts of my role that require context, judgment, and working with people.

AI should create more room for thoughtful work, not eliminate the need for it.

Building for the future

This is an especially interesting time to be thinking about systems at Paperless Parts.

We’ve been on a mission since 2017 to help manufacturers quote faster and more consistently. That is still core to what we do, but since our customers and team have scaled dramatically over the last 9 years, the problems we’re solving are more complex. We’re working with larger manufacturers who have teams that operate across multiple sites and systems, which changes the questions in front of us. Today, we ask ourselves questions like:

• What systems should we be putting in place now that will get us to where we need to be in 9-12 months?
• How do we connect different parts of the product in a way that is thoughtful, but not overbuilt?
• How do we build in a way that will allow us to take advantage of AI—securely—as we mature, without betting on things that aren’t ready yet?

The better path should feel easier to follow

I often still think about those rural hospitals from my first role. Too many businesses who struggle to scale are just stuck inside systems that make their work more difficult than it needs to be. Good technology should make people’s lives easier and make better paths easier to follow. That’s true for our customers, and it’s true for our engineers.

The work I’m most excited about right now is building the systems that give people more time for the parts of their jobs that require real thought and care. We’re passionate about building a culture that keeps people creative and curious, and that means making work feel a little less painful than it has to be.

If you want to help build that culture, we’re hiring a Principal Software Engineer. Visit our Careers page to learn more.

—

Ariella joined Paperless Parts in 2023 after holding roles in healthcare technology and software engineering, where she built experience across customer-facing systems, data analysis, automation, and engineering leadership. She holds a Bachelor’s degree in Biology, Brain, and Cognitive Sciences from the Massachusetts Institute of Technology (MIT)