As we cannot evaluate the business impact of a developer directly, I like to assess the reliability of them.
Evaluation of story point and commitment to delivery is an important aspect to consider a developer as great.
We should be able to count on a great developer word. Delays due to development not able to deliver can have an enormous impact on the road maps, so on the business.
I am not telling developer should kill himself to give. I am more into someone I can trust to tell me if there are delays and then we can act.
I also like the approach from Mike Seavers, Director of Engineering at Riot Games, describe in the articles Debugging Title: Part I, II, III
Beekey Cheung is a software engineer with a large amount of enthusiasm for economics and a passion for education. He loves mentoring other programmers and is currently building an application to te...
I agree that a developer should be extremely communicative of any kind of delay. I also think it's pretty bad if a 2 day task blows up into 2 weeks with no reason on why, though there's also a management failure there for allowing it to get to that point without communication.
I do think whether delivery commitments are actually the most important thing is something a team should discuss. Trying to make a deadline for a conference or investor meeting? Yeah, the deadline matters a lot.
Taking some downtime to clean up technical debt or laying down some foundational work of a new system? Quality is the important part here. It's important not to make the incentive time based rather than quality based (so long as the time is reasonable). Creating arbitrary time lines when they aren't necessary will encourage developers to cut corners elsewhere. If a dev has an epiphany at the last minute which will save us enormous amounts of time going forward, I would probably be up for extending the scope of that work. I would not want to have created an incentive for the dev to not speak up about it because they want a "completed" task as a notch on their belt.
The article about debugging titles seems really interesting. I think it's good that someone is trying to be more analytical about this. I've only skimmed it, but I do think there is still a lot of contention with the attributes though. People leadership can include both 1-1 mentoring and leading a whole team. Someone can be good at one without being good at the other. How does the attribute become affected? I like the effort, but I think it is extremely difficult to remove subjectivity from titles.
"Quality is the important part here. It's important not to make the incentive time based rather than quality based (so long as the time is reasonable). "
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As we cannot evaluate the business impact of a developer directly, I like to assess the reliability of them.
Evaluation of story point and commitment to delivery is an important aspect to consider a developer as great.
We should be able to count on a great developer word. Delays due to development not able to deliver can have an enormous impact on the road maps, so on the business.
I am not telling developer should kill himself to give. I am more into someone I can trust to tell me if there are delays and then we can act.
I also like the approach from Mike Seavers, Director of Engineering at Riot Games, describe in the articles Debugging Title: Part I, II, III
What do you think about these approaches?
I agree that a developer should be extremely communicative of any kind of delay. I also think it's pretty bad if a 2 day task blows up into 2 weeks with no reason on why, though there's also a management failure there for allowing it to get to that point without communication.
I do think whether delivery commitments are actually the most important thing is something a team should discuss. Trying to make a deadline for a conference or investor meeting? Yeah, the deadline matters a lot.
Taking some downtime to clean up technical debt or laying down some foundational work of a new system? Quality is the important part here. It's important not to make the incentive time based rather than quality based (so long as the time is reasonable). Creating arbitrary time lines when they aren't necessary will encourage developers to cut corners elsewhere. If a dev has an epiphany at the last minute which will save us enormous amounts of time going forward, I would probably be up for extending the scope of that work. I would not want to have created an incentive for the dev to not speak up about it because they want a "completed" task as a notch on their belt.
The article about debugging titles seems really interesting. I think it's good that someone is trying to be more analytical about this. I've only skimmed it, but I do think there is still a lot of contention with the attributes though. People leadership can include both 1-1 mentoring and leading a whole team. Someone can be good at one without being good at the other. How does the attribute become affected? I like the effort, but I think it is extremely difficult to remove subjectivity from titles.
Yeah I really love what the riot game says above all how he conducted it as an experiment engineering.riotgames.com/news/deb... find some problems after feedbacks and then tries to fix them engineering.riotgames.com/news/deb...
That follows Deming's Philosophy of PDCA (by the way I start a talk "Agile Conversations" on this here youtube.com/watch?v=Cgs0F70c-I4)
About performance appraisal Deming makes this warning youtube.com/watch?v=2F1rhik2_X0
So I like what you said also:
"Quality is the important part here. It's important not to make the incentive time based rather than quality based (so long as the time is reasonable). "