TSA Handbook¶

Technical Solution Architect Reference Guide Worksuite AWE (Agentic Workforce Era) | April 2026 | Internal

Unfamiliar term? See the AWE Glossary.

1. What Is a TSA?¶

A Technical Solution Architect is an individual contributor who builds. You extend the Worksuite Platform and Worksuite Services to solve real customer problems. You are not managed. You are not a resource on someone else's roadmap. You own technical work products end-to-end.

In the old model, an engineer waited for a product manager to write a PRD, a backlog to be groomed, a sprint to be planned, and a ticket to land in their lap. That's dead. In AWE, a BSA walks over with a customer problem, you design the technical approach together, and you start building. The entire cycle from "customer has a problem" to "solution ships" runs through two people: the BSA and you.

There is no engineering manager between you and the work. No product manager between you and the customer's need. No sprint planning between you and shipping.

What you own: - Technical design and implementation of platform extensions and service enhancements - Technical Solution Builds (TSBs) as Single Threaded Owner - Build Cycles (BCs), the atomic unit of shippable work - Platform Solution Builds (PSBs) when you spot patterns that call for platform investment

What you don't own: - Customer relationships (that's the BSA) - Prioritization of customer work (the BSA uses ICE for that) - Operational service delivery (that's Worksuite Services under the Head of Services and PayOps)

2. The BSA-TSA Loop¶

This is the core operating relationship in AWE. It replaces the old handoff chain of Account Manager → Product Manager → Engineering Lead → Sprint → Developer.

How It Works¶

 Customer Need                              Customer Solution
      │                                           ▲
      ▼                                           │
 ┌──────────────────┐     ┌──────────────────┐    │
 │  BSA              │     │  TSA              │    │
 │                   │     │                   │    │
 │  Hears customer   ├────►│  Creates TSB      │    │
 │  Designs solution │     │  Breaks into BCs  │    │
 │  using ICE        │◄────┤  Builds (DPEV)    │    │
 │  Delivers result  ├─────┼──────────────────►─┘    │
 └──────────────────┘     └──────────────────┘

One handoff. The BSA maintains customer context end-to-end. You maintain technical context end-to-end. Neither of you loses information to an intermediary.

The Loop in Practice¶

BSA brings the problem. They've talked to the customer, they understand the business need, they've framed it using ICE. They come to you with Intent, Context, and Evaluation criteria.
You discuss the technical approach together. This is the "Discuss" phase of DPEV. You push back on scope, suggest alternatives, identify platform capabilities that already exist. The BSA pushes back on technical choices that don't serve the customer outcome.
You build. The BSA doesn't disappear. They're available for questions, clarifications, and validation throughout the BC. But they're not hovering. You own execution.
You verify together. At the end of a BC, you and the BSA confirm the work meets the Evaluation criteria from the original ICE framing.
It ships. Every BC ends with a shipment. The BSA takes the solution back to the customer. If more BCs are needed, the loop continues.

Rules of Engagement¶

BSAs don't write tickets for you. They bring problems and context. You turn that into technical work.
You don't go directly to the customer. The BSA owns the customer relationship. If you need more context, ask the BSA.
Disagreements go through D3. If you and the BSA can't agree on approach, you Discuss, Debate, and Decide. If D3 doesn't resolve it, the CSA breaks the tie.
The BSA's ICE Spec is your input. It tells you Intent (what outcome), Context (what constraints), and Evaluation (how to measure done). You add technical Context and refine Evaluation criteria from a technical perspective.

3. Work Products¶

You own three types of work products. Each has strict time caps and clear ownership.

3.1 Build Cycle (BC)¶

The atomic unit of work. Max 3 days. Ships at the end.

A BC is a combination of Platform Features and/or Platform Fixes that can be completed and shipped within 3 calendar days. It follows the DPEV cycle. Every BC produces something deployable.

Attribute	Value
Time cap	3 days max
Owner	TSA
Lifecycle	DPEV (Discuss → Plan → Execute → Verify)
Output	Shipped code, deployed feature, or deployed fix
Scope	Must be completable and shippable in 3 days

Why 3 days? - Forces you to scope tightly. If it can't ship in 3 days, break it down further. - Reduces resource contention. You're never blocked on a 3-week chunk of someone else's time. - Enables fast failure. If the approach is wrong, you've lost 3 days, not 3 months. - Creates natural checkpoints for the BSA to validate direction.

Example BC:

BC: Add payment method validation for ADP integration - Discuss (2 hours): BSA explains ADP requires ACH validation before payroll submission. Review existing payment method API. - Plan (2 hours): Design validation endpoint, define acceptance criteria, identify test cases. - Execute (1.5 days): Build endpoint, write tests, integrate with existing payment flow. - Verify (half day): Run test suite, BSA validates against ADP requirements, deploy. - Ships end of day 3.

3.2 Technical Solution Build (TSB)¶

A collection of BCs that delivers a complete technical solution. Max 3 weeks. You are STO.

A TSB is created when a BSA's CSB requires technical platform or service work. It contains one or more BCs, each following DPEV independently. The 3-week cap is a hard constraint, not a suggestion.

Attribute	Value
Time cap	3 weeks max
Owner (STO)	TSA
Composition	One or more BCs
Trigger	BSA needs technical work for a CSB
Scope	Must complete within 3 weeks; if not, rescope

Why 3 weeks? - Prevents scope creep. If it's growing past 3 weeks, the scope was wrong. - Keeps work tied to a specific, deliverable customer outcome. - Forces you to break large efforts into multiple TSBs with clear boundaries.

Example TSB:

TSB: ADP Payroll Integration for Omnicom - BC 1 (days 1-3): Payment method validation endpoint - BC 2 (days 4-6): Payroll file generation in ADP format - BC 3 (days 7-9): Error handling and retry logic for ADP submissions - BC 4 (days 10-12): End-to-end integration testing and BSA validation - Ships at the end of BC 4. Total: ~2.5 weeks.

If you're on day 12 and realize you need another week, that's a red flag. Talk to the BSA. Either rescope the current TSB to ship what you have, or create a new TSB for the remaining work.

3.3 Platform Solution Build (PSB)¶

TSA-initiated platform investment. Multi-TSA collaboration for core modules or cross-module feature sets.

PSBs are how the platform evolves. They are not driven by a product team (there is none). They are driven by TSAs who see patterns across multiple CSBs that signal a platform capability is missing or inadequate.

Attribute	Value
Time cap	None (but comprised of time-capped TSBs/BCs)
Owner	One or more TSAs
Composition	TSBs → BCs (same hierarchy)
Trigger	TSA identifies platform gap from cross-CSB patterns
Scope	Core module additions or cross-module feature sets

PSBs are covered in detail in Section 8.

4. DPEV in Practice¶

Every Build Cycle follows DPEV. Not sometimes. Every time. It's the rhythm of how technical work happens in AWE.

Discuss¶

What it is: Align on what needs to be built and why. This is where the BSA's ICE framing meets your technical perspective.

Who's involved: You (TSA), the BSA, and anyone with relevant domain expertise (could include a Worksuite Services IC if their operational knowledge is needed).

What happens: - BSA presents the customer need and their ICE framing - You ask questions. Challenge assumptions. Identify technical constraints. - You surface existing platform capabilities that might already solve part of the problem - Together, you agree on the scope of this BC

Time budget: 1-3 hours. If Discuss is taking longer than half a day, the scope is too big. Break it down.

Example:

BSA: "Home Depot needs to validate contractor licenses before approving work orders. They want it integrated with the existing onboarding flow."

TSA: "We already have a document verification step in onboarding. Can we extend that, or does license validation have different rules?"

BSA: "Different rules. License types vary by state. They want real-time verification against state databases."

TSA: "Real-time verification against 50 state databases is a multi-TSB effort. For this BC, let's build the validation framework and integrate three states they care about most. We can add states in follow-up BCs."

BSA: "Works. Their top three are Texas, California, and Florida."

Plan¶

What it is: Define the technical approach, scope boundaries, and acceptance criteria.

Who's involved: Primarily you. BSA reviews acceptance criteria for alignment with customer needs.

What happens: - Define the technical design (keep it lightweight; this isn't a design doc that sits in a wiki) - List what's in scope and what's explicitly out of scope - Write acceptance criteria that map back to the Evaluation component of ICE - Identify dependencies or risks

Time budget: 1-4 hours. If you're spending a full day planning a 3-day BC, the ratio is off.

Agentic tooling in Plan: Use your AI agents to generate boilerplate, scaffold tests from acceptance criteria, research external API documentation, and draft technical approaches. The agent handles the mechanical parts; you handle the judgment calls.

Execute¶

What it is: Build the thing.

Who's involved: You. Your AI agents. Other TSAs if the BC requires it (rare for a single BC; more common in PSB contexts).

What happens: - Write code, configure services, build integrations - Lean on agentic tooling for code generation, test writing, documentation - Communicate blockers immediately (don't wait for a standup that doesn't exist) - If scope is shifting, loop in the BSA for a quick realignment

Time budget: 1-2 days. This is the bulk of the BC.

Verify¶

What it is: Confirm it works, meets acceptance criteria, and is ready to ship.

Who's involved: You, the BSA, and any relevant domain experts.

What happens: - Run the test suite - BSA validates against the original ICE Evaluation criteria - Fix anything that doesn't meet the bar - Deploy

Time budget: 2-4 hours. If verification is taking a full day, something went wrong in Plan or Execute.

The BC ships at the end of Verify. Not "goes to staging." Not "gets queued for release." Ships. If it can't ship, it's not done, and you either fix it within the BC window or carry it as a known gap into the next BC.

5. Using ICE for Technical Decisions¶

ICE (Intent, Context, Evaluation) isn't just for BSAs designing customer solutions. You use it for every significant technical decision.

Intent¶

What outcome are we trying to achieve?

This is not "build a REST endpoint." That's an implementation detail. Intent is the outcome. "Enable real-time license verification so Home Depot can approve contractors without manual review."

When a BSA brings you their ICE Spec, the Intent is already framed from a customer perspective. Your job is to translate that into technical Intent that serves the same outcome.

Technical Intent examples: - "Extend the payment processing pipeline to support ACH validation before payroll submission" - "Build a state-aware license verification framework that can scale across all 50 states incrementally" - "Reduce onboarding API response time from 4 seconds to under 500ms to support real-time UX"

Context¶

What do we know? What constraints exist?

This is where you add the most value. The BSA brings customer context. You bring technical context.

Technical Context includes: - Current platform architecture and relevant modules - Existing APIs, services, and data models that relate to the problem - Performance constraints, scaling concerns, security requirements - Third-party integrations and their limitations - Technical debt that affects the approach - What other TSBs or PSBs are in flight that might conflict or overlap

Evaluation¶

How do we measure success?

The BSA defines customer success criteria. You define technical success criteria. Both matter.

Technical Evaluation examples: - "License verification API responds in under 2 seconds for 95th percentile" - "All three target state databases have integration tests passing" - "Payment validation endpoint handles 500 concurrent requests without degradation" - "Zero regression in existing onboarding flow (existing test suite passes)"

Anchoring Technical Work to the Big 3 and FY26 Objectives¶

Platform investment is not self-justifying. Every TSB — and especially every PSB — ties back to Worksuite's Big 3 Metrics (ARR, eNPS, Operating Cash Burn) and at least one FY26 Annual Objective. Your Intent section names the anchor explicitly.

The Big 3 for technical work: - ARR — Does this build unblock customer ARR, reduce churn risk, or enable new revenue? - eNPS — Does this build reduce friction for the SA team or Worksuite Services? (Developer experience, tooling, reduced toil.) - Operating Cash Burn — Does this build reduce infrastructure cost, cut manual ops work, or improve efficiency?

FY26 Objectives: 1. Grow OMC/IPG by $1.0M ARR 2. Grow non-OMC AOR to $0.5M ARR 3. Release 10 EASI product releases 4. Launch rebrand + close 20 new customers 5. Improve Gross Dollar Retention to 90%

TSB anchor (BSA-driven): The parent CSB already names the anchor. Your TSB inherits it. Restate it in your technical Intent so the tie isn't lost in implementation.

PSB anchor (TSA-initiated): You own the anchor yourself. A PSB that can't be tied to an Objective or Big 3 metric should not start — no matter how elegant the architecture. Pattern-across-CSBs is the evidence; Objective advancement is the justification.

How to state the anchor in your ICE Spec:

"This PSB advances Objective 3 (EASI releases) and reduces Operating Cash Burn by eliminating ~40 hours/week of manual CompOps work across 12 customers. Pattern observed across 5 TSBs in the last quarter."

If you can't write a sentence like this, the build isn't ready. Kill it or refine the anchor.

When to Write an ICE Spec¶

Not everything needs a formal ICE Spec. Use judgment:

Situation	ICE?
Starting a new TSB	Yes. Your technical ICE Spec complements the BSA's customer ICE Spec.
Starting a BC within an already-scoped TSB	Usually no. The TSB's ICE covers it. Jot down BC-specific acceptance criteria.
Initiating a PSB	Yes. This is a platform investment decision. ICE is how you justify it.
Quick bug fix	No. Just fix it.
Technical design choice with trade-offs	Brief ICE framing in your head or a quick note. Enough to explain your reasoning if someone asks.

6. The D3 Framework for Peer Decisions¶

D3 (Discuss, Debate, Decide) is how peers make decisions without a manager to break ties. It applies to TSA-to-TSA decisions, TSA-to-BSA decisions, and cross-team resource allocation.

Discuss¶

Surface the decision that needs to be made. Get all relevant perspectives on the table. This is information gathering, not argumentation.

Example: Two TSAs both need access to the same staging environment for different TSBs this week.

Debate¶

Challenge each other's positions. Explore trade-offs. This is not conflict; it's collaborative pressure-testing.

Example:

TSA 1: "My TSB ships Thursday and the customer demo is Friday. I need the staging environment Monday through Thursday."

TSA 2: "My BC is a 2-day piece of work. If I get staging Monday-Tuesday, I'm done and it's all yours Wednesday."

TSA 1: "That works if you're confident you'll be done Tuesday. If it bleeds into Wednesday I'm blocked for the demo."

TSA 2: "I'll scope it to guarantee completion by Tuesday EOD. If I hit a blocker, I'll move to a different environment and free it up."

Decide¶

Reach consensus. In most cases, D3 resolves at this point because the people closest to the work have the best context.

When to escalate to the CSA: - You've gone through Discuss and Debate and genuinely can't reach consensus - The decision has org-wide implications (e.g., a PSB that would lock up three TSAs for weeks) - Resource contention affects multiple customer commitments and you can't resolve the priority

The CSA is a tiebreaker, not an approver. You don't escalate to get permission. You escalate because peers with equal context reached an impasse.

7. A Typical Day and Week¶

There are no standup meetings. No sprint ceremonies. No status update meetings. Your calendar should be mostly empty blocks for building.

Typical Day¶

Time	Activity
Morning	Check if any BSAs need Discuss time for new work. Review overnight CI results. Pick up your current BC where you left off.
Midday	Execute. Build. Your agents handle boilerplate, tests, and documentation while you handle architecture and judgment calls.
Afternoon	Continue execution. If you're in Verify, loop in the BSA. Ship if the BC is complete.
End of day	If a BC shipped, note what was done. If mid-BC, know exactly where you'll pick up tomorrow.

Typical Week (During a TSB)¶

Day	Activity
Monday	Start BC. Discuss + Plan with BSA (morning). Begin Execute (afternoon).
Tuesday	Execute. Deep build day.
Wednesday	Execute + Verify. Ship BC. If the TSB has another BC, begin Discuss for the next one.
Thursday	Start next BC. Discuss + Plan (morning). Execute (afternoon).
Friday	Execute + Verify. Ship BC. Reflect on TSB progress. Flag any scope risks for the following week.

Two BCs per week is the natural rhythm. Some weeks you'll do one complex BC. Some weeks you'll do three smaller ones. The 3-day cap is the constraint; the actual pace varies.

Typical Week (Between TSBs)¶

Day	Activity
Monday-Tuesday	Review patterns across recent TSBs. Is there a PSB opportunity? Talk to other TSAs. Contribute to an active PSB if one needs your module expertise.
Wednesday	BSA brings new CSB that needs technical work. Discuss phase.
Thursday-Friday	Plan + begin first BC of the new TSB.

You won't always have a TSB in flight. The gap between TSBs is productive time: PSB contributions, platform improvements, tooling enhancements, knowledge sharing with other TSAs.

8. Initiating a PSB¶

Platform Solution Builds are how the platform gets better. They are not driven by a product roadmap (there is no product team). They are driven by you.

Recognizing the Signal¶

You'll start seeing the same pattern across CSBs and TSBs:

"I built a custom license verification integration for Home Depot. Now Omnicom needs the same thing with slight variations."
"Three different TSBs this quarter have needed custom payment validation logic. The platform should handle this natively."
"Every BSA is asking for configurable approval workflows, and every TSA is building them from scratch each time."

When you see the same problem solved three times with custom code, that's a PSB signal. The platform needs a module.

How to Initiate¶

Frame it with ICE.
Intent: "Build a configurable license verification module so TSAs stop building one-off integrations and BSAs can offer it as a standard capability."
Context: "Three CSBs in Q1 required license verification. Each took a separate TSB. The Home Depot version and the Omnicom version share 70% of their logic."
Evaluation: "Module supports configurable state rules. New state integration takes one BC instead of a full TSB. Existing integrations migrate to the module."
Talk to other TSAs. A PSB often spans multiple platform modules. Find the TSAs who built the one-off versions. They have the deepest context on what a general solution needs.
Use D3 for resource allocation. A PSB pulls TSAs away from customer-driven TSBs. This is a trade-off. Use D3 among peers to decide timing. If there's contention, escalate to the CSA.
Structure it like any other work. A PSB is composed of TSBs, which are composed of BCs. Same time caps. Same DPEV cycle. The only difference is the trigger (TSA-identified platform gap vs. BSA-identified customer need).

PSB vs TSB: When Is It Which?¶

Signal	Work Product
Single customer needs a specific technical capability	TSB (within a CSB)
Multiple customers need similar capabilities and you're building one-offs	PSB
You're extending an existing platform module for one use case	TSB
You're building a new platform module or significantly extending one for general use	PSB

9. STO Responsibilities¶

STO (Single Threaded Owner) is not a title. It's a responsibility you hold for a specific work product. When you're STO of a TSB, you own it. When the TSB is done, you're not an STO anymore (until you pick up the next one).

What STO Means¶

Decision authority. You make final technical calls for this work product. You don't need approval from a manager (there is none) or a product lead (there is none).
Accountability. If the TSB ships late, ships broken, or doesn't meet the BSA's Evaluation criteria, that's on you.
Coordination. If multiple people are contributing to your TSB (rare for a single TSB, common for a PSB), you coordinate their work. You don't manage them. You align their BCs.
Communication. The BSA and other stakeholders know the status because you keep them informed. Not through status reports, through the natural rhythm of BC completions and Discuss/Verify touchpoints.

What STO Does NOT Mean¶

You are not a manager. You don't do 1:1s, performance reviews, or career planning.
You are not a tech lead. You don't own a team. You own a work product.
You are not permanent. STO rotates with work products. The TSA who was STO on the last PSB might be a contributor on the next one.
You don't assign work to other TSAs. In a multi-TSA PSB, you coordinate and align. Each TSA owns their own BCs.

STO Across Work Products¶

Work Product	Who Is STO	Scope of Authority
TSB	Single TSA	Technical decisions, BC scoping, ship timing within the 3-week cap
PSB	Initiating TSA (or agreed-upon lead)	Architecture decisions, TSB decomposition, cross-TSA coordination
BC	The TSA doing the BC	Implementation decisions within the BC scope

10. Agentic Tooling Expectations¶

TSAs in AWE are expected to leverage AI agents as core tools. This is not optional and it's not a nice-to-have. Agentic tooling is a force multiplier that makes the 3-day BC cap realistic for work that would have taken 2-3 sprints in the old model.

What Agents Handle¶

Task	How Agents Help
Code generation	Scaffold modules, write boilerplate, generate CRUD operations, implement known patterns
Test writing	Generate test cases from acceptance criteria, write unit and integration tests, identify edge cases
Code review	Automated review for patterns, security issues, style consistency
Documentation	Generate API docs, write technical notes, update platform documentation
Research	Explore third-party APIs, find existing platform code that solves part of the problem, review past TSBs for reusable patterns
Debugging	Trace errors, analyze logs, suggest fixes

What You Handle¶

Task	Why It's Yours
Architecture decisions	Judgment calls that require understanding the full platform context
Trade-off evaluation	Agents can list options; you decide which trade-offs are acceptable
Customer context interpretation	Understanding why the BSA needs something a certain way
Quality judgment	Agents write code; you decide if the code is right for the platform
Cross-system impact	Understanding how your change affects other modules, other TSBs, other customers

The Expected Workflow¶

Discuss/Plan: Use agents to research existing platform code, draft technical approaches, and scaffold acceptance criteria.
Execute: Use agents to generate code, write tests, and handle mechanical implementation. You architect, review, and steer.
Verify: Use agents to run test suites, generate documentation, and flag potential issues. You and the BSA make the ship/no-ship call.

A TSA who isn't using agents effectively is operating at half speed. The 3-day BC cap assumes agentic augmentation. If you're writing every line of code by hand and manually running every test, you'll miss the window.

11. Working with Worksuite Services¶

Worksuite Services (owned by the Head of Services and PayOps, Cristin) encompasses Payment Operations, Compliance Operations, and Help Desk. These teams are ICs with deep domain expertise in operational areas of the platform.

How Worksuite Services Contributes to Your Work¶

Worksuite Services team members contribute to Build Cycles and Platform Solution Builds based on their technical expertise. They are not a separate silo. They're domain experts who know the operational side of the platform better than anyone.

When to pull in Worksuite Services:

Scenario	Example
A BC touches payment processing logic	Loop in a Payment Operations IC. They know the edge cases, the compliance requirements, and the operational impact.
A PSB affects compliance workflows	A Compliance Operations IC should be in the Discuss and Verify phases.
A TSB changes how Help Desk interacts with the platform	Include a Help Desk IC in the Plan phase so the operational impact is understood.
You need operational data to validate your approach	Worksuite Services has the production context: what breaks, what customers complain about, what the actual usage patterns look like.

The Relationship¶

You lead the technical work. Worksuite Services contributes expertise, not direction.
They contribute to BCs. A Payment Operations IC might own specific tasks within your BC if the work is in their domain.
They contribute to PSBs. If a PSB touches operational workflows, relevant Worksuite Services ICs should be part of the contributing TSA team.
They don't file tickets with you. If Worksuite Services identifies a platform issue, they bring it to a TSA through the same Discuss pathway a BSA would. The TSA then decides how to handle it (BC within an existing TSB, new TSB, or PSB if there's a pattern).

What Worksuite Services Is NOT¶

Not professional services. Client implementations and solution delivery are owned by BSAs.
Not a separate engineering team. They contribute domain expertise to builds; they don't run parallel build processes.
Not a ticket queue. Operational issues flow through ICE and DPEV like everything else.

Quick Reference¶

Time Caps¶

Work Product	Cap	Enforced By
BC	3 days	Self-discipline. If it's not shipping in 3 days, the scope is wrong.
TSB	3 weeks	If you're approaching the cap, talk to the BSA. Rescope or start a new TSB.
PSB	No fixed cap	But comprised of capped TSBs and BCs, so scope is naturally bounded.

Frameworks¶

Framework	What It Does	When to Use It
ICE	Frames decisions (Intent, Context, Evaluation)	Starting a TSB, initiating a PSB, making trade-off decisions
DPEV	Structures build execution (Discuss, Plan, Execute, Verify)	Every BC. Every time.
D3	Resolves peer disagreements (Discuss, Debate, Decide)	Disagreements with BSAs, other TSAs, or resource contention

What Doesn't Exist¶

Old World	AWE
Sprint planning	Start building. BCs are your cadence.
Backlog grooming	There is no backlog. BSAs bring work when customers need it.
PRDs	ICE Specs. Written by the people doing the work, not a middleman.
Engineering managers	You manage your own work. STO when you own a work product.
Product managers	BSAs + TSAs + ICE + agents replace the function entirely.
Status update meetings	Ship at the end of every BC. That's your status update.

Glossary¶

See AWE Glossary for canonical definitions.

Part of the AWE reference library. Companion to org/awe-org-design.md.