The feedback by said Lead was direct but constructive: this is not a root cause. It describes an instruction, not the failure that caused the incident. It doesn't help us learn or improve.

The actual story is internal and out of scope for this article. But I wanted to discuss ownership, one of its key ingredients: time, and how it is affected by LLMs (it is a blog about AI after all).

What should we expect from people working on a product? That they should not only execute requests. Quite the contrary, in fact: they should understand enough context to challenge requests, identify risks, propose better options, or simply disagree with the usefulness of a request.

Without falling on the wrong end of the spectrum (endlessly challenging every decision), we should expect a healthy organization to make risks visible before decisions are taken, and the team owning the product is the best positioned to do that. Authority may decide but only after expertise is heard.

This is where the current discussion around AI becomes interesting, because they are not designed to do that.

Language models are very good at producing an answer, completing a task, and following a prompt. But they optimize for being helpful and agreeable rather than for asking whether a request is based on a mistaken assumption, creates a hidden risk, or damages a customer experience. They do not naturally own the consequences of what they produce.

That responsibility remains human. A person who knows the product can notice that a seemingly simple change affects a merchant integration, an operational process, or a promise already made to customers.

However, this kind of judgment not only requires competence but also time.

Unfortunately, time is often in short supply. Many organizations are structured to maximize utilization: the fraction of time that people spend on tasks that are directly billable or measurable. I am not necessarily speaking of control-freak organizations, but a simple KPI for the number of tickets resolved is enough to kill "spare time".

If people are expected to be busy every minute of every day, they will aim for completion rather than understanding. More dramatically, they will have little room to explore alternatives, read surrounding context, talk to stakeholders, or recognize that a request is poorly framed. That is detrimental to both competence building and product ownership.

A colleague working in a support role once made this argument: it is good not to be busy all the time. Some empty space is necessary to support people properly. It allows someone to respond quickly when help is needed and, sometimes, to spend more time than the immediate question appears to justify.

It was strange to me at first. Why would an employer want employees with "free" time? That's inefficient!

But the more I thought about it, the more convinced I became that it is key to improved productivity. A little "spare time" makes room for anticipation. It allows engineers to investigate a signal before it becomes an incident. It allows product teams to consider second-order effects. It allows people to help a colleague, improve documentation, or challenge a plan before the cost of changing it becomes high.

AI makes these questions more important. If AI is used to multiply output, and KPIs are enabled to measure that improved efficiency, we will get teams that are faster at producing work while becoming worse at evaluating whether the work should be done at all, how it should be done, and what the impact might be.

The question, then, is how teams could use AI to improve their knowledge of the product and their sense of ownership.

A note on ownership, because that's a topic I'm passionate about:

• There is good ownership and apparent ownership. Without authority, context, support, or recognition, "ownership" can become a vague way to shift responsibility downward while decisions remain centralized.
• I don't want to romanticize ownership. Employees are not founders, and they should not be asked to carry unlimited responsibility.
• Job security also plays a role. It is easier to invest in long-term quality when people believe they will live with the consequences of their decisions.
• Team stability is also important. If people are constantly moved around, they will not have the time to build the context and relationships that allow them to make good decisions.
• Contractors, offshore teams, and external partners are not inherently less capable of ownership. People care about quality when they have sufficient context, continuity, access to decision-makers, and incentives aligned with outcomes. But I think that is usually not the case.