3 ms·

The impact of Jenkins could be: - Reduced the average time from pull request to deploy from 6 days to 1.5 days (efficiency gains) - Increased the number of de

by beager 9y ago

The impact of Jenkins could be: - Reduced the average time from pull request to deploy from 6 days to 1.5 days (efficiency gains) - Increased the number of deploys from 1x/week to 4x/day (output gains) - Reduced the number of production quality incidents from 36/month to 3/month (quality metrics) - Enabled the team to ship XYZ Project 90 days earlier, which enabled an new $10 million annual revenue stream for the company. If one has to "make up some BS numbers" then one either doesn't understand what Jenkins is good for, or doesn't understand how to identify and measure the positive benefits of Jenkins. And that's kinda my point. edit: I should also mention that yes, it's on your employer to help you account for this as a backend/infrastructure engineer. If not, they're kinda stacking that deck against you and you should speak up!

maxxxxx 9y ago
I guess the main problem in my company is that they want to have money saved as the main input for the awards.
alexandercrohde 9y ago
That's a great list in theory, but what would it really mean? - Pull-request-to-deploy is simply a latency, not a throughput factor, and may or may not correspond to business value. - Number of deploys (without looking at features/deploy) doesn't necessarily measure business value - 36/month -> 3/month meaningful statistic, made up numbers - "Ship product 90 days earlier"- You can't really objectively prove when it would have come out otherwise Other problems include - usually the engineers are the ones who are collecting and researching these metrics so it's a conflict of interest: an engineer is never going to mention the downsides of their work in such statistics. I'm saying if I saw those "facts" on a resume (or as a manager) I'd ignore them all; they don't sound objective at all to me but more like good sounding pseudo-truth to give a low-competence manager something to work with.
- beager 9y ago
  I think you'd be shocked to find that on any results-oriented resume, it's nearly impossible to objectively prove essential and sole causation of positive results. A sales rep bringing in $10mm/year in deals is a great achievement, and a hiring manager may ask about the details, but just because you needed marketing, a good product, and biz dev to warm the pipe doesn't mean that you are bullshitting when you claim those results and talk about your impact on them. > usually the engineers are the ones who are collecting and researching these metrics so it's a conflict of interest: an engineer is never going to mention the downsides of their work in such statistics Yeah, that's called effective self-marketing, and everyone does it. > I'm saying if I saw those "facts" on a resume (or as a manager) I'd ignore them all; they don't sound objective at all to me but more like good sounding pseudo-truth to give a low-competence manager something to work with. Thoroughly disagree, and I would hope as an engineer to avoid encountering hiring managers who would harbor a prejudice against engineers who can identify and speak cogently about the impact of their work.

by beager 9y ago

maxxxxx 9y ago

I guess the main problem in my company is that they want to have money saved as the main input for the awards.

alexandercrohde 9y ago

That's a great list in theory, but what would it really mean? - Pull-request-to-deploy is simply a latency, not a throughput factor, and may or may not correspond to business value. - Number of deploys (without looking at features/deploy) doesn't necessarily measure business value - 36/month -> 3/month meaningful statistic, made up numbers - "Ship product 90 days earlier"- You can't really objectively prove when it would have come out otherwise Other problems include - usually the engineers are the ones who are collecting and researching these metrics so it's a conflict of interest: an engineer is never going to mention the downsides of their work in such statistics. I'm saying if I saw those "facts" on a resume (or as a manager) I'd ignore them all; they don't sound objective at all to me but more like good sounding pseudo-truth to give a low-competence manager something to work with.

beager 9y ago
I think you'd be shocked to find that on any results-oriented resume, it's nearly impossible to objectively prove essential and sole causation of positive results. A sales rep bringing in $10mm/year in deals is a great achievement, and a hiring manager may ask about the details, but just because you needed marketing, a good product, and biz dev to warm the pipe doesn't mean that you are bullshitting when you claim those results and talk about your impact on them. > usually the engineers are the ones who are collecting and researching these metrics so it's a conflict of interest: an engineer is never going to mention the downsides of their work in such statistics Yeah, that's called effective self-marketing, and everyone does it. > I'm saying if I saw those "facts" on a resume (or as a manager) I'd ignore them all; they don't sound objective at all to me but more like good sounding pseudo-truth to give a low-competence manager something to work with. Thoroughly disagree, and I would hope as an engineer to avoid encountering hiring managers who would harbor a prejudice against engineers who can identify and speak cogently about the impact of their work.