Monday morning, week 1. You walk into the office - or open Slack - and realise you are no longer judged by your code. You are judged by your team's output. And you have no idea how to measure that yet.
Most engineering management advice is written by VPs with 15 years of experience. It talks about 5-year vision, OKRs, and "scaling culture." You do not need that yet. You need week 1 survival. You need to know what to do on day 3 when your senior engineer asks if you are changing the sprint process. You need to know why your old IC friends suddenly stop inviting you to lunch.
This playbook is built from interviews with three Indian EMs who made the IC-to-manager switch in the last 18 months - at a Series B fintech in Bangalore, a Delhi SaaS startup, and a Hyderabad e-commerce platform. Each of them told us exactly what they got wrong, and what they would do differently.
If you are still deciding whether to make the switch, our guides on IC to Manager: 9 questions to ask someone who's already made the jump and how to switch from SDE to PM cover the decision phase. This post is for after you have said yes.
The mindset shift: what changes on day 1
The single biggest shock for new EMs is not the work - it is the invisibility of the work. As an IC, you commit code, fix bugs, ship features. You have a daily sense of accomplishment. As an EM, your accomplishments are indirect. A team member ships a feature. A conflict gets resolved. A process improves. You facilitated it, but you did not do it.
Your output is now invisible - and that is the point. If you are still chasing the dopamine of individual contribution, you will either micromanage your team or burn out trying to do both jobs. EM A, the Bangalore fintech EM, told us: "I wrote 200 lines of code on day 3 because I felt useless in meetings. My senior engineer looked at me like I'd stolen his lunch. I had undermined myself before I even started."
The calendar shock: As an IC, you might have had 2 hours of meetings a day. As an EM, expect 5-7. Stand-ups, 1-on-1s, planning meetings, cross-team syncs, manager syncs, hiring calls. Your deep work time shrinks dramatically. The new EM who tries to "fit in" their old IC work between meetings is the EM who fails.
Your old IC friends will treat you differently. Not because they dislike you - because they are unsure what you are now. Are you still "one of us" or are you "management"? The answer is: you are management. Act like it. Join team lunches, but do not lead the complaining about company policy. Be friendly, but separate. Your team needs to trust that you represent their interests upward, and your manager needs to trust that you represent company interests downward.
The impostor syndrome hits at week 2, not week 1. Week 1 is a blur of names and systems. Week 2 is when the adrenaline fades and you realise: I have no idea if I am doing this right. That feeling is normal. Every EM we interviewed said it lasted 3-6 months. The ones who recovered fastest were the ones who found a mentor - another EM, not their own manager - to normalise the experience.
Week 1: The listening week
Your only goal in week 1 is to listen. Do not change anything. Do not introduce anything. Do not "fix" anything you think is broken. You do not have context yet. What looks like a broken process might be a workaround for a political constraint you do not know about.
Day 1-2: Meet your manager, understand expectations
Schedule a 45-minute meeting with your manager. Ask these questions:
- "What does success look like for me in 30 days? 90 days?"
- "What is the one thing my team is blocked on that I should prioritise?"
- "Who on the team is at risk of leaving?"
- "What is the political landmine I should avoid stepping on?"
- "How do you prefer to receive bad news?"
Write down the answers. You will reference them in week 3 and 4 when you start making decisions.
Day 3-4: 1-on-1s with every direct report
Schedule 30 minutes with each person on your team. Not 15 minutes - 30. This is your most important work in week 1. The 1-on-1 is not a status update. It is a relationship-building conversation. Ask:
- "What is working well on the team that I should not change?"
- "What is one thing that frustrates you about how we work?"
- "What do you need from me that you are not getting from your previous manager?"
- "What are you working toward in your career - here or elsewhere?"
- "Is there anything I should know about the team dynamics that is not obvious?"
Day 5: Observe, do not lead
Attend stand-up, sprint planning, or whatever team ritual exists. Do not lead it. Do not change the format. Do not add your "perspective." Just watch. Take notes on:
- Who speaks and who stays silent?
- Where do disagreements happen?
- What topics get skipped or rushed?
- Who looks frustrated?
What NOT to do in week 1
Do not change stand-up format. EM B tried this on day 4. It took 3 weeks to rebuild trust. The team interpreted it as "new manager thinks our way of working is wrong."
Do not commit to deadlines you do not understand. Your manager or product person will ask "Can the team ship X by Y?" The answer is: "Let me check with the team and get back to you." Never guess.
Do not complain about your predecessor. Even if the previous manager was terrible, your team may have liked them. Criticising them makes you look insecure.
Week 2: Map the system
Week 2 is about understanding how things actually work - not how the org chart says they work. There are three maps you need: technical, people, and cross-team.
Technical mapping
You do not need to know every line of code. You need to know:
- Architecture: What are the major services? What depends on what? Where is the technical debt?
- On-call: Who is on call this week? What do they actually do when paged? Shadow one on-call rotation if possible.
- Deployment pipeline: How does code get to production? How often? Who has deploy access? What happens when it breaks?
- The "it broke last month" story: Ask your team about the last major incident. What happened? What did they learn? What did not get fixed?
People mapping
The org chart is fiction. The real influence map is what matters. Ask yourself:
- Who do people go to for technical decisions, even if that person is not the tech lead?
- Who is the "glue" - the person who knows where everything is and helps everyone?
- Who is coasting? Who is overworked?
- Who wanted your job and did not get it?
EM C, the Hyderabad EM, discovered in week 2 that his team's most productive engineer was also the most unhappy - because she was doing 60% of the on-call load while another engineer was doing 10%. The previous manager had not noticed. This became EM C's first real intervention in week 3.
Cross-team mapping
Your team does not work in a vacuum. Map:
- Which teams depend on your output?
- Which teams block your output?
- Who are the key stakeholders outside engineering (product, design, sales)?
- Where are the active conflicts or passive-aggressive Slack threads?
Week 3: Find a quick win
By week 3, you have listened for two weeks. You have context. Now you need credibility. The fastest way to get it is a quick win - but it must be the right kind of quick win.
What makes a good quick win
A good week-3 win has three traits:
- Visible: People notice it. It is not a refactor that only engineers appreciate.
- Low-risk: It cannot backfire. If it fails, no one gets hurt.
- Someone else's idea: You are implementing something a team member already wanted. You are not imposing your idea.
Examples of good week-3 wins from the 3 EMs:
- EM A: "My team complained that stand-up ran 25 minutes because people went into problem-solving. I suggested we try a 'parking lot' for topics that need discussion. The team loved it. It was their idea - I just gave it a name and enforced the boundary."
- EM B: "I fixed the on-call rotation. One person was carrying 60% of the load. I rebalanced it and she thanked me publicly in the team channel. It took 20 minutes."
- EM C: "I got approval from my manager to approve a training budget that had been sitting in limbo for 3 months. Two engineers got the courses they wanted. Cost: Rs. 40,000. Morale impact: huge."
Examples of bad week-3 wins:
- Introducing a new project management tool because you used it at your old company. (Imposing, not listening.)
- Committing the team to a tighter sprint because "we can move faster." (You do not know their constraints yet.)
- Publicly calling out someone's code quality in a review. (Destroys trust before you have earned the right to give hard feedback.)
The "ask before acting" rule
For any change you want to make in week 3, ask at least one team member: "I am thinking of doing X. Do you think that would help or hurt?" If they hesitate, do not do it. Their hesitation is data.
Week 4: Set your first ritual
Rituals are recurring practices that create predictability. Processes are documented rules that create compliance. New EMs often confuse the two. Start with rituals.
Why rituals matter more than processes
A ritual builds culture. A process builds bureaucracy. In Indian tech teams, where attrition is high and context is constantly lost, rituals are what preserve team identity when people leave. A weekly team lunch. A fortnightly retro where everyone shares one thing they learned. A 1-on-1 cadence that never gets cancelled.
Three rituals that work for new EMs
Ritual 1: The weekly 1-on-1 cadence. Schedule recurring 30-minute 1-on-1s with every direct report. Same day, same time, every week. Do not cancel them. If you cancel once, your team learns that your time with them is optional. EM A: "I cancelled a 1-on-1 in week 5 because of a 'urgent' meeting. That engineer did not reschedule. He stopped bringing me problems. It took 2 months to rebuild that channel."
Ritual 2: The monthly team lunch (or virtual coffee). Not a working lunch. No agenda. Just food and conversation. This is where you learn who people are outside of work. In Indian teams, where hierarchy is culturally ingrained, a casual team lunch is often the first time junior engineers speak freely around their manager.
Ritual 3: The fortnightly retro. Keep it simple: what went well, what could be better, one action item. Do not let it become a complaint session. Do not let it become a status meeting. 30 minutes, fortnightly, same format. Consistency matters more than perfection.
How to introduce a ritual without seeming like you are changing everything
Frame it as an experiment, not a mandate. "I would like to try a fortnightly retro. Just 30 minutes. If it does not work for us, we will stop." This gives people permission to push back, which makes them more likely to try it honestly.
Preparing for month 2: the 30-60-90 day conversation
Schedule a 45-minute meeting with your manager at the end of week 4. Come prepared with:
- What you learned about the team
- The top 3 blockers you identified
- One change you want to make in month 2 and why
- What support you need from your manager
This is not a performance review. It is an alignment check. The best EMs use this meeting to set expectations before they start making bigger changes.
The 5 mistakes every new EM makes
These are so common that you should assume you will make at least two of them. Knowing them in advance helps you recover faster.
Mistake 1: Writing code in week 1. You are not an IC anymore. Every hour you spend coding is an hour you are not spending on the things only you can do: unblocking your team, managing upward, building relationships. EM A wrote 200 lines on day 3. His senior engineer's look said everything: "Why is my manager doing my job?"
Mistake 2: Changing process before understanding it. EM B changed stand-up format on day 4. The team had designed that format to accommodate a remote member in a different time zone. EM B did not know that. He looked incompetent and uncaring.
Mistake 3: Being "one of the team" instead of "the team's manager." You cannot be both. When you join the complaining about company policy, you lose the ability to advocate for your team upward. When you share confidential information to seem "cool," you destroy trust. Be friendly. Be separate.
Mistake 4: Not having 1-on-1s in week 1. Some new EMs wait until they "feel settled" to schedule 1-on-1s. By then, problems have festered. By then, people have formed impressions. The 1-on-1 is not a reward for being organised - it is the foundation of everything else.
Mistake 5: Avoiding difficult conversations. New EMs often delay feedback because they do not feel they have "earned the right" yet. But delaying feedback does not make it easier - it makes the problem worse. By week 3 or 4, if you have observed a real issue during your listening phase, address it. Frame it as curiosity, not accusation: "I have noticed X. Can you help me understand what's going on?"
Need to talk to someone who has done this before?
EM B told us the best advice he got in week 2 came from a 15-minute call with an EM at a Series C startup. "I asked about the 1-on-1 template. He sent me his actual Google Doc. I used it for 6 months." The fastest way out of the 47-tabs loop is to stop reading and start asking.
Frequently asked questions
Quick answers about the first 30 days as an engineering manager in India.
Should I still code as an EM?
In your first 30 days, write almost no code. Your job is to learn the people, the system, and the politics - not to prove you can still ship. EM A told us he wrote 200 lines on day 3 and his senior engineer looked at him like he'd stolen his lunch. Most Indian tech companies expect EMs to be technically credible but not hands-on. After month 1, you can pick up small bugs or code reviews, but never let coding compete with your 1-on-1s or team unblocking.
How do I handle a team member who was my peer last month?
Have a direct 1-on-1 in week 1. Say: "I know this transition is awkward for both of us. My role is to help you succeed, not to boss you around. If I ever step on your autonomy, call it out." Then actually listen when they do. Do not try to be "one of the team" by joining every lunch or inside joke - it undermines your authority and confuses the relationship. Be friendly, but separate.
What if my manager and I disagree on priorities?
In month 1, your manager wins every disagreement. You do not have enough context to argue. Document your concerns in writing (a brief email after the conversation) and revisit in your 30-60-90 day check-in. By then you will have data - team velocity, blockers, technical debt - to support your view. EM C said: "I fought my manager in week 2 about roadmap priority. I was wrong. I didn't know the CEO had promised that feature to a board member."
How do I know if I'm doing well?
In month 1, you are doing well if: (1) You have met every direct report for a 1-on-1, (2) You can name the top 3 blockers your team faces, (3) You have not introduced any new process, (4) Your manager is not worried about you. Do not measure yourself by team output - that is a month 3 metric. Do not measure yourself by how much code you shipped - that is an IC metric. Your only job in month 1 is to listen and learn.
When should I have my first difficult conversation?
Not in week 1. Probably not in week 2. By week 3 or 4, if you have observed a real performance or behaviour issue during your listening phase, you can address it - but keep it light. Frame it as: "I have noticed X. Can you help me understand what's going on?" Not as: "You need to fix X." The first difficult conversation where you actually hold someone accountable should happen in month 2 or 3, after you have built trust and credibility.