Your Engineers Own the Code. Who Owns the Technical Decisions?

Imagine your engineers have finished comparing two ways to deliver a customer request. One takes longer. The other uses a supplier that adds a monthly cost and changes how customer data is handled.

The technical work has reached an answer. The company has not.

Who can approve the spending? Who can agree to the data access? Who can tell the customer that the date needs to move if neither option is acceptable? Giving the engineers ownership of the code does not answer those questions.

I would start there when a team says that technical decisions keep going in circles. The useful distinction is what someone is qualified to assess and what the company has actually allowed them to decide. Sometimes those belong to the same person. Sometimes they do not.

The fix can be small: one person responsible for moving the choice forward, clear limits on what they can approve, and a named route for the parts that need someone else's answer. You do not need to put the founder in every design discussion. You do need to make it possible for a company decision to reach the right person.

“Engineering owns it” can mean several different things.

It may mean that the team maintains the code. It may mean that a tech lead chooses the design. It may mean that engineering prepares a recommendation while product or the founder makes the final trade-off. If people assume different meanings, a project can move a long way before the disagreement becomes visible.

In the supplier example, the lead can explain how the integration works, what it costs to maintain, and where it could fail. That is valuable technical judgment. Approval to accept new spending or change a customer commitment may still sit elsewhere.

The opposite mistake is to pull every choice back to the founder. Engineers can have room to choose an implementation within an agreed budget and set of requirements. If they keep having to seek permission inside that boundary, delegation exists on paper but does not help the work move.

I would make the boundary clear enough that both sides can recognize it. The lead should know when they can proceed. The founder should know which decisions will come back and why.

Start with one recurring choice that is causing friction. Avoid trying to assign ownership of “technology” in one conversation.

Take a supplier change. Name the person who will prepare the options and bring the choice to an answer. State what that person can approve, what remains with another owner, and whose input could change the decision. Then name who will implement it.

One person can do several of these jobs in a small company. Separating the jobs still matters. A founder might approve a budget while the tech lead chooses the implementation. A specialist may need to assess a particular risk without taking over the product priority.

This is also where the business needs to be specific. What should the change let the company do? What customer promise, operating cost, or work does each option affect? An architecture recommendation becomes easier to discuss when those consequences are visible.

The result can fit in a short decision record. It should let a new person understand the choice, the reasons, who can approve it, and what happens next. A long role chart is less useful if the current decision still has nowhere to go.

Published decision practices make a similar distinction. Atlassian's DACI guidance separates the person driving a decision from the person approving it, with other people contributing or staying informed. GitLab's DRI guidance separates accountability from consultation and execution, while recognizing that some choices need additional approval.

You do not have to adopt either system's labels. They help make the jobs visible. One person can be responsible for getting a decision resolved without personally holding every approval it requires.

These are examples of organizational practice, not evidence that a particular template will make your team faster. Their value here is practical: they give you distinctions to test against the decision that is stuck in front of you.

Clear ownership does not make disagreement disappear. It helps the team work out what kind of answer is needed.

Suppose two engineers disagree about whether a supplier supports an important behavior. That is a question about facts. Find the documentation or run a suitable test. Giving one person the final word does not make the missing evidence less important.

Now suppose everyone agrees on the facts. The faster option costs more and leaves the team with recurring support work. Product wants the date; engineering wants the smaller operating burden. The next step is to put that trade-off in front of the person who can choose between those commitments.

A third situation is different again. The proposed action may be outside a rule the team has no authority to waive. Agreement around the table cannot make it permitted. The owner needs an acceptable alternative or clarification from whoever is responsible for that rule.

This distinction stops another estimate, meeting, or review from becoming the automatic response to every disagreement. Ask what would actually settle the choice: more evidence, a priority decision, or a different permitted option.

Give the next difficult decision a route before it becomes urgent.

Write the question, the options, your recommendation, and what happens if the company waits. Name the person who can answer and an alternate for when they are unavailable. Agree what the team may do while the answer is pending.

For the hypothetical supplier change, waiting might mean that the team continues work that does not depend on the supplier. It might mean offering a smaller scope to the customer. The interim plan should follow the consequences of this decision. Silence should not quietly become permission to spend or share data.

Once the choice is made, keep a short record of the context, the answer, and its consequences. Include the person carrying it out and what would make the company look again. AWS's guidance on technical decision records is useful for preserving that reasoning without turning every choice into a lengthy report.

If an exception is temporary, give it a limit. Record who approved it, where it applies, and when it needs another decision. Otherwise a one-off response can remain in place long after everyone has forgotten why it was accepted.

Finally, check that someone has time to do the work. A decision with an owner and approval can still wait because every engineer is occupied. At that point, change the delivery plan rather than adding another approval step.

Before changing the ownership arrangement, look at why recent decisions were reopened.

A founder repeatedly reversing choices that were made inside an agreed boundary suggests the delegation needs repair. A customer changing the requirement after the decision is a different problem. So is new evidence showing that the selected option will not work.

Those later changes should be allowed to reopen a choice. Preserve the earlier reasons and explain what changed. Otherwise people may protect an old answer just to avoid appearing inconsistent.

A named owner also needs enough skill and support to assess the options. If they do not have it, bring in the right help or change the assignment. Responsibility cannot substitute for knowledge, working time, or the approvals the company must retain.

Do not judge the arrangement only by how quickly decisions close. Look at whether the answer led to useful work, whether required approvals arrived in time, and whether the same unresolved objection keeps returning. A fast answer can still leave a difficult problem behind.

At the next technical discussion, ask three ordinary questions: who will bring this choice to an answer, what can that person decide, and what needs someone else's approval?

Then make sure the answer has somewhere to go. Name who will implement it, what happens while it waits, and what would justify looking again.

Engineers should have room to make the technical choices they are equipped and authorized to make. When a choice changes a company commitment, the company needs to participate through a clear owner.

That is the boundary I would try to make visible. Keep routine design decisions close to the work. Give decisions about money, customers, and accepted risk a route that does not depend on everyone guessing who can say yes.