Part of my Upper Bound 2026 series — write-ups of the talks from Amii's AI conference in Edmonton worth carrying home. Honesty note up front: I did not catch this one live. I'm reconstructing it from the session materials and the notes I grabbed, so I'm sticking close to what the talk actually laid out. The framework names are hers; where I don't have the internals, I say so rather than invent them.
The Talk: "Building Your AI Team: A Guide That Actually Works"
Debra Somani gave this keynote on the Deloitte Stage, Wednesday May 20, 10:30 AM. The premise: most organizations know they need an AI team and have no idea how to build one. They hire too fast, start on the wrong problems, or buy technology before they invest in people — and months later they have tools nobody uses and a team nobody trusts.
The single line the whole talk hangs on:
AI team success is 20% technology, 80% intentional design.
Everything else falls out of that ratio. The hard part isn't picking the model — it's the human, structural side: who's on the team, how the work is organized, and what you actually do in the first hundred days.
Who She Is
Debra Somani is a transformation strategist, consultant, and keynote speaker — Founder & CEO of Learn Ed Inc. and a Premier's Award of Excellence nominee. She's spent roughly 30 years leading large-scale strategy and digital-transformation work across public, private, and not-for-profit organizations — including ERP/digital transformation for the Government of Alberta — integrating strategy, culture, people, process, and technology, now including AI. In other words: someone who has actually stood teams up and watched them succeed or fail, not a theorist working from a slide deck.
The 20/80 Framework
The core lens, and the thing I'd actually carry into a meeting: evaluate every AI-team decision by where it lands on the 20/80 split. If most of your energy is going into the 20% — tooling, models, infrastructure — and you're treating the 80% (people, structure, intent) as something that'll sort itself out, you've inverted the work. The framework is a standing reminder to keep the human side in front.
The 3 Core Roles Model
Somani's staffing take: forget the sprawling org chart — any AI effort, at any size or maturity, comes down to three core talent roles:
- The Champion. Advocates for the AI work, drives adoption, and keeps momentum when the novelty wears off. Without a Champion, the effort stalls the first time it gets hard.
- The Builder. The hands-on technical role — whoever actually builds and implements the AI systems and workflows. Without a Builder you have slides, not software.
- The Connector. Bridges teams and communicates across silos — the person who makes things happen between groups that otherwise wouldn't talk. Usually the difference between a tool that ships and a tool that gets used.
The move that matters: name the roles the work genuinely needs before you start hiring against job titles.
The 5 Design Failures
A consolidated, memorable diagnostic of what actually kills AI teams — and the reframe is that none of these are technology problems, they're design problems baked in from day one. The five she calls out:
- Hiring too fast. Standing up headcount before the work is designed. You end up paying for a team you never scoped.
- Starting on the wrong problem. Picking the flashy or convenient first use case instead of one that proves value and earns trust.
- Technology before people. Buying tools and models first and treating the human, structural work as an afterthought — the exact inversion of the 20/80 rule.
- Tools nobody uses. The predictable downstream result: software ships, adoption doesn't follow, and the initiative quietly dies on the vine.
- A team nobody trusts. Once the org stops believing the AI team can deliver, every future ask gets harder. Trust is the currency, and it's the first thing these failures spend.
Treating each of these as a design failure rather than an execution screw-up is the move with teeth — because a design is something you can actually go back and fix.
The AI Team Readiness Score
The part I keep coming back to: a self-diagnostic you score and re-score on your own team. You rate yourself across a handful of readiness dimensions — leadership alignment, how clearly the work is structured, process maturity, data readiness, how embedded governance is — and the total drops you into a tier, each with a different first move. The output isn't a grade, it's a Monday Morning Action: the smallest concrete thing you can do at the start of next week.
The tiers, the way I read them off my notes (so treat the cutoffs as approximate, not gospel):
- Low — start with belief. The shared understanding and buy-in isn't there yet. Pouring process on top of that gap just buys you expensive, well-documented confusion. The work here is organizational, not technical.
- Middle — start with design. Enough buy-in to work with, but the structures, processes, and ownership aren't solid. This is where most teams stall: they feel ready, but keep shipping ambiguous results because nobody actually designed the system.
- High — start with scale. The foundation is sound. Now the question is expanding what works without breaking it.
The 5-Finger Framework
Five design principles, deliberately memorable — one per finger, recallable without notes. These are the ones I caught off the slides, paraphrased to how I wrote them down:
- Design before you build. The structural calls you make at the start — who owns what, how work flows, what the model is actually responsible for — decide most of what happens downstream. A vague brief and a hope that the team sorts it out is how you get chaos at scale.
- Structure over headcount. More people on a poorly-designed team is more noise, not more output. Fix the structure first, then staff to it.
- Start small, signal loud. Pick a focused slice, make it genuinely work, and let the result speak. A small team with a clear win earns the trust to scale; a big team with fuzzy goals burns it.
- Every landmine is a design failure. When something blows up — a model doing the wrong thing, a process nobody follows, a governance incident — the reflex is to blame execution. If it was predictable, it was a design failure. That reframe leads to fixes instead of blame cycles.
- Your team is your competitive advantage. Not the model, not the vendor, not the stack. The people and how they're organized around the work — that's what compounds, and what a competitor can't copy-paste.
What I'm Taking From It
I didn't see this one live, so I won't pretend I felt the room. But the 20/80 thesis is sticky, and it squares with research I already trust. To be clear, these are my connections — not citations I can attribute to Somani's talk — they're just why the framing rings true to me:
- Conway's Law — Melvin Conway, "How Do Committees Invent?" (1968): a system's design ends up mirroring the communication structure of the organization that built it. If the team structure is wrong, the AI system inherits it. That's the 80% in one law.
- The model is the small box — Sculley et al., "Hidden Technical Debt in Machine Learning Systems" (NeurIPS 2015): in real ML systems, the model code is a tiny fraction; the bulk is data, infrastructure, and the human/process scaffolding around it. The 20/80 split from the engineering side.
- Governance is designed-in — the NIST AI Risk Management Framework (AI RMF 1.0, NIST AI 100-1, January 2023, nist.gov/itl/ai-risk-management-framework) is built on the premise that trustworthiness gets mapped, measured, and managed across the lifecycle — not bolted on at the end. That's a design failure you can choose to avoid.
The line that hit hardest — and it's one of the five principles above — is "every landmine is a design failure." That's a reframe with real teeth: it moves the conversation from "who screwed up the execution" to "what did we fail to design for," and that second question is actually answerable. You can fix a design. Blame cycles just cycle.
Three things I'm keeping:
- Score yourself before you staff up. The AI Team Readiness Score is worth five minutes before any conversation about growing a team — and the payoff is the Monday Morning Action it spits out, not the number.
- The model is the small box. Sculley's insight, her application: fix the data and the structure before you reach for a better model.
- Governance is a design decision, not a compliance step. If it's not in the first conversation, it's already late.
More in the Upper Bound 2026 series: the Memory Paradox, Bayesian optimization, Vibe Ops, IT/OT security and the Purdue model, and more.
Header photo by Vlad Hilitanu on Unsplash.
Content on this blog was created using human and AI-assisted workflows described here. Original ideas and editorial decisions by Justin Quaintance.