Engineer Onboarding

Companion to time-tracking-and-billing.md and engagement-lifecycle.md. This doc is the first-week (and first-month) playbook for a new Meseta engineer. It's structured chronologically rather than by topic — for topic reference, see the other handbook docs.

Two audiences: the engineer, who reads this to know what to expect, and the founder/PM, who reads this as a checklist for what they need to do to set the engineer up for success. Owner is marked on each item.

What working at Meseta is like

Before the mechanics, the shape of the relationship.

Meseta is a boutique consulting firm. That word matters: we sell a small number of expert hours at a premium rate to clients who care about quality. We do not sell bodies. Every engineer is expected to operate at a senior level — making technical decisions, communicating with clients directly when needed, and exercising judgment without waiting for permission.

You are a 1099 contractor. This means:

• You set your own schedule and tools (within client constraints)
• You're responsible for your own taxes, benefits, and equipment
• You're not guaranteed hours. We commit to bringing you work when we have it; you commit to delivering the work when we do.
• You can take other clients (subject to non-compete language in your contract)

About hours, specifically. We agree on a target — "about X hours per week" — when you start. That target is not enforced week to week. Some weeks you'll do more, some less. The expectation is:

• If there's plenty of work and you're consistently under target, we'll have a conversation
• If there's a slow week and we have nothing for you, that's our problem, not yours — we won't ask you to manufacture hours
• We'll be transparent with you about pipeline so you can plan your own schedule and other commitments

This is the core of the trust relationship. We won't lie to you about how much work is coming. You won't pad your hours. We'll both be adults about it.

Right now Xenter is the dominant engagement and there is, frankly, a mountain of work. The "no guarantee" language is real, but the practical reality for the foreseeable future is that there's more work than capacity.

About the firm. Meseta is small and intentionally so. The bar for who works here is high. You being here means we believe you can operate at this bar. That's not flattery — it's information about how we'll treat you. We won't micromanage. We will expect you to flag issues early, communicate proactively, and own outcomes.

Before day one (founder/pm prep)

Things Meseta does before the engineer's first day. The engineer should not have to chase any of this.

• [ ] Founder: Contract signed (1099 agreement, NDA if separate)
• [ ] Founder: Engineer's pay rate documented in their contract
• [ ] Founder: Engineer added to rates.yaml in the ops repo (bill rate, pay rate, engagement assignments)
• [ ] PM: Toggl Track Premium seat provisioned, invitation sent
• [ ] PM: Slack workspace invitation sent (Meseta workspace)
• [ ] PM: Meseta vault access (read-only initially) — handbook/ directory shared
• [ ] PM: Calendar invite for kickoff call (founder + PM + engineer, 45 min)
• [ ] Founder or Lead: Engagement context doc shared (what's the work, who's the client, what's the current state)
• [ ] Founder: Client-side access provisioning kicked off (this often has lead time — start a week early). For Xenter: GitHub, Azure, any compliance-required onboarding.
• [ ] PM: First Toggl project assignment configured with correct rate overrides

Engineer should arrive day one with everything they need to log a billable entry by lunch.

Week one

Day one — kickoff and orientation

Kickoff call (45 min, founder + PM + engineer):

• Walk through the firm: what Meseta is, what it isn't, what we sell, how we work
• Walk through the engagement: which client, which track, who the lead is, what the immediate work is
• Walk through the handbook: time tracking policy, engagement lifecycle, this doc
• Q&A — block real time for this. New engineers always have questions they're afraid to ask later.

Reading list (engineer, ~1 hour):

• This document
• time-tracking-and-billing.md
• engagement-lifecycle.md
• branding.md — context on who Meseta is and how we present
• Engagement-specific brief (founder shares)

Tooling setup (engineer, ~1 hour):

• [ ] Install Toggl Track desktop app (Mac or Windows)
• [ ] Sign in, verify access to Meseta workspace
• [ ] Verify the assigned project shows up with correct billable defaults
• [ ] Install Toggl browser extension (optional, but recommended)
• [ ] Join Meseta Slack workspace; introduce self in #general
• [ ] Bookmark the Meseta vault handbook/ directory

First time entry (by end of day): Even if it's just 30 minutes of "Meseta onboarding — kickoff call and tooling setup" against a non-billable internal project. Track from day one. The habit forms on day one or it doesn't form.

Days two through five — first billable work

Goal: ship something useful for a client by end of week.

• [ ] Engineer is introduced to client team (lead handles the introduction)
• [ ] Client-side access verified working
• [ ] First task or scope identified by lead
• [ ] First billable time entries logged
• [ ] First Friday submit (per time-tracking-and-billing.md) — even if it's a partial week

Founder/PM check-in (Friday, 15 min):

• How's it going?
• Any access issues we haven't resolved?
• Any expectations that don't match reality?
• Tooling friction?

This is the most important check-in of the entire onboarding. Surface friction early — it's never cheaper to fix than in week one.

Time tracking — what good looks like

The single thing that most affects engineer experience and invoice quality is the description field on Toggl entries. Here's what we mean by good and bad:

Good descriptions

• "Argo CD app-of-apps refactor for pi-core — extracted shared base config"
• "PHI vault threat model review with Xenter security team"
• "GitHub Actions security scanning rollout — repos 4–7"
• "Pairing with @engineer on Confidential AKS attestation issue"
• "Triaged P1 alert on data-pipeline ingest, root-caused to expired cert"
• "Weekly client sync — covered milestone status, open scope questions"

Good descriptions are:

• Specific enough that you'd recognize what you did when reading it three months later
• Recognizable to the client as work they'd value
• A complete thought (a fragment, not necessarily a sentence)

Bad descriptions

• "work"
• "infra stuff"
• "meeting"
• "Xenter" (the project field already says that)
• "various"
• "emails and slack"
• blank

Bad descriptions become bad invoice line items, which become awkward client conversations and reduced trust. A 30-second tax on each entry to write a real description prevents 30 minutes of client cleanup later.

When in doubt

• Round to 15 minutes. Smaller blocks fold into adjacent ones or into a daily admin/comms entry.
• Mark billable if it's client-facing or client-deliverable work. Mark non-billable for Meseta internal work, your own learning, and unpaid kickoff time written into the SOW.
• Backfill within 48 hours. Past that, add a note in the description: "logged Wednesday — was traveling."
• Tag the work category. Flat tag namespace: cloud, platform, it, security, meeting, docs, ops, architecture, code-review, support. Multiple tags are fine.

If you're uncertain about a category or whether something is billable, ask in #meseta-billing Slack — that's why the channel exists.

Communication — what's expected

Meseta clients don't want to be surprised, and Meseta engineers don't want to be alone with a problem. Two sides of the same coin.

With clients

• Day-to-day: the lead handles client-facing technical decisions in the engagement Slack or your equivalent channel. Engineers can and should respond to client messages directly when in their lane.
• Weekly: PM publishes the weekly status update. Engineers may be asked to contribute a few sentences about their week's work.
• Strategic / contractual: founder owns. If a client raises something contractual, scope-change-shaped, or budget-related, route to founder rather than answering directly.

When in doubt about whether to engage or escalate, escalate. It is much easier to step back than to walk back.

Within Meseta

• #general: firm-wide
• #meseta-billing: time tracking, rate questions, invoicing
• #{engagement-name}: per-engagement internal channel (Meseta-only, not client-facing)
• DM the founder or PM: anything sensitive or urgent

We do not have a strong meeting culture. Async-first. If you need a synchronous conversation, schedule one — but most things are better written.

Scope and judgment

Two principles that matter more than any specific rule:

Flag scope changes. If a client asks for something outside the SOW — even if it's "just a small thing" — note it in the engagement's scope-changes.md and tag the founder. Most of the time the answer is "yes, do it." But the founder needs the trail. See engagement-lifecycle.md for the protocol.

Use your judgment, then document it. We hired you for your judgment. Make calls. If you're not sure, make the call you think is right and write down why. Bad decisions made in good faith with documented reasoning are recoverable. The unrecoverable mistake is to wait for permission and miss the moment.

Pay and 1099 mechanics

• Bill rate vs. pay rate. Meseta bills the client at one rate, pays you at another. The spread covers Meseta overhead, business development, and margin. Your pay rate is documented in your contract.
• Payout cadence. Once a client invoice is paid (typically 15–30 days after we send it), Meseta calculates and pays your share. Payouts go out monthly via Mercury ACH, usually mid-month for the prior month's collected invoices.
• Tax responsibility. You're a 1099 contractor. You're responsible for your own quarterly estimated taxes, self-employment tax, and any business expenses you want to deduct. Meseta files a 1099 with you and the IRS at year-end if your earnings exceeded $600.
• Expenses. By default, expenses are not reimbursed unless pre-approved by the founder for a specific purpose (e.g., client-required travel, a tool needed for the engagement). Standard cost of doing business — laptop, internet, software — is on you.
• Equipment and security. Use your own machine. Maintain reasonable security hygiene: full-disk encryption, password manager, MFA on all accounts. Some clients (Xenter) may require additional controls.

What we'll talk about at thirty days

A 30-min check-in at the one-month mark, founder + PM + engineer.

• How's the engagement going from your side?
• How's it going from the client side (we'll have separately checked)
• What's working in our handbook? What's friction?
• Pipeline visibility for the next quarter
• Any rate, scope, or assignment adjustments worth discussing

This is not a performance review. It's a calibration conversation. Real performance reviews happen at six months and annually if the engagement is ongoing.

Pre-arrival checklist (quick reference)

For founder/PM, condensed:

Task	Owner	When
Contract signed, pay rate documented	Founder	Before start
rates.yaml updated	Founder	Before start
Toggl seat + invite	PM	Before start
Slack invite	PM	Before start
Vault handbook/ access	PM	Before start
Kickoff call scheduled	PM	Before start
Engagement context doc shared	Founder/Lead	Day one or before
Client-side access kicked off	Founder	Up to a week before
Toggl project + rates configured	PM	Before start
Day-one kickoff call	Founder + PM	Day one
Friday week-one check-in	Founder or PM	End of week one
30-day calibration	Founder + PM	End of month one

Open items

• [ ] Build a Meseta onboarding email template (sent before day one)
• [ ] Build a "Meseta at a glance" one-pager engineers can share with their accountant or spouse
• [ ] Decide on equipment policy specifics — does Meseta provide any hardware reimbursement for long-term engagements?
• [ ] Decide on benefits-equivalent payments — for engineers we want to retain long-term, is there a stipend equivalent for health insurance or retirement?
• [ ] Define performance review template (6-month, annual)

Related docs

• time-tracking-and-billing.md
• engagement-lifecycle.md
• branding.md
• rates.yaml — in ops repo, not vault