Props to you for making the best out of this and shaping it into a win. Based on your story though that's just poor feedback and communication from the manager. I stay away from comments like those in any of my reviews. Why does he think that's over engineered? Retractor what? What's their reference to call it out as one engineered?
You're right that it's not personal but we should expect better from managers when they provide feedback.
Would this have been a better experience if the manager had expressed care in day to day conversations, like expressed belief in your growth or shown empathy about your personal life?
This was quite an engaging piece, and it inspired for me a whole slew of thoughts. (I ran across a link to it in TLDR Web Dev.) Thank you, Stephane, for sharing.
I like how you integrated your former manager's brusque style into your own management style in a more constructive manner. As you were telling the story, that was my gripe: “Over-engineered. Too many moving parts. Refactor”? What's that supposed to mean? What if I think it's engineered the perfect amount for the complexity of the problem? My feelings aren't hurt. Rather, I feel lost and confused, and I'm angry that he expects me to read his mind and then just agree with it, and I don't think that's very effective or constructive. You didn't do that. You "stole the parts that worked": provide reasons, not just quips; broaden the context, don't just criticize; provide constructive feedback, don't just complain.
As a developer, I would have asked that he be more specific and provide more detail, and this is gonna be a conversation. Some of his comments seem to me a question of style and priorities, not absolutes. (There are very few absolutes in our business, only trade-offs.) I think it's important for a leader to discuss goals, priorities, and trade-offs with the team, not just fire off one-liners and expect the team to magically divine the right answer.
(Of course, it's possible that he actually did discuss these things and supported the team in other ways that you did not include in your telling of the story.)
As a side note, I agree that as professionals, we should not take things personally and should focus on the work. That said, people's feelings do matter, and ignoring that human fact will only make the team's job harder. Telling people that we appreciate the effort they're putting into the work is a good idea, and doing so doesn't mean we have to okay substandard work.
One more thought: The most effective negotiators always try to get on the same side of the table—metaphorically speaking—as their opponents. They approach disagreements as problems that both parties can solve together rather than issues to fight over. I think that code reviews, design discussions, and scope negotiations should be approached the same way. We should try to approach these discussions not as conflicts between differing viewpoints but as problems to be solved together.
I think the thing I discovered at Hashicorp, where I was in over my head most days, is that code reviews, even from that pain-in-the-ass colleague, are not about you as a person; it's about the work I produced at this point in time. When I stopped taking everything so personally, along with not projecting my own self-doubts, things improved for me.
Props to you for making the best out of this and shaping it into a win. Based on your story though that's just poor feedback and communication from the manager. I stay away from comments like those in any of my reviews. Why does he think that's over engineered? Retractor what? What's their reference to call it out as one engineered?
You're right that it's not personal but we should expect better from managers when they provide feedback.
Would this have been a better experience if the manager had expressed care in day to day conversations, like expressed belief in your growth or shown empathy about your personal life?
This is just what I needed in my current role, though the lead in question is more of a tech lead than my manager.
This was quite an engaging piece, and it inspired for me a whole slew of thoughts. (I ran across a link to it in TLDR Web Dev.) Thank you, Stephane, for sharing.
I like how you integrated your former manager's brusque style into your own management style in a more constructive manner. As you were telling the story, that was my gripe: “Over-engineered. Too many moving parts. Refactor”? What's that supposed to mean? What if I think it's engineered the perfect amount for the complexity of the problem? My feelings aren't hurt. Rather, I feel lost and confused, and I'm angry that he expects me to read his mind and then just agree with it, and I don't think that's very effective or constructive. You didn't do that. You "stole the parts that worked": provide reasons, not just quips; broaden the context, don't just criticize; provide constructive feedback, don't just complain.
As a developer, I would have asked that he be more specific and provide more detail, and this is gonna be a conversation. Some of his comments seem to me a question of style and priorities, not absolutes. (There are very few absolutes in our business, only trade-offs.) I think it's important for a leader to discuss goals, priorities, and trade-offs with the team, not just fire off one-liners and expect the team to magically divine the right answer.
(Of course, it's possible that he actually did discuss these things and supported the team in other ways that you did not include in your telling of the story.)
As a side note, I agree that as professionals, we should not take things personally and should focus on the work. That said, people's feelings do matter, and ignoring that human fact will only make the team's job harder. Telling people that we appreciate the effort they're putting into the work is a good idea, and doing so doesn't mean we have to okay substandard work.
One more thought: The most effective negotiators always try to get on the same side of the table—metaphorically speaking—as their opponents. They approach disagreements as problems that both parties can solve together rather than issues to fight over. I think that code reviews, design discussions, and scope negotiations should be approached the same way. We should try to approach these discussions not as conflicts between differing viewpoints but as problems to be solved together.
Thanks again for the thought-provoking article!
Super cool 😎 for rejection
I think the thing I discovered at Hashicorp, where I was in over my head most days, is that code reviews, even from that pain-in-the-ass colleague, are not about you as a person; it's about the work I produced at this point in time. When I stopped taking everything so personally, along with not projecting my own self-doubts, things improved for me.