I've Sat on Both Sides of the Table. Here's What Nobody Tells You.

I have been the person waiting six weeks for a report I needed yesterday. I have also been the person who built the report and watched it go unused.

I have been in meetings where leadership described what they wanted and the technical team heard something completely different. I have been on both sides of that conversation. Sometimes in the same week.

That is not something you get from a degree or a certification. It is something you get from years of being in rooms where things fall apart and having to figure out why.

The Non-Technical Side

Early in my career, I worked in roles that were operational. Program management. Strategy. The kind of work where your success depends on information you usually do not control.

I remember sitting in a meeting, trying to make a case for reallocating resources to a program that was underperforming. I had the anecdotal evidence. I had the gut feeling. What I did not have was numbers that told the story in a way that ended the argument.

So I asked our data team for a report. And I waited. And when it came back, it had everything I did not need and nothing I did. Not because the team was bad. Because I did not know how to ask for what I actually needed, and they did not have enough context to fill in the blanks.

That experience repeated itself everywhere I went. Higher ed. Nonprofits. Startups. The same dynamic. The people closest to the work could not get the information they needed in a form they could use. And the people who controlled the information could not get clear enough direction to build the right thing.

The Technical Side

Then I moved into roles where I was building and managing data and insights teams. And I saw the exact same problem from the other direction.

Program staff would come to us with requests that sounded simple but were not. "Can we get a dashboard for our enrollment numbers?" Sure. But which enrollment numbers? Which programs? Over what time period? Compared to what? For what decision?

Those follow-up questions are not nitpicking. They are the difference between building something useful and building something that sits in a browser tab nobody opens.

But here is the part nobody tells you. When you are on the technical side, asking those clarifying questions can feel like you are slowing things down. People came to you with a need, and instead of just building it, you are interrogating them. Some teams stop asking after a while. They just interpret the request as best they can and start building. And that is how you end up with a technically solid product that completely misses the point.

The Space in Between

What I learned from living on both sides is that the problem is not on either end. It is in the middle.

There is a space between "what the organization needs" and "what gets built" where nobody is in charge. The business side assumes the technical team will figure it out. The technical team assumes the business side knows what they want. Both assumptions are wrong, and nobody realizes it until the thing ships and the reaction is, "That is not what we asked for."

But it is. Word for word, it is what they described. It just has nothing to do with what they actually needed.

That space in the middle does not have a job title. There is no department for it. Most organizations do not even recognize it exists until they have burned through two or three failed projects and start asking harder questions.

What I Stopped Doing

At a certain point, I stopped trying to be on one side or the other and started working in the gap.

I stopped waiting for perfect requirements. Instead, I started sitting with teams and watching how they actually work. What do they pull up when a decision needs to be made? What do they wish they had? Where do they waste time?

I stopped building what people asked for and started building what they needed. Not because I thought I knew better, but because I learned to ask the right questions before anyone touched a keyboard.

And I stopped assuming that technology was the answer. Half the time the answer is a redesigned spreadsheet, a different meeting cadence, or a ten-minute conversation where someone explains what the data actually means and what the options are.

The best solution is the one people use. Everything else is decoration.

Why I Started Forte

I did not start a data consulting firm because I saw a business angle. I started Forte because I kept watching the same problem destroy value at organizations that could not afford to waste it.

Every organization deserves what the big companies take for granted. The ability to make decisions based on evidence instead of guesswork. Someone who can sit in the gap and make the data work for the people who need it most.

That is what Forte does. We find the mismatch. We build the infrastructure. We close it. And we do it at a scale that makes sense for organizations that cannot afford to get it wrong.

Find the problem. Build something better. Keep pushing.

---

Aaron Buchanan, MPP, is the founder of Forte AI Solutions. Before starting Forte, he spent years across higher education, nonprofits, and startups as a Teach For America corps member and staff, a data team leader, and an operational strategist. Meet the founder or book a discovery call.