Why do founders lose visibility as the company grows?

Direct observation stops scaling past a certain size. Below it a founder sees the work by being near it. Above it, everything they know arrives through a described version of the work — a status update, a review meeting, a dashboard — produced on a schedule by someone with a reason to describe it in a particular way. The loss is structural, not a failure of attention or of the team.

Why don't status meetings and dashboards fix the problem?

Because they are records of description rather than records of work. A status deck reports what someone assembled the night before. A weekly review reports what people chose to raise. A dashboard is green until someone sets a threshold, and nobody sets thresholds. Each measures the reporting layer, so each is most inaccurate exactly when the team is busiest and the accuracy matters most.

What makes a record of work trustworthy?

Three properties. First, it is a byproduct of doing the work rather than a separate task, so it does not compete with the work for time. Second, absence reads as absence — a day with nothing recorded means nobody worked on it, rather than disappearing into a backlog. Third, closing something requires evidence attached to it rather than a declaration that it is done.

Why do project tools make visibility worse over time?

Most generate work: recurring tasks, reminders, alerts and digests that arrive whether or not anyone acts on them. Generated items accumulate faster than they are cleared, the queue passes the point of being readable, and people stop opening it. The queue then reports on itself rather than on the work, and the tool has quietly become another reporting layer.

GoWarm Work · The argument

Why you stopped knowing what's happening in your own company

There is a size at which a founder stops seeing the work and starts receiving descriptions of it. Nobody announces the crossing. You notice it later, usually during a week when being wrong about something was expensive.

A GoWarm Work position paper · September 2026

Why do founders stop knowing what is happening in their own company?

Because direct observation has a ceiling. Past roughly forty people, almost everything a founder knows arrives as a description of the work rather than the work itself — a status deck, a weekly review, a dashboard, a project tool holding last month's dates. Each of those is a record of reporting, not a record of work. The cause is structural: recording was separated from doing, so the record decays fastest exactly when the work speeds up.

The crossing

At twelve people you know what everyone is doing because you are in the room. At twenty-five you have lost the detail but you can still reconstruct it in a morning of walking around. At some point after that, and it comes sooner than anyone expects, that stops working. Not because the team got worse, and not because you got lazier. Direct observation has a ceiling, and you have hit it.

Nothing breaks on the day you cross. The change is silent, which is why it is usually discovered in retrospect, during an expensive week.

What replaces observation is description. From that point on, almost everything you know about your own company arrives as an account of the work rather than the work: a slide someone assembled last night, a sentence in a review meeting, a number on a dashboard whose definition you have never checked, a date in a project tool that was last edited in March.

You did not lose visibility. You swapped a record of work for a record of people describing work, and nobody told you the exchange rate.

This is worth being precise about, because the usual diagnoses are wrong and expensive. It is not that your managers are hiding things. It is not that the team lacks ownership. It is not that you need to be more hands-on, which mostly produces a founder who is a bottleneck in six places at once. The problem is that the act of recording work has been separated from the act of doing it, and everything that follows is a consequence of that split.

The four substitutes, and what each one actually measures

You will have been sold at least three of these. Each is reasonable on its own terms. None of them is a record of work, and it is worth naming exactly what each one does measure.

The weekly review

Measures what people chose to raise in a room with their peers and their boss in it. Selection is the whole mechanism. The items most worth hearing are the ones nobody wants to be the person who raises, and those are precisely the ones that do not make the agenda until they are unavoidable. You are sampling the team's judgement about what you want to hear.

The status deck

Measures the assembly effort of whoever built it, usually the night before, usually by asking four people who each reconstructed their week from memory. It is a genuine artefact of something — of a reporting process — but the thing it describes has already passed through two rounds of summarisation before it reaches you. You are reading a compression of a compression.

The dashboard

Measures whatever the underlying systems happen to capture, which is rarely the work and often just its financial shadow. Dashboards are green by default because thresholds require someone to decide what bad looks like, and that decision keeps getting postponed. You are watching a metric that was chosen because it was available.

The project tool

Measures how recently someone updated the project tool. This is the cruellest one, because it looks the most like a record of work. Updating it is a separate task that competes for time with the work it describes, so it is maintained best when the team is idle and worst when the team is under pressure — which is exactly when you need it. You are reading a document whose accuracy is inversely proportional to how much you need it.

By the time it reaches you, what survived was selected four times over — and what got cut was chosen by whoever had the least appetite to raise it.

The common failure is the same in all four. Each is produced on a schedule, by a person, for an audience. That is the definition of reporting, and reporting has a bias built into it that no amount of good faith removes.

Why buying a better tool usually makes it worse

The instinctive response is to buy something. What gets bought is usually a tool that generates work: recurring tasks, reminders, alerts, nudges, weekly digests. The pitch is that the system will keep everyone honest. The mechanism is that the system manufactures items and assumes people will clear them.

Generated items accumulate faster than any human clears them. That is not a possibility, it is arithmetic — the generator runs on a schedule and the human runs on available attention. Once the queue passes the length at which it can be read in a sitting, it stops being read at all, and from that moment the tool is reporting on itself.

What that looks like at rest. In one live system, a single user's generated action queue had grown from 389 open items to 541 to 583, and then sat at 583 unchanged for nineteen days. Every reminder digest sent in that period was unopened.

Nothing was broken. The system worked exactly as designed. It had simply been generating obligations for longer than anyone could absorb them, and the person on the other end had done the only rational thing available and stopped looking.

Every tool that manufactures work arrives at this state eventually. The interesting question is not how to clear the backlog. It is whether a backlog should have been possible at all.

What a record worth trusting has to do

Three properties. They are unglamorous, and each one rules out a category of product you have probably evaluated.

Three tests you can apply to any tool in an afternoon, including the one you already pay for.

One. It is a byproduct, not a task

If recording is a separate job, it competes with the work and loses, permanently and everywhere. The only version that survives is one where the person writes their line once, where they already are, and every other view reads that same line. Not a copy of it that has to be kept in step — the same one. Two copies means two screens that can disagree, and the first time they disagree, both lose their authority and the spreadsheet comes back within a month.

Two. Absence reads as absence

If a day with no record turns into an item in a queue, you have built a backlog. If it simply stays empty, you have built a measurement: work was recorded on this many of the available working days. That number is honest, cheap to produce, and does not degrade. It also compares properly across people with different schedules, as long as the denominator comes from their actual working calendar rather than from a count of rows in a table.

Three. Closing requires evidence, not a declaration

A step marked done by the person responsible for it is not a fact, it is an assertion, and assertions are what the whole problem is made of. Attach something — a file, a link, a note that cannot be quietly rewritten later — and the record stops depending on anyone's memory or optimism. The same logic applies to money: a spend ledger that can be edited is not a ledger, and a correction that overwrites the original destroys the one thing worth keeping, which is that the original happened.

The test is simple. If everyone stopped trying to keep you informed tomorrow, would you still know what happened this week?

Five things to check on Monday

None of these requires buying anything. All five are diagnostic, and any one of them coming back badly tells you where you actually are.

Pick a project and ask when its dates were last changed. Not when the project was last discussed. When the plan itself was last edited. If the dates have moved several times with no record of why, you do not have a plan, you have a rolling forecast that agrees with the present.

Ask what someone in a non-revenue function did last Tuesday. Data, marketing, finance, delivery, quality. If the only way to answer is to ask them, their work is invisible to the company by default, and their contribution is unassessable in either direction.

Open the queue in whichever tool sends the most reminders. Count the open items and check when the oldest one was created. Then check whether the last few digests were opened. This takes four minutes and is usually the most uncomfortable of the five.

Find something marked complete last quarter and ask what proves it. If the answer is that the owner marked it complete, you have a declaration. If a document, a sign-off or a measurement is attached to it, you have a record.

Ask where the last three project decisions were actually made. If the honest answer is a messaging group, then that is your system of record, and no tool that ignores it will ever be more than a second place people are asked to type things.

What we built, and what it refuses to do

GoWarm Work is the version of this we needed ourselves. Projects carry stages, gates, dependencies and a plan frozen at the start so that drift is a measurable difference rather than a monthly renegotiation. Tasks need evidence attached before they close. Bills of quantity behave like ledgers, with corrections booked as reversals and approved variations kept separate from the original bill.

Daily work is one line a day, written by the person doing the work, stored in exactly one place and read by their own view, by the project task and by their manager. Nothing generates an entry for anyone, so there is no backlog and nothing to fall behind on. A day with no entry is a day nobody worked on it, and the measure is against your working calendar rather than against a pile of manufactured tasks.

What it will not do is count anyone's hours, take a screenshot, detect idleness or produce a productivity score. Those products exist and they are answering a different question — one about whether people are working, rather than about what the company is doing. That question corrodes the thing it measures, and a record people are afraid of is a record nobody writes honestly.

See how GoWarm Work does it Book a walkthrough