Why Our Engineers Own a Number, Not Just a Codebase

More responsibility than a traditional engineering role? Yes. But it’s also a direct line between the work you do and the results you create.

I interview a lot of engineers for Kilo, and something they always want to know is why and how engineers at Kilo own a whole product area. At most companies, this would be the job of at least 2-3 people, so how can one engineer do it all?

Engineers as Mini-CEOs

Most engineering orgs assign engineers to a codebase. Ship features, close tickets, repeat. The problem with this model is that engineers end up disconnected from the people actually using what they build.

At Kilo, we do something different. This is our version of product engineering—and it flips the traditional model on its head. Every engineer at Kilo owns a product area. Not just the code—the whole thing. They’re responsible for driving week-over-week growth in weekly active users for their area.

That’s not a team goal. That’s their individual number.

They report on it every Monday at all-hands. They see exactly how their work translates into people using the product. And when the number moves, they know why.

How This Is Even Possible

How can one engineer own a growth metric, talk to users constantly, create weekly content, maintain docs, AND ship features?

The answer is that they’re not coding alone. They’re managing a team of AI agents.

At Kilo, we use Kilo to build Kilo. Our engineers operate as managers of agent teams—parallelizing work that would traditionally require multiple people. One engineer recently shipped an AI adoption dashboard in two days. The same project would have taken two to three people about a month in a traditional setup.

This is what makes the product engineering model possible. When you can delegate UI code, tests, and boilerplate to agents, you can focus on the hardest problems and user conversations. This creates bandwidth for true ownership.

What Ownership Actually Looks Like

Owning a product area means more than just writing code. Our engineers:

• Talk to users directly. They read every Discord channel related to their area. They respond to feedback in Discord and GitHub. They hear firsthand what’s working and what isn’t.

• Drive their own roadmap. There’s no product manager handing down a spec. Engineers maintain and plan their own roadmap based on what they learn from users and what moves their metric.

• Create content. Every engineer produces at least one video per week showing how their product area works or highlighting a new feature. They keep their docs up to date.

• Collaborate with marketing. Each engineer is paired with a marketer who handles the true marketing activities—distribution strategies, campaign ideas, channel expertise.

Why This Model Works

When engineers own metrics, they think differently. They don’t just ask, “Is this technically elegant?” They ask, “Will this get more people using the product?”

That shift changes everything. Features get simpler, iteration gets faster, and user feedback becomes something engineers seek out (not something that lands in a backlog).

And because they’re managing agent teams instead of writing every line of code themselves, they have time to actually understand the users they’re building for.

The Expectations Are Clear

What we expect from every engineer at Kilo:

1. Own a WAUzer (Weekly Active Users metric), documented in our company goals

2. Drive week-over-week growth for your area

3. Produce at least one video per week about your product area

4. Keep your docs current

5. Respond to user feedback in Discord and GitHub

6. Read all Discord channels for your product area

7. Maintain your own roadmap

8. Update your slides for the Monday all-hands

Is this more responsibility than a traditional engineering role? Yes. But it’s also more ownership, more impact, and a direct line between the work you do and the results you create.

That’s product engineering at Kilo.