Successfully support the <milestone> for the <project name>
Many managers use this boilerplate performance goal for just about any employee. It's lazy. It reflects nothing with regards to the expectations of the employee, nor does it reflect at all, in what way would one grow in their capabilities.
Why is it not great to tie project success to performance goals.
Simply stating success of a project without identifying how they should be contributing to the project does not set them for success in being able to support the NEXT project on a DIFFERENT team in a more COMPLEX situation. This not only provides no guidance to the employee on what they should be improving upon, but also may not give you, as the manager, the right capabilities in succeeding should any adversity arise.
Most importantly, many software projects fail due to circumstances that have absolutely nothing to do with the execution of the project.
Why is project success commonly tied to performance goals
- If a project succeeds, the company would make more money, therefore, there's more money in the pool to pay for raises, right?
- A manager's thinking: if a project succeeds, then I succeed, and that means the individuals of the team succeeds right?
What should performance goals include instead?
Activity and contribution to a project should be an EXAMPLE of how you want them to be performing.
Focusing on Software Developers:
- Three Basics
- Ability to tackle complex challenges.
- Ability to interact with their colleagues in the form of clean code, communication in PRs, and overall communication with the team via chats, email, IRL
- Ability to interact with stakeholders in the form of requirements feedback for clarification and further getting feedback on software behavior.
- The thing that I care about the most
- How accountable are they in production and are they able to observe the behavior of their code out in the wild?
If you really want to talk about it in the context of a project:
- How did they contribute to projects last year, and is there any difference in contribution that htey should be doing in future projects? Spell it out.
- Are these projects more or less complex that last year's projects? How does completing these projects demonstrate their skill set? Explain how this project is a more significant challenge that will test capabilities that haven't been tested before.
Bottom Line: Goals should not be effectively "yeah do what you did last year but more". You need to give them explicit skills to level up and a clear example of how you plan to observe it. for some managers, that is solely based on the success of a project, and that's a shitty manager.
Soapbox Moment
In developing and operating software, it all boils down to how much trust do you have in the employee. When shit hits the fan, will you call on them? When a brand new paradigm needs to be investigated, will you ask them to spike it? When another member of the team is not around, will they be able to temporarily fill in? These should all be straight forward yes/no questions and for the situations your team finds themselves in, you should have a pretty clear list of which members of your team are your primary, secondary, "bench" type people for a given situation.
For each of these moments, based on an employees skills, potential, and professional interests, their goals should be balancing enhancing their skill set so that they can contribute more for your team that suits both their interests, capabilities, and team needs.
Who said management is easy!?
