Andrea | Code to People

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

Your team doesn’t push back on leadership. You do that for them. If you’re silently passing down unrealistic deadlines, you’re not managing. You’re just forwarding emails.

@randomrecruiter As a manager I have one rule: nothing after 3pm on a Friday. Some hills are worth dying on.

"I need a mental health day because my manager scheduled a 4pm Friday meeting" Meanwhile your ancestors on a random Tuesday:

@JoinBlind A lot of this is what happens when nobody prepares you for the actual job. Micromanaging and redoing people’s work aren’t signs you hate management - they’re signs you were handed the title and left to figure it out alone.

Promoted to manager, demoted in happiness 😅

The ones who got into leadership by default (promoted because they were the best IC, not because they wanted to lead) often never made the identity shift to being a manager in the first place. Going back to hands-on work isn’t regression. It’s just honesty about what they actually want.

Every day I’m talking to 1-2 L7s and L8s who are trying to find a truly hands on project to become a pure IC again. The dynamics of engineering has changed.

@1ssve Agreed. And as a manager, I’d add: if you find yourself wanting to ask why - the more important question is why you don’t already trust your team enough not to need the answer.

If your manager approves your leave without asking for a reason, it means you work in a good culture. Personal leaves should not be questioned. It's basic human rights.

Same is true for how managers develop their team. You can’t announce “I’m investing in your growth” and have that mean anything. Development isn’t a favor you grant - it’s a relationship that forms through the challenges you give, the feedback you deliver, and the trust you build over time. The managers who say it the most are often the ones doing it the least.

If you’re asking someone to be your mentor, you’re doing it wrong. Mentorship is not a favor you ask for. It’s a relationship that develops when you demonstrate that you are a cannon worth pointing at a big problem.

The common thread across all 7: managers who still think their job is to have the answers. Showing up unprepared, doing status updates, avoiding challenge - it all comes from not yet understanding that the 1:1 exists for them, not for you. The shift from “what do I need from this meeting” to “what does my team member need from me” fixes most of this list.

7 Reasons Your 1:1s Are a Waste of Time (And how to fix them before your next meeting)

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.