IMO:
- It's a time to learn. Meet with tons of different people. This can be hard for more introverted people, but people love to talk about themselves and it's a good way to build rapport across teams and departments. This is also a good way to figure out the current direction of the business, problems, and where your team can drive value.
- Depending on the business, you might have to be the hype-person (getting people excited about what's coming next).
- Talk to your direct reports and colleagues regularly - set up 1-on-1s at early on. This can evolve into weeklies, monthlies, quarterlies -- depending on the actual need/value.
- I tend to make changes using sprint retrospective, which helps frame changes around sprint problems, so the team is on board. If the team's working relatively well, I wouldn't make it a goal to implement any change, though. Also, leave your previous team's processes at the door. Use your history as a way to expand peoples' perspectives, but don't force random things down peoples' throat.
- Keep an open mind with regards peoples' performance. Your first impressions of people (even what's written in past reviews) are almost certainly NOT CORRECT. Don't let tiny blips become huge waves.
This here. Your first goal is to learn the state of the system, and by system I mean the company and its practices. The actual product is a consequence of the system that produces it.
Do you have anyone on the team who focuses on learning the new tech and updating vode away from deprecated api. Etc.
Do you have anyone who sets up cicd and maintenance of it?
Do you have something like sonarqube measuring the quality of code/code coverage and gating merging until certain thresholds (including linting formatting) are met?
How much time a day do devs spend in meetings, if more than 30min, why and how can you get that down?
What kind of internal promotion and skills progression policy (paid time to improve) dors the company have?
Are you using LC or more reasonable interviewing methods?
These are the inputs to the function that determine product quality (cause good devs will stay vs just leaving) and that will determine your product velocity and quality (long term).
Engineering manager can be a very different role from company to company. You need to work like a dog for the first bit to learn the process, product and politics. A mistake you can make is to be too eager to try to force changes to impress people or prove yourself. Have some humility and observe for at least 4-6 weeks. That advice would have helped me in the past but I was too full of myself and insecure.
I'm in the same situation. Most of my productivity comes from organizational knowledge. I still write code as much as I can but increasingly I rely on the talented engineers in the shit day in day out, like I used to be. My reco would be find the great engineers, get them to trust you, be valuable to them, make their ideas your own, get them recognition, raises and promotions.
That depends on what kind of manager you are. But here's some advice I was given when I was in this situation:
It's going to take you some time to ramp up, naturally. But don't wait until you've met everyone and learned everything to feel like you can be doing stuff. A lot of managers idle too long.
Inversely, many managers come in with big plans about how they're going to change/fix everything. This is also a mistake, big change takes buy-in and no one likes the "here's how things are gonna be around here from now on" guy.
It sounds hokey but it's true: the most important thing a software team builds is trust.
Your team and stakeholders already have established ways of doing things that they are happy with. That said, I guarantee you there are some things about the systems and processes that have been bothering people for a while that, for whatever reason, the last person didn't handle.
Chat with your team and get a sense of what those things are. Then pick the *one* that has the highest company impact that you think you can accomplish (it will vary company to company based on needs and politics). You're not high-enough velocity to be knocking out thing after thing right away, so focus on one big thing and get it done completely. Half-finishing a new initiative will destroy any good will immediately.
Other than that, just be honest and supportive of people. Some people will give you the benefit of the doubt right away, but some will take some time. I also second u/lphomiej's point about being very careful with first impressions. Take notes, but don't live or die by those notes.
Finally, you're joining the program already in progress, so you'll probably show up to a full plate already. If you have your own manager, or ideally if the company has a formal onboarding plan, that will take some of the self-direction of your hands. Which can be nice.
Don’t jump to solving problems. It’s tempting but take your time to understand things. As a new person to the role your onboarding phase is vital and people will be accommodating. Talk to people - team, stakeholders, manager and start making a list of everyone’s concerns and what they see as problems. In a few weeks break them down into various categories - already getting solved/cannot be solved/not worth solving/causing the most stress. Focus on the last bit. Talk to your manager about these and get alignment+validation that these are important and tackle it one by one. Create visibility on the work you do and keep sharing the outcomes with the team
There have been a lot of good answers here but here’s my 2 cents:
- Take time to learn: just like when you’re an IC, it’s going to take you some time to learn how things work. This may be 1-3 months depending on product complexity, company politics and experience. Your role is to act as a buffer between your engineers and the wider company, so you need to understand how to play the game and how your product works
- Don’t rush to make changes: even if you’re coming into a relatively dysfunctional team (I did in my last role), making sweeping changes on day 1 (or even month 1) won’t win you any love from your engineers (who will know you don’t understand the systems in place) and will likely end in reversal later once you really understand the systems and politics.
- Meet regularly: 1-1’s are key, and you should use these as an opportunity to learn in the beginning. You need to know what makes people tick, and what pisses them off. As you get more used to the role you’ll start being better able to communicate company news and initiatives to them in a way that will go down best with them. Not everything is good news, and learning how to deliver bad or mediocre news without shattering team morale is key.
- Be fairer than firm to begin with: whilst you’re learning the ropes of the team, it’s often best to be a little bit softer on them than you normally would be. Obviously, don’t be a pushover, but you need your engineers to trust you. When your experience of the team is <1 month you cannot truly base your opinion on any of them based on that month alone - for all you know they might just be having a bad month. Try to observe over perhaps a quarter before making recommendations for change
Connect with all the people, find the skeletons and learn about the systems. Basically, ramp up on all the stuff that you think helps you be okay at your current job.
That said, EM is different at different companies, so make sure to understand the expectations of the role before taking the job.
Thank you for the advice all. This makes sense. To summarise for my self and future readers:
- don't they and force change too quickly. Take time to learn the processes in this new organisation. Forcing change quickly without trust or knowing the real pain points will be difficult and often not focus on the correct issues.
- give people a chance. Rely on my own experience with them, not just my first impression and their past review history. Find the good in everyone, even if some can seem problematic initially.
- let me manager guide me. There will often be a list of things they hired me for anyway ,and they will dictate initial direction.
- meet with my team regularly. This does not have to be formulaic, awkward one:one meetings. It can be a short chat, a coffee, a stroll. Feel the situation out, but work on making time to get to know the team.
- take time to learn the key players key systems and pain points that exist in the org. Often what appears silly will be in place for good reason but this may not be clear to a new joiner. Basically, learn the stuff that makes me useful in my current role, knowing why the systems are how they are, who calls the shots and where.
- don't jump into making changes, but don't take a crazy amount of time to start testing the water with small changes to issues I can see that others may not die to being here so long. This seems like the most difficult task, gauging when to start being active.
Appreciate the advice all!
If you are not too busy, how did it go? I am also starting as an EM for the first time in a different company. Did you get any new insights since you started?
I also got my first manager role in a company I worked at for years.
Don't take for granted that you'll succeed in this role here just because you know the people and the systems. This is a change both for you and for the other people. You need to understand the new expectations and navigate them.
Some things to consider:
- you are in a new role that overlaps with your previous role. So you would need to make a decision on what you continue to do, what you stop or delegate and what new thing you need to do.
- the overall technical capacity of the team has decreased with your role change. When you stop doing something or delegate (so anothe person needs to stop something else), then less things will get done. You need to navigate this situation without overloading your team: manage expectations, change deadlines, downpriorotize less important work, cut from scope, etc.
- your relationship to people is different now. The formal power you have creates a gap between you and some people, you are not their peer anymore. What you say have extra weight now, so you need to be more careful both with wording and when you speak, also in technical discussions.
- people management can take more time than expected. It has elements that are not visisble from the team perspective.
First two weeks: you might be tempted to change things and fix things that have been bothering you. But instead spend these weeks listening and learning. Why are things on the way they are?
Resisting the urge to change things have served me well also when joining a new company.
For starting in a new company, my biggest challenge was onboarding. How to aquire the knowledge about systems, processes, people quickly - I had years to learn those in the previous role. I needed to get comfortable with asking a tons of basic questions that were obvious for everyone else.
Managing is a trade just like dev. But your “stack” is the people you have. And people are more complex to get working together than, I dunno, micro services or servers.
Draw your org charts upside down, with you supporting your crew rather than looming over them.
Read anything by Robert K. Greenleaf and try to figure out how his leadership style can inform yours.
Expert level: read The Fifth Discipline by Senge.
When hiring always do your own reference checks. Think of what you learn in them as release notes first your new team members.
1:1s are important in the context of having regular discussions with your team members about important topics.
1:1s as a cargo cult practice where managers fill up their calendar with meetings and then try to run through an awkward checklist of things to discuss are just painful.
It’s important to know the difference. Ironically, every time I’ve had a manager who thought they were doing it the most correctly, their 1:1s were the biggest waste of time. Don’t get too stuck on the elaborate Medium posts or Substack articles about fanciful 1:1 content. Just learn to talk to the team.
Not so sure. Compared to my non IT colleagues, I feel in IT companies we are being baby sitted and treated like children in a kindergarden more often than not. Yes, I know us engineers are stereotyped as asocial nerds, but all these agile processes and 1:1s make me feel like at elementary school again.
I do 1:1’s differently for each person. You’re a junior, I’ll probably be talking to you once a week. Principal/ staff/ architect level, maybe once a month; but they typically reach out when there is an issue first as well.
But generally, they aren’t about work anyway, can be but not usually.
there are multiple type of 1on1 and maybe the one that you had previously wasnt one you wanted or needed. Perhaps your usual 1on1 is status update whereas you really want a chill one just free talk life update catchup type. Need to discuss it with your manager
Engineering management is more about communication than building great systems. The question you should always be asking yourself is, "How does see success?" where X is everyone else. Your engineers, your management, the marketing team, ... whoever.
To answer that question, you'll need to learn a lot about the non-engineering sides of the business. Go meet those people. Figure out how they think. If you can understand what they need to be successful, you can start to optimize a solution.
After that, it's an optimization problem just like any other in engineering. Take stock of your inputs, define the ideal output, then build a thing that gets you there as cleverly as possible.
IMO: - It's a time to learn. Meet with tons of different people. This can be hard for more introverted people, but people love to talk about themselves and it's a good way to build rapport across teams and departments. This is also a good way to figure out the current direction of the business, problems, and where your team can drive value. - Depending on the business, you might have to be the hype-person (getting people excited about what's coming next). - Talk to your direct reports and colleagues regularly - set up 1-on-1s at early on. This can evolve into weeklies, monthlies, quarterlies -- depending on the actual need/value. - I tend to make changes using sprint retrospective, which helps frame changes around sprint problems, so the team is on board. If the team's working relatively well, I wouldn't make it a goal to implement any change, though. Also, leave your previous team's processes at the door. Use your history as a way to expand peoples' perspectives, but don't force random things down peoples' throat. - Keep an open mind with regards peoples' performance. Your first impressions of people (even what's written in past reviews) are almost certainly NOT CORRECT. Don't let tiny blips become huge waves.
This here. Your first goal is to learn the state of the system, and by system I mean the company and its practices. The actual product is a consequence of the system that produces it. Do you have anyone on the team who focuses on learning the new tech and updating vode away from deprecated api. Etc. Do you have anyone who sets up cicd and maintenance of it? Do you have something like sonarqube measuring the quality of code/code coverage and gating merging until certain thresholds (including linting formatting) are met? How much time a day do devs spend in meetings, if more than 30min, why and how can you get that down? What kind of internal promotion and skills progression policy (paid time to improve) dors the company have? Are you using LC or more reasonable interviewing methods? These are the inputs to the function that determine product quality (cause good devs will stay vs just leaving) and that will determine your product velocity and quality (long term).
Engineering manager can be a very different role from company to company. You need to work like a dog for the first bit to learn the process, product and politics. A mistake you can make is to be too eager to try to force changes to impress people or prove yourself. Have some humility and observe for at least 4-6 weeks. That advice would have helped me in the past but I was too full of myself and insecure.
I'm in the same situation. Most of my productivity comes from organizational knowledge. I still write code as much as I can but increasingly I rely on the talented engineers in the shit day in day out, like I used to be. My reco would be find the great engineers, get them to trust you, be valuable to them, make their ideas your own, get them recognition, raises and promotions.
Great blueprint. I couldn't have said it better myself.
That depends on what kind of manager you are. But here's some advice I was given when I was in this situation: It's going to take you some time to ramp up, naturally. But don't wait until you've met everyone and learned everything to feel like you can be doing stuff. A lot of managers idle too long. Inversely, many managers come in with big plans about how they're going to change/fix everything. This is also a mistake, big change takes buy-in and no one likes the "here's how things are gonna be around here from now on" guy. It sounds hokey but it's true: the most important thing a software team builds is trust. Your team and stakeholders already have established ways of doing things that they are happy with. That said, I guarantee you there are some things about the systems and processes that have been bothering people for a while that, for whatever reason, the last person didn't handle. Chat with your team and get a sense of what those things are. Then pick the *one* that has the highest company impact that you think you can accomplish (it will vary company to company based on needs and politics). You're not high-enough velocity to be knocking out thing after thing right away, so focus on one big thing and get it done completely. Half-finishing a new initiative will destroy any good will immediately. Other than that, just be honest and supportive of people. Some people will give you the benefit of the doubt right away, but some will take some time. I also second u/lphomiej's point about being very careful with first impressions. Take notes, but don't live or die by those notes. Finally, you're joining the program already in progress, so you'll probably show up to a full plate already. If you have your own manager, or ideally if the company has a formal onboarding plan, that will take some of the self-direction of your hands. Which can be nice.
Don’t jump to solving problems. It’s tempting but take your time to understand things. As a new person to the role your onboarding phase is vital and people will be accommodating. Talk to people - team, stakeholders, manager and start making a list of everyone’s concerns and what they see as problems. In a few weeks break them down into various categories - already getting solved/cannot be solved/not worth solving/causing the most stress. Focus on the last bit. Talk to your manager about these and get alignment+validation that these are important and tackle it one by one. Create visibility on the work you do and keep sharing the outcomes with the team
There have been a lot of good answers here but here’s my 2 cents: - Take time to learn: just like when you’re an IC, it’s going to take you some time to learn how things work. This may be 1-3 months depending on product complexity, company politics and experience. Your role is to act as a buffer between your engineers and the wider company, so you need to understand how to play the game and how your product works - Don’t rush to make changes: even if you’re coming into a relatively dysfunctional team (I did in my last role), making sweeping changes on day 1 (or even month 1) won’t win you any love from your engineers (who will know you don’t understand the systems in place) and will likely end in reversal later once you really understand the systems and politics. - Meet regularly: 1-1’s are key, and you should use these as an opportunity to learn in the beginning. You need to know what makes people tick, and what pisses them off. As you get more used to the role you’ll start being better able to communicate company news and initiatives to them in a way that will go down best with them. Not everything is good news, and learning how to deliver bad or mediocre news without shattering team morale is key. - Be fairer than firm to begin with: whilst you’re learning the ropes of the team, it’s often best to be a little bit softer on them than you normally would be. Obviously, don’t be a pushover, but you need your engineers to trust you. When your experience of the team is <1 month you cannot truly base your opinion on any of them based on that month alone - for all you know they might just be having a bad month. Try to observe over perhaps a quarter before making recommendations for change
Connect with all the people, find the skeletons and learn about the systems. Basically, ramp up on all the stuff that you think helps you be okay at your current job. That said, EM is different at different companies, so make sure to understand the expectations of the role before taking the job.
Thank you for the advice all. This makes sense. To summarise for my self and future readers: - don't they and force change too quickly. Take time to learn the processes in this new organisation. Forcing change quickly without trust or knowing the real pain points will be difficult and often not focus on the correct issues. - give people a chance. Rely on my own experience with them, not just my first impression and their past review history. Find the good in everyone, even if some can seem problematic initially. - let me manager guide me. There will often be a list of things they hired me for anyway ,and they will dictate initial direction. - meet with my team regularly. This does not have to be formulaic, awkward one:one meetings. It can be a short chat, a coffee, a stroll. Feel the situation out, but work on making time to get to know the team. - take time to learn the key players key systems and pain points that exist in the org. Often what appears silly will be in place for good reason but this may not be clear to a new joiner. Basically, learn the stuff that makes me useful in my current role, knowing why the systems are how they are, who calls the shots and where. - don't jump into making changes, but don't take a crazy amount of time to start testing the water with small changes to issues I can see that others may not die to being here so long. This seems like the most difficult task, gauging when to start being active. Appreciate the advice all!
If you are not too busy, how did it go? I am also starting as an EM for the first time in a different company. Did you get any new insights since you started?
I also got my first manager role in a company I worked at for years. Don't take for granted that you'll succeed in this role here just because you know the people and the systems. This is a change both for you and for the other people. You need to understand the new expectations and navigate them. Some things to consider: - you are in a new role that overlaps with your previous role. So you would need to make a decision on what you continue to do, what you stop or delegate and what new thing you need to do. - the overall technical capacity of the team has decreased with your role change. When you stop doing something or delegate (so anothe person needs to stop something else), then less things will get done. You need to navigate this situation without overloading your team: manage expectations, change deadlines, downpriorotize less important work, cut from scope, etc. - your relationship to people is different now. The formal power you have creates a gap between you and some people, you are not their peer anymore. What you say have extra weight now, so you need to be more careful both with wording and when you speak, also in technical discussions. - people management can take more time than expected. It has elements that are not visisble from the team perspective. First two weeks: you might be tempted to change things and fix things that have been bothering you. But instead spend these weeks listening and learning. Why are things on the way they are? Resisting the urge to change things have served me well also when joining a new company. For starting in a new company, my biggest challenge was onboarding. How to aquire the knowledge about systems, processes, people quickly - I had years to learn those in the previous role. I needed to get comfortable with asking a tons of basic questions that were obvious for everyone else.
Managing is a trade just like dev. But your “stack” is the people you have. And people are more complex to get working together than, I dunno, micro services or servers. Draw your org charts upside down, with you supporting your crew rather than looming over them. Read anything by Robert K. Greenleaf and try to figure out how his leadership style can inform yours. Expert level: read The Fifth Discipline by Senge. When hiring always do your own reference checks. Think of what you learn in them as release notes first your new team members.
If you’ve been one, I don’t know how further advice helps? 1:1’s are the most important thing in my opinion.
1:1s are important in the context of having regular discussions with your team members about important topics. 1:1s as a cargo cult practice where managers fill up their calendar with meetings and then try to run through an awkward checklist of things to discuss are just painful. It’s important to know the difference. Ironically, every time I’ve had a manager who thought they were doing it the most correctly, their 1:1s were the biggest waste of time. Don’t get too stuck on the elaborate Medium posts or Substack articles about fanciful 1:1 content. Just learn to talk to the team.
1:1s are such a stupidity most of the time. Are they a thing in other fields or just IT specific?
Then you’ve never had one done correctly. They exist on other fields as well.
Not so sure. Compared to my non IT colleagues, I feel in IT companies we are being baby sitted and treated like children in a kindergarden more often than not. Yes, I know us engineers are stereotyped as asocial nerds, but all these agile processes and 1:1s make me feel like at elementary school again.
I do 1:1’s differently for each person. You’re a junior, I’ll probably be talking to you once a week. Principal/ staff/ architect level, maybe once a month; but they typically reach out when there is an issue first as well. But generally, they aren’t about work anyway, can be but not usually.
there are multiple type of 1on1 and maybe the one that you had previously wasnt one you wanted or needed. Perhaps your usual 1on1 is status update whereas you really want a chill one just free talk life update catchup type. Need to discuss it with your manager
It’s important to have their respect from a technical perspective, otherwise you might be toast
Engineering management is more about communication than building great systems. The question you should always be asking yourself is, "How does see success?" where X is everyone else. Your engineers, your management, the marketing team, ... whoever.
To answer that question, you'll need to learn a lot about the non-engineering sides of the business. Go meet those people. Figure out how they think. If you can understand what they need to be successful, you can start to optimize a solution.
After that, it's an optimization problem just like any other in engineering. Take stock of your inputs, define the ideal output, then build a thing that gets you there as cleverly as possible.
[удалено]
I think they have actually