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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.
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.
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.
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.<p>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.<p>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.<p>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.<p>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.<p>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).<p>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.<p>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.<p>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.<p>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.<p>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".<p>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?<p>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?<p>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).<p>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.