Hacker News Reader

Comment by ep103 | Hacker News Reader

The moment I saw this link, I clicked it. I'm pretty lost for advice at the moment, and hoped this would help. But it looks like it is just a collection of interviews with people who became managers about what they've learned?

One of the quotes on the page was:

"Moving from dev to manager is NOT A PROMOTION. It's a CAREER CHANGE."

This is what I'm having a problem with.

I look at my team, and the entire office is happier than I've seen it in 5 years. I'm watching people train, and actively grow under my management. It is incredibly rewarding, and much, much better than before I moved to my current position.

But I've also spent the last 9 weeks doing nothing but reading resumes, phone screens, and interviewing candidates. Staring at an excel spreadsheet mix of engineers I could out-code, great developers I can't afford, internal politics, and emailing recruiters all day, isn't what I went into engineering for. Being judged on my projected demeanor in meetings, ability to navigate politics, and clear bureaucratic hurdles for my team isn't itself enjoyable... its soul-sucking and stressful.

I wake up every morning and don't want to get out of bed. I've started setting aside a (very) small portion of time for coding, just because I miss it so much. Ever wake up and realize you are going to spend the first two hours of the day rescheduling meetings... again?

But most days, something will happen among the team, where, before I leave, I'll realize "That wouldn't have happened here before you rose up the ranks. You've made all of these people's lives better." and it'll bounce me back a bit.

Your website says that the transition to management is difficult and nuanced, but things like the above are what I need help with.

View on HN

You're just getting started. Most of what you are feeling is temporary (like all feelings). You will grow with your challenges.

> its soul-sucking and stressful.

Remember that you are still creating software - you are just doing it through others.

> I've started setting aside a (very) small portion of time for coding, just because I miss it so much.

That's a very good strategy. Aside from keeping you happy, it will help you to understand what the team is doing. It will keep you grounded and help you gain respect.

> Ever wake up and realize you are going to spend the first two hours of the day rescheduling meetings... again?

It sounds like you are already a pretty good people manager.

The next thing you need to learn is to manage your time. Your goal should be to do as little as possible. Your todo list should be empty by 5pm.

1. Learn to delegate. Only do the things that nobody else can do well enough.

2. Learn to say no. If you say "yes" to a task, remember that this implies saying "no" to another task that you could have done in this time.

3. If you cannot do something now, snooze it so it disappears from your todo list/email inbox until you can do it and does not distract you in the meantime.

> Remember that you are still creating software - you are just doing it through others.

It is probably just as enjoyable as reading a book through others, or watching a movie through others.

Fair point. Though people’s motivations differ and for some, the above might be a motivating thought.

Perhaps, but i love to share a favorite book, movie or album with others and it feels similar.

When you kindle the start of the same feeling in someone else that you got from learning or experiencing something new is the best

That still implies you read the book at some point to share it. Successful management career paths you end up not even knowing if you're sharing the book or movie version of a story you only had the blurb for.

Coming from a position where I have done both, I'm confident in telling you this is not true. Before I actually tried it, I was convinced this was the case though. It's a tempting thought that seems correct on the face of it.

>Remember that you are still creating software - you are just doing it through others.

Managers should not be creating software. Directly or indirectly (unless you're a product manager or in a position where you have to take PM responsibilities). I've had too many managers try to insert themselves in design decisions, micromanaging and what not. Managers should be managing people. Making people happier and more productive and communicating what your people can and cannot do with the higher ups. Even deadlines and milestones, etc should be PM responsibilities, not dev managers.

In a software company you can make the argument that everyone contributes to the process of making software. I would say that managing resources towards the development of a product IS indirectly creating software.

Better than delegating is setting up systems where the team can be self organising. If you can sell higher up on not being too deadline focused, this can work well, the team can learn how to prioritise and figure out a crisis. A good sign is if you can go on a 4 week vacation with very little to “hand over”.

Management as it exists today is bullshit. Complete waste of time. Scheduling meetings to discuss the business process is a waste of time.

A good manager does not need processes, they just need to make sure that stuff gets done to a high standard. That just means delegating tasks to people you can trust to complete the tasks. If you can't trust your people and need expensive project management software to get the necessary visibility to manage the shit out of them, then you already failed at your job.

While it's tempting to ignore the realities of working with large groups of people in favour of a simplified model that is easy to problem-solve against, it's not particularly useful as a way to figure out what to do in real life.

I said systems on purpose, not processes. Systems can exist in the heads and habits of the team, without a JIRA workflow or such like.

I didn't disagree with your statement. I was adding to it.

The problem is it really is a career change.

> I'll realize "That wouldn't have happened here before you rose up the ranks. You've made all of these people's lives better."

Yeah so what, they might like you (if they even find out its due to your hard work) but if you don't enjoy it what's the point? Eventually you'll be just another manager who doesn't have up to date tech skills and is due to get laid off.

I went into middle management. It sucked. I went back into a senior dev role, tiny pay cut but much more employable and fun.

I'm a senior dev who could cross over if I wanted to, but when I see what the managers are doing on a day-to-day basis I realize I'm perfectly happy doing what I'm doing and making pretty solid money while I'm at it.

Oh man, I know exactly what you are going through. I had the "3am chest squeezes" for a long time, I'd wake up thinking I should be working harding doing SOMETHING to make SOMETHING happen. And realizing that even if I worked 80 hours a week there were somethings I could not budge. It's like with coding if you put in a lot of effort you can fix things, but with management there is no feedback loop like that. It took me a long time to get used to.

Delegation is necessary but it hard the first few times. It takes a lot of getting used to because very few people are going to do things up to your standards (some will do >= you which is awesome). Note that eventually these feelings went away...until I got promoted and then they came back again: 3am chest squeezes and a sense of "I don't know what the fuck I'm doing again and no matter how hard I work the needle doesn't move."

Over the years I realized this is just a side effect of new challenges with increased responsibility. You (YOU) are a natural problem solver and it takes MONTHS to come up to speed so don't beat yourself up. You will solve the problems and invent your own systems.

Finding mentors is hard, but I found some through Meetup.com of all places (bay area, austin, and portland are my haunts). Note: they're not all older than me, but they have had similar experiences. Mentors can be younger than you. And mostly they don't have specific help because at this level techniques aren't really transferrable from person to person... my startup founder friends just remind me I'm not a phony fuckup. And that matters.

Welcome to being a grown up!!! It'll never be quite as fun as being a 20-something hacking code 80 hours a week for years on end, but there are new things to enjoy with age!!! (Confession: I still write shell scripts to procrastinate because it makes me feel like I've accomplished something.)

Good luck! This sounds cliche, but remember YOU REALLY CAN DO IT, don't set the bar impossibly high. You've got the right attitude with your realization in the sentence to last. Just trust that your knack for problem solving as a coder will cause your brain to inevitably figure out creative solutions to your current problems.

You're 9 weeks in? It takes months to get used to it.

> But most days, something will happen among the team, where, before I leave, I'll realize "That wouldn't have happened here before you rose up the ranks. You've made all of these people's lives better." and it'll bounce me back a bit.

This is what you need to focus on. Everyone has parts of a job they don't like. What you described here is the reason you're a manager.

I don't think he's 9 weeks into a managerial position, I think those things he listed are just the things he's been doing for the last 9 weeks, sounds like they're hiring right now.

He's just saying what he has done in the last 9 weeks. Overall experience seems higher to me.

(Using he in the gender agnostic way).

9 weeks into this hiring sprint. Maybe a few more depending on how you count. ~2-3ish years into management, again, depending on how we count.

I agree with your second statement.

I suppose what I'm trying to vocalize is the following:

When working on code, the work itself is fun. Coding is enjoyable. That means an 8-10 hour day is largely 8-10 hours of enjoyment.

With management, those ~8-9 hours are no longer enjoyable. The end result is extremely fulfilling and meaningful, much more so than code... but I'm genuinely not finding the actual work of management enjoyable, quite the opposite.

I think I need a way to find the managerial aspect itself enjoyable, otherwise it feels like light suffering for several hours each day in return for the overall health of the rest of the team. And as much as I like these people, that's not long-term sustainable.

I think the way forward might be to fully commit to the positive aspect you highlighted. To consciously attempt to keep in mind the meaning and enjoyment that comes from the making of connections and improvements of the people around me.

I'd love it if a more experienced manager could chime in here and speak to whether or not that really can be enough to power one through the endless meetings, excel reports and politics given time.

And I agree with what other commenters have said. It is simply not possible to be a good manager, while attempting to stay relevant in technology. There simply isn't enough time each day for me to balance my life, keep up to date with code, and learn the management skills I need to improve on.

But that means consciously giving up on staying technically relevant, in this competitive industry..... for a new role which day to day, I'm not finding day-to-day enjoyable. That's a huge leap of faith, that quite honestly, I find very scary to take.

Meanwhile, it seems similarly risky to just give in and go back to pure code, and give up on this managerial aspect. I clearly do have an aptitude for it, it clearly is rewarding, and getting the opportunity to climb this high simply does not happen every day.

Hence, the feeling of being in need of advice, and somewhat stuck.

The recruitment is definitely a killer. If at all possible, outsource as much of that as you can. To internal recruiters, to engineers in your team, to external recruiters, to a pa you might want to hire to do bits of it.

Have you tried diving into some gnarly bugs or some off-critical-path items that would help you stay in the code while doing these other things? A manager’s job is typically about building a team as their product, but it’s also important to stay connected to the technical part - both for love and for relevance / humility.

Have you asked (if available) someone to help with recruiting? Maybe offload some of the nitty gritty things that you aren’t adding value on to someone that can, or somebody that works for you and is interested in that side of the work?

To enjoy every minute of the day requires understanding why you are doing it - to build your team. Connecting back to what it will get you may help.

If you’re stuck doing stuff you don’t want to do because somebody above you “said so” (the curse of middle management) then that may make things a lot harder but you may also talk to them to help shape your role into what you want for what they need.

I don't think a manager should be grabbing tough bugs unless there is no time sensitivity (so why are you addressing them?) as they never have enough time to complete them and become a blocker.

I think your best bet is to do strategic technical spikes and as an output identify deeper areas for your engineers to pursue.

I'm managing in one form or another for ~12 years, so... somewhat experienced at least, but take with a grain of salt.

Does it get better? Maybe. That really depends on what you like. If you find joy in, essentially, coaching & teaching, it's a great job. If you enjoy politics, you'll be OK. If you get your joy from creating, it's much harder.

You still create, as a manager. Teams. Processes. Cultures. All things that have incredibly long feedback cycles, nowhere close to writing some code, running it, iterating. I've currently got things in flight that (hopefully) will pay off three years from now. There is no instant success.

That said, all the things where I as a dev said "Why on earth are we doing this stupid thing"? I get to fix those. Or, alternatively, to learn why it's not quite so stupid as I thought.

Politics will happen, though. Wherever humans interact, there are politics. There are healthy levels, and dysfunctional levels. (Everybody lobbies for their project, but there are plenty of lines they shouldn't cross)

Excel sheets will happen, too. After text docs and e-mail, it's your most important tool. (And many of us who came from tech nourish their yearning for building things by scripting the hell out of them, because that's all we get to code)

But again, if you like interacting with people, at some point, a switch will flip. You'll have a day of back-to-back meetings about genuinely interesting efforts, and you'll walk out of it thinking "Damn, I can't believe they pay me for just spending a whole day chatting about cool stuff". You'll see the first of your reports stepping into a leadership role. You see a multi-year, multi-team effort come to fruition and can honestly say "would've failed without me bringing the teams together"

So yes, it can be enjoyable. It depends on what you want, though. There's nothing wrong with doing a management stint and going back to coding after a few years, either. A lot of front-line managers bounce back and forth between the two sides.

Hope that's at least remotely helpful.

EDIT: Forgot to say that your place sounds... not quite healthy. It might be a question of finding a company that actually values managing and doesn't have it degenerate into total soul suck. They do exist.

Looping back in from my other answer - looking at this, I think you probably know what you want to do, but are still trying to hedge a bet each way. I absolutely empathize - I have been in this exact headspace quite recently.

To answer some specifics, from my perspective

> I'd love it if a more experienced manager could chime in here and speak to whether or not that really can be enough to power one through the endless meetings, excel reports and politics given time.

Yes, of course. Some find meaning and purpose in that and enjoy it. However, I think you do not, not truly. And this is probably why you are keeping a leg in the tech side - especially based on your paragraphs around this one.

My suggestion is talk - out loud - to someone about this and resolve what you actually want to do with yourself. And then make a decision. Because being stuck between these two things will tear you up far more than making a potentially "non-optimal" decision (whatever that actually means).

As to me - I chose option 3, working for myself as a consultant. I realised that while I love the people aspect, I have some distaste for various aspect of traditionally corporate life. Now I can just swan in, talk game at high and low levels and leave when I need to. Works for me. Might not work for you. This is an intensely personal junction you are at and only you can know the correct answer.

> it seems similarly risky to just give in and go back to pure code, and give up on this managerial aspect.

Why do you say that? It certainly depends on company and industry, but there are many companies that have a parallel individual-contributor track where you can achieve a level (that is: seniority, benefits, compensation) analogous to management-track Senior Director or VP.

What were the most important management skills you cultivated to be so successful managing your team?

> That means an 8-10 hour day...

Wow, do you work in a sweatshop or some kind of slavery?

Very specifically, spending a lot of time rescheduling meetings suggests to me that your org may need to do a bit of soul searching about how they handle meetings.

My specific advice is:

1. Cull meetings that are there to inform a wide group of people about general goings on. Especially regular meetings of this type. Especially especially if they're more regular than monthly. There are very few topics that need to be presented to a room of 10 people in a weekly or biweekly basis.

2. Your business should have a heartbeat of some kind, and meetings should be scheduled on the basis of this heartbeat, not in a variety of recurrence schedules. So, if you do two week sprints, for example, meetings should be ideally biweekly (as in once every two weeks, not twice a week) or quadweekly, with some tolerance for weekly. If a meeting is currently scheduled monthly, it should be replaced with quadweekly. You can somewhat tolerate quarterly meetings interfering with this schedule, but nothing more common.

3. You should be designating time bands for different kinds of meetings. A zone of time when standups happen. A zone of time when 1:1s happen. A few times that are resolutely free of meetings that want individual contributors to visit them.

If you can implement these, I would not expect to have to spend a lot of time ad-hoc detangling schedules every few months.

If your org resists these kinds of changes, then, well, it can be frustrating being someone charged with implementing dumb policies, for real.

So far as I can tell, most orgs have meeting problems to one degree or another. If they're on the good end they're only spending ~2x the person-hours they would if meetings were scheduled and run about as well as conceivably possible. On the worse end... sky's the limit.

I think it's part of a broader problem with communication. Lots of heavy, poorly scoped tools and processes, way too many channels (in the sense of a communication channel generally, not Slack channels or something) tons and tons of look-busy chatter because people are insecure and can't figure out what to do with their time, piles of messages and emails and reports that no-one ever reads. Huge amounts of waste and down-time and frustration due to all the above. On and on and on. "Efficient" market. Maybe gross organizational inefficiency is really the best we can manage.

Also it seems like every org is perpetually in the middle of trying to figure out how do store and distribute documents of all sorts. I sometimes wonder whether for most orgs the benefits of tech have even been positive, outside maybe one or two things they're really, actually leveraging well, in the best cases. This sort of organization that's totally screwed up but doesn't know, or care, and is making money regardless, is well documented back to at least the middle of the 20th century—but more technology seems to have made the inefficiency more efficient, more often than it's eliminated it.

Believe it or not, _you_ and you alone can fix this. DELEGATE! Delegate enough to get back SOME of that coding time. Block off 2 hours a day as "Free Time" or "Creative Space" a la Michael Scott from _The Office_. People will respect that.

At my prior place of employment in which I grew the team from 0 to 25 in 3 years, I eventually delegated all the stuff I did not like and empowered my team to own it. It sounds like you can do something very similar with the culture you have there.

An example: At first I loved phone screens and getting to know candidates. I refined and built that process from scratch. Once that process was up and running, it was no longer the best use of my time to be hammering the phones and scheduling screens. There was a better use of my time and someone else that REALLY enjoyed that aspect of team building stepped up. I was able to move myself to the end of the recruiting funnel which freed up 70-80% of my time allocated to that function. The opportunity cost was simply too high for the company having me screening people.

You can certainly find a way to do that as well.

If you feel like chatting more on this, my email is in my profile. Good luck and don't burn out! Your work should be just as fulfilling as your team members work.

How can he delegate hiring?

Make it a team effort. Distribute resume reviews & interviews.

Somehow, I feel like this is starting to sound like managers shouldn't do any work. Managers aren't supposed to be coding as their primary responsibility. I mean if you can find someone willing to do managerial responsibilities, then go for it. Just make sure you're not the one taking advantage of them and reward them for it.

A leader's job should be to effectively delegate themselves out of a job. If you think delegating effectively isn't "work" then I don't know what to tell you.

Work themselves out of a job, not necessarily delegate. The former could mean solving a problem once and for all, or putting process in place, or eliminating a task. The latter means having someone else do it.

Delegating yourself out of a job means growing your report's skills so you can do higher level things, not so you can get back to doing your old job.

Leaders are not effective if all they do is throw work over the wall expecting other people to do it. That's the quickest way to isolate yourself and is why managers often don't know what's going on in times of problems. It's also the quickest way to get employees to hate you because they view you as useless.

And this is especially true when its a task managers should be responsible for, like hiring people.

If the point is to make them have no job, then why are they even needed in the first place?

Most times you are correct. In this scenario, however, it seems like he started as an individual contributor and transitioned to management. When that happens, in my experience, companies want to continue to leverage the system knowledge from the individual in some form of producing technical assets.

Absolutely this. You will want the feedback from the existing team anyway right? Why not have them form their opinion first, and only talk to the candidates that pass their screening?

Disagree with this, this is why the industry is filled with junior engineers doing ineffective algorithm whiteboard interviews. Hiring is too important to leave to engineers who don't want to do it. Generally they will do a bad job because it's just an annoying thing getting in the way of their work.

Hiring is broken because engineers think it's just another problem you can apply typical engineering solution. Same kind of thinking that causes the terrible customer service in Google products like random algorithm locking out accounts.

That's why you need a good manager to codify the process first, and make sure your team is following it correctly.

> Hiring is too important to leave to engineers who don't want to do it.

Who says they don't want to? I'm an engineer, and I love doing interviews. Plenty of engineers are interested in human aspects of the job too, and would be greatful for the experience.

> Hiring is too important to leave to engineers who don't want to do it.

I'm trying to come up with a ballpark estimate of portion of co-workers who seemed entirely unconcerned about who potential new co-workers might be, and while a precise figure is going to be beyond me, it's probably close to an order of magnitude smaller than people who care somewhere between a bit and quite a bit.

Filtering out the people who don't care much also doesn't seem like it'd be a difficult problem: ask for assistance rather than assigning it.

Passion doesn't equal competence. It doesn't matter if they're passionate about doing interviews, sometimes that even makes it worse because they think they are raising the "hiring bar" but instead doing a really bad job at interviewing. The disinterested engineer doing an interview is less harmful than this type of passionate engineer interviewing.

The current broken system started with Google. They had a hiring problem, too many candidates to interview. So what did they do? Apply principles used for scaling computer systems. Treat each employee engineer as a generic interviewer who can give a generic algorithm question. Scale across all engineering teams to handle the candidate load. That's the Google way, apply algorithmic scaling to everything. It works except when the fundamental problem is a human issue like hiring and customer service. It's bad system but they get so many candidates it doesn't matter. And the company is successful, success hides all failures.

So other engineers in much smaller companies get asked to interview their future teammates. Sounds great in theory. But passionate or not, they have no idea how to do it. So they just cargo cult the big tech companies. Completely clueless copying of a system that was created for a problem they don't have (massive number of candidates).

Only the manager and lead engineer should be involved. They need to take back control and leave the juniors out of it.

So is the problem interviewing or is the problem cargo culting?

You dont get magically good at hiring because you are the manager or lead engineer, just like anyone else you have to practice and build skills towards this.

Dumping it on any level of engineer (or person) without education and training on how to conduct interviews will not yield good results.

There's a difference between "we are scaling this wrong" and "nobody knows how to do this thing" and "only the top boss should do this thing."

Some sr eng are great at team leading through interpersonal skills on top of technical, some are so good technically they lead their teams anyway, and I dont want the second group interviewing almost anyone.

I did a fair chunk of interviews when I was just a dev. I loved it, and I took it very seriously in terms of vetting programming skill and practices. I also felt good offloading that burden from a good manager.

It was win-win for our team. YMMV

What were your success rates compared to other teams who depended more on the manager for hiring? How often did your company fire people for poor performance?

Sorry, didn't mean these to come off so pointed, just super curious is all, not trying a gotcha or anything.

If you just chuck a random dev at the interviews sure. If you handover gently and make sure they've internalized your interviewing process it's a different equation.

In enterprise, I've mostly seen hiring broken because there isn't a dev in the room, just fluffy non-technical management.

> the industry is filled with junior engineers doing ineffective algorithm whiteboard interviews

What industry? I've been a hiring manager for years and am not familiar with this happening.

> Hiring is too important to leave to engineers who don't want to do it. Generally they will do a bad job because it's just an annoying thing getting in the way of their work.

So ask them. If they don't want to do it, don't force them. Most DO want to do it, because they get to pick who they get to work with, and do a fantastic job contrary to what you're saying.

Random algorithms locking Google accounts is nothing at all like hiring and I am failing to see the parallel you're trying to illustrate.

> What industry? I've been a hiring manager for years and am not familiar with this happening.

Then you must not be very in touch with technology.

Like, this type of denial or lack of sight into one of the basic problems with the industry right now pretty shockign.

Delegating interviews isn't a unique thing. A team Lead or a senior dev can handle a good portion of it. It's also important that a candidate have a good fit personality-wise with the team he'll be working with, not just the manager.

Invite team members to the screenings, get them to ask questions and understand people. After a while, the member could do it all on their own, and maybe even train someone else. Try different people, look for talents inside team :)

At one point, you can give away resume reading too. And talking with HRs will get easier (more repetitive/automated) after a while; try to engineer a way for that.

All the hiring processes I've been involved in are primarily driven by individual contributors. The manager probably makes the ultimate hiring decision, but engineers are better suited to do the technical portions of the interview anyway.

There are definitely portions that can be delegated. I was doing interviews in the first month of my first job out of college. The trick is to do pairs: one person who's new to it, and one person who's had plenty of practice.

Make it a multi-round approach so someone else does first round interviews and all he has to do is pick from the final X candidates

Place some trust in your reports; they're going to be working with the candidates if they are hired, they might as well interview them, too. And they could probably use the practice.

In fact, the worst hires I've had to work with were hired by my manager without involving the team at all.

I think it’s also worth mentioning that if you’re going to involve the team make sure you’re prepared to actually objectively assess and act on their feedback. Not necessarily saying everyone should have veto powers but we can tell when you’re blindly excited for a candidate and are disregarding anything negative that contradicts that. Don’t waste your people’s time if you’re going to ignore what they say and do whatever you wanted to do anyway.

I completely agree with this. It's actually hard to delegate too much. Almost all managers I've ever known have delegated too little. I think they're afraid that by delegating important parts of their job they're diminishing their role in the company, but it's actually the opposite. Leadership is not necessarily a zero sum game: you can elevate yourself while also elevating those you work with.

You really want to delegate that soul crushing work to your engineers?

There's less to delegate if you're a team lead with IC direct reports. The situation starts becoming a lot more complex when your reports are themselves managers or team leads.

What is soul crushing to you is not soul crushing to someone else. You can certainly find people who are motivated to meet new engineers and talk and spend part of their day doing that than going to a meeting of choice.

If you are leading a team of engineers, chances are you have some form of recurring check in to see how the individual is doing. In those times, it is the leaders responsibility to understand what motivates that individual and what they enjoy doing. This way, your delegation is impactful in an empowering way and not a “well thanks for unloading the stuff you don’t like”.

I prefer people to opt in to the processes that need to be handed off as that is how you get true ownership, evolution, and trust.

If I ever assign myself dev tasks they never get done because something else will always come up that's higher priority. I only ever take small tasks when I'm having a quiet week. Usually I'm preempted by meetings. This is the way of things.

I self admittedly have trouble with delegation, and maybe you or someone else on here can help. The problem I have is a lot of my time is spent in meetings. I can certainly throw meeting invites to my reports, but I think to when I was a developer and how grateful I was when my manager shielded me from meetings so I could focus on work. It's not that I don't think there's useful information in those meetings for the individual contributors, its that I think there's also a lot of useless information that would largely be a waste of time.

In my experience, meetings follow responsibility. Make somebody responsible for the thing that causes the meeting and you'll get mental and physical time back. Plus you'll give that individual a chance to truly own something end to end.

There are meetings and other tasks that managers must take care of. I like to make a list of those things with a brutally critical eye towards what I _must_ do and figure out how to delegate everything else. Oftentimes this doesn't save time in the short term (you have to teach and then follow up with your delegates), but it works quite well over time.

I used to think I hated all meetings but what I actually hated was pointless meetings, especially ones that could be hammered out in less time asynchronously via email or chat. I learned about the distinction when I dealt with a manager with some unaddressed control issues. Of course that was just the tip of the iceberg but it was a standout symptom of a bigger issue.

It’s ok to try to unload bullshit but it’s also important to make your employees feel like you trust them. If you shield them too much and firewall everything they can end up feeling like they’re just workhorses that can be swapped out.

You can even delegate to people that don’t love doing it but will happily volunteer for their own sanity. For example, I hate interviews and phone screens but if someone asked for volunteers I’d jump on it because I hate being stuck with a bad hire much, much more.

You can also ask for volunteers for something you want to delegate and if none are forthcoming try out rotating it. Consistency might suffer but at least you’re not making one person shoulder something the entire team doesn’t want to do.

I run a free mentoring service for managers & leaders. No strings attached. Not a coaching service. Not trying to pitch you anything. Just me being a service to our community.

https://freemanagermentors.com

I've met with a lot of people from HN since I started the program. It's been a real joy!

As for your comments, a couple of things jump to mind you might want to explore.

[1] Are you receiving enough positive reinforcement from those around you? Are your colleagues aware that their support & positive affirmations make a difference to you? This is all part of "managing up", and a lot of colleagues don't realize it's ok to tell their manager how they appreciate them. It may sound self-serving to you to teach them this, but it's important you know how you benefit them, so you can continue to do that effectively!

[2] I think it's great you're carving out time to do some coding. I'd lean harder into this area if you're finding it's generating enjoyment. Perhaps finding someone to take on 50% of your manager workload would allow you to take a more active coding role in non-time-critical projects?

[3] Are you due for a sabbatical, or have the ability to take an un-paid sabbatical? You may just be hitting some general burnout and may need to hit a reset button.

[4] Perhaps you're due to try a tougher management role in an area that you have little to no expertise. I spent a year at my previous job deep diving into our business operations team, and it helped keep me going for an extra 12 months on a job I was "done" doing. You might be due for a fresh challenge that's beyond engineering.

Happy to chat if you'd like! Be well, and best of luck!

Are you due for a sabbatical

Not to detract from your advice, but what's with that question? Virtually no engineer has a job that offers sabbaticals. Even the companies that family used to don't anymore.

I don't doubt someone will chime in and say "my job offers me a sabbatical", but they're in the extreme minority.

You might as well ask, "does you job offer free massages? If so, I recommend you go for the shiatsu"

YMMV. A lot of the startups in my circle now offer sabbaticals. I get it’s not even remotely common in non tech related jobs, but in tech jobs in the US it’s absolutely on the rise. I wouldn’t call it rare anymore.

I get that’s a very heavy anecdotal answer but my day job has me interact with a lot of companies from a people / performance perspective, so I see a lot of these policies first hand. It’s also come up in five of the fifteen most recent mentoring conversations I’ve had (just went and double checked my notes).

Can’t really produce anything more concrete than that for you, unfortunately. No clue what the hard data is. Might just be some weird bias based on the type of work I do.

-- EDIT --

Switched to my laptop and found an HBR article saying it's about 17% of companies. So, doesn't seem that rare.

https://hbr.org/2017/08/research-shows-that-organizations-be...

Keep in mind that in America a "sabbatical" may mean something like 2-3 weeks off...I.e. what in Europe would just be a normal vacation (most every job I ever had in Austria or Germany included ~25 days [5 weeks] off per year - it is common for people to take 2-3 weeks of those in the summer in one go).

The original meaning (and the one that will probably throw europeans off) was 1 year every 7, which I would venture a guess is so rare outside of academia/education as to basically be irrelevant.

No, it doesn't.

You are no longer an individual contributor (nor will you be evaluated as such) but are now considered part of the leadership cadre. That's now your life and sure, you might be able to set aside a bit of time to code and try to keep up but, and this is a big one, you won't be able to.

It is a career change and not one everyone wants or is suited for. It's like an athlete becoming a coach or gm, it doesn't usually end up well. My personal experience is that I tried it for a couple of years and realized I wasn't cut out for management (various reasons). For me I find that team lead is were I'm happiest, bonus if the manager above you is someone who wants to be there and understands what a manager is / should do.

Good luck

edit: spelling

But won't you be required to demonstrate senior or better technical skill, the next time you go into the market to find a job? How do you keep both edges of the knife sharp?

That’s the question but there’s likely not enough hours in the day to do that if you want to have a life outside of work and trying to keep up.

Eventually you gotta pick one.

> "Moving from dev to manager is NOT A PROMOTION. It's a CAREER CHANGE."

It's in the same field, and you're making a lot more money, and you have higher level responsibilities, and are maybe even working on the same team as before, right? That sounds exactly like a promotion to me.

As someone in another comment says, "In most companies unfortunately the only way to move higher in pay is the management route." This is treated by all involved as not only a promotion, but the only possible promotion.

I guess this pithy saying is meant to emphasize that you're no longer a developer, but that doesn't change the basic fact of what it is.

Moving from help desk to programmer is a career change not a promotion. It's a higher paying career which is why the flow is mostly unidirectional. Programmer to manager is similar, except at good companies that need good senior devs and pay for them.

If I move from help desk to programming that usually requires retraining, switching teams, etc...

Programmer to manager is just a promotion.

Moving from being a programmer to being a manger should require retraining.

These things are orthogonal. What decides "career change" is that your job function changes (managing people vs. writing code) and that the skills required to be successful are significantly different. Dev to management easily fits the bill for this.

The fact that you are making more and have higher level responsibilities isn't really relevant here. That can be a component of a promotion, but it can also be a component of a career change.

As an aside, at many companies switching to a management position doesn't automatically mean more money or responsibility; hell, as a long-time, senior individual contributor at my company, I definitely make more than many/most managers & senior managers, and have more responsibility than some of them.

Dunno, sounds like you're doing something wrong. Part of being a manager is being able to be in a position where your value added is built upon your subordinates labor. I.e. you can delegate the actual work items to your subordinates which leaves you with the just work related to the delegation.

Do you really miss coding? Fighting with shit tools that are crashing, spending large amounts of time dealing with some messy crappy code that some people vomited. Shit that was never tested and it fails and you have to burn the candle to fix the crap other people made. Spending time solving useless problems like why libpoop.so fails to link against libpiss.so. Fighting with CMake files or some package manager etc. The problem with engineering and coding is that the "joy" of creating software is way too often overshadowed by this engineering busy work (that is only because things in general are so shit) that brings 0 value to the table.

I wish I had a career track out of this engineering work and into management...

Management is not for everyone - you could always go back to an IC role/track

In most companies unfortunately the only way to move higher in pay is the management route. I know there are exceptions but in general you quickly hit a pay ceiling as IC.

While this is true, so what? If you are miserable in a manager role, you're probably not going to advance that much in the manager track, because the higher up you go the more miserable you are likely to be.

I've found in general the pay differential between an upper level IC and a senior manager/director role is about 25%. So the question is whether you would (a) rather be in a job where you are miserable and stressed out but making 25% more, or (b) in a job you enjoy with much less stress but making 25% less.

I say the above all from personal experience. I am glad I spent my 3+ years in management, and while I think I learned to be fairly good at it, I was miserable and I am certainly MUCH happier now that I've stepped off that train.

In my company the potential to make more as manager is much greater than 25%. And you have the chance to move further up which is extremely rare for ICs.

> And you have the chance to move further up which is extremely rare for ICs.

Agreed, but my point above was that if you are not happy as a manager, you're probably going to be really unhappy as a senior manager, approaching severe depression/anxiety as a director, and ready to jump off a bridge as a VP. If you're just going on that track for the pay potential, your happiness level is going to be worse the higher you go up and the more divorced you are from tasks (like programming) that you enjoy.

I can take a lot of pain if the money is right so the decision is not that easy.

In my experience you make a fraction as an upper IC vs director. I think an upper level IC (12-25 years experience) makes about $250k-350k/year. Senior managers making about $600k. Directors are probably making at least $1mm/year

That greatly depends on company. I'm a fairly-senior IC (~15 years experience) and make more than your high end for your "upper level IC".

Yeah, this company is in Seattle so it doesn't hit the bay area highs. I know at Google these same people would probably be making almost double.

I don't think directors make anywhere near that much. A director is going to max out ~600K all in. Reference:

https://www.levels.fyi/?compare=Google,Facebook,Microsoft&tr...

To get to 1M you'll need to be a VP.

Hmm, I don't think they properly translated all of those titles. Director is supposed to be above GM/GPM/GEM at Microsoft. I guess what I meant by director is what levels.fyi labels as "VP"

I'm not sure what your issue with that quote is - because it's 100% accurate. IT sounds like you have enough reports that you now have a people job and not a tech job and that is where your conflict is coming from.

You need to either wholeheartedly commit to that aspect and give up the tech (in a professional sense, have whatever hobby makes you happy) and find value and meaning in that, or go back to being "on the tools".

This dichotomy isn't unique to tech - as alluded to above, the trades have the same conflict - and people do shift between being "on the tools" and not.

But make no mistake - you can't do both. At least not for a sustainable period, effectively, if you are managing a decent number of people. So choose, and commit - at least for the period of that choice.

I don't think there's an issue with the quote, he's relating to the quote. It's 100% accurate and that's what he's saying sucks.

Exactly

I think you hit the issue on the nose. I've spent the last few (~2?) years committed to the people management role, and have improved immensely.

While 2 years isn't a large amount of time, it is enough time to start noticing myself starting to become technically out of date. And I agree, it hasn't been possible to do both. That in turn means I feel like I need to make a decision one way or the other now, because if I don't, in another year or two, I may not have the option.

I wrote about the difficulty I am having in choosing to permanently commit here: https://news.ycombinator.com/item?id=19486404, if you have a few minutes

Charity Majors talks about the Manager-IC pendulum. You should rotate between the two every couple of years.

Not sure you're into podcasts, but I recommend Manager Tools Podcasts, which is like a 15-year gold mine of free training. https://www.manager-tools.com/all-podcasts

Outside of searching the keywords "interview" and "hiring" and looking for what seems relevant, I'd recommend specifically the 4 "Management Trinity" episodes and "Juggling Koan".

source: 5-year manager at a public SaaS company in the Midwest, recently discovered the podcast.

It's usually instructive to look at how OSS does these things - how good devs with no weird corporate constraints goes about it

Take the Linux kernel - Yes there is a lot of delegation - but there are strong gated "lieutenants" at every stage - so perhaps do not treat it as one large structure but lots of small teams - who will do their own hiring, share improvements to their CI process etc

Admittedly Torvalds struggled immensely with your issues too - but he also was able to see where opportunities for his code intervention was most useful

OSS offers a lot of interesting lessons for companies, especially on how to communicate and organize large numbers of devs, IME they are dead set on ignoring them.

I was recently on a "globalization" project, trying to get teams around the world all working on the same products/teams, everyone in management seemed to think the only way to get communication working is to have global conference calls 3 times a week, usually at stupid'o'clock. The idea of open discussion on a mailing list was something they just couldn't comprehend. Fast forward six months and the corporate overlord has changed to one that actually does have some pretty good async communication methods in place, they still feel the need to have a global conference once a week while so everyone can read their kanban board aloud.

I don't know exactly what Torvalds reaction would be if he was asked to join a weekly conference call at 4AM with all the lieutenants, but I'd buy tickets to see it.

>>> so everyone can read their kanban board aloud.

It's scary how the same problems with Agile simply organically appear in wildly different companies - parallel evolution in memes or something

Delegation in a FOSS environment is an interesting use case. What if there person refuse to do the work delegated to him? For the Linux kernel, there are not shortage of developers willing to close out the gap. For the smaller FOSS projects, it becomes much more problematic.

If you are getting fleeting moments of satisfaction managing people - that’s good. You have to give yourself a chance. Being a manager means getting things done through other people.You have to try to increase those moments as the manager where you feel your team is becoming more productive and happier. At the same time, you will also have to learn to give more constructive feedback to those who are not achieving. That’s not an easy job. But clearly, you have to give yourself more time to become more proficient at utilizing management skills. It can be extremely rewarding knowing that you have an impact on others’ lives. However, having said all this, there will come a point in time when you will have to be true to yourself. Managing people is not for everyone. You may decide that you absolutely truly love coding and go back to it. I want to make this very clear that this does not make you are a good or bad person. It simply is what it is. You have to decide ultimately in the short and intermediate term what truly makes you happy and where you can make the greatest contribution.

Sometimes getting a coach can help you learn the right skills or just be a good sounding board. Someone else offered a free coaching session which you should definitely try out, but if you want a long term solution, we offer unlimited coaching for new managers here: https://leadingup.co

I started my first real management role about 9 months ago. Actually, I was sort of dragged into it kicking and screaming, because the team needed a lead right after I joined. It's been challenging and a large adjustment for me. My natural inclination is to be an IC, and that's what I enjoy doing.

At first I really did not like it. Dealing with people is difficult and tricky, and there is a much greater responsibility.

I'm still of mixed opinion whether I'd want to do this for a long time. There are definitely perks. As an IC, I would get frustrated when I saw some organizational dysfunction. Now, I feel I have a voice and can do something about it. The trade off is spending more of my time talking with people rather than computers.

The other benefit I've found is my personal growth. I'm naturally quite introverted, and this has really pushed my boundaries. I've become much more comfortable leading discussions, trying to sell my ideas to upper management, and so forth. I've also had to deal with difficult people. Despite being incredibly tough at times, I've learned a lot.

I also care a lot about people on my team, and want to see them do well. I feel great when I'm able to make their lives better.

Still... I think I will probably go back to being an IC in a couple years. That is truly what makes me happy, and I don't think that is going to change.

So what is an IC?

Individual contributor.

Individual Contributor aka a non-manager

I worked for a company where a lot of ICs were also assigned reportes but they weren't doing full time management. They were just interacting with their coach/mentor, doing weekly meetings and stuff. I believe transition from developer to Lead to Manager is smooth than becoming manager and getting away from coding and doing mgmt just overnight.

I think the problem is not enough companies have a robust technical career ladder. There should be technical equivalents to each management position, that would have some overlap with management responsibilities (mentorship, translating business requirements into technical actions, representing technical needs to the business, etc). But without things like employee evaluations or hiring/firing (but still be involved in candidate selection / interviews).

Completely agree. The other big issue is that some companies do nominally have higher technical positions than "tech lead" but in practice the number of people in these positions is much lower than in "equivalent" management positions so it's still a much better career/financial move too get into management even though it's technically possible to have a similarly good advancement path staying technical. For example in the group under my director there are maybe 4-5 "Architects" but there are around 15-20 people in engineering management that are probably around the same "level". And even for the architects, afaik none of them are actually writing code. They seem more like technical advisors who are still in "management" but don't have direct reports.

It's kind of insane when I think about it, how at a huge tech company all of the people with a lot of experience who mostly did very well as engineers are making $400k-$2mm/year as managers while all the actual technical product (in terms of code) is being written by people with 0-15 years professional experience. Of course it's not that weird that managers make more than employees but it does seem weird that there are so few people with a lot of experience and successful careers actually working directly on the product.

"it's not that weird that managers make more than employees" -- this is something that I really never understood, where it is expected that everyone under a manager makes less than them. At least considering what each role brings to the company's bottom line. After all, it really wouldn't be weird if a manager who makes, say 150 K a year brought in a consultant at $200 bucks an hour. Or purchased a machine that amortizes out to a couple million a year. Whereas if they have permanent employees that are developing product that is the lifeblood of the company, then the manager has to make more than any of their direct reports even if all they are doing is human resource type tasks.

I think from a logical perspective, you're right, but not from a practical perspective. For better or for worse (especially at large companies) your title basically defines where you are on the totem pole, and if the average salary for your title is lower than someone else's average title, that de facto puts you lower in the hierarchy. That's why I think PMs need to make as much as the devs pretty much everywhere and why the managers need to make more than the managed pretty much everywhere - it's not because these jobs each produce exactly that much value, or even that the skills to do the job have that particular rate on the market, but that you need these relative salary relationships to create a stable working environment.

Also, if engineering management paid less than engineering, I think you would mostly end up with non-technical engineering managers which doesn't sound like a very pleasant experience.

Lots claim to, but then end up with a manager per 10 devs, a senior manager per 5 managers, a director for 5 senior managers.

vs 2 principal engineers for the entire org up to the director.

So you can either jump over to management and be a senior manager a few years later and a director a few years after that, or you can stick around at senior engineer for another 5-10 years and maybe move up to principal.

Was your pay hike motivating enough that you did not put enough thought (I am sure you did) for missing out on daily hands-on-experience? I am just curios about the +% delta.

No. My salary has increased significantly here, and is noticeably higher than the rest of the department, but not so high that there aren't still IC roles in my city that pay higher. Quite honestly, my salary has been lagging 1-2 years behind my position, for the last half decade. This is a result of advancing internally, as opposed to advancing through job hopping. I've been okay with this trade, because I've received a large amount of training and safety to fail from the people above me that I believe it to be worth the trade in terms of career advancement.

In all honesty though, if you are unhappy with your day to day, no amount of money makes up for it. Hence the expression golden handcuffs.

I would give it more time -- perhaps 6 months total -- and if you're still feeling the way you are now, go back to a development role. If dev to manager is a career change and not a promotion, going from manager to dev is also a career change, and also not a demotion.

In the meantime, work on delegating the stuff you hate about management to others, and keeping work you enjoy to yourself. You probably won't be able to find a perfect balance, but maybe you can find something you can be content with.

It's great that you've made positive impact at your company as a manager, impact that you suspect would not have happened had you not switched tracks, but... you have to look out for yourself, first and foremost. If you're not happy, and don't see a path to becoming happy in your current role, what's the point in staying there?

Also consider that, while you have made some positive impact, you are not unique. Someone else, who maybe actually enjoys what you dislike about management, could likely do as good a job.

Edit: I see from a later post of yours that you've actually been in management 2-3 years. If you haven't been able to make it enjoyable by now, it might be time to just recognize that it's not for you and find a role that you enjoy more.

What you can do as a manager is delegate. What you should do is distribute the task of interviewing candidates - especially technical interviews - to the rest of your team. They have to work with the candidate, after all. You can ask them to help with screening resumes as well. Ask your manager to take on a recruitment manager, so that you can refocus onto engineering instead of recruitment / hiring.

Sounds like you need a recruiting coordinator. They aren't all that expensive (compared to your time, or an engineer's time).

The first time I sat at a keyboard I loved coding. I was a manager for a couple years and got proficient but never got the joy I had coding.

I’ve gone back to coding (team lead 80% hands on, won’t lead a team bigger than 6). I’m happy again and getting paid >200k through contracting.

Don’t stop yourself going back if you don’t get a buzz out of your job. Nothing else really matters.

I'm in a very similar position. I find myself wondering if anyone really finds management fulfilling, or if that's just a lie we tell ourselves.

I look at my peers and don't see any of the passion and enthusiasm that I see in some developers.

In general you hear people say a lot "Well, I went into management because the pay potential is higher and at an IC level you can really cap out fairly early".

Well, the reason the pay is generally higher is because it is, generally, a much shittier job. If the pay was the same between developer and management tracks you'd see a heck of a lot fewer people wanting to get into management.

I have never heard anyone say they went into management for the money and then stick with it for long.

At least for the companies whose pay scales I’m familiar with, that would be a terrible trade off. You maybe get a tiny bit more money than a high performer, but you have a world of responsibility coupled with less control of your work product.

You need to love coordination and mentoring to be a good manager (among many other things).

I coach new engineering managers and have been both an engineer and a manager in the past. Management is fulfilling in an entirely different way than engineering is fulfilling. It's not only a career change, it's a change in mindset. If you are working as a manager but still living in the engineer's mindset, I can completely understand how it would feel very unfulfilling.

It's not easy to make such a mindset change as an adult but I know it's possible because I've done it and I've seen others do it. It's a very personal change, kind of like breaking out of a psychic prison. It's not something you can think your way through, it's not an engineering problem to solve, it requires a deeper change in your beliefs and in how you use your mind from moment to moment.

Engineering requires extreme internally-focused attention and an intensely analytical mindset and a "deep thinking" approach in order to keep all of the inner models and abstractions clear and well-organized. Management (and especially leadership) requires a practice of broader externally-focused awareness and a more intuitive mindset. A manager needs to hold several perspectives more loosely and have a "wide thinking" approach in order to be a great leader.

All of the "soft skills" are either easy to adopt, or hard to adopt, depending on where your mindset is. If you are the engineer's mindset, you might find it very challenging influencing others or making yourself emotionally available as a leader. You know how people get "developer head" after a long day of coding and have a hard time communicating with people? Developer head inhibits the leadership soft skills. But in the manager's mindset, presence is completely natural, and from a place of presence things like empathy or approachability are natural too.

For me it required 3-4 years of uncomfortable growth, and quite a bit of what I would call spiritual work, before I felt I had really found the manager's mindset.

I hope this is helpful somehow; I'm happy to chat further about it anytime. :D

I appreciate the offer. I've been managing for four years now. I've experienced a fairly substantial shift in mindset, not perfect, but most of the way to being there. All signs (delivering on outcomes, ad hoc feedback, 360-reviews, career-progression) indicate I'm good at this.

It is satisfying in many ways. It's also much more impactful; as a manager I can do much more to help people and companies succeed than I could as a software engineer. But it is nowhere near as satisfying as being an engineer was.

Go to a conference for software engineers, everyone is pumped up, and excited about what is happening. At a similar conference for engineering mangers you would not find that same level of happiness. I certainly don't go home and read management books or blogs.

Being a manager can be grueling, but good management matters a lot.

I, and many of my peers, really enjoy being managers. It helps that I don’t aspire to more pay/power/people; I like what I’m doing and I like my team, and that by itself is very satisfying.

I do miss being close enough to the code to reliably fix lots of bugs, but I still code during times in the release cycle when less coordination and planning is needed, and that’s enough for me.

I recently went through a change where I manage people but still try to code and I don't enjoy it at all. I also prefer to code rather than manage the politics and emotions of the developers I manage. I hope I can move back to coding full time at some point but we're a startup and I'm the CTO so I'm nervous that won't be the case. If you're able to make the change back I would just tell them you don't enjoy your current role and go back to being a developer. You don't have to be unhappy just to make your team happy. There are others that will manage them just as well and will enjoy it.

I'm just starting to transition my career into a more managerial role, and I agree with everything you are saying above. I would like to know though how you are doing:

"I look at my team, and the entire office is happier than I've seen it in 5 years. I'm watching people train, and actively grow under my management. It is incredibly rewarding, and much, much better than before I moved to my current position."

I am having a problem having my team be happy and also growing/learning. Do you have any tips to share in this regard?

Honestly it sounds like you're really good at what you do. Why not go for a tech lead role rather than management? Best of both worlds. Little bit of column A, little bit of column 2.

Sorry to hear about your situation and I believe you. Have seen similar dynamics before.

It's not always true that you alone can fix this (at least while working there). Anyway, from the sound of it you have done a great job for your team which is what counts most in my opinion. If its really that bad that you don't feel like getting out of bed because of this, I might consider moving at some point in time. Hope things will get better for you soon.

I decided after 3 months that being a development manager was not for me. It was too much of a career change for me personally.

Luckily the team was still lacking actual developers so it worked out with the same organization.

Either way though, I started to do a lot of development on my own, like you are now. This is maybe a good indicator.

Not an uncommon story sadly. But take a moment to think deeply about this:

And remember back to things you did while coding that had similar levels of distaste/discomfort. In my experience, good engineers develop tools around doing the 'scut work' of engineering (checking regressions, processing code review comments, validating doxygen/documentation, Etc.) Whether it is setting aside a time, or coding some tools to automate the parts that are automatable (is that even a word?), and then as they switch from 'senior engineer' to 'manager' they have either forgotten or greatly damped down the memories of themselves making the painful things less painful.

Take resume scanning for example. When I started managing each new resume was like a brand new unrelated to anything before it, document. Each to be parsed, cataloged, evaluated, and then dispatched. Time consuming and sometimes mind numbing. To combat that I started writing down things that were common factors, things that turned out to be red flags at the interview, things that the recruiter could have screened prior to me seeing the resume, and in working with recruiters on their 'rejected' pile things that screened that shouldn't have. After hiring and managing enough people I started getting a better feel for the folks who I could work with and those who would be challenging. I also started looking at teams as a pool of skill sets rather than an individual set of skills. So if the team already had a skill covered it wasn't critical that the latest hire had it, but it was critical that they could cross train it.

As a result, scanning resumes stopped being a soul sucking waste of time, and I started "coding" my own process for processing them efficiently. Thinking of recruiters as a variant on lexical analyzers that needed to be tuned to return the right candidates, and ways to look at the candidate to identify skill sets that people don't often write down directly. Have they always worked in small groups? or large? Is their exposition full of more inclusive language or exclusive language. When I can, I like to 'blind' a resume, as names can trigger internal biases. The evaluation process becomes more like reading code and "running it" in my head. I got pretty good at reading code and being able to guess if it was going to work correctly, with time I've gotten better at reading resumes and guessing if they will fit into the current organization.

As you apply more of your analytic skills that you used every day programming to your management challenges (obviously with fuzzier variables and more opaque motivations of third parties) it starts to feel more like engineering and less burdensome.

Great post, great example - I'm going to try and apply this analytical/process optimization mindset to more of these "softer" management tasks. Thank you

> Your website says that the transition to management is difficult and nuanced, but things like the above are what I need help with.

I've found manager-tools.com to be a useful resource for new and aspiring managers; but it's no replacement for a therapist or a demotion.

Don't do what you hate, life is too short. If it is soul-sucking and stressful, and making you not want to get out of bed in the morning, then you should find something to do every day that doesn't make you feel this way.

So, I would think of it a little differently. Sometimes your reward function in your life will shift: You go from being excited to get good grades to excited to get a raise, or you go from being excited to see the red/green test cycle go green to being excited to hire the right developer for your team.

All things go, I just pray that I can always either adapt or guide my life in a direction that makes me happy. I'm basically a full time manager now, but I do find it incredibly fulfilling.

Stick it out until you become a manager of managers. Then the job gets fun again.

Care to elaborate?

Several things get better:

As a skip-level manager, you have a better relationship with IC's. Any interest you take in them personally or professionally is magnified simply because you're the boss of the boss.

Most of anything that is soul sucking CAN be delegated to your managers.

You don't have to solve problems, you just need to make sure your managers know they have everything they need to solve problems.

You have a lot more responsibility for the over all direction of a large swath of features.

The flipside is that it's pretty much all politics at that level.

Is that why we see Dept. Managers of the fortune 500s always with smiles on their faces? :-)

Seriously, it would be the next phase of a career change. The type of responsibilities are totally different and the problems you are dealing with are also very different.

> the problems you are dealing with are also very different.

If you thought dealing with interpersonal conflicts between IC's was fun, JUST wait till you deal with them with your managers.

I've always said that same quote, as it is true and I have seen it over and over again, and if you aren't happy with your new career I would probably switch back to being an IC.

You're in a toxic work environment, and you need to get the fuck out of there.

In itself it has nothing to do with management, except you're now exposed to it, shielding your people from it.

Take it from someone who's been there: it's not worth sacrificing you're health over it.

You're devs will be fine, one way or the other. Invest your energy in a company that's worth it, and that will actually change due to your efforts.

Live is too short to be doing things that keep you down, in bed. Literally too short. Quit today.

Life is too short to opt into homelessness too. Quit when you have a plan.

> "Moving from dev to manager is NOT A PROMOTION. It's a CAREER CHANGE."

This is such a load of crap. Hey I get paid more, have a more obvious path to higher levels, I'm now actually above the people I used to work with, but it's not a promotion.

You are not “engineering harder” or being an engineer++, you are doing _different work_ with a _new set of skills_. This is what is meant by the phrase. It is unlike the transition from eng to sr eng or even sr eng to team lead — not in degree, but in _kind_.

That's nice, it's still a promotion.

Reply on news.ycombinator.com