[HN Gopher] Engineering Productivity Can Be Measured - Just Not ...
___________________________________________________________________
Engineering Productivity Can Be Measured - Just Not How You'd
Expect
Author : tomasrb
Score : 33 points
Date : 2021-02-02 19:57 UTC (3 hours ago)
(HTM) web link (www.okayhq.com)
(TXT) w3m dump (www.okayhq.com)
| strangattractor wrote:
| The best teams appear to be doing nothing. If as a general rule
| things are always in a fire drill then your software sucks (there
| are other reasons for this). We always measure how many things
| are fixed. New features added. Rarely how much time is spent baby
| sitting machines etc.
| snidane wrote:
| The best way to motivate devs to build truly robust systems is
| to let them go home at 2pm when things are finished and
| production process is running smooth.
|
| However most organizations would pile more work onto devs if
| they finish early, so devs then compensate by taking more time
| on their current tasks. Why finish them early, when you'll be
| thrown another one right away.
| horsawlarway wrote:
| The best way to motivate _any_ employee is to give them a
| vested interest in the company (ownership, equity, profit
| share, etc).
|
| Prod can be running as smoothly as you like - it doesn't
| matter if your company is having its lunch eaten by
| competitors adding or improving features faster than you.
|
| You should be incentivizing employees to step back and look
| at the big picture every now and then. If customers are
| happy, the company is profitable, and prod is running
| smoothly? Go take some time off, head out early, etc.
|
| Is revenue down? Company growth slowing, or worse, is the
| company shrinking? Time to work. Prod being red or green has
| little to do with it.
| snidane wrote:
| That kind of works in theory or for people up there in
| decision making ranks. For engineers down in the trenches
| it might not be such a motivating factor because they don't
| feel their individual contributions matter as much. It
| might motivate them to stay and slack off without getting
| fired until the company does an exit. So one might suggest
| giving devs equity would motivate them not to their maximum
| potential, but rather to the very minimum which will not
| get them fired before the cash day.
|
| Also I'm sure we could come up with examples of people who
| got a good amount of equity just because they were there
| among the first employees and then not working at all
| because, well, their profit was already locked in by just
| waiting for others to do the hard work.
| kamilafsar wrote:
| Finish what? Where do you draw the line of "work for today"?
| I don't think motivated devs want to go home at 2pm.
|
| Speaking as a dev, the best way to motivate me is to give me
| some head cracking challenge, trust (no reporting) and
| autonomy (don't tell me how to do my work).
| snidane wrote:
| > I don't think motivated devs want to go home at 2pm.
|
| That's the beauty of it. Motivated engineers will use the
| spare time after 2pm to study and improve things. Or run
| some errands if they have to, without feeling their butt
| has to be glued to the chair until 6pm.
|
| I've often solved many problems at work in my spare time or
| when taking a dump or something. It's pretty difficult to
| really get into deep thinking at the office because of 1.
| noise and 2. looking unproductive when you actually think
| hard.
|
| Paradoxically office slackers bashing keyboard when
| chatting on facebook look more productive from a distance
| than somebody who actually is deeply thinking about system
| design and spinning in a chair or staring at a ceiling
| while doing it.
| [deleted]
| BossingAround wrote:
| > I don't think motivated devs want to go home at 2pm.
|
| I can understand the attitude when one's in their twenties,
| has no significant other, kids, or other commitments.
|
| Me? I just get tired. I'm very motivated and like what I
| do, but at some point, it's just silly to stay behind the
| screen. And sometimes, that point is even earlier than 2pm.
| That's ok. We aren't machines to be working like a Swiss
| watch.
| Jtsummers wrote:
| I was most productive when my office let us take a few
| hours a week to exercise. I wouldn't use it if I had
| anything critical pending, but otherwise I would duck out
| an hour early several times a week to go get in a good
| long run (5-10km).
|
| It felt like they had more respect for my time and well-
| being. When they cut it (with bullshit reasons [0])
| "productivity" did not improve in the office. Instead,
| projects expanded to fill the time. Those 3 hours or so
| we got to use at the gym before became 3 hours spent to
| produce the exact same total work. There was zero
| motivation to utilize it "properly" by using it to get
| ahead on anything. Every project continued to hit the
| same deadlines they were hitting before.
|
| [0] One reason I say it was BS, we were typically on or
| ahead of schedule on projects. Teams that were behind
| weren't making use of this time while they were behind,
| they weren't permitted to.
| emteycz wrote:
| Sadly business people want to fire you when you're seemingly
| doing nothing (as in coming to work on time, doing your job
| without stress and conflict, going home on time)... Even if all
| the business goals were met, they just can't stomach someone
| not working their asses off 24/7 for them.
| maximente wrote:
| well, yeah. if you don't have air cover from a team or
| manager and don't appear to be engaged in shared suffering,
| it's no surprise people are going to ask questions, both from
| above and equal level. other labor will resent your non-
| suffering (how come /they/ get to leave on time?) and
| management will wonder whose reports get such a cushy setup
| and why.
| ndiscussion wrote:
| It's about power not money.
| karmakaze wrote:
| That's actually insightful. Wish I'd known this early in my
| career. Often, I'll be doing a great job with no complains
| from peers or project deliveries but seemingly 'tolerated'
| and not liked by any management types as they had no
| influence, I just did what needed doing of my own accord.
| Or maybe I didn't need to know, ignorance was bliss.
| ndiscussion wrote:
| Check out this post: https://daedtech.com/defining-the-
| corporate-hierarchy/
|
| I really recommend his book Developer Hegemony, although
| it was very depressing and I haven't quite recovered a
| year later :D
| bjornsing wrote:
| > Engineers will become more focused and engaged, managers will
| become more effective and empathetic, and companies will build
| faster with higher quality. Engineering will rise to a whole new
| level.
|
| A bit too much hyperbole for my taste, given the less than
| groundbreaking ideas.
| horsawlarway wrote:
| I mostly agree - This doesn't seem to be adding any real
| visibility that velocity tracking (a la - agile) wouldn't give
| you already (not that I'm advocating for agile, mind you...).
|
| Consider -
|
| I have two teams, with the same staffing levels and the same
| general seniority. For this example, lets assume each is a team
| of 5, with 1 tech lead, 2 seniors, and 2 juniors.
|
| Both teams have the same approximate meeting count, both work
| on the same stack with the same dev tools.
|
| Team A consistently releases new features faster than team B.
| Why?
|
| Because if the answer is "Find the blocker" aren't we right
| back at
|
| > "your engineering leaders will simply justify failures,
| telling stories like "The customer didn't give us the right
| requirements" or "We were surprised by unexpected vacations.""
|
| except with blockers this time?
|
| Maybe Team A is actually just better than Team B.
|
| Maybe Team B is actually working on a feature set that has more
| inherent complexity.
|
| Maybe Team A releases faster but also has more incidents in
| prod.
|
| Maybe Team B releases a larger changeset on average.
|
| None of this is getting addressed or answered.
|
| ----
|
| None of that is to say that measuring blockers isn't a useful
| idea, but it's certainly not some silver bullet.
| andrey_utkin wrote:
| Engineering activities are economic activities.
|
| Engineering activities must make sense as economic activities.
|
| Engineering activities productivity can be measured the same way
| the productivity can be measured for any economic activities.
|
| See "Internal Market Economics: Practical Resource-Governance
| Processes Based on Principles We All Believe In", Book by N. Dean
| Meyer.
|
| The posted article came so close to the idea of the right
| measurements, I was intrigued and was like "yes, say it!", but
| the author didn't say what I expected, instead they pointed at
| quantifying calendars and commit logs. What a bizzare self-
| contradiction.
| dmos62 wrote:
| So what is that true way to measure productivity you alude to?
| By the way, engineering can be an economic activity, but it
| doesn't have to be. Could be an art as well, for example.
| andrey_utkin wrote:
| Simply: does revenue exceed cost of running it?
|
| The book I referred to answers the "but engineering team
| doesn't have revenue".
|
| Engineering can be art, sure, and if you like, we can even
| discount the idea that art creation can be seen as economic
| activity. But is there a need to measure productivity then?
| p0nce wrote:
| Here is an idea: measure added value. Realize it's produced at
| the bottom and consumed at the top of the hierarchy. Remove
| yourself from the organization as a pure consumer of added value.
| tyingq wrote:
| "Measuring blockers" may make unfair scapegoats out of undersized
| teams.
| andor wrote:
| Can you explain why you think this will happen to undersized
| teams more often?
|
| If it's an indication that something is wrong with the team, I
| think that's still helpful. For instance, if the team does not
| have the right experience and are often blocked waiting for
| someone else's answer to a question, it might make sense to
| work on team composition. It's not about blaming people or
| teams, but about improving flow.
| novok wrote:
| Often you literally don't have hiring headcount allocated to
| your team. Sadly the solution is to make the team implode to
| force the company to fund it properly.
| snidane wrote:
| The article is correct to point out that in case of no process
| measurement, politics, not results, will start to dominate.
|
| Measuring process inputs will favor Sisyphean work. Appearing to
| be working, hours punched in and butts-in-seats will be more
| valued than results. Many companies are stuck in here.
|
| Measuring proxies of outputs such as lines of code, or number of
| tickets closed, as the article mentions, only leads to people
| gaming the system.
|
| Measuring the actual value delivered is obviously the best thing
| to do. However it is often difficult to even define value and the
| amount of it created. Which is always a problem especially for
| inhouse projects or in the absence of direct contact with the
| market.
|
| I like what the article suggests - measuring process flow instead
| of measuring inputs or outputs. Can't say exactly why I like it
| but it seems that engineer types are naturally motivated to
| perform and learn, so giving them enough space is a good way to
| get working systems as a side effect.
| mr-wendel wrote:
| I like it too, but I think it misses something crucial: how
| often is the team _unblocking_ others? This, naturally, is at
| odds with minimizing interruptions.
|
| On one extreme there is no shield around engineers and they
| experience constant whiplash with "code oracling", shifting
| priorities, obscure trivialities, and other things that can
| drive people insane and can prevent meaningful work from being
| completed.
|
| On the other hand, sticking perfectly to "we're committed to
| this sprint and unless its on fire you wait in line" and much
| of your business becomes unnecessarily rigid and painful. That,
| IMHO, is much worse.
|
| Finding a balance is crucial, and to me thats just as
| interesting of a datapoint.
| dazzawazza wrote:
| The more time goes by, the more I value what I learned from
| Peopleware (DeMarco, Lister) 20 or so years ago. It seems so
| clear, precise and uncluttered compared to modern efforts.
| ndiscussion wrote:
| I read Peopleware last year and totally agree, it's the
| masterclass.
|
| Along with Mythical Man-Month, it's clear that we didn't need
| any other management books.
| stuxnet79 wrote:
| Peopleware is a classic. It's genius lies in the fact that it's
| able to shine a light on the important aspects of productivity
| and work life that fall between the cracks in our quest to
| 'measure' productivity and be 'efficient' (Taylorism).
|
| The big issue it has, IMO, (which other DeMarco books like
| 'Slack' share) is that it does not provide actual case studies
| that would convince a typical executive / manager working in a
| high pressure / competitive environment to change their
| methods.
___________________________________________________________________
(page generated 2021-02-02 23:00 UTC)