Canonical page: https://samuelawonorin.com/books/signal-architecture/templates/ Copy these Markdown templates into Notion, Google Docs, Word, or your team workspace.
How To Use These Templates
Start with one painful workflow. Do not redesign the whole organization first.
Use this order:
- Start Here Under Pressure - for urgent confusion, duplicated work, stalled decisions, or a team that needs relief before Monday.
- Red Flag / Green Flag Checklist - to identify the weakest signal pillar.
- Team API Contract - when people do not know how to engage a team, request help, escalate, or find the final answer.
- Operational Signal Incident Post-Mortem - after a missed decision, communication failure, duplicated effort, or avoidable escalation.
- Before / After Workshop Worksheet - when you want a group to redesign one workflow together.
- Telemetry Mapping Guide - only after you know what pain you want to measure.
Recommended workshop flow:
- Pick one workflow that hurt recently.
- Describe the pain in plain workplace language.
- Map the signal, route, owner, state home, and feedback loop.
- Identify the weakest pillar.
- Choose one Monday-morning experiment.
- Assign one owner and one review date.
Simple rule: if a template does not help people act more clearly within one week, simplify it.
Use this when your team is already in pain and you need one repair before Monday.
Source: Signal Architecture by Samuel Awonorin
Painful workflow
What keeps repeating?
Who feels the pain?
What did this cost?
Signal map
Signal: What did someone need to know?
Route: Where should it have gone?
Owner: Who should have acted?
State: Where should truth live?
Feedback: How should the sender know the system responded?
First Monday-morning experiment
What will we change for one week?
Who owns it?
How will we know it helped?
When will we review?
Define how a team should be engaged so collaboration stops depending on guessing.
Source: Signal Architecture by Samuel Awonorin
Identity
Team
Purpose
Boundaries
What we own
What we do not own
Inputs and outputs
Inputs required before asking for help
Outputs we provide
Routes
Urgent route
Normal route
Decision route
Documentation/state home
Operating expectations
Response expectations
Escalation rules
Dependencies
Feedback loop
Score system health and repair the weakest pillar first.
Source: Signal Architecture by Samuel Awonorin
Scoring scale
1 = broken
2 = weak
3 = functional but fragile
4 = strong
5 = elite
Pillars
Signal Integrity: Do people interpret important messages consistently?
Signal Routing: Does the message reach the right owner?
Signal Latency: How long before information becomes action?
Signal Redundancy: What happens when someone misses the first signal?
Signal Amplification: Do leaders make priorities unmistakable?
Interpretation
Total score
Weakest pillar
Next repair
A practical diagnostic for seeing whether each pillar works in daily behavior.
Source: Signal Architecture by Samuel Awonorin
Signal Integrity
-
Red flag: Three managers explain the same policy in three different ways.
-
Green flag: People can repeat the expected output without needing the sender in the room.
Signal Routing
-
Red flag: Important requests are posted to a broad group chat with no named owner.
-
Green flag: Every important request has one owner, one route, and one next review time.
Signal Latency
-
Red flag: A decision thread stays open for more than two working days without resolution.
-
Green flag: Owners post a decision, deadline, or blocker within the agreed response window.
Signal Redundancy
-
Red flag: The team searches chat for more than five minutes to find last week?s decision.
-
Green flag: Every important meeting ends with the decision recorded in the agreed source.
Signal Amplification
-
Red flag: Teams can name five priorities but cannot name the current priority.
-
Green flag: Leaders repeat the few signals that matter until trade-offs become obvious.
Measure signal problems without turning work into surveillance.
Source: Signal Architecture by Samuel Awonorin
Principle
Track only signals that help leaders act. Use telemetry as pain detection.
Metrics to count
Clarification loops
Decision latency
Attention thrashing
Stale decisions
After-hours escalation volume
Attention error budget
- Starting hypothesis: reserve up to four hours per person per week for systemic noise.
Treat this as a calibration point, not a law.
Review communication failures without turning the review into blame.
Source: Signal Architecture by Samuel Awonorin
Incident basics
Incident title
Date
Human impact
What happened
What was supposed to happen?
What actually happened?
Timeline
Signal created
Signal noticed
Ownership clarified
Action completed
Route and state
Expected route
Actual route
State failure
Human edge case
Did fear, ego, politeness, fatigue, time zone, trust, or unclear authority affect the path?
Repair
Owner
Route
State home
Trigger
Feedback loop
A worked example readers can copy before adapting to their own team.
Source: Signal Architecture by Samuel Awonorin
Identity
-
Team: Product Management - Payments Platform
-
Purpose: Translate customer, commercial, regulatory, and operational needs into clear product decisions.
Boundaries
-
What we own: product priorities, roadmap trade-offs, customer-impact decisions, release scope, product requirements.
-
What we do not own: engineering estimates, legal interpretation, commercial pricing approval, support staffing decisions.
Routes
-
Urgent route: customer-risk, compliance, revenue, or executive-commitment items enter the escalation channel.
-
Normal route: discovery and prioritization requests enter the product intake board.
-
State home: product decision log, roadmap board, release notes, and customer-impact register.
A worked post-mortem for customer renewal risk lost in parallel channels.
Source: Signal Architecture by Samuel Awonorin
Incident basics
-
Incident title: Customer renewal risk lost in three parallel channels.
-
Human impact: customer success felt exposed, sales felt blindsided, product felt unfairly blamed.
Timeline
-
Signal created: Monday 09:20.
-
Signal noticed: Monday 11:40.
-
Ownership clarified: Tuesday 15:00.
-
Action completed: Wednesday 14:00.
Repair
-
Owner: account manager owns renewal-risk escalation until closed.
-
Route: one renewal-risk route for customer success, sales, and product.
-
State home: customer-impact register.
Turn one painful workflow into a first Monday-morning experiment.
Source: Signal Architecture by Samuel Awonorin
Workflow to inspect
Workflow name
Why this workflow matters
Who feels the pain?
Legacy way
Where does the request enter?
Who sees it?
Who owns it?
Where does truth live?
Where does it stall?
Signal Architecture way
What is the signal?
What route should it follow?
Who owns action?
Where does state live?
What triggers escalation?
Commitment
First Monday-morning experiment
Owner
Review date
Make hidden dependencies visible before they become late-stage surprise.
Source: Signal Architecture by Samuel Awonorin
Workflow
Workflow name
Desired outcome
Deadline or decision point
Dependency questions
Who must provide input?
Who can approve?
Who can block?
Who needs to be informed?
Who owns final state?
Warning signs
If the answer is everyone, the route is not designed.
If the answer is the manager, the manager may be a bottleneck.
Choose the right channel for the signal.
Source: Signal Architecture by Samuel Awonorin
Channel rules
Use chat for quick coordination, not final truth.
Use documents for persistent state.
Use meetings for ambiguity, conflict, sensitive judgement, and high-bandwidth alignment.
Use dashboards for status that changes often.
Use email when a durable formal record is useful.
Decision prompt
What is the signal?
How complex is it?
How emotionally loaded is it?
How urgent is it?
Where should final state live?
Prevent meetings from creating discussion without durable decisions.
Source: Signal Architecture by Samuel Awonorin
Before the meeting ends
What changed?
Who owns the next action?
When is the action due?
Where will the decision live?
Who must be told after the meeting?
Failure test
If those five things are missing, the meeting may have created discussion without creating state.
A lightweight adoption path for turning Signal Architecture into operating behavior.
Source: Signal Architecture by Samuel Awonorin
First 30 days
Choose one painful workflow.
Map signal, route, owner, state, and feedback.
Run the Red Flag / Green Flag Checklist.
Pick one Monday-morning experiment.
Days 31-60
Turn the first repair into a lightweight operating agreement.
Create or update the Team API Contract.
Add one telemetry measure.
Days 61-90
Run the scorecard.
Repair the weakest pillar.
Retire one old workaround.