Mistakes as a new manager(terriblesoftware.org)
terriblesoftware.org
Mistakes as a new manager
https://terriblesoftware.org/2024/12/04/the-6-mistakes-youre-going-to-make-as-a-new-manager/
156 comments
This misses the single biggest mistake every new manager makes: avoiding hard conversations with your reports. If you start managing folks you were recently in the trenches with this can be VERY hard. These are your comrades after all! You want them to like you. It’s all very natural. Sadly it is the single biggest cause for dissatisfaction I’ve seen on a given team. Being unwilling to give honest, direct feedback results in underperforming teams and unhappy reports. It’s counterintuitive but very important to get right as a manager. The big “AHA!!” moment for me was when I realized you need to speak to behaviors and outcomes not character. So instead of “you’re sloppy” you say something like “I’ve noticed quality issues in your code recently that’s resulted in some rollbacks. Can we talk about how we can address that?”. Involving them in the solution and explaining why it matters. It makes all the difference and folks ironically respect and like you more for it.
> “I’ve noticed quality issues in your code recently that’s resulted in some rollbacks. Can we talk about how we can address that?”
This is just about the laziest and least trustworthy language possible to use. Your reports aren't going to know what they don't know and are just going to become paranoid and work slower. The code quality will likely not improve from a conversation prompted this way. This is also a continuous process, not a magic high stakes meeting. If you're in charge you should see patterns in the code reviews and know what their knowledge gaps are causing these issues. They're looking to you for help if you're the one bringing this up in the first place.
If that's too time consuming or over your head you should not be a manager. Leverage your own knowledge and use mentorship to avoid conflicts with your reports and the improved productivity will please the people above you as well. You aren't giving anyone what they need by merely communicating requirements. Your job is to fulfill those requirements with the team you have.
This is just about the laziest and least trustworthy language possible to use. Your reports aren't going to know what they don't know and are just going to become paranoid and work slower. The code quality will likely not improve from a conversation prompted this way. This is also a continuous process, not a magic high stakes meeting. If you're in charge you should see patterns in the code reviews and know what their knowledge gaps are causing these issues. They're looking to you for help if you're the one bringing this up in the first place.
If that's too time consuming or over your head you should not be a manager. Leverage your own knowledge and use mentorship to avoid conflicts with your reports and the improved productivity will please the people above you as well. You aren't giving anyone what they need by merely communicating requirements. Your job is to fulfill those requirements with the team you have.
I’m sure you mean well but reading GP’s post I’m convinced that the laziest and least trustworthy language to use is actually, “you’re sloppy.”
Good idea to think in systems and figure out how to lift the quality of the team but it’s okay to give direct feedback. Especially if the feedback is like GP’s in that it kicks off a constructive conversation, which iiuc is exactly what your final sentence there is waxing on about…
Edit; to be clear I’m suggesting to not aim to avoid conflict. Certainly don’t stoke it for no reason but there is a healthy kind of conflict and how it is engaged with, which builds trust, deepens human relationships, and leads to growth for everyone involved. Psychological safety etc
Good idea to think in systems and figure out how to lift the quality of the team but it’s okay to give direct feedback. Especially if the feedback is like GP’s in that it kicks off a constructive conversation, which iiuc is exactly what your final sentence there is waxing on about…
Edit; to be clear I’m suggesting to not aim to avoid conflict. Certainly don’t stoke it for no reason but there is a healthy kind of conflict and how it is engaged with, which builds trust, deepens human relationships, and leads to growth for everyone involved. Psychological safety etc
Maybe it means the manager assigned work to someone junior that was beyond their capabilities? I suggest the manager has a talk with themselves along these lines: "I've noticed you've assigned Jimmy to work on improving the scalability of the widget producer. In retrospect this was beyond where Jimmy is right now in his journey as a software engineer. Let's reflect on this incident and try to make sure that we have people working on things that help them grow but don't put them in a position where they don't have the experience to do the job right and also to realize they don't have that experience".
Seriously though, I don't think there's "healthy conflict". There are healthy relationships where you can someone they're full of it without it being an insult or you can discuss how to write better software without it being perceived as a personal insult. An environment where people want to grow, are curious, are friendly, and just talk about how to do things better. Once you're in "conflict" territory it's something else. Unfortunately in most organizations you actually do have to get into conflict territory to impact change but I don't see that as a positive thing, just a negative that is a fact of life.
EDIT: This "I noticed blah" pattern is what's taught in formal management training as a method of giving feedback. I know because I've done those. The problem is that wrapping negative feedback in some formulaic pattern is transparent and doesn't work. So the person receiving this immediately strips away your formula and hears the negative feedback. I know that's what I do when someone uses those tools on me. The way forward is not to use those tools but to engage in a true positive way and foster a positive atmosphere. A smart person already knows there's a problem when their code got rolled back. The discussion shouldn't be about their performance "issue" but just about assigning people jobs they can handle and giving them tools and support to that right. There are exceptions when there are more complicated things going on, but the way this is handled when people have good intentions and are motivated is to generally keep helping them stay motivated and have good intentions even when they make mistakes.
Seriously though, I don't think there's "healthy conflict". There are healthy relationships where you can someone they're full of it without it being an insult or you can discuss how to write better software without it being perceived as a personal insult. An environment where people want to grow, are curious, are friendly, and just talk about how to do things better. Once you're in "conflict" territory it's something else. Unfortunately in most organizations you actually do have to get into conflict territory to impact change but I don't see that as a positive thing, just a negative that is a fact of life.
EDIT: This "I noticed blah" pattern is what's taught in formal management training as a method of giving feedback. I know because I've done those. The problem is that wrapping negative feedback in some formulaic pattern is transparent and doesn't work. So the person receiving this immediately strips away your formula and hears the negative feedback. I know that's what I do when someone uses those tools on me. The way forward is not to use those tools but to engage in a true positive way and foster a positive atmosphere. A smart person already knows there's a problem when their code got rolled back. The discussion shouldn't be about their performance "issue" but just about assigning people jobs they can handle and giving them tools and support to that right. There are exceptions when there are more complicated things going on, but the way this is handled when people have good intentions and are motivated is to generally keep helping them stay motivated and have good intentions even when they make mistakes.
I wouldn't say that there's unambiguously healthy conflict, but there's definitely such a thing as unhealthy conflict avoidance.
One generalized example I've seen. Jimmy proposes to make a change that assumes all Foos in production have been replaced with Bars, and will cause an outage if that's not so. Reviewer A says "hey, this seems risky - are you sure the Foos are gone?" "Yes, I'm sure, there's no way that there could be any Foos left". When it turns out that he didn't really check and there were some Foos left, your options are:
* Frank and conflict-laden conversation with Jimmy. By all means say it nicely, but the bottom line is that you can't maintain a collaborative culture if reviewers can't trust the things Jimmy certifies to be true. The underlying unhealthiness might be that it's too hard to verify production state, or that Jimmy isn't competent enough to do it, or that Jimmy is just lazy. You'll have to engage in some conflict to find out.
* Put Jimmy in a penalty box, where everyone knows they can't give him the normal level of trust and need to double check his work. (Won't Jimmy notice, and won't you then have to give him the same conflict-laden conversation? Probably.)
* Let Jimmy run around wrecking things until his relationship with the team is so compromised he's forced to transfer or quit.
Having seen managers pick all three options, the first seems clearly best to me.
One generalized example I've seen. Jimmy proposes to make a change that assumes all Foos in production have been replaced with Bars, and will cause an outage if that's not so. Reviewer A says "hey, this seems risky - are you sure the Foos are gone?" "Yes, I'm sure, there's no way that there could be any Foos left". When it turns out that he didn't really check and there were some Foos left, your options are:
* Frank and conflict-laden conversation with Jimmy. By all means say it nicely, but the bottom line is that you can't maintain a collaborative culture if reviewers can't trust the things Jimmy certifies to be true. The underlying unhealthiness might be that it's too hard to verify production state, or that Jimmy isn't competent enough to do it, or that Jimmy is just lazy. You'll have to engage in some conflict to find out.
* Put Jimmy in a penalty box, where everyone knows they can't give him the normal level of trust and need to double check his work. (Won't Jimmy notice, and won't you then have to give him the same conflict-laden conversation? Probably.)
* Let Jimmy run around wrecking things until his relationship with the team is so compromised he's forced to transfer or quit.
Having seen managers pick all three options, the first seems clearly best to me.
I would first ask myself whether this an honest mistake that anyone could make. If the answer is yes then there's really no need for any conflict. I don't think you have to get into a conflict to find out.
We don't expect people to be perfect. Everyone will occasionally make mistakes. I would not frame it as a loss of trust.
If the answer is no then I agree there's a problem that needs to be root caused. Maybe the root cause is Jimmy had a fight with his spouse, or didn't get enough sleep. Maybe Jimmy just can't do the job we're asking him to do.
Beyond that there are process questions to be asked. Don't you have some sort of staged deployments? dev/stage/prod? The reviewer that was concerned about whether Foos are gone - why was he concerned? Is there an easy way to check that?
I wouldn't say there's never a situation for difficult conversations. But usually those are not the right tool for the job. Jimmy is completely aware (presumably) that he said no Foos are left, and that when his code merged the remaining Foos caused an outage, and that his change had to be rolled back to recover. He is a responsible and trusted member of the team. How does he own up to that? What is your culture? If he is not responsible nor trusted than eventually he'll not be there and that's something to be reinforced positively and understood by a high performance team. It's just my experience that if you're at a point where you're playing those games then it usually isn't going to result in a positive outcome. Those tools are not appropriate for high performance teams in high performance organizations. Maybe they are in different organizations.
EDIT: In the military for example it is common to reinforce what people need to do via some sort of punishment. The difference is that you got people who possibly don't want to be there in the first place and in general you don't fire soldiers. That method sort of works but it doesn't really produce the kind of environment a lot of us would like to be in and there's always conflict between fear of punishment and taking initiative.
I would also say there are other things that can be done in this scenario, including a culture of postmortems, where you review the incident as a team and brainstorm ways of avoiding it in the future. This can be tricky to be done in a truly blameless way but if done right can act as a positive reinforcement. In general it's better that peer pressure and culture are the mechanisms that drive people vs. managerial action simply because the manager can't be everywhere all the time. The manager drives that culture.
We don't expect people to be perfect. Everyone will occasionally make mistakes. I would not frame it as a loss of trust.
If the answer is no then I agree there's a problem that needs to be root caused. Maybe the root cause is Jimmy had a fight with his spouse, or didn't get enough sleep. Maybe Jimmy just can't do the job we're asking him to do.
Beyond that there are process questions to be asked. Don't you have some sort of staged deployments? dev/stage/prod? The reviewer that was concerned about whether Foos are gone - why was he concerned? Is there an easy way to check that?
I wouldn't say there's never a situation for difficult conversations. But usually those are not the right tool for the job. Jimmy is completely aware (presumably) that he said no Foos are left, and that when his code merged the remaining Foos caused an outage, and that his change had to be rolled back to recover. He is a responsible and trusted member of the team. How does he own up to that? What is your culture? If he is not responsible nor trusted than eventually he'll not be there and that's something to be reinforced positively and understood by a high performance team. It's just my experience that if you're at a point where you're playing those games then it usually isn't going to result in a positive outcome. Those tools are not appropriate for high performance teams in high performance organizations. Maybe they are in different organizations.
EDIT: In the military for example it is common to reinforce what people need to do via some sort of punishment. The difference is that you got people who possibly don't want to be there in the first place and in general you don't fire soldiers. That method sort of works but it doesn't really produce the kind of environment a lot of us would like to be in and there's always conflict between fear of punishment and taking initiative.
I would also say there are other things that can be done in this scenario, including a culture of postmortems, where you review the incident as a team and brainstorm ways of avoiding it in the future. This can be tricky to be done in a truly blameless way but if done right can act as a positive reinforcement. In general it's better that peer pressure and culture are the mechanisms that drive people vs. managerial action simply because the manager can't be everywhere all the time. The manager drives that culture.
Ok fair. Some devs do not respond well to advice and consider it just as condescending. Most I've worked with aren't like this though. Yes, we should use our own judgement.
My response is based on my own experiences with management that are incapable of moving the needle on anything, rarely have any constructive input, and ultimately cause their team to either quit or be fired. Then they themselves get pressured to quit.
It's very obvious to devs when someone delegating couldn't even do the work themselves or would do an even sloppier job. It's one thing to expect higher performance, but quite another to demand it while spending all day in meetings giving limp wristed handshakes and bullshitting their way through every question they get from anyone.
I understand that it's already hard enough to hire good devs let alone promote one into management. I'm suggesting how an organization goes about making and promoting those people from within. This industry cannot go on like this. I don't care if someone isn't perfect when I hire them, but I do care that everyone wins.
My response is based on my own experiences with management that are incapable of moving the needle on anything, rarely have any constructive input, and ultimately cause their team to either quit or be fired. Then they themselves get pressured to quit.
It's very obvious to devs when someone delegating couldn't even do the work themselves or would do an even sloppier job. It's one thing to expect higher performance, but quite another to demand it while spending all day in meetings giving limp wristed handshakes and bullshitting their way through every question they get from anyone.
I understand that it's already hard enough to hire good devs let alone promote one into management. I'm suggesting how an organization goes about making and promoting those people from within. This industry cannot go on like this. I don't care if someone isn't perfect when I hire them, but I do care that everyone wins.
Depends on the overall rapport.
"you're sloppy" is too personal.
"this is not to the standard what I would expect" with reasons is factual, if, having been on the receiving end of, harsh. But it should not be done publicly.
"This has to be changed because it will break" (on a PR) is perfectly fine.
"This wasn't even run through linter, please don't drive folks to force push hooks" can be 3rd person passive aggressive (e.x. I'm not advocating for them but others want a series of hooks that is just...too...much...) but potentially factual.
"This .cs file was 2500 lines. You were given a choice but instead you chose violence" is something that was very very hard to not reword into something more polite when a PR wanted to add another 2600 lines. At the very least turn it into a more constructive "This .cs file is already 2500 lines. We need to stop the violence and refactor the class per-business-aspect."
I like that last example, because it shows some very subtle differences in how the same information can be communicated while severity/importance is still pretty dang clear.
"you're sloppy" is too personal.
"this is not to the standard what I would expect" with reasons is factual, if, having been on the receiving end of, harsh. But it should not be done publicly.
"This has to be changed because it will break" (on a PR) is perfectly fine.
"This wasn't even run through linter, please don't drive folks to force push hooks" can be 3rd person passive aggressive (e.x. I'm not advocating for them but others want a series of hooks that is just...too...much...) but potentially factual.
"This .cs file was 2500 lines. You were given a choice but instead you chose violence" is something that was very very hard to not reword into something more polite when a PR wanted to add another 2600 lines. At the very least turn it into a more constructive "This .cs file is already 2500 lines. We need to stop the violence and refactor the class per-business-aspect."
I like that last example, because it shows some very subtle differences in how the same information can be communicated while severity/importance is still pretty dang clear.
Fully agree, quality is teams's effort and having a blameless culture where the team pushes for higher quality bar is essential. Chasing a single individual only makes sense when they have a track record of repeating the same thing multiple times - means they are not learning from their past mistakes.
Constantly pushing for higher quality is not healthy imo. You end up burned. I don’t want to be a high performer (I end up burned) and I don’t want to be a low performer either (end up fired). Something in between is something ICs shouldn’t be afraid of aiming to (unfortunately management doesn’t think like that and want to extract until the last drop of productivity from us)
Exactly. A steady pace is how one achieves longterm success. This is something that I learned after burning out. Do the job well, but don't kill yourself.
Out of curiosity, the OP’s language is “quality issues”, not “quality issue.” Why did you assume there wasn’t already a pattern of behavior implied there?
I'm not OP, but just by the way it was worded. It feels vague and grandstand-y. "I have noticed" is such a silly way to word what's happening here and it's hard not to imbue underlying meanings to it.
And then "can we talk about how we can address that." More vague, leading statements.
Speak to the facts. "The team / org had to roll back this release, the team does not think there is a process improvement that would have alleviated this problem, and the team relied on you to properly make this feature. Our exceptions of all team members is [...]"
Make it clear:
1. This is affecting the whole team (equally)
2. The team as a whole shares this perspective (it's not just the manager nitpicking)
3. There are consistent and vibrant standards that the entire team must adhere to
4. You are not meeting those standard(s) or necessary actions for success.
5. Offer what you think will fix the problem (if anything)
6. Make it clear this is their chance to agree/disagree
7. Continue to talk it out.
Honestly OP seems like a person who has struggled in his position as manager to properly speak to people, and instead of understanding why there was a struggle simply switched to more coded language.
Most people will see through it and react negatively.
And then "can we talk about how we can address that." More vague, leading statements.
Speak to the facts. "The team / org had to roll back this release, the team does not think there is a process improvement that would have alleviated this problem, and the team relied on you to properly make this feature. Our exceptions of all team members is [...]"
Make it clear:
1. This is affecting the whole team (equally)
2. The team as a whole shares this perspective (it's not just the manager nitpicking)
3. There are consistent and vibrant standards that the entire team must adhere to
4. You are not meeting those standard(s) or necessary actions for success.
5. Offer what you think will fix the problem (if anything)
6. Make it clear this is their chance to agree/disagree
7. Continue to talk it out.
Honestly OP seems like a person who has struggled in his position as manager to properly speak to people, and instead of understanding why there was a struggle simply switched to more coded language.
Most people will see through it and react negatively.
I’m surprised by this and curious at the “team thinks” framing. What advantages do you see here?
I think I would much rather own the critique myself than say “the team thinks x.”
For context, I’d probably start with “what happened with that deployment that was rolled back?” and let them self-diagnose and share their perspective. By listening, I might learn there were extenuating issues, or I may see they are already aware of the issue.
If they’re able to critique their own work, I can agree and reinforce the whys. There’s no hostility and we can talk about what ideas we have for what we can do going forward.
If not, and I think we must do better, I can talk about my concerns, my expectations, and the consequences that I am worried about or frustrated by, and propose more prescriptive remedies.
I think I would much rather own the critique myself than say “the team thinks x.”
For context, I’d probably start with “what happened with that deployment that was rolled back?” and let them self-diagnose and share their perspective. By listening, I might learn there were extenuating issues, or I may see they are already aware of the issue.
If they’re able to critique their own work, I can agree and reinforce the whys. There’s no hostility and we can talk about what ideas we have for what we can do going forward.
If not, and I think we must do better, I can talk about my concerns, my expectations, and the consequences that I am worried about or frustrated by, and propose more prescriptive remedies.
>I’m surprised by this and curious at the “team thinks” framing. What advantages do you see here?
>I think I would much rather own the critique myself than say “the team thinks x.”
"the team thinks" means, well I went around and talked to everyone else about you before talking to you and they all say you suck! In short I don't think there would be an advantage to that.
>I think I would much rather own the critique myself than say “the team thinks x.”
"the team thinks" means, well I went around and talked to everyone else about you before talking to you and they all say you suck! In short I don't think there would be an advantage to that.
> “I’ve noticed quality issues in your code recently that’s resulted in some rollbacks. Can we talk about how we can address that?”
That’s the first step in fixing the quality issues, not an end state. Reports don’t know what they don’t know, so step 1 is to get their ideas on how to fix quality issues.
That’s the first step in fixing the quality issues, not an end state. Reports don’t know what they don’t know, so step 1 is to get their ideas on how to fix quality issues.
This sounds so stupid. I'm sorry but feedback is already given in PRs. This kind of feedback is just a bad idea IMO. Focus on growth and areas of improvements. Your reports often already know what they should focus on, and they are on their own journey of time management. The only lever you have as a manager is to add or remove pressure. The only help you can give is through mentoring or therapy/coaching.
It really depends on how you communicate with your team and the level of physiological safety you have.
I work on a team where this would be a "matter of fact" means of having this conversation. Nobody on the team would bat an eye at someone else telling them this or their manager telling them this. We all know we're extremely good at our jobs and we all know that even the best of us have issues from time to times. Every, single, one of us would prefer to have this conversation upfront, before it becomes a spiraling issue that results in termination.
That being said, I've also worked on teams where I'd be sending my resume out the moment I've heard those words.
I work on a team where this would be a "matter of fact" means of having this conversation. Nobody on the team would bat an eye at someone else telling them this or their manager telling them this. We all know we're extremely good at our jobs and we all know that even the best of us have issues from time to times. Every, single, one of us would prefer to have this conversation upfront, before it becomes a spiraling issue that results in termination.
That being said, I've also worked on teams where I'd be sending my resume out the moment I've heard those words.
I'm willing to give them the benefit of the doubt, there's a tendency to write like that when you certainly wouldn't say it like that. It doesn't help that it's an example.
In a real meeting, it might be more like "the email bug last week was a big problem. I'm not trying to blame you, but it can't happen again, so what happened?"
But I'm also inclined to agree with you. If your strategy to maintain quality hinges on people not messing up, you'll have a bad time.
In a real meeting, it might be more like "the email bug last week was a big problem. I'm not trying to blame you, but it can't happen again, so what happened?"
But I'm also inclined to agree with you. If your strategy to maintain quality hinges on people not messing up, you'll have a bad time.
Heh. Thanks for this. I am a bit disheartened about how much the arbitrary example I made is getting picked apart vs the actual point I was trying to make. It is what it is. HN gonna HN and all that lol.
Blameless culture is very important. You need psychological safety. Maybe I should have picked something else as an example like rudeness or something. Ah well.
Blameless culture is very important. You need psychological safety. Maybe I should have picked something else as an example like rudeness or something. Ah well.
I mean look, it was an arbitrary example I gave and not a very good one apparently. The bulk of these comments are all focusing myopically on that which is a bummer as it distracts from the point I’m trying to make. Managers need to be willing to have hard conversations and most new ones don’t.
I believe strongly in a blameless culture when it comes to bugs and such. The example I gave doesn’t really honor that. I can’t edit it unfortunately. I do stand my my larger point however.
I believe strongly in a blameless culture when it comes to bugs and such. The example I gave doesn’t really honor that. I can’t edit it unfortunately. I do stand my my larger point however.
Huh?
This is precisely the way to have that conversation.
This is precisely the way to have that conversation.
> I’ve noticed quality issues in your code recently that’s resulted in some rollbacks
I would tend to even leave out the first part of that phrase. Focus on the actual objective measure: the rollbacks. They happened, and the goal is to figure out how to not have them happen in the future.
I would tend to even leave out the first part of that phrase. Focus on the actual objective measure: the rollbacks. They happened, and the goal is to figure out how to not have them happen in the future.
I disagree, at least in this case. In the comment you're replying to, the new manager is technical and familiar with the codebase, and can assess that the reason for the rollbacks is a genuine quality issue. This is useful information, and if you leave it out then you leave your report partially in the dark, wondering if the rollbacks are happening for some other reason (I can think of plenty).
I'm not saying it needs to literally be in the first sentence or phrased exactly like that, but I don't think that's what they meant anyway. Rather, you do need to be upfront about it instead of alluding to the problem without giving away what you actually think.
I'm not saying it needs to literally be in the first sentence or phrased exactly like that, but I don't think that's what they meant anyway. Rather, you do need to be upfront about it instead of alluding to the problem without giving away what you actually think.
> the new manager is technical and familiar with the codebase, and can assess that the reason for the rollbacks is a genuine quality issue. This is useful information
Only if the report doesn't already know it. But they probably do. It doesn't seem likely to me that the report would be in the dark about why the rollbacks happened. And if they already know it, it's better to let them ask for help than to tell them up front that you, their manager, know that their code quality is an issue. Give them a chance to identify the issue themselves first.
Only if the report doesn't already know it. But they probably do. It doesn't seem likely to me that the report would be in the dark about why the rollbacks happened. And if they already know it, it's better to let them ask for help than to tell them up front that you, their manager, know that their code quality is an issue. Give them a chance to identify the issue themselves first.
You haven't met anyone that has quality issues but doesn't realise it? Lucky you!
Even if they do, mentioning that everyone is rejecting their code and asking why they think that is, when you know full well the answer, is classic passive aggression and more condescending than just stating the obvious situation (again, not saying it literally needs to be in the same breath like the sentence I quoted).
Even if they do, mentioning that everyone is rejecting their code and asking why they think that is, when you know full well the answer, is classic passive aggression and more condescending than just stating the obvious situation (again, not saying it literally needs to be in the same breath like the sentence I quoted).
> everyone is rejecting their code
That's not what "rollbacks" means. "Rollbacks" means other people accepted their code, let it get into production, and then an issue surfaced that forced the change to be rolled back, and this happened multiple times. So at a minimum, there have to be other people besides this particular coder who made mistakes, multiple times.
If other people rejected their code multiple times in code review, the problem wouldn't be "multiple rollbacks", it would be "multiple rejections in code review", and yes, in that situation you have a much better case for being up front about "quality issues in their code", since the process itself is working and highlighting that specific issue.
> you know full well the answer
If you are operating on the belief that only this particular report bears responsibility for "multiple rollbacks", then I think you do not "know full well the answer". You are ignoring the fact that other people had to let this poor quality code get into production in order to have rollbacks happen. You are also ignoring your own responsibility as a manager (as the sibling post to yours by cutemonster pointed out) to address issues like this before they result in multiple instances of a problem with production code (see my response to the sibling post I just mentioned).
That's not what "rollbacks" means. "Rollbacks" means other people accepted their code, let it get into production, and then an issue surfaced that forced the change to be rolled back, and this happened multiple times. So at a minimum, there have to be other people besides this particular coder who made mistakes, multiple times.
If other people rejected their code multiple times in code review, the problem wouldn't be "multiple rollbacks", it would be "multiple rejections in code review", and yes, in that situation you have a much better case for being up front about "quality issues in their code", since the process itself is working and highlighting that specific issue.
> you know full well the answer
If you are operating on the belief that only this particular report bears responsibility for "multiple rollbacks", then I think you do not "know full well the answer". You are ignoring the fact that other people had to let this poor quality code get into production in order to have rollbacks happen. You are also ignoring your own responsibility as a manager (as the sibling post to yours by cutemonster pointed out) to address issues like this before they result in multiple instances of a problem with production code (see my response to the sibling post I just mentioned).
> You haven't met anyone that has quality issues but doesn't realise it? Lucky you!
We're not just talking about someone who has code quality issues. We're talking about someone who has code quality issues that have resulted in multiple rollbacks. Even if they weren't bright enough to spot that their code quality contributed on their own, they're going to hear about it from other people who had to get involved in the rollbacks.
We're not just talking about someone who has code quality issues. We're talking about someone who has code quality issues that have resulted in multiple rollbacks. Even if they weren't bright enough to spot that their code quality contributed on their own, they're going to hear about it from other people who had to get involved in the rollbacks.
Meanwhile, deployments keep getting rolled back?
Sounds like this mistake:
> > avoiding hard conversations with your reports.
And hoping that things will get better soon. But:
> > Sadly it is the single biggest cause for dissatisfaction
that can also be among others in the team, who have to deal with the rollbacks.
Sounds like this mistake:
> > avoiding hard conversations with your reports.
And hoping that things will get better soon. But:
> > Sadly it is the single biggest cause for dissatisfaction
that can also be among others in the team, who have to deal with the rollbacks.
> Meanwhile, deployments keep getting rolled back?
One could say that the scenario as described in the post I originally responded to, by localghost3000, doesn't make sense, yes. If there have already been multiple rollbacks, and this is the first conversation you as a manager are having about them with this report, then you as a manager have already messed up by not addressing the issue sooner.
But that just makes it even more of a problem to lead with language like "quality issues in your code", implying that all the responsibility lies with the report, and none of it lies with you, the manager. The approach I described, where you focus first on the objective fact, that the rollbacks happened, and on how to keep them from happening again, avoids that.
One could say that the scenario as described in the post I originally responded to, by localghost3000, doesn't make sense, yes. If there have already been multiple rollbacks, and this is the first conversation you as a manager are having about them with this report, then you as a manager have already messed up by not addressing the issue sooner.
But that just makes it even more of a problem to lead with language like "quality issues in your code", implying that all the responsibility lies with the report, and none of it lies with you, the manager. The approach I described, where you focus first on the objective fact, that the rollbacks happened, and on how to keep them from happening again, avoids that.
Yeah, code quality is marginally important if whatever QA/UAT process allowed that code to go to production.
If "bad code" can make it to production it's usually the fault of the system as a whole, not the author.
If "bad code" can make it to production it's usually the fault of the system as a whole, not the author.
I have mixed feelings about this.
For the most part, I think "you can't bolt on quality after the fact" is true. Code reviews and CI/CD automated-tests are helpful, but can never be thorough enough to catch every mistake that a low performing developer might make.
If that developer causes enough problems over time, that is absolutely something that their manager can and should address.
For the most part, I think "you can't bolt on quality after the fact" is true. Code reviews and CI/CD automated-tests are helpful, but can never be thorough enough to catch every mistake that a low performing developer might make.
If that developer causes enough problems over time, that is absolutely something that their manager can and should address.
I'd think about actioning the individual only if it was exactly the same issue every time (how did the same issues manage pass time and time again, didn't we learn anything as a team?). Otherwise I'm more in the mentality that breakages are a great way to improve internal flows against (inevitable) failures.
I think the real problem would be when a developer cannot manage to get any code into production (e.g. Code stuck in PR for weeks) but once the rest of the team and our systems approve it then they have proven their worth.
Also, if developer X's code keeps passing code reviews, CI/CD, QA and UAT, and it's not the fault of the systems in place, I would ask myself what kind cutting edge stuff are they working on?
I think the real problem would be when a developer cannot manage to get any code into production (e.g. Code stuck in PR for weeks) but once the rest of the team and our systems approve it then they have proven their worth.
Also, if developer X's code keeps passing code reviews, CI/CD, QA and UAT, and it's not the fault of the systems in place, I would ask myself what kind cutting edge stuff are they working on?
I got the impression that when he says "couple of years" he's talking about the low-end of the word couple. The other thing in the article that jumps out is the conclusion where he says that a team that is shipping and happy is enough to be crushing it.
That isn't really enough in my experience. There are 3 questions - is the team happy? Are they shipping? Is what they are shipping valuable? - and I've seen a lot of new managers are so overwhelmed that they forget about number 3 and a fair chunk of people end up unemployed because sooner or later the bean counters figure out that the team isn't actually productive.
This article, overall, doesn't identify achieving excellent outcomes as something he got wrong at first. I suspect either he is a natural manager or it is a mistake that is still being made. Probably the latter based on the other mistakes identified. The journey I've seen usually goes from lost -> controlling external perceptions of success -> oh I need to actually succeed and it isn't what I thought.
That isn't really enough in my experience. There are 3 questions - is the team happy? Are they shipping? Is what they are shipping valuable? - and I've seen a lot of new managers are so overwhelmed that they forget about number 3 and a fair chunk of people end up unemployed because sooner or later the bean counters figure out that the team isn't actually productive.
This article, overall, doesn't identify achieving excellent outcomes as something he got wrong at first. I suspect either he is a natural manager or it is a mistake that is still being made. Probably the latter based on the other mistakes identified. The journey I've seen usually goes from lost -> controlling external perceptions of success -> oh I need to actually succeed and it isn't what I thought.
> Is what they are shipping valuable?
That’s indeed critical, but most Director-level managers and below have very little control of how well the business model serves the OKRs. Yes the OKRs need to be achieved and help make the business work, but e.g. if the business model’s margins are just too tepid or if the VC’s expected revenue growth (exponential?) will never actually realize, then there is really zero material value to the shipped product. Hence the focus on a happy team that’s shipping, because at least that provides some technological value. And build a network you can bring to your next gig—- because that’s what gets you the next job.
There are rare cases where a team might discover a new business model or impress a whale customer, and then the business model fundamentally changes.
Yes there is risk the “bean counters” or CFO / COO office will want to cut the cord (especially now tech hiring is in a recession). But tech moves fast; those bean counters will likely end up owning shares of a zombie in the next 5-7 years. And their game is to cash out, not build a future.
And if the business model actually works, then keep at those OKRs and everybody should win. Good business models are where stupid can succeed; the team has the right levers.
That’s indeed critical, but most Director-level managers and below have very little control of how well the business model serves the OKRs. Yes the OKRs need to be achieved and help make the business work, but e.g. if the business model’s margins are just too tepid or if the VC’s expected revenue growth (exponential?) will never actually realize, then there is really zero material value to the shipped product. Hence the focus on a happy team that’s shipping, because at least that provides some technological value. And build a network you can bring to your next gig—- because that’s what gets you the next job.
There are rare cases where a team might discover a new business model or impress a whale customer, and then the business model fundamentally changes.
Yes there is risk the “bean counters” or CFO / COO office will want to cut the cord (especially now tech hiring is in a recession). But tech moves fast; those bean counters will likely end up owning shares of a zombie in the next 5-7 years. And their game is to cash out, not build a future.
And if the business model actually works, then keep at those OKRs and everybody should win. Good business models are where stupid can succeed; the team has the right levers.
> I've noticed quality issues in your code recently...
Why is it always the report who is the source of the problem and not the manager?
How about "I've created a toxic work environment and put my reports under a lot of stress. And I have not given them any opportunities to grow and learn new skills. I am planning to do better..." Words that will never come from the mouth of a manager.
Have a hard conversation with yourself first before blaming the reports.
Why is it always the report who is the source of the problem and not the manager?
How about "I've created a toxic work environment and put my reports under a lot of stress. And I have not given them any opportunities to grow and learn new skills. I am planning to do better..." Words that will never come from the mouth of a manager.
Have a hard conversation with yourself first before blaming the reports.
Articles aren't written for reports, or at least the advertising on those articles are directed at the managerial and above level.
Yes, and s/he did actually say:
"Can we talk about how we can address that?"
rather than "Can we talk about what you can stop doing wrong"
(Although maybe does sound a little little bit in that direction?)
Maybe the answer is "Too much stress and deadlines"? And it's the manager's fault?
What's something even more neutral to say, that leaves the possibility that it's the managers "fault" more open?
"Can we talk about how we can address that?"
rather than "Can we talk about what you can stop doing wrong"
(Although maybe does sound a little little bit in that direction?)
Maybe the answer is "Too much stress and deadlines"? And it's the manager's fault?
What's something even more neutral to say, that leaves the possibility that it's the managers "fault" more open?
I have found that company culture has the biggest impact on junior managers. It sets the expectation for them the most because they don’t have any actual ability yet.
Overly empathetic companies end up with terrible junior managers because they can’t have any real direct conversations. Tough and demanding companies I have seen fair much better because no one can hide from tough conversations for too long.
Overly empathetic companies end up with terrible junior managers because they can’t have any real direct conversations. Tough and demanding companies I have seen fair much better because no one can hide from tough conversations for too long.
That's not what empathy means.
I’m meaning in the sense of ‘ruinous empathy’
https://www.radicalcandor.com/faq/what-is-ruinous-empathy/
https://www.radicalcandor.com/faq/what-is-ruinous-empathy/
Thank you for the link. I like saying "confront with compassion" for the upside of empathetic honesty.
[deleted]
100% agree with this. I would say that the other highly likely mistake new managers make is trying to code their way out of problems. It makes sense, right? Previously when you're an IC and a project ran into issues you could just "code harder" and get through it, but that's rarely the right solution when you're a manager and will likely exacerbate the problem itself if you disappear into the trenches trying to code your way through a critical path. Your role is no longer primarily solving coding problems it's solving people problems.
Indeed. Purposefully stay off the critical path! Do coding that helps you keep up with what people are talking about. Not coding that is urgent!
I made that mistake as a new manager by picking up a small but important task in an area I knew well. I thought it would help unblock the team, but I didn't realise I was about to go into three days of back to back meetings. After the third stand-up in a row of reporting zero progress I sheepishly reassigned the ticket to someone else, and didn't make that mistake again.
Refactors, doc fixes, low priority bug fixes, and tech debt are all fair game for managers to pick up. I do think it's important to keep your hand in.
Refactors, doc fixes, low priority bug fixes, and tech debt are all fair game for managers to pick up. I do think it's important to keep your hand in.
If you are not going to add anything technically, you should probably have 20+ reports.
It depends!
"I have noticed you ate brutalizing your subordinates and that has increased quality and output but I know it is not sustainable and the team is going to crash" any ideas how to communicate it are welcome
What's wrong with saying what you typed above verbatim? It is a fairy standard scenario and your wordings probably have been said in one-on-one millions of times.
You need to follow up the sentence with "what's next", since the scenario does not have a simple solution (the manager can tone down the demand, but then output and quality goes back to where is was and we have to deal with that). But now that is more about the work itself rather than communication
That is how I said it, but there was no joint understanding of what I predicted about the future.
Navigating hard conversations is arguably the crucible for new managers
Completely agree. This is excellent advice.
I agree with the sentiment and importance of addressing these things, or dealing with conflicts in-general, but I disagree with the tone somewhat and disagree with the notion that you're not in the trenches with them, but it depends on what trenches means to whoever it's relevant to. I feel like many new managers know they'll need to deal with this, but never developed their abilities prior to being a manager, and don't realize that just because the conversation happens, doesn't mean it produces valuable outcomes, breeds respect, or means anyone will like the way you approached it, or even that you were as vulnerable or honest as you thought you were.
Every manager I've had that used your example quote—almost verbatim—went on to be incredibly passive-aggressive, because they're trying too hard not to actually create conflict, they want to be liked more than they care about the result, they don't have that much innate confidence, or like the author of the article suggested, they want to see the results they would have produced when they were an IC, and haven't yet learned how to guide autonomy and relinquish a certain amount of control. These are perhaps the traits that led them to keeping their IC job all those years.
These people would turn 1-on-1s into 45 mins of beating around the bush, trying to get me to reveal myself as having insufficiently met the unspoken criteria they've been having internal anxiety attacks about, and maybe in the last few minutes when there's no room left for pushback they'd conjure the answer they wanted to hear and set that as the benchmark.
This failure on their part predictibly bled into other interactions and created toxicity and resentment, they couldn't yield control, and they couldn't have a real discussion that involved more than themselves manifesting as their overbearing mother waiting for their kid to implicate themselves for some petty wrongdoing. They couldn't clearly communicate priorities, or timelines, or requirements, and were starting in their new job with a skill issue of their own. They hadn't adapted to the role or developed a good personality for it, and apparently lacked an ability to reflect on their behavior or communication style.
I don't mean to extrapolate too far from this or in-turn attack you in any way, it's just a small quote, but in the past it's been telling.
"Can we talk about code quality issues" doesn't just avoid a character trait, which I agree should should never be the target, it leans into vague, soft, meek, intentionally indirect language that just creates undue anxiety and establishes an ambiguous context for whatever the problem might be, and was a dishonest pretext for for downstream attribution of fault, since they couldn't accept the possibility that the problem might be upstream (which it wasn't always, but if it had been, they weren't going to address it then). In these situations, sometimes I was struggling with purely my own productivity, having a bad couple weeks, but otherwise it was some other issue they weren't willing or able to genuinely help me with.
Do your best to be humble, learn to delegate and try to trust people, avoid thinking about character traits but don't avoid direct (and clear) language, and accept that your perception might be inaccurate. Get as far away as necessary from the dreaded "just checking in" or "is there anything we can do to improve (your problem)" as possible. What if their code is suffering because of noise in the office or someone's depressed because they're having relationship issues? What if it's because you keep coming over to their desk unannounced and asking diverting their attention?
If you can do that, you're on a good track.
Edit: it's worth noting that the underlying assumption in all of my comment is that people and their reasons and issues are often different, and likewise how they respond to this language may be different, and as such many might actually love the quoted phrases because they aren't imposing, and a good manager will do their best to communicate with people in a way that accepts that a variety of ways to address conflict is the right move, and sometimes less imposing language is viable.
Every manager I've had that used your example quote—almost verbatim—went on to be incredibly passive-aggressive, because they're trying too hard not to actually create conflict, they want to be liked more than they care about the result, they don't have that much innate confidence, or like the author of the article suggested, they want to see the results they would have produced when they were an IC, and haven't yet learned how to guide autonomy and relinquish a certain amount of control. These are perhaps the traits that led them to keeping their IC job all those years.
These people would turn 1-on-1s into 45 mins of beating around the bush, trying to get me to reveal myself as having insufficiently met the unspoken criteria they've been having internal anxiety attacks about, and maybe in the last few minutes when there's no room left for pushback they'd conjure the answer they wanted to hear and set that as the benchmark.
This failure on their part predictibly bled into other interactions and created toxicity and resentment, they couldn't yield control, and they couldn't have a real discussion that involved more than themselves manifesting as their overbearing mother waiting for their kid to implicate themselves for some petty wrongdoing. They couldn't clearly communicate priorities, or timelines, or requirements, and were starting in their new job with a skill issue of their own. They hadn't adapted to the role or developed a good personality for it, and apparently lacked an ability to reflect on their behavior or communication style.
I don't mean to extrapolate too far from this or in-turn attack you in any way, it's just a small quote, but in the past it's been telling.
"Can we talk about code quality issues" doesn't just avoid a character trait, which I agree should should never be the target, it leans into vague, soft, meek, intentionally indirect language that just creates undue anxiety and establishes an ambiguous context for whatever the problem might be, and was a dishonest pretext for for downstream attribution of fault, since they couldn't accept the possibility that the problem might be upstream (which it wasn't always, but if it had been, they weren't going to address it then). In these situations, sometimes I was struggling with purely my own productivity, having a bad couple weeks, but otherwise it was some other issue they weren't willing or able to genuinely help me with.
Do your best to be humble, learn to delegate and try to trust people, avoid thinking about character traits but don't avoid direct (and clear) language, and accept that your perception might be inaccurate. Get as far away as necessary from the dreaded "just checking in" or "is there anything we can do to improve (your problem)" as possible. What if their code is suffering because of noise in the office or someone's depressed because they're having relationship issues? What if it's because you keep coming over to their desk unannounced and asking diverting their attention?
If you can do that, you're on a good track.
Edit: it's worth noting that the underlying assumption in all of my comment is that people and their reasons and issues are often different, and likewise how they respond to this language may be different, and as such many might actually love the quoted phrases because they aren't imposing, and a good manager will do their best to communicate with people in a way that accepts that a variety of ways to address conflict is the right move, and sometimes less imposing language is viable.
You’re basically validating my original point if I am reading your comment correctly. You absolutely cannot avoid conflict but there is a right and a wrong way to go about it. Simple, direct feedback that speaks to behaviors not character is very important.
To your point about being in the trenches I think maybe you’re extrapolating too much from that. Any manager who is any good is of course right there alongside their team in said trenches.
To your point about being in the trenches I think maybe you’re extrapolating too much from that. Any manager who is any good is of course right there alongside their team in said trenches.
These are the marks of a passive-aggressive and adversarial manager who would sell their team out from under them.
This is literally the opposite of passive aggressive. That’s my entire point!! You have to be direct with people so the know where they stand. That applies to what they’re doing well on also.
As for the “sell out” statement… I have no idea how you got that out of what I said. Sounds like maybe you had some bad managers?
As for the “sell out” statement… I have no idea how you got that out of what I said. Sounds like maybe you had some bad managers?
That camaraderie should have been built up in the trenches. They must trust you enough to be honest, otherwise they are not your comrades.
If your words and tone sound nice, they can still be mean, doubly so.
If your words and tone sound nice, they can still be mean, doubly so.
Most of these are pretty accurate, but there's good news: giving a sh!t about your people will likely get you 80% of the way to being a good manager. If you genuinely care about them, their work and progression you're already aligned with the key aspects. You can learn & figure out the rest. It might be hard and very unpleasant at times, and stressful, but building the teams that build software is the most rewarding accomplishment of my life.
I will add one too: sometimes you only find out you don't want to be a manager after trying it. Building a lead mentorship program where both management and the individual can live a realistic experience of being a people leader is invaluable. I've implemented this program twice now and it has been great for building leadership capacity with people who are excited to take this path.
I will add one too: sometimes you only find out you don't want to be a manager after trying it. Building a lead mentorship program where both management and the individual can live a realistic experience of being a people leader is invaluable. I've implemented this program twice now and it has been great for building leadership capacity with people who are excited to take this path.
> giving a sh!t about your people
One of the most stand-out moments of leadership I've ever witnessed was my boss protecting me and a colleague from another manager on a different team. He put his foot down and drew a line about what was to be expected of us (among our other competing responsibilities). Fight for me and I'll fight for you.
One of the most stand-out moments of leadership I've ever witnessed was my boss protecting me and a colleague from another manager on a different team. He put his foot down and drew a line about what was to be expected of us (among our other competing responsibilities). Fight for me and I'll fight for you.
I joined a new team as a manager and after 3 years was kindly asked to step down and become an IC. While there are many external factors to blame, I decided to do an honest postmortem with myself so I thought about these things a lot.
As a line manager a huge mistake you could make (especially if you’re joining a new team) is not being technical enough.
You may not write code anymore, but you are expected to know the system very thoroughly, otherwise you’ll be perceived as a glorified babysitter.
As a new manager it’s very easy to fall into the trap of not doing any technical work because you’re a big boy now playing in the big boy league, but this will 100% hurt you.
You need to stay on top of everything your reports are doing. Give them their space but always ask hard questions and dig deep.
Frame it like this: if this report were to quit today, are you able to step in and complete their project? I’m not saying it’s something a manager is supposed to do, but that ultimately YOU are directly responsible for your reports’ work so you should be extremely familiar with it.
As a line manager a huge mistake you could make (especially if you’re joining a new team) is not being technical enough.
You may not write code anymore, but you are expected to know the system very thoroughly, otherwise you’ll be perceived as a glorified babysitter.
As a new manager it’s very easy to fall into the trap of not doing any technical work because you’re a big boy now playing in the big boy league, but this will 100% hurt you.
You need to stay on top of everything your reports are doing. Give them their space but always ask hard questions and dig deep.
Frame it like this: if this report were to quit today, are you able to step in and complete their project? I’m not saying it’s something a manager is supposed to do, but that ultimately YOU are directly responsible for your reports’ work so you should be extremely familiar with it.
I've entered 2 new orgs as an engineering manager, after getting some experience organically. You need to prioritize between lots of things, including technical / people. Usually people is the right choice I've concluded, but the first time my teams were using all new tech for me and I really struggled after over focusing on relationships. The second time I still focused more on people but new the tech better, and forced myself to find time to go through more typical developer onboarding. It was way more successful.
Some of the things you mention sound right for a team lead (i.e. single team) but not really for an EM where you might have 2+ teams. You need to be able to solve the problems the leaving teammates create for you, but stepping into the role is probably the last thing you should do. Don't get me wrong, you need to live the life to build credibility and empathy, but doing the job yourself is usually a substandard, unsustainable solution.
Some of the things you mention sound right for a team lead (i.e. single team) but not really for an EM where you might have 2+ teams. You need to be able to solve the problems the leaving teammates create for you, but stepping into the role is probably the last thing you should do. Don't get me wrong, you need to live the life to build credibility and empathy, but doing the job yourself is usually a substandard, unsustainable solution.
> You may not write code anymore, but you are expected to know the system very thoroughly, otherwise you’ll be perceived as a glorified babysitter.
I think the way "experienced" managers do this is to not actually understand the technical work 100% but rather make your manager think you understand it 100%. Even as an individual contributor, I fail to fully understand all the changes my team is making. I can't imagine being 100% fully up to date with all the changes at are in flight, have landed, etc. and why. The best you can do is some kind of abstraction.
They call this "managing up" or something like that.
I think the way "experienced" managers do this is to not actually understand the technical work 100% but rather make your manager think you understand it 100%. Even as an individual contributor, I fail to fully understand all the changes my team is making. I can't imagine being 100% fully up to date with all the changes at are in flight, have landed, etc. and why. The best you can do is some kind of abstraction.
They call this "managing up" or something like that.
For those sorts of things you need to understand:
- the reason it's happening
- the cost (time / people)
- what else you are deciding not to do instead
You don't have to be in the weeds enough to implement it yourself but you need to guard against both:
- people working on things that aren't priorities because they only want to work on their own pet projects, by not being technical enough to tell when they're BSing about the technical justification for certain things
- people doing things in inefficient or not-aligned-with-future-needs ways because they are more junior and don't know some technical things, or because you haven't shared enough roadmap context
It's related to "managing up" in that it's good to be proactive about sharing some of that info upward as-relevant with your boss so that they don't have to go out of their way to know what's going on with you (or else you run the risk of them having a wrong assumption when they're making decisions that impact you and your reports).
- the reason it's happening
- the cost (time / people)
- what else you are deciding not to do instead
You don't have to be in the weeds enough to implement it yourself but you need to guard against both:
- people working on things that aren't priorities because they only want to work on their own pet projects, by not being technical enough to tell when they're BSing about the technical justification for certain things
- people doing things in inefficient or not-aligned-with-future-needs ways because they are more junior and don't know some technical things, or because you haven't shared enough roadmap context
It's related to "managing up" in that it's good to be proactive about sharing some of that info upward as-relevant with your boss so that they don't have to go out of their way to know what's going on with you (or else you run the risk of them having a wrong assumption when they're making decisions that impact you and your reports).
I’m pretty sure “managing up” refers to the extra work the IC needs to do so that their non-technical manager doesn’t look incompetent to their own manager.
Managing up is just rebranded brown-nosing.
I think it's the direct opposite: A huge part of "managing up" is making your your boss knows what's going on enough to help them make a wrong decision due to being unaware of details you and your reports are aware of. If you're scared of contradicting or correcting them you can't do that.
A huge common mistake for anyone with a boss - at ANY level, IC or management, is assuming their boss knows everything that they know + more things. The intersection of what you know + they know is probably smaller than you think. And so being able to recognize what they will NEED to know in the near future is a valuable skill.
A huge common mistake for anyone with a boss - at ANY level, IC or management, is assuming their boss knows everything that they know + more things. The intersection of what you know + they know is probably smaller than you think. And so being able to recognize what they will NEED to know in the near future is a valuable skill.
> if this report were to quit today, are you able to step in and complete their project?
I’ve had many managers over the years, more and less successful, and this was possible just for one of them. And only because they were promoted to the position from a developer level on that team. They hated being a manager though and left the company promptly.
I’ve had many managers over the years, more and less successful, and this was possible just for one of them. And only because they were promoted to the position from a developer level on that team. They hated being a manager though and left the company promptly.
Turning this person into a manager is a major fail. Typically their only move is to quit, and everyone loses.
I'm an IC on a team full of seniors with strong domain knowledge that recently hired in an EM from the outside. In short, it was pretty bumpy and despite the guy being an ex engineer, his constant questions about how the system works were a huge drag. Maybe to him he was digging deep but to me it felt like my (and my teammates') work was blocked by his inability to grasp simple concepts. Like the time spent explaining could've been spent just fixing the bug.
So I guess with the digging deep thing, be careful to not take up too much of people's time!
So I guess with the digging deep thing, be careful to not take up too much of people's time!
How long are these Q&A sessions, would you say the work of ICs getting blocked isn’t worth having the manager be able to eg: advocate for that work upwards?
We recently had an hour long session in the middle of the day with the entire team dedicated to explaining to the EM what exactly happened during a recent incident (a fairly sophisticated attack - not a simple bug, to be fair). Then next week another hour long session with the entire team AND a hefty handful of other people where EM regurgitated what we had explained to him. Fine I guess, except I'm pretty sure most people in that "retro" meeting already knew way more about what happened than EM did. So ~40 minutes explaining something to people who did not need an explanation.
Sounds annoying. Maybe if he'd asked one person to explain instead of the whole team? How big is the team if I can ask?
> AND a hefty handful of other people where EM regurgitated what we had explained to him.
Is that him trying to show he's doing something useful?
How many people does he manage btw?
> AND a hefty handful of other people where EM regurgitated what we had explained to him.
Is that him trying to show he's doing something useful?
How many people does he manage btw?
The explanation party was maybe 4 or 5 people. The "retro" was 10+ people (almost 20 on calendar but I don't think everyone actually attended).
> Is that him trying to show he's doing something useful?
That is certainly what it looked like to me
> How many people does he manage btw?
About 10.
> Is that him trying to show he's doing something useful?
That is certainly what it looked like to me
> How many people does he manage btw?
About 10.
I wonder if, in this case, 10 is too few, and it'd been better with a technical person and manager at the same time? Maybe everyone manages themselves pretty well?
Tech Lead Manager maybe? But I'm guessing. https://www.developing.dev/p/tech-lead-manager-tlm-roles
Tech Lead Manager maybe? But I'm guessing. https://www.developing.dev/p/tech-lead-manager-tlm-roles
What’s wrong with taking “too much” peoples time? I mean, it’s a colleague, asking questions… it’s not that you are going to work more because you’re allocating time to help others.
Partly answered here: https://news.ycombinator.com/item?id=42356687
Having full knowledge of the work is not the same thing as full knowledge of the system. Being able to step in to do the work of one of your people is one possible way to provide a safety net for the bus factor, yes. But not the only way, and I'd argue it is not the best way.
This is your team - you are managing them, not the other way around, so if they have expectations of you that are incorrect, then fix those expectations. If you are not technical, tell them so. Communicate your needs and expectations, and then let them do the work. If there is a bus factor that is too high of a risk for a sustainable team, cross-train the team to remove the bus factor. Have a sense of the priority of all the work so that if someone quits, you can re-arrange the schedule, not be forced to jump in and put out a fire.
At the same time, be building up your people so that they can jump in and replace you. After all, if you cannot be replaced, you cannot be promoted either. Don't pigeon-hole yourself into a front-line manager role unless you truly love it. Grow your team, but grow yourself at the same time.
This is your team - you are managing them, not the other way around, so if they have expectations of you that are incorrect, then fix those expectations. If you are not technical, tell them so. Communicate your needs and expectations, and then let them do the work. If there is a bus factor that is too high of a risk for a sustainable team, cross-train the team to remove the bus factor. Have a sense of the priority of all the work so that if someone quits, you can re-arrange the schedule, not be forced to jump in and put out a fire.
At the same time, be building up your people so that they can jump in and replace you. After all, if you cannot be replaced, you cannot be promoted either. Don't pigeon-hole yourself into a front-line manager role unless you truly love it. Grow your team, but grow yourself at the same time.
> if this report were to quit today, are you able to step in and complete their project?
I don't think that's the main goal for a manager (even technical). I'd say generally, the manager should understand why the team is building something, and the engineers should know how. The why includes who is going to use what was built, when do they need it, what trade-offs can be made, etc.
I don't think that's the main goal for a manager (even technical). I'd say generally, the manager should understand why the team is building something, and the engineers should know how. The why includes who is going to use what was built, when do they need it, what trade-offs can be made, etc.
IMO, if I have to choose between managers that are technical “enough” and glorified babysitters, I go for the latter. Little knowledge is dangerous and causes more pain than help. At least glorified babysitters know that they don’t know enough and leave all the important tech decisions to the devs; that’s relieving.
That’s the team leads job. The manager’s job is to manage the people. You are a babysitter or more akin to a teacher that has to stay out of the way of the kids doing things well and prevent the bad kids from ruining the class for everyone.
Not at all. I mean for a small team where you are or expected to perform as TLM yes. But generally speaking no.
I can't read the article to tell if this is just an observation from you, or if you are responding to the article, because my DNS just broke for whatever reason.
> Frame it like this: if this report were to quit today, are you able to step in and complete their project?
That is not the manager's job. The real question here is, do you know the bus factor of your team and do you know what particular skills are most critical to replace?
I can't read the article to tell if this is just an observation from you, or if you are responding to the article, because my DNS just broke for whatever reason.
> Frame it like this: if this report were to quit today, are you able to step in and complete their project?
That is not the manager's job. The real question here is, do you know the bus factor of your team and do you know what particular skills are most critical to replace?
The way to see this is that we’re all individual contributors, from the janitor to the CEO. Because if you’re not an individual, then what are you? And if you’re not contributing, then what are you doing there? When you manage a project or team, you’re just individually contributing in a different (though usually overlapping) way.
Also, it’s helpful to remember, when delegating, that one reason you’re probably managing is that you either have tired of running your brain in fifth gear or, at your age, can’t. So the way you contribute is, in general, by applying the hard-won lessons gleaned from your time on the brain-speed freeway while letting others, whose brains naturally run faster, either because of youth or disposition, do the fast-brain work.
Personally, I don’t generally enjoy managing in part because brain speed, which I value, seems to slow further because of the nature of manager or executive work. When I’ve gotten a taste of management and spent time on calls with other managers and executives, I was shocked to discover how slowly (and often haphazardly) they thought through problems that were quite understandable in an instant or two spent alone. They were all very smart people, and yet the managing—or, more likely, the group settings of meetings and calls—seemed to trap their mind, eventually habitually, in a socially constructed box from which they couldn’t escape.
Also, it’s helpful to remember, when delegating, that one reason you’re probably managing is that you either have tired of running your brain in fifth gear or, at your age, can’t. So the way you contribute is, in general, by applying the hard-won lessons gleaned from your time on the brain-speed freeway while letting others, whose brains naturally run faster, either because of youth or disposition, do the fast-brain work.
Personally, I don’t generally enjoy managing in part because brain speed, which I value, seems to slow further because of the nature of manager or executive work. When I’ve gotten a taste of management and spent time on calls with other managers and executives, I was shocked to discover how slowly (and often haphazardly) they thought through problems that were quite understandable in an instant or two spent alone. They were all very smart people, and yet the managing—or, more likely, the group settings of meetings and calls—seemed to trap their mind, eventually habitually, in a socially constructed box from which they couldn’t escape.
They are taking so many more factors into account that you don't see. It's like a junior engineer saying, why not just bang out the code? You're missing all the long term impact.
I hate the term IC. Its often used in a semi-derogatory context.
Ah, I was wondering what was going on with my brain since I became a manager.
Seriously though, I've known some people who are managers and extremely fast/strong thinkers. Yes, the nature of the job requires more of the big picture and less of the details.
Ah, I was wondering what was going on with my brain since I became a manager.
Seriously though, I've known some people who are managers and extremely fast/strong thinkers. Yes, the nature of the job requires more of the big picture and less of the details.
In what context is IC every used in any derogatory fashion? In my experience "Manager" or "People Leader" is far far more derogatory.
It implies the persons' leverage is limited to only what they personally do. That's obviously false. A non-manager engineer can have broad scope in putting in a proper architecture, in mentoring others, in cross-team communications. I would go as far as saying there's virtually no engineer whose impact is limited to themselves. They have a harder job since they need to affect change without having official authority to affect change.
The term's very existence it puts people in a certain bin. Why is a CEO not also an "individual contributor"? They're an individual. They contribute. It's just newspeak.
I've never thought of management positions in an organization to reflect something derogatory. But maybe to some.
The term's very existence it puts people in a certain bin. Why is a CEO not also an "individual contributor"? They're an individual. They contribute. It's just newspeak.
I've never thought of management positions in an organization to reflect something derogatory. But maybe to some.
What's a better word than IC? :-)
> The way to see this is that we’re all individual contributors, from the janitor to the CEO. Because if you’re not an individual, then what are you? And if you’re not contributing, then what are you doing there? When you manage a project or team, you’re just individually contributing in a different (though usually overlapping) way.
The difference is in how your performance is judged. ICs are judged by their individual contributions, hence the name. Managers are judged by the performance of their team/department/organization/company. It's not enough to say, as a manager, "I personally ran the sprint meetings and did 1:1s and performance reviews so therefore I'm doing a good job."
The individual work managers do is much harder to tangibly measure. Things like establishing a culture, balancing your roadmap between one-off customer requests and internal production vision (and hacking in some AI crap to make your CEO happy), hiring the right people. Just doing the table stakes individual work of managing your direct reports' vacation time, promotions, and running team meetings is really only good enough for beginner, first-level line managers at bigger companies, where they just need people to execute established processes.
> Also, it’s helpful to remember, when delegating, that one reason you’re probably managing is that you either have tired of running your brain in fifth gear or, at your age, can’t.
ehhhhh. Management is a lot more reactive, that's true, but saying it requires less brainpower isn't true. As a manager you're constantly context switching. You don't just care about the codebase and solving one specific problem, you also care about sales and marketing, your customer support team, the budget for next year. You're getting slack messages from executives who need an update right now on your project, at the same time as an engineer needing to talk because their partner just filed for divorce and they need mental health days (and you need to support them while also figuring out how to rebalance their workload). It's a very different way of working that uses very different parts of your brain. But it's not just sitting in the executive bathroom and delegating work while you smoke a cigar.
The difference is in how your performance is judged. ICs are judged by their individual contributions, hence the name. Managers are judged by the performance of their team/department/organization/company. It's not enough to say, as a manager, "I personally ran the sprint meetings and did 1:1s and performance reviews so therefore I'm doing a good job."
The individual work managers do is much harder to tangibly measure. Things like establishing a culture, balancing your roadmap between one-off customer requests and internal production vision (and hacking in some AI crap to make your CEO happy), hiring the right people. Just doing the table stakes individual work of managing your direct reports' vacation time, promotions, and running team meetings is really only good enough for beginner, first-level line managers at bigger companies, where they just need people to execute established processes.
> Also, it’s helpful to remember, when delegating, that one reason you’re probably managing is that you either have tired of running your brain in fifth gear or, at your age, can’t.
ehhhhh. Management is a lot more reactive, that's true, but saying it requires less brainpower isn't true. As a manager you're constantly context switching. You don't just care about the codebase and solving one specific problem, you also care about sales and marketing, your customer support team, the budget for next year. You're getting slack messages from executives who need an update right now on your project, at the same time as an engineer needing to talk because their partner just filed for divorce and they need mental health days (and you need to support them while also figuring out how to rebalance their workload). It's a very different way of working that uses very different parts of your brain. But it's not just sitting in the executive bathroom and delegating work while you smoke a cigar.
Management might feel frustrating to those who thrive on fast, solitary problem-solving
Delegation -> This is 1000% the hardest thing to do. You need to let go and trust your people.
Where’s my dopamine? -> Your success is the teams' success. When they are doing well, you are doing well.
Quality over quantity -> Yes.
The level of engagement -> Your job is to support the team - blockers are your problem, not their problem. Fight to remove blockers. That's your job.
Managing perception -> Which leads into, your role, well done, is invisible. Protect them from the bullshit politics that any org has and let them do what they do well.
Redefining success -> That's up to you and your manager. If you're a new manager, you need to manage across and up. That's a set of skills that we don't train people for.
You're coming from an IC position and you know how to do the work. Managing people is a different job,
Where’s my dopamine? -> Your success is the teams' success. When they are doing well, you are doing well.
Quality over quantity -> Yes.
The level of engagement -> Your job is to support the team - blockers are your problem, not their problem. Fight to remove blockers. That's your job.
Managing perception -> Which leads into, your role, well done, is invisible. Protect them from the bullshit politics that any org has and let them do what they do well.
Redefining success -> That's up to you and your manager. If you're a new manager, you need to manage across and up. That's a set of skills that we don't train people for.
You're coming from an IC position and you know how to do the work. Managing people is a different job,
>The level of engagement -> Your job is to support the team - blockers are your problem, not their problem. Fight to remove blockers. That's your job.
The best managers I've ever had saw it as their job to remove barriers and bullshit from my day. It's what I try to do as a leader as well. It serves the purpose of making their jobs easier, and also takes up your time which creates less opportunity for you to micromanage and forces you to delegate.
>Managing perception -> Which leads into, your role, well done, is invisible. Protect them from the bullshit politics that any org has and let them do what they do well.
This is SO important, and where I struggle the most. Your team won't appreciate it, but when they have the time, support, and resources they need, they'll notice.
The best managers I've ever had saw it as their job to remove barriers and bullshit from my day. It's what I try to do as a leader as well. It serves the purpose of making their jobs easier, and also takes up your time which creates less opportunity for you to micromanage and forces you to delegate.
>Managing perception -> Which leads into, your role, well done, is invisible. Protect them from the bullshit politics that any org has and let them do what they do well.
This is SO important, and where I struggle the most. Your team won't appreciate it, but when they have the time, support, and resources they need, they'll notice.
Where’s my dopamine? -> Your success is the teams' success. When they are doing well, you are doing well.
It's hard to get a dopamine hit of a second-order signal though. When you're a developer there's a strong linkage between the work you complete and results. If you write code for a new feature, you get to see it take shape on your screen. When your team reaches a milestone, you see where you contributed and can often quantify your contributions.What happens after you move into management? Your day-to-day is no longer filled with relatively concrete tasks and goals. Your role is not to do the work yourself but guide and support a team doing the actual execution. How do you measure that?
It's hard to get a dopamine hit of a second-order signal though. When you're a developer there's a strong linkage between the work you complete and results. If you write code for a new feature, you get to see it take shape on your screen. When your team reaches a milestone, you see where you contributed and can often quantify your contributions.What happens after you move into management? Your day-to-day is no longer filled with relatively concrete tasks and goals. Your role is not to do the work yourself but guide and support a team doing the actual execution. How do you measure that?
Agreed. "Where's my dopamine" is the right way to describe it. As an IC I could find a bug, craft a test that reproduces it, write a fix, see the test go green, see the PR get approved and land... I'd get a little dopamine ping at each step. As a manager I'd have days where I had constructive 1:1s in the morning and maybe made a decision on some strategic or resourcing problem in an afternoon meeting. Of course I recognised that the work was not only valuable, but higher impact than just fixing a bug. But the direct hit in the pleasure receptors just wasn't there. I'd finish a day a like that and instead of feeling happy with my work, I'd just feel exhausted and not looking forward to the next day.
After a few years as a manager I switched back to the IC track. I sometimes wonder if my experience means I'm just hard-wired to be an IC, or if with more time and practice you can train yourself to get the dopamine feedback from management activities.
After a few years as a manager I switched back to the IC track. I sometimes wonder if my experience means I'm just hard-wired to be an IC, or if with more time and practice you can train yourself to get the dopamine feedback from management activities.
I'm still getting dopamine off getting a team member promoted, two years later. Every success they make reminds me that I helped them build that confidence and those skills. Manager-side successes might not be obvious and daily, but they have staying power like you wouldn't believe.
Delegation was one I struggled with a lot in the early days. Even as the CEO, I was reluctant to give up my customer service responsibilities of manning the inboxes. Eventually, I understand that even if someone handled it only 80-90% as well, that would be much better for the company than having me do it.
Delegation is so hard, i struggle constantly and I'm technically a "Sr. Manager". When the project is up against deadline pressure, it's so tempting to do something yourself that only takes you a day vs delegating to someone else and they spin on it for 3 and screw it up at the end anyway. Inevitably you become the bottleneck when a wave of escalations or other management tasks come down the pipe but there's a pile of actual work you decided to take on yourself half done too.
> vs delegating to someone else and they spin on it for 3 and screw it up at the end anyway.
If that is happening more than twice in a 6 month period you need to do a post-mortem on your management style, something is wrong. Spinning on a task is already a bad sign pointing at a problem that can be solved at the management level.
If that is happening more than twice in a 6 month period you need to do a post-mortem on your management style, something is wrong. Spinning on a task is already a bad sign pointing at a problem that can be solved at the management level.
I moved up to Director this year, and explicitly called out that if I needed to give up any more direct interaction with ICs and "contact time" with the real builders I had probably topped out. I've mitigated this a lot with an awesome team of leads and managers, and a (hopefully good kind of) lazy, non-prescriptive management style.
Sounds like there are some fundamental process/team issues going on. If a team cannot be trusted to deliver, superman always coming in to save the day shouldn't be the solution.
I’ve got a good hack for the dopamine: PowerPoint and excel. Go to town on making kick ass presentations and reports. “Ship” those to the org during meetings and all hands. It’s not the same as code for customers, but it helps. Also, if you have time, code non critical things that will never be a dependency for anything else.
Agreed, my go to when feeling like I haven't produced real work in awhile is to document processes, especially if there is something I've noticed has been done poorly or been asked about a couple times recently.
I build internal tools, do BS support requests and push little initiatives that align with my core values. Like get a dozen people in-person for a technical watch party - cheap, easy, super rewarding.
It is cynical, but quality over quantity is bad advice if you want to grow your career as a manager. It's a real failure mode. Not being aggressive about growing your headcount will hold you back. Pretty much all managers are evaluated on amount of headcount when it comes to promotions, especially if you're not tied to P&L.
[deleted]
> For over a decade, my dopamine (from work) came from a very predictable place: shipping new things. As a manager, those direct rewards will simply disappear, leaving you feeling unfulfilled for weeks (months in my case).
Your job as a manager is still to ship things -- only now it's to ship more than you ever could alone. You get the privilege and responsibility to steward the skills of two or more engineers and shape the entire part of a business. The dopamine is harder won and often more rewarding. Management is difficult and exhausting but it's anything but unfulfilling. Let's not start new managers off telling them what they can't do but what they can do.
Ironically, as a manager of software engineers you should still be very engaged with the team's code. How else will you understand your capacity and understand what gaps you need to fill? Run the test suite, review designs, read PRs, ask questions, give praise for attention to detail. You will keep the bar high on the team and advocate for their work more effectively within the organization.
Your job as a manager is still to ship things -- only now it's to ship more than you ever could alone. You get the privilege and responsibility to steward the skills of two or more engineers and shape the entire part of a business. The dopamine is harder won and often more rewarding. Management is difficult and exhausting but it's anything but unfulfilling. Let's not start new managers off telling them what they can't do but what they can do.
Ironically, as a manager of software engineers you should still be very engaged with the team's code. How else will you understand your capacity and understand what gaps you need to fill? Run the test suite, review designs, read PRs, ask questions, give praise for attention to detail. You will keep the bar high on the team and advocate for their work more effectively within the organization.
> "Where’s my dopamine?"
I'm not in management, but couldn't OP become a working manager? Might depend on the size of their team and demands of the new role, but I've worked with managers who wear their IC hat on occasion and thought it was a positive value-add for the group as a whole.
I'm not in management, but couldn't OP become a working manager? Might depend on the size of their team and demands of the new role, but I've worked with managers who wear their IC hat on occasion and thought it was a positive value-add for the group as a whole.
Every manager I've ever had that couldn't let go of their IC hat also had a pile of manager hat work that wasn't ever getting done.
What sort of manager work was ignored?
For small teams (like, 5 people max) that may make sense. It really depends on the organization. With some orgs, you're going to meetings all day and there's no time to focus.
for these IC/leaders a big mistake is taking on critical path work, then blocking everyone else.
This is generally a bad idea. I never know when I'm going to get pulled into something that will take my attention away from the task. The only times I really do that anymore is if the task is not time critical or if it is something that I know I could be picked up by others in any state without any issue.
For team leads, yes - to some degree. It is really hard to get the balance right, and even harder to step out of one of those worlds as your responsibilities grow.
> As an individual contributor (IC), your work spoke for itself; people could easily see it. Plain and simple. As a manager, it’s less black and white, and surprisingly, for many new managers, part of your job now involves managing how others see you.
This doesn't only apply to managers. Even as an individual software engineer, the more you move up (if moving up is something that matters to you), the more you have to play politics.
Your work can't possibly "speak for itself", since the people it's speaking to (the managers with power over your career) don't speak code.
This doesn't only apply to managers. Even as an individual software engineer, the more you move up (if moving up is something that matters to you), the more you have to play politics.
Your work can't possibly "speak for itself", since the people it's speaking to (the managers with power over your career) don't speak code.
"Is my team shipping? Are they happy?" is a simple yet powerful metric for success. If more managers internalized this, I suspect we’d see healthier teams and better products.
As a (former) manager of a department in a design school, I defined three managerial imperatives:
1. Get rid of old, dead wood. Given that our program is scaffolded, with each course building upon the preceding, A single low performing lecturer can bring down the quality of an entire program. Don’t trust student feedback when identifying such people. They favour nice lecturers over effective ones. Getting rid of low performing team members in a university can be a low process. It can sometimes be quicker to find programs they would be happier/more productive in, and engineer a transfer.
2. Hire effective new blood. Well duh, I hear you say. Finding good new hires can be a difficult task. For those who I really wanted to hire, I did my research on who they were and what they might want, and tried to show them that I was willing to build a nest for them.
3. Have a vision of what the department should be. This vision requires constant maintenance and should always consider input from the team.
1. Get rid of old, dead wood. Given that our program is scaffolded, with each course building upon the preceding, A single low performing lecturer can bring down the quality of an entire program. Don’t trust student feedback when identifying such people. They favour nice lecturers over effective ones. Getting rid of low performing team members in a university can be a low process. It can sometimes be quicker to find programs they would be happier/more productive in, and engineer a transfer.
2. Hire effective new blood. Well duh, I hear you say. Finding good new hires can be a difficult task. For those who I really wanted to hire, I did my research on who they were and what they might want, and tried to show them that I was willing to build a nest for them.
3. Have a vision of what the department should be. This vision requires constant maintenance and should always consider input from the team.
#2 is considered taboo, but IMO if a team is full of people who are checked out, it may be time to make huge changes.
People become jaded and start to tell you all the ways we can't do something, or it will take too long. They often don't realize what tools are at their disposal to help make change easier, and instead insist there is only one good path to a solution...
Fresh talent really helps get people excited again, after the initial shock of layoffs. Not to mention new talent always comes in excited for an opportunity.
People become jaded and start to tell you all the ways we can't do something, or it will take too long. They often don't realize what tools are at their disposal to help make change easier, and instead insist there is only one good path to a solution...
Fresh talent really helps get people excited again, after the initial shock of layoffs. Not to mention new talent always comes in excited for an opportunity.
On "Where’s my dopamine?", while I'm not a manager but just a tech lead, so still working as an IC for most of the time, I do get satisfaction from eliminating repetitive work for people in my team and optimizing process.
It's great to be able to tell your teammates that the meeting is canceled because you just sent an email explaining that you prepared everything for next sprint and here's a 5 lines summary.
It's great to be able to tell your teammates that the meeting is canceled because you just sent an email explaining that you prepared everything for next sprint and here's a 5 lines summary.
I’ve been an IC, a manager, a CEO and now even an IC again. This advice is all really sound and easily digestible. Many thanks to the author for sharing it.
[deleted]
Another mistake: Thinking your former coworkers are still your friends.
I don't agree. Trust allows for a lot of things to go a lot smoother. Sure, good friendships can end, but one can also be honest with good friends.
What are you supposed to do when your manager has terrible and/or selective memory? My last manager would assign me work and then promptly forget half the time what he assigned me. It was bizarre. Sometimes it worked in my favour because I would do something he assigned me - then show him - and then he would sing praises for my "self initiative" and creativity. Like dude, you told me to do this. Of course this sort of amnesia will eventually come back to bite you when you are yelled at because "why are you working on Y?? you should be working on Z!!". Dude you told me to work on "Y" two days ago.
I never understood whose blame the poor memory falls on? In my opinion it was on him to stay organized - something he never made an effort to do. Others would say it was on me to communicate to him what he told me. I don't get paid enough to be his executive assistant. And I don't see the point in communicating better if he would just forget again.
Other times his memory was bizzare. Like he would remember some off comment I'd made to him in a 1-on-1 and then use it as a way to butter me up or appeal to me. I once mentioned to him I follow news in the "programming space" (aka reading this website). And he seemed to remember this whenever he needed to appeal to me to look into some new platform feature clients were requesting. "You read a lot about this stuff right??? Take a look into PDF generation using this library. You read a lot about this stuff right??" I think he thought he was juicing up my ego with this. So bizzare.
Of course its the same manager who did the fundamental sin of complaining downwards to me, and about my peers whenever one of them messed up. Dude you're the CTO. If you can't maintain face then I will lose all confidence in your ability.
OK I'm going to stop venting about my last boss now. Sorry!
I never understood whose blame the poor memory falls on? In my opinion it was on him to stay organized - something he never made an effort to do. Others would say it was on me to communicate to him what he told me. I don't get paid enough to be his executive assistant. And I don't see the point in communicating better if he would just forget again.
Other times his memory was bizzare. Like he would remember some off comment I'd made to him in a 1-on-1 and then use it as a way to butter me up or appeal to me. I once mentioned to him I follow news in the "programming space" (aka reading this website). And he seemed to remember this whenever he needed to appeal to me to look into some new platform feature clients were requesting. "You read a lot about this stuff right??? Take a look into PDF generation using this library. You read a lot about this stuff right??" I think he thought he was juicing up my ego with this. So bizzare.
Of course its the same manager who did the fundamental sin of complaining downwards to me, and about my peers whenever one of them messed up. Dude you're the CTO. If you can't maintain face then I will lose all confidence in your ability.
OK I'm going to stop venting about my last boss now. Sorry!
About the poor memory stuff, just get it in writing. “In writing“ could mean in an email, or a chat, or more likely in an issue tracker that has an audit log. When there’s a discrepancy, just link to where it was written down.
Just write the daily standup in a list, and keep this list. It will be succint and task-level.
It's important to know exactly what you are managing: a team? a project? a service? a product? "Engineering manager" is an ambiguous term here.
The worst is having a manager who thinks he's great, but is actually disloyal and shit. Not sure how best to deal with that situation other than to ignore and eventually move on... If they'd be willing to admit their failing and improve, that would be awesome. Asking for a friend.
New era manager mistake. Ask ChatGPT about time estimates and pretend you know that because you are an expert, then use that to micromanage people. Mistake is a nice word. I consider that to be pure evil
Reading the comments here just makes me feel like managers are useless. This role doesn't have to exist. It's just fluff.
I worked at a company that emulated Valve’s hyper-flat structure on their engineering team, with 1 manager having 50 direct reports. That’s as close to a management-less structure as I can think of, since your manager can’t attend meetings or do 1:1s anymore.
It’s great at the beginning. We started with a team of mostly self-motivated people and the lack of upward review made technical decision-making easy.
Eventually, you hire someone who is not self motivated. Also, some existing people get wise to the fact that no one will check up on them, and read Reddit for half the day.
About 4 months in, every team had 1 person like that. They had to work around them - one team can’t ever get designs cause the designer is checked out, one team’s backend work takes 1.5x as long as everyone else.
People say things to the underperformers, but there’s no teeth to anything, no one is anyone’s manager, so it’s just suggestions. They get ignored. Resentment builds into each individual team’s culture. Deadlines start slipping.
1 year in, non technical leadership is fed up. They don’t see benefits from the flat structure, and hire a new CTO and new middle management layer.
The new managers come in briefed with “the team is lazy.” The underperformers get pushed out, and have trouble finding work because their skills have absolutely atrophied. Any remaining high performers are permanently tarred with the reputation of the org from the flat structure days, and get micromanaged. To the new managers, they are kids who will misbehave the second they aren’t watched (which, in fairness, is kinda what happened at the organizational level when they weren’t watched.)
Sone good middle management providing timely oversight and feedback could’ve avoided the whole situation.
It’s great at the beginning. We started with a team of mostly self-motivated people and the lack of upward review made technical decision-making easy.
Eventually, you hire someone who is not self motivated. Also, some existing people get wise to the fact that no one will check up on them, and read Reddit for half the day.
About 4 months in, every team had 1 person like that. They had to work around them - one team can’t ever get designs cause the designer is checked out, one team’s backend work takes 1.5x as long as everyone else.
People say things to the underperformers, but there’s no teeth to anything, no one is anyone’s manager, so it’s just suggestions. They get ignored. Resentment builds into each individual team’s culture. Deadlines start slipping.
1 year in, non technical leadership is fed up. They don’t see benefits from the flat structure, and hire a new CTO and new middle management layer.
The new managers come in briefed with “the team is lazy.” The underperformers get pushed out, and have trouble finding work because their skills have absolutely atrophied. Any remaining high performers are permanently tarred with the reputation of the org from the flat structure days, and get micromanaged. To the new managers, they are kids who will misbehave the second they aren’t watched (which, in fairness, is kinda what happened at the organizational level when they weren’t watched.)
Sone good middle management providing timely oversight and feedback could’ve avoided the whole situation.
I have an opposite experience in one of my last gigs where hired management batted 50% mishire rate where people just didn’t do anything at all or worse shipped something that needn't to even exist of quality so bad that the project had to be scrapped. This was allowed to drag on for years.
Last I heard he eventually got rid of most of them when the company fell on hard times and had to do a bunch of layoffs. By that point the damage was already done and most good people have left or quite quit.
Imo it’s a common misconception that management doesn’t know who low performers are. In most cases they know even if the team is large, they just choose to ignore it for whatever political reasons
Last I heard he eventually got rid of most of them when the company fell on hard times and had to do a bunch of layoffs. By that point the damage was already done and most good people have left or quite quit.
Imo it’s a common misconception that management doesn’t know who low performers are. In most cases they know even if the team is large, they just choose to ignore it for whatever political reasons
I find it hard to take anything seriously where "imposter syndrom" is mentioned. That said, I think having full time managers at all is a mistake. This was discussed in detail in this podcast: https://37signals.com/podcast/everybody-works/
"Mistakes I made as a new manager which you won't necessarily make because all humans are different"
Everyone is different, yes, but people are >99% similar. We all go through the same developmental stages, perhaps at different times, and we exhibit millions of the same psychological biases.
The mistakes are common. Almost tropes.
It would be like golf swing or skiing mistakes. Every instructor knows em.
It would be like golf swing or skiing mistakes. Every instructor knows em.
List is toi short. I’d add: Posture.
Everyone wants to be the benevolent manager, especially if there is enough money for everyone, and especially in these times where collaboration and positive management are touted. But you have to keep a carrot and a leash on the employees.
My first employees got a 33% raise the first year things were good. Long story short: None of them are here anymore and we’re still scrambling to recover from the mess they’ve created by being lazy.
Now people struggle to get a few percent salary increase. It eats me to my core, but I want them to get my product out.
Everyone wants to be the benevolent manager, especially if there is enough money for everyone, and especially in these times where collaboration and positive management are touted. But you have to keep a carrot and a leash on the employees.
My first employees got a 33% raise the first year things were good. Long story short: None of them are here anymore and we’re still scrambling to recover from the mess they’ve created by being lazy.
Now people struggle to get a few percent salary increase. It eats me to my core, but I want them to get my product out.
I have to admit I initially hired a few Papered Posers, and it was a mistake to pay them 2.4x higher than market rate to ensure the project would reach conclusion on schedule.
The lessons we learned:
1. "Manage or be managed...": your first lesson is people will try to manipulate those in positions of authority regardless of competency. i.e. the idea of "goodwill" being the true core product can escape the irrationally ambitious/sycophantic.
2. No amount of money can make someone care about company projects. The worker may be interested in the project, or is simply there for the wrong reasons. Remember you want to keep employees content, but a "kingdom of kings" is unsustainable.
3. People can postpone something until tomorrow indefinitely. Thus, pay very close attention to projected deliverable times.
4. Fire someone for being unproductive according to a defined workmanship-standard as soon as possible. It will notify the rest of staff you are not there to play games, and stupid behavior will have consequences. Mostly effective with Jr staff using ChatGPT to try and BS the world like any other con.
5. Delegation? Just initially run trial contracts with potential staff first for each project deliverable. Failure to deliver on time means they don't get another dime, or a second chance to be unaccountable for their behavior.
6. Entrenched incompetence: organizations have their own emergent structure, and it will usually drift back to the same dysfunctional patterns/designs.
7. Redacted
8. try to leave things slightly better than when you arrived.
9. Managers usually can never be a normal employee again. People subconsciously fear they cannot control authority, and will prefer to hire someone easier to "handle".
Best regards, =3
The lessons we learned:
1. "Manage or be managed...": your first lesson is people will try to manipulate those in positions of authority regardless of competency. i.e. the idea of "goodwill" being the true core product can escape the irrationally ambitious/sycophantic.
2. No amount of money can make someone care about company projects. The worker may be interested in the project, or is simply there for the wrong reasons. Remember you want to keep employees content, but a "kingdom of kings" is unsustainable.
3. People can postpone something until tomorrow indefinitely. Thus, pay very close attention to projected deliverable times.
4. Fire someone for being unproductive according to a defined workmanship-standard as soon as possible. It will notify the rest of staff you are not there to play games, and stupid behavior will have consequences. Mostly effective with Jr staff using ChatGPT to try and BS the world like any other con.
5. Delegation? Just initially run trial contracts with potential staff first for each project deliverable. Failure to deliver on time means they don't get another dime, or a second chance to be unaccountable for their behavior.
6. Entrenched incompetence: organizations have their own emergent structure, and it will usually drift back to the same dysfunctional patterns/designs.
7. Redacted
8. try to leave things slightly better than when you arrived.
9. Managers usually can never be a normal employee again. People subconsciously fear they cannot control authority, and will prefer to hire someone easier to "handle".
Best regards, =3
You may wish to talk to someone to evaluate whether the company you work for might be completely dysfunctional-- none of that list sounds like it's coming from a healthy place.
> 9. Managers usually can never be a normal employee again. People subconsciously fear they cannot control authority, and will prefer to hire someone easier to "handle".
This is usually not the case at a FAANG, for whatever it's worth. Multiple people I know have voluntarily moved back to IC from management positions. It's not that unusual for senior devs to try managing and figure out that they don't like it (whether or not they're good at it) and then move back into being a highly regarded IC.
> 9. Managers usually can never be a normal employee again. People subconsciously fear they cannot control authority, and will prefer to hire someone easier to "handle".
This is usually not the case at a FAANG, for whatever it's worth. Multiple people I know have voluntarily moved back to IC from management positions. It's not that unusual for senior devs to try managing and figure out that they don't like it (whether or not they're good at it) and then move back into being a highly regarded IC.
My personal experience with titles has always been complicated.
By the time a corporation has reached FAANG scale, they become boring and ultimately immutable out of necessity. I find it sad many folks dream of joining that drudgery, inventing nothing, and gambling on asinine business plans. =3
By the time a corporation has reached FAANG scale, they become boring and ultimately immutable out of necessity. I find it sad many folks dream of joining that drudgery, inventing nothing, and gambling on asinine business plans. =3
Hi,
I’m coming here a few days later and I would like to thank you for the feedback and reflection. My impression is there are two styles:
- Restless: Hire and fire as fast as possible until you work with the right people, be tough. Could be positive if you can spell out the rules of success very clearly, with 100% reliability.
- Patience: Hire and train until people fulfill your needs. Run the risk of charlatans. Sometimes even good people end up slacking off because they aren’t motivated by the trust and the absence of the carrot and the stick. But you have the satisfaction of caring about people’s wellbeing. Which they most probably abuse, and they’re probably not even happy in this situation.
It’s Christmas so I’m having hard times firing 2 non-performing people who may just happen to need more time to ramp up than I estimate. January’s coming up soon.
I’m coming here a few days later and I would like to thank you for the feedback and reflection. My impression is there are two styles:
- Restless: Hire and fire as fast as possible until you work with the right people, be tough. Could be positive if you can spell out the rules of success very clearly, with 100% reliability.
- Patience: Hire and train until people fulfill your needs. Run the risk of charlatans. Sometimes even good people end up slacking off because they aren’t motivated by the trust and the absence of the carrot and the stick. But you have the satisfaction of caring about people’s wellbeing. Which they most probably abuse, and they’re probably not even happy in this situation.
It’s Christmas so I’m having hard times firing 2 non-performing people who may just happen to need more time to ramp up than I estimate. January’s coming up soon.
Indeed, often it is a tough call, but sometimes even the best talent cannot overcome the inertia of seniority. I have witnessed folks:
* deploy the wrong stack due to existing team skill issues, than the maintenance sinks time and resources away from the project
* hit unclear project goals leading to constant distractions, and entrenched policies dominate design back into garbage
* have informal testing in random situations developers never get to see
* break the testing repeatability loop, so bugs never get properly resolved
If one only has 2 staff left, than they are likely doing 8 jobs 8 times less efficient than one expects.
Best of luck =3
* deploy the wrong stack due to existing team skill issues, than the maintenance sinks time and resources away from the project
* hit unclear project goals leading to constant distractions, and entrenched policies dominate design back into garbage
* have informal testing in random situations developers never get to see
* break the testing repeatability loop, so bugs never get properly resolved
If one only has 2 staff left, than they are likely doing 8 jobs 8 times less efficient than one expects.
Best of luck =3
>> Failure to deliver on time means they don't get another dime
"On time" can be achieved by over estimating. As a hypothetical, dev A estimates that a project will take a year and completes it in 6 months. Dev B estimates 1 month for the same project and completes it in 3.
Companies that focus too much on things being "on time" ultimately get the "nothing is worth doing" corporate culture.
"On time" can be achieved by over estimating. As a hypothetical, dev A estimates that a project will take a year and completes it in 6 months. Dev B estimates 1 month for the same project and completes it in 3.
Companies that focus too much on things being "on time" ultimately get the "nothing is worth doing" corporate culture.
Actually, sometimes it means hiring rank amateurs, and training them to reliably complete tasks like a real business. Understanding the time constraint would be lower for Jr, and thus the equivalent pay scale will be less lucrative... but it is up to individuals to decide their own work ethics.
Using PERT deliverable/vertices redundancies is often necessary for projects no one has seen before:
https://en.wikipedia.org/wiki/Program_evaluation_and_review_...
Note, the simple system uses probabilistic time estimates of key deliverables, considers redundancy, and explicitly mitigates teams that introduce liabilities.
If it put people on the moon, than I figured it was good enough for most of my ridiculous projects. Have a great day =3
Rule #17: "Always listen to the person that signs your paycheck. Everyone has an opinion, but some opinions are more profitable than others"
Using PERT deliverable/vertices redundancies is often necessary for projects no one has seen before:
https://en.wikipedia.org/wiki/Program_evaluation_and_review_...
Note, the simple system uses probabilistic time estimates of key deliverables, considers redundancy, and explicitly mitigates teams that introduce liabilities.
If it put people on the moon, than I figured it was good enough for most of my ridiculous projects. Have a great day =3
Rule #17: "Always listen to the person that signs your paycheck. Everyone has an opinion, but some opinions are more profitable than others"
I think the PERT chart is pretty accurate. The issue is typically predicting what all of the nodes on graph will be ends up being a waste of time. Instead, there are really just two points: current state and desired state. It is better to spend time clearly articulating the desired state so that everyone really understands it. Then incentivize people to get there as quickly as possible.
I think our perspectives differ slightly, as I really don't care to micromanage adults that know better. Notably, the fixed cost of development is far less of a concern than long-term deployment, support, and maintenance costs.
Probably a ROWE would be a similar modern equivalent...
Have a nice day, =3
Probably a ROWE would be a similar modern equivalent...
Have a nice day, =3
heh i will say being a parent helps with being a manager. You really understand the carrot/stick balance as a parent.
true! I'm not really kidding when I "joke" that being a father of three has helped shape my management style. The value systems and overall approach are really similar :)
What is your management stick?
How were things good if there was a mess?