Onboarding plan

A 30/60/90 plan for a new joiner in a given role.

HR · produces a Document · built in, ready to run

What you give it

Something like this:

Role: Backend engineer joining a 4-person team on a multi-tenant Laravel order platform for food distributors. Integrations with SAP Business One. They will eventually own the pricing engine and the SAP sync. On-call one week in four starts after month 2.

What you get back

This is a real run of the skill on the input above, not a mock-up:

## **30/60/90 Day Onboarding Plan**
### Backend Engineer – Multi-Tenant Laravel Order Platform

---

## **DAYS 1–30: Foundation & Observation**

### **What They Should Learn**
- **Codebase structure**: Laravel app architecture, multi-tenant setup, database schema, key services
- **Domain knowledge**: Food distribution fundamentals—order types, supplier relationships, margin vs. margin-based pricing
- **SAP Business One integrations**: Where they connect, what data syncs, sync frequency, current pain points
- **Development workflow**: Code standards, PR process, testing conventions, branching strategy
- **Team & culture**: Daily standup rhythm, decision-making, who owns what, where knowledge lives
- **Ops & access**: How to reach staging/production, monitoring tools, log aggregation, alerting

### **What They Should Ship**
- **Update internal onboarding docs** with their own learnings (clarity for the next hire)
- **Fix 2–3 low-risk bugs or typos** found during code review (not assigned from the backlog—found organically)
- **Add one unit test** to an existing module (learn the testing patterns in context)
- **Write one internal doc page**: e.g., "SAP Sync Overview" or "Multi-Tenancy Architecture for New Engineers"
- **No production deployments yet**

### **Who They Should Meet**
- All 3 team members (**1:1 meetings**: understand their focus area, what they love/hate about the system)
- Product/Customer Success (what do customers struggle with? What features are requested most?)
- One data/analytics person (if one exists—how do they use the platform? What metrics matter?)
- Informal team lunch or coffee chat (not a formal meeting)

---

## **DAYS 31–60: Hands-On Contribution**

### **What They Should Learn**
- **Authentication & multi-tenancy in practice**: Tenant isolation, how data boundaries are enforced, where mistakes happen
- **Order workflow end-to-end**: Creation → modification → fulfillment. Where do orders fail?
- **Error handling & observability**: How failures bubble up, how the team debugs issues, where blind spots exist
- **Pricing engine anatomy**: Current structure, business rules, known tech debt, edge cases (seasonal pricing? Volume discounts? Supplier-specific margins?)
- **SAP sync mechanics**: Request/response cycle, data validation, failure modes, how often it breaks and why
- **Performance baselines**: Known bottlenecks, query patterns to avoid, caching strategy
- **Staging vs. production differences**: Why things work differently, data refresh cadence

### **What They Should Ship**
- **One moderate feature or improvement**: e.g., add a new field to an order endpoint, improve error logging, refactor a non-critical module
- **Fix 5–7 medium-complexity bugs**: From monitoring alerts, code review findings, or customer reports
- **Extend test coverage by 5–10%** in an area they touched
- **One performance optimization**: N+1 query fix, caching layer, or batch operation improvement
- **One PR with substantive code review** (they receive critical feedback and revise)

### **Who They Should Meet**
- Sales or Account Management (which customers are most demanding? What are their use cases?)
- Finance/procurement person at a customer (**optional**—ride-along to understand workflow from their chair)
- Support or CSM team (what tickets repeat? What causes escalations?)
- Deepening 1:1s with team members (understand *how* they think, not just *what* they do)

---

## **DAYS 61–90: Ownership & Independence**

### **What They Should Learn**
- **Pricing engine internals**: All business rules, edge cases, how suppliers/customers/seasons affect pricing
- **SAP sync in depth**: Complete request/response flow, error recovery strategies, data validation rules, reconciliation
- **On-call rotation** (**starts this month**): Runbooks, escalation paths, what constitutes an emergency, how to triage
- **Performance tuning at scale**: Database indexing, query optimization, caching invalidation
- **Prioritization & scope**: How to propose work, estimate it, say no to things, break down larger problems
- **Observability**: Alerts they should watch, metrics to understand, dashboards to read

### **What They Should Ship**
- **One pricing engine improvement or bug fix**: Build momentum toward future ownership of this system
- **One SAP sync reliability improvement**: Better error handling, retry logic, or monitoring/alerting
- **Support 1–2 production incidents during on-call week**: With team backing them up, not flying solo
- **Refactor or optimize one small subsystem**: With tests, code review, and a ship
- **Contribute meaningfully to sprint planning**: Speak up on feasibility, raise technical risks
- **First draft of documentation** for both systems they'll own (pricing + SAP sync)

### **Who They Should Meet**
- **Customers directly**: On a support call, demo, or meeting—hear pain points firsthand
- Engineering leads or architects from integrated systems (if relationship exists)
- Internal retrospective—share learnings and ideas for improving onboarding
- Regular 1:1 mentor for pricing engine work (establish who will guide them long-term)

---

## **Success Metrics (End of Day 90)**

✓ Deploy to production independently (with code review)  
✓ Debug and resolve a production issue with minimal guidance  
✓ Explain pricing engine and SAP sync architecture to a new hire  
✓ Have informed opinions on code quality and technical debt  
✓ Ready to own pricing engine and SAP sync (with ongoing support from team)  
✓ Confident in on-call rotation and knows escalation paths  
✓ Has delivered ~8–12 distinct pieces of work to production

---

This plan front-loads learning and relationships, gates shipping to low-risk items in weeks 1–4, and gradually builds toward independent ownership. The emphasis on reading, understanding, and documenting in month 1 sets them up to be fast and confident in months 2–3.

The wording changes a little every run. The shape does not — that is what the procedure below is for.

Tools it uses

None of its own. A skill that only writes needs no tools, so this one inherits whatever your assistant can normally reach.

The procedure it follows

This is the skill, in full. Add it to your own skills to change any of it.

Write a 30/60/90 day plan for the role below.

For each period: what they should have learned, what they should have shipped, and who they should have met.

Make the first 30 days mostly reading and small changes. A plan whose first week includes shipping to production is a plan written by someone who has forgotten what week one is like.

How to run it

In chat, on the Skills page and in automations you do not have to add it first — a library skill runs as it is. Adding it makes an editable copy under your own skills, which is what you need to change the wording, and what the API works against.

New to skills? Start with what a skill is.