Building and managing an AI team
Build backup coverage that someone has actually demonstrated.
In this lesson · 06 of 7
All lessons in this track →Saved in this browser. View your learning.
Start with the idea
Build backup coverage that someone has actually demonstrated.
Name the critical functions and their owners. Give backups a chance to perform the work, not only read the documentation. Keep decision authority distinct from technical implementation.
Single point of failure: A person or component whose loss can prevent the required work from continuing.
See the example and check your understanding
A made-up teaching example
One engineer owns search, releases and recovery. The backup can read code but cannot restore the index. Pair them on a training restoration and record what still cannot be done.
Ask yourself
Does having a backup’s name in a document prove recovery coverage?
Show the explanation
No. Use observable restoration evidence. A new title does not remove the dependency.
Start with these checks
- Name owners and backups.
- Test restoration with the backup.
- Use the documented release-decision process.
Use the different practice case below and check every requirement in its full instructions.
The video explains the main idea. Use the sources, instructions and checks below to complete the practice.
Captions appear here during playback.
Building and managing an AI team
Build backup coverage that someone has actually demonstrated.
Video playback is unavailable. Read the descriptive transcript below, go directly to practice, or open the video file.
Source-based teaching example · Fictional data · Reviewed 2026-10-03. Microsoft Mark · locally synthesized. On a small screen, use fullscreen for diagram details or read the transcript.
Read the descriptive transcript
0:00 · What you will learn
Build backup coverage that someone has actually demonstrated.
What appears on screen
Build backup coverage that someone has actually demonstrated.
0:06 · The idea
Name the critical functions and their owners. Give backups a chance to perform the work, not only read the documentation. Keep decision authority distinct from technical implementation.
What appears on screen
Name the critical functions and their owners. Give backups a chance to perform the work, not only read the documentation. Keep decision authority distinct from technical implementation.
0:21 · One useful term
Single point of failure. A person or component whose loss can prevent the required work from continuing.
What appears on screen
A person or component whose loss can prevent the required work from continuing.
0:30 · A worked example
One engineer owns search, releases and recovery. The backup can read code but cannot restore the index. Pair them on a training restoration and record what still cannot be done.
What appears on screen
One engineer owns search, releases and recovery. The backup can read code but cannot restore the index. Pair them on a training restoration and record what still cannot be done.
0:45 · Your turn to think
Does having a backup’s name in a document prove recovery coverage? Pause and decide before continuing.
What appears on screen
Does having a backup’s name in a document prove recovery coverage? Pause the video if you need more time.
1:03 · Why this answer works
No. Use observable restoration evidence. A new title does not remove the dependency.
What appears on screen
No. Use observable restoration evidence. A new title does not remove the dependency.
1:12 · Check 1
Name owners and backups.
What appears on screen
Name owners and backups.
1:17 · Check 2
Test restoration with the backup.
What appears on screen
Test restoration with the backup.
1:22 · Check 3
Use the documented release-decision process.
What appears on screen
Use the documented release-decision process.
1:28 · Now try a different case
Open the lesson and try its different practice case. Use every check in the full task. Watching alone does not mark the lesson complete.
What appears on screen
Open the lesson Try the new case Check and revise The full task and its requirements are in the linked lesson.
Watching explains the example. Complete the lesson practice to check what you can do. Explore all visual lessons →
Build coverage around responsibilities. Build a judgment you can explain and a result another reader can inspect.
Prerequisites: know the difference between generated text and source evidence. For configuration vocabulary, use the AI workflow reference. This is public self-study, not official government training, accreditation, a clearance or a professional credential.
Observable outcomes: Map responsibility and backup coverage; design a restoration exercise and a fair synthetic work-sample rubric.
Part 1 Build coverage around responsibilities
An operational team needs mission/product ownership, application engineering, data/retrieval stewardship, evaluation, operations and appropriate security, privacy, accessibility, legal and acquisition interfaces. These are responsibilities, not a mandatory headcount or hiring order. Research-heavy work may need scientists early; a bounded prototype may combine roles. Document gaps and conflicts instead of declaring one org chart universal.
Evaluate candidates with a bounded synthetic work sample, a published rubric and reasonable accessibility accommodations. Ask them to explain a failure, verify a citation, compare deployment options and show a rollback plan. Public portfolio absence does not prove lack of skill; protected work may not be publishable. Compare observable task evidence rather than stereotypes, credentials alone or unsupported salary ratios.
Prevent single-person dependencies with paired ownership, tested runbooks, reviewer capacity and fair on-call coverage. SkillBridge is an authorized transition-training program with applicable rules, not “free labor” or a guaranteed hiring pipeline. Retention discussions should address workload, development, mission fit and compensation through legitimate processes.
Part 2 Synthetic worked example
Fictional team: one engineer owns retrieval, release keys and incident recovery. A second engineer can read the code but cannot restore the index. Pair them on a synthetic restoration exercise, move release authority to the documented process and record the missing recovery evidence. Adding a title does not fix the dependency.
Guided practice: write the tempting conclusion first, then underline the fact that does not support it. Rewrite the conclusion with that limitation visible. Identify one additional observation that would change the decision.
Next step: carry your artifact into the 180-day evidence plan in lesson 07; retain assumptions and unanswered questions.