How We Manage 300+ Employees with Daily Reports and AI

A customer churned on us. When we went back through what happened, we found something that still bothers me.

We had put a new engineer on their team. Every single day, that engineer filed the same daily report. Reviewing documentation. Doing training. Same thing, day after day.

Here is what was actually going on. They had been reaching out to the client every other day trying to get started, and nobody was answering. So they did the only sensible thing a person can do while they wait, which is read the docs and work through training material.

Their reports were completely honest. That is genuinely what they were doing.

And internally, we did not know there was a problem. The daily report was the exact mechanism that should have told us. It was sitting right there, saying the same thing every day for weeks, and nobody read it as an alarm.

Here is the unglamorous reason why. A customer success manager here carries 50 to 70 engineers. Nobody in that position is reading three hundred reports a week looking for the one that has not changed since Tuesday, and pretending otherwise would be the kind of answer I hate getting from a vendor. It was an arithmetic problem that nothing in our process was solving.

That is what this post is about:

How do we ensure our 300+ team members are being productive every day in a highly subjective type of job role?

The only question I actually want answered

People love to argue about how much work somebody is getting done. Story points and hours and velocity and lines of whatever. I have written a whole post on measuring engineering productivity and I am still not sure I have ever seen one of those conversations end well.

What I want to know is simpler than that. Are we making progress toward our goals, or are we stuck?

That is it. That is the whole question. And the daily report is the simplest mechanism I know of for answering it.

A developer who is moving forward writes something different every day, because different things happened. A developer who is stuck either writes nothing, or writes the same sentence over and over.

You do not have to grade the work to see it. You just have to notice the pattern.

The shape of the report matters more than the words

Reading a report for its shape is the part most people miss, and our own churned customer is the proof.

That engineer’s reports were accurate. If you read any single one of them in isolation, it looked fine. Reviewing documentation and working through training are both real activities, and nothing in that report was wrong.

The problem was never one report. It was report after report saying the same thing.

Content tells you what somebody did yesterday. Shape tells you whether anything is moving. A person who is genuinely progressing produces reports that change, because the work changes underneath them. When the reports stop changing, the work has stopped changing, and something is in the way.

Two shapes matter more than anything written in the body:

– Nothing filed at all. Either something is wrong with the person or something is wrong with the work. – The same report repeating. Somebody is blocked and either has not said so, or has said so and nobody acted.

The second one is more dangerous, because it looks like compliance. The report is there. The box is ticked. It just is not telling you anything new, which is itself the message.

What we actually ask for

None of this works if the form is vague, so the one every engineer at Full Scale fills in asks four things, and each one exists for a reason.

– What I did today, with ticket numbers, so the work can be traced. – What I will be doing the next working day, which is where you find out whether anyone has a plan. – What I need from the client, which goes straight to them. – What is slowing me down or would help me grow, which is marked internal and goes only to our customer success manager.

That last split matters more than it looks. An engineer who is being blocked by the client needs somewhere to say so that is not addressed to the client. Without that field, the honest version of “I am stuck because nobody is answering me” has nowhere to go, and you get exactly the silence that cost us a customer.

The form nags in one more useful way. It asks for productivity blockers, not just technical ones. Slow hardware, unclear priorities, waiting on somebody’s decision. Nobody thinks those are worth mentioning, which is how they quietly eat a week.

Clients see nearly all of it. Clients can be set up to receive the reports by email, and they are available anytime in Rocks, our management system. We sort that out on the kickoff call. The only part they do not see is the internal note to the CSM, because that is the channel for telling us the client is the problem.

Software is bad at showing its work

There is a bigger problem underneath all of this. It shows up long before anyone starts managing an offshore team.

Engineering is terrible at marketing the value of what it is working on. It is one of the oldest communication problems in software development, and it has nothing to do with where anyone sits. Where the time actually goes tends to stay hidden, even from the people paying for it. A team can spend three weeks on something genuinely hard and important, and to everyone outside the team it looks like three weeks of silence.

Then somebody asks what the developers have been doing all month, and the honest answer is complicated and nobody wants to hear a complicated answer.

Daily reports fix a surprising amount of that. Not because they are a productivity tool, but because they make the work legible to people who are not sitting inside it. When the work is written down every day, “what have they been doing” stops being a debate and becomes a document.

This runs in both directions, and the inward-facing half matters at least as much. The reports are how our own management team holds our own people accountable, so that we know we are actually being productive for the client rather than assuming it. We are the first audience for them, before any client ever is.

That matters commercially too. If we ever have an issue with a client, we can go back and show them exactly what people were working on, day by day. Not a summary written after the fact by somebody with an interest in the answer. The actual reports, written at the time, before anyone knew there would be an argument.

What builds up over months

One report tells you about a day. A few hundred of them tell you about a person and a team, and that is where these get genuinely valuable.

Read enough of them and you can see how much somebody gets done, what they get blocked on, what they get stuck on, how they work with the people around them, and whether they ask for help when they need it.

That last one turns out to matter enormously. An engineer who writes “stuck on the auth flow, grabbing time with the tech lead tomorrow” is telling you something good about themselves. An engineer who is stuck for two weeks and never mentions it is telling you something too. Same underlying problem, completely different person.

We interview for that quality directly, and I have written about what we score developers on and why communication carries the most weight. We also background check every hire before they touch a client’s code. The daily reports are where you find out whether all of that was right.

Then we pointed AI at them

The obvious problem with everything I have described is that it does not scale by reading.

Nobody is going through hundreds of daily reports a week looking for a pattern in the shape. That is exactly the sort of tedious, high-volume, pattern-shaped work that people are bad at and machines are good at, so we built a system that reads them for us.

It has been extremely valuable, and not in the way I expected. I assumed we would get a productivity score. What we actually got was a much better answer to my one question, at the level of the whole team.

A few things it catches that a human reader reliably misses:

– Reports that repeat, which is the case that cost us a customer. – Work that is taking longer than the work should take. Somebody keeps reporting progress on the same project, and the system flags that this particular job has no business running this long. A human reviewer rarely has the baseline to make that call across dozens of engineers. Something that has read thousands of these does. – Reports filed in a batch days later, which usually means they were reconstructed from memory rather than written as the work happened. – Word-rich reports with nothing checkable in them. No commits, no tickets, no pull requests, no names. These are the hardest to catch by eye, because they read as confident and busy. It is also why the form asks for ticket numbers by name.

That third one produced the most humbling result we have had. On one team, a face-value AI summary of the same reports had rated somebody a high performer, because they wrote fluently and at length. Reading the shape instead of the sentiment put the same person in the red. Confident prose reads as productivity to a naive model, and to a busy human.

It also catches the opposite problem, and this one surprised me. Sometimes a person’s reports are thin because they are not being given enough to do. The work is not there. That is not a performance problem and treating it like one would be both wrong and insulting; it is a staffing or client-communication problem, and it usually means somebody on our side needs to go ask why the queue is empty.

Yes, we tell them to use AI to write these

We tell our engineers to use AI to help write these, which raises an obvious objection, so let me get ahead of it.

We actively encourage our engineers to use AI to help fill these out. Point it at your commits, your ticket movements, your pull requests, and let it assemble the list of what you actually did today. Why not? Nobody’s memory of Tuesday afternoon is better than the commit log.

That probably sounds like it contradicts the previous section, where the giveaway was reports full of confident prose and nothing checkable. It doesn’t, and the difference is the whole point.

The question was never whether a machine helped write it. The question is whether it is anchored to something that exists. A report assembled from real commits and real tickets is more accurate than one written from memory at the end of a long day. A report generated out of nothing is filler, and filler is filler whether a person or a model produced it.

Same tool, opposite directions. One of them starts from the artifacts and describes them. The other starts from a blank page and sounds busy.

There is a fair follow-up buried in that. If the artifacts are the ground truth, somebody is going to ask why we do not just skip the report and read the commit log. The commit log cannot tell you what somebody plans to do tomorrow, what they need from the client, what is blocking them, or whether they asked anyone for help. Those are the four things the form asks for, and not one of them exists in a repository.

The form also reads the report as it is being written. If an update is thin on detail, the engineer gets immediate feedback right there in the box, rather than hearing about it three weeks later in some audit. Catching it at the keyboard is a lot cheaper than catching it in a post-mortem.

Which is the tell for reading these correctly. Hollow reports filed against long hours point at the person. Honest, consistently thin ones point back at us.

We also learned that some signals belong to the team rather than to a person. Individually reasonable absences, a sick day here and a holiday there, add up to a stretch where the client cannot get anyone on a call. No individual did anything wrong and the client still felt it. That is a conversation for the customer success manager rather than a performance review.

Is this just micromanagement?

Somebody is going to read all of this and hear a vendor arguing for a mandatory daily paper trail on people it bills by the hour. That objection deserves a straight answer rather than a dodge.

The honest part of it first: it is easier for us to run this than it would be for you. These engineers are our employees, so we can make it part of the job. A CTO asking their own team to start writing daily updates has a harder sell and should expect some eye-rolling.

What makes it survivable is the size and the direction. It is two minutes at the end of a shift, nobody is scored on how long it is, and the field that matters most is the one where the engineer says what is in their way. The report exists to get somebody help, not to prove they were busy. When the reports come back thin because we did not give a person enough work, we treat that as our own failure.

The version of this that people rightly hate is the one where the update goes up the chain and nothing ever comes back down. That is the failure mode to watch for, and it is the one that cost us a customer.

The one report our clients actually love

Here is the part that surprised me most, and it is where all of this pays off.

Every team we place through staff augmentation rolls up the same way. We take every daily report from an entire team and roll them into a single summary of what the team did together. Not a stack of individual updates a client has to read and assemble in their head, but a single one.

That summary is far and away our clients’ favorite thing. More than the dashboards, more than the individual reports, more than the meetings. Because it answers the question they actually have, which is not “what did engineer number seven do on Thursday” but “is my team moving.”

And that is how the whole thing comes full circle. The daily report started as a way for one person to say whether they were stuck. Roll a team’s worth together and it answers the same question one level up, for the person paying for the team.

It is the same question I started with. Are we making progress toward our goals, or are we stuck? A client should never have to guess at the answer, and they should never have to sit through a status meeting to get it either.

What I would tell you to do with your own team

You do not need our system for most of the value here. You need the habit and one rule for reading it. Somewhere north of about twenty engineers per reader the hand version stops working, which is the whole reason we built anything, but below that a person can absolutely do this by eye.

The habit is that every engineer writes a few lines at the end of their shift: what they did, what is next, and what is in the way. It takes two minutes and the third item is the one that matters.

The rule is to read them vertically instead of horizontally. Take one person and read their last two weeks straight down. Reading across the team tells you what happened yesterday. Reading down one person tells you whether anything is moving, which is the only question worth asking.

If somebody’s last ten reports could be swapped around without anyone noticing, you have found your problem. Go talk to them today. In our case, the answer was that a client had gone quiet on a new engineer for weeks and we were the last to know.

The rest of our operating cadence, the weekly checkpoint with our engineers and the monthly one with the client, sits on top of this. Our customer success managers run all of it, and the daily report is the raw material every one of those conversations is built from.

Why any of this matters

None of this is complicated. That is sort of the point.

There is a whole industry of tooling built to tell you how productive your engineers are, and most of it measures things that are easy to count rather than things that are worth knowing. Meanwhile the most useful signal available to you is whether a person wrote something different today than they wrote yesterday.

We learned that the hard way, from a customer we lost while the answer sat in a file nobody was reading.

If you want a team where somebody is actually reading them, tell us what you need.