Every team is an experiment. Over the years I have seen a lot of different approaches, and I have landed on one that consistently outperforms the rest for knowledge work teams building complex systems. By complex I mean work with real constraints: ambiguous requirements, multiple stakeholders, long feedback loops, and technical debt that compounds. In those environments, your decision making model is not a nice to have. It is the operating system of the team. It determines how quickly you learn, how reliably you deliver, and whether people feel proud of the work or burned out by it.
I care about two outcomes at the same time: shipping high quality results and building a creative team that wants to come back tomorrow. The trap is optimizing for only one. If you optimize only for speed, you get brittle systems and attrition. If you optimize only for harmony, you get endless discussion and slow death by indecision. The best teams I have seen do both by being explicit about how decisions get made.
The Common Models
At one extreme, sits the autocratic model: a single leader makes all decisions, top down. It is fast in a crisis and sometimes necessary when the cost of delay is catastrophic. When an outage is unfolding or a deadline is fixed, a single point of decision can save the day. The problem is when this becomes the default. Over time it creates learned helplessness. People stop bringing their best thinking because they expect it to be ignored. You also create a single point of failure: when the leader is wrong, the whole system is wrong. Retention suffers, creativity dies, and senior talent quietly leaves because the job becomes execution without ownership.
Then there is the consensus model, common in flat orgs and some academic environments. Everyone has a voice, nothing ships. The model looks inclusive, but it often hides the real dynamic: decisions drift toward whoever has the most time, the most persistence, or the lowest risk tolerance. When you need unanimity, any stakeholder can veto, and the easiest way to avoid conflict is to water down the plan until it threatens no one. That is how you get slow decisions and mediocre outcomes. In high velocity environments this model quietly kills momentum, and when momentum dies, quality usually follows.
Many modern tech companies default to agile structures where teams self organize around sprints. This works well for execution and for making progress visible. It is a strong default for delivery. The gap is accountability for cross cutting decisions. When something goes wrong, it is often unclear who owns the outcome across product, engineering, design, and operations. Sprint structures can also struggle when priorities shift fast, when dependencies multiply, or when the work is not easily decomposed into independent tickets. You can be busy every sprint and still be directionally lost.
The Model That Works: Consultative + DRIs
My preferred model is simple: assign a Directly Responsible Individual (DRI) to every significant decision or workstream, within a consultative culture. This is not about hierarchy. It is about clarity. The DRI is the named owner of the outcome, regardless of which team they sit in or what their title is. If there is a question about a decision, you know who will decide. If there is a failure, you know who will drive the fix. If there is ambiguity, you know who will turn ambiguity into a plan.
The DRI is not a manager. They are the person who owns the outcome. They consult broadly, listen carefully, and then decide. There is no design by committee, but no dictatorship either. Everyone knows who to talk to, and everyone knows who will pull the trigger. Consultation is not performative. It is a real effort to gather perspectives, surface risks, and improve the plan. The DRI earns trust by doing three things consistently: asking for input early, explaining the decision clearly, and following through.
In practice this means: when we start a new project, the first thing I do is establish who the DRI is for each key component. That person drives the roadmap, coordinates dependencies, and is accountable for delivery. They are expected to seek input from engineers, domain experts, and product stakeholders before making major calls, but the final decision is theirs. I also want the DRI role to be crisp in scope. One DRI for the overall outcome, and additional DRIs for major subcomponents if the work is large. If DRIs overlap in unclear ways, you create confusion and politics.
A practical detail that matters is decision cadence. DRIs should not “disappear to decide.” The loop is visible: here is the question, here is the context, here are the options, here is what I am hearing, here is the decision, here is what we are doing next. This can be written down in a short decision record. The goal is not bureaucracy, it is avoiding the constant re-debating of the same issues.
Why This Works
I have spent over 15 years leading AI and ML teams, from building infrastructure across hospital systems to shipping multimodal models into clinical workflows. This model keeps coming out on top for three reasons. It matches how complex systems actually get built: by many people contributing expertise, with clear ownership for integration and trade offs.
First, it scales with ambiguity. In research and healthcare AI, requirements shift constantly. Data changes, clinical workflows evolve, regulations shape what is acceptable, and what looks good in a prototype can collapse in production. You need someone empowered to adapt, not waiting for committee approval. The DRI can absorb new information, update the plan, and keep the team moving without restarting the entire conversation. When ambiguity is high, the cost of decision latency is enormous.
Second, it retains senior talent. Strong engineers and scientists want ownership, not just assignments. They want to be trusted with real decisions and real consequences. The DRI model gives them real agency while keeping accountability clear. It also makes growth visible. People learn by owning an outcome end to end: understanding the trade offs, communicating decisions, taking feedback, and shipping. When senior people have ownership, they also raise the bar for everyone around them.
Third, it reduces my load as a leader. Rather than being the bottleneck on every decision, I focus on setting direction, resolving conflicts between workstreams, and making the big calls. Everything else flows through empowered people. That frees leadership time for the things only leadership can do: strategy, hiring, culture, and alignment across teams. It also makes the organization more resilient. If everything depends on one person, the system breaks under growth or stress. With DRIs, ownership is distributed and explicit.
The Honest Trade-off
This model only works with psychological safety. DRIs will make mistakes, and if people get punished for good faith calls, they will retreat into consensus and you are back to committee paralysis. The culture has to reward ownership, including owning misses and learning fast. The standard should be high and the feedback direct, but the goal is improvement, not blame. A DRI who hides problems is dangerous. A DRI who surfaces problems early is valuable, even if the news is bad.
The honest trade off is speed versus alignment. A consultative DRI model moves quickly because one person is accountable, but consultation can drift into consensus seeking and stall execution. That is why you need explicit norms. “Disagree and commit” means you air objections and alternatives early, then once the DRI decides, everyone executes the decision as if it were their own. It does not mean suppressing concerns. It means choosing a path and moving, while keeping the risk visible. If you disagree, you document the key risk and what evidence would trigger a revisit. That turns disagreement into a hypothesis you can test, not a political standoff.
To prevent silent vetoes or late surprise resistance, define an escalation path. Set an input window and deadline so consultation has a clear end. Let the DRI decide. Escalate only for material risk or irreversible impact, and be specific about what counts. If everything escalates, nothing does. If nothing escalates, the team accumulates hidden risk. The point of escalation is not to undermine the DRI. It is to protect the system when the stakes warrant another level of review. A simple rule works: if the decision is reversible, decide fast and learn. If it is irreversible, slow down, consult more, and escalate when needed.
Final Thought
There is no universally correct way to run a team. Autocratic works for crisis response. Consensus works for early stage discovery and building shared understanding. Agile delivery works well for execution rhythm. But for building complex, high stakes systems over time, where you need speed and quality and a team that wants to come back tomorrow, the consultative DRI model is the best I have found.
It is simple enough to explain, strong enough to scale, and human enough to keep talented people engaged. Clear ownership plus real consultation is a rare combination. When you get it right, decisions get better, delivery gets faster, and the team spends less time arguing about process and more time doing the work that matters.
