161–170 of 170 posts
Earlier quoted context omitted.
Thanks! I couldn't find it on your profile. Here's mine: forgot.hn@outlook.com Some anonymous email exchanges would do, if you'd prefer that way.
director@industrialintel.co
Earlier quoted context omitted.
Yes. Suck up to the boss, then say you're interested in a new opportunity at Team X, or, sadly, you've accepted an offer to work somewhere else, or, you are quitting for personal reasons.
That's why I liked Google so much: you don't have to "suck up" to anybody. If things aren't working out, figure out what you'd like to do instead and 2 weeks later you're working on that, if they have spots on the team and would like your help. You may be asked to stay a bit longer, say 6 weeks, but the process is very non-confrontational. It's not like that for junior people, though - if you're junior you have to st…
Earlier quoted context omitted.
I want to do 360s on the managers two level up and higher. Because they are the real problem in my view. I hate snitching on my direct team members not knowing how the the feedback is used so I usually just praise them without much detail.
We are not a big shop so there are not many levels up but the managers, including myself also got 360 reviews.
Earlier quoted context omitted.
But companies doing SAFe can use developer velocity to help judge individual dev productivity. That can be surprising if you aren't aware of what story points are used for.
As someone who is again at a company doing SAFe, I am genuinely curious as to the relevance of story points. For estimation, hours is a good measure, even more so when there are external consultants that get paid by the hour. Developer velocity can be measured by tasks/features completed compared to the estimate. Could you elaborate on why story points are useful or perhaps point to some resources on the topic ?
There was an expectation that devs complete about 8 points a sprint. I don't know if the eight point target is common, but SAFe does talk about comparing story points across teams.
> At scale, it becomes difficult to predict the story point size for larger epics and features when team velocities can vary wildly. To overcome this, SAFe teams initially calibrate a starting story point baseline where one story point is defined roughly the same across all teams.
...
> Give every developer-tester on the team eight points for a two-week iteration
Earlier quoted context omitted.
Yet the corporate legal eagles will insist on documentation as to bolster their case of such dismissal, if any.
And that’s when you create a performance improvement plan. If someone is underperforming then you take steps to try to understand why and help them to get to the level the company needs them to be at. Hopefully this works and everyone is happy but you need to be clear (to your employee and yourself) that ultimately this could end up in dismissal if it doesn’t work out. This is when you document everything and have re…
The more savvy people started applying at other companies the same day they received the PIP, since it was clear to them they would have to work significantly more for no increase in salary and they perceived the attainable effort/reward ratio to be better elsewhere. In one case this led to hilarity when the CTO had instructed the managers to PIP at least one of their team members "for morale reasons" and it ended in more than a third of all devs leaving the company in the next two months.
Earlier quoted context omitted.
And that’s when you create a performance improvement plan. If someone is underperforming then you take steps to try to understand why and help them to get to the level the company needs them to be at. Hopefully this works and everyone is happy but you need to be clear (to your employee and yourself) that ultimately this could end up in dismissal if it doesn’t work out. This is when you document everything and have re…
I've never seen PIPs work out well, although all my observations are from outside the manager/PIP-ee perspective and perhaps my sample size is not large enough yet. One employee managed to meet the demands of the PIP but only at the expense of dropping all other (not documented in the PIP) tasks, an extreme case of "what gets measured gets managed". Overall, they got to stay on but it was detrimental to the team they…
"what gets measured gets managed" is one of the reasons I don't like the usual metrics and performance reviews, but in the specific case of a PIP they are necessary. If someone meets the targets of the PIP but starts dropping other required behaviours then you just add that into the PIP to make sure they don't do that
Earlier quoted context omitted.
I hope you then worked out how much TOIL you where owned and pointed out to them the definition of salaried employment.
Salaried employment doesn't mean unscheduled.
It has been known for nearly 100 years that you can never criticize your staff. “I will speak ill of no man and speak all the good I know of everybody.” ― Benjamin Franklin Last job, my last performance review. There was literally only 1 complaint against me. I was late >40 times. My boss told me he was disappointed in me. I was upset because I was never ever late to work; I was always early. I asked him to tell me w…
I hope you then worked out how much TOIL you where owned and pointed out to them the definition of salaried employment.
I reported this to my boss. The next day I was fired.
Earlier quoted context omitted.
Here's my slightly unusual take on performance management as a manager. If I'm doing my job well, reviews should mostly feel like a formality. They shouldn't take much time from me or from my reports. If I'm doing my job poorly, one signal of that is that a review takes a lot of effort. If a performance review takes a lot of my time or that of the report receiving the review, it suggests there's been some considerabl…
Some people just don’t like talking and/or writing about themselves. I find the process painful even if I know I’m doing great and I know that everyone else knows too.