Essay
What I tell engineers who join my teams. Learn the business and the code, fix an annoyance first, take shared ownership, and build visibility through writing, ownership, and public help.
When an engineer joins one of my teams, I tell them the same thing early. The first six months at any company are where you show impact and build trust. Push yourself harder in those months than at any other time.
The reason is that trust compounds. The work you do early decides which problems people bring to you later. It decides how much freedom you get, and how leadership sees you. An engineer who earns trust in the first six months gets larger problems in month seven. An engineer who does not earn it spends the next year trying to catch up.
This post is what I tell new joiners, in the order I tell it. At the end there is a short section for managers and leads, because a new joiner’s first months depend on them too.
Most engineers start with the code. I ask them to start with the business.
Use the product the way a customer does. Ask questions about who uses each feature and why it exists. Then read the API and the code flows behind the parts you used. The goal is to know the “why” behind the system, as well as the “what”.
Three habits make this faster:
None of this needs permission. You can start all of it in the first week.
AI agents make the first weeks much faster if you use them in the right order.
First, try the product yourself. Then ask an agent to give you a walkthrough of the code behind what you just did. Ask it to explain each part, one flow at a time. This gives you a map of an unfamiliar codebase in hours instead of weeks.
The agent has limits. Sometimes you still have doubts, or the agent cannot explain why something works the way it does. Then go to the subject matter expert or the module owner. Those questions are good questions. They show that you did the work first, and they are usually about the decisions that never got written down.
Your first win does not need to be large. It needs to be visible and useful.
The best first win I know is an annoyance the team complains about and nobody has time to fix. A flaky test, a slow script, a manual step in a release, a confusing error message. Everyone feels it, so everyone notices when it stops.
This kind of fix has three advantages for a new joiner. The scope is small, so you can finish it. It makes you read the parts of the system the team touches every day. And it shows that you see the team’s problems as your problems.
After the first few weeks, start to own parts of a module that someone already owns. This works best on a team with clear module owners.
Shared ownership protects you. You will make mistakes in a system you do not know yet. With an owner next to you, a mistake is a lesson and a review comment. Without one, it can become an incident. Shared ownership also gives you confidence, because you know someone will catch what you miss.
On a new team, shared ownership is harder because there may be no module owners yet. In that case, I ask new joiners to come to me. I fill that role until the team has owners.
For freshers, I am direct about it. The first six months are hard and labour intensive. That means writing code, and then more code. There are no thinking projects in this phase, only implementation. You earn the team’s trust by delivering a lot of working code that reviewers can depend on.
For experienced hires, the path is the same in shape and different in speed. A senior engineer should bring judgment early. That means taking a larger problem sooner and making decisions about it, beyond the volume of code you ship. The team hired you for that judgment, so let them see it in the first months.
Visibility matters. Engineers who do good work quietly often get less credit than they earn. The fix is to make the work legible and useful to other people.
I ask new joiners to do three things.
Write it down. A spec before you build, a short design note, or a summary of what you learned about a flow. Writing makes your thinking visible, and it helps the next person who joins.
Own a problem end to end. When you own something fully, from the spec to production to the follow-up, people learn who to go to. Visibility follows ownership.
Help in public. Answer questions in shared channels, write thoughtful PR reviews, and unblock other people where the team can see it. That kind of help builds trust with people outside your immediate team.
Some mistakes are common enough that I warn about them on day one.
The first is bringing an idea to a large audience without data and without testing it on a smaller group first. Perceptions are hard to change. Once leadership forms an image of an engineer, that image is hard to move, and sometimes it does not move at all. Test your idea with your manager or a few peers. Get the data. Then take it to the larger room.
The second is worrying too much. New joiners often feel slow and assume everyone notices. The fix is practical: clarify what you do not understand, and keep reading code.
The others are familiar:
A new joiner’s first six months depend a lot on what their manager sets up. I try to do three things.
Pair them with an owner. Attach every new joiner to a module owner for shared ownership. They learn the “why” faster, and their early mistakes stay safe.
Pick the first work. Do not leave a new joiner to find their own work in an unfamiliar system. Hand them scoped, real work with a clear finish line.
Set expectations. Say plainly what the first six months look like and what good looks like. For a fresher, that is a lot of implementation. For a senior hire, that is judgment on a larger problem. Nobody should have to guess.
Learn the business, read the code, fix the annoyance, take shared ownership, and write down what you learn. Every one of those actions builds trust, and trust is what turns into larger problems, more freedom, and real impact later.
Krishna Dey