Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

comment on

( #3333=superdoc: print w/replies, xml ) Need Help??

As with many things, developer metrics can work well when chosen from the bottom (of the organization) and can be horrible when imposed from the top.

The only developer metrics we use are ones selected by our own team and those are only short-term for getting improvement on a specific problem. We haven't resorted to that recently. So that would be the Process Improvement part.

The main place I see pushing to identify metrics is around determining how successful a feature or product (or other "story") really is. But that seems tangential to what you were asking.

There are various rewards for developers and many of them have individual, team, business unit, and corporate-wide components. We have performance reviews and PKIs (using a different name).

We don't use metrics in performance review. Metrics might make them seem less subjective, but they'd mostly just make them more stupid. There is no way around needing a good manager. A desire to impose metrics on performance review is usually a reaction to some of the managers being worse at their job. The best metrics can't compete with even a moderately good manager. Instead of metrics, invest in improving how good your managers are.

We do lots of other things to try to reduce problematic subjectivity: have company-wide guidance on how reviews are done; do them all at the same time; incorporate feedback from top-down, bottom-up, laterally, and cross-team; separate performance review from compensation review; keep pushing to minimize as much of the process as practical.

Some PKIs have metrics, but each such would be chosen by the people closest to the particular PKI. So some of my personal goals have metrics but those metrics are meant to aid me and my manager being more objective in accessing progress on the goal and to improve clarity on expectations. Those metrics mostly don't matter in the PKI assessment process. My manager and I discuss how successful I was at each goal and assign a percentage grade to groups of goals for the purpose of determining bonus amount. We write up a very short assessment and we might mention numbers from some metrics, but what matters is the percentage score we agree on. Rarely there can be push-back from a higher layer of management but that is pretty rare because most of this is no surprise; even the President of the company has some idea of how well I'm doing before he sees my PKI paperwork (and that is true for most of the 200 employees).

The broader PKIs are more likely to have metrics or to be completely expressed as a particular metric (for example, there are usually a couple of direct financial metric goals). Those end up being less important and are just an attempt to encourage alignment at a broader scale and mostly have value, IMHO, when we meet those goals because it lets everybody share in the success.

But the real value in all of this is facilitating the flow of information and expertise such that each person has a clearer and more accurate picture of how well they themselves are doing and how they can do better (and are less likely to feel that others are "getting away with" doing a poor job).

Rewards are actually quite dismal at improving performance. Read "Punished by Rewards" if you want to know more about that.

- tye        

In reply to Re: Nobody Expects the Agile Imposition (Part VII): Metrics (self) by tye
in thread Nobody Expects the Agile Imposition (Part VII): Metrics by eyepopslikeamosquito

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or or How to display code and escape characters are good places to start.
Log In?

What's my password?
Create A New User
Domain Nodelet?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (6)
As of 2021-10-19 15:20 GMT
Find Nodes?
    Voting Booth?
    My first memorable Perl project was:

    Results (77 votes). Check out past polls.