It’s kind of sad because you can tell pretty quickly who has always been told what to do. In the beginning they’ll struggle so you can’t just leave them to drown. When they get over that, they need almost constant affirmation. It can take years which is fine. But it often operationalizes itself as really talented people who get stuck as intermediate developers.

So it turns into two competing management problems. How do you convince them that management works for them? And how do you groom them into leadership positions? The first is the easier of the two.

Most importantly, how to reach agreement with different stakeholders on decisions where you have insufficient data. That‘s where making an argument comes in. You weigh different alternatives. You show the consequences. You conduct workshops - where in the end the people might have gone through the same thinking process you have gone through, but now they are buying in to the idea. You learn to manage up and across.

You learn when to step back. Where you should let others shine and enable them making a career. And become a mentor.

You learn how to take risks. That you need to balance high-risk, high-reward projects with quick, short term wins. That you need to find out how to do both at the same time. One securing the funding for the other.

You learn that relationship power always trumps knowledge power and power through authority. You learn to get to know people as human beings and learn about their motivations.

You become a servant of the team, filling in the gaps where they exist. Because you can.

I‘m still writing code as well, as I have since I was in my teens. Still loving it. Writing a piece of code that solves a difficult problem in a beautiful way makes me high.

[Insert frustrated comment here about how capable, sufficient and well-performing ICs are absolutely rewarded.....with more work and additional duties]

But... if your manager is displeased with most ICs for brainstorming, considering edge cases, researching possible solutions, refactoring, helping other people, testing, and automating... you should probably consider working somewhere else. These are all things the industry does too little of, and that my company puts significant effort into encouraging and rewarding. They are also important steps in growing into (technical or people) leadership roles. And they are nowhere near the top of the list of things that people waste time on.

As someone who many years back looked at a team of 40 developers I was leading and went “nah, I want to be an IC again” that resonates

Helping other people grow has also been important to me. Mentorship and teaching have always been things I prioritized. When I moved into a management role a couple of years ago it was because I’d done the principal level IC thing before where I was extremely cross-functional and I wanted to try focusing on a specific part of the business and a specific team of people and try to grow them. I wanted to grow vertically rather than horizontally.

I think I’m a pretty good manager, based on feed back from my team and my peers, but the reality is that it’s enormously more draining than I ever imagined and there’s very little to concretely feel satisfied about at the end of a given day. When I became a manager I thought I’d just code in my spare time since I wouldn’t be coding at work, but in reality I’m far far more burned out from any given day of management than I ever was from the most stressful day as an IC. It’s hard to find the motivation after work, and I worry about my skills slipping over time.

In an abstract sense it feels good to see a product grow, and to grow a team, but practically speaking none of the success is mine. Every good thing that gets done is thanks to the people on my team. Their growth and accomplishments are ultimately thanks to them. I facilitate, I give direction, I find alignment and build consensus, hopefully I make things easier- but I personally accomplish nothing. It feels like being stuck running at top speed on a treadmill going nowhere. Being a manager means taking on none of the credit when things go well, and all of the blame when things go poorly.

Unfortunately, part of what got me into management at all was caring about the product and the people and no matter how much it sucks giving up and going back to an IC role seems worse. I don’t want to leave my team unsupported or risk them getting a worse manager, and I don't want to see the product my team owns fail due to a lack of leadership. I’m hopeful that in a few more years with more experience I’ll figure out ways to be happier with the situation, and until then I just try to remember that most people hate their jobs and I’m just lucky to have had almost 20 years of loving mine before moving into management.

I’ve been here for 8 years, and never known that to be true. At most, higher IC levels are expected to do more “direction setting” work (ie, writing a technical design doc for your team to follow, rather than writing all the code by yourself), but that’s still distinct from “management”

In most companies that's definitely the case. You can make way more as a mediocre manager than as an outstanding IC.

What I learned was that communicating your vision (or implementing the vision of your boss) is not enough, you've got to be in there next to your people and show you understand why they are not able to get to where you are leading them, so you can find new ways to unblock things and get them to do what you need them to do.

Also: sometimes the only way to prevent shit from rolling downhill onto your people is to take it on yourself. You pay a real price for the perks of rank, if you take your responsibility to your people seriously.

What I learned about being an IC is to have some empathy for management: they can be trying but the results can look like they are not because of the enormous inertia of groups of people.

the idea that there's no path for ICs beyond management is insulting and degrading to the hard working creatives and engineers out there. Don't give up there's a place for you, you just need to look a LOT harder and in places you wouldn't expect. Play the numbers its a statistics game.

That's just the reality of senior IC engineering positions. At some point, there's a limit to the amount that you can contribute by sheerly by your own work - to have a bigger impact, you'll need to need influence/improve/impact others

This was one of my biggest lessons transitioning to management. My biggest mistakes have all been cases where a feedback loop from engineering to PM/UX/leadership was missing and I failed to set one up. Biggest successes have been projects where I set that feedback loop up early and got out of the way, so that engineering and UX had a high-bandwidth communication pathway to negotiate issues and make product compromises based on real constraints.

Unfortunately it feels like I'm swimming upstream when it comes to actual org policies here, which have forcibly reclassified me from a TLM to an Engineering Manager (so my official job duties now include assigning work, but not necessarily understanding the work I'm assigning), given me a reporting load that's too big to understand the details of each project I'm managing, made my report's performance reviews independent of how well they work with others and instead fully dependent on how much they please me, made my performance reviews largely independent of how well I support my team but very dependent on how well I please my superiors, and so on. Somebody in upper management wants people to be responsible for things and yet doesn't seem to know or care much about how to actually get results in a knowledge-based org.

Life is always about trade offs.

I thought that was the whole point of the IC track: putting a technical person into a role where they can be a multiplier without burdening them with management responsibilities.

Every staff/principle/architect IC I've ever worked with has had that kind of positive effect on the teams around them. Their schedules were indistinguishable from most managers, except they met mostly one on one and they could get a senior engineer's worth of work (impact wise) done in between the meetings instead of paying the management overhead.

If I'm accountable to (recognized) business value, something is deeply wrong. The whole reason we have you is to shoulder that responsibility, and to insulate developers so that we're only accountable for/thinking about architecture and implementation. If I have to do the job of both engineering manager and engineer, I'll find somewhere to pay me both compensation packages (i.e. consulting), or (more likely) somewhere I can do just one.

As an aside, even if all your projects are successful, comparing ICs on business value created only tells you who you gave the most impactful projects to. Sometimes your best engineers are stuck doing unsexy, low-impact but necessary maintenance. They create no business value, but prevent existing business value from being destroyed by bit-rot. Sometimes your weakest engineers get a low-hanging-fruit project that's impossible to screw up and immensely valuable to the business. That does not make them ready to take a larger role in more difficult problems, which is typically what a high performance rating entails.

Otoh, what ICs often overlook is that managers often lack the hard and soft power to manage effectively, which of course is a leadership problem in itself. I’ve had well-meaning managers who still were bad for me because they didn’t have enough influence or respect in the greater org. Just like with engineering, even the best can’t do a great job if they are unable to access the right tools.