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?<p>One of the quotes on the page was:<p>"Moving from dev to manager is NOT A PROMOTION. It's a CAREER CHANGE."<p>This is what I'm having a problem with.<p>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.<p>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.<p>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?<p>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.<p>Your website says that the transition to management is difficult and nuanced, but things like the above are what I need help with.
Here is a collection of related advice I put together useful for managers of software developers:
<a href="https://github.com/pdfernhout/High-Performance-Organizations-Reading-List" rel="nofollow">https://github.com/pdfernhout/High-Performance-Organizations...</a><p>It includes, among other things, a link to the Khan Academy Engineering Management Reading List.<p>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."<p>Tom DeMarco also previously co-wrote "Peopleware: Productive Projects and Team", another excellent book on software management.<p>Another informative and funny book in that area is by Michael Lopp: "Managing Humans: Biting and Humorous Tales of a Software Engineering Manager"<p>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.)<p>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).
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.<p>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.<p>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 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).<p>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 <i>enough</i> to hit a good equilibrium.<p>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 <i>deliver</i>. 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.
Can't recommend enough "The One Minute Manager" by Kenneth H. Blanchard.<p>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.
I just became a manager of my team and was introduced to the <a href="https://www.manager-tools.com/podcasts" rel="nofollow">https://www.manager-tools.com/podcasts</a><p>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.<p>I attended the Manager Tools conference and did a conference debrief of it:<p><a href="http://redgreenrepeat.com/2019/03/08/conference-debrief-manager-tools/" rel="nofollow">http://redgreenrepeat.com/2019/03/08/conference-debrief-mana...</a><p>If you have any questions, please ask!
Interesting content. I'm at the IC vs. manager crossroads and this was some well timed perspective.<p>FYI: You have a `margin-top: 1rem;` value in your `.navbar-custom` class causing text to be visible above the header when you scroll.
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.<p>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.<p>As a coder you train a lot! then as a manager you should also train => proactively get training please!!<p>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....<p>an anecdote:<p>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.<p>:) <a href="https://www.edwardtufte.com/tufte/posters" rel="nofollow">https://www.edwardtufte.com/tufte/posters</a>
Highest recommendation for The Manager's Path: <a href="https://www.oreilly.com/library/view/the-managers-path/9781491973882/" rel="nofollow">https://www.oreilly.com/library/view/the-managers-path/97814...</a><p>Also excellent but require some translation to a tech setting: Becoming a Manager (Hill) and Managing (Mintzberg)
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.<p>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.
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.