From Day 1 to First Deploy

Your new engineer starts Monday. By Wednesday, they'll ask where the staging environment lives. By Friday, they'll need the deploy checklist. Next week, they'll ask both questions again.

This happens because onboarding answers live in Slack threads, Google Docs, and someone's memory. New engineers ask the same questions. Senior engineers answer them. Everyone loses time.

Here are the 12 questions every new engineer asks, and how to make the answers discoverable.

Environment Access

"Where do I find staging credentials?"

New engineers need access before they can do anything. They ask in Slack. Someone sends a link. The link is outdated. They ask again.

Make credentials discoverable. Put them in your password manager with clear naming. Document the process in your wiki. Link to it from your onboarding checklist.

"How do I get production read access?"

This question reveals a gap in your access control documentation. Engineers need to know what they can access, when they can access it, and how to request more.

Write down your access levels. Explain the approval process. Show them where to submit requests.

Development Environment

"What's the local development setup?"

Your README says "run docker-compose up" but the new engineer gets errors. They're missing environment variables. Or using the wrong Node version. Or their database migrations are out of sync.

Your setup guide should work from a clean machine. Test it yourself every quarter. Include troubleshooting steps for common errors.

"Which branch should I work from?"

Some teams use main. Others use develop. Some use feature branches off main with release branches for production.

Your branching strategy lives in someone's head. Write it down. Include examples. Show the full workflow from branch creation to merge.

Code and Architecture

"Where does the authentication logic live?"

New engineers spend days searching for code. They grep for function names. They follow imports. They interrupt their teammates.

Create an architecture document. Map your main services. Explain what each one does. Include file paths for core functionality.

"What are the testing requirements?"

Do you need unit tests? Integration tests? What's the coverage threshold? Can they merge without tests if it's a small change?

Make your testing standards explicit. Show examples of good tests. Explain when to skip tests and when that's unacceptable.

Deployment

"How do I deploy to staging?"

This is where most onboarding documentation breaks down. You have a CI/CD pipeline, but the new engineer doesn't know how to trigger it.

Document your deploy process step by step. Include screenshots. Explain what to check before deploying. Show them how to verify the deploy worked.

"What's the production deploy process?"

Production deploys need more care. Who approves them? What time windows are allowed? What's the rollback procedure?

Write a production deploy checklist. Make it mandatory. Include pre-deploy verification, deploy steps, and post-deploy monitoring.

Communication

"Where should I ask questions?"

You have Slack channels for engineering, backend, frontend, devops, and random. New engineers don't know which one to use.

Document your communication channels. Explain what belongs where. Tell them which channels to monitor and which to mute.

"How do code reviews work here?"

Some teams require two approvals. Others need one from a senior engineer. Some teams expect line-by-line comments. Others prefer high-level feedback.

Explain your code review culture. Set response time expectations. Show examples of good reviews.

Incidents and Support

"What do I do if something breaks?"

Production breaks at 2am. The new engineer is on call. They don't know the escalation path.

Create an incident response guide. List the steps. Include contact information. Explain when to escalate.

"How do I check logs and metrics?"

You use Datadog. Or New Relic. Or Grafana. The new engineer doesn't know which dashboard shows what.

Document your observability tools. Create links to key dashboards. Explain what metrics matter for each service.

The Pattern

These questions repeat because your knowledge exists in fragments. A Slack message here. A wiki page there. Tribal knowledge everywhere.

You need a single source of truth. Make it searchable. Keep it current. Link to it constantly.

When someone asks a question, answer it once in the documentation. Then send them the link. Next time someone asks, send the same link.

Your senior engineers stop answering the same questions. Your new engineers move faster. Everyone ships more code.

What to Do Next

Pick three questions from this list. Write clear answers. Put them where new engineers will find them.

Then measure the impact. Track how often people ask these questions in Slack. Watch the number drop.

Geert P. Thiemens
The Moai team