"People are squishy."
My words. Not a quote from some leadership book... my own words, said out loud to a colleague who asked if I'd ever consider moving into management.
I was a software engineer. Code was logical. Code didn't have bad days. Code didn't misread your tone in an email and spend the next week giving you the silent treatment. People did all of those things. I preferred to stay where I was: head down, building things, producing output I saw and measured.
It took years before I changed my mind. And when I did, it wasn't a dramatic lightning-bolt moment. It was gradual, uncomfortable, and eventually... wonderful.
Why I Said No
I want to be honest about the resistance, because a lot of technical people feel the same way but don't say it.
Managing people felt like a step backward. I'd spent years getting good at something specific. Architecture decisions, debugging sessions, system design trade-offs... I had hard-won expertise. Management felt like being asked to give all of it up and spend my days in meetings talking about feelings.
Underneath the surface was something more uncomfortable: identity. I was a software engineer. Not what I did... who I was. Moving into management felt like erasure. Like I'd be handing over the source of my value.
And, if I'm being completely honest, people scared me a little. Not in a dramatic way. I'm a people person at heart. But managing people... being responsible for their performance, their morale, their careers... felt like a different kind of accountability. Code errors throw exceptions. People errors are quieter, and they compound in ways you don't always see coming.
There's also a narrative in tech worth calling out. The "stay technical" path is celebrated. Staff engineers, principal engineers, distinguished engineers... these roles carry prestige. Management is often framed as a consolation prize, or something you do when you're not good enough to keep advancing technically. I absorbed some of those ideas, and they made me more resistant than I should have been.
It Chose Me
I didn't choose management so much as management chose me. My team grew. My responsibilities expanded. The organization needed someone who understood both the technical work and the people doing it. I said yes, mostly because saying no felt worse.
Those first few months were rough. I missed writing code. I found myself sneaking in at the weekend to work on tickets nobody had assigned me, because I felt more comfortable there. I attended management training and thought "I am a fraud." I had 1:1s where I sat across from people who were clearly struggling, and I had no idea what to say.
But slowly, something shifted.
The Conversation
I remember a specific conversation with a junior engineer on my team. He was brilliant... technically sharper than I'd been at his age... but he was stuck. Not on a technical problem. He felt invisible in the team. He felt his ideas weren't taken seriously in meetings. He was starting to disengage.
We talked for about 45 minutes. I didn't give him a roadmap or a solution. I asked questions and listened. By the end of it, he had a plan: he was going to start documenting his ideas before meetings so they were easier to articulate, and he was going to stop self-editing so aggressively in front of the group.
A month later, he ran one of the best technical discussions I'd ever sat in. The change in him was visible.
The conversation did more for me than shipping a feature. More than solving a gnarly architectural problem. The satisfaction was completely different... more personal, more lasting.
It's where I started to understand what people meant when they said "people are the work."
What I Got Wrong
I'd been thinking about management as giving something up. What I hadn't considered is what you gain.
When you lead people well, you multiply your impact in ways coding alone never achieves. One good developer ships one developer's worth of work. One good engineering manager shapes five, eight, twelve developers. The code they write, the decisions they make, the career paths they take... you have a hand in all of it.
I'd also been wrong about complexity. I thought code was complex and people were messy. It's the opposite. People are infinitely more complex than any system I've built. They're harder to understand, harder to debug, harder to fix. And the puzzles they present are more interesting.
What does it take for this person to do their best work? Why is this team underperforming despite everyone working long hours? What's the real reason this person is about to quit, and it isn't what they're telling me?
These are harder problems than anything in a codebase. They're also more meaningful.
What Nobody Warns You About
Managing people teaches you more about yourself than coding ever will.
You learn where your patience runs out. You learn whether you're as good at communication as you thought. You find out if you give clear enough direction, or whether you leave people guessing. You find your blind spots... usually because someone on your team is suffering quietly because of them.
In the Army, I learned early: leadership is a privilege. You earn the right to lead people by looking after them. The technical world wasn't always great at teaching this... there was a lot of "the best coder gets promoted" thinking... but the principle holds. Your job as a manager is to clear obstacles, develop your people, and make the team more capable than it was when you arrived.
I was once skeptical about the return on investment of good management. Now I run Step It Up HR because I saw, firsthand, how much a manager's behavior shapes everything around them. Good managers don't keep teams together by accident. They're the reason people stay, grow, and bring their best work.
The Data Worth Knowing
According to Stack Overflow's research on engineering management, many engineers who move into management miss the deep technical focus of individual contributor work. The loss of flow state is real. I felt it.
But the engineers who thrive in management are generally those who found a new kind of flow state in the people work... the coaching conversations, the team design, the mentoring. The transition works when you stop mourning the loss of one kind of satisfaction and start genuinely seeking the other.
The research also shows engineering managers of real quality are rare. Most technical leaders get promoted because of coding ability, not people skills. This creates a persistent gap: technically excellent people leading with approaches not serving their teams.
I was one of those people, early on. Learning to lead differently was harder work than learning any new programming language. But it was worth it.
To the Reluctant Technical Leaders
If you're where I was... head down, good at your work, quietly dreading the conversation about whether you want to "go into management"... here's what I wish someone had told me.
Management is not for everyone, and choosing to stay in an individual contributor role is completely legitimate. Some of the best engineers I know are senior ICs who've made a deliberate choice not to manage, and their teams and organizations are better for it.
But if the resistance you feel is based on the belief people are too messy, too unpredictable, too soft... then your resistance is based on a misunderstanding.
People are everything code is not. They surprise you. They grow in ways you didn't expect. They bring insight from directions you never anticipated. The work of leading people well is harder, messier, and more rewarding than anything you'll build in a terminal window.
I used to say people are squishy. Now I'd say people are the whole point.
So if you're on the fence: give it a proper try. Not six months of reluctant compliance, wondering when you'll get back to the "real work." A genuine attempt, where you show up curious and committed, and see whether it turns out to be the thing you were made for.
It was, for me.