Best practices: getting the most out of EngLedger

None of the advice on this page is EngLedger ceremony. Every practice here is good engineering hygiene that teams have run for years without any tool watching: small tickets, traceable commits, current access, contemporaneous records. EngLedger happens to read that hygiene as signal: where the practice is in place, the numbers are accurate; where it isn't, the reports show a gap rather than a wrong figure. So the payoff is stated as a consequence, not a reason. If a tip only earned its place by helping EngLedger, it wouldn't be here.

Keep tickets small and clearly described

Aim for one unit of work per ticket, a description someone else could pick up cold, and a consistent set of ticket types. This is ordinary agile hygiene: small tickets are easier to review, estimate and hand over, and a consistent type taxonomy keeps a backlog legible. So EngLedger classifies that work with more confidence and attributes AI spend to it more precisely: a ticket that mixes three jobs can only ever be classified as one, and the classification rules have less to bite on.

Reference the ticket in commits and branches

Put the ticket key in the commit subject and the branch name: feat: add rate bands (ENG-123). Traceability from code back to the work that asked for it is a baseline practice, and a required one in many regulated shops; it also saves the person doing git archaeology in a year's time. So EngLedger can link commits (and the AI sessions behind them) to the ticket, which is what makes AI spend attribution and the commit-to-ticket effort split work.

Keep one task per AI session, and say what it is

Good AI-assisted work looks like good focused work: one task at a time, stated plainly at the start, in a fresh session when you move on to the next thing. A session scoped to a single piece of work gets better answers — the model isn't juggling three unrelated problems — and leaves a transcript that still reads as a record of how that work was done. Starting a new session for a new task is the same clean-desk habit as cutting a new branch, and naming the ticket you're on is the same traceability you'd put in a commit message. So EngLedger can attribute AI spend to work precisely rather than by inference. Metering groups a person's requests into sessions, and the session is the unit spend is attributed on, so three habits decide how exact that attribution is:

• One task per session. A session that touches a single ticket has its whole cost attributed there, cleanly. One that spans several has its cost split between them by a timing estimate — defensible, but an estimate rather than a fact.
• Name the ticket in the session. A ticket key mentioned in the conversation (ENG-123) is the strongest signal there is: the session links to that ticket directly and EngLedger stops looking. Without one, attribution falls back to inferring from nearby commits or overlapping worklogs, and abstains when that evidence is ambiguous — correct, but it leaves the spend unticketed.
• Start a fresh session when you switch tasks. A session's boundary is your AI tool's own session; resuming yesterday's for a different job pools two tasks' cost together. A new session draws the line the metering attributes on.

This is the commit-hygiene point one layer up: attribution is only as sharp as the signals you leave it, and a ticket key in the session is the cheapest and strongest one. Setting up AI metering covers what gets captured, and AI spend attribution covers how the tied and untied portions are reported.

Pick one effort method and keep to it

Decide whether your organisation measures effort from logged worklogs or from commit sessions, and hold that choice steady. Switching mid-stream, or running both informally, makes one month's trend incomparable with the next, a problem for any metric, not just these. So EngLedger's effort model produces a consistent series: it builds reports from one method's entries only, and a stable method is what lets you read a trend as a trend rather than an artefact of how you counted.

Keep your foundation current

The people, rates and teams behind your reports drift out of date quietly. Three habits keep them honest:

• One primary email per person, and link new joiners in week one. Orphaned or duplicate accounts are an offboarding and security smell on their own: you want to know which live accounts map to which people. So in EngLedger an unlinked identity means work with no person attached: hours with no cost, missing from per-person and per-team views. See people and identities.
• Set and maintain hourly rates, or use bands. Costing labour is something finance needs regardless. So a person with no rate shows up in EngLedger as hours with no cost: the ledger won't invent a figure it doesn't have.
• Update teams when people move. Keeping the org chart current is its own reward for clarity. So team rollups in EngLedger reflect who is actually where, rather than last quarter's structure (see teams and initiatives).

Move work through statuses as it happens

Transition tickets as the work actually moves, not in a batch at sprint end. Flow metrics everywhere depend on this: batch status updates collapse cycle time and lead time into noise, whatever tool is reading them. So EngLedger's sprint and status reporting reflects real flow: a ticket that sat in review for three days and one that was dragged across four columns at 5pm on the last day should not look the same, and with contemporaneous transitions they don't.

Review classifications monthly

Look over how work was classified each month, while the context is fresh, not in a scramble before year end. Contemporaneous records are what auditors accept, and reconstructing intent months later is guesswork that gets harder the longer you leave it; this aligns with standard R&D substantiation guidance. So EngLedger's classification stays defensible: the R&D capitalisation guide leans on a confidence score that a monthly review keeps high, rather than a year's worth of low-confidence fallbacks discovered at close.

Announce AI metering before you enable it

Tell your people that AI usage will be metered before you turn it on, and point them at their own-usage page so they can see exactly what you see. This is change-management basics: people accept measurement they were told about and can inspect, and resent measurement they discover. So the numbers are trusted: an AI spend programme people were surprised by is one whose figures get argued with rather than acted on. The rollout guide covers the sequence, and connecting AI tools is the page to send people to.

The through-line

Every practice here has the same shape: keep honest, contemporaneous records of who did what and why, and keep the map of people, access and cost current. That's how good engineering organisations run whether or not they measure themselves. EngLedger's job is to read those records faithfully and to show a gap where they're thin, so the closer your practice is to the advice above, the less the reports have to caveat, and the more the numbers are simply true.