{"id":172,"date":"2026-04-21T16:43:49","date_gmt":"2026-04-21T16:43:49","guid":{"rendered":"https:\/\/bkbc.net\/index.php\/2026\/04\/21\/ic-or-manager\/"},"modified":"2026-04-21T16:43:49","modified_gmt":"2026-04-21T16:43:49","slug":"ic-or-manager","status":"publish","type":"post","link":"https:\/\/bkbc.net\/index.php\/2026\/04\/21\/ic-or-manager\/","title":{"rendered":"What to Consider Before You Accept a Management Role"},"content":{"rendered":"
<\/p>\n

This article is crossposted from <\/em>IEEE Spectrum\u2019s careers newsletter. Sign up now<\/em><\/a> to get insider tips, expert advice, and practical strategies, written in partnership with tech career development company Parsity<\/a> and <\/em><\/em><\/em>delivered to your inbox for free!<\/em><\/em><\/p>\n

The Individual Contributor\u2013Manager Fork: It\u2019s Not a Promotion. It\u2019s a Profession Change.<\/h2>\n

When I was promoted to engineering manager of a mid-sized team at Clorox, I thought I had made it.<\/p>\n

More money. More stock. More visibility. More proximity to senior leadership. From the outside, and on paper, it was clearly a promotion.<\/p>\n

I had often heard the phrase, \u201cManagement isn\u2019t a promotion. It\u2019s a job switch.\u201d I brushed it off as clich\u00e9 advice engineers tell each other to sound wise.<\/p>\n

It turns out both things were true. It was a promotion. It was also an entirely different job.<\/p>\n

And I was nowhere near ready for what that meant.<\/p>\n

A Shift in Priorities<\/h3>\n

There\u2019s surprisingly little training for new managers. As engineers, we\u2019re highly technical and used to mastering complex systems. Many of us assume managing people will be easier than distributed systems. Or we assume it\u2019s just \u201cmore meetings.\u201d<\/p>\n

Both assumptions are wrong.<\/p>\n

Yes, I had more meetings. But what changed most wasn\u2019t my calendar, it was how my impact was measured. As an individual contributor, my output was visible. Code shipped. Features delivered. Bugs fixed.<\/p>\n

As a manager, my impact became indirect. It flowed through other people.<\/p>\n

That shift was disorienting.<\/p>\n

So I fell back into my comfort zone. I started writing more code. I tried to be the strongest engineer on the team. It felt productive and measurable.<\/p>\n

It was also a mistake.<\/p>\n

By trying to be the number one engineer, I was neglecting my actual job. I wasn\u2019t supporting senior engineers. I wasn\u2019t unblocking systemic problems. I wasn\u2019t building career paths. I was competing with the very people I was supposed to enable.<\/p>\n

Management is about amplification.<\/p>\n

Learning to Redefine Impact<\/h3>\n

The turning point came when I began each week with a simple question:<\/p>\n

What is the single most impactful thing I can do right now?<\/strong><\/p>\n

Often, it wasn\u2019t code. It was writing a document that clarified direction. It was fixing a broken process with a single point of failure. It was redistributing ownership so that knowledge wasn\u2019t concentrated in one person.<\/p>\n

I started deliberately removing myself from implementation work. I committed to writing almost no code. That forced trust. It also revealed gaps in the system that I could address at the right level: through coaching, documentation, hiring, or process changes.<\/p>\n

Another major shift was taking one-on-one meetings seriously.<\/p>\n

Many engineers dislike one-on-ones. They can feel awkward or devolve into status updates. I scheduled them every other week and approached them with a mix of tactical alignment and human check-in.<\/p>\n

I rarely started with engineering questions. Instead:<\/p>\n