Engineers Owning Metrics: The Kilo Approach to Product Engineering

Why Our Engineers Own a Number, Not Just a Codebase

TLDR: Kilo reimagines the engineering role by assigning each engineer full ownership of a product area, including a weekly active users metric they personally report on. This is made possible by having engineers manage teams of AI coding agents rather than writing all code themselves.

Summary:

There's a fascinating experiment happening at Kilo that challenges how we think about engineering organizations. Instead of the traditional model where engineers are assigned to codebases—shipping features, closing tickets, rinse and repeat—Kilo assigns each engineer to own an entire product area. And not just the code. The whole thing, including a specific growth metric: weekly active users for their area.

This isn't a team goal buried in some OKR document. It's an individual number that each engineer reports on every Monday at the company all-hands. When that number moves, they know exactly why, because they're the ones talking to users, reading Discord channels, responding to feedback on GitHub, and maintaining their own roadmap. There's no product manager handing down specs. Engineers drive their own direction based on what they learn from actual users.

The obvious question is: how can one person do all this? The answer lies in AI agents. Kilo engineers operate as managers of agent teams, parallelizing work that would traditionally require multiple people. The article mentions one engineer shipping an AI adoption dashboard in two days—a project that would have taken two to three people about a month in a traditional setup. By delegating UI code, tests, and boilerplate to agents, engineers free up bandwidth to focus on the hardest problems and genuine user conversations.

What's particularly interesting is the culture this creates. Engineers don't just ask "Is this technically elegant?" They ask "Will this get more people using the product?" That shift changes incentive structures dramatically. Features get simpler because complexity doesn't impress users—solving their problems does. Iteration speeds up because there's a direct feedback loop between work and results. User feedback becomes something engineers actively seek rather than something that piles up in a backlog.

For architects and team leads thinking about applying this model: the key enabler here isn't just AI agents—it's the organizational design that makes ownership meaningful. When you give someone a number they personally report on, you've created accountability that no amount of process documentation can match. The AI agents are the force multiplier that makes this sustainable for one person. Without them, this model would burn people out. With them, it becomes a compelling alternative to the traditional PM-engineer-designer triumvirate.

Key takeaways:

• Engineers at Kilo own individual WAU metrics for their product areas, not just code
• AI coding agents act as force multipliers, letting one engineer do work that traditionally required 2-3 people
• The model eliminates the disconnect between engineers and users by making engineers responsible for growth, not just shipping

Tradeoffs:

• Gain direct ownership and faster iteration but sacrifice the specialization benefits of dedicated PMs and designers
• Individual metric ownership creates clear accountability but may reduce collaboration across product areas
• Managing AI agents speeds up development but requires engineers to develop new skills beyond pure coding

Link: Why Our Engineers Own a Number, Not Just a Codebase

This summary is provided for informational purposes. Views and opinions expressed in the original articles belong to their respective authors.