07:30
engineering leadership
Matt developed a five-component "product driven model" — vision, focus, clarity, shared ownership, and courage — while trying to teach software engineers to think about product beyond just code, and argues clarity is probably the most important of the five because it drives what a team does day to day.
The product driven model is not a company-wide HR vision but a tactical model: vision means explaining why this specific piece of work matters this week.
Focus means telling engineers explicitly why the team chose to do this thing and not that thing, including the trade-offs, because ambiguity about "why" is one of the biggest sources of engineer frustration.
Clarity is the third and, in Matt's view, probably the most important component: the constant, day-to-day flow of what needs to be done and why, mostly coming from product managers.
The best engineers "create their own clarity" and don't need to be told what to do — Matt calls these people "purple squirrels" or "10x developers."
Clarity has to be dosed: giving a team six months of requirements at once is as unusable as giving none, so context has to be delivered project-by-project or day-by-day.
Shared ownership is the goal of the model: ownership should always be distributed across the team and never belong to one person, not even a company's founder, because a company can't scale from one team to many teams without it.
Courage is the component that originated the whole model about 18 months before this conversation, sparked by conversations at Full Scale about developers who were "struggling" rather than "bad."
Courage means telling engineers explicitly that they were hired as experts and are wanted to voice opinions, ask why, and suggest better ideas — and it requires leaders to have the courage to change and stop being "the hero."
Courage is tied to psychological safety: team members should feel safe saying they don't want to be "the code monkey" anymore, and leaders should respond by thanking them and acting on it.
In practice, applying the model comes down to spending a few extra minutes every week giving the team context on what they're doing, why, and whether they're winning or losing based on the previous week's work.
Product Driven Model — A five-part model Matt built while trying to teach engineers to think about product beyond just code, made up of vision, focus, clarity, shared ownership, and courage. Apply: Run through all five components with an engineering team to check that each is present, rather than assuming any single one (e.g., just vision) is sufficient.
Vision — The tactical vision of why a specific piece of work matters this week, not a company-wide HR-style vision statement. Apply: Explain to the team why this particular thing being built today matters, framed as the "big picture" for the current week.
Focus — Explaining the customer value behind doing this thing and not that thing, including the trade-offs behind the choice. Apply: When engineers ask why a particular approach was chosen over an alternative, tell them explicitly why option A was chosen over option B so they understand the trade-off and get on board.
Clarity — The day-to-day, continuous flow of information from product managers about what needs to be done and why, described as probably the most important of the five components. Apply: Give engineers just enough context to unblock today's work, dosed day-by-day or project-by-project, rather than dumping months of requirements on them at once.
Shared ownership — A state in which ownership of a product or team is always distributed among everyone, never held by a single individual, not even the founder. Apply: Give every team member a voice and an opinion and let the team collectively decide and strike a balance, as the mechanism that lets a company scale from one team to many teams.
Courage — The willingness of engineers to voice opinions, ask why, and suggest better ideas, paired with leaders' willingness to change and stop being "the hero"; tied to psychological safety. Apply: Tell struggling developers explicitly that they were hired as experts and are wanted to speak up, ask why, and suggest better ideas, and thank them when they do (e.g., when someone says they don't want to be "the code monkey" anymore).
Definition of Done ("log in as me") — Matt's practical redefinition of "done" for his team: a feature isn't done until someone has logged into his (the CEO's) account and confirmed it works from his perspective. Apply: Tell engineers explicitly that work isn't complete until they've tested it by logging in as a specific real user (e.g., the CEO), not just verified it running on their own machine.
The interviewer notes that Matt built the model without turning it into a mnemonic acronym, and reads that specifically as a sign of his engineering/CEO background rather than a "product person" background, who would have "backwards engineered it into an acronym to make it a little bit more memorable."
The clarity component surfaces a dosage problem unique to engineering work: too little context stalls engineers into asking someone else what to do, but too much context (e.g., six months of requirements dumped at once) is equally useless because it won't be remembered — Matt frames this exact tension as part of why software engineering is hard.
Shared ownership is defined by explicit exclusion of the founder — Matt argues no one, "not even the the founder of a company," should truly own something alone, reasoning from the risk of what happens when they leave.
Courage as a component originated from a labeling shift: Full Scale stopped calling underperforming developers "bad" and reframed them as needing "courage," turning a performance issue into a psychological-safety/leadership issue rather than a skills issue.
The concrete "log in as Matt" definition-of-done practice illustrates shared ownership and courage in action: once Matt modeled the expectation, a lead engineer independently began repeating and enforcing it to the rest of the team without being asked to.
«And it's five components. It's vision, focus, clarity, shared ownership, and courage.»
— 00:13
«Why are we doing this thing today? Why does this thing matter?»
— 00:33
«the very best engineers create their own clarity like nobody even has to tell them what to do»
— 03:04
«not even the the founder of a company should truly own something»
— 03:47
«What they needed more than anything was courage.»
— 04:17
«Have the courage to do that.»
— 04:35
«that's the definition of done. You log in as me and make sure the software actually works.»
— 06:53
«I can definitely tell that you come from uh more of an engineering and CEO background rather than the product background»
— 05:13
Reception
No comments are available, so audience reception cannot be determined.
The video maps Matt's own five-part leadership model, which he presents as having emerged organically from running an engineering organization (Full Scale) rather than as an acronym-driven product-management framework, and grounds each component (vision, focus, clarity, shared ownership, courage) in specific workplace anecdotes like requirement overload and the "log in as me" definition of done.
07:30