Andrea | Code to People

The IC to manager transition isn’t a promotion. It’s a career change.

This is the most underused rule in management. The feedback conversation you’ve been avoiding for weeks? It almost always goes better than you imagined. And the delay costs far more than the discomfort. Most managers wait until the situation is already broken. The ones who get better learn to have the conversation early - when it’s still just uncomfortable, not urgent.

A general rule of life: the more afraid you are to talk about something, the better you’ll probably feel after talking about it.

@THEROSSHARKNESS Agreed, and this matters even more when you’re managing people. AI can’t fix how your team thinks or operates either. And as a manager, that’s now your problem to solve - not just for yourself, but for everyone around you. Your leverage multiplies. So do your blind spots.

The one thing AI can’t fix is how you think, focus, operate and execute. Funnily, that’s where your biggest advantage lies.

The “reluctance to speak without something to say” is exactly what new managers struggle with - they feel pressure to fill every silence in 1:1s and meetings. And depth over breadth with your team is exactly how trust gets built - not by being liked by everyone, but by really knowing a the people well.

Things I wish someone had told me when I started in my career: The reluctance to speak without having something to say was actually quality control. The preference for depth over breadth in relationships was actually the foundation of a network built on trust rather than volume.

I spoke to someone yesterday who’s been a senior architect for years. Burned out. Exhausted. Wondering what comes next. She said she didn’t thrive in management because she hated giving critical feedback. Here’s what I told her: That’s not a personality trait. That’s a skill nobody taught you. The architects, engineers, and analysts who feel stuck often have exactly the instincts management requires - strategic thinking, systems awareness, deep domain knowledge. What they’re missing isn’t capability. It’s the framework for translating those instincts into leading people. That’s the gap nobody talks about. And it’s 100% learnable.

Worth adding: if you ever move into management, coding drops to near 0%. But clear communication, understanding trade-offs, ownership mindset - those stay. They just apply to people and decisions instead of code. The skills that make a great senior engineer and a great manager overlap more than most people expect.

I asked 10 senior engineers: "What skill makes a developer stand out?" Almost everyone said the same things: 1. Debugging skills 2. Reading other people's code 3. Clear communication 4. Understanding trade-offs 5. Writing simple code 6. Knowing system fundamentals 7. Curiosity 8. Consistency 9. Ownership mindset 10. Learning quick. Coding is only 20% of engineering

Same is true in management. New managers often go looking for the right framework, the right 1:1 template, the right performance process. But the managers who actually get better start by understanding what’s really going on with their team. The tool only works once you’ve diagnosed the problem.

Hello Datafam You don’t need 5 tools. You need to understand the problem.

Tech support teaches you things most technical roles don’t. How to communicate clearly when someone is frustrated. How to stay calm under pressure. How to solve a problem that isn’t your fault but is now your responsibility. Turns out those are also the core skills of management.

starting out in tech support was definitely rough, but looking back, it really set me up for success.

@rajshamani This is how trust gets built with your team too. Through whether you followed up on that thing you said you would. Whether your 1:1s actually happened. Whether your feedback matched your actions. Your team is watching the pattern, not the words.

The most trusted people aren't always the most honest. But they're always the most consistent. Trust isn't built by what you reveal. It's built by whether what you say and what you do match, repeatedly.

Most managers get to this point without ever having a direct conversation about what’s not working. They absorb the slack, cover the gaps, and avoid the difficult feedback - until they’re exhausted and the person still doesn’t know there was a problem. The burnout isn’t just from doing their work. It’s from never addressing it.

You don't burn out from doing too much work. You burn out from doing the work of the people you refuse to fire.

@TheBayoHub Wait until you become their manager. The stress doesn’t go away - it just becomes everyone else’s stress too. 😅

As a Data Analytics Beginner, are you stressed?

The small talk before a firing is almost always self-soothing by the manager. It doesn't help the person being let go - it just delays their ability to process what's happening. I'd add: the script is less important than the clarity. Say the thing clearly in the first 60 seconds. Everything else is noise.

So many founders botch the firing conversation because they ease into it. You can tell because it starts with 5 minutes of small talk. This is exactly how I do it, start to finish: 1. Send a pre-message: "We need to have a difficult conversation today. Are you available for 15 minutes?" That message leaves no room for misunderstanding. 2. No small talk. First sentence: "I've made the difficult decision to let you go." 3. Keep it short. You're walking through the next steps, not relitigating the decision. 4. If they push back: "This is a decision I've already made. The point of this conversation is to discuss the transition." 5. Tell them exactly what you'd say as a reference so they can decide whether to list you. The hardest part is having done the work, so they already know it’s coming.

@TheJobfather__ Especially true if management is in your future. LeetCode gets you through the interview. Social skills determine whether your team actually wants to follow you once you’re in the role.

A lot of people in tech are grinding LeetCode when they should be sharpening their social skills

@LeadClearly1 That’s why communication skills are so important to master when moving i to management.

A team keeps asking questions. The leader gets frustrated. The leader assumes the problem is the team. "Why do they need so much clarification?" But look closely at the pattern. The questions are not random. They are clustered around the same things: Expectations. Priorities. Decision boundaries. This is not dependency. It is a signal. When direction is incomplete, people fill the gaps by asking. Over time, if answers feel inconsistent, they ask even more. Or they stop asking and start guessing. Both slow execution. Strong leaders pay attention to repeated questions. They don't just answer them. They fix the original instruction. Clarity reduces questions. Confusion multiplies them.

None of the analysts on my team understood how compensation calibration worked. So I sat down with each of them and walked through the entire process. How performance ratings are decided. How the matrix works. What factors influence the outcome. Every single person said some version of: 'I had no idea. I always just assumed.' It's shocking how many ICs have no idea how decisions about their own career are being made. You can't advocate for yourself in a process you don't understand. And as managers, we have a responsibility to provide as much transparency as possible.

Staying technical as an engineering manager is a real tension - and AI is making that part easier. What’s harder to offload is the people side. Feedback, delegation, team development - there’s no AI tool that does that for you. Most managers default to staying technical because it’s familiar. The ones who grow are the ones who invest equally in the harder side.

As an engineering manager, Codex from @OpenAI has been key for keeping me in the code while still supporting my team. We paired up to share a few snippets on how I used it to ship Voice Input in Notion AI. 📺👇

This is the thing nobody says out loud before the promotion. I used to think everyone promoted to manager was promoted because they had the skills for it. I was wrong. Most are promoted because there's no upward IC path - not because they chose this. That's not a personal failure. It's a structural one.

One of the biggest mistakes you can make in your career is getting into management "just because." Too many people think the only way up is a linear path from IC to manager to director to VP without realizing management isn't a promotion but an entire career change. Becoming a manager is a lot like becoming a coach. You stop playing the game. You stop getting individual credit, and your job now becomes making other people successful. If you got into it for the title, the pay bump, or because you thought it was "the next step" you're probably going to burn out. The best managers I've worked with genuinely wanted to develop people. The worst ones wanted the corner office and ended up micromanaging everyone into the ground because they couldn't let go of being the best individual performer.

@vheeorji22 Add “coach for your team” and “translator for your skip-level” and you’ve basically described management.

learning data analytics means also becoming a detective, a storyteller, and a therapist for confused stakeholders

A lot of workplace anxiety comes from managers hoarding context. When people don't understand why decisions are made, they fill the gap with assumptions. Usually the wrong ones.

The hardest part is that new managers rarely see this happening in real time. Discretionary effort disappears quietly. No one announces they’ve stopped going the extra mile. By the time it shows up in output, the trust is already gone. Learning to read those early signals is one of the most underrated skills in management.

Accountability without support is just blame with a title. Leaders either absorb pressure or redirect it because incentives reward self-protection over ownership. Most call it delegation while stepping aside. The team notices and recalibrates risk immediately. Discretionary effort disappears first. “Effort follows protection.” Output narrows, decisions get safer, and upside vanishes before anyone names it. You can recover a missed deadline. You can’t recover the moment the team priced the work as unsafe.

This is one of the hardest habits to maintain when you become a manager. The pressure to act is constant. Decisions feel urgent. Slowing down to think feels like inaction. But the managers who pause to map the problem first almost always get better outcomes than the ones who jump straight to solving it.

I once spent 3 days on a single implementation plan. Didn’t write a line of code. Didn’t open my editor. Just thinking. Mapping flows on paper. Tracing every dependency. Asking myself "what breaks if this fails?" When I finally started building - it took 2 days. Clean. No rewrites. No surprises. If I’d jumped in on day one like I used to? It would’ve taken 2 weeks and 3 panic calls. Most developers confuse movement with progress. The person who thinks for 3 days and builds for 2 will always outperform the person who builds for 10 and rewrites for 10 more.