Your first 90 days should leave you able to explain the customer problem, ship useful changes and own an agreed area of work. Start with a small piece of delivery that teaches you how the company operates, then increase responsibility as your understanding grows.
The plan below is Corellia Talent’s suggested structure for an engineer joining a seed-stage startup. Agree the detail with your manager or founder before treating it as your schedule. The most useful plan connects what you learn to work the team actually needs.
If the role is still being defined, use the founding engineer brief to clarify the outcome you are joining to deliver.
Before you start: agree the first useful outcome
Ask who will help you get set up, who will review your work and what the team would like you to understand first. Arrange access and equipment through the company’s approved process rather than improvising with personal accounts.
Request a short introduction to the customer, the product and the current priorities. You do not need to absorb every document before your first day. You need a reliable starting point and someone who can explain what is current.
Agree an initial task that is useful, bounded and safe to review. It should take you through the normal path from understanding a problem to checking a change in use. A large architectural rewrite is a poor way to discover how decisions and releases work.
Confirm the working arrangements and practical expectations too. In UK employment, the written statement has specified day-one requirements, including the principal statement and information about relevant terms. [Source 1] Resolve questions with the company rather than assuming the informal conversation contains the complete arrangement.
Days 1 to 10: learn how the product reaches a customer
Follow one customer journey from beginning to end. Use the product, watch a demonstration or join an appropriate customer conversation. Ask what the person is trying to achieve, where they struggle and how the team knows whether the product helps.
Then follow that journey through the system. Identify the main components, the data they use and the points where failures become visible. Ask someone to show you how a change is tested, reviewed, deployed and, if necessary, rolled back.
Keep a small map of the people and decisions around the work. Who knows the customer context? Who can approve a release? Who understands a fragile integration? Who should you contact if a change affects access or sensitive data?
You will notice gaps. Record them as questions first, with the effect they have on your task. A note that setup requires an undocumented secret is immediately useful. A broad judgement that the whole engineering process is wrong is harder to act on before you understand its history.
Ship a small change through the real process
Your first delivery should teach you the whole feedback loop. Choose a change with a clear reason, a reviewer and a way to check the result. It might improve an error message, remove a small customer friction or make a repeated support task easier.
Write down what you expect to happen and how you will know. After the change reaches its intended environment, compare that expectation with what actually happened. Ask for help interpreting a result that is unclear.
Working in small, testable batches is an established software-delivery capability in DORA’s research. [Source 2] For your first weeks, the practical value is that you can learn from a complete change without waiting for a large piece of work to finish.
Keep the scope small enough to finish responsibly. The aim is not to prove your speed by skipping review or testing. It is to understand and improve the route by which useful work reaches someone.
Days 11 to 30: make priorities and feedback explicit
Meet your manager or founder regularly to compare what you are learning with the role’s priorities. Bring a short update: what changed, what you learned, what is blocked and what decision you need.
Ask for specific feedback on your work and communication. Is your level of detail useful? Are you raising uncertainty at the right time? Are you choosing an appropriate scope before building? A short correction now is easier to use than a surprise at the end of the quarter.
Create a small list of improvements that would make your own work more dependable. Separate immediate obstacles from larger proposals. Agree which deserves attention and which can wait.
By the end of this period, you should be able to explain the company’s next important outcome in plain language and connect your work to it. Check that explanation with the founder. A technically accurate understanding of the code is only part of knowing what to do next.
Days 31 to 60: own a bounded outcome
Take responsibility for a piece of work that includes both delivery and follow-through. Define the customer or internal user, the problem, the expected result and the constraints. Name the decisions you can make and the ones that need discussion.
Break the work into useful increments. Show progress while there is still time for the team to change its mind. If a dependency moves or an assumption fails, explain the effect on scope and timing rather than silently absorbing the change.
Keep talking to the people affected. A founder’s initial explanation may be enough to begin, but implementation often exposes details that need a customer, colleague or specialist to resolve.
Record decisions briefly. A few sentences about why you chose an approach help the next person understand it and help you revisit it when the constraints change. Documentation becomes useful when it supports a real decision or repeatable task.
Learn the operating work as well as the product work
Ask how the team handles incidents, support, access changes and routine maintenance. Shadow the appropriate person before taking responsibility for something unfamiliar, especially where customer data or reliability is involved.
Find out how operational work is recognised when priorities are set. If it regularly interrupts delivery, make that visible in your planning conversation. Useful ownership includes maintaining what you ship, with a realistic allocation of time.
Keep a note of tasks that only one person can perform. Improving a repeated process or sharing knowledge can be a meaningful contribution, provided it addresses a real dependency rather than creating process for its own sake.
Days 61 to 90: make the responsibility sustainable
Review the outcome you have owned and what it taught you. What improved for the user? Which assumption changed? What still needs attention? Use evidence from the work rather than a list of hours spent or tickets closed.
Agree the next area of responsibility and the support you need. You may be ready to own more independently, or a new technical problem may need pairing or specialist help. Make the decision explicit.
Discuss the shape of the team as it grows. The first five engineering hires guide explains how a founder might plan complementary roles. Ask which gaps the next hire is intended to fill and how that affects your work.
If your role is moving towards leadership, use the technical leadership mandate guide to separate technical direction from managing people. Taking on more should come with a shared understanding of the decisions and time involved.
Bring a short review to the end of the quarter
Prepare a one-page review with four headings: outcomes delivered, important learning, unresolved risks and proposed next priorities. Include one or two examples under each, and make the requests you need from the company clear.
Ask whether your understanding of the role still matches the founder’s. If the business has changed direction, update the agreement rather than measuring yourself against an obsolete plan.
Return to the questions you asked before joining. You should now have better answers about the work, the people and the decisions. The strongest first quarter leaves the team with useful work delivered and a clearer way to build the next part together.
If you are considering your next technical role, Start a conversation.
Sources
- GOV.UK: written statement of employment particulars, official guidance, checked 31 October 2026.
- DORA: working in small batches, primary software-delivery research guidance, checked 31 October 2026.
The questions, decision framework and suggested wording are Corellia Talent’s editorial recommendations.