Role guide # Every role directly participates in the engineering outcome. In Specification-First Delivery, you either help deliver the product or help deliver its Knowledge System. Both ship together: knowledge, decisions, constraints, and evidence stay coherent with the product and remain accessible to people and AI coding agents throughout delivery. ## The product Knowledge System Its location may vary, but its authority and accessibility must not. It gives every contributor and coding agent durable, shared context for change. - Intent - Knowledge - Outcome ## CTO / Head of Engineering Design the organizational and delivery architecture that makes trusted software delivery a repeatable capability. A familiar delivery day ### As a CTO or Head of Engineering, You are trying to turn accelerating AI-assisted work into dependable organizational capability without becoming the escalation point for every important decision. A familiar pattern: The day starts with delivery metrics, AI-adoption questions, and priorities that look clear in a dashboard. Behind them, experienced engineers are still supplying system history, responsibilities, and constraints in conversation, while you decide which judgment must become a durable condition for delivery. #### Set direction for capability and risk You establish priorities for architecture, teams, investment, AI adoption, reliability, and governance across a changing delivery landscape. #### Manage through fragmented signals Roadmaps, delivery metrics, incidents, reviews, and team reports show activity, but rarely reveal whether accountable decisions are carrying through to execution and acceptance. #### Intervene through escalation You discover weak ownership, missing context, or unsafe scope and unclear constraints when delivery slows, work conflicts, or production risk has already increased. Your current pain points ### Why local speed does not become dependable organizational delivery. Fragmented authority, context, and evidence prevent the organization from turning local activity into dependable delivery confidence. #### Delivery depends on individual context Experienced people compensate for missing organizational memory, creating bottlenecks and continuity risk as teams and priorities change. #### Governance is separate from execution Leadership decisions, engineering standards, and review expectations are not consistently available at the point where people and AI agents make changes. #### AI can amplify an uneven operating model Faster implementation scales the consequences of unclear authority, poorly defined scope, and incomplete evidence as readily as it scales useful work. The Specification-First workflow ### Keep your accountable judgment connected to the work that follows. The workflow makes your contribution explicit, challengeable, and usable. It gives engineers and AI coding agents a coherent path to execute within explicit scope and authority without silently replacing human judgment. #### Define the accountable delivery system Make ownership, decision authority, required context, review paths, acceptance responsibilities, and acceptance criteria explicit across product, engineering, quality, and operations. #### Make the operating model usable in delivery Ensure the Specification System, repository guidance, job scope, and evidence expectations give teams and AI agents task-appropriate context with explicit ownership and review controls. #### Govern through evidence and learning Use traceable delivery evidence, deviations, incidents, and recurring questions to improve capability rather than relying on escalation or individual heroics. ## Product owner Own value, priority, scope, and the decision on whether the delivered behavior is worth accepting. A familiar delivery day ### As a product owner, You remain accountable for whether a delivered change creates the right value, even as AI can turn a short request into implementation momentum very quickly. A familiar pattern: A stakeholder asks for an improvement, and you clarify the outcome, trade-offs, and urgency. The request then becomes a ticket, a prompt, and a stream of delivery activity, while the reasoning that made the change worth doing is increasingly difficult to see. #### Frame the request You clarify the desired outcome with stakeholders, often through conversations that are only partly recorded. #### Prioritize the work You make scope and trade-off decisions, then express them as backlog items for downstream interpretation. #### Review the result You see implemented behavior late, when assumptions and omissions are expensive to revisit. Your current pain points ### Why accountable product decisions become expensive to recover. Separate product decisions, implementation work, and acceptance evidence make it expensive to recover the value a change was meant to create. #### Value is reduced to a ticket The outcome, non-goals, and trade-offs behind a request can disappear behind a short implementation summary. #### Acceptance arrives too late You are asked to judge whether a change creates value after the team has already committed to a particular interpretation. #### AI accelerates untested assumptions Faster implementation makes an unclear product decision travel farther before anyone can challenge it. The Specification-First workflow ### Keep your accountable judgment connected to the work that follows. The workflow makes your contribution explicit, challengeable, and usable. It gives engineers and AI coding agents a coherent path to execute within explicit scope and authority without silently replacing human judgment. #### Make the intended outcome explicit Record the problem, expected value, priorities, non-goals, and decisions that shape the change. #### Co-author observable acceptance Work with analysis, engineering, and quality to make normal and exceptional outcomes testable before execution. #### Accept with traceable evidence Review whether the intended value was delivered, the agreed scope was respected, and the expected behavior was preserved. ## Product or program manager Connect outcomes, dependencies, sequencing, and delivery decisions across a product or program. A familiar delivery day ### As a product or program manager, You maintain a credible path from outcomes and dependencies to delivery, while AI-generated updates can make activity look clearer than the decisions beneath it. A familiar pattern: The planning view looks reassuring: work is moving, summaries are fresh, and teams have dates. Between those signals, unresolved decisions and dependency assumptions surface in meetings, where you again connect the story of the outcome to the work already under way. #### Coordinate priorities and dependencies You align initiatives, teams, dates, and risks through plans that rarely carry the full product and engineering rationale. #### Escalate uncertainty Open decisions surface in ceremonies or status updates, often after they have already affected sequencing. #### Track delivery signals Progress is visible, but it can be difficult to tell whether completed work still serves the intended outcome. Your current pain points ### Why progress signals do not show whether the right increment is being delivered. Activity cannot show whether the right increment is being delivered when outcomes, dependencies, authority, and evidence are not connected. #### Plans hide decision quality Milestones can look healthy while essential product, architecture, or dependency decisions remain unresolved. #### Dependencies lose their meaning A dependency is recorded as a date or owner, rather than as the interface, assumption, or capability it protects. #### Status is not acceptance evidence Reported progress cannot show whether the product and its Knowledge System remain coherent. The Specification-First workflow ### Keep your accountable judgment connected to the work that follows. The workflow makes your contribution explicit, challengeable, and usable. It gives engineers and AI coding agents a coherent path to execute within explicit scope and authority without silently replacing human judgment. #### Connect outcomes to delivery decisions Maintain a visible path from initiative intent through dependencies, scope choices, and accountable ownership. #### Sequence clearly scoped work Use explicit constraints and open decisions to order work without asking teams to infer hidden program assumptions. #### Steer with conformance evidence Use evidence of intended behavior, respected constraints, and unresolved risk, not activity alone, to guide delivery. ## Business analyst Make business rules, domain meaning, decisions, exceptions, and traceability usable in delivery. A familiar delivery day ### As a business analyst, You make the domain meaning that software depends on explicit, while AI can rapidly turn an incomplete interpretation into plausible behavior. A familiar pattern: A conversation reveals the exception behind a seemingly simple rule, and you trace the meaning across stakeholders and existing material. Once work begins, engineers and AI agents need that same distinction, but it may remain in workshop notes, a chat thread, or your memory. #### Elicit domain knowledge You identify rules, language, exceptions, and stakeholder decisions across conversations and existing materials. #### Describe functional behavior You translate that knowledge into requirements or process artifacts that engineering must reinterpret in context. #### Clarify during implementation Questions return through meetings and messages, creating parallel versions of the same business decision. Your current pain points ### Why rules and exceptions become costly to recover. Scattered domain knowledge makes every clarification a reconstruction task and allows inconsistent interpretations to persist. #### Rules become detached from implementation The precise semantics that matter to the business may not be visible where engineers or AI agents make changes. #### Exceptions appear as late surprises Important edge cases stay in expert memory until a test, incident, or stakeholder review exposes them. #### Traceability is manual and fragile Teams reconstruct why behavior exists because decision history is not kept alongside the specifications and code it governs. The Specification-First workflow ### Keep your accountable judgment connected to the work that follows. The workflow makes your contribution explicit, challengeable, and usable. It gives engineers and AI coding agents a coherent path to execute within explicit scope and authority without silently replacing human judgment. #### Establish authoritative domain knowledge Make rules, terms, sources, exceptions, and unresolved questions inspectable and clearly owned. #### Specify behavior and decision logic Describe normal paths, exceptions, data meaning, and acceptance conditions in a form humans and AI can use. #### Maintain traceable change Update the Knowledge System with the delivered behavior so rationale and domain meaning remain coherent over time. ## Dev lead Turn agreed intent and constraints into clearly scoped, sequenced work that a team can execute safely. A familiar delivery day ### As a development lead, You keep people and AI moving safely through a change, often supplying sequencing, scope, and integration context that the work itself does not carry. A familiar pattern: Engineers arrive with sensible questions, prompts are ready to run, and the team wants to move. You draw on personal experience, architecture conversations, and a few trusted experts to decide what can happen in parallel and what must remain protected. #### Interpret the request You infer technical implications, dependencies, and missing decisions from tickets, discussions, and existing code. #### Break work into tasks You distribute implementation work and protect the team from uncertainty through informal coordination. #### Integrate and recover You resolve collisions and clarify deviations as work comes together, often after the original assumptions have drifted. Your current pain points ### Why delegation turns into integration and recovery work. Delegation creates recovery work when people and AI agents receive tasks without shared context, explicit scope and constraints, or evidence expectations. #### You become the hidden context hub Critical sequencing and scope decisions live in your head or in transient conversations, creating a continuity risk. #### Delegation is under-specified Engineers and AI agents receive tasks without clear scope, ownership, protected areas, or observable completion criteria. #### Integration reveals late decisions Technical and product conflicts emerge only when independently interpreted work is combined. The Specification-First workflow ### Keep your accountable judgment connected to the work that follows. The workflow makes your contribution explicit, challengeable, and usable. It gives engineers and AI coding agents a coherent path to execute within explicit scope and authority without silently replacing human judgment. #### Challenge and refine the specification Expose ambiguity, dependency, risk, and technical consequences before committing work to the team or an AI agent. #### Create clearly scoped implementation jobs Define ownership, interfaces, protected areas, sequencing, and evidence so each contribution can proceed safely. #### Integrate against the shared system Review deviations and completed work against the same intent, constraints, and acceptance evidence that authorized it. ## Architect Own system responsibilities, interfaces, constraints, and technical authority for change, and make the relevant context available to delivery. A familiar delivery day ### As an Architect, You protect system structure and technical authority while AI-assisted implementation can move ahead before every relevant constraint reaches the work. A familiar pattern: A change crosses from one service into another or touches an old integration. You can explain why a constraint exists, and a senior engineer may remember the incident behind it, but the team and its agents need that judgment at the moment they choose an approach. #### Assess the change in context You reason about responsibilities, interfaces, dependencies, data, risk, and standards across a landscape of evolving systems. #### Advise or approve the approach You communicate constraints through design review, patterns, and direct guidance that may not travel with the implementation. #### Discover divergence later You find inconsistent interpretations through review, integration, incidents, or accumulated architectural drift. Your current pain points ### Why architecture governance arrives after the decision. Disconnected architectural context turns governance into a late check rather than usable guidance that shapes delivery from the start. #### Architecture is consulted, not executable A correct architectural decision has little effect if it is not connected to the work, tools, and evidence that implement it. #### Responsibilities and interfaces are reinterpreted repeatedly Teams and agents need to infer interfaces, ownership, and constraints from dispersed artifacts and existing code. #### Governance arrives after the decision Reviews catch divergence late because technical authority was not expressed as a usable constraint at the point of execution. The Specification-First workflow ### Keep your accountable judgment connected to the work that follows. The workflow makes your contribution explicit, challengeable, and usable. It gives engineers and AI coding agents a coherent path to execute within explicit scope and authority without silently replacing human judgment. #### Make technical authority accessible Express relevant responsibilities, interfaces, constraints, decisions, and authoritative sources where delivery participants can use them. #### Shape change within its context Work with product, analysis, leads, and engineers to turn system-level concerns into explicit, proportionate delivery scope and constraints. #### Verify conformance and evolve context Use evidence to review whether the change preserves architecture, then update the Knowledge System as the system evolves. ## Software engineer (e.g., backend/UI) Implement, challenge, test, and explain changes within authorized product and technical scope and constraints. A familiar delivery day ### As a software engineer, You are expected to deliver a safe change quickly, while AI helps with code but not with the product, architectural, or operational judgment surrounding it. A familiar pattern: A task arrives with a short brief and an AI assistant ready to accelerate implementation. Before either of you can act safely, you reconstruct intent from code, tickets, chats, and the senior engineer who remembers why an awkward constraint exists. #### Reconstruct the intent You infer what should change, what must not change, and which conditions matter from incomplete or inconsistent sources. #### Implement and negotiate ambiguity You make local technical decisions or seek clarification while the work is already under way. #### Prove the change after the fact Tests and review establish some confidence, but the reasoning behind choices and deviations may remain implicit. Your current pain points ### Why implementation uncertainty becomes engineering rework. Separate sources of intent, constraints, and evidence make implementation uncertainty a repeated cost rather than a challenge resolved before execution. #### Context hunting consumes engineering time The knowledge needed to implement safely is spread across tools and people instead of being available with the work. #### Tasks lack explicit scope and safeguards Without explicit non-goals, interfaces, and constraints, an apparently small change can create unintended effects. #### AI output still needs hidden context Coding agents can accelerate implementation, but they cannot reliably recover authority or intent that the organization has not made explicit. The Specification-First workflow ### Keep your accountable judgment connected to the work that follows. The workflow makes your contribution explicit, challengeable, and usable. It gives engineers and AI coding agents a coherent path to execute within explicit scope and authority without silently replacing human judgment. #### Review and challenge before execution Use the Specification System to identify ambiguity, missing constraints, or risks that need accountable resolution. #### Implement within an explicit scope Use product, domain, architecture, and job specifications to guide human and AI implementation without silently expanding scope. #### Record evidence and deviations Show how the change meets its agreed behavior and constraints, and make any necessary deviation visible for review. ## Production engineer / Site Reliability Engineer Make operational constraints, reliability expectations, release readiness, and production evidence usable throughout delivery. A familiar delivery day ### As a production engineer or Site Reliability Engineer, You make production risk visible before release, while AI can speed up changes that still lack operational context, observability, recovery limits, or rollback conditions. A familiar pattern: A change approaches release and suddenly raises questions about load, monitoring, rollback, and support. You know where the last incident left its mark, but the operational lesson is often in a runbook, a dashboard, or the memory of the person who responded. #### Recover operational context You draw on incidents, telemetry, runbooks, service ownership, and support experience to understand what a change must preserve. #### Review late release risk You assess observability, resilience, capacity, rollback, and deployment concerns after product and implementation choices have largely been made. #### Respond and learn after release You manage the consequences of unexpected behavior, while the operational lessons may not become durable guidance for the next change. Your current pain points ### Why operational risk is discovered after deployment. Separate delivery and operational systems force teams to discover readiness, recovery, and support gaps when deployment risk is already high. #### Production reality arrives too late Failure modes, support needs, dependencies, and operational limits are treated as release checks instead of constraints that shape the change. #### Reliability expectations are not executable Service objectives, observability, recovery, and rollback needs may be documented separately from the jobs, code, and evidence that must satisfy them. #### Incidents do not reliably improve delivery Learning remains in post-incident conversations or local runbooks rather than updating the authoritative context available to future contributors and agents. The Specification-First workflow ### Keep your accountable judgment connected to the work that follows. The workflow makes your contribution explicit, challengeable, and usable. It gives engineers and AI coding agents a coherent path to execute within explicit scope and authority without silently replacing human judgment. #### Make operational expectations explicit Contribute service objectives, failure behavior, dependencies, support needs, observability, recovery, and release constraints before implementation begins. #### Shape a controlled path to production Work with product, architecture, engineering, and quality to make operational risks, rollout conditions, rollback paths, and accountable approvals visible in the delivery plan. #### Accept operational evidence and improve context Use deployment and production evidence to assess readiness, surface deviations, and convert material operational learning into reusable context in the Specification System. ## QA engineer Design the evidence that shows normal, exceptional, regression, and operational expectations are satisfied. A familiar delivery day ### As a QA engineer, You need to establish meaningful confidence in a change, while AI can create tests quickly without determining which behavior, risks, and evidence matter. A familiar pattern: A completed change reaches verification with code, a short acceptance list, and perhaps AI-generated tests. You begin reconstructing the promised behavior, the exceptions that matter, and the operational conditions that would make the evidence sufficient for acceptance. #### Interpret expected behavior You gather acceptance detail from tickets, demos, conversations, code, and previous defects. #### Design and run verification You test normal paths, exceptions, integration, and regression risks against a moving interpretation of the change. #### Report confidence and defects You communicate results, while the connection between evidence, intent, and risk may remain fragmented. Your current pain points ### Why verification has to compensate for upstream ambiguity. Separate specifications and verification evidence require quality professionals to reconstruct what must be proven and why it is sufficient. #### Quality enters after scope decisions Testability, negative paths, and operational expectations are discovered late instead of shaping the specification from the beginning. #### Acceptance criteria leave gaps A short list of happy-path checks cannot represent the evidence needed to trust a complex change. #### Evidence is hard to reuse Test results may confirm a build but not preserve why the evidence was sufficient for acceptance. The Specification-First workflow ### Keep your accountable judgment connected to the work that follows. The workflow makes your contribution explicit, challengeable, and usable. It gives engineers and AI coding agents a coherent path to execute within explicit scope and authority without silently replacing human judgment. #### Shape acceptance early Co-author observable outcomes, risk conditions, negative paths, and evidence needs while the change is still being specified. #### Trace verification to intent and constraints Design tests and checks against the authoritative behavior, constraints, and quality attributes, not an inferred summary. #### Support evidence-based acceptance Present clear evidence of conformance, remaining risk, and any limitations so accountable roles can accept with confidence. A shared professional discipline ## Everyone can become a Specification Architect. This is not a new universal job title, and it does not make a formal architect responsible for every specification. A Specification Architect is a delivery professional who makes intent, knowledge, constraints, decisions, execution scope, and evidence explicit enough for other people and AI systems to use within their sphere of responsibility. > Everyone architects the specification layer within their own sphere of responsibility.