Every engineering organisation eventually reaches a point where it has to choose what it wants to optimise for.

Some optimise for process.

Some optimise for predictability.

Some optimise for velocity.

At LYKSTAGE we optimise for something different.

Ownership.

Not ownership of code.

Ownership of problems.

The world has changed

Ten years ago it made sense to organise engineering around specialists.

One person knew databases.

Another knew infrastructure.

Someone else knew frontend.

Someone else deployed production.

Learning a new technology took months.

Today we live in a different world.

With AI, documentation, code search and modern tooling, learning a framework has become dramatically easier.

The bottleneck is no longer:

"Can someone write this code?"

The bottleneck has become:

"Does someone understand the problem deeply enough to make the right decisions?"

Engineering is increasingly becoming a thinking discipline

That changes how teams should operate.

We don't assign tasks.

We assign problems.

There is an important difference.

A task says

Build API X.

A problem says

Creators cannot discover local content because language detection is inaccurate.

The second forces someone to understand:

• users
• architecture
• tradeoffs
• production
• rollout
• failure cases

The implementation is almost the easy part.

One owner

Every important initiative has exactly one owner.

Not because that person writes every line of code.

But because someone must own the outcome.

Ownership means asking questions like

• What problem are we solving?
• Is this actually the right solution?
• What happens in production?
• How do we roll it back?
• How do we know it succeeded?
• Who gets paged at 2 AM?

If nobody owns those questions, nobody owns the project.

At the same time, the knowledge and decision history must remain shared. The team should be able to review the work, challenge the direction and continue operating the system even when the original owner is not available.

Working like a leaderless system

This model is inspired by leaderless systems.

Each person can move independently.

The RFC keeps everyone aligned.

The project document keeps the context shared.

The metrics show what is happening in production.

The owner drives the problem.

But the owner should not become a single point of failure.

If the owner is unavailable, the team should still have enough context to keep moving.

Work continues.

Knowledge stays shared.

This gives us individual ownership without making the team dependent on one person

RFC before code

Before writing code, we expect an RFC.

Not because we enjoy documentation.

Because changing architecture is cheaper than changing production.

The owner writes:

• problem
• constraints
• alternatives
• architecture
• rollout
• risks
• metrics
• rollback

The RFC is shared.

Everyone challenges it.

Everyone suggests improvements.

The discussion happens before code exists.

Once the team agrees...

The owner moves.

No committee.

No endless meetings.

No design-by-consensus.

Build it.

Release it.

Operate it.

Ownership doesn't stop after merge.

The same person should ideally

• design it
• implement it
• deploy it
• monitor it
• fix it
• improve it

Production teaches lessons no architecture diagram ever will.

If you never operate your software, you never truly understand it.

We don't optimise for Jira

This usually surprises people.

Large organisations need Jira because ownership is fragmented.

One person analyses.

Another designs.

Another implements.

Another tests.

Another deploys.

Another monitors.

Now everyone needs status updates.

Someone becomes the project manager.

Meetings appear.

Standups appear.

Sprint planning appears.

Backlog grooming appears.

Soon more time is spent coordinating work than doing work.

Our model is different.

When one person owns the entire lifecycle, coordination cost drops dramatically.

A simple list is often enough.

Progress becomes obvious.

Either the problem is moving.

Or it isn't.

Documentation becomes memory

Traditional documentation tries to explain code.

We think documentation should explain decisions.

Every project maintains a living Markdown file.

It contains

• RFC
• decisions
• rejected alternatives
• production incidents
• rollout history
• metrics
• lessons learned

Months later we don't ask

"Who remembers why we did this?"

We ask Claude.

Or ChatGPT.

Or any AI assistant.

Because the complete history exists in text.

Markdown has become our engineering memory.

AI simply makes that memory searchable.

Small teams move faster

We intentionally keep teams lean.

Not because people should work longer.

Because communication grows faster than engineering output.

Five engineers require little coordination.

Twenty engineers require meetings.

Fifty engineers require management.

A lean team with clear ownership often ships faster than a much larger team.

Trust before process

This model only works if people are trusted.

Owners make decisions.

Owners choose approaches.

Owners ask for help.

Owners change direction.

Managers don't need to review every implementation detail.

They review the thinking.

Once trust exists...

Micromanagement disappears.

What if someone makes the wrong decision?

They will.

Everyone does.

That is not the interesting question.

The interesting question is:

How expensive is it to recover?

Modern software makes recovery remarkably cheap.

We can

• deploy in minutes
• roll back instantly
• feature flag
• migrate safely
• rewrite quickly
• use AI to accelerate changes

The cost of changing software has fallen dramatically.

The cost of slow decision making has not.

Given the choice between

• making ten fast decisions and correcting two

or

• spending weeks trying to make one perfect decision

we usually choose the first.

Speed with accountability beats perfect planning.

Ownership is not about credit

One misunderstanding of this model is believing ownership means doing everything yourself.

It doesn't.

Owners ask for reviews.

Owners seek feedback.

Owners borrow ideas.

Owners involve experts.

Ownership simply means there is one person accountable for the outcome.

Engineering remains collaborative.

Responsibility remains clear.

What we value

We don't value

• number of tickets
• hours worked
• amount of code
• meetings attended

We value

• problems solved
• systems improved
• customer impact
• production quality
• speed of learning
• willingness to own outcomes

This isn't for every company

Large enterprises often cannot operate this way.

Highly regulated industries require extensive controls.

Huge engineering organisations need more coordination.

That's okay.

Every company optimises for different constraints.

We optimise for speed of learning.

We believe small teams with high ownership outperform large teams with fragmented responsibility.

The culture we're building

We don't want engineers who ask,

"Which ticket should I pick next?"

We want engineers who ask,

"What is the biggest problem we should solve?"

We don't want specialists who only own one layer of the stack.

We want engineers who own an outcome from idea to production.

Because in the age of AI, writing code is becoming easier every day.

Thinking clearly, making good decisions, and taking responsibility for the outcome are becoming the true engineering skills.

I think this is stronger than framing it as a rebuttal to someone's workload claims. It implicitly answers that concern: in this model, individual contribution isn't measured by how many components someone touches or how busy they appear, but by the business problems they own and successfully deliver end-to-end. That makes the document a durable statement of engineering culture rather than a response to a single situation.