So I am dev who's been managing people for fairly recently.<p>I also manage people who manage other devs.<p>The thing that I am struggling with the most is how to point out where people are clearly going to go wrong and correct them?<p>For example, A dev who reports into me decided to do something in a certain way which:
1. Is clearly not required.
2. Takes things personally when corrected.<p>How do I give feedback/course correct without upsetting people. I understand how developments works(still do significant IC work) and understand that people want to try out different things, however I work in a startup and we don't have the luxury of doing things long tail.<p>How do I balance this? Whenever I ask people for the reason they are doing things, all I get are grumpy faces.<p>I also feel like I am being a bit of an hypocrite -> I am the last person who would want to do this, because I used to be like the dev I mentioned above, and have caused major issues in the past by making decisions like this, but they also enabled me to learn from it. However I didn't own the whole software org at that time, but do now. Should I just stop saying anything and let people fall(and hoping they learn from it).
Humans tend to take things personally. It can help a little to work hard at not sounding blamey and not making it personal from your end.<p>Don't use "you" language. Instead, talk about <i>the work</i>.<p>I loved something you said and here it is with a little editing as a suggested place to start:<p><i>Because this is a startup, we don't have the luxury of doing things long tail.</i>
Steps:<p>1. Learn active listening, model it and use it to make people feel heard<p>2. Model healthy debate to the team and normalize it, then give feedback to it<p>3. Provide the convergent values to use when force ranking decision criteria<p>4. Encourage dispassionate assessment of multiple alternatives in every decision<p>5. Give a pathway to express strong feelings 1:1 and talk it out with them<p>Sounds like:
'It sounds like you're suggesting that we (your steelman understanding of their proposal). The purpose of this work is to (convergent reason for doing the work). I would challenge that pursuing that alternative (dispassionately assess alternatives, model healthy debate) would lead to (unintended outcome, outsized effort). My recommendation based on what I'm hearing is (path you recommend). If anyone has strong feelings against this please (pathway to express strong feelings).<p>For example:
'Thanks John, it sounds like you're proposing we use Terraform for this. Terraform worked well for us on that other project, and we're analogizing this work to that other work.<p>The reason we're focusing on this is because that one big customer asked us to do it. But because it's only one customer, we aren't sure it this work generalizes to others yet.<p>I would challenge you to consider a lighterweight alternative, such as manually provisioning servers for the dedicated instance, until we know more about impact.<p>My recommendation based on your feedback is that we manually provision here and revisit in two months. By then we'll know much more about how much this work generalizes<p>If you or anyone else on the call has strong feelings about this, I'm happy to talk more and around today until 5pm. If not, let's start work and revisit in two months'<p>If you have to flash your badge (e.g. appeal to institutional power you hold) on every decision, something is wrong (either with them or your approach, but most likely your approach).<p>Reasons for the steps:<p>1. Active listening helps people feel heard even if you have to decide something against their preference. It is more satisfying to have your proposal acknowledged than not.<p>2. Modelling healthy debate will show people the 'right way' to disagree, and normalize it. Then you can coach people (e.g. 'Hey, you did a good job advocating your proposal' vs. 'I noticed you were too direct advocating for this...')<p>3. It's on you as the leader to provide convergent values. Should we prioritize speed? Quality? Customer happiness? Tech debt? Supportability? Explainability? Minimum sellable? Make sure this is clear to contextualize the eventual path<p>4. Encourage in all decision being exhaustive about brainstorming alternatives (e.g. there are many ways to implement this, lets seriously consider the best three) which will make people feel heard and lead to better decisions, because often a combination is right<p>5. Give people a private pathway to express strong feelings of disagreement, or else you'll only hear from the beligerant at the expense of hearing from the wise. The wise might come to you after the fact and disagree on further reflection, but won't want to wage open war in a meeting.