How to Transition from Managing Pipelines to Managing People like Prajakta

You Are Already a Manager Before the Title Most people wait for the promotion to start operating differently. That is the wrong order. The data professionals who get promoted into leadership are not the ones who wanted the title. They are the ones who were already doing the work before anyone gave it to them. Clarifying requirements with stakeholders when nobody asked. Helping teammates get unblocked when they had their own deliverables to ship. Asking the why behind the problem instead of just solving the what. The Week Your Code Sits Untouched There is a specific moment that signals the shift. You get to the end of a week and realize you made almost no progress on your own work — but the team moved forward because of the conversations you had. That discomfort is the job changing underneath you. If you wait until the title to start operating at the next level, you are asking your manager to take a bet on future behavior. That is a harder sell than showing them behavior that is already there. Speaking Up Is a Skill Early in any leadership journey, the most uncomfortable moment is the same for almost everyone: being in a room of more experienced people, knowing something is wrong, and deciding whether to say it. The imposter syndrome is real. The difference is learning not to let it make the decision for you. Facts Remove the Politics In data, you have a specific advantage: you can ground a challenge in numbers and evidence. When you do that, you shift the conversation from opinion to information. The most experienced person in the room does not win by default anymore. Leadership is about stepping up when something needs to be said. That is available to you at any level. An intern can flag a bad assumption. A senior IC can challenge a decision made three levels above them. The cost of staying quiet is harder to measure than the cost of speaking up. But it compounds over time. Empathy Is Leverage. As engineers, we are trained to solve technical problems. The higher you go, the more you realize the hardest problems are people problems. Misalignment. Stress. Lack of clarity. Someone having an off day. These do not have a clean solution. Some of them do not need a solution at all. Instead, they need listening. The Problem-Solver Trap The instinct to fix things immediately is exactly what gets senior ICs into leadership. It is also the thing that makes early management hard. Not every situation calls for a solution. Sometimes the person in front of you just needs to feel heard. When you learn to read that distinction — when you can tell the difference between a problem that needs solving and a person who needs to know you are paying attention — the team responds differently. People who feel understood and supported perform better without you pushing harder. You do not manufacture that with a process or a framework. It is built through consistent, genuine attention to what is actually going on beneath the surface. Technical skills get you to the role. Empathy and emotional intelligence determine how far you go inside it. Your Impact Becomes Invisible. That Is the Whole Point. As an IC, your output is visible. Code you wrote. Pipelines you fixed. A cost number you moved. You can point to it directly. As a manager, your impact shows up through other people. Better decisions. Stronger execution. A team delivering consistently and growing in the process. None of that has your name on it. Unlearning the Need to Own the Outcome The hardest thing to unlearn is tying your personal value to what you directly produce. Andy Grove put it clearly in High Output Management: your output as a manager is your team’s output. That is the measure. You do not have a separate output anymore. The team speaks on your behalf. That means impact can look like: Creating the right direction when things are ambiguous Removing friction before it slows the team down Helping someone succeed in a way they would not have without your support Building the environment in which good work happens consistently You stop building systems. You start building the conditions in which good systems get built. That is more scalable than anything you could ship yourself.