What I Wish I Knew About Management When I Was an IC

I fell into managment out of necessity not an active choice, as often happens in startups. When you find yourself in a management role in these technical fields, you of course think you know everything, but quickly realize that you had no idea.

Not wrong in a “this is terrible” way, but wrong in a “the job is fundamentally different than I imagined” way. Here’s what I wish someone had told me before I made the jump.

Your Day Will Be Unrecognizable

As an IC, I had this fantasy that management would be like my current job plus some meetings and people stuff. The reality is that your entire relationship with work changes.

You will have very few uninterrupted blocks of time. Paul Graham’s essay “Maker’s Schedule, Manager’s Schedule” captures this perfectly - you move from a maker’s schedule (long blocks of uninterrupted focus time) to a manager’s schedule (time chunked into hour or even 30 minute blocks). That deep focus you relied on for complex technical work? It’s gone. Your calendar becomes a series of context switches. Some days you won’t write a single line of code or finish a single “big” task, and that has to be okay. This is one of the hardest mental shifts, learning to feel productive in a completely different rhythm of work. It fundamentally changes the kinds of technical work you can still do well.

Your value creation becomes indirect and delayed. The dopamine hit of pushing working code or seeing a model perform well is replaced by slower, more ambiguous wins. Did that coaching conversation help? Will the process change actually improve things? You often won’t know for months.

You become a service function for your team. Your job is to remove blockers, provide context, and enable others. Some days you’ll feel like a glorified project manager. Other days you’ll realize you prevented three different fires from starting. Both are the job.

The Technical Relationship Gets Complicated

You can’t stay equally technical. I don’t care what anyone tells you-you cannot manage a team well and maintain the same technical depth you had as an IC. Something has to give. The key is being strategic about where you invest your limited technical time. You can’t use it to do just the most interesting work, that goes to the team.

Your technical opinions carry different weight. When you were an IC, technical debates were (mostly) about being right. As a manager, your technical opinions can shut down discussions or create false consensus. You have to learn when to share your view and when to facilitate others finding the answer.

You become responsible for technical decisions you didn’t make. Your team will make implementation choices you wouldn’t have made. Some of them will be wrong. You have to decide when to intervene and when to let people learn from experience.

The People Part Is Everything (And Nothing Like You Think)

Everyone is different, and nothing works for everyone. That management book you read? The framework that worked for your old manager? None of it applies universally. You’ll spend a lot of time figuring out what motivates each person, how they like to receive feedback, and what support they need.

Performance issues are harder than technical bugs. Technical problems have root causes and solutions. People problems are messier. Someone might be struggling because of personal issues, unclear expectations, skill gaps, team dynamics, or they’re just not in the right role. Usually it’s multiple factors.

You’ll have conversations you never expected. Career anxiety, interpersonal conflicts, personal crises that affect work, salary negotiations, difficult feedback-all of this becomes your responsibility. Some of it you’ll be naturally good at. Some of it you’ll have to learn through painful trial and error.

The Hiring and Firing Reality

These are the decisions that will haunt you. Nothing prepares you for the weight of hiring and firing decisions. When you hire someone, you’re betting on their potential and their fit-not just their current skills. When you fire someone, you’re ending their livelihood and possibly derailing their career trajectory. Both decisions have profound impacts on real people’s lives.

Hiring is harder than you think. You’re not just evaluating technical skills anymore. You’re trying to predict how someone will mesh with the team, handle ambiguity, grow over time, and contribute to culture. The person who aces the technical interview might struggle with collaboration. The one who seems perfect on paper might not thrive in your specific environment. You’ll make mistakes, and those mistakes compound-a bad hire affects team morale, productivity, and your own credibility.

Firing someone is brutal. Even when it’s the right decision, even when you’ve tried coaching, provided support, and given clear feedback: telling someone their job is ending is gut wrenching. You’ll question yourself constantly: Did I give them enough support? Was I clear enough about expectations? Could they have succeeded with a different manager? The worst part is when you have to let good people go due to budget cuts or strategy changes. There’s no amount of business justification that makes it feel better. It’s obviously harder for the person being let go, but still tough.

The timing is always wrong. You’ll keep underperformers too long because you want to believe they can turn it around. You’ll rush hiring decisions when you’re understaffed and desperate for help. Both create bigger problems down the line. Learning to act decisively, but not rashly, on people decisions is one of the hardest skills to develop.

Your reputation depends on these decisions. Your team watches how you hire and how you handle performance issues. Hire poorly, and they question your judgment. Keep deadweight, and they resent carrying extra load. Fire someone harshly or unfairly, and you lose their trust. But handle these decisions with fairness and transparency, and you build credibility that makes everything else easier.

The Strategic Burden

You become responsible for direction, not just execution. As an IC, someone else figured out what to build and why. Now that’s partly your job. You have to have opinions about strategy, priorities, and resource allocation-even when you don’t have complete information.

You represent your team up and your company down. You’re simultaneously advocating for your team’s needs to leadership and explaining leadership decisions to your team. Sometimes these feel contradictory. Sometimes they are contradictory.

You make decisions with incomplete information. As an IC, you could often dig deeper, run more experiments, gather more data. As a manager, you frequently have to make calls with 70% of the information you’d like to have.

What Made It Worth It (For Me)

Despite all this, I don’t regret the transition. But it’s worth understanding why it worked:

I genuinely enjoy developing people and teams. Not everyone does, and that’s fine. But if you don’t get energy from that aspect, management will drain you.

I like systems thinking. Management is largely about designing systems-processes, communication patterns, team structures that enable good work. If you think in systems, many management challenges become interesting puzzles.

I was ready to multiply impact differently. The shift from “what can I build?” to “what can my team build?” felt like a natural evolution, not a loss.

The Decision Framework

Before you make the jump, honestly assess:

• Do you get energized by other people’s success, or do you need personal achievement to feel fulfilled? Does getting credit for things personally matter to you?
• Are you comfortable with ambiguity and indirect impact?
• Can you find meaning in enabling work rather than doing work?
• Do you have the emotional bandwidth for difficult conversations and interpersonal complexity?

There’s no right answer, just what’s right for you. But go in with open eyes about what you’re actually signing up for.