I Killed Our Standup: How I Use Origin as an Engineering Leader

I lead engineering at Origin. We build a platform that collects AI usage across your environment. I also use it every day to run my own team, and this post is about what that looks like in practice, because I think it changes what the job is.

Sooner or later, someone in your org is going to ask: "Joe spent $5,000 on Claude last week. What did we get for it?"

That's a hard question to answer with the tools most of us have. It's also just the newest version of a problem engineering leaders have always had.

Terrible metrics, because they were all we had

Engineering has a long history of bad proxies for progress. PRs merged. Tickets closed. Lines of code. Now, tokens burned. All of them are coarse estimates of what people are actually doing, and all of them trail the work: you find out after the fact, then react.

Strip away the metrics and there were only ever three questions worth asking:

• Are they working toward the goal?
• Is it moving at a reasonable pace?
• Are they on task, solving the problems that need solved?

Nothing ever gave you a live answer to those, so you fell back on whatever proxy was available. At best you got delayed information and responded a cycle late. At worst you proxied months of work through numbers that don't correspond to value at all.

What you want is a live look at the work as it happens, without adding so much status-reporting process that you slow down the work itself.

The AI usage is the work

When AI dominates the workflow, watching the AI usage is watching the work. If you can see how engineers interact with their AI tools, you can see what they're working on, how they're approaching it, where it intersects with someone else's work, and where they're drifting off course and need help.

Origin collects those interactions at the endpoint: the prompts and responses moving between your people and the providers, including the agents running in your environment, attributed to the process that sent them. It aggregates and summarizes all of it, and exposes the whole thing through an MCP server, so the agents you already run can query it directly.

You also get the resource picture for free: whether the tools are being used well, who needs coaching, whether the spend maps to anything. The $5,000 question has an answer.

What this looks like day to day

Everyone at Origin dogfoods the product. Every engineer runs the Origin Agent on their machine, and their AI usage flows into our staging environment. So I can query what any engineer is up to at any time.

If I want an update on a project, I ask for one. I get back what the engineer has been doing: PRs opened, commits made, the questions they've been asking, the state of the implementation, how much testing has happened, what problems they've hit. I can check it against the rest of the team's work to find overlap. I can pull an old discussion about a scaling decision and hold it up against what someone is building right now, and catch the conflict before it lands.

Each morning, an agent I set up queries the past 24 hours and writes me a report on each engineer. It takes a couple of minutes to read. From it I know who I need to talk to, what needs reprioritizing, and whose implementation is about to collide with someone else's.

Because of that report, we don't run a daily standup.

A standup exists to provide visibility: everyone recites what they did yesterday, and the manager adjusts priorities. I don't need a room full of engineers doing that from memory, because I can ask Origin. What I get back is richer and more consistent, and everyone gets fifteen minutes of their day back.

The same trick extends to anything I'm waiting on. If I expect a piece of work done in a week, I give an agent the rough shape of what I expect and have it check periodically, pinging me only when something drifts: new problems, scope changes, a discovery that should be shared more widely. I don't check in. I get interrupted when something needs me.

The surveillance question

I worried about this when I started, so I was open with the team about exactly what I was doing. The reaction surprised me. The general take was that it's not much different from permanent pair programming: in this industry your output is always up for review, that's the job, and AI usage is no different.

I had also braced for "micromanager's dream product," and the day-to-day turned out closer to the reverse. Visibility is what lets me stay out of the way. As long as someone is aligned, has what they need, and is pointed in the right direction, I have no reason to show up. When that stops being true, stepping in is literally my job, and I'd rather do it early, off a trace, than late, in a PR review. My team has taken fewer meetings and earlier course corrections as a fair trade for the over-the-shoulder feel. So have I.

Most engineering process is context transfer

Standups, status reports, planning meetings, syncs. Nearly all engineering process exists to move knowledge around: getting everyone to agree on what needs to be done, what is being done, and what has been done. That gets brutally expensive as you scale, because more people means more inputs into the shared context and more readers of it. Distributing and collecting context becomes a huge part of running an engineering org, and a huge part of whether it succeeds.

Origin collects that context as a byproduct of people doing their jobs. I don't add meetings. I don't ask for written status reports. My engineers do nothing except the work, and I query the work.

Ask engineering leaders what their hardest internal problem is and you'll hear context problems: knowing what's actually happening, getting an unbiased picture from the ground, spotting where the work has quietly disconnected from the objective. Origin's answer is a granular view of what every person is doing right now, aggregatable however you want, that nobody had to write a status update to produce.

It scales in both directions

An engineering manager with six reports can get per-engineer detail. An engineer can check what a teammate is doing before touching adjacent code. A CTO tracking a cross-functional project can query at the level of teams instead. Whether the question is what three teams have collectively shipped toward a goal or what's holding up a deliverable, you describe what you're looking for and ask. You get back who's on it, what they've run into, and whether they're blocked.

Engineering leaders have spent decades buying visibility with their teams' time, one standup and status report at a time. Now the work itself produces the context, and the only cost of seeing it is collecting it.