The Work Exists Somewhere. That’s the Problem.

Over the last few weeks, I’ve been talking to engineers, project managers, and operators across construction, utilities, energy, and consulting teams.

I’m not going to describe anyone’s internal process. That’s not the point.

But the pattern that kept coming up was pretty clear:

Most teams do have systems.

They have email. They have spreadsheets. They have PDFs. They have shared folders. They have project tools. They have enterprise systems. They have meetings. They have check-ins. They have some tracker someone made because the official process didn’t quite cover the messy reality of the work.

The issue is not always that the work is missing.

The issue is that the work exists somewhere.

And “somewhere” is doing a lot of damage.

The current state of work still lives in people’s heads

One thing I keep noticing is that many teams already have a way to record work.

That is not the same as having a clear current state of the work.

A spreadsheet can say a task exists.
An email can say someone sent an update.
A PDF can contain the latest detail.
A project tool can show that something is open.
A meeting can mention what needs to happen next.

But when you ask, “What is actually going on with this right now?” the answer often depends on a person.

Someone remembers the latest context. Someone knows which file matters. Someone knows which vendor update changed the plan. Someone knows why the schedule is not actually as clean as it looks. Someone knows the thing that never made it into the tracker.

That is the part that feels fragile.

The work may be documented, but the real operating picture is still half in tools and half in people’s heads.

A lot of work only stays alive because someone keeps bringing it up

This is the part I think people outside these industries underestimate.

Important work does not always fail because someone ignored it. It fails because nobody keeps it alive long enough.

A maintenance issue. A project update. A subcontractor response. A vendor delay. A document revision. A compliance task. A field note. A testing item. A purchasing step. A customer clarification.

These things can all be technically captured somewhere and still fade out of the team’s attention.

Not because people are lazy.

Because everyone already has too much context to hold.

So the actual system becomes informal. Someone remembers to ask. Someone brings it up in a meeting. Someone pings the person again. Someone checks the spreadsheet. Someone searches the email thread. Someone knows which PDF had the latest note. Someone has enough experience to know that this “small” update probably matters.

That works until the person forgets, gets busy, goes on vacation, changes teams, or assumes someone else has it.

Then the work doesn’t disappear from the tools.

It disappears from attention.

“We have a tracker” is not always reassuring

I used to think the main question was whether a team had a tracker.

Now I think that is only the first question.

The better question is whether the tracker reflects reality.

A tracker can be technically correct and still not tell the whole story. It can show that a task exists, but not why it’s blocked. It can show that something is assigned, but not whether the person has enough context to act. It can show that a file was uploaded, but not whether the latest version changes the decision someone is about to make.

This is where teams end up doing the annoying coordination work around the tracker.

They still ask:

“Is this the latest?”
“Did we hear back?”
“Was this already handled?”
“Who has the current status?”
“Did that change anything?”
“Are we still waiting on someone?”
“Was that update included in the plan?”

That is the hidden work.

And it is not rare. Asana has reported that 60% of knowledge workers’ time goes to “work about work,” meaning coordination, searching, status updates, switching tools, and other activity around the actual skilled work.

That number sounds high until you talk to teams that spend their day rebuilding context across inboxes, spreadsheets, documents, and meetings.

The annoying part is not always doing the work

A lot of the people I’ve spoken with are not complaining about hard work.

They expect the work to be hard.

The frustrating part is when the work becomes hard for dumb reasons.

A document exists, but it’s painful to navigate. A status exists, but it’s not in the place people actually check. A note exists, but it’s buried in a thread. A decision happened, but the reason is unclear later. A follow-up exists, but only one person knows where it stands. A change exists, but the people affected by it are still working from the older assumption.

This is not really a “we need more software” problem.

Most of these teams already have a lot of software.

It is a “we need the current state to be obvious” problem.

Because when the current state is not obvious, teams spend time proving things to themselves. They re-open old threads. They compare files. They ask for updates. They wait for replies. They hold another meeting. They rebuild the story.

McKinsey estimated years ago that better communication and collaboration could raise productivity for high-skill knowledge workers by 20 to 25 percent.

That stat gets quoted a lot, but the practical version is simple: a ridiculous amount of time gets burned just trying to keep people aligned on what is true right now.

The real risk is when people keep moving on old context

There is another version of this that is more dangerous than wasted time.

It is when the team keeps moving, but the context changed behind them.

A vendor date moves, but the schedule still assumes the old one.
A customer clarifies something, but the internal plan still reflects the earlier version.
A file gets revised, but pricing or coordination started from the previous copy.
A policy changes, but the team keeps following the old checklist.
A subcontractor response changes the picture, but someone else keeps working from the first assumption.

That is when work gets expensive.

Not because the update was impossible to find. Not because nobody cared. But because the update did not make it into the operating picture quickly enough.

Companies do not just need places to store work.

They need the work to stay current while people are making decisions from it.

Search helps, but only after you know to search

A lot of tools make it easier to find things.

That is useful. I’m not arguing against search.

But search has a built-in assumption: someone knows they need to look.

That is often not how these problems happen.

The issue is not always, “I searched and couldn’t find the file.”

Sometimes the issue is, “I didn’t know that file changed in a way that affected me.”

Or, “I didn’t know that email changed the thing I was about to do.”

Or, “I didn’t know someone else was waiting on my part before they could move.”

This is why better folders, better search, and better dashboards can help but still not fully solve the problem.

The company can have the information and still have people acting without the relevant context.

There are stats that back up the document side of this too. One M-Files-related survey reported that 96% of workers had problems finding the most recent version of a file or document, and 45% found searching for information and documents time-consuming and difficult.

That lines up with what you hear in real conversations: people are not always lacking information, but they are constantly fighting to know which information matters right now.

Copilot starts after someone knows there is a question

One question I got was basically: how is this different from something like Copilot?

I think the distinction matters.

Copilot is powerful once someone knows what they need help with. You can ask it to summarize a thread, draft a document, find information, clean up notes, or help make sense of something in front of you.

But a lot of operational work breaks one step earlier.

Nobody asks about the vendor update because they did not realize it affected the schedule.

Nobody asks about the revised file because they did not know the team was still using the older assumption.

Nobody asks whether a subcontractor confirmed the latest scope because everyone thinks someone else already handled it.

Nobody asks whether a testing item is blocked because the status technically exists somewhere already.

That is the gap Pertava is focused on.

It is not trying to replace Copilot. It is trying to catch the important change before the team even knows what question to ask.

The product we’re building

Pertava is not meant to be another place where work goes to sit.

The idea is closer to this:

Companies already have information spread across emails, documents, portals, trackers, shared drives, and internal systems. Pertava watches for meaningful changes in that business context and helps bring the current state to the people who need it before the work drifts too far.

For construction and engineering teams, that might be changes across drawings, specs, RFIs, addenda, vendor notes, project files, or emails.

For utilities, energy, reliability, maintenance, procurement, or operations teams, it might be status changes, vendor updates, purchase-order context, testing progress, equipment-related notes, compliance updates, internal handoffs, or other work that gets painful when the current state is scattered.

The exact workflow changes by industry.

The underlying issue is similar: the team needs a clearer view of what is going on now, not just a record of what happened somewhere.

The goal is not to replace the tools people already use

This is important.

I don’t think the answer is “rip out everything and use one magical system.”

That is not how real companies work.

Large companies especially already have systems, security reviews, support expectations, procurement constraints, and internal processes that are not going away overnight. Even smaller companies have ways they are used to working.

So the goal is not to replace email, Teams, spreadsheets, PDFs, Maximo, SAP, Dynamics, project tools, document systems, or whatever else a team already uses.

The goal is to make the current state easier to trust across them.

If something changed, the affected people should not have to discover it by accident.
If something is waiting, it should not rely entirely on one person remembering to bring it up.
If a decision depends on a newer piece of context, the old assumption should not quietly keep driving the work.

That is the layer we care about.

The thing I keep coming back to

The more conversations I have, the more I keep coming back to the same line:

The work exists somewhere. That’s the problem.

It exists in the email.
It exists in the spreadsheet.
It exists in the PDF.
It exists in the tracker.
It exists in the meeting.
It exists in someone’s head.
It exists in a system that technically works but is painful enough that people avoid it until they have to use it.

But operations do not run on “somewhere.”

They run on the current state being clear enough for people to make the next decision.

That is what we are building Pertava around.

Not more noise. Not another inbox. Not another dashboard people have to babysit.

Just a better way for teams to keep important work from getting buried across the places it already lives.

This builds on the same broader problem behind the cost of missed project-change follow-up, but from a different angle: not just what missed follow-up costs, but why the current state of work is so hard to trust in the first place.