Hiring a strong software engineer is only half the job.
The other half is making sure they understand how to succeed inside your company.
Most engineering leaders already know:
how they like people to communicate
when they expect someone to take ownership
when they want to be consulted
what makes them trust an engineer
what behaviors frustrate them
how quickly someone should raise a blocker
what a good update looks like
what “high ownership” actually means in practice
The problem is that most of this information lives in their head.
A new engineer is then expected to pick it up through observation, trial and error, and what we sometimes jokingly call company osmosis.
That creates unnecessary ambiguity.
At Cloud Employee, we hire 20+ engineers per month for companies.
One of the things we've learned is that you can remove a surprising amount of early friction simply by getting those unwritten expectations out of the hiring manager's head before the engineer has to discover them through mistakes.
So we use a structured 30-minute conversation with the manager.
We record and transcribe the conversation, combine it with a short input from the engineer, and use AI to create a practical working guide. The manager reviews it.
Then the engineer receives it before or at the beginning of Day 1.
How Much Time Does It Take?
30-minute interview. About 1 hour end to end.
That includes:
the manager interview
engineer input
preparing the practical onboarding information
generating the first draft with AI
manager review
finalizing the working guide
The point isn't to create another lengthy onboarding process.
It's to turn information that already exists in people's heads into something a new engineer can actually use.
How It Works
- 1. INTERVIEWSpend 30 minutes with the engineer’s lead.
- 2. TRANSCRIBECapture the conversation.
- 3. ADD THE ENGINEER'S INPUTUnderstand how they work best too.
- 4. PREPAREMake sure the practical Day 1 information is ready.
- 5. GENERATEUse the AI prompt in this framework to create the working guide.
- 6. REVIEWThe client manager checks it for accuracy and if they want to make any changes.
- 7. SHAREGive it to the engineer before or at the beginning of Day 1.
- 8. CALIBRATERevisit it after three weeks using real experience.
What You’re Creating
At the end of this process, the engineer receives a practical:
HOW TO WORK WITH [COMPANY NAME]
Engineering Working Guide
It turns the manager interview, engineer input and onboarding information into something the engineer can actually use from Day 1.
The guide can include:
what great looks like here
how the team communicates
when to act vs. ask
what to do when blocked
working hours and availability
who owns what
how the engineer and manager work best together
what success looks like across the first 90 days
The output: a practical working guide the engineer receives before or at the beginning of Day 1.
How to work with
ACME
Engineering Working Guide
A practical guide to how this team communicates, decides and works best together.
- Prepared for
- Daniel Martin
- Role
- Senior Software Engineer
- Manager
- Jason Carter, CTO
What great looks like here
The behaviors that make someone easy to trust and effective on this team.
- 01Raise delays earlyFlag risk as soon as you see it, not on the deadline.
- 02Bring problems with possible solutionsInvestigate first. When you raise an issue, include what you've tried and what you recommend.
- 03Challenge ideas constructivelyIf you disagree, say so. Bring context, reasoning and an alternative.
- 04Keep progress visibleUse clear, predictable updates so nobody has to chase.
Cloud Employee · Example output from the 30-Minute Software Engineer Onboarding Framework
How we work together
Make the important defaults explicit, so the engineer does not have to guess.
How we communicate
Use the channel that fits the problem.
- SlackQuick questions and everyday updates.
- LoomDetailed asynchronous explanations.
- CallsUrgent or complex conversations.
How we make decisions
Know when to act and when to check.
LEVEL 1: JUST DO ITMake the decision and move forward.
When you're blocked
Bring context, not just the problem.
- 1What I'm trying to do
- 2What's blocking me
- 3What I've already tried
- 4What I think we should do next
Working hours
Clear availability. Fewer assumptions.
9am to 5pm ET
with agreed team overlapOutside core hours
Use asynchronous communication unless something is genuinely urgent.Your first 90 days
Increasing context. Increasing autonomy.
Cloud Employee · Example output from the 30-Minute Software Engineer Onboarding Framework
The Goal
The goal isn't more onboarding documentation.
It's:
Less ambiguity.
The 30-Minute Interview Questions
If you only use one page, use this one.
1. What does great look like? 6 mins
Think about one of the best engineers you've worked with. What did they actually do that made them particularly effective?
Push for observable behaviors rather than personality traits.
2. What creates friction? 4 mins
Think about engineers you've struggled to work with. What did they repeatedly do that created friction?
Again, focus on behaviors rather than whether you personally liked them.
3. How should they communicate? 4 mins
What should happen on Slack, Loom, calls, and meetings? What deserves an immediate message? What can wait?
4. When should they act vs. ask? 4 mins
What can they just do? What should they tell you afterward? What requires a recommendation first? What requires approval?
5. What happens when they're blocked? 2 mins
How long should they try independently? Who should they ask? What information should they bring?
6. What business context do they need? 3 mins
What should they understand about the company, customer, product, and current priorities?
7. Who do they need to know? 2 mins
Who owns what, and when should this engineer go to them?
8. When are they expected to be available? 2 mins
What are the working hours, team overlap, and expectations around asynchronous communication?
9. What does success look like after 90 days? 3 mins
Imagine we're talking again 90 days after they start. What would need to be true for you to say:
“This hire is working really well”?
Total: approximately 30 minutes
PART ONEThe 30-Minute Manager Interview
You're not trying to document everything about the company.
You're trying to identify the things a new engineer would otherwise have to discover through mistakes.
Record the conversation so you can use the transcript later.
1. What Does Great Look Like?
Target: 6 minutes
Don't begin by asking:
“What are you looking for in an engineer?”
You'll often get answers like:
proactive
good communicator
team player
can-do attitude
takes ownership
Those aren't wrong.
They're just too vague.
Instead ask:
Think about one of the best engineers you've ever worked with.
Let's call them John.
What did John actually do that made them so effective?
Probe for habits and behaviors, not personality traits.
Ask:
How did they communicate?
What happened when something went wrong?
What did they do when blocked?
How much direction did they need?
Did they challenge your thinking?
Did they bring ideas without being asked?
How did they handle disagreement?
What made you trust them?
What consistently made them easy to work with?
Make It Tangible
If the manager says:
“They were a great communicator.”
Ask:
“What did great communication actually look like?”
| Too vague | Useful |
|---|---|
| Communicates well. | When something was delayed, they told me as soon as they realized rather than waiting until the deadline. |
| Takes ownership. | When they hit a problem, they investigated it and came back with possible solutions and a recommendation. |
| Didn't need much management. | I'd rather receive one thoughtful Loom explaining what they did and why than ten Slack interruptions throughout the day. |
| Proactive. | If they noticed something that could be improved, they'd raise it and explain what they thought we should do. |
Capture 5-8 Behaviors
What great looks like here
2. What Creates Friction?
Target: 4 minutes
Ask:
Think about engineers you've struggled to work with. Your pet peeves.
What did they repeatedly do that created friction?
Focus on observable behaviors.
Prompts:
Went quiet when stuck?
Waited too long to ask for help?
Asked permission for every small decision?
Made major decisions without involving anyone?
Missed deadlines without warning?
Needed constant chasing?
Overengineered simple problems?
Executed tickets without understanding why?
Failed to challenge something obviously flawed?
Raised problems without possible solutions?
Became defensive when receiving feedback?
Things that tend not to work well here
3. How Should We Communicate?
Target: 4 minutes
- Slack / Teams Used for:
- Email Used for:
- Loom / Video Used for:
- Calls Used for:
- What deserves an immediate message?
- What can wait?
- What does a good progress update look like?
- How often do you expect updates?
- Multiple times per day
- Daily
- A few times per week
- During stand-up
- Other: __________________
4. When Should They Act vs. Ask?
Target: 4 minutes
Different managers mean very different things when they say:
“Take ownership.”
Use four levels.
LEVEL 1: Just Do It
Make the decision and move forward.
LEVEL 2: Do It, Then Tell Me
Act independently, then communicate what you decided.
LEVEL 3: Recommend, Then Check
Investigate, form a recommendation, and discuss it before proceeding.
LEVEL 4: Get Approval First
Do not proceed without explicit approval.
Apply Them
| Decision / Area | Starting Level | Expected Day 90 |
|---|---|---|
| Small implementation decisions | ___ | ___ |
| Production deployments | ___ | ___ |
| Database changes | ___ | ___ |
| Architecture decisions | ___ | ___ |
| Customer-impacting changes | ___ | ___ |
Autonomy Should Change
A decision that is Level 3 in Week 1 may appropriately become Level 1 by Month 3.
The goal isn't permanent caution.
It's increasing autonomy as context and trust develop.
5. What Happens When They're Blocked?
Target: 2 minutes
- How long should they normally try independently before asking for help?
- Who should they contact first?
A useful blocker format is:
What I'm trying to do
What's blocking me
What I've already tried
What I think we should do next
The goal isn't fewer questions.
It's:
Better questions.
6. Give Them the Business Context
Target: 3 minutes
- What does the company do?
- Who is the customer?
- Why do customers choose you?
- What are the biggest priorities right now?
- How does engineering contribute?
Engineers make better decisions when they understand why they're building something, not just what ticket is next.
7. Who Do They Need to Know?
Target: 2 minutes
Hiring Manager
Name: ______________________________
Go to them for: ______________________
Technical Lead / Senior Engineer
Name: ______________________________
Go to them for: ______________________
Product
Name: ______________________________
Go to them for: ______________________
Other
Name / role: _________________________
Go to them for: ______________________
8. Working Hours & Availability
Target: 2 minutes
Particularly important for distributed teams. Don’t just document the engineer’s time zone. Agree the hours of real-time overlap you actually need, what can happen asynchronously, and where flexibility sits on both sides.
- Expected working hours
- Required team overlap
- Core availability
- Expected response time during those hours
- What genuinely counts as urgent outside those hours?
9. What Does Success Look Like in 90 Days?
Target: 3 minutes
Finish with:
Imagine we're talking again 90 days after this engineer starts.
What would need to be true for you to say:
“This hire is working really well.”
Probe:
What would they own?
What would they do independently?
What would they no longer need to ask about?
What would good communication look like?
What would make you trust them?
What would they contribute beyond simply completing tickets?
- Capture the answer:
END OF THE 30-MINUTE INTERVIEW
Stop there.
You don't need the manager to spend another hour writing documentation.
You now have the raw material.
PART TWOUnderstand the Engineer Too
The manager has preferences.
So does the engineer.
Ask the engineer to answer these before their guide is created.
- I do my best work when...
- The best way to give me feedback is...
- When I'm stuck, my natural tendency is...
- I prefer questions and feedback through...
- The kind of management that helps me perform best is...
- When I disagree, my natural tendency is...
- One thing I'd like my manager to know about how I work is...
The goal isn't to make the engineer conform to the manager.
It's to make both sides' expectations visible before differences become problems.
PART THREEThe Practical Day 1 Checklist
A great working guide won't help if the engineer can't access the codebase.
Before they start, make sure the basics are ready.
Access
- Company email
- Slack / Teams
- GitHub / GitLab / Bitbucket
- Project management system
- Documentation
- VPN
- Cloud/platform access
- Development environment
- Test/staging environment
- Password manager
- Calendar / recurring meetings
Security
- MFA enabled
- Appropriate permissions
- Production access rules understood
- Data-handling requirements understood
- Credential/secrets process understood
Technical Context
- Product walkthrough scheduled
- Architecture walkthrough scheduled
- Main repositories identified
- Development setup instructions available
- PR/review process explained
- Testing expectations explained
- Deployment process explained
- Definition of Done explained
- Engineering standards explained: PRs, testing, documentation and code review
- Approved AI coding tools and data/code-handling rules understood
Give Them an Early Win
Don't spend the first two weeks purely consuming information.
Choose a first piece of work that is:
real
useful
relatively small
safe for someone learning the system
broad enough to expose them to the normal workflow
- First meaningful piece of work
- What does done look like?
- Who can help?
A real delivery gives you something documentation can't:
Evidence of how you're actually working together.
PART FOURThe First 90 Days
You don't need 50 KPIs.
A useful progression is:
30 DAYS: UNDERSTAND
The engineer should increasingly understand:
the company and customer
the product
the relevant architecture
the codebase
how the team communicates
who owns what
how decisions get made
how to ask for help
what great looks like
They should also have shipped real work.
- What should they be able to do independently by Day 30?
- What should they have shipped?
60 DAYS: CONTRIBUTE
The engineer should increasingly:
complete meaningful work independently
contribute to code reviews
raise blockers early
communicate progress predictably
understand why their work matters
make appropriate decisions
contribute ideas
require less guidance
- What should they own by Day 60?
- What decisions should they now make independently?
90 DAYS: OWN
The engineer should increasingly:
own meaningful work
make appropriate independent decisions
identify problems proactively
recommend solutions
understand business and product context
challenge ideas constructively
require materially less management
- What should they own by Day 90?
- What should no longer require approval?
What would make you say:
“This hire is working really well.”
PART FIVETurn the Interview Into the Working Guide
You now have four potential sources of information:
INPUT 1
The manager interview transcript.
INPUT 2
The engineer's working preferences.
INPUT 3
Technical onboarding information.
INPUT 4
The 30/60/90 expectations.
Use the AI prompt to turn those inputs into the first draft of the engineer's working guide.
Before Using AI
- Make sure participants know the interview is being recorded and transcribed.
- Use an AI environment approved by your company.
- Avoid putting passwords, credentials, customer data, or unnecessary sensitive information into the transcript.
The AI creates the first draft.
The manager approves the final version.
Get the AI Prompt
Long prompts can lose formatting when copied from a PDF: grab the clean version here →
cloudemployee.io/engineer-onboarding-prompt
The prompt is designed for ChatGPT, Claude, or another capable AI tool.
You'll add:
the manager interview transcript
the engineer's working preferences
the technical onboarding information
the 30/60/90 expectations
The AI will then create the first draft of the engineer-facing working guide and flag anything that still needs clarification.
PART SIXManager Review
AI should accelerate the process.
It shouldn't become the manager.
Before sharing the guide:
- The manager has read it
- It accurately reflects what they meant
- AI hasn't overstated vague comments
- Missing information has been resolved where necessary
- Contradictions have been addressed
- Working hours are correct
- Decision boundaries are correct
- 90-day expectations are realistic
- Sensitive comments have been removed
- The document sounds like the company
Then share it with the engineer.
PART SEVENThe 3-Week Reality Check
The original guide is based partly on expectations.
Three weeks later, you have evidence.
Where possible, collect the manager's and engineer's feedback separately first.
If you're hiring through Cloud Employee, we can run these check-ins independently with both the manager and engineer. That gives each side space to speak candidly before we bring the important points together and help recalibrate the working relationship.
Ask the Manager
- What's working?
- What has surprised you positively?
- Where are expectations still unclear?
- What should the engineer do more of, less of, or differently?
- Where are you still providing more direction than expected?
- Are any Act vs. Ask levels ready to change?
Ask the Engineer
- What do you wish you'd known on Day 1?
- Where are you still unsure how decisions get made?
- What context are you still missing?
- Are you getting enough useful feedback?
- Is anything slowing you down?
- Is there anything you're hesitant to raise directly?
- What could your manager or team do differently to help you perform?
Then Calibrate
Together agree:
- What should we keep doing?
- What should change?
- What expectation needs to become clearer?
- What autonomy can increase?
Then update the working guide.
The first version isn't sacred.
The objective is an increasingly accurate shared understanding of:
How do we work effectively together?
Final Principle
Most companies don't deliberately create ambiguity.
It happens because experienced employees know things that new employees don't.
- The manager knows how decisions get made.
- The team knows how people communicate.
- Everyone knows which processes really matter.
- Everyone knows what “good” looks like.
Except the person who just joined.
Good onboarding is largely the process of making those invisible rules visible.
Today, that can be surprisingly simple:
- 30 minutes with the manager.
- One transcript.
- A short input from the engineer.
- Clear 30/60/90 expectations.
- One structured AI prompt.
- One practical working guide.
Then give the engineer an early win, increase autonomy as context develops, and check that what you agreed before Day 1 actually matches reality.
The objective isn't simply to onboard someone.
It's to create the conditions for a strong engineer to become a strong engineer inside your company.
About Cloud Employee
Cloud Employee helps companies build dedicated software engineering teams using carefully selected talent from global engineering markets.
We don't believe a successful hire ends when someone accepts an offer.
How people work together matters just as much as what's written on a resume.
That's why we work with clients to understand their team, working style, expectations, and definition of great before an engineer joins.
We then turn those unwritten expectations into something both sides can actually use and continue checking that the relationship is working once the engineer starts.
Less ambiguity. Faster integration. Better long-term engineering relationships.