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.
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.
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'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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
> 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.
> 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.
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?
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.
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?
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.
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.
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.
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.
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.
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.
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 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.
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!
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.
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.
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.
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?
> "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.
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...
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 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
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"
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'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 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.
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.
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.
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.
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.
Not an uncommon story sadly. But take a moment to think deeply about this:
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.
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
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.
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.
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.
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.
> "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_.
It includes, among other things, a link to the Khan Academy Engineering Management Reading List.
See especially the first book on the list about a need for "slack" (free time, not the software) called "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency" by Tom DeMarco". The summary: "There is a tradeoff between efficiency (meeting previous well-defined needs with minimal effort) versus effectiveness (meeting newly emerging needs with flexibility and responsiveness through organizational learning). If you optimize only for efficiency in meeting previous needs from past opportunities, you will by necessity eliminate your organizations's capacity to respond effectively to future needs from newly emerging opportunities. This ability to learn and grow as an organization requires "slack" time. Middle management has a vital role to play in organizational adaptability -- but only if they are not over-scheduled."
Tom DeMarco also previously co-wrote "Peopleware: Productive Projects and Team", another excellent book on software management.
Another informative and funny book in that area is by Michael Lopp: "Managing Humans: Biting and Humorous Tales of a Software Engineering Manager"
Bottom line: you have essentially switched to a new field even if computers are still involved so you need time for self-education and practice and failures and recoveries. As in, ultimately, years to get really good at this new profession the same way it took years and thousands of mistakes to get good at software development as a programmer... (Although mistakes with people are often more personally painful than mistakes that just the compiler yells at you about.)
Something else to be aware of (may not apply to you) is that many of the best software developers have some degree of Asperger's -- but people with Asperger's often have issues dealing with human relationships unless they consciously learn various skills for dealing with people that many other non-Aspies just seem to have intuitively. And even when they get good at those skills (sometimes better than non-Aspies because they make understanding all that a focus or obsession), an Aspie using the logical primary CPU part of your brain all day to do what many other people do essentially with an emotion co-processor can leave one feeling drained at the end of the day. So "promotion" from software developer to manager may often be a step backwards in career satisfaction for top developers. Anyway, that is just another complexity on top of all the other issues a new manager of any sort has to deal with. But as you point out, being a manager has its own satisfaction in helping others grow, so if you can get enough positive feedback from seeing your own leverage increase that way, the benefits of transitioning to becoming a manager may eventually outweigh the costs (especially once the people and organizational skills needed to excel become more routinized).
I appreciate the thought RE the "Asperger", but in the interest of aligning with reality: Asperger no longer exists as a diagnosis (it's all on an autism spectrum now) and saying that many of "the best" software developers "have some degree of" a psychiatric diagnosis is... Well I'm not sure exactly what to call it. Premature springs to mind.
Something by Jeff Atwood on this:
https://blog.codinghorror.com/software-developers-and-asperg...
"Software Developers and Asperger's Syndrome: When I read Wesner Moise's post on Asperger's Syndrome, I wasn't surprised. Many of the best software developers I've known share some of the traits associated with Asperger's Syndrome: ..."
Jeff also links to this 2001 Wired article on the topic:
https://www.wired.com/2001/12/aspergers/
"Autism -- and its milder cousin Asperger's syndrome -- is surging among the children of Silicon Valley. Are math-and-tech genes to blame?"
See also: "The Real Problems With Psychiatry: A psychotherapist contends that the DSM, psychiatry's "bible" that defines all mental illness, is not scientific but a product of unscrupulous politics and bureaucracy." https://www.theatlantic.com/health/archive/2013/05/the-real-...
And from there: "One of the overlooked ways is that diagnoses can change people's lives for the better. Asperger's Syndrome is probably the most successful psychiatric disorder ever in this respect. It created a community. It gave people whose primary symptom was isolation a way to belong and provided resources to those who were diagnosed. It can also have bad effects. A depression diagnosis gives people an identity formed around having a disease that we know doesn't exist, and how that can divert resources from where they might be needed. Imagine how much less depression there would be if people weren't worried about tuition, health care, and retirement. Those are all things that aren't provided by Prozac."
Also, in general, there has been pushback about removing Asperger's from the DSM. As above, it was a "successful" diagnosis in that it helped a lot of people feel less alone and find better ways to cope with a situation once they had a name for it -- see especially the multiple books now on Asperger's and relationships which can be extremely helpful for people with it and their partners (e.g. "Love, Sex and Long-Term Relationships: What People with Asperger Syndrome Really Really Want" by Sarah Hendrickx).
But, moreso, it is not clear that Asperger's is completely the same as "high-functioning autism" in some ways. This is controversial, but just one example: https://www.spectrumnews.org/news/brain-curvature-distinguis...
"A region of the brain that controls language is more extensively curved in children with autism than in those with Asperger syndrome, according to a study in the Journal of Child Neurology. The findings offer preliminary biological evidence that Asperger syndrome, a disorder on the autism spectrum, is distinct from high-functioning autism, researchers say."
I wrote "many of the best software developers have some degree of Asperger's...". Someone can have a little of something to some benefits in some area like programming (below the level where a formal diagnosis of Asperger's might be made other than noting tendencies) -- whereas a lot of something might cause profound difficulties in life overall and fit all the diagnostic criterion for a formal diagnosis. There may also be some sweet spot for success given programming in practice especially in a corporate setting does involve dealing with other people to some extent. Labels tend to be binary -- whereas personality trends are more shades of grey (or shades of colors). In various books on Asperger's (e.g. Asperger's on the Job) there are examples of people with Asperger's who excelled in their jobs because of Asperger's and then got promoted to management where they crashed and burned again because of Asperger's (well, usually undiagnosed Asperger's where people were unaware of the particular challenges they would face and did not know how to handle the transition including just asking to go back to their previous role).
I had qualified my comment as "many of the best...". For contrast, here is a Quora article arguing most programmers in general do not have Asperger's though. Part of the reason is explained here:
https://www.quora.com/Is-it-true-that-most-programmers-have-...
"While in a way aspergers's gives a good aptitude for something methodical and logic based like programming. The deadlines/stress of company life and ‘real world’ work does not provide a good environment for somebody with Asperger's Syndrome."
So, in the right environment and role, a programmer with Asperger's might excel beyond those without it. In other situations (including for some, a promotion to management), a programmer with Asperger's may fail hard and someone with less technical ability or less ability to focus intensely on one task but a better intuitive people-sense and better multi-tasking ability may do much better.
Asperger's and IT: Dark secret or open secret? Asperger's Syndrome has been a part of IT for as long as there's been IT. So why aren't we doing better by the Aspies among us?
... He loved the tech parts of being a system administrator, and he was good at them. But the interpersonal interactions that went along with the position -- the hearty backslaps from random users, the impromptu meetings -- were literally unbearable for Ryno. "I can make your systems efficient and lower your downtime," he says. "I cannot make your users happy."
... While careful to protect his clients' confidentiality, Becker confirms that he sees many adults and children of adults who work for the region's tech powerhouses -- Microsoft Corp. and The Boeing Co. -- and the hundreds of smaller companies that orbit around them.
Some of the Aspies he counsels are at the very top of their tech game: software and aerospace engineers, computer scientists, Ph.Ds. But for every research fellow with Asperger's, he says, there are a legion of fellow Aspies having a much tougher time in the middle or low ranks of the industry.
"The spectrum of success is much broader than one would expect," agrees Roger Meyer, the Portland, Ore.-based author of The Asperger Syndrome Employment Workbook who runs one of the oldest peer-led adult Asperger's groups in the country. "Adults who have grown sophisticated at masking and adaptive behaviors can either bubble along at the bottom of the market or do very well at the top."
It's that "bubbling along at the bottom" that has Becker, Meyer and other Aspie specialists concerned. Employees with Asperger's might do well for years in data entry or working in a job like insurance claims, where knowledge of ephemera is a prized work skill, only to flounder when they're promoted to a position that requires a higher degree of social interaction."
That looks very useful. I'll be adding a resources section in the next few days. I'll make sure I link to this Github repository, if that's OK with you!
Early in my career I worked at a large company where the average dev age was late 30s. Quite a few of these people had taken a stab at management and returned to development.
Basically I was told this much - don't do it unless you're done with coding and desire to rise up the company ranks.
9 years ago I did such a bang-up job as the lead on a medium size product that I was offered a promotion to management. The first thing I asked was "can I still code?". No. I got my CS degree because I like doing that. Turned it down and accepted a promotion to a principal dev instead. Still, I was rather miserable in that environment. A year later I rebooted my career from .NET enterprise dev -> Rails consultant for early stage start-ups, best thing I ever did in my 20 years as a dev.
You're hired by your company to perform a job for a certain comp package. You're not there for charity. If you're not happy change things up. Your reports will carry on without you, and if things are that bad in your absence, will also carry on to hopefully higher planes.
I'm a solid coder and have lots of experience in the non technical aspects of our business from consulting and running a startup, but I'm moving into management because it's the best way for me to apply a multiplier to my skills.
Plus I've complained about poor managers long enough that its time for me to step up
Kind of, yes. I guess it depends on the workplace. Some companies still allow managers to code for a certain percentage of their time, while some don't.
But you're right - transitioning to management usually involves letting go of code.
Yeah, I should definitely qualify that statement to larger orgs. Every company I've been in with < 100 people tech management usually coded, and typically in places < 20 people the CTO would be the most prolific coder.
I have a good friend that went from Google Software Reliability Engineer (SRE) to manager of an SRE team, but for him it's less of a problem because he's always focused on helping others (and to hear him, he gets a good amount of time to help steer juniors towards solutions and around problems).
I believe he does make sure to set aside a good amount of time every week to code on whatever side project is his current fancy (usually Perl 6 related). I don't think he would handle it nearly as well if he didn't have that to fall back on. So it sounds like maybe you've stumbled on something that might help (designated time for side projects). The question is whether the rest of the job is (or will become) gratifying enough to hit a good equilibrium.
I assume you're being paid a salary at the position you're at. An important facet of salaried positions I've drawn upon is that unless outlined clearly otherwise in a contract, I'm judged on what I deliver. If that means to keep my sanity I take an hour out of the work day to read HN, or code a side project, or any other thing, so be it. That's a requirement for me keeping my sanity at the job I'm at, and if I'm not delivering, then I'll be judged on that by my superiors. My suggestion is to do whatever it takes to make the job palatable to you. If that means putting less than 100% in, then put less than 100% in. I assume they would rather have you at 80% indefinitely than 100% for another 3-6 months before you burn out. It sure sounds like your co-workers would.
This is exactly where I am at. You summarized it perfectly. I'm happy to hear there are other people who are in my position, that devote time to code as well.
I'm trying to find a way to make that remaining 80% more gratifying. And I'm nervous about committing to it permanently until it is. Similarly, I am hesitant to give up on the opportunity, or go back to IC / team lead status (with the career limitations that implies (how real a threat is ageism?)) if it might still be possible to make management more gratifying, given what an opportunity it represents.
Can't recommend enough "The One Minute Manager" by Kenneth H. Blanchard.
Clean read. Easy to understand principles. From what I remember and learnt: Limit meetings, define responsibilities, trust your people, focus on what has been done, going to be done, and the obstacles. And, you are here to help not to micromanage.
Single best resource I have used for management. It taught me how to manage, even after getting my MBA and serving as president of a Toastmasters club.
I attended the Manager Tools conference and did a conference debrief of it:
So many times i have seen coders "promoted" to managing roles. It actually seems to be normal practice to do this because: the coder is intelligent, the coder knows whats going on technically, plus the idea that general experience is somehow related to management skill.
However the truth is if your not regularly training as a manager and consciously applying well known good management techniques then your probably not doing so well... as a manager.
As a coder you train a lot! then as a manager you should also train => proactively get training please!!
However management is a soft-skill, and coding is a hard -skill. Mistakes in management are not seen clearly to actually matter too much. Mistakes in coding clearly matter. When bad management techniques are applied (such as frequently requesting changes, imposing bad deadlines, not actually planning ....) then the outcome: bad or wrong code, missing deadlines will be seen as an issue with the coder and not the management. How many coders are being turned over before....
an anecdote:
When the emperor napoleon marched back to Paris after his 5 month sprint through the Russian winter, he was able to return as Emperor and remain as Emperor without too much trouble when considering the scale of the disaster, he was then able to then raise another Army and start a new series of campaigns.
For me, the most challenging part was doing performance evaluations among different engineers where some was doing really amazing stuff but they weren't good at selling while others weren't doing anything impressive but selling it very smartly. Being manager, doing code reviews, going through ticket managers and other tools you can see this who is what and how much but you can barely influence 360 reviews.
On another occasion, it really got out of hands, when I was working on totally independent team and my people working on so many different teams. Being the guys, you gotta know ins/outs of all these projects going on while not loosing track of yours
The Problem with this Kind of interview is that a lot of These Manager types won't do interviews About their Jobs. So you will only get interviews with ~20% of them who are probably neither at the top nor at the Bottom of the Manager sphere.
It’s a common way to retain people who have knowledge and enough people skills that are useful when the dev’s code may not be as good as it once was or thought to be. Personally often the differences come down to who’s is more passionate about coding and people’s interest wanes over time as the facination wares off. So less experienced devs don’t always produce better code but are just more ambitious about fixing it.
Also I don’t know why you got down voted, when much more flippant posts make it to the front page.
Why do we need managers? Seems to me like anachronism from authoritative past. I can't recall a single manager that wasn't getting in the way of doing things in my past working experience (top engineering companies everybody wanted to get into); more often they were just enforcers of shady things that companies kept in the dark. Ramping up education, practicing virtues, supporting transparent exchange of information, and people can self-organize without any managers. Having managers just keeps everybody weak, uninformed, ignorant and lazy. Anyone remotely competent doesn't want to be managed.
Who makes the decision to hire and fire? Or decides what to prioritize after speaking with upper leadership and assigns resources? Managers deal with a ton of day to day stuff that most engineers should not have to worry about. I am a software team lead (not manager level in my company, our structure is strange, I report to a VP) but I have to manage several employees while also dealing with the customer to properly capture requirements and code.
I spend a couple hours a day in meetings and can then based on that tell, the developers what to focus on. Having the entire team in each of those meetings is a waste.
Managers for the most part act as meeting shields to the development team to optimally allow them to focus on writing good code with good motivated team mates.
But yes, some of them can micro manage and make things far worse than they should be. Few things are worse than working for a bad manager, especially glory hounds.
The number one thing I do as a manager that actually got to me enjoy the job was being responsible for setting expectations. In particular, getting a big say in contract writing. I negotiate the scope and staffing plan. I set the SLAs. I tell stakeholders what iterative delivery looks like, what we need from them to have a successful delivery and what my team can do for them.
The first project I scoped delivered almost to the day on schedule and on budget without burning the team. My next project we had a locked scope where I took one look and predicted disaster and it happened. Now I have enough credibility to make these decisions and set a team up for success.
A good manager makes a bad team good, and a good team outstanding. A good manager is an enabler. A good manager makes individual programmers better, makes the team work better together, makes the work itself better. A good manager can have an incredibly positive effect on a group. Seen it myself.
Sure, sometimes a group has relatively simple tasks and doesn't have enough incompetents, prima donnas, social disaster zones or or straight up sociopaths to need a good manager, but given that a good manager can massively improve the output of a team, make everyone happier and make a company more profitable, it seems silly not to have a good manager.
In the interests of no passive-aggressive nonsense, I simply don't believe that you've never encountered a situation where a good manager can make things better, or never encountered a situation where somebody was managing things and in doing so making a positive difference. The odds against it seem astronomical; especially in a 750 personnel sized company.
I've heard a lot about good managers, but never experienced one. It was always some form of manipulation, cutting the corners, forcing agenda even on solutions that were both wildly profitable as well as technically excellent "to make their mark", finding scapegoats to blame, in order to propel manager's ego and standing within company; the game was purely about power, hacking perception of their seniors about their qualities in order to progress. People that didn't play tended to find themselves packaged for layoffs, regardless of how much company benefited from them in the past.
So from my experience: Good manager is like UFO - I've heard of it, but never seen one. Unless you consider top management that just makes itself invisible and leaves kids on the playground doing whatever they are inspired to. That would be probably closest to what I could take as good management.
They exist. I've had a few. Protecting devs from meetings, being flexible, not getting their own ego into things, generally trust their developers to figure out how to code things (or at least the architects), try to keep you from working long hours (or if there are long hours, they're probably working them with you), pretty transparent about the crap that's going on above their heads (although that can be because that's all they can offer and aren't allowed to give you what you really want by the higher ups).
Invariably though, these guys were in the trenches at one point. Good developers or designers that eventually rose up into management. They understand how it's better if everyone works together instead of get too deep in politics (they aren't perfect about that, though, I've seen them have favorites) and try to enable their team as much as possible.
The types of things you're talking about like manipulation et al., I've only seen from career managers, who never really had a proper job making things. And those definitely exist, and are more plentiful than the good managers, but the good ones aren't mythical creatures. You're just getting unlucky in finding them, I guess.
This is my main problem with engineers that become managers. Programming does tend to create ego problems. You want that as your manager? Not really a good move. My best manager had no idea how to code, but he knew how to communicate, lend an ear and really listen, and make sure everyone was happy. But somehow he did it with a firm hand. Every one knew the line to not cross was mostly about lying. You have to be truthful that's what he can see through.
Apropos of this, some of my junior engineers now repeat back to me "code without ego" every time they have a code review or make a mistake. They take pride in not allowing their ego to get in the way. All it took was me demonstrating egoless working and loudly advocating that we all leave our ego at home.
I soothe my ego on the anonymous internet. In the workplace, it goes in the fucking box and every other thing I say is a variation on "I don't understand". Working life is so much easier without ego games. So much more pleasant.
I hypothesise that programmers with excessive ego have been sadly let down by managers and team leads in their formative years :(
> I can't recall a single manager that wasn't getting in the way of doing things in my past working experience (top engineering companies everybody wanted to get into)
To counter your anecdote with one, I work at a reasonably famous tech company in SF, and my manager has definitely elevated my productivity as well the amount of things I had visibility into.
I'm switching teams in a week and one of my big regrets is leaving my manager.
I have a good manager right now. If that person hasn't had a good manager ever, then it might be one of those cases "if it smells like shit everywhere you go, check your own shoe".
> Are managers really necessary? Google wanted to know for sure, so in 2002, it experimented by removing bosses from its hierarchy. The answer was a resounding yes. Managers were critical not only for structure and clarity, but also for team performance.
What I love about this is that google had the research experience and the size that they were able to just conduct a massive study on themselves.
I worked for a company with around 750 people, considered better than any FANG, that had no managers. Moreover, everybody thought they wanted to do cool stuff and not do a manager (synonymous with uselessness). Internally ran like a bunch of startups. Extremely profitable. Multiple FANGs wanted to acquire it/destroy it.
Haven't worked in a better environment. Getting calls from recruiters from FB/Google about "exciting leadership opportunities" sounds like moving backwards and is as appealing as accepting a crappy job to survive. Half of the people who left to FB/Goog were back within a year. You have no idea how much better companies can be.
Recently during my university admission interview (3rd master degree) I mentioned to an interviewer that I turned down FB twice in the past 6 months and seeing their brain spinning, unable to understand why, was pretty funny... Not sure why people desire to work in such soulless environments with opaque army-like hierarchy.
What company is unilaterally considered better than FANG? I honestly can't think of one. I hope you're not referring to some banking or crypto startup because, well...
No, definitely not one of those "get rich via pyramid scheme" companies. Reliable engineering-driven company with nerds at the helm. You might use their products daily. Do your research ;-)
Within one of those "internal startups" how did engineers make decisions when there were different opinions on the team? Especially when polarizing decisions had to be made?
Was there an implicit power structure if not an explicit one?
Generally, it's difficult to get into, so a strong pre-selection is applied. Second, initiative on what to do, developing own bleeding-edge tech (literally creating frameworks/languages/devices/whatever and making them popular) is strongly encouraged. People joining a team will get a few % of ownership of the resulting business after a long enough cliff (3-6 years) so it's in their best interest to work together; polarizing decisions could take a while to resolve, usually by majority, but losing sides could prototype their ideas to a smaller extent time-wise; conditions that FANGs simply can't match as they don't have such internal flexibility post IPO. The only "safe" approach was to use already winning technology as a base for future products if one didn't want to do whole research themselves (e.g. use whatever best performing ML approach from Kaggle instead of figuring out your own). Wearing multiple hats is encouraged; people collaborate on unrelated activities like making music/videos/performance art together if they like and they are encouraged to showcase themselves. Nobody cares what people do in their own free time, remote work from anywhere in the world is encouraged and financially supported.
Not sure about now, though I remember they hit $1B with around 500 people. How is the PPE/RPE comparing to FANGs I have no idea; I might do some study during my 3rd master degree on that topic ;-)
No, I am sorry, I won't (for doxxing reasons). They don't advertise themselves as aggressively as FANGs, yet can pick up some of the best developers easily due to word of mouth. I am sure the people that tried to acquire them and got denied as well as their employees can identify them easily. You might try to sort all companies on Glassdoor by overall rating and maybe you can spot something interesting there...
A good manager will 'stop the shit from rolling downhill' onto others and will give their people the tools they need to succeed and get out of the way.
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.