Hacker News new | comments | show | ask | jobs | submit login
Ask HN: Developers who became engineering managers, how was the experience?
211 points by 6ak74rfy 64 days ago | hide | past | web | favorite | 72 comments
How was the new role challenging? What skill-sets from earlier were important in the transition?



I've been in software development for more than 20 years. Here are my 2 cents:

- 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.


I bet you read "Training, training training" and thought "yeah, but I'm pretty good. I'll skip that bit."

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.


"Train people well enough so they can leave, treat them well enough so they don't want to"

- Richard Branson

https://twitter.com/richardbranson/status/449220072176107520...


This is spot on. I would add that as a manager, it is my job to foster good relationships with other managers and use those to remove bottlenecks for my team. I spend a good portion of my day on the phone and walking around the office connecting the dots and getting buy-in or compromises and making sure everyone is on the same page about what's being built. On top of that is having a clear "second" who people can go to when you're out to do the same thing.

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.


Well said. Your goal is to make your team as productive as possible. That means protecting them from wastes of time and keeping them focused on doing nothing but producing high quality product. The term servant leadership is very popular and a good way to approach it. It's not about what they can do for you, you (and me, as management). It's about what you can do to make them as productive as humanly possible. This means keeping them unencumbered, removing all road blocks and making sure they're happy.

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.


I'm in a role as manager/lead dev, so it's kind of mixed. The transition to the managerial part was pretty rough back then and I wished I had gotten more support, many companies don't know how to do that well.

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.


Good tips. A few more:

* 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.)


Go have a listen to this excellent podcast on delegation [1] from Manager Tools. They hit the same notes you’re hitting, but provide some additional actionable tips and tricks for figuring out when things are going well, about to go wrong, or going wrong.

[1] https://www.manager-tools.com/2005/08/the-art-of-delegation


This is a great episode about their "balls in boxes" model of delegation. If you delegate it's probably worth your while to listen to it. If you are delegated to then it's probably also worth your while!


>I wished I had gotten more support, many companies don't know how to do that well.

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.


There's only so much you can "teach" of that, a lot is learning on the job, but a company needs to facilitate that learning. If it was simply a matter of teaching, it would be very easy, but I think everybody knows the feeling of opening a book on "management", reading briefly into it, and then throwing it away thinking that it's all completely obvious. It's not, and you really only find out when you actually do it.


Agreed. I found that books were good for learning the language and theory of management, but the important stuff -- interacting with, influencing and negotiating with people -- that only comes from practice and reflection.


coaching does not equal teaching. teaching is learning information, coaching is ensuring skills transfer and achieving desired personal qualities.


That's just terminology, in both cases there is no way of actually creating those skills beforehand, you have to learn it while going. And that means making a non-manager a manager at some point.


I’m a senior technical staff member on my team. This means that I occasionally get to write code, spend lots of time debugging integration problems, and (as I see it) matching up people and problems that come in to the team. I don’t have direct reports, but I provide feedback to managers, am a team member, lead my own team, and lead / mentor team leaders of other teams.

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] https://www.manager-tools.com/map-of-the-universe


Random thoughts:

* 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.


> You just have to take that massive leap of faith that everything will be alright.

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's not really what he's saying. As a developer, it is up to you to make things go. As a manager, your job is to support engineers and believe that they will make things go.

That is indeed a leap, and a very different mindset.


When you're an engineer, you can literally prove your solutions will work; (through unit tests, etc).

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.


Answer from a different side of the fence:

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.


I’ve read first two -points about four times, but still have no idea what these are about (usual thing when talking to completely “other side of fence” minded people). Can I ask for some examples in context?


Sorry, English is not my primary language, so the grammar constructions might get odd from time to time, this might have been the cause.

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.


Thanks for detailed explanation, it delivered a sense to me and is in great touch with my own leading experience. I even stumbled on point 2, and it took me a month to clearly understand that it’s better to let employee go. But before that I made dead sure I’m objective and not elitist (evaluated task-times, insighted into persons thoughts and knowledge, investigated virtually everything I was aware of in situation). That was pretty stressful and happened few weeks right after my assignment, but later I got few hints from team members that it was an obvious thing to do.


yeah I think it is a suggestion to immediately fire the weakest co-worker when you get promoted? great morale advice for the rest of the culture <3


Could you give an example for the 'eliminating weaknesses is more important than growing strengths' part? I think I've encountered this before - where letting an incompetent developer go would have accelerated a project much more than hiring a very competent one.


It's true, but real leader is responsible for his people and the team as much as for success. Team has to see that leader puts significant effort into making weaker people become stronger before actually letting them go. This way, healthy mutual respect arises instead of hostility and fear, because letting underperformers go always leads to fear, unhealthy competition, intra-team political games which are just a waste of human time and nerves.


I didn't like it, and after about a decade I went back to being a developer.

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.


As a developer, I found that much of the programming I was doing was not very challenging or interesting. Hooking one API to another, optimizing some database routines, converting data efficiently... It felt more like "building" than "designing". Not sure it counts as pure management, but I've moved more into product design roll that needs to understand the business, what can be done in a given time, and set expectations. It's been far more challenging and interesting to me.

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.


I think you could generally classify that sort of role as an "Architect," which is usually a senior/lead engineer who works directly with business analysts/PMs to design the product and also "manage up" to set expectations with the business.


Ask HN: Just made Director, now what? | https://news.ycombinator.com/item?id=14937290 (Aug 2017, only 38 comments)

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


great list of books


The new role itself was not challenging, per se, except getting used to approaching unrealistic demands by non-technical people who have a say in the project. (There is a near constant influx of requests that are made without appreciation for the difference between ones that take 60 minutes versus 600 hours, and explaining such things tactfully and in human terms is an important highlight.)

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


I'm working as developer, now since approx 8 years. At my first job I had a boss with Engineering background but he worked a long time in Management as well. So this was quite nice and when he asked me implement things that would take a long time or would be risky to build, I'd tell him and he would prefer me doing other things. At other jobs this changed, I had to talk to more people but doing the programming mostly alone. Although I sometimes got help from other technical people. Ever since on a regular base I'm confronted with this 60 minutes vs 600 hours problem. Just that it's my problem to write these things myself. But I don't really see myself as anything close to Management.


Managers are allowed to delegate parts of their job. A good manager will allow engineers with interest and potential to get some experience in this sort of thing. Individual contributors should be able to give feedback to the manager if they aren't equipped or prepared to take care of those sorts of tasks. Similarly, if the manager is missing something (like making a mistake on a ballpark estimate), an individual contributor should feel able to bring this up and be taken seriously.


One side note I'll offer: don't view the change as a permanent one. I've bounced back and forth over the 10+ years of my career, and that's been a surprisingly good idea.

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.


I'd highly recommend reading The Manager's Path by Camille Fournier. (http://amzn.com/1491973897) It covers the entire career path for a developer from developer to lead to manager to CTO. I found it incredibly insightful as a roadmap for what skills I'd need and challenges I'd face while laddering up. I also found it useful in understanding the challenges that my current manager is facing and how I could help learn to "manage up".


Learning to limit scope from both engineers “wouldn’t this cool new feature be great” and end users “we want this new feature we never talked about after agreeing on the MVP” has been a learning experience.

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.


What's an MVP? Is that like an SoW?


I read MVP as: Minimum Viable Product.

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


Ah, thank you. Couldn't get past the "Most Valuable Player" association; it is called a Proof of Concept in my industry.


An MVP is actually released to production and is not a PoC It was popularized by Eric Ries in his book _The Lean Startup_.


PoC is quite different. A PoC has to demonstrate a concept, it doesn't have to provide value. An MVP should be something that is used in a production setting. A PoC is usually followed by a "go / no go" decision, MVP is something that is built after the go.


I think most industries have their own terms for essentially the same base idea.

xkcd [0] made an ingenious comic about this that I keep coming back to

[0] https://xkcd.com/793/


The biggest challenge of being a manager compared to a developer is this: Computers do what you tell them to, people do not.

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).


Many years ago, one of my mentors was a senior programmer who had gone from programmer to manager back to programmer again.

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.


I’m a senior technical staff member on my team. This means that I occasionally get to write code, spend lots of time debugging integration problems, and (as I see it) matching up people and problems that come in to the team. I don’t have direct reports, but I provide feedback to managers, am a team member, lead my own team, and lead / mentor team leaders of other teams.

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]


Missing link (I assume) https://www.manager-tools.com/ :)


Yep. :-) of course, I double posted which you can see with the correct link, then couldn’t edit the post thanks to turning on the “anti distraction” features in HN. ;)


I was pushed into the role due to an acquisition from the position of a technical contributor CTO.

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.


I have seen fantastic developers promoted to horrible managers. As others have stated management isn't coding. Leadership isn't management. Understand that it is your job to guide and lead your team not write every line of code or decide that every line written isn't what you would do. You must build trust both up to your management and down to your team. This can be very difficult to juggle as the impedance miss match can tear you apart. be honest and transparent, this doesn't mean be a unfiltered asshole to everyone. Understand not every decision made is binary there are shades of grey. If you find that "politics" is everywhere and you are constantly in an episode of Days of Our Lives then find another job or move back down to development. I personally don't deal with politics or like where everyone has an agenda but I will help solve problems for both my team and for the company and I will help forward ideas I think are good and get behind the decisions made above me and do my best to execute on those decisions.


Its very different, few skill sets carry over from engineering, at first it seemed like I wasn't doing anything useful at all.

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.


Communication. Both up the ladder and down. Up the ladder, you have to be able to sell yourself, your ideas, and your team to other leaders within the organization. Down the ladder, you need to manage the expectations of your direct reports, keep them happy, challenged, and moving forward in their own careers.

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.


I have about 9 months of experience as an engineering manager after a little under 4 years of experience as a developer. I found it a mostly straightforward transition, but perhaps I had a background that prepared me better than a lot of people have.

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.

[1] http://www.au.af.mil/au/awc/awcgate/usmc/leadership.htm


Depends on the company but here's what I have been through:

* 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.


The first time I was promoted to a a manager position I had no idea what this means and nobody told me. Mistakes I made:

- 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.


A pushed "offshore team that didn't deliver". I really don't know when to pull the plug here myself...


I asked a similar question some time ago: https://news.ycombinator.com/item?id=13284742 not about the experience, but more about what to keep in mind when switching. Hope it helps.


The role of project management is very different from that of engineering management. For e.g., the former doesn't have any people management, whereas the latter does.


That's not exactly true. A project manager in some ways has a more difficult people management job than an engineering manager does. They're held accountable for the coordination and performance of people over whom they hold no actual authority. That takes some major diplomatic skills.


I made this jump from researcher to network engineering to applications and systems management to tech group management. I sucked at people and project and process management and I was very lucky to escape back to research and technical communication. Tech management required skills I lack and now, I report to a professional technical manager who is wonderful, a kind, humane and also appropriately critical man. What I sucked at most was giving negative feedback. That and time management. Good managers manage expectations upward and downward, keep blame, share recognition and do not excuse failure but reward admitting mistakes. Don't ever be tempted to lie, and don't shaft people. Don't keep dud hires unless you can find the role they don't suck at. Don't allow bullies to triumph.

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.


Honestly it is a pretty thankless role and unless you are being paid very well to do it I'd recommend avoiding. Jump to being the business owner instead.

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.


I found the daily interactions and increased participation in strategy to be great... BUT I never felt productive. As a dev, it was easy to know when I was productive. I could FEEL productive. As a manager? Not so much. There was nothing tangible. Just meetings and documents, and comments from direct reports. After 2.5 years, I just went back to development.


Can't stress training enough. If your company offers training take advantage of it. If it does not you have to consider if they take your success as a manager seriously, and if you are willing to invest a lot of your own time and energy into bettering yourself while being responsible for other people. I had a bit of training but also was fortunate to have worked for great managers I considered my mentors and found that to be an invaluable resource to fall back on.

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.


I've made the mistake of being a "tech lead". The term usually means some who plays a sort of CTO role but is also a key programmer. It's really tempting because you get a star player salary, but also make full use of your technical skills.

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.


I made the transition after 12 years as a developer.

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.


These are all the minimum requirements for an engineering manager. If I hire a new software engineer I’d excpect to see someone capable of building awesome products. Same for a manager, being good at managing a dev team is for me the minimum requirement. If I were to push the boundaries further, I’d say that you have to be likable, friendly, inspiring, extremely adaptable to different personalities and totally transparent. Be straightforward whenever you can, cut the BS when it comes to career growth. Put yourself at risk and become friends with all your direct reports. The further you stand the harder it is to maintain a healthy relationship. Get your hands dirty. That’s how you seperate an awesome eng manager from the pack.


F*cking awful. I'm a great engineer. I'm not a good manager. There is a big difference, and most of the other replies have done a great job laying out the differences. All I want to do is sit in my corner and build stuff.

/end cathartic outburst


I always felt my only chance to stay relevant in the IT industry is to move to a more managerial position because there are so many smarter developers than me, especially the sort that codes in their free time or has a formal education in CS. Essentially I felt that almost everyone is smarter than me. After being a self-thought developer for 15 years I made a transition to Product and I boost the title of Senior Technical Product Manager. Here are some of my thoughts:

- 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'm editing the blog http://cto.pizza that relates challenges of CTOs, VPs, engineering directors... you might get some insights on what it is like on the blog


Managing requirements vs Managing expectations need different set of skills


I was a Sr. Developer. My boss refused to relocate, and I was offered the job. We have the following leadership roles on a team: Scrum Master, Technical Lead, Product Owner and HR Manager. Originally I was Technical Lead and HR Manager. Later I was TL, PO and HR.

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.


Agreed. I found that books were good for learning the language and theory of management, but the important stuff -- interacting with, influencing and negotiating with people -- that only comes from practice and reflection.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: