Results vs. Hours: creating a results-focused work environment | Hacker News Reader

Results vs. Hours: creating a results-focused work environment

friday.app

56 pointslukethomas31 comments

Just stop please. If you are a IT leader and reading this, do us technical workers a favor and just stop. Please get a life outside of work to satisfy your slave leader/world conquerer appetite instead.

As a developer, I am really getting tired of all these nanny/big-brother style theory of how to make IT workers work harder and faster. It is bad enough always being student for life and having uphill battle trying to raise a family and having some social life.

All these items like agile, scrums, standups, support tickets, SLAs, retros, post mortems, overnight support, 24/7 slack channels, etc. are only targeted towards IT workers and are being embraced by companies in name of being more nimble and ship out faster.

Meanwhile finance, accounting, legal, traders etc don’t bother with any of these, make more money (in Canada) on average and have cushy team lunches and bonuses. Hell, these non IT folks end up becoming managers and directors often on basis of seniority while not even understanding how to work properly with basic Windows functions.

All these things combined have led to a dangerous culture where a 15 year experienced developer is often being grilled by a pointy head scrum master or product owner who doesn’t even have half that amount of experience and is being artificially emboldened by top management while being obsessed with work related and productivity metrics.

I don’t mind if IT workers are subjected to some of these changes at a Company but to bring out all these changes and apply them towards us is just inhumane.

Sorry for the rant but I really didn’t get into IT to be treated like a dispensible factory worker or to be case study for management on how to extract more juice out of me.

Author here - the point of the article was to outline a super basic process to understand what people are working on and what can be expected of them. You may notice in the article that the individual opts-in to what they'd like to accomplish. That's the starting point.

We don't use Jira. We don't do scrums. We have one meeting every week. We definitely aren't a sweatshop.

I care deeply about making sure people are performing at their best, but in a way that's considerate of their lives outside of work. Process is required, but the level of process is negotiable and this post aims to outline the minimum process needed that's also respectful of the individual.

You must admit that this is all they can do. Management has no clue about quality of software or how to achieve it. For them incidents either just happen randomly or are completely unexpected. So all they can actually control is the pace of change of the product and what incomplete, unsound features make it into this week's release...

Then go get one of those other jobs. As an employee you are an asset to be utilized. Companies that are too heavy handed about it lose employees. IT is one of the cushiest professions in the world, if you want it to be even less demanding then there are people willing to take your place.

your last sentence says it all - it is the same age old, classic, in-your-face, thinly-veiled-threat management style attitude that is behind this micro management era.

Frankly, among white collar jobs, not sure how exactly you are calling IT related profession cushy. If you are talking about free coffee, catered lunches and beer fridge tech startups, these ‘perks’ usually equally ungodly amount of work hours and employees taking even less of break during regular business hours.

And yes, rewind back 15 years and I would definitely pursue another line of work.

If you compare IT to venture capital or just being a Senator’s son then sure it’s got its problems. But when you look at the pay and difficulty of IT compared to nursing, teaching, truck driving, coal mining, construction, etc... it’s the easiest money you’ll ever make. So if you don’t want it, please show yourself the door.

> it’s the easiest money you’ll ever make

The idea that you have to do back-breaking physical labour for something to be "hard" is silly rubbish. There's absolutely nothing "easy" about getting into and sustaining a career in IT.

Find some people who have worked in an engine room or a McDonalds or similar, and supported themselves from the income from that job, and also had a career in IT. I think they will have a different opinion.

I read it very differently, just a "instead of scrum, what works for us is a Monday meeting with objectives for the week and a Friday meeting to retrospect", more of a "how our team works" than a manifesto for overworking or anything.

Problem with results vs hours is that there are always unknown unknowns that will slow you down. So the employee will feel like their results sucked. And that their 8 hour day wasn't good enough, and they'll keep working. And everyone will do that and start comparing themselves to their peers who are working longer and longer hours.

It depends on your manager ultimately. I've worked at 3 companies that have supposedly had a "results" focused work environment. However, the managers at the first two did not fully commit and they still operated under the "more hours = more work" mentality. I now work under a manager that understands results based output and it's an entirely different ballgame. Ultimately the leader has to be 100% bought in for it to work well.

> they’ll keep working

You realize that’s entirely the goal of measuring “results vs hours”, right?

You get paid by results by becoming owner [stakeholder]. The rest is all BS.

Whenever I got results at work, my manager would just give me more work.

Work always filled up all the time I had, and then some.

then there is parkinsons law:

https://en.m.wikipedia.org/wiki/Parkinson%27s_law

I've always run my businesses this way. Aside from positions that really need to have someone during specific hours (mostly positions involving talking to the public), my practice has long been that I pay a salary and don't track hours. As long as deadlines are being met with an acceptable work quality, I don't see why I should care how many, or what, hours people are working.

As a contractor, I always prefer hours

Why?

I'm assuming because hours = money when contracting/consulting

When I was a contractor I also preferred hours. If you get paid by results there is less reluctance to wasting your time. I had several situations where I told a client “you understand that you are paying me good money for sitting around and waiting for X to make a decision?”. Sometimes they were ok with it and sometimes they would accelerate things. But at least I got paid. On the other hand I did fixed price where they didn’t respond to questions which wasted my time (and money).

Interesting. I always found more intense push back on hourly price, whereas it's easier to price on value when it's results-based.

It is, in the end, what costs to you as a person. It is the ultimate limited resource. An hour spent doing work for a customer is an hour ticked off of your finite list of hours you'll ever have in this life.

In contrast, results are somewhat of a renewable resource.

As a contractor, I only accept per hour since this is the best result for both parties. A fixed sum for a task requires a fixed and extremely detailed spec up front which leads to worse software, since you always learn more in the process. And even then there may be ambiguities and misunderstanding which means the contractor might have to use more time than expected to satisfy the customer.

I prefer getting paid by the day or week, not by hour.

I recently heard a pretty solid argument against results based work, from a person obsessed with efficiency and squeezing every last minute out of an employee about a task that typically ends up being paid by results.

From their experience, the drop in quality was unacceptable, while the increase in productivity was negligible. The slight drop in speed was worth the far higher quality of the results in paying by the hour.

I prefer hours. As tools get better, and companies invest in buying these tools to make their employees more productive, the employer recoups on their investments in the tools by getting more productivity, more stuff produced for the same cost of employee time.

I think employers are purchasing ~40 hours a week from an employee, give or take due to breaks and such.

If your following agile and using level of effort story points, your grooming sessions should solidify stories that the team agrees is complete (fully defined). If someone is sandbagging, this will become obvious to the team and can be addressed directly.

My experience with hours is that management still wants actual cost metrics, so they still need to be tracked.

This is a really complicated topic IMO and there is not a single right answer. I've been a freelance developer for a really long time and tried everything. Here's how I see it from a contractor / freelance POV.

It's complicated because it's almost impossible to come up with a good number for a results based project that isn't trivial. That would be "good" in the sense of it makes sense for both the freelancer and the person hiring you where in the end both of you are happy and want to work together again in the future.

Results oriented payments sets you up to start hating what you're doing if your estimate was a bit off where you need to work more hours than you thought. Suddenly you find yourself working much longer and it feels like "damn it, why won't this gig end already -- this is such an inefficient use of my time", or if the estimate is off in the other direction the person hiring you might feel like they overpaid (even if you slam dunked the project it's still a negative).

But hourly by itself isn't close to perfect either. Hourly sets you up to become a "wage worker" where you get punished for being a master of your craft, because if you invested a lot of time off the clock to improve then suddenly you're getting paid less because you finish your work faster.

A prime example is, let's say you have an iron clad user registration system written that you made for a side project on your own time and it took 25 hours. You have great test coverage, it works perfectly and it's pretty easy to plop it into another project and customize it.

So now a client hires you to make them an app that requires a user registration system. Now you can implement that into their code base in literally 5 minutes because you have a project skeleton to start your app off with, vs starting at ground zero.

This is where the problem starts. If you charge $100 an hour, you just "lost" $2,500 because now you finished something that took you 25 hours on your unbilled time in 5 minutes.

So what do you do? Do you hide that aspect from your client and bill them somewhere between 15-25 extra hours and then try to come off like a hero where you contact them in 3 days with a progress report with the user system in place? That 15-25 number is something you decide on the fly with a thought process of "well, I invested the time and continue to maintain this feature on my own time, I should be able to bill for that and re-use it for 5, 10 or 50 clients over the next few years".

Or do you not do that but instead drastically raise your rates but let them know you can finish things faster because you have years worth of license free personal code you've written?

What if you step back and use another example of investing 200 hours into tweaking your development environment to the point where you can actually finish real work faster than someone who didn't, so now on a 200 hour project you can legit finish things in 180 hours (a 10% increase isn't unreasonable IMO). How do you factor that in other than raising your rates?

All of these things are complicated questions. I typically go with hourly based rates but I'm also transparent with my clients when it comes to implementing things I already have code for. I let them know they are getting a huge discount by not having me implement this thing from scratch and in turn we decide on a fair figure on the spot (on a per client / per project basis).

But for things like general skills that make me faster at coding, I raise my base rates. Nothing wrong with doing that. If I can finish things faster then it's a benefit to everyone. The client gets their work done faster, I gain hours back from my life in the long run and I have an incentive to continue becoming better at my craft.

> All of these things are complicated questions. I typically go with hourly based rates but I'm also transparent with my clients when it comes to implementing things I already have code for

How do you deal with the inevitable question about intellectual property here? If you already sold your old code along with new code to a previous client, did you not transfer any and all copyright to them, but maybe added a license for existing code?

Really curious how people do that, since I also entertained the idea of having prepacked code for common features that is always up-to-date to bootstrap new client projects.

> How do you deal with the inevitable question about intellectual property here?

IP is pretty easy to deal with. You just need to bring it up with your clients before you start the project.

Here's an article I wrote on that subject: https://nickjanetakis.com/blog/protecting-your-code-and-ip-w...

The domain name checks.

Reply on news.ycombinator.com