Ask HN: Developers who became engineering managers, how was the experience?
How was the new role challenging? What skill-sets from earlier were important in the transition?
- Training, training, training! Without exception, all the technical managers that I've worked with had arrived where they were at based on technical merits. However, being a manager, especially being a leader have nothing to do with technical knowledge. Therefore management and leadership training is a must. This doesn't necessarily need to be an organized class, but being coached and mentored would be an amazing start.
- Management and Leadership are different skills. This goes back to my #1. One needs to develop both.
- Ideally, you become a servant of the team. You're there to help them become highly productive. Your first job is not to solve the technical problems yourself, not to micromanage everyone, not to command and control. You're there to create a self-managing team that can, ironically, work without a manager.
- You are there to ensure that their motivation and engagement are at a high level. One can be motivated by not engaged. You need to know the differences and the ways to increase them.
- You need empathy to become a good leader.
- You need to be a good communicator. And transparency is a great tool.
- You have to ensure that your team members become good enough to be able to leave your company and find plenty of jobs anywhere else, but also ensure that they wouldn't want to leave.
Also, I think everyone should spend at least some time in their life managing teams. It will profoundly change how you interact with your superiors.
Do not underestimate the differences between being an effective individual contributor and an effective engineering manager.
A lot of the concepts a good manager is driven by are counter-intuitive. For example, technical "leadership" as a manager can be repellant, especially to the more senior of your team, and interpreted as evidence of lack of trust.
The political environment of the company will also dictate your success. Half your job is to be the team coach/servant. The other half is making sure the rest of the company understands that what your team is doing is high-value (and making sure that actually is true).
The OP asked "what skill-sets from earlier were important in the transition." Surprisingly little. One of the team's biggest jobs (which you should try to delegate, by the way), is breaking down a problem into smaller, doable chunks. You'll have done this on smaller scales as a coder, and finding reasonable separations of concern can make or break projects. At the same time, you shouldn't be doing all this work yourself. The more responsibility (not just tasks, but decision-making) you can delegate to your team, the more they will own their work and feel responsible for their own success.
These are very different jobs, but training and spending time in those roles can help you on both sides.
Another piece is being able to make decisions and stand by them. That doesn't mean never backing down, or always being right, but you'll often make quick decisions with less than ideal information and need to be comfortable with that. You'll be wrong a non-negligible portion of the time, so you'll need to own that, work to fix any issues, etc. and not take it too personally.
As a manager of other managers, I like to tell my team that you're in a good place when work can continue on without you; your job is to push things forward, drive process changes and improvements, message successes up and down, etc.
- Richard Branson
https://twitter.com/richardbranson/status/449220072176107520...
With a developer mindset, what helped me was this (no particular order)
* Go about it as a problem solving task. This can be as complex and fun as building a new system - you are building organization and culture. The way you treat them will mirror in how they treat each other and your customers.
* Don't assume too much what a manager should do or what you have seen, but see your new job as an enabler of other people and find out what the particular needs there are. You're the user interface for other people to get things done in the company.
* The hardest thing is probably to stop solving implementation problems yourself. That's again an enabling position. All the stuff you were the expert in before you now need to transfer to other people. Don't just quickly solve their new problems because you know it better.
* One thing about micromanagement - If there's something that appears to be micromanagement, it's often a problem of too little actual management and not enough. That sounds weird, but the reason is that management interferes with people's work directly, where they actually should have given them the tools and the knowledge to do it themselves. So when you start hearing or sensing that notion, don't stop managing, but try to find out where you really need to help.
* Resist all tasks that you and your team can't figure out next step for. (They're not actionable.)
* Find the maximum task length you're comfortable with doing yourself; try to delegate anything that you expect will take you longer. Keep this number very low (e.g. 15 min or 5 min).
* To balance the latter, find the maximum hours you're comfortable with having someone else do work you'd do in an hour. Keep this number high (e.g. 8 hours or 20 hours), and step in to do things yourself only when delegating will make you over it.
(Edit: Also, there are good lessons learned from the past; don't forget to read books books, like PeopleWare.)
[1] https://www.manager-tools.com/2005/08/the-art-of-delegation
It's literally the biggest leadership failure when non-managers get elected to management positions - failure to coach them by senior managers, and ends to torture for everyone. People don't get to deadlift 500lbs after lifting 20lbs for previous 10 years just because someone decided they can do it.
Delegation and Motivation are most difficult by far. I can think of several occasions where I’ve said or done something the wrong way, causing friction, heartache and strife. I’be gotten better at recognizing different communication styles and matching the message to the recipient however.
Soft skills are key. Go look at Manager Tools[1], a podcast focused on improving the quality of management in the workforce. Every podcast they’ve ever produced is online, going back to 2005, and covers all of the unspoken stuff like how to communicate effectively, how to have good 1:1’s, how to give feedback, how to handle “steel cage death match” meetings, and even how to handle personal scent issues.
They organize the podcasts into a “map of the universe” and also have a “hall of fame.”
I’d say start with the map of the universe (it has a “start here” which covers a couple of foundational topics, like I mentioned above. Once you’ve gotten a feel for it, search around and find something relevant (eg performance reviews might be a good idea given that we’re in q4).
* The priorities of developers are very different from those of managers and the greater business. Your goal is to serve the business, but neglecting the needs of your developers has obvious long-term consequences.
* Politics, obviously. I didn't expect to spend my entire working week literally arguing with people.
* Technical skills are still super important. It's not like you give up coding and just manage. You have to be able to do both.
* Buy a Bluetooth headset that you love. I have a Plantronics Voyager Edge. If you're going to spend hours on the phone each day, you might as well be able to type and walk around. (Remember to mute the mic when you flush the toilet.)
* Block out time in your calendar for 'getting work done' -- focus time. Make yourself unavailable. One employer had single-person meeting rooms, which I loved -- I could be found if necessary, but was a lot less likely to be interrupted.
Being a manager for a while helped me to understand why my managers behaved the way that they did, and helps me now (as an individual contributor) to direct my managers to where I think I need to be.
I love the 'bigger picture' thinking, and I love designing larger systems with others. Negotiating about subsystem boundaries and "whose job is it" is challenging, but useful.
I'm happy to leave the fiddly details to others. This is possibly the hardest thing to adapt to -- if other people are coding on your project, they're going to do things the way that they want to. It won't be the way that you want it, and it'll frustrate everyone if you try to force them into doing it your way. You just have to take that massive leap of faith that everything will be alright.
You can never overcommunicate. Learn to love PowerPoint. Write a lot of emails. Document everything on your company wiki.
To let your employees do their jobs is taking a massive leap of faith for you? Looks like you should learn to trust them a little bit more. If they cannot be trusted due to lack of competence, perhaps you should invest in training and a better process.
That is indeed a leap, and a very different mindset.
I think the OP is saying that with management you don't have that kind of proof, and trying to get it will hinder your team.
As an executive who elected senior engineers into engineering managers three time in different companies, there are three challenging areas for even the most fit for the job engineers:
- understanding that soft skills and understanding company politics now matter not as much, but more than detailed technical skills. focusing on eliminating weaknesses in this area is that pareto-ean 20% of effort that makes the rest 10x easier. - it's now about eliminating weaknesses, not growing strengths: what you tolerate slows down and makes everything toxic, while what you preach is a second-order problem for a while. it evens out, and later on you can focus on growing strengths, but only after a while. - you own consistency of engineering culture, not your piece of code and responsibility, now. which makes figuring out internal feeling of "I'm doing it right" twice as hard.
Point 1. Good engineer should know how to code, and how to cooperate with fellow engineers well. This means healthy balance of "hard" (engineering) and "soft" (communication) skills. When engineer becomes tech lead or engineering manager, being able to communicate, understand other people's behavior, lead them, communicate situation up and down the chain,- soft skills start to matter way more. If there are serious skill gaps in soft skills (and all ex-engineers have ones when they start to grow in this area), addressing them is more important for engineering manager's career than addressing lack of up-to-date-ness in latest technology.
Point 1, Example: when I first got to manage a small team, me not understanding power distribution between younger and more experienced engineers (I came from latter category) led to mass extinction of juniors: the way important decisions were made (with more contribution from senior engineers) was good for the company, but the way it was presented (We The Elders Made Crucial Decision) pissed youngsters off, made them feel incapable of making valuable contributions and they quickly left. After understanding the reason (which took hours of mentoring from CTO, a very experienced manager), I had to really work hard on creating the atmosphere where, even when the decisions were made by seniors, the ownership and responsibility for actual implementation of these decisions was distributed among the teams and everybody could contribute to mutual success.
Point 2, with examples already: It kinda continues point 1, but bridges from personal scale to team scale. Process is as good as it's bottleneck. Team is as fast/writes as quality code, as it's weakest members. If you tolerate them, they constrain the process. Your goal is to spot weaker people / weaker engineering decisions and put reasonable amount of effort to either make them better or make them live. As an engineering manager (e.g. manager that comes from engineering, not from fancy MBA factory), you actually can tell the slacker from person who wasn't properly integrated into the process. As an engineering manager, you can tell that the decision to make blocking tests stop CI on the first failure is a poor decision and having a proper failure log of all tests is crucial for speed of bug fixes, not fixing them faster or with better method. Basically you are responsible for the failure (even if you're formally not), because you're the focal point of knowledge and power that can prevent them, put slower people to speed, put processes to full power.
Management may suit you but, as mentioned elsewhere in this thread, even if you're at a 'good' company you'll probably spend a lot of your time neck deep in politics. For me this just wasn't enjoyable or fulfilling, I could do it, my soft skills are ok, but it just wasn't for me. Arguing the toss with Sales or other non-technical people for 40 hours a week was not how I wanted to spend the rest of my working life.
Going back to being a dev was the best thing I ever did, I make the same money as I made in management without the hassle. I still manage dev teams sometimes, but make sure to keep away from the board room. I'm not ruling out ever going back into management but it would have to be a team and an idea I really cared about.
It's not exactly management roll, and it still requires a degree of tech skills, but it's another type of career move option you can make.
Book recommendations:
>gtf21: Would recommend very highly: (1) Andrew Grove's "High Output Management" (controversial recommendation) https://amzn.com/dp/B015VACHOK/ $13.99 2015;4+stars;153 reviews
>killjoywashere: I like Lazlo Bock's book, Work Rules! https://amzn.com/dp/B00MEMMVB8/ $16.99 2015;4+stars;295 reviews
>helper: Maybe read "The Manager's Path" by Camille Fournier. https://amzn.com/dp/B06XP3GJ7F/ $16.19 2017;4+stars;30 reviews
>simonhamp: I'd highly recommend reading Radical Candor by Kim Scott. https://www.amazon.com/dp/B01KTIEFEE/ $12.99 2017;4+stars;138 reviews
Podcast recomendation:
>gtf21: Manager Tools "Basics" podcasts, especially on 1x1s and feedback https://www.manager-tools.com/manager-tools-basics
That said, the thing I would personally place emphasis on is not letting yourself fall behind in the development world, both because (1) it's easy to let happen as you get busy, and (2) maintaining a solid understanding of what you're doing is crucial to efficiency in this capacity.
Disclaimer: personal experience derives from contract work
As an engineer, I have a better understanding of team dynamics, business needs, and other "big picture" items. As a manager, I don't have to worry as much about "losing my edge" technically -- I'll be back into code 6 months or a few years from now.
Best of both worlds.
Also learning to explain how and why one feature is stupidly simple and another is exceedingly impossible has been an interesting challenge.
Otherwise nothing particularly revelatory, you will hear all of the typical “learning the people skills” stuff from me. Also people complain privately to their managers way more than you would think.
Essentially, the first draft of a product that does what it needs to do to show capabilities to others. Similar to a proof of principle
EDIT: Thanks for the clarification @kweinber, an MVP is put into production whereas a PoC/PoP is not
xkcd [0] made an ingenious comic about this that I keep coming back to
Good leadership is paramount I found - it makes the difference between a team that is focused on executing and one that is mired in other issues. As a Marine, I strongly believe in the Marine Corps leadership principles [1] and applied them with great success in improving the work experience for the engineers I was managing in a dysfunctional environment - I have been told that I was the best manager some of these people had as a result, one engineer with over 20 years of experience in the industry.
Anything you are not able to accomplish to make people's lives better at work makes their lives harder, so you must use that as motivation to do the best you can to give them the tools and environment to succeed.
Trust in your engineers to make the right decision & the judgment of the team as a collective - your job is not to handle the technical stuff in general.
Keep eyes and ears open for stuff coming down the pipeline and its effect on the team (people might be interested in certain projects, or it might even affect technical design sometimes).
Keep listening for the things each team member may need/want. Actively probe, and take action wherever possible to help accomplish it.
The list of things that one may want to know is endless. An ability to learn & adapt is very important for a good manager. Seek advice from above and below constantly.
It's definitely a different skill set. Being an engineer is more fun from a day to day perspective. You get to sit down at your desk and build something.
As a manager, you are in the middle of your boss's goals and trying to keep your direct reports happy. Those things don't always align.
You'll need to improve your soft skills. Learn to manage conflict, learn to lead others, and learn to trust your direct reports to do their work without micromanaging. More on that here: https://www.climbuptheladder.com/how-to-be-a-great-manager/.
But life as a manager isn't all bad. You get to learn more about the business. I find the most fulfilling part to be helping my direct reports improve their software skills (particularly the new hires from college).
At the time, I couldn't imagine why anyone would leave the management track-- wasn't that the logical career progression for a programmer? So I asked my friend.
His response: "Because in management, they nip at you from the top and they nip at you from the bottom." Meaning that you have to answer to those above you, and also deal with flak from those below you. It's a constant struggle.
His words (like many other words given to me by others) have proven true.
Delegation and Motivation are most difficult by far. I can think of several occasions where I’ve said or done something the wrong way, causing friction, heartache and strife. I’be gotten better at recognizing different communication styles and matching the message to the recipient however.
Soft skills are key. Go look at Manager Tools[1], a podcast focused on improving the quality of management in the workforce. Every podcast they’ve ever produced is online, going back to 2005, and covers all of the unspoken stuff like how to communicate effectively, how to have good 1:1’s, how to give feedback, how to handle “steel cage death match” meetings, and even how to handle personal scent issues.
They organize the podcasts into a “map of the universe” and also have a “hall of fame.”
I’d say start with the map of the universe (it has a “start here” which covers a couple of foundational topics, like I mentioned above. Once you’ve gotten a feel for it, search around and find something relevant (eg performance reviews might be a good idea given that we’re in q4).
[1]
My experience: It's brutally hard and utterly unrewarding. A good manager is evaluated by the performance of their team and the happiness of their team, but most companies do not even collect metrics on team satisfaction other than the mostly discarded of "peer evaluations". This tends to create a toxic environment where abusive managers who exploit their employees rise to the top and equitable and compassionate managers are forced out or given no real opportunity.
I've also never been offered, and in fact have been refused, any engineering management training. I asked, and folks say it's "too expensive." They offer some books (the wrong ones, usually), but I think they (subconsciously or consciously, idk) recognize that performance of the team is a lot more important.
The final thing is even if you do it for awhile and start to get better at it (as has been the case for me), it begins to infect people's expectations of you in the technical world. Everyone assumes you'll start to do it. In some part because you train yourself to adopt a manager's attitude of calm and promote the idea that "yes, this is fixable we don't need to panic."
Once you do it, it will follow you around.
The challenge is not going back and doing technical work that someone on the team can do because it feels good to 'get something done', and it isn't possible to just edit some code in an engineer reporting to you and recompile them so that they work 20% faster than they did before.
There are a lot of bad managers. You'll hear all sorts of horror stories. But there isn't a book that explains good management, there are 100's of books and they are all different because how management makes sense to a person is unique to that person. When I first started managing I would read books that people recommended. Sometimes there was something useful, sometimes it was opaque. Some assumed you had no understanding of others emotions, others assumed that what others were feeling was as clear to you as if they had an emotional status monitor hanging over their head.
Three things emerged from the mess;
1) There are always two people in a manager/employee relationship and that pair is unique, and the tools need to be appropriate for that pair.
2) People who work for you, are notoriously bad at telling you that you suck. Try to cultivate relationships outside of your group that can give you a different perspective of how things are going.
3) At the end of the day respect, responsibility, and a clear understanding of what is expected is the most effective way to keep people happy and productive.
So to summarize, yes the new role was challenging and what was more, frustrating, in part because the tools I had learned for developing new engineering skills were not applicable. It isn't a job for everyone, this is for sure.
Delegation. As a project manager, I was able to spend a fair amount of time keeping up on tech skills, coding, etc. As soon as I took on personnel responsibilities (as a software development manager), I've found very little time to write code. Some, here and there, but it tends to be in short spurts between meetings or other tasks. I had to learn to trust my team to make good decisions. And also learn how to spot when they are about to make a bad one (and intervene without killing morale, efficiency, etc).
Management is much more of a balancing act. As a developer, you really have one goal - write quality software. As a manager, you have two - fulfill the needs of the executive team while also fulfilling the needs of your team.
* Good dev team doesn't need "managing" but instead you become some kind of BS umbrella to protect them from arbitrary disruptions.
* Don't expect every developer to be as communicative as you expect. They may be unhappy but may not let you know directly. 1 on 1s are really important.
* Much less coding. Less than I am comfortable with.
- Didn't take charge of hiring. My VP pushed people on me I didn't trust. Also had to deal with an offshore team that didn't deliver. Should have said "No" both times.
- Didn't have the final say on raises and promotions. Should have taken charge
- Stayed involved too much in coding. Should have let go
- Didn't get rid of people who didn't fit with the team. Should have made tough decisions
- Had to follow a process that didn't work and caused a lot of overhead. Should have refused
Things I did right:
- Brought things to quick decisions to reduce uncertainty for devs.
- Let people be autonomous and make decisions for themselves
In short, when you are manager, take charge and take responsibility! You are the boss now, so lead, don't just transmit orders from higher up.
Tech management should be more like an anarchist collective of mutuality but I tried, and it doesn't work well in a hierarchical reward structured environment.
Tech management can be learnt but I now understand not everyone can apply it, and you need to be open to the possibility it's not for you. On one management course I was told that if you find yourself in conflict with the goals you're being asked to deliver you may be getting a signal to move. As a wage slave with no reports it's possible to compromise on this but in a leadership role, its untenable to command outcomes you cannot adhere to. Don't do it.
Edit: ok, perhaps it is ok in a situation where you are "earning your chops" as part of a plan for future world domination. Also in specific circumstances and the right company it could be a fulfilling challenge.
It isn't clear exactly what your role entails, but in my opinion it is pretty much impossible to be a great manager and continue in a role as a technical contributor. To me that's more a technical lead than a manager, so if you still like writing code you need to think about that long and hard. Your #1 responsibility is the success of your team and they need to know you are there for them 100%, and not busy buried in code. There are times when you may be able to get your hands dirty but you can be nowhere near the critical path of the project.
You also have to remember you are not only managing your direct reports but who you report to and whomever is relying on your team. In my case, I reported to a VP but I also had to work laterally with other development managers, and in particular project managers that weren't always technical. Just like as an individual contributor you need to maintain a healthy relationship with those you work with directly because you need to balance what they need and want from your team with what your team needs and wants.
That being said, I lasted in management for a little over a year, mostly because the role evolved and due to some changes at the top where I didn't feel I was enabled to be an effective manager. Still, I found the experience invaluable as it gave me more insight into how to better work with people of all stripes. Like any role, technical or otherwise, you have to constantly evaluate what you are getting out of it, if you enjoy it, and if you want to continue bettering yourself in the craft.
One of the issues I had was mistakenly assuming all the people working with me would be easy to get along with and hard working, which was how I behaved and is a factor in my becoming a manager.
It's not that way at all. You see the 80/20 rule play out, where you have a few A+ players who do most everything, a few people who do decent work, and then a handful of duds. Attitude-wise, the harder people work, the more pleasant they tend to be. The duds can be indifferent towards you or even hostile.
Being a developer and being used to controlling my work product, I had to make a shift to trusting other people blindly and that wasn't easy for me. Over time, I realized it was the most effective way to get people to do their best work though - trust that they'll give good results until they repeatedly prove otherwise.
A programmer needs a lot of deep, focused work to do their job, whereas a manager needs to be available.
Managers are the spine and nervous system of a company. They need to transfer information from one part to another quickly. They need to communicate a lot, make decisions quickly. They train newbies, manage project progress, deal with issues.
A manager who wants to do technical work should probably limit himself to more shallow tasks like bug triaging or maybe setting up a checklist of things for the other programmers to do.
/end cathartic outburst
- The variety of companies and cultures is way more heterogeneous than I ever thought. I worked as a dev for mediocre companies where I was one of the weakest in the team and I worked as a PM for NASDAQ companies where I was a probably better developer than the average.
- As a developer I was often frustrated by the inefficiencies in the system that I could not change. AS a manager I am often frustrated by the inefficiencies in the system that I can not change.
- You can learn social skills same as you can learn swimming or dancing. Regardless of how much of a neckbeard you are, if you commit to it, you can learn to be a people person. Use your analytical skills as an advantage to filter out bullshit and follow evidence-based advice. Giving a compliment works 99% of the time.
- The recruitment process for managers is a sham. You must know to recite all the hippest theories but in the actual job you will often fight to fix the most obvious inefficiencies.
- I have less stress and higher salary as a manager. This may not apply universally, but as a manager I will never cause production outage or P0 defect.
- My technical background is a huge advantage, still, there are managers with much better people skills, negotiation skills, business intuition etc. Many others just hide behind buzzwords and fake smiles. Listen and learn.
- Manager or not, I highly recommend this gem of condensed, practical advice: https://www.amazon.co.uk/Mobile-MBA-Skills-Further-Faster/dp... (based on the success of the book Jo Owen diluted the same content in much longer book The Death of Modern Management)
I gave up TL to someone but retained PO. I was just too busy to do all three and decided that Power of the Pen trumped Power of the Code Review, though I still do CRs.
It's hard to let go of the technical leadership, not just for me, but also for everyone else who is used to coming to me.
The people management role is the least rewarding and the most challenging. Hiring can be rewarding, but unless you work somewhere where you're always hiring, you quickly hire some decent or great folks, and then you're done with that. Like really done -- letting people go can take a long time in a big company.
I still write code, but it tends to be emergency fixes or prototypes, not the type of code that requires days on end of focus, because it is impossible to be left alone for any length of time, and not have to do a million simple but important tasks.
Being somebody's boss typically carries a lot of weight, as long as you have their respect, and I find it challenging not to suck the technical oxygen out of our team by doing the research while writing the requirements and taking that fun phase away from developers, thereby limiting their satisfaction and growth. I mean, a good developer will still do their own research even if you hand them something on a silver platter.
Also, you have to learn how each team member works and communicates. Some people are very focused on dry facts, and others on feelings. If you don't speak their language, you'll never be on the same page with them and your relationship will be constantly frustrated.
Some people work fast, and others more slowly. When people seem to be working slowly, you need to consider why. Are they on the wrong path? Did you not give them all the info they need, and they're hesitant to admit they don't understand. Maybe they just the real thorough type? Find a way to get people into their zone quicker, and leverage their individual strengths.
Finally, there is the whole issue of what role do you play. You may have been friend/peer to people who now report to you. If you notice they are slacking off, it's a bit more challenging to get them back on track, but not that hard. Just ask for a detailed status update, take a few notes, and then do it again a few days later, and compare what they've done, or schedule a demo.
Larger or less flat organizations will have a dedicated people manager for 1-3 teams, and their full time job is to manage people, foster moral, etc. That may be rewarding for some folks, but I tend to think the majority of engineering types would hate it.