Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Engineering productivity can be measured, just not how you'd expect

okayhq.com

Post reply on HN
Print view View original

21–30 of 122 posts

Re: Engineering productivity can be measured, just not how you'd expect

#21

Post by snidane »

horsawlarway wrote: post #9
snidane wrote: post #5

Earlier quoted context omitted.

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.

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…

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.

Re: Engineering productivity can be measured, just not how you'd expect

#22

Post by ndiscussion »

dazzawazza wrote: post #13

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.

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.

Re: Engineering productivity can be measured, just not how you'd expect

#23

Post by andor »

tyingq wrote: post #10

"Measuring blockers" may make unfair scapegoats out of undersized teams.

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.

Re: Engineering productivity can be measured, just not how you'd expect

#24

Post by Jtsummers »

BossingAround wrote: post #11
kamilafsar wrote: post #7

Earlier quoted context omitted.

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).

> 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.

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.

Re: Engineering productivity can be measured, just not how you'd expect

#25

Post by dmos62 »

andrey_utkin wrote: post #16

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…

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.

Re: Engineering productivity can be measured, just not how you'd expect

#27

Post by novok »

andor wrote: post #23
tyingq wrote: post #10

"Measuring blockers" may make unfair scapegoats out of undersized teams.

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.

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.

Re: Engineering productivity can be measured, just not how you'd expect

#28

Post by andrey_utkin »

dmos62 wrote: post #25
andrey_utkin wrote: post #16

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…

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.

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?

Re: Engineering productivity can be measured, just not how you'd expect

#29

Post by stuxnet79 »

dazzawazza wrote: post #13

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.

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.

Re: Engineering productivity can be measured, just not how you'd expect

#30

Post by majormajor »

horsawlarway wrote: post #17
bjornsing wrote: post #8

> 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.

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,…

Those blockers should be things that give you falsifiable stories, no?

So if someone says "it's because we're blocked on [slow delivery of designs from another team]" and you measure that specifically, and then improve it, and you notice the team's output hasn't changed, you've learned something.

I've certainly seen those reasons before, but haven't seen people turn them into specifically measured things versus "ok let's see if we can improve it" with often little or ineffective followup.

Post reply on HN