// THE ARCHETYPES OF AUTOMATION FRAMEWORK
8 DIMENSIONS OF
AUTOMATION CAPABILITY
This framework helps teams identify their collective strengths and gaps across 8 dimensions of automation capability; regardless of industry, size, or technical maturity.
The core insight: the biggest barrier to automation is not technical skill. It is process thinking, team composition, and role awareness. No single person covers all eight archetypes. Teams assess collectively and use the gap analysis to guide hiring, training, or partnership decisions.
Like a sports roster, each team member brings a unique combination of strengths. The radar chart visualization makes it easy to see where coverage is strong and where critical gaps exist. Two people scoring 9 in Building but zero in Quality is a risk profile; and one this framework is designed to surface.
THE 8 ARCHETYPES
Click any archetype to explore its sub-roles, descriptions, and the established frameworks behind each one.
1
PROCESS & KNOWLEDGE HOLDING
Understanding, retaining, and communicating how work actually happens
▼
Every automation starts with understanding the process it replaces. This archetype cluster covers the people who hold that knowledge which is often undocumented, frequently locked in one person’s head, and always more complex than it appears on paper. Without these roles, teams automate what they think the process is, not what it actually is.
The Tribal Knowledge Keeper
- Holds the undocumented “real” version of how things work
- Critical to interview before building anything
- Often resistant to change but invaluable for accuracy
Nonaka & Takeuchi, The Knowledge-Creating Company — tacit vs. explicit knowledge
The Exception Whisperer
- Knows every edge case and every “but sometimes it works differently because…” scenario
- Will immediately break your demo by thinking of the one situation you didn’t plan for
- Essential for QA
Failure Mode and Effects Analysis (FMEA); Agile edge case testing practices
The Process Archaeologist
- Can trace back why a process exists the way it does
- Understands the organizational history behind current workflows
- Helps the team avoid automating something that should just be eliminated
Root Cause Analysis (RCA); “5 Whys” methodology (Toyota Production System)
The Documenter
- Naturally inclined to write things down
- Comfortable translating verbal or observed processes into structured written steps
- Serves as connective tissue between all other archetypes
Business Process Management (BPM) documentation standards; Systemology (Jenyns)
2
PROBLEM DEFINITION
Identifying, articulating, and prioritizing what is worth automating
▼
Before anyone touches a tool, someone needs to define the problem clearly. These sub-archetypes focus on identifying friction, spotting bottlenecks, keeping scope realistic, and questioning whether the stated problem is even the real one. Skipping this step is the fastest path to building the wrong thing.
The Friction Finder
- Acutely aware of where work feels slow, annoying, or repetitive
- Often the one who initiates the “we should automate this” conversation
- May not know how but is excellent at identifying what
Lean Manufacturing “waste” identification (Muda); Making Work Visible (DeGrandis)
The Bottleneck Spotter
- Thinks in flow and throughput
- Can identify where work piles up or waits
- Reads a process map and immediately sees the constraint
Theory of Constraints (Goldratt, The Goal); Drum-Buffer-Rope scheduling
The Scope Realist
- Keeps the team from boiling the ocean
- Asks “what’s the smallest version of this that still solves the problem?”
- Prevents over-engineering
Agile/Scrum MVP concept; “Walking Skeleton” pattern in software design
The Problem Reframer
- Challenges whether the stated problem is the actual problem
- Asks “why are we doing this at all?” before asking how to automate it
- Saves enormous rework
Design Thinking (Stanford d.school / IDEO) “reframe the problem” principle; Jobs To Be Done theory (Christensen)
3
DESIGN & LOGIC THINKING
Translating real-world processes into explicit logic before touching any tool
▼
This is where process knowledge becomes automation logic. These sub-archetypes think in structures like conditions, sequences, data flows, and failure modes without necessarily writing code. They turn vague verbal descriptions into explicit, testable logic that a builder can implement. This is the bridge between “we know how it works” and “we can automate it.”
The Decision Tree Builder
- Naturally thinks in if/then/else structures
- Can take a vague verbal description of a process and map it to explicit conditional logic without needing to code
Decision Theory; Business Process Model and Notation (BPMN) standards
The Data Modeler
- Thinks about what information flows through a process what it looks like coming in and what it needs to look like going out
- Cares about field naming and consistency across systems
Data Flow Diagrams (DFD); Entity-Relationship modeling; “Garbage In, Garbage Out” principle
The Workflow Choreographer
- Sees automation as a sequence of steps with dependencies
- Naturally thinks about order of operations, parallel vs. sequential work, and timing
Critical Path Method (CPM); PERT charts; Project Management Body of Knowledge (PMBOK)
The Edge Case Hunter
- Systematically asks “what could go wrong?” at every step before building rather than after
- Designs for resilience proactively
FMEA (Failure Mode and Effects Analysis); Defensive Programming; Pre-Mortem analysis (Gary Klein)
The Simplicity Advocate
- Allergic to complexity
- Always asking “can we do this with fewer steps?”
- Ensures maintainability over time
KISS Principle (“Keep It Simple, Stupid”) — US Navy design doctrine; Occam’s Razor; Lean “eliminate waste” philosophy
4
COMMUNICATION & TRANSLATION
Bridging the gap between process owners and builders
▼
Automation projects fail politically as often as they fail technically. This cluster covers the people who translate between worlds turning business language into technical requirements, managing stakeholder expectations, and making sure the work outlives its creator through training and documentation.
The Bridge Builder
- Translates between technical and non-technical team members
- Can explain a workflow to a developer and then explain the same thing in plain English to a business owner
Team Topologies (Skelton & Pais) “enabling team” concept; T-shaped skills model
The Stakeholder Whisperer
- Understands that automation projects fail politically as often as technically
- Manages expectations and keeps affected parties from becoming the automation’s enemies
Kotter’s 8-Step Change Model; Prosci ADKAR Model (Awareness, Desire, Knowledge, Ability, Reinforcement)
The Requirements Articulator
- Converts vague requests (“make this easier”) into specific, testable requirements
- Knows how to ask the right clarifying questions
Agile User Story format (“As a [user], I want [action] so that [outcome]”); INVEST criteria for requirements
The Trainer
- Not just able to use the automation once built, but capable of explaining it to others, writing the how-to, and onboarding new team members
- Ensures the work outlives its creator
Kirkpatrick Training Evaluation Model; “See One, Do One, Teach One” medical education framework
5
BUILDING & IMPLEMENTATION
Constructing automations using tools, AI, or both
▼
This is where the actual construction happens. But “building” in automation is broader than just coding. It includes rapid prototyping to test ideas, finishing the unglamorous last 20%, picking up new tools intuitively, leveraging AI as a building partner, and thinking across system boundaries. Not every builder writes code; many use low-code/no-code platforms and AI tools.
The Rapid Prototyper
- Gets something working quickly, even imperfectly, to test assumptions
- Values speed of learning over perfection
- Generates momentum and surfaces real problems early
Agile Sprint methodology; “Fail Fast” principle; Eric Ries, The Lean Startup Build-Measure-Learn loop
The Finisher
- Completes and polishes what the Rapid Prototyper leaves behind
- Gets the last 20% done
- Comfortable with unglamorous detail work
Pareto Principle (the 80/20 rule inverted — the last 20% takes 80% of the effort); Agile “Definition of Done”
The Tool Native
- Picks up new software quickly and intuitively
- Comfortable exploring platforms without step-by-step instruction
- Often self-taught and learns by doing
Technology Adoption Lifecycle (Rogers, Diffusion of Innovations) — Early Adopter profile
The AI Whisperer
- Knows how to get useful output from AI tools
- Understands prompt construction, context-setting, and iteration
- Uses AI as a thought partner rather than a search engine
Co-Intelligence (Mollick); Prompt Engineering as an emerging discipline; “Centaur” model of human-AI collaboration
The Integration Thinker
- Sees every tool as a potential data source or action target
- Thinks across system boundaries rather than within a single tool
- Naturally asks “what does this connect to?”
Enterprise Architecture (Zachman Framework); API-first design thinking; Event-Driven Architecture patterns
6
QUALITY & OVERSIGHT
Verifying automations work correctly, including failure scenarios
▼
Building an automation is only half the work. This archetype cluster covers the people who make sure it actually works; not just on the happy path, but with bad data, missing inputs, and unexpected failures. They also ensure there’s visibility into what’s running so problems don’t fail silently.
The QA Mindset
- Tests with the intent to break things
- Creates test cases that include bad data, missing data, and unexpected inputs
- Uncomfortable shipping anything without trying to make it fail first
Software Testing fundamentals; Equivalence Partitioning and Boundary Value Analysis; Agile Test-Driven Development (TDD)
The Auditor
- Asks “how do we know this is working correctly?” and “how will we know when it’s not?”
- Builds in logging, notifications, and checkpoints
- Thinks about accountability and visibility
COBIT (Control Objectives for Information Technologies); SOC 2 audit principles; Observability practices in DevOps
The Risk Modeler
- Evaluates what happens if an automation fails mid-run
- Thinks about rollback, error handling, and the cost of a broken automation vs. manual work
Risk Matrix (Probability × Impact); FMEA; ISO 31000 Risk Management standard
7
HUMAN & ORGANIZATIONAL AWARENESS
Managing adoption, resistance, ownership, and compliance
▼
The most technically perfect automation fails if no one uses it, if it violates a policy, or if no one maintains it after launch. This cluster covers the human side: the champions who drive adoption, the skeptics who improve outcomes by pushing back, the reluctant users whose confusion is a signal, the compliance voice who prevents regulatory disasters, and the ownership taker who keeps things running.
The Change Champion
- Enthusiastic early adopter who brings others along through energy and example
- Helps normalize new workflows and tools within team culture
Kotter’s 8-Step Change Model (Step 1: Create Urgency + Step 4: Enlist a Volunteer Army); Prosci ADKAR
The Skeptic
- Questions whether automation is the right answer
- Plays devil’s advocate on ROI, complexity, and unintended consequences
- A healthy skeptic improves outcomes — not the same as a blocker
Red Team / Blue Team methodology; “Premortem” analysis (Gary Klein); Critical Thinking frameworks
The Reluctant Participant
- Will use automation once it’s proven but won’t help build it
- Represents the average user, not the enthusiast
- Their confusion during testing is signal, not noise
Technology Adoption Lifecycle (Rogers) — Late Majority profile; User Acceptance Testing (UAT) stakeholder role
The Compliance Voice
- Asks “is this allowed?” and “what does this do with data?”
- Keeps the team from building something that violates a policy, regulation, or client agreement
GDPR / HIPAA / SOC 2 compliance frameworks; Privacy by Design principles (Cavoukian)
The Ownership Taker
- Assumes responsibility for an automation after it’s built
- Monitors it, maintains it, fields questions
- Without this archetype, automations become orphaned and break silently
RACI Matrix — “Accountable” role; DevOps “You Build It, You Run It” principle (Werner Vogels, Amazon)
8
STRATEGIC & VISION THINKING
Connecting automation work to measurable business outcomes
▼
Automation without strategy is just busywork. This cluster covers the people who connect individual automations to measurable business outcomes, drive organizational will, and see the big picture: how individual workflows fit into a larger connected system. Without these roles, teams build impressive automations that don’t move the needle.
The ROI Tracker
- Connects automation work to measurable outcomes
- Asks “how much time does this save?” and “how do we know?”
- Keeps the team focused on value rather than building for its own sake
OKR Framework (Doerr, Measure What Matters); Lean ROI measurement; Time-on-Task analysis
The Automation Evangelist
- Sees automation potential everywhere
- Energizes teams and sells the vision internally
- Drives ambition and organizational will — but needs a Scope Realist as a counterbalance
Diffusion of Innovations (Rogers) — Innovator profile; Kotter Change Model coalition building
The Systems Thinker
- Sees individual automations as part of a larger connected whole
- Thinks about how workflows interact, where data flows across systems, and what the architecture looks like at scale
- Prevents local optimization that creates global problems
Thinking in Systems (Meadows); Cynefin Framework (Snowden); Systems Dynamics (Forrester/MIT)
FRAMEWORK CITATIONS
The sub-archetypes are grounded in 16 established management, systems, and process frameworks:
| Framework | Source |
|---|---|
| Theory of Constraints | Eliyahu M. Goldratt & Jeff Cox, The Goal (1984) |
| Lean / Toyota Production System | Taiichi Ohno; Womack & Jones, Lean Thinking (1996) |
| Design Thinking | IDEO; Stanford d.school |
| Agile / Scrum | Agile Manifesto (2001); Schwaber & Sutherland, The Scrum Guide |
| Diffusion of Innovations | Everett M. Rogers (5th ed., 2003) |
| Kotter's 8-Step Change Model | John P. Kotter, Leading Change (1996) |
| Prosci ADKAR | Jeff Hiatt (2006) |
| RACI Matrix | Project Management Institute (PMBOK) |
| Team Topologies | Skelton & Pais (2019) |
| Cynefin Framework | Dave Snowden & Mary Boone, HBR (2007) |
| FMEA | US Military MIL-P-1629 (1949); widely adopted |
| Thinking in Systems | Donella H. Meadows (2008) |
| Co-Intelligence / AI Collaboration | Ethan Mollick (2024) |
| Tacit vs. Explicit Knowledge | Nonaka & Takeuchi (1995) |
| Jobs To Be Done | Clayton M. Christensen (2016) |
| Pre-Mortem Analysis | Gary Klein, HBR (2007) |
READY TO ASSESS YOUR TEAM?
Take the Archetypes of Automation self-assessment! It takes about 10 minutes and gives you a clear picture of where you and your team stand.
START THE ASSESSMENT