Question about setting Employee Targets
I was asked by the president of our company to create a dev plan there is a goals section with the one of the areas to fill in is Employee Targets. The description added here was "What individual goals do team members have—for example, maybe logged time per week, month, quarter--- what happens if they are not met? What does remediation look like? "
I do not like the idea of using logged time per week and I feel like achieving a specific number of story points could be subjective but I would really like to hear other opinions on this and if anyone has any example of employee targets.
What does remediation look like?
To answer that, you must first know what the problem looks like.
- Have you asked the purpose of these targets?
- What issue are they intended to resolve?
- What would they provide for the company, which the delivery of Done working product increments would not?
First of all, it is important to understand the reasons these targets are being requested. It is pointless, and can even be dangerous to decide on something without that knowledge.
However, in general terms, professionals usually find themselves in a stronger position if they can engage with management and investors in conversations about outcomes and impact. This is (or at least should be) the kind of information that senior management can act on. If anyone is doing the kind of job where hard work is a better measure of success than results achieved, it's quite likely that they have a simple function, and might just be a matter of time before they're replaced by a machine. In any case, Scrum is a generally a poor fit for such simple work.
Examples of outcomes can be sales revenue (even if the team is only working to make the product saleable, and not selling it directly), and the amount a product is being adopted by customers and users (perhaps focused on customers and users within certain strategic segments).
By impact, I mean the changes that are brought about in others, as a result of the outcomes achieved. This may even go so far as shifting an entire market or global behaviour. One classic example of impact is the way the original iPhone revolutionized user expectations for mobile phone capabilities. Another impact of the same product is that it led to a great many businesses deciding that developing an iPhone app was a crucial to their own success.
In contrast, outputs are measures of things like the amount of done units being produced (e.g. a count of completed items of work, lines of code developed/added/removed, messages sent). These are terrible proxies for success, and if used in such a way are likely to be gamed if there's a perceived reward for achieving a certain result, even if such decisions threaten the viability of the entire company. For instance, a target to add 1000 lines of code per day might lead to decisions not to simplify code, avoid removing unwanted functionality, or could lead to new solutions being deliberately overcomplicated in order to appear more successful.
Hours worked are arguably an input, which is just something that the company is already paying for. The management should already know this. The only potential benefit I can see to understanding logged hours worked would be to eliminate waste, but again, if this is a proxy for success, there remains the risk that these numbers will be gamed, rather than focusing on real success.
Internally, teams may want to consider outputs and inputs for the purpose of continuous improvement; particularly as they can provide a greater understanding internally about waste, and other nuanced changes around internal processes.
But when it comes to accountability, unless you want to encourage all kinds of strange behaviours that may put the company at risk, it's almost certainly a better idea for management to engage inquisitively and collaboratively with teams about the outcomes they are achieving.
It might eventually be useful to talk about impact, but probably not before there is a good understanding of outcomes.