
Results vs. Hours: creating a results-focused work environment - lukethomas
https://www.friday.app/results-first-workplace
======
m23khan
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.

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

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

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

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

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

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

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

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

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

~~~
anewguy9000
then there is parkinsons law:

[https://en.m.wikipedia.org/wiki/Parkinson%27s_law](https://en.m.wikipedia.org/wiki/Parkinson%27s_law)

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

------
snow_mac
As a contractor, I always prefer hours

~~~
AlchemistCamp
Why?

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

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

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

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

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

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

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

~~~
nickjj
> 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...](https://nickjanetakis.com/blog/protecting-your-code-and-ip-when-
doing-contract-or-freelance-work)

------
anticensor
The domain name checks.

