How to propose a new process without making everyone hate you

Working in BI/analytics and internal systems roles, I've helped design and build new processes and systems, big and small.

A common pattern is that a team approaches me with a question or report request. I'll dig into the process or systems used to create the data, and I'll uncover some gap in our understanding of how to use the data or make it useful.

This is particularly common for finance and accounting teams. They often sit in a different room or corner of the office (or in a remote world, different Slack channels). They speak a different language. They have a higher bar for output (accounting mostly can't be directionally correct). But they're forced to do gymnastics with data that's created by another team, for another purpose.

When this happens, you're thrust into a unique position. As you dig into sources and uses of data (and the processes around them) you're often the only one seeing the full picture! The tricky part is that you have to effect change across multiple teams and overhaul processes you don't own. Here's what I've learned to be effective.

Working in BI/analytics and internal systems roles, I’ve helped design and build new processes and systems, big and small.

A common pattern is that a team approaches me with a question or report request. I’ll dig into the process or systems used to create the data, and I’ll uncover some gap in our understanding of how to use the data or make it useful.

This is particularly common for finance and accounting teams. They often sit in a different room or corner of the office (or in a remote world, different Slack channels). They speak a different language. They have a higher bar for output (accounting mostly can’t be directionally correct). But they’re forced to do gymnastics with data that’s created by another team, for another purpose.

When this happens, you’re thrust into a unique position. As you dig into sources and uses of data (and the processes around them) you’re often the only one seeing the full picture! The tricky part is that you have to effect change across multiple teams and overhaul processes you don’t own. Here’s what I’ve learned to be effective.

Start by noticing, not solving

It starts with noticing a friction. Someone asks for a report to verify data or complains to me about something. I notice the same problem coming up in different conversations. Or perhaps related problems from different teams of contexts.

The instinct is to immediately start designing a solution (and I’ll often start designing a solution in my head) but the noticing phase matters. If you jump to solutions too fast, you’ll solve for your understanding of the problem, which is probably incomplete.

Talk to people without an agenda

Before I have any real ideas, I talk to a few people who touch the process. Usually a couple of people performing the work and a manager.

I never go in with a specific agenda: it’s never hey, I want to change the way your team works.

Rather I’m just trying to get an understanding. I do this pretty casually. Catch someone grabbing coffee in the kitchen. Shoot a quick Slack message. Or even if I run into someone in an unrelated meeting, I may ask for a few extra minutes to ask a question.

When I was working on generating leads from our data at Levelset, my desk was between the sales area and the kitchen. When I’d see a salesperson walk over to get coffee, I’d follow them and get a quick two or three minutes with them to learn or fill in gaps of my understanding.

Another trick is to talk to people who used to work on a role that touched that process. Now that they’ve moved on and have new context, they often have unique perspective.

Talk to people on different sides of the process. The person who submits requests and the person who fulfills them. The person who set it up and the person who inherited it. You’ll hear different pain points.

For what it’s worth, it takes me 6 to 12 months to really feel effective when I join or start working with a new organization. That’s the time it takes me to understand the business, understand the data and processes, and work on a few things to develop relationships with people who become useful nodes for solving problems

Make a crappy mockup

Once I think I understand the problem, I make something tangible. A Google Sheet. A boxy presentation. Something ugly and functional. Those who have worked with me know that I love to make crappy mockups.

I once built a mockup of a system by copy/pasting various Bootstrap components together in an HTML file. Later, because I didn’t have a designer on the project, the engineer just used my template to plug in data and make it real. It didn’t look half bad! In the LLM-era, it’s even easier to get good looking mockups. But make sure you’re not feeding people slop.

A mockup gives people something concrete to look at, because they’ll never read a project document at this point. Second, it gives people something to react to. Reacting to a thing is easier than imagining a thing.

My mockup usually includes three parts:

My understanding of the current process (so people can correct me if I’m wrong)
The problems it’s causing (as I understand them)
A proposed new process

I’m not precious about any of it. The goal is to draw a line in the sand so people can tell me where I’m off.

Why crappy? So that I don’t spend too much time on it, and so that people know that it’s just a sketch.

Float it gently

I send the mockup to a small group, usually the people I talked to earlier. Not proposal or spec (again, no one will read it). More like: “Hey, I’ve been playing with this idea in my head and wanted to sketch something out. Would something like this work?”

Comments in a doc work well for this. People can react to specific parts without the pressure of a meeting.

Get buy-in in the right order

If managers seem generally positive (even with feedback and changes), then I go talk to more of the people who actually do the process day to day. Same energy: “Hey, I’m playing with this idea…”

This order matters. You need managers on board to actually implement anything. But you need practitioners to tell you if it’ll actually work. Skipping either group causes problems.

Sometimes the people doing the work have concerns that the managers didn’t anticipate. Iterate on the mockup. The goal is to end up with something that the people who have to live with it actually want.

Then make it real

Once everyone seems onboard, I’ll put together a project overview and send it around. “Hey, remember that thing we chatted about a few weeks ago? Here’s more detail about how we’ll get it done.”

Ideally you’ll have a little excitement on the team (“Finally we’re going to fix X!”). Even if you don’t quite have excitement, people like to have input into the way they work, so you’ll hopefully have some champions.

Depending on the size of the project and the time to get it down, I’ll align resources and get buy-in.

Why this works

The whole approach is designed to avoid the two failure modes I see most often:

Failure mode 1: The top-down mandate. Someone goofball (like me) decides we need a new process, announces it, and everyone grudgingly complies (or quietly ignores it). No buy-in, no ownership, often no understanding of the actual problem.

Failure mode 2: The grassroots mess. Someone with good intentions tries to change things but doesn’t get the right people involved. They build something, announce it, and it dies because a key stakeholder wasn’t consulted or a critical use case wasn’t considered.

The approach I’m describing threads the needle. You’re leading with curiosity instead of solutions. You’re building buy-in incrementally instead of asking for it all at once. You’re making something concrete early so people can react to a real thing.

It takes longer than just announcing a new process. But the processes that stick are the ones people actually want to use.