|
|
|
|
|
by thanksgiving
558 days ago
|
|
> 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. |
|
- 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).