The Ownership Trap - by Gert Lõhmus - The Velocity Curve

The Velocity Curve

SubscribeSign in

The Ownership Trap<br>Why Engineers Struggle to Decide (And How to Teach Them)

Gert Lõhmus<br>Jun 02, 2026

Share

We often say we want teams that move faster, take ownership, and lead initiatives. We look for people who do not wait for instructions.<br>Yet many engineering teams remain slower than they should be.<br>It is easy to assume this is a lack of confidence or motivation. The reality? Most engineers are trained to solve technical problems, not to navigate organisational decision-making. If they have never led an initiative, we cannot expect them to know what ownership looks like in practice.<br>One of managers’ biggest responsibilities is to grow people into leaders. That means resisting the urge to step in with the answer and getting involved only when my team asks for help.<br>But there’s a catch: making decisions is a skill, and we rarely teach it.

Understanding the Meeting Trap

Technical alignment meetings often create an illusion of progress. Teams discussing a system migration can spend an hour filling whiteboards, debating implementation details, and leaving the room feeling highly productive. Yet a week later, with no code written, the only tangible outcome is a follow-up meeting to continue the debate.<br>This phenomenon highlights a fundamental truth:<br>A decision is not a conversation. It is not an analysis. It is certainly not a follow-up meeting. A decision is a commitment to a specific course of action.

When teams fail to define the decision upfront, everyone solves a different problem. One engineer debates implementation, another argues about priority, and a third worries about customer impact. Everyone contributes, but no one is answering the same question.<br>The fastest teams spend less time debating solutions and more time aligning on the framework first.<br>The Three Tools Engineers Need

To help engineers transition from technical execution to strategic ownership, we must give them structured tools. Three concepts change the flow entirely:<br>1. One-Way vs. Two-Way Doors

This model divides decisions into two categories based on the cost of reversal:<br>Type 1 (One-Way Doors): These decisions are irreversible and costly. If you walk through, you cannot easily go back. In engineering, this is often a core architectural change. These require deep debate and multiple perspectives.

Type 2 (Two-Way Doors): These decisions are easily changed or corrected, like choosing a minor architectural path. They should be made fast and with high autonomy.

Slow teams treat every decision like a One-Way Door. As a manager, you must teach your engineers to ask: “If this goes wrong, how difficult is it to change our minds?” If the answer is “not difficult,” they should make the call immediately.<br>2. The DARE Model

Many organisations confuse decision-making with consensus-building. They believe every stakeholder must agree before moving forward.<br>The result is more meetings, endless debates about strategies, and slower execution.<br>To avoid the situation of “too many cooks,” use the DARE model (RACI is also popular) to clarify roles before a meeting begins:<br>Decision Maker: The single individual who has the vote and veto.

Advisors: Subject matter experts who provide input but do not decide.

Recommenders: Those who frame the options and data.

Execution Partners: Those who will translate the decision into code and operations.

3. Fist-to-Five

High-performing teams disconnect input from ownership. While everyone deserves context, a voice, and the space to challenge assumptions, not everyone needs a vote.<br>A reliable approach for gauging sentiment during an alignment meeting is the Fist-to-Five method. It avoids the delayed outcomes of traditional consensus by allowing for a spectrum of support: from a “5” (championing the idea) to a “1” (serious concerns) or a “fist” (fundamental disagreement). This fosters psychological safety while ensuring that a single leader can ultimately determine if the group can commit and move forward.<br>Turning Decisions into Action

The final trap is assuming a decision made is a decision completed.<br>If the next steps are vague, the decision dissolves. A week later, you will find yourself in a new meeting about the exact same topic.<br>Every decision must close with a clear agreement:<br>What exact decision was made?

Who owns the execution steps?

What happens the moment the meeting ends?

Leadership is Teaching

The most effective engineering leaders are not necessarily the smartest technical minds in the room. They are the people who create clarity.<br>They do not simply delegate a project and assume leadership will follow. Instead, they teach their teams how to scope a problem, balance technical rigour with business constraints, and identify the exact moment a discussion must end.<br>Our ultimate goal as managers should not be to make every decision ourselves. It is to build the capability in our people so they can...