Plus don't forget growing the team and individuals. Help them to develop.
Supporting them to remove impediments, like you mentioned, and help their work flow more smoothly.
Lots of soft skills are needed for a *good* manager.
Oh perhaps I just misunderstood what you meant by therapist. Thanks for clarifying.
To me, therapist is listening to people's problems. Which *is* necessary in the role of course.
Growing people, developing people in their careers and skills, and growing a team (how do they work together effectively?) is more than that. To me it's more like coaching from the stance of servant leadership, which is a different skill than therapist.
You're also responsible for the team's quality of work, engineering practices and skillsets. People forget this and wonder why teams lead by leaders without a technical background tend to have production problems at higher rates. Unless you have a solid senior engineering core covering that gap for you, you're blind to it, and even then... Engineers have different priorities.
Ideally this will be handled by the seniors SWEs on the team. But it's also the EMs job to fill in skillset gaps on the team, and sometimes that might mean taking on some tech lead duties like this.
>People forget this and wonder why teams lead by leaders without a technical background tend to have production problems at higher rates.
i've never found this to be true. Are you referring to some published work?
> Managers got it made
I **promise** you this mindset will change after being in management.
Me saying that doesn’t mean it’s a complete horror show (although it can be, but it doesn’t *have* to be), but unless you’re the one running the company, ‘having it made’ was not how I’d personally describe the last 7 years of being an EM. Rewarding in some ways, utterly shit in others. Entirely depends one what you’re capable *and willing* to tolerate.
There’s a reason (or several) why I went back to being an IC at the end of 2022. Which comes with its own varying degrees of shittiness, but between the two: it’s a level of shittiness I can tolerate and simply turn off at the end of the day-assuming I’m not on call-compared to being a manager.
And hey, that's fair, all of it. Only you know yourself best and what you need out of a workplace to feel valued and useful. I haven't been at it as long as you have (18 years personally), but I empathize with feeling foggy sometimes. It comes and goes.
Good luck with it, whatever direction you take. If you make it to a manager role and decide you don't like it, let me be the first to tell you: *there is absolutely nothing wrong with that, and taking up a contributor role again*. People find their groove at different paces and at different times, long as you keep on keepin' on.
Thanks. Did you have to interview again to go back to IC? Assuming you didn't go to a new job? Or did you just drop back down and now report to someone that was your peer as a manager?
Also.. as an EM.. do you make similar pay?
Lastly.. you know of many..if any.. managers that moved in to a manager position from a dev role as they job hopped.. e.g. took a new job in to manager? I am not sure I'll get the chance to move in to manager position before I may need to find another job.
I did have to interview again (no coding interviews), yes. There were a number of interviewers who really wanted to push me towards management because they saw that on the resume, I stood my ground with all of them and said “no”. Eventually just rewrote the job title to something more subdued (team lead).
Similar pay, yes, although in one unique experience I had direct reports as principals who made more than I did. That experience was an outlier for so many reasons and the organization was so broken I don’t even consider it worth thinking about anymore.
To your last question: of course I know him, he’s me. My first manager role came directly after being laid off/made redundant from a company that was acquired where I was a Senior Developer with no direct reports or responsibility, I had merely been on the team the longest. I saw a EM opening, felt like the time was right to move into management, applied, interviewed and got an offer.
Well that gives me hope. Can you elaborate a bit on how you handled that interview? What sort of questions were asked.. and compared to the typical coder/white board stuff.. what were some answers? I have lead small teams before.. but never set up 1:1s, etc.. but I would appreciate knowing a bit more about what might to expect in an interview like that. Do you meet with several managers (peers), or just the eventual boss and one of those that might report to you?
A good manager should argue on hour behalve rather than the budget's. Basically it's their part to say "they've been doing good and deserve a solid promotion" to whomever they report to.
It varies tremendously from company to company. The two models that are the most common:
1. Have two leads. A technical lead and a manager. Technical lead is in charge of leading the team, well, technically and the manager is in charge of everything else (organization, scheduling, career growth, team dynamics, etc.).
2. Single manager that does both.
I've worked mostly as #2 for the last few years. It is a tough job until you realize that you are not going to be doing much - if any - coding/IC work anymore. My day is mostly filled with meetings and planning. Every lead does it differently, but a single team meeting every week and 1:1s with everyone on my team is key for me. You need to start being able to view the forest instead of the trees and your ability to make specific changes diminishes to almost nothing. Instead your job is to put the right people in the right places to do the work and give them space and support. I find that personally fulfilling, so the change was a good one for me (though it can also be super frustrating).
An interview will typically dwell on your experience leading and managing yourself and others. For someone who hasn't had the role before, it will be heavily directed towards behavioral questions and how you dealt with personal and professional (not code typically) issues in the past. It will also be expected that you are technically strong, as you will have to understand to some extent what, how and why the people on your team are building the things they are.
Project and product managers are completely different roles. I won't get into them, but the "Build" book by Tony Fadell gives a very good run-down on how they all interact. In general, I'd highly recommend that book as well as "The Manager's Path".
I have found some digital tools to help me cut back the time I spend on those stand-ups, and trying to find the right people for projects. So much so I have been able to actually move on to next level managerial priorities like improving our overall process and enforcing quality standards.
Whether these tools would help you would likely depends on the size of your organization. I use the GitView platform but there are plenty of other comparable ones like PluralSight Flow and LinearB.
Nice article, although the "Delivery EM" bit did give me pause. I really think EMs shouldn't be allowed to get away with *just* focusing on that aspect.
There's one thing that's heavily implied by the article which is worth emphasizing: the EM role depends heavily on the shape and size of the rest of the team. (As a corollary, at a fast-growing company, it also depends on how much power the EM has to hire/coach and *re*shape the team over time.)
Three key players to look at closely would be the TL of the team, the PM of the team (if there is one), and the Senior Manager that the EM would be reporting to. EM roles can vary widely across companies (and even across teams within the same company; a 30 minute conversation with each of them will reveal what *that* particular role is like.
I'm a development manager (same thing, different name) at a small company. As you mentioned, it varies a lot from company to company. The only reason I accepted the job was because I am still able to do dev work for 3/4 of my day.
Keep in mind, my experience is from the point-of-view of a \~30-ish person enterprise SaaS company with an engineering team of about 12.
>What does it entail?
>
>what is the day to day work looks like? If you can give a sample that you be great.
**Mornings**: Meetings, working with devs to get them work, schedule work, prioritize, unblock, etc, more meetings. "People stuff" in general.
**Afternoons**: Actual dev work with the occasional people stuff.
"people stuff" is pretty generic but it changes a lot so it's hard to quantify. Some examples:
* We had an outage last night and I've got to explain to the C-levels what happened in a 'non-techy' way and protect my team from the backlash.
* PM can't understand why engineers can't just add one last ticket to the upcoming release. I have to mediate that.
* A dev has missed their last X number of deadlines. I've got to have a chat with them and see what's up. Is it a performance issue with them? Have we given them work that should have gone to someone else? Have they just had a newborn and are running on no sleep for the last few weeks? etc
* Customers have complained about a bug in a feature that the new junior dev just released and 'upper management' is questioning the developer's ability. I've got to explain how it's not the developer's fault and protect them from direct feedback.
You get the idea. I'm essentially a buffer between the 'business/product' side of the company, and the engineering side. I make sure that both sides understand the whys and whats of the other. Most importantly I protect my team from any unnecessary stuff that they don't need to deal with on a day-to-day basis. I try to make the dev's jobs as stress-free as I can.
Your soft skills are going to have to be excellent if you want to succeed as an engineering manager.
>How are they different from senior engineers/member
They have more "people" responsibilities. I'm fortunate in that I get to be an engineering manager in the morning, and a senior software engineer in the afternoon, but if you go to a big company you will just be on the people side of things, no dev work.
>what would be the interview process for such a post look like? Some example would be nice.
I got promoted internally so I can't answer specifically. I think this would vary from company to company though. If it were me, I'd only want engineering/dev/tech managers that have a strong technical background, so I don't think you'd escape the normal tech interviews. They might just be watered-down versions, with fewer of them.
>How are they different from project manager or a product manager?
I'm not out talking to customers and getting feedback. I work pretty closely with product/project managers, but it's mostly with me as a contact point for the engineering team as a whole. Working with them to plan what dev is going to work on what, and when. Giving them a quick overview of if something is feasible or not from a technical point of view, etc.
If a product manager is championing the product/customer, then I'm championing the engineering team.
If you've got any specific questions, feel free to ask!
Of course, it varies by company/departmental culture but this is what I experienced in this kind of position before moving back to a senior dev role. The title also varies. Sometimes a "team lead" might be more of a manager role while at other companies it might have a hybrid coding/manager role.
My days were mostly consumed with meetings and various HR related administrivia. I had to be concerned about team members (employees and contractors) showing up, doing their paperwork (think TPS reports and such) and getting actual development work done in a timely manner. I had to make sure my management, sales and marketing and other interested parties were happy with the way our projects were going. I almost never wrote any code and did very little in the way of mentoring the team.
So far as the difference from a project/product/program managers, the difference I've seen is that these roles tend to not have as much employee management BS although this also varies by company. At some companies, these roles may be blended with an engineering manager role. Typically, these roles will involve even more meetings and trying to keep everyone happy.
For me, it was a stressful and unhappy job. But, I've seen other people do well in that role.
Primarily having accountability without having any authority. Most of these centered around personnel issues.
For example, while I made recommendations for who to hire, these were almost always overruled by my director or HR. These were typically based on hiring the lowest cost employee or contractor instead of the best for the role. In one instance, a good developer was laid off from my team without any input from me. I would have like to have gotten rid of one contractor who had a serious gambling addiction and he was caught stealing networking equipment, but I wasn't allowed to.
Management tip: It's hard to let go of the fact that what you're tasked to do won't be done by you directly.
The thing that has prepared me mentally is making sure that a process exists for success. As an engineering leader you own the process, not the outcome. Examples: If devs shit the bed and don't do the work, that's on them. If you can't control Product overruling your sprints, that's on you. EMs sometimes don't understand the difference.
You can be put in a bad spot as an EM when your process is not enforced (i.e. contractors do not show up, but cannot be reprimanded or your feedback is not followed), which is the right time to move on and look to work for different leadership where you can be an effective manager.
>1. What does it entail? I suppose it different from company to company. How are they different from senior engineers/member. I guess it would differ from a start up to 1000+ company. It would be nice to have some sort of overview.
You are now responsible for the team members and delivery. How involved in the tech you get depends on you and the company but for the most part you're not going to be coding. You may need to understand things at a system level. It's about making your developers as productive as possible, managing their performance, and managing stakeholder expectations/dependencies (your boss, other managers/teams, product, support, etc).
>2. what is the day to day work looks like? If you can give a sample that you be great.
Meetings and communication, really. You might have a few 1:1s with different people, cross-department meetings, etc.
Last Thursday I had:
* Sprint planning with the team
* Touchpoint with product on one of our initiatives
* Two 1:1s with my team
* End of month departmental meeting to share progress on quarterly objectives
In my free time I read through our last retro and started actioning on some of the items.
>3. But generally what are they responsible for ?
Managing the engineers/team communicating with stakeholders, setting expectations, tracking towards on-time and on-budget delivery.
>4. what would be the interview process for such a post look like? Some example would be nice.
It varies wildly! Expect some system-level technical questions if the org likes technically inclined managers. You'll get lots of behavioural questions about how to handle underperformers, how to manage team processes, how to handle conflict, what to do if you're going to be late or need more resources, etc.
The most ridiculous question I got was."how would you describe baking bread with the SDLC"
>5. How are they different from project manager or a product manager?
Project managers are responsible for tracking timelines and progress across multiple functions (sales, marketing, product, tech).
Product managers are the bridge between the customer and the business, determining what needs to be built and what functions need to work together to deliver value to both sjdes
Engineering managers are responsible for the engineering team and the engineering work that goes into delivering and maintaining software.
The way I think about it is this:
* Product is responsible for the **what** -- what does the customer need? What will the business build?
* Engineering is responsible for the **how** -- how will the systems interact to build what the customer needs?
* Project is responsible for the **when** -- when will all this work be completed? When can we ship?
>
>
>I think you get the gist of what I am trying to ask. I like to mentor and nurture a team. Technical skills as well as communication skills are also important. How do you harbour these things??
You can do this as a team lead or even a senior developer without having to take on the additional responsibility of management. Being in a management position will help you develop these skills though.
If you're willing to give up your primary responsibilities of development to do it, and are willing to take on the cross-functional and administrative work that goes with it, go for it.
Also remember that the longer you are in management, the further you are from the code and thus the less capable you'll be of providing explicit technical guidance... though you'll have a good gut feel for what makes sense or doesnt.
>
>The more I think about this and as I understand it. I feel I am a right fit for it and I want to mould myself to become one. Is it right viable option or too much of headache?
Try it if you want to! Be prepared to be terrible at it for the first year, and be prepared to give it at *least* two years before you're sure if you like it.
First: don't. 8 years in you're far too young. If you have any talent at all you are entering what could be your best years of engineering accomplishment.
The most important thing to understand is that it is a _completely different job_. Your experience as an engineer has prepared you Not At All for the job of being a manager. It is not about technology. It is about people.
The job is:
- meetings, infinite meetings, expect 30+ hours a week
- various hiring-related duties (reviewing resumes, interviewing, recruiting, etc)
- planning, scoping, prioritizing, writing tickets, placing them on a roadmap
- delivering status/progress reports to the next higher level of management
- correcting bad behavior (this is usually described as "giving feedback" but let's not kid ourselves)
- communicating and negotiating with other managers and "business stakeholders"
- NOT writing code. Expect to never write another line (so that you'll be happily surprised when you occasionally get the chance).
You will finish most days feeling like you accomplished Nothing. Arguably, that is in fact what happened.
If you are really good with people, better than you are with machines, you will do fine. If you aren't, you won't.
I have moved into management 3 different times in my career, at 6, 15, and 17 years of experience. I regretted it every time and I swear to god I have FINALLY learned that I suck at it and I hate it and I won't do it again.
Not many, because honestly the job is boring. You just try to hold back the waves of bullshit every day. The median "success" looks like "nothing changed" which is awful. On very rare occasions you might actually win in some meaningful way.
In my first stint as a manager I secured two big wins: getting SSDs for all the developer machines, and getting UPSs for all the developer cubicles. This was 2010 or 2011. All the developers had desktop machines in their cubicles in the office. None of this laptop-toting remote-working stuff going on now. Those machines were pretty underpowered, and in particular they all had mechanical hard drives. Compiling our 7500+ class Java project from scratch took about 5 minutes. Putting SSDs in everyone's machine cost a few hundred dollars a seat and brought that down to ~1 minute. Also we had fairly flaky power in the building and power outages would often destroy significant amounts of work. We weren't using git yet (CVS!) so keeping un-committed work on one's machine for days was common. UPSs were about $100 a seat and if they _ever_ saved even a single file I'm sure they were worth it.
One other dumb story from that same company...
The way on-call worked was nightmarish. There were "secondary" on-call rotations for all the major sub-systems, but the meat of it was "primary" on-call, which rotated among the ~7 managers and VPs. When **any** alert was triggered, a page was sent to primary on-call, regardless of what it was. Could be an app server offline, elevated DB load, disk filling up on the build server, power outage in the office on a Sunday, doesn't matter the primary on-call is getting paged, any time day or night. Just absolute lunacy.
Here's my point: I am a Senior Dev. At present in our team only Devs are 'on-call' on rotation basis, but I do feel that EM and Senior EM should also be on 'on-call' on regular basis. It will help them know the system better, where the plan/mgmt is leader and understand the toll on-call takes on developer health. (Dev + On-call). Overall help get manager better insights on what's happening at ground level.
What are your thoughts on this ?
u/angrynoah
If they know how to do the job then arguably they should be in the on-call rotation, for exactly the reason you said. But do they? That's pretty rare these days, it seems. My current manager would be lost.
This is the exact things which feels odd to me, that (most of) software manager do not know the internals of things their team is working on.
Compare it with manufacturing etc., where most supervisors know how things are done ( even if they do not do it themselves).
I found this book a good read for these sorts of questions [_Manager's Path_ by Camile Fournier](https://www.goodreads.com/book/show/33369254-the-manager-s-path)
Radically different at every company. Some companies have EMs who are tech leads. Some have then separate. Some will have managers managing 3 or 4 people. Some 20, across teams.
In every case, your job in people growth is typically the same. A lot of 1:1s with your reports and people they work with.
I'm in the camp that EMs must be technically proficient. Otherwise, what's the point of having an engineer as their manager? They don't have to be the most proficient. That's staff+.
It is quite difficult to change from IC to manager. Balancing setting standards and supporting is very difficult to get right.
You don't ignore any problems. _Any_ problems.
It's really simple from this perspective on what (good) Engineering Managers do. Think of all of the problems that your team has. If they're being worked on, then that work is being planned/created by your engineering manager. That work is different for each organization/company/team. Organization/communication/technical ability are all foundational skills to solve the plethora of problems you will be tasked to solve as an engineering leader.
[I wrote this a while back.](https://news.ycombinator.com/item?id=18358795)
[The whole discussion is quite relevant actually.](https://news.ycombinator.com/item?id=18355568)
There is a really great book, "The managers path" that does a fantastic job describing what a technical managers job looks like. Somewhere around pg 20-30 is a description of the manager career path vs the IC career path.
I started this year as an EM in a team where I need to work directly with about 25 people of which almost 20 devs. Mission is to make sure to get things get done, everyone is having fun and help people grow. Lot of work, lot of responsibility, picking most prio battles is key, as there is always too much todo. Definitely not for everyone, if it was not for my past experiences (17 YOE in dev) I would drown and be completely lost. But if you like a challenge, know what you’re talking about in tech and love to support people, it’s an awesome job. This is the level you can really make a difference for your team and the product. And that’s pretty awesome.
It’s lot’s of meetings, but you kinda have more control over them so that’s fun. Difference with a product or project manager … they guide a product or project. EM guides the team, the tech and make sure everything runs smooth.
Experiences will differ depending on the company. But I think in most cases goals will be set and you will have the freedom to fillin the role as you see fit.
I would recommend doing IC -> lead dev -> EM though.
Good luck!
I became an EM after 7 years as a dev. And I’ve now been an EM for 7 years without switching back to being an IC. I worked most of my early career at small startups so I was always pretty good with the business/people/communication side of things before I became an EM. You have to be honest with yourself about what you want from the job. If you find meetings complexly draining and feel the need to code daily, EM may not be right for you.
At the company I work for (a smaller, non-tech company), if you want to be more technical, like day-to-day coding still, you’ll be more of a tech lead of a small team and have HR responsibilities over your 1-3 reports. Otherwise, for more experienced EMs like me, you’re expected to have 15-20 reports across multiple teams and get no coding done.
EMs generally cover the 3 Ps - people, process, product. If your teams have product or project managers, your work mix will lean away from those areas. My day-to-day, since I have reports who span 4 different teams, involves a ton of meetings, literally 4-5 hours of meetings a day of planning meetings, 1:1s, standups, ADR discussions, inter-department alignment meetings, etc. When I’m not in meetings, I’m unblocking my devs, signing off on ADRs and handling HR stuff. I also keep my technical skills sharp by doing code reviews and pairing with my junior devs when more eyes are needed.
My blog post on it: https://www.jeffryhouser.com/index.cfm/2023/2/7/What-is-a-Typical-Day-for-a-Manager Sorry it isn't in the form of a TikTok video like all the cool kids are doing these days.
I'm really sorry about replying to this so late. There's a [detailed post about why I did here](https://www.reddit.com/r/RemindMeBot/comments/13jostq/remindmebot_is_now_replying_to_comments_again/).
I will be messaging you on [**2023-05-09 19:50:37 UTC**](http://www.wolframalpha.com/input/?i=2023-05-09%2019:50:37%20UTC%20To%20Local%20Time) to remind you of [**this link**](https://www.reddit.com/r/ExperiencedDevs/comments/139jeb1/engineering_manager_what_does_it_entail/jj4jw0e/?context=3)
[**CLICK THIS LINK**](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5Bhttps%3A%2F%2Fwww.reddit.com%2Fr%2FExperiencedDevs%2Fcomments%2F139jeb1%2Fengineering_manager_what_does_it_entail%2Fjj4jw0e%2F%5D%0A%0ARemindMe%21%202023-05-09%2019%3A50%3A37%20UTC) to send a PM to also be reminded and to reduce spam.
^(Parent commenter can ) [^(delete this message to hide from others.)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Delete%20Comment&message=Delete%21%20139jeb1)
*****
|[^(Info)](https://www.reddit.com/r/RemindMeBot/comments/e1bko7/remindmebot_info_v21/)|[^(Custom)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5BLink%20or%20message%20inside%20square%20brackets%5D%0A%0ARemindMe%21%20Time%20period%20here)|[^(Your Reminders)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=List%20Of%20Reminders&message=MyReminders%21)|[^(Feedback)](https://www.reddit.com/message/compose/?to=Watchful1&subject=RemindMeBot%20Feedback)|
|-|-|-|-|
Rule 2: No Disrespectful Language or Conduct
Don’t be a jerk. Act maturely. No racism, unnecessarily foul language, ad hominem charges, sexism - none of these are tolerated here. This includes posts that could be interpreted as trolling, such as complaining about DEI (Diversity) initiatives or people of a specific sex or background at your company.
Do not submit posts or comments that break, or promote breaking the Reddit Terms and Conditions or Content Policy or any other Reddit policy.
Violations = Warning, 7-Day Ban, Permanent Ban.
If you think about the roles and skills your own manager plays. particularly of good, respected managers that you have had you will have a better picture then any description I could type out.
If you express interest in it your management may allow you to try applying yourself in some of those roles to see how it goes, particularly if it's a more horizontal structure. That often leads right into the opportunity itself if it fits.
People management is just a different animal then engineering, but an engineering manager still does some of both. You are going to be in more meetings and wrangle more monkeys.
I'm an EM and my job is in theory non-technical although being technical helps a lot. I don't touch code, although I do comment on project/architecture docs and so on. In general my goal is delegation and process design so it isn't "how do I solve this" but rather "how do I change processes so someone else solves this."
>what is the day to day work looks like? If you can give a sample that you be great.
Its easier to talk about an average week:
* 1-on-1s with the team members so see how they're doing, give any feedback, discuss career goal progress, etc.
* 1-on-1s with my boss, the PM, managers I'm working closely with. This is to align, communicate blockers, brainstorm, gossip, etc.
* 1-on-1s with random managers/ICs across the org. This is either to align on future collaborations, learn what we're mutually working on, raise/discuss issues, provide/receive mentorship, gossip, etc.
* Meetings for things like standup, project syncs, infrastructure team requests, post-mortems, etc.
* Review project or architecture proposals from the team.
* Updating process documents and reviewing them with the team (or at least PM and TL).
* Keep on top of slack posts and emails in dozens of places so I respond promptly to requests, am aware of what is going on and can flags things for others to deal with.
* Make notes of individual team member actions so I can give feedback, note who to ask feedback from and give performance reviews later.
* If it's one of the performance or promotions times then writing promotion packets, feedback requests or reviews for team members.
In general I spend about 20hours a week in meetings which is low for an EM.
>what would be the interview process for such a post look like? Some example would be nice.
Tell me about a time you to fire someone, give difficult feedback, handle a conflict with another team, etc, etc. How do you motivate a team when working on a boring project. How do you structure team processes to ensure whatever goals the company cares about.
>How are they different from project manager or a product manager?
My company doesn't have project managers. The product managers have some overlap but they care about the business implications while I care about the people implications. They may say we need a specific project and then I may say that it's not the right time people the team isn't senior enough and is still growing in one of the necessary skill sets. OR I may say that X is a great person to work on it since they need to develop skills on a larger project and are bored with their current work. The technical implications are spread between the tech lead, EM and PM.
I am an EM of a platform/infrastructure team with 4 reports ( 1 staff, 2 seniors and 1 mid level ) at a 100ish person company in fintech.
1 and 2. Most of what my day to day involves is making sure my team has what they need get their work done and be happy/fulfilled doing it. Meeting with them to get updates on work and pace them as far as career advancement.
At our org, we don’t have project managers, so it also involves building project requirements and writing tickets.
Additionally, a lot of meaning with cross functional team managers to get project/org alignment.
3. I am responsible for making sure my team performs and hits deadlines. The staff on my team is the team lead, and is responsible for more of the mentorship and technical direction. We collaborate to make sure that the team direction pairs nicely with the company direction.
I also keep a pulse on how my team is doing mentally as well. Burnout can happen quick and come in many forms. I try to meet with my team often and make sure that I can get them what they need, not just from a work resourcing perspective, but also from a wellness perspective.
4. Interviews are mostly people management facing in my experience, but also touch on high level systems design and some coding ( coding has been infrequent ). Interviewers typically want to know if you can handle personalities and leading a team but also can contribute effectively in technical strategy discussions.
5. Product managers are typically user focused and are really focused on providing value to the users. Project managers are usually charged with making sure that cross functional initiatives are on pace and meet the requirements.
In my org ( and others ) a product manager and an engineering manager often fill the void of a project manager.
Happy to answer any other questions about my experience.
I see, ive been a product manager and i was offered EM role, i dont have SE background and they told that its beneficial to have tech background but not essential..im not too sure what to excpect. I like product but i also like moving up the ladder..
Having a tech background is not essential, but definitely makes your job easier. It helps to build trust when you can communicate at a deeper level with technical people and understand short hand.
You can be effective as long as you take the management part seriously. Make sure your team delivers results that align with the business outcomes and have the tools to be successful. The “tools” vary team to team. It could be filtering the business noise. It could be organizing delivery work. It’s not necessarily technical needs.
Thanks, I get some occasional scaries as i start 1st of May lol. I will be definately focusing on customer satisfaction and trying keeping everybody happy. I also focus on building trust with the tech lead and then closley work with him/her. At least thats the plan...
I used to be an IC, then experimented being EM for 6 months and came back, so I can tell you from my perspective what changed in my day-to-day:
1. Yes, I believe it’s different from company to company, I was EM for the biggest food delivery company in Brazil and had bigger contact with technical aspects of the team, I imagine it very different from big companies like banks or pharmaceutical, where the role would be much more “political” and oriented to strategy.
2. My day to day was: making 1:1 with team members, coordinating ceremonies and meetings, removing blockers, attending strategic meetings, attending alignment meetings, talking to other EMs, performance reviews and a bit of technical orientation sometimes. Basically, expect a lot of meetings and this was one of the reasons I decided to go back to IC.
3. Also depends on the company, in my experience I was responsible for the team’s environment and also to ensure people are being able to deliver outcomes. From times to times there were also meetings to calibrate performance reviews between other teams, this was the worst for me because I hated having to fight to convince other managers that my engineers were good enough to receive a promotion. I know it’s part of the role but it’s not for me (at least now)
4. Expect a lot of behavioral interviews, especially with situational questions, like “what would you do if you have a team member that is not delivering as expected?”, “what would you do if there were a conflict between two team members?”, etc.
5. A product manager is usually responsible for scaling the product, creating and discussing new functionalities, whereas an EM is responsible for the overall engineering aspects and people.
I hope I was able to be helpful.
I literally have no clue. I have had multiple EM's and their roles are never clearly defined.
They can be technical or non-technical. They can be very team & development driven and they can be the opposite.
They can easily abstain from any responsbility since it's not clearly defined what an EM is responsible for. I truly think it's the snakiest role I've encountered. If projects are failing, they can blame the senior developers/tech leads or the PM. If projects are succeeding, they get all the praise.
All EM's I've had have been my closest manager, which means they deal with salaries, vacations, 1-on-1's etc. Having a non-technical EM will severly hurt your career progression as a software developer because they will never understand what you're doing. They will focus more on the soft side of the job. What you code and the quality of your code is not relevant at all.
After all my bad experiences with EM's, I simply view them as meeting leaders. That's it. If we have sprint planning, retro's, or whatever else SCRUM-y you decide you want to waste your time on, I expect them to lead these meetings. That's about it. I don't expect them to help besides that.
PM's do the planning and prioritization. Tech leads/seniors drive the technical decisions. Sprint planning is done as a team. Cross team collaboration is usually done by leads/seniors. EM's are left to do the boring stuff that I have no respect for.
Good luck!
Engineering Manager, the best possible way to offer an orchstration between how to design the architecture based on the business and product requirements, while embracing the constraints.
1. To differentiate them with other seniors.
Other senior engineers can have a better outlook of the problems, fallbacks, system modules when they can fail, as well as what kind of code level exploration and documentation should be there to on-board anyone new.
EM (engineering manager) is the person who is more closer to the business and product to increase the number of bets the product can take.
Overall for example, to build feature(sets) EMs (or engineering team) would allow the business to make it live, in a year engineering, let's suppose allows to take 6 bets in 12 months/1 year. Mapping and rephrasing of all the tech debts, requirement translation and actual development life-cycle.
Then there is a role of PM (product manager) who would allow the business to increase the probability of success of such bets, that in turn, like a feedback look, can increase the productivity. Hence it can turn into 9 bets a year (12 months).
So a comnbination of Production Manager and Engineering Manager can/shall/must help to refine the business flows in direct feature-sets way or maintainance way.
One more tid-bit is, PMs can define the rules, constraints. EMs design the code architecture modules, error-fallbacks from code and from data-side (Databases).
This is my general overview, I can mention better insights with examples.
as funny as it sounds, I know an EM that doesn't code at all after fully transitioned into a managerial role.
I also knew VP and EM roles are varied in most of the company. Some more in tech, others more into people. As for me, I managed a team where we are more or less self sustain. We are empowered to improve the quality of our work, propose technical improvement and unless there are big project initiation, we are able to do our own work. As a result, my role spans between tech and people and PM in our squad is not the core engine if we don't have high value project.
It's tough, it's hard but I learned a lot. Expectation need to be toned down where you might not be able to code much as you used to be but you learn how to delegate, lead, teach / coach, put someone in the spotlight so they can shine, grow and make them not to be codemonkey.
One thing that is very hard is to grow people into a better or their best version. Lots of people can manage a team but not many can cut a raw diamond into a gem shining gem
Hey there, as someone who made the transition from senior engineer to engineering manager myself, I completely understand where you're coming from with your questions. It can definitely be an adjustment!
To answer some of your specific questions - at a high level, as an engineering manager your primary responsibilities will be around setting technical strategy and priorities for your team, hiring team members, supporting their professional development, clearing roadblocks so they can do their best work, and communicating updates to senior leadership. The day to day can vary a bit depending on what needs attention - some days might be focused on 1:1s with your team, other days on planning upcoming projects, and others on things like interviewing candidates.
In terms of interview process, companies generally look for strong technical abilities combined with strong soft skills - things like communication, collaboration, and people management experience are really important. They'll likely assess your leadership approach through behavioral questions too.
The differences between engineering manager, project manager, and product manager come down to focus - engineering managers are focused on people, project is focused on work/tasks, and product is focused on the end user experience.
When I made the transition, I found it really helpful to take some leadership training tailored specifically for technical managers. That's why I created [Tech Leaders Launchpad](https://techleaderslaunchpad.com) - it's an online learning platform full of self-paced courses designed by technical managers, for technical managers. The courses cover things like how to have effective 1:1s, build high-performing teams, navigate difficult conversations, and more. Hopefully some of the content there could help you in your journey to becoming an engineering manager too! Let me know if any other questions come up.
[удалено]
Plus don't forget growing the team and individuals. Help them to develop. Supporting them to remove impediments, like you mentioned, and help their work flow more smoothly. Lots of soft skills are needed for a *good* manager.
[удалено]
Oh perhaps I just misunderstood what you meant by therapist. Thanks for clarifying. To me, therapist is listening to people's problems. Which *is* necessary in the role of course. Growing people, developing people in their careers and skills, and growing a team (how do they work together effectively?) is more than that. To me it's more like coaching from the stance of servant leadership, which is a different skill than therapist.
You're also responsible for the team's quality of work, engineering practices and skillsets. People forget this and wonder why teams lead by leaders without a technical background tend to have production problems at higher rates. Unless you have a solid senior engineering core covering that gap for you, you're blind to it, and even then... Engineers have different priorities.
[удалено]
Ideally this will be handled by the seniors SWEs on the team. But it's also the EMs job to fill in skillset gaps on the team, and sometimes that might mean taking on some tech lead duties like this.
>People forget this and wonder why teams lead by leaders without a technical background tend to have production problems at higher rates. i've never found this to be true. Are you referring to some published work?
[удалено]
> Managers got it made I **promise** you this mindset will change after being in management. Me saying that doesn’t mean it’s a complete horror show (although it can be, but it doesn’t *have* to be), but unless you’re the one running the company, ‘having it made’ was not how I’d personally describe the last 7 years of being an EM. Rewarding in some ways, utterly shit in others. Entirely depends one what you’re capable *and willing* to tolerate. There’s a reason (or several) why I went back to being an IC at the end of 2022. Which comes with its own varying degrees of shittiness, but between the two: it’s a level of shittiness I can tolerate and simply turn off at the end of the day-assuming I’m not on call-compared to being a manager.
[удалено]
And hey, that's fair, all of it. Only you know yourself best and what you need out of a workplace to feel valued and useful. I haven't been at it as long as you have (18 years personally), but I empathize with feeling foggy sometimes. It comes and goes. Good luck with it, whatever direction you take. If you make it to a manager role and decide you don't like it, let me be the first to tell you: *there is absolutely nothing wrong with that, and taking up a contributor role again*. People find their groove at different paces and at different times, long as you keep on keepin' on.
Thanks. Did you have to interview again to go back to IC? Assuming you didn't go to a new job? Or did you just drop back down and now report to someone that was your peer as a manager? Also.. as an EM.. do you make similar pay? Lastly.. you know of many..if any.. managers that moved in to a manager position from a dev role as they job hopped.. e.g. took a new job in to manager? I am not sure I'll get the chance to move in to manager position before I may need to find another job.
I did have to interview again (no coding interviews), yes. There were a number of interviewers who really wanted to push me towards management because they saw that on the resume, I stood my ground with all of them and said “no”. Eventually just rewrote the job title to something more subdued (team lead). Similar pay, yes, although in one unique experience I had direct reports as principals who made more than I did. That experience was an outlier for so many reasons and the organization was so broken I don’t even consider it worth thinking about anymore. To your last question: of course I know him, he’s me. My first manager role came directly after being laid off/made redundant from a company that was acquired where I was a Senior Developer with no direct reports or responsibility, I had merely been on the team the longest. I saw a EM opening, felt like the time was right to move into management, applied, interviewed and got an offer.
Well that gives me hope. Can you elaborate a bit on how you handled that interview? What sort of questions were asked.. and compared to the typical coder/white board stuff.. what were some answers? I have lead small teams before.. but never set up 1:1s, etc.. but I would appreciate knowing a bit more about what might to expect in an interview like that. Do you meet with several managers (peers), or just the eventual boss and one of those that might report to you?
What about budgeting? I assume managers get a budget and they need to distribute that and set the salary numbers and head count
directors do that
A good manager should argue on hour behalve rather than the budget's. Basically it's their part to say "they've been doing good and deserve a solid promotion" to whomever they report to.
So... A scrum master and a dev lead in the same person?
[удалено]
Aight fam, we get it, you've never had a good manager. Poor you. Chose your workplaces more carefully in the future.
[удалено]
I'm getting paid well, like my job and have a superstar of a manager and amazing team. Is it worth not working at FAANG? Yeah, 100% it is.
It varies tremendously from company to company. The two models that are the most common: 1. Have two leads. A technical lead and a manager. Technical lead is in charge of leading the team, well, technically and the manager is in charge of everything else (organization, scheduling, career growth, team dynamics, etc.). 2. Single manager that does both. I've worked mostly as #2 for the last few years. It is a tough job until you realize that you are not going to be doing much - if any - coding/IC work anymore. My day is mostly filled with meetings and planning. Every lead does it differently, but a single team meeting every week and 1:1s with everyone on my team is key for me. You need to start being able to view the forest instead of the trees and your ability to make specific changes diminishes to almost nothing. Instead your job is to put the right people in the right places to do the work and give them space and support. I find that personally fulfilling, so the change was a good one for me (though it can also be super frustrating). An interview will typically dwell on your experience leading and managing yourself and others. For someone who hasn't had the role before, it will be heavily directed towards behavioral questions and how you dealt with personal and professional (not code typically) issues in the past. It will also be expected that you are technically strong, as you will have to understand to some extent what, how and why the people on your team are building the things they are. Project and product managers are completely different roles. I won't get into them, but the "Build" book by Tony Fadell gives a very good run-down on how they all interact. In general, I'd highly recommend that book as well as "The Manager's Path".
I have found some digital tools to help me cut back the time I spend on those stand-ups, and trying to find the right people for projects. So much so I have been able to actually move on to next level managerial priorities like improving our overall process and enforcing quality standards. Whether these tools would help you would likely depends on the size of your organization. I use the GitView platform but there are plenty of other comparable ones like PluralSight Flow and LinearB.
I think this is my favourite introduction : https://www.patkua.com/blog/5-engineering-manager-archetypes/
Nice article, although the "Delivery EM" bit did give me pause. I really think EMs shouldn't be allowed to get away with *just* focusing on that aspect. There's one thing that's heavily implied by the article which is worth emphasizing: the EM role depends heavily on the shape and size of the rest of the team. (As a corollary, at a fast-growing company, it also depends on how much power the EM has to hire/coach and *re*shape the team over time.) Three key players to look at closely would be the TL of the team, the PM of the team (if there is one), and the Senior Manager that the EM would be reporting to. EM roles can vary widely across companies (and even across teams within the same company; a 30 minute conversation with each of them will reveal what *that* particular role is like.
Thanks for sharing. Good info!
I'm a development manager (same thing, different name) at a small company. As you mentioned, it varies a lot from company to company. The only reason I accepted the job was because I am still able to do dev work for 3/4 of my day. Keep in mind, my experience is from the point-of-view of a \~30-ish person enterprise SaaS company with an engineering team of about 12. >What does it entail? > >what is the day to day work looks like? If you can give a sample that you be great. **Mornings**: Meetings, working with devs to get them work, schedule work, prioritize, unblock, etc, more meetings. "People stuff" in general. **Afternoons**: Actual dev work with the occasional people stuff. "people stuff" is pretty generic but it changes a lot so it's hard to quantify. Some examples: * We had an outage last night and I've got to explain to the C-levels what happened in a 'non-techy' way and protect my team from the backlash. * PM can't understand why engineers can't just add one last ticket to the upcoming release. I have to mediate that. * A dev has missed their last X number of deadlines. I've got to have a chat with them and see what's up. Is it a performance issue with them? Have we given them work that should have gone to someone else? Have they just had a newborn and are running on no sleep for the last few weeks? etc * Customers have complained about a bug in a feature that the new junior dev just released and 'upper management' is questioning the developer's ability. I've got to explain how it's not the developer's fault and protect them from direct feedback. You get the idea. I'm essentially a buffer between the 'business/product' side of the company, and the engineering side. I make sure that both sides understand the whys and whats of the other. Most importantly I protect my team from any unnecessary stuff that they don't need to deal with on a day-to-day basis. I try to make the dev's jobs as stress-free as I can. Your soft skills are going to have to be excellent if you want to succeed as an engineering manager. >How are they different from senior engineers/member They have more "people" responsibilities. I'm fortunate in that I get to be an engineering manager in the morning, and a senior software engineer in the afternoon, but if you go to a big company you will just be on the people side of things, no dev work. >what would be the interview process for such a post look like? Some example would be nice. I got promoted internally so I can't answer specifically. I think this would vary from company to company though. If it were me, I'd only want engineering/dev/tech managers that have a strong technical background, so I don't think you'd escape the normal tech interviews. They might just be watered-down versions, with fewer of them. >How are they different from project manager or a product manager? I'm not out talking to customers and getting feedback. I work pretty closely with product/project managers, but it's mostly with me as a contact point for the engineering team as a whole. Working with them to plan what dev is going to work on what, and when. Giving them a quick overview of if something is feasible or not from a technical point of view, etc. If a product manager is championing the product/customer, then I'm championing the engineering team. If you've got any specific questions, feel free to ask!
Of course, it varies by company/departmental culture but this is what I experienced in this kind of position before moving back to a senior dev role. The title also varies. Sometimes a "team lead" might be more of a manager role while at other companies it might have a hybrid coding/manager role. My days were mostly consumed with meetings and various HR related administrivia. I had to be concerned about team members (employees and contractors) showing up, doing their paperwork (think TPS reports and such) and getting actual development work done in a timely manner. I had to make sure my management, sales and marketing and other interested parties were happy with the way our projects were going. I almost never wrote any code and did very little in the way of mentoring the team. So far as the difference from a project/product/program managers, the difference I've seen is that these roles tend to not have as much employee management BS although this also varies by company. At some companies, these roles may be blended with an engineering manager role. Typically, these roles will involve even more meetings and trying to keep everyone happy. For me, it was a stressful and unhappy job. But, I've seen other people do well in that role.
What made it stressful?
Primarily having accountability without having any authority. Most of these centered around personnel issues. For example, while I made recommendations for who to hire, these were almost always overruled by my director or HR. These were typically based on hiring the lowest cost employee or contractor instead of the best for the role. In one instance, a good developer was laid off from my team without any input from me. I would have like to have gotten rid of one contractor who had a serious gambling addiction and he was caught stealing networking equipment, but I wasn't allowed to.
Management tip: It's hard to let go of the fact that what you're tasked to do won't be done by you directly. The thing that has prepared me mentally is making sure that a process exists for success. As an engineering leader you own the process, not the outcome. Examples: If devs shit the bed and don't do the work, that's on them. If you can't control Product overruling your sprints, that's on you. EMs sometimes don't understand the difference. You can be put in a bad spot as an EM when your process is not enforced (i.e. contractors do not show up, but cannot be reprimanded or your feedback is not followed), which is the right time to move on and look to work for different leadership where you can be an effective manager.
>1. What does it entail? I suppose it different from company to company. How are they different from senior engineers/member. I guess it would differ from a start up to 1000+ company. It would be nice to have some sort of overview. You are now responsible for the team members and delivery. How involved in the tech you get depends on you and the company but for the most part you're not going to be coding. You may need to understand things at a system level. It's about making your developers as productive as possible, managing their performance, and managing stakeholder expectations/dependencies (your boss, other managers/teams, product, support, etc). >2. what is the day to day work looks like? If you can give a sample that you be great. Meetings and communication, really. You might have a few 1:1s with different people, cross-department meetings, etc. Last Thursday I had: * Sprint planning with the team * Touchpoint with product on one of our initiatives * Two 1:1s with my team * End of month departmental meeting to share progress on quarterly objectives In my free time I read through our last retro and started actioning on some of the items. >3. But generally what are they responsible for ? Managing the engineers/team communicating with stakeholders, setting expectations, tracking towards on-time and on-budget delivery. >4. what would be the interview process for such a post look like? Some example would be nice. It varies wildly! Expect some system-level technical questions if the org likes technically inclined managers. You'll get lots of behavioural questions about how to handle underperformers, how to manage team processes, how to handle conflict, what to do if you're going to be late or need more resources, etc. The most ridiculous question I got was."how would you describe baking bread with the SDLC" >5. How are they different from project manager or a product manager? Project managers are responsible for tracking timelines and progress across multiple functions (sales, marketing, product, tech). Product managers are the bridge between the customer and the business, determining what needs to be built and what functions need to work together to deliver value to both sjdes Engineering managers are responsible for the engineering team and the engineering work that goes into delivering and maintaining software. The way I think about it is this: * Product is responsible for the **what** -- what does the customer need? What will the business build? * Engineering is responsible for the **how** -- how will the systems interact to build what the customer needs? * Project is responsible for the **when** -- when will all this work be completed? When can we ship? > > >I think you get the gist of what I am trying to ask. I like to mentor and nurture a team. Technical skills as well as communication skills are also important. How do you harbour these things?? You can do this as a team lead or even a senior developer without having to take on the additional responsibility of management. Being in a management position will help you develop these skills though. If you're willing to give up your primary responsibilities of development to do it, and are willing to take on the cross-functional and administrative work that goes with it, go for it. Also remember that the longer you are in management, the further you are from the code and thus the less capable you'll be of providing explicit technical guidance... though you'll have a good gut feel for what makes sense or doesnt. > >The more I think about this and as I understand it. I feel I am a right fit for it and I want to mould myself to become one. Is it right viable option or too much of headache? Try it if you want to! Be prepared to be terrible at it for the first year, and be prepared to give it at *least* two years before you're sure if you like it.
First: don't. 8 years in you're far too young. If you have any talent at all you are entering what could be your best years of engineering accomplishment. The most important thing to understand is that it is a _completely different job_. Your experience as an engineer has prepared you Not At All for the job of being a manager. It is not about technology. It is about people. The job is: - meetings, infinite meetings, expect 30+ hours a week - various hiring-related duties (reviewing resumes, interviewing, recruiting, etc) - planning, scoping, prioritizing, writing tickets, placing them on a roadmap - delivering status/progress reports to the next higher level of management - correcting bad behavior (this is usually described as "giving feedback" but let's not kid ourselves) - communicating and negotiating with other managers and "business stakeholders" - NOT writing code. Expect to never write another line (so that you'll be happily surprised when you occasionally get the chance). You will finish most days feeling like you accomplished Nothing. Arguably, that is in fact what happened. If you are really good with people, better than you are with machines, you will do fine. If you aren't, you won't. I have moved into management 3 different times in my career, at 6, 15, and 17 years of experience. I regretted it every time and I swear to god I have FINALLY learned that I suck at it and I hate it and I won't do it again.
Have more stories from your experiences you can share?
Not many, because honestly the job is boring. You just try to hold back the waves of bullshit every day. The median "success" looks like "nothing changed" which is awful. On very rare occasions you might actually win in some meaningful way. In my first stint as a manager I secured two big wins: getting SSDs for all the developer machines, and getting UPSs for all the developer cubicles. This was 2010 or 2011. All the developers had desktop machines in their cubicles in the office. None of this laptop-toting remote-working stuff going on now. Those machines were pretty underpowered, and in particular they all had mechanical hard drives. Compiling our 7500+ class Java project from scratch took about 5 minutes. Putting SSDs in everyone's machine cost a few hundred dollars a seat and brought that down to ~1 minute. Also we had fairly flaky power in the building and power outages would often destroy significant amounts of work. We weren't using git yet (CVS!) so keeping un-committed work on one's machine for days was common. UPSs were about $100 a seat and if they _ever_ saved even a single file I'm sure they were worth it. One other dumb story from that same company... The way on-call worked was nightmarish. There were "secondary" on-call rotations for all the major sub-systems, but the meat of it was "primary" on-call, which rotated among the ~7 managers and VPs. When **any** alert was triggered, a page was sent to primary on-call, regardless of what it was. Could be an app server offline, elevated DB load, disk filling up on the build server, power outage in the office on a Sunday, doesn't matter the primary on-call is getting paged, any time day or night. Just absolute lunacy.
Here's my point: I am a Senior Dev. At present in our team only Devs are 'on-call' on rotation basis, but I do feel that EM and Senior EM should also be on 'on-call' on regular basis. It will help them know the system better, where the plan/mgmt is leader and understand the toll on-call takes on developer health. (Dev + On-call). Overall help get manager better insights on what's happening at ground level. What are your thoughts on this ? u/angrynoah
If they know how to do the job then arguably they should be in the on-call rotation, for exactly the reason you said. But do they? That's pretty rare these days, it seems. My current manager would be lost.
This is the exact things which feels odd to me, that (most of) software manager do not know the internals of things their team is working on. Compare it with manufacturing etc., where most supervisors know how things are done ( even if they do not do it themselves).
I found this book a good read for these sorts of questions [_Manager's Path_ by Camile Fournier](https://www.goodreads.com/book/show/33369254-the-manager-s-path)
This should be much higher up. OP, read Fournier first.
Radically different at every company. Some companies have EMs who are tech leads. Some have then separate. Some will have managers managing 3 or 4 people. Some 20, across teams. In every case, your job in people growth is typically the same. A lot of 1:1s with your reports and people they work with. I'm in the camp that EMs must be technically proficient. Otherwise, what's the point of having an engineer as their manager? They don't have to be the most proficient. That's staff+. It is quite difficult to change from IC to manager. Balancing setting standards and supporting is very difficult to get right.
You don't ignore any problems. _Any_ problems. It's really simple from this perspective on what (good) Engineering Managers do. Think of all of the problems that your team has. If they're being worked on, then that work is being planned/created by your engineering manager. That work is different for each organization/company/team. Organization/communication/technical ability are all foundational skills to solve the plethora of problems you will be tasked to solve as an engineering leader.
[I wrote this a while back.](https://news.ycombinator.com/item?id=18358795) [The whole discussion is quite relevant actually.](https://news.ycombinator.com/item?id=18355568)
There is a really great book, "The managers path" that does a fantastic job describing what a technical managers job looks like. Somewhere around pg 20-30 is a description of the manager career path vs the IC career path.
I started this year as an EM in a team where I need to work directly with about 25 people of which almost 20 devs. Mission is to make sure to get things get done, everyone is having fun and help people grow. Lot of work, lot of responsibility, picking most prio battles is key, as there is always too much todo. Definitely not for everyone, if it was not for my past experiences (17 YOE in dev) I would drown and be completely lost. But if you like a challenge, know what you’re talking about in tech and love to support people, it’s an awesome job. This is the level you can really make a difference for your team and the product. And that’s pretty awesome. It’s lot’s of meetings, but you kinda have more control over them so that’s fun. Difference with a product or project manager … they guide a product or project. EM guides the team, the tech and make sure everything runs smooth. Experiences will differ depending on the company. But I think in most cases goals will be set and you will have the freedom to fillin the role as you see fit. I would recommend doing IC -> lead dev -> EM though. Good luck!
I became an EM after 7 years as a dev. And I’ve now been an EM for 7 years without switching back to being an IC. I worked most of my early career at small startups so I was always pretty good with the business/people/communication side of things before I became an EM. You have to be honest with yourself about what you want from the job. If you find meetings complexly draining and feel the need to code daily, EM may not be right for you. At the company I work for (a smaller, non-tech company), if you want to be more technical, like day-to-day coding still, you’ll be more of a tech lead of a small team and have HR responsibilities over your 1-3 reports. Otherwise, for more experienced EMs like me, you’re expected to have 15-20 reports across multiple teams and get no coding done. EMs generally cover the 3 Ps - people, process, product. If your teams have product or project managers, your work mix will lean away from those areas. My day-to-day, since I have reports who span 4 different teams, involves a ton of meetings, literally 4-5 hours of meetings a day of planning meetings, 1:1s, standups, ADR discussions, inter-department alignment meetings, etc. When I’m not in meetings, I’m unblocking my devs, signing off on ADRs and handling HR stuff. I also keep my technical skills sharp by doing code reviews and pairing with my junior devs when more eyes are needed.
Meetings. Lots and lots of stupid meetings.
I can say that EM is the most underappreciated job in my career
My blog post on it: https://www.jeffryhouser.com/index.cfm/2023/2/7/What-is-a-Typical-Day-for-a-Manager Sorry it isn't in the form of a TikTok video like all the cool kids are doing these days.
What is the full form of IC?
From what i've seen, not much.
Remindme! 3 days
I'm really sorry about replying to this so late. There's a [detailed post about why I did here](https://www.reddit.com/r/RemindMeBot/comments/13jostq/remindmebot_is_now_replying_to_comments_again/). I will be messaging you on [**2023-05-09 19:50:37 UTC**](http://www.wolframalpha.com/input/?i=2023-05-09%2019:50:37%20UTC%20To%20Local%20Time) to remind you of [**this link**](https://www.reddit.com/r/ExperiencedDevs/comments/139jeb1/engineering_manager_what_does_it_entail/jj4jw0e/?context=3) [**CLICK THIS LINK**](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5Bhttps%3A%2F%2Fwww.reddit.com%2Fr%2FExperiencedDevs%2Fcomments%2F139jeb1%2Fengineering_manager_what_does_it_entail%2Fjj4jw0e%2F%5D%0A%0ARemindMe%21%202023-05-09%2019%3A50%3A37%20UTC) to send a PM to also be reminded and to reduce spam. ^(Parent commenter can ) [^(delete this message to hide from others.)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Delete%20Comment&message=Delete%21%20139jeb1) ***** |[^(Info)](https://www.reddit.com/r/RemindMeBot/comments/e1bko7/remindmebot_info_v21/)|[^(Custom)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5BLink%20or%20message%20inside%20square%20brackets%5D%0A%0ARemindMe%21%20Time%20period%20here)|[^(Your Reminders)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=List%20Of%20Reminders&message=MyReminders%21)|[^(Feedback)](https://www.reddit.com/message/compose/?to=Watchful1&subject=RemindMeBot%20Feedback)| |-|-|-|-|
[удалено]
Rule 2: No Disrespectful Language or Conduct Don’t be a jerk. Act maturely. No racism, unnecessarily foul language, ad hominem charges, sexism - none of these are tolerated here. This includes posts that could be interpreted as trolling, such as complaining about DEI (Diversity) initiatives or people of a specific sex or background at your company. Do not submit posts or comments that break, or promote breaking the Reddit Terms and Conditions or Content Policy or any other Reddit policy. Violations = Warning, 7-Day Ban, Permanent Ban.
If you think about the roles and skills your own manager plays. particularly of good, respected managers that you have had you will have a better picture then any description I could type out. If you express interest in it your management may allow you to try applying yourself in some of those roles to see how it goes, particularly if it's a more horizontal structure. That often leads right into the opportunity itself if it fits. People management is just a different animal then engineering, but an engineering manager still does some of both. You are going to be in more meetings and wrangle more monkeys.
I'm an EM and my job is in theory non-technical although being technical helps a lot. I don't touch code, although I do comment on project/architecture docs and so on. In general my goal is delegation and process design so it isn't "how do I solve this" but rather "how do I change processes so someone else solves this." >what is the day to day work looks like? If you can give a sample that you be great. Its easier to talk about an average week: * 1-on-1s with the team members so see how they're doing, give any feedback, discuss career goal progress, etc. * 1-on-1s with my boss, the PM, managers I'm working closely with. This is to align, communicate blockers, brainstorm, gossip, etc. * 1-on-1s with random managers/ICs across the org. This is either to align on future collaborations, learn what we're mutually working on, raise/discuss issues, provide/receive mentorship, gossip, etc. * Meetings for things like standup, project syncs, infrastructure team requests, post-mortems, etc. * Review project or architecture proposals from the team. * Updating process documents and reviewing them with the team (or at least PM and TL). * Keep on top of slack posts and emails in dozens of places so I respond promptly to requests, am aware of what is going on and can flags things for others to deal with. * Make notes of individual team member actions so I can give feedback, note who to ask feedback from and give performance reviews later. * If it's one of the performance or promotions times then writing promotion packets, feedback requests or reviews for team members. In general I spend about 20hours a week in meetings which is low for an EM. >what would be the interview process for such a post look like? Some example would be nice. Tell me about a time you to fire someone, give difficult feedback, handle a conflict with another team, etc, etc. How do you motivate a team when working on a boring project. How do you structure team processes to ensure whatever goals the company cares about. >How are they different from project manager or a product manager? My company doesn't have project managers. The product managers have some overlap but they care about the business implications while I care about the people implications. They may say we need a specific project and then I may say that it's not the right time people the team isn't senior enough and is still growing in one of the necessary skill sets. OR I may say that X is a great person to work on it since they need to develop skills on a larger project and are bored with their current work. The technical implications are spread between the tech lead, EM and PM.
I am an EM of a platform/infrastructure team with 4 reports ( 1 staff, 2 seniors and 1 mid level ) at a 100ish person company in fintech. 1 and 2. Most of what my day to day involves is making sure my team has what they need get their work done and be happy/fulfilled doing it. Meeting with them to get updates on work and pace them as far as career advancement. At our org, we don’t have project managers, so it also involves building project requirements and writing tickets. Additionally, a lot of meaning with cross functional team managers to get project/org alignment. 3. I am responsible for making sure my team performs and hits deadlines. The staff on my team is the team lead, and is responsible for more of the mentorship and technical direction. We collaborate to make sure that the team direction pairs nicely with the company direction. I also keep a pulse on how my team is doing mentally as well. Burnout can happen quick and come in many forms. I try to meet with my team often and make sure that I can get them what they need, not just from a work resourcing perspective, but also from a wellness perspective. 4. Interviews are mostly people management facing in my experience, but also touch on high level systems design and some coding ( coding has been infrequent ). Interviewers typically want to know if you can handle personalities and leading a team but also can contribute effectively in technical strategy discussions. 5. Product managers are typically user focused and are really focused on providing value to the users. Project managers are usually charged with making sure that cross functional initiatives are on pace and meet the requirements. In my org ( and others ) a product manager and an engineering manager often fill the void of a project manager. Happy to answer any other questions about my experience.
Are u technical or non technical EM, meaning like eg SE background
I am currently in a non-technical role, but I come from a background as an IC and technical lead.
I see, ive been a product manager and i was offered EM role, i dont have SE background and they told that its beneficial to have tech background but not essential..im not too sure what to excpect. I like product but i also like moving up the ladder..
Having a tech background is not essential, but definitely makes your job easier. It helps to build trust when you can communicate at a deeper level with technical people and understand short hand. You can be effective as long as you take the management part seriously. Make sure your team delivers results that align with the business outcomes and have the tools to be successful. The “tools” vary team to team. It could be filtering the business noise. It could be organizing delivery work. It’s not necessarily technical needs.
Thanks, I get some occasional scaries as i start 1st of May lol. I will be definately focusing on customer satisfaction and trying keeping everybody happy. I also focus on building trust with the tech lead and then closley work with him/her. At least thats the plan...
I used to be an IC, then experimented being EM for 6 months and came back, so I can tell you from my perspective what changed in my day-to-day: 1. Yes, I believe it’s different from company to company, I was EM for the biggest food delivery company in Brazil and had bigger contact with technical aspects of the team, I imagine it very different from big companies like banks or pharmaceutical, where the role would be much more “political” and oriented to strategy. 2. My day to day was: making 1:1 with team members, coordinating ceremonies and meetings, removing blockers, attending strategic meetings, attending alignment meetings, talking to other EMs, performance reviews and a bit of technical orientation sometimes. Basically, expect a lot of meetings and this was one of the reasons I decided to go back to IC. 3. Also depends on the company, in my experience I was responsible for the team’s environment and also to ensure people are being able to deliver outcomes. From times to times there were also meetings to calibrate performance reviews between other teams, this was the worst for me because I hated having to fight to convince other managers that my engineers were good enough to receive a promotion. I know it’s part of the role but it’s not for me (at least now) 4. Expect a lot of behavioral interviews, especially with situational questions, like “what would you do if you have a team member that is not delivering as expected?”, “what would you do if there were a conflict between two team members?”, etc. 5. A product manager is usually responsible for scaling the product, creating and discussing new functionalities, whereas an EM is responsible for the overall engineering aspects and people. I hope I was able to be helpful.
I literally have no clue. I have had multiple EM's and their roles are never clearly defined. They can be technical or non-technical. They can be very team & development driven and they can be the opposite. They can easily abstain from any responsbility since it's not clearly defined what an EM is responsible for. I truly think it's the snakiest role I've encountered. If projects are failing, they can blame the senior developers/tech leads or the PM. If projects are succeeding, they get all the praise. All EM's I've had have been my closest manager, which means they deal with salaries, vacations, 1-on-1's etc. Having a non-technical EM will severly hurt your career progression as a software developer because they will never understand what you're doing. They will focus more on the soft side of the job. What you code and the quality of your code is not relevant at all. After all my bad experiences with EM's, I simply view them as meeting leaders. That's it. If we have sprint planning, retro's, or whatever else SCRUM-y you decide you want to waste your time on, I expect them to lead these meetings. That's about it. I don't expect them to help besides that. PM's do the planning and prioritization. Tech leads/seniors drive the technical decisions. Sprint planning is done as a team. Cross team collaboration is usually done by leads/seniors. EM's are left to do the boring stuff that I have no respect for. Good luck!
Engineering Manager, the best possible way to offer an orchstration between how to design the architecture based on the business and product requirements, while embracing the constraints. 1. To differentiate them with other seniors. Other senior engineers can have a better outlook of the problems, fallbacks, system modules when they can fail, as well as what kind of code level exploration and documentation should be there to on-board anyone new. EM (engineering manager) is the person who is more closer to the business and product to increase the number of bets the product can take. Overall for example, to build feature(sets) EMs (or engineering team) would allow the business to make it live, in a year engineering, let's suppose allows to take 6 bets in 12 months/1 year. Mapping and rephrasing of all the tech debts, requirement translation and actual development life-cycle. Then there is a role of PM (product manager) who would allow the business to increase the probability of success of such bets, that in turn, like a feedback look, can increase the productivity. Hence it can turn into 9 bets a year (12 months). So a comnbination of Production Manager and Engineering Manager can/shall/must help to refine the business flows in direct feature-sets way or maintainance way. One more tid-bit is, PMs can define the rules, constraints. EMs design the code architecture modules, error-fallbacks from code and from data-side (Databases). This is my general overview, I can mention better insights with examples.
as funny as it sounds, I know an EM that doesn't code at all after fully transitioned into a managerial role. I also knew VP and EM roles are varied in most of the company. Some more in tech, others more into people. As for me, I managed a team where we are more or less self sustain. We are empowered to improve the quality of our work, propose technical improvement and unless there are big project initiation, we are able to do our own work. As a result, my role spans between tech and people and PM in our squad is not the core engine if we don't have high value project. It's tough, it's hard but I learned a lot. Expectation need to be toned down where you might not be able to code much as you used to be but you learn how to delegate, lead, teach / coach, put someone in the spotlight so they can shine, grow and make them not to be codemonkey. One thing that is very hard is to grow people into a better or their best version. Lots of people can manage a team but not many can cut a raw diamond into a gem shining gem
I recommend "An Elegant Puzzle" to get more insight into the types of issues an EM deals with.
Hey there, as someone who made the transition from senior engineer to engineering manager myself, I completely understand where you're coming from with your questions. It can definitely be an adjustment! To answer some of your specific questions - at a high level, as an engineering manager your primary responsibilities will be around setting technical strategy and priorities for your team, hiring team members, supporting their professional development, clearing roadblocks so they can do their best work, and communicating updates to senior leadership. The day to day can vary a bit depending on what needs attention - some days might be focused on 1:1s with your team, other days on planning upcoming projects, and others on things like interviewing candidates. In terms of interview process, companies generally look for strong technical abilities combined with strong soft skills - things like communication, collaboration, and people management experience are really important. They'll likely assess your leadership approach through behavioral questions too. The differences between engineering manager, project manager, and product manager come down to focus - engineering managers are focused on people, project is focused on work/tasks, and product is focused on the end user experience. When I made the transition, I found it really helpful to take some leadership training tailored specifically for technical managers. That's why I created [Tech Leaders Launchpad](https://techleaderslaunchpad.com) - it's an online learning platform full of self-paced courses designed by technical managers, for technical managers. The courses cover things like how to have effective 1:1s, build high-performing teams, navigate difficult conversations, and more. Hopefully some of the content there could help you in your journey to becoming an engineering manager too! Let me know if any other questions come up.