3 ms·

One way to mitigate that is to continue working on the project; even if you only spend one day a week actually working on a team, you will have to actually unde

One way to mitigate that is to continue working on the project; even if you only spend one day a week actually working on a team, you will have to actually understand what is going on and what the technical problems are. If something is delayed you are in a much better position to know why and how to fix it than just getting vague reports from people who don't want to disappoint you. That would probably help a lot of other things like empathy, etc. and if your team has to stay late to finish a release, you stay late too. I think managers often use moving up an excuse to stop doing anything technical, when they should really be keeping in touch with the tech, the teams, and the projects in an intimate way.

spookthesunset 8y ago
> One way to mitigate that is to continue working on the project; even if you only spend one day a week actually working on a team That is a conflict of interest. You can't do both. A good leader delegates to others. - You start doing the work yourself and nobody will challenge your (probably questionable) technical decisions--your their boss, so you have to be right, right? - A leader knows when to make course corrections. You start doing the work yourself and you'll be more likely to get caught up in the sunk cost fallacy and hold onto projects you worked on longer than they ought to exist. The older and hopefully wiser I get, the more I have realized that the technical decisions almost never really matter as much as you'd think. Having a vision for your product, a roadmap to get there, key metrics to correct course with, and buyin from key stakeholders are very important things to a successful project. No technical person will do that work. That is on you...
- fjsolwmv 8y ago
  A good leader should work on tech support and bugfixes in the part time, to get empathy for the pain points and to not get stuck in big projects.
  - spookthesunset 8y ago
    I would agree with that. Everybody top to bottom should at least shadow tech support and sales. Where I draw the line, I think, is trying to make meaningful “productive” contributions at the “worker bee” level. Be it code commits, installing rebar, or packing a shipment, you are there to gain empathy and to learn what is up on the front line. This means you get to watch and ask a lot of questions. If you do actual work, your host will be right next to you guiding you. They get all credit for any work produced. You are the guest, they are the host. Trying to do their job for them isn’t gonna help you do yours. Learning how they do their job, why they do what they do, and how to make it better... that is your job. Note: I’m talking about leaders that are one or two levels removed from the rank and file.

spookthesunset 8y ago

> One way to mitigate that is to continue working on the project; even if you only spend one day a week actually working on a team That is a conflict of interest. You can't do both. A good leader delegates to others. - You start doing the work yourself and nobody will challenge your (probably questionable) technical decisions--your their boss, so you have to be right, right? - A leader knows when to make course corrections. You start doing the work yourself and you'll be more likely to get caught up in the sunk cost fallacy and hold onto projects you worked on longer than they ought to exist. The older and hopefully wiser I get, the more I have realized that the technical decisions almost never really matter as much as you'd think. Having a vision for your product, a roadmap to get there, key metrics to correct course with, and buyin from key stakeholders are very important things to a successful project. No technical person will do that work. That is on you...

fjsolwmv 8y ago
A good leader should work on tech support and bugfixes in the part time, to get empathy for the pain points and to not get stuck in big projects.
- spookthesunset 8y ago
  I would agree with that. Everybody top to bottom should at least shadow tech support and sales. Where I draw the line, I think, is trying to make meaningful “productive” contributions at the “worker bee” level. Be it code commits, installing rebar, or packing a shipment, you are there to gain empathy and to learn what is up on the front line. This means you get to watch and ask a lot of questions. If you do actual work, your host will be right next to you guiding you. They get all credit for any work produced. You are the guest, they are the host. Trying to do their job for them isn’t gonna help you do yours. Learning how they do their job, why they do what they do, and how to make it better... that is your job. Note: I’m talking about leaders that are one or two levels removed from the rank and file.