The line is not about seniority and it is not about how technical you are. It is about which decisions carry business consequences. Those are yours, permanently, whether or not you understand the technology underneath them. Everything else belongs to the people doing the work.
Most non-technical owners get this wrong in one of two directions. They delegate decisions that determine what the business ends up with, or they involve themselves in choices where their input adds nothing and costs authority.
Key takeaways
- Own outcomes and trade-offs, delegate methods: What and why are yours; how is theirs.
- Deadlines are a business decision, dates are a technical estimate: Do not confuse the two.
- Delegating a decision is not the same as not hearing it: Ask to be told what was decided and why.
- Over-reaching costs more than under-reaching: Authority spent on tooling is not available for scope.
What you should own
What the product is for
The business result, written as something measurable. Not "a mobile app" but "existing customers reorder without calling sales". This sentence is the filter for every scope question that follows, and nobody else can write it for you.
What ships first
When something has to be cut, and it always does, the choice of what goes is a business decision. Your team can tell you what each option costs in time; only you can say which loss the business can absorb.
The deadline, and what it is for
There is a difference between a date that exists because of a trade show, a contract or a funding round, and a date that exists because someone estimated. The first is yours and is real. The second is theirs and will move. Be explicit about which you are talking about, because teams behave very differently when a date has a reason behind it.
Budget and when to stop
Including the harder version: the point at which you would stop the project. Deciding that in advance, in writing, is one of the few protections against sunk cost.
Who the users are, and access to them
You own the relationship with the people who will use the thing. Teams build better software when they can watch a real user struggle for ten minutes, and you are the only person who can arrange that.
Risk you are willing to carry
Whether to launch with a manual workaround, whether to support older devices, whether to take the faster option that will need rework later. Each of these is a business trade-off wearing technical clothes.
What you should delegate
How it is built
Languages, frameworks, architecture, tools, hosting. There is no version of this question where your input improves the answer, and involvement here is the fastest way to lose standing on the questions that matter.
How the work is organised
Sprints or a continuous list, who works on what, how they review each other. Ask for outcomes, not for a particular process.
Technical sequencing
Which parts have to be built before which others. You can and should ask why, and a good team can explain the dependency in business terms. But the ordering is theirs.
Individual estimates
You can ask for a range and for the assumptions behind it. Negotiating the number down does not change how long the work takes; it changes what you get told.
The part in the middle
Some decisions are technical in form and commercial in effect, and these are the ones worth spending your attention on. Buying a platform rather than building. Adding a dependency on a supplier you would find hard to leave. Taking a shortcut that will need to be redone. Storing customer data somewhere that constrains where you can operate.
You do not need to evaluate these technically. You need them surfaced, in business language, before they are settled. The way to get that is to ask, routinely: is there anything being decided this month that would be expensive to reverse later? A good team will have an answer. It is also one of the four questions worth asking every week, which we cover in what to ask your development team every week.
When you cannot judge the answers
Owning a decision means being able to weigh the options, and sometimes you cannot, because the options are described in terms you have no way to evaluate. That is not a reason to hand the decision over. It is a reason to get the options translated by someone who has no stake in which one wins.
That is a narrow, practical role, and it is different from hiring a technical leader. It leaves the decision where it belongs, which is with you.
Ali Boran Gazel