3 ms·
Thoughts in no particular order: - Know the limits of your knowledge. This is probably hard. The less of a programmer you are, the harder this will be. The peo
by pmjordan 18y ago
Thoughts in no particular order:
- Know the limits of your knowledge. This is probably hard. The less of a programmer you are, the harder this will be. The people you're managing probably know more about a lot of the detaily that are part of the project. Try to keep track of who is the expert on what. That's okay, that's what they're there for. Try to make sure you know your limits, and whenever you hit those limits, get the experts involved. Hence leaving alone/bugging. (managers at my last job got that right almost all the time) If in doubt, you probably don't know better. That's not to say you shouldn't make decisions, just genuinely use input from the experts. One of the best ways to do this is to openly admit that you don't know everything.
- It should be clear to everyone what it is you do and why you (need to) do it. If the positive impact your job on the project isn't felt by the people lower down, they won't respect you.
- Actions speak louder than words.
- Meetings without substance should be rare. The occasional "you're doing great, that is all" probably is appreciated, but at my last job it was way overdone. (daily to weekly) If you expect only you to be doing the talking, 9 times out of 10 you don't need a meeting. Of course, if people are likely to be asking questions relevant to everyone, it's acceptable.
- Don't lie. It builds resentment, no matter how smart it seems at the time.
- Unless you're handing out equity, overtime should be the exception rather than the rule. For some people, longer periods of overtime (1-2 weeks or more) won't actually get more work done anyway, they'll just get more tired and unhappy. Some people do get more done. It's a tricky subject, and I can't offer any great advice despite having been on the receiving end of death march orders. In my case the reason was constant orders from waay up to keep changing key parts of the project combined with bad QA handling of the project early on, causing bugs to accumulate because no time was scheduled for finding or fixing them.