Onboard an executive assistant in a remote-first startup

Assistant onboarding

Key takeaways

• Teach business context and executive preferences through real decisions, not a document dump.
• Expand delegated authority in observable stages with written boundaries.
• Review corrections as system feedback instead of hiding early uncertainty.

Operating data

Playbook

The first week for a remote executive assistant should not be a tour of every tool the startup owns. It should establish how the executive makes decisions, where reliable context lives, what the assistant may do, and how uncertainty is escalated.

Before day one: prepare accounts with least-necessary access, a role outcome statement, communication norms, an organization map, recurring-meeting inventory, and a short glossary. Name one onboarding owner. Test the new hire’s access without sending live customer, employee, financial, or investor material through an unapproved channel.

Days one through three: teach the executive’s operating landscape. Walk through current priorities, protected relationships, major deadlines, and known risks. Pair each topic with a real artifact and explain which source is authoritative. Ask the assistant to summarize the context back; misunderstandings are valuable when discovered before delegated action.

Days four through ten: practice in shadow mode. The assistant drafts a daily agenda, classifies a sample inbox set, prepares one meeting packet, and converts meeting notes into proposed actions. The executive or onboarding owner reviews the reasoning, not just the final formatting. Use the remote assistant onboarding guide to structure preference capture without pretending preferences are permanent rules.

Weeks three and four: transfer bounded lanes. For each lane, document what the assistant may complete, what needs approval, what must always escalate, and what evidence closes the task. Start with reversible work and observed patterns. Do not expand authority merely because the executive is busy.

Maintain a correction log with the situation, assumption, intended rule, correction, and system change. The purpose is not to score the new assistant. It reveals missing context, conflicting sources, unclear authority, and training gaps. Retire a correction only after the relevant checklist, template, or rule has been updated.

GitLab’s remote onboarding guidance illustrates the value of documented responsibilities, asynchronous resources, and deliberate connection in a distributed environment. Adapt practices to the startup’s actual tools, policies, and employment requirements rather than copying another organization’s handbook.

At 30 days, review outcomes: decisions prepared with enough context, calendar or inbox corrections, commitments closed, risks escalated appropriately, and relationships handled with care. Agree on the next authority lanes and learning goals. Teams needing structured implementation can use hiring and onboarding support. Good onboarding creates safe independence, not instant access to everything.