Manager View: Why Your PMs Shouldn't See Project Margins

Two years ago, when the agency I was CTO of first turned on the financial layer that would later become Saldo, we made the default-transparency mistake. The thinking was clean and the execution was honest: every project had a margin number; every project had a manager; every manager could see the margin number on their own project. We assumed that visibility would produce alignment.

The first quarter on the new system did produce alignment, of a kind. Project managers under margin pressure pulled scope back hard, declined the discretionary half-hour of polish work the team had been doing without thinking, and started to optimise their own decisions for the margin column. Margins on every project ticked up. The numbers were going in the right direction. We congratulated ourselves on the rollout.

The second quarter was when we started to see the cost. Senior engineers, who could see their own hourly cost, stopped logging exploratory work that was hard to attribute to a specific ticket. Project managers, who could see margins compressing on projects with junior staff, started gravitating quietly to senior staffing for everything — which fixed the apparent problem (margin compression on the manager’s view) at the cost of creating a real one (long-term margin compression at agency level, because senior staffing on junior work is the most expensive way to deliver). The team’s output, by every metric we cared about, was getting worse while the metrics we had been measuring went up.

By the third quarter we understood what had happened, and we rebuilt the information architecture from scratch. The version that came out of that rebuild is what we now call manager view. This piece is what we learned, why the default is wrong, and what the right architecture looks like.

What flat transparency actually does

Showing margin numbers to project managers and engineers feels like a transparency win because it sounds like one. In practice the pattern is consistent enough that I can predict it within the first month after a rollout.

Project managers, given a margin number on their project, will optimise for it. This sounds like a good thing until you ask what optimising means in the day-to-day operational sense. Optimising for margin means declining the team’s discretionary work that does not show up on the budget plan: the engineer who wants to investigate a subtle bug for an extra hour, the designer who wants to do another iteration on a layout, the QA who wants to write a regression test for an edge case the client did not ask for but will hit in production. Each of those is unbillable in the short term and quietly pays back in client retention, work quality, and the kind of discretionary effort that compounds over years.

A project manager under margin pressure who is trusted to optimise will compress all of that discretionary work in the first three months. Margins go up by 4–6 percentage points on the projects under that manager’s control. Renewal rates start sliding eighteen months later. The pattern is reliable enough that I now treat short-term margin lift after a transparency rollout as a leading indicator of medium-term trouble, not a success metric.

Engineers, given visibility into their own cost line, behave differently but converge on a similar place. The senior engineer who saw their hourly cost would log time conservatively. The half-hour of unpaid investigation, the twenty minutes of helping a junior across a difficult problem, the bit of unpaid maintenance on the test infrastructure — all of it would get rounded down or dropped from the worklog entirely. The agency’s margin numbers would look slightly better. The team’s actual capacity would be lower because nobody could plan capacity off worklogs that no longer reflected what people were doing.

In both directions, the same dynamic. The metric, exposed to the role that cannot fully control it, distorted the role’s behaviour in a way that improved the metric in the short term and degraded the underlying activity over the medium term. This is Goodhart’s Law in agency form, and it is the most reliable failure mode of margin tooling I know.

Why role-appropriate views matter more than permission management

The first instinct, when the dynamic above shows up, is to manage it through permission gates. Hide the margin number from the project manager. Hide the cost line from the engineer. Lock the financial reports to the CFO and a few senior decision-makers.

This solves the dynamic and creates a different problem: opacity. A project manager who cannot see any margin signal at all loses the ability to escalate when something is going wrong on their project. They have to wait for the CFO’s monthly review, which usually arrives a month later than the right moment to intervene. Engineers who cannot see any economic signal at all start to feel that the agency’s economics are someone else’s problem, which is rarely the relationship a healthy agency wants between its delivery team and its book of work.

The right answer is not less information for some roles; it is differently-shaped information for each role. The principle is that every role should see metrics they can act on, in a unit they can act on, and not see metrics they cannot.

Project managers can act on hours, role overruns, scope-creep flags, sub-project structure, and the things that move work day-to-day. They cannot directly act on margin (that is mostly priced in by the contract and structured by the staffing plan, both of which are decisions made above the project manager’s level). Showing them margin produces the optimisation pressure described above; showing them hours and role overruns produces operational vigilance that does not bend the work in destructive ways.

The CFO needs the full picture to make decisions about pricing, capacity, hiring and portfolio composition. Hiding margin from the CFO would cripple every one of those decisions. Showing margin to the CFO is exactly the architecture that puts the metric in the hands of the role that can act on it.

Engineers, in most agency contexts, do not need to see economic metrics at all by default. They need to know the work they are responsible for, the priorities of the next two weeks, and the technical context of the engagement. Their relationship with the agency’s economics is mediated by the project manager and the senior leadership.

This is not a hierarchy of permission. It is an information architecture in which every role sees the metrics it can use and is protected from the metrics that would distort its behaviour.

What manager view actually looks like in practice

The version we rebuilt at the agency, after the first-quarter mistake, has three views of the same project, computed off the same worklogs.

The finance view, available to the CFO and a small number of senior decision-makers, shows the full picture. Revenue, cost, margin, variance against the contract, attribution by cause (wrong people, wrong rate, scope creep), overhead allocation, comparison against budget, comparison against historical norms. This is what the CFO uses to run the book.

The manager view, available to the project manager on their own projects, shows hours and role overruns. The total hours logged against budget. The hours by role compared to the planned role mix. Flags for scope creep (work logged against tickets that did not exist at the start of the engagement, or that were added after the original scope was agreed). Flags for role mismatch (a senior logging hours that were budgeted at junior cost, without the manager having to know what the costs actually are). The structure of the project as it was sold versus the structure of the project as it is being delivered.

The team view, available by default to every member of the team, shows their own work. The tickets they are responsible for. The priorities of the next sprint. The progress on the project as a whole, expressed in deliverable terms (epics complete, milestones approached) rather than economic ones.

The same project. The same worklogs underneath. Three different lenses, each calibrated to what the role using the lens can act on.

Side-by-side, the manager view and the finance view of the same project look like this. Each is computed off the same Jira worklogs in the same Saldo workspace; the difference is information design, not data access.

The result of running this architecture for two years has been a measurable improvement on every dimension we cared about. Margins ticked up steadily over the first year and stabilised in the second, without the short-term lift-and-erode pattern that flat transparency produced. Engineering output, measured by every quality metric we tracked, returned to and exceeded its pre-tooling baseline within six months. Project-manager-level intervention on at-risk projects became more frequent and more useful, because the manager view surfaces the operational signals (role overruns, scope creep) without requiring the manager to translate from a margin number they were not supposed to optimise against.

What manager view does not solve

Two qualifiers, because the architecture is not a free lunch.

The first qualifier is that manager view requires the agency to have a clear answer to the question “what should this role be optimising for?” If the agency does not know whether project managers are responsible for margin or for delivery, manager view will surface the ambiguity rather than resolve it. The architecture works when the optimisation targets are explicit at the role level. It does not work when the agency is using metric exposure as a proxy for organisational clarity it has not yet reached.

The second qualifier is that the architecture is harder to build than it looks. The metrics are computed off the same worklogs, but the views require role-aware presentation, role-aware permission management, and a discipline about which numbers go which place. This is information design, not feature engineering, and it is rarely a checkbox in financial tooling. Most agencies that adopt manager view do so by choosing financial tooling that has it built in, because retrofitting it onto a tool with flat transparency is harder than starting from a tool with the architecture native.

The third qualifier, smaller but real, is that some agency cultures genuinely benefit from flat transparency. Small agencies (under 25 staff) where every team member is functionally a senior, where the management overhead is minimal, and where the operating margin is comfortable enough that the optimisation pressure described earlier does not bite. For those agencies, the additional architectural complexity of manager view is overhead. The pattern I have described kicks in reliably once the agency crosses the 30–50 staff threshold; below that, flat transparency is often fine.

What to do if your agency is in the first quarter of flat transparency

If you are in the first quarter after rolling out margin tooling and you are seeing margin numbers tick up, two questions worth asking before declaring victory.

The first question: are project managers reporting that the team is happier and the work is going better? If the answer is “the team is leaner and the margins are up”, the dynamic above is in motion. Margins ticking up while the team feels worse is the leading indicator of medium-term erosion.

The second question: are senior engineers logging the same volume of hours they were before the tooling went live? If they are logging fewer hours and the apparent productivity is up, you are seeing the engineer-level adaptation, not a real productivity gain. The hours are still being worked; they are no longer being logged.

If either signal is present, manager view is the architecture worth moving to before the second quarter. The cost of the rebuild is two to three weeks of operational discipline. The cost of not rebuilding is two to three quarters of margin lift followed by a long tail of trust repair.

What we built around this on Saldo

Saldo has manager view as a first-class feature. The same project produces three views: finance (full picture, money), manager (hours, role overruns, scope-creep flags, no money), team (own work, deliverable progress). The views are role-aware; permission management is layered on top. The default for project managers is the manager view, not the finance view, because the architecture assumes the right metric for the role rather than asking every agency to figure that out themselves.

The reason it is built this way is the same reason this article exists. I tried flat transparency in the agency I was CTO of, watched the first-quarter pattern unfold, rebuilt the architecture and ran the rebuilt version for the next two years. The rebuilt version is what is in the product today, and it is the version we offer to other agencies on the demo.

If you are looking at margin tooling and the architecture matters, see your own saldo is the next step we would offer. A 15-minute demo on your existing Jira ships with manager view enabled by default and the architecture is the thing the demo is mostly there to demonstrate. The manager view is the part most CFOs we speak to had not seen before but recognise within the first ten minutes of the call. No card details up front, no follow-up if it does not land.