4 ms·

Lot of misconceptions here that cause teams to underperform. 1. Managing comes first. (Nope, as a manager your are primarily responsible for ensuring a good ou

Lot of misconceptions here that cause teams to underperform. 1. Managing comes first. (Nope, as a manager your are primarily responsible for ensuring a good outcome. As your title goes from manager, senior, higher to VP etc this becomes more important. Lower job titles you get paid to "do the work", higher titles are about "achieve outcome".) In the current market you'll often run into team members that don't perform. I see this so often where leads think that they have to "manage" and not do the work and the result is them and their team failing 2. Facilitate wellbeing. That's nice. But your primary responsibility is to A. Achieve the goal. B. hold people accountable to an acceptable level of performance Give credit, take blame: That's a good one. This post is just full of vague language that doesn't hold anyone accountable. Sucks to be an IC on that team, thinking everything is going well and eventually end up having whole teams being fired since your manager didn't set the right pace.

malfist 4y ago
If you supplant your team and do the work yourself, you're not helping the team perform. Nobody is learning lessons and everyone, including yourself will just be more stressed and less satisfied with the job. If you can't trust your team to do the work, then you shouldn't be managing those people. Management is about being a force multiplier, and not the force.
- throwawaythekey 4y ago
  What team size would you say this applies to? At the moment I have flexibility in how many people I hire underneath me and would like the team to remain small enough where I can be both a force multiplier and part of the force. The goal is to be an elite small squad. The other option is to hire a larger number of people, handle more of the project scope, and cease being an IC. However I'm new to being a formal manager and am guessing this would probably be bad for my sanity.
  - NhanH 4y ago
    You can't do that at any team size. The role you was looking for is generally called a "lead" role, which has different responsibility than manager role. It's mostly because of conflicting mindset and commitment. As manager, meeting is your tool to get work done (source: High output management by Andrew Groove, I didn't make this up, and I didn't understand it until after I had to become a manager either). As an IC, meeting is a big giant distraction to you. You basically can't get the two type of works to mix together. You will always be blocking other members of your team in your IC task. And this doesn't get started with the different mindset yet (For example, you have to watch/ teach people fixing ugly code, as opposed to doing it yourself. And there will be some point you have to give up asking polishing certain piece of code, due to the members not interested, incapable or other reasons). Being a manager and part of the force should only be a transitional period.
bumby 4y ago
I suspect you're right and the article conflates the means (managing) to the end (achieving an outcome). It's not unlike the military priority of 1) mission accomplishment and 2) troop welfare. But in fairness, "achieving outcome" is equally vague and it seems most leaders know they want Outcome X, but falter because they don't know how to get from their current state to that end state. Can you elaborate on how you'd fill those gaps of "achieve outcome"?
- and-not-drew 4y ago
  > It's not unlike the military priority of 1) mission accomplishment and 2) troop welfare. I hear what you're saying, but I would be careful taking a military type model and applying it to a team of software US engineers mainly because I think the power balance is so different. If I'm in the military and I tell one of my subordinates that they need to dig trenches in the rain all weekend for the next 6 weeks, they may bitch and moan, but they've signed a contract so they're just kind of stuck. If I tell one of the engineers on my team that they need to work weekends for the next 6 weeks, they can probably have 3 interviews with other companies lined up by Monday. I agree that achieving results is still priority #1, but the distance between that and #2 is very different.
  - bumby 4y ago
    This is a perspective that is bandied about quite a bit, but I don't think it's exactly true (or at least not true to the extent presumed). Personally, I've only heard it come from people who have little actual military experience. Leadership capital is a perishable resource in the military. Junior troops are not dumb and if you treat them like crap and just use the justification that they signed the contract, you won't be a very effective leader. If I leader has to use that type of tactic (or use their rank, or whatever), it's an indicator they've messed up somewhere along the way. The power dynamic isn't as cut-and-dry as most outside the military think. It's not unheard of for junior troops to get a bad leader fired, and in the absolute worst cases junior troops can put a poor leader's lives in danger. The idea that good military leaders would tell their subordinates to pound sand because they signed a contract is more of a trope than reality. There's a surprising amount of times when the incentives align for a military subordinate to NOT listen to orders and leaders have to actually rely on the social capital they've accumulated by building trusting relationships with their subordinates.
gfody 4y ago
> hold people accountable to an acceptable level of performance > end up having whole teams being fired since your manager didn't set the right pace Whatever work exists where a manager can control such things as "pace" and "performance level" it aint engineering.
- majormajor 4y ago
  I've seen teams that got very little done for a long time because their manager didn't hold them to finishing tasks. So the team was perpetually in a state of polishing just a few more edges and never finally shipping things. I don't know what sort of company would respond by firing the whole team, though. If a manager fails, the manager should be out, and a new manager should try to turn the team around.

malfist 4y ago

If you supplant your team and do the work yourself, you're not helping the team perform. Nobody is learning lessons and everyone, including yourself will just be more stressed and less satisfied with the job. If you can't trust your team to do the work, then you shouldn't be managing those people. Management is about being a force multiplier, and not the force.

throwawaythekey 4y ago
What team size would you say this applies to? At the moment I have flexibility in how many people I hire underneath me and would like the team to remain small enough where I can be both a force multiplier and part of the force. The goal is to be an elite small squad. The other option is to hire a larger number of people, handle more of the project scope, and cease being an IC. However I'm new to being a formal manager and am guessing this would probably be bad for my sanity.
- NhanH 4y ago
  You can't do that at any team size. The role you was looking for is generally called a "lead" role, which has different responsibility than manager role. It's mostly because of conflicting mindset and commitment. As manager, meeting is your tool to get work done (source: High output management by Andrew Groove, I didn't make this up, and I didn't understand it until after I had to become a manager either). As an IC, meeting is a big giant distraction to you. You basically can't get the two type of works to mix together. You will always be blocking other members of your team in your IC task. And this doesn't get started with the different mindset yet (For example, you have to watch/ teach people fixing ugly code, as opposed to doing it yourself. And there will be some point you have to give up asking polishing certain piece of code, due to the members not interested, incapable or other reasons). Being a manager and part of the force should only be a transitional period.

bumby 4y ago

I suspect you're right and the article conflates the means (managing) to the end (achieving an outcome). It's not unlike the military priority of 1) mission accomplishment and 2) troop welfare. But in fairness, "achieving outcome" is equally vague and it seems most leaders know they want Outcome X, but falter because they don't know how to get from their current state to that end state. Can you elaborate on how you'd fill those gaps of "achieve outcome"?

and-not-drew 4y ago
> It's not unlike the military priority of 1) mission accomplishment and 2) troop welfare. I hear what you're saying, but I would be careful taking a military type model and applying it to a team of software US engineers mainly because I think the power balance is so different. If I'm in the military and I tell one of my subordinates that they need to dig trenches in the rain all weekend for the next 6 weeks, they may bitch and moan, but they've signed a contract so they're just kind of stuck. If I tell one of the engineers on my team that they need to work weekends for the next 6 weeks, they can probably have 3 interviews with other companies lined up by Monday. I agree that achieving results is still priority #1, but the distance between that and #2 is very different.
- bumby 4y ago
  This is a perspective that is bandied about quite a bit, but I don't think it's exactly true (or at least not true to the extent presumed). Personally, I've only heard it come from people who have little actual military experience. Leadership capital is a perishable resource in the military. Junior troops are not dumb and if you treat them like crap and just use the justification that they signed the contract, you won't be a very effective leader. If I leader has to use that type of tactic (or use their rank, or whatever), it's an indicator they've messed up somewhere along the way. The power dynamic isn't as cut-and-dry as most outside the military think. It's not unheard of for junior troops to get a bad leader fired, and in the absolute worst cases junior troops can put a poor leader's lives in danger. The idea that good military leaders would tell their subordinates to pound sand because they signed a contract is more of a trope than reality. There's a surprising amount of times when the incentives align for a military subordinate to NOT listen to orders and leaders have to actually rely on the social capital they've accumulated by building trusting relationships with their subordinates.

gfody 4y ago

> hold people accountable to an acceptable level of performance > end up having whole teams being fired since your manager didn't set the right pace Whatever work exists where a manager can control such things as "pace" and "performance level" it aint engineering.

majormajor 4y ago
I've seen teams that got very little done for a long time because their manager didn't hold them to finishing tasks. So the team was perpetually in a state of polishing just a few more edges and never finally shipping things. I don't know what sort of company would respond by firing the whole team, though. If a manager fails, the manager should be out, and a new manager should try to turn the team around.