81–90 of 102 posts
Remember that if one of your team members has a good idea about how to improve the codebase or the process that you should acknowledge that it's a good idea and tell them how much you like it. Then you should always remember to tell them that it's "not the right time" so you can then move on to demand status updates on features.
Earlier quoted context omitted.
>so that women Men aren't impervious to sexism either. >Only hire young men in their twenties, and praise the idea of working long hours Young women are working ridiculous hours as well. >Child care is for their wives to do. What child care, most of the highly educated aren't having kids to begin with. (Exaggerating, but it's not the big deal given what most career couples in their 30s make.) >Pay new grads more than…
> Men aren't impervious to sexism either. Given that GP didn’t say they were, why is your first instinct to assume that anything OP didn’t mention, in what were fairly obvious examples, was specifically excluded? > Young women are working ridiculous hours as well. So are the elderly, why are you excluding them? And so on. Come on. There’s absolutely no need for the ridiculous pedantry, and it adds less than nothing t…
But it sure does tell us a hell of a lot about the person who wrote it.
My team went through a lot of instability. We lost 2 devs, a manager, a director, and a VP in 2 months. We were the only 4 software engineers working on the product.
The company worked according to milestones. Every month we'd need to meet some arbitrary feature set. We were planning to launch every month for 9 months straight. That's right, the entire 800 person company was aiming to launch in less than 30 ways for 9 months.
Our product was shit. It was rushed and messy. After we hired a new director and hired more devs those original 4 people (including me) got yelled at, blamed for the bad product, and pushed out of the company.
Remember that if one of your team members has a good idea about how to improve the codebase or the process that you should acknowledge that it's a good idea and tell them how much you like it. Then you should always remember to tell them that it's "not the right time" so you can then move on to demand status updates on features.
Creating useful digital over-communication in the right way can go a long way to establish the “what do you need from me so I can get out of your way culture”.
On a positive note, we just had a sprint retrospective today and the entire team gushed with praises for each other and we all agreed that team morale is great, and that we are accomplishing great things despite all the challenges we had been facing recently. I attribute this to a few things I’ve observed. First, we do have some extremely dedicated engineers who lead by example rather than granted authority. This gar…
Lol, you should add that this is a sarcasm.
Remember that if one of your team members has a good idea about how to improve the codebase or the process that you should acknowledge that it's a good idea and tell them how much you like it. Then you should always remember to tell them that it's "not the right time" so you can then move on to demand status updates on features.
Remember that if one of your team members has a good idea about how to improve the codebase or the process that you should acknowledge that it's a good idea and tell them how much you like it. Then you should always remember to tell them that it's "not the right time" so you can then move on to demand status updates on features.
If said teammate decides to follow through on his idea without your explicit permission, transfer him to another team ASAP (without his approval). No teammate can show initiative, self-direction, or autonomy. Furthermore, every piece of work must be represented in JIRA and every team member must report on it —- daily. This happened to me recently. Yes, I’m a little salty about it. Although it’s probably for the bette…
Ive been in the weird scenario of not having a real manager a couple times. One time it was how you described. Another was pretty bad, we basically became the dumping ground for unwanted projects and tedious work because we didn't have authority to say no.
Later when the deadlines slide by a mere 2 weeks, blame the engineer saying that the time given to them was "generous".
Use performance ratings as a tool to set them up for failure, but only after getting the guarantee of a backfill headcount.