"We need to work longer" - Why this is not what you want to say | Hacker News Reader

"We need to work longer" - Why this is not what you want to say

manuel.kiessling.net

This is something to take to heart if you are a manager. Often times managers will be presented with the problem that the things that need to get done, aren't. The 'simple' solution is 'work longer', the expensive solution is 'hire more people', and the right solution is 'work smarter.'

If you can get clear feedback as to what holds things up from getting done, you can address those barriers and knock them down. Once you run out of ways to add leverage though, hiring is your best bet. Making people put in extra hours when they are working efficiently is asking them to burn out.

The issue being that the manager who needs the work delivered is often not one empowered to get more resource on board.

Right on target, it's amazing what can get done in when people know what's expected of them. Within a year of finishing college and getting my first job I was promoted from rookie designer to manager. Within two I was Art Director running all of advertising production and leading people who had been there for 15+ years. Why? For this exact reason, I had been lucky enough to grow up with people who knew how to work smarter and get things done. When you get into a company and people see you know how to work smart rather than "hard" it's like a green light and all the doors open. Pass go and collect $200! (Actually I more than doubled my salary, At the same company!)

Why are you going home? There are still unclosed issues in the bug tracker.

Where is "do less" on that priority list?

Oftentimes, the problem isn't really that development is inefficient, it's that the wrong product is being developed. A little customer feedback could shave off a lot of effort.

Also, more features don't always make for a better product (witness: Apple vs. Google or Microsoft). Judicious feature-cutting both saves development effort and tends to make the UI simpler and easier to use.

One of my theories is that "morning people" have a tendency to get promoted in managerial tracks, while most IT workers tend to be "evening people". Thus to the mismanagers, it appears that their staff comes in late all the time - so to the "morning people", the "cure" for lateness is to make folks come in earlier and stay longer.

It seems to me that mismanagers never get the point that longer hours "in the seat" do not correlate to more positive work acomplished. In our profession, we've been aware that "crunch mode" is counter productive, but the lessons don't seem to get uphill to the people that dictate such things.

http://www.igda.org/why-crunch-modes-doesnt-work-six-lessons

That truth seems to stop flowing upwards in organizations is something that appears far more often than I'd like to happen. In the worst companies I've worked for, truth stops moving upwards at my direct superior's level. In the better ones, it is a few levels uphill. The most bureaucratic and hidebound company I worked for - GM - had 15 levels of people between myself (and I was salaried) and the CEO; which was more than enough for multiple thermoclines of truth to occur.

http://brucefwebster.com/2008/04/15/the-wetware-crisis-the-t...

http://www.cio.com.au/article/250886/thermocline_truth/

article starts off on fallacious footing:

"Let’s face it, doing about 30% better isn’t going to get you anywhere significant. And I’m not even going to start talking about why working 30% longer of course won’t bring anything significant in your company up by 30%, especially not the “doing better” – much has been written about this already."

dead wrong. there are reasons not to work long hours, but this article articulates none of them, hand-waving about exponential growth instead. There's a time to grow yourself, and there's also a time to ship your product.

"From a business point of view, long hours by programmers are a key to profitability. Suppose that a programmer needs to spend 25 hours per week keeping current with new technology, getting coordinated with other programmers, contributing to documentation and thought leadership pieces, and comprehending the structures of the systems being extended. Under this assumption, a programmer who works 55 hours per week will produce twice as much code as one who works 40 hours per week. In The Mythical Man-Month, the only great book ever written on software engineering, Fred Brooks concludes that no software product should be designed by more than two people. He argues that a program designed by more than two people might be more complete but it will never be easy to understand because it will not be as consistent as something designed by fewer people. This means that if you want to follow the best practices of the industry in terms of design and architecture, the only way to improve speed to market is to have the same people working longer hours. Finally there is the common sense notion that the smaller the team the less management overhead. A product is going to get out the door much faster if it is built by 4 people working 70-hour weeks (180 productive programmer-hours per week, after subtracting for 25 hours of coordination and structure comprehension time) than if by 12 people working 40-hour weeks (the same net of 180 hours per week). The 12-person team will inevitably require additional managers and all-day meetings to stay coordinated."[1]

[1] http://news.ycombinator.com/item?id=3547965 (secondary source)

Can you please fly over to this place and tell my boss about these 25 hours? Don't mention the rest though - as a corporate drone I learned the hard way (a good amount > 70h/week for roughly a year) that there's only one correct reaction to requests like this from my manager:

1) Smile and say that you don't agree, point out what might work

2) Don't follow that request (in my home country it's even against the law as soon as you require certain amounts. Unless you're in very specific scenarios)

3) Go elsewhere

And - the biggest lesson of all: Avoid peer pressure and congratulate your coworkers that don't back down and leave after a 10 hour day, instead of joking about his part-time job attitude. Cost me dearly to learn these lessons - but I'm sure I'll never forget those.

That assumes that a programmer working 70 hours is more productive than one working 40 hours.

I agree the article is off base, but the assumption in this citation is that programmer productivity is constant, which it is clearly not. It's not even just a uniform curve because being overworked can have a knock-on effect that decreases productivity even more. Basically, it's entirely ignoring the human aspect of programming, which I think was a lot easier to do in the 70s, because frankly, America had a better work ethic and were inherently more willing to be a good team player because back then nothing interesting happened except with major capital backing and a lot of team work.

All else being equal, sure a single programmer is more efficient than two programmers because of a more comprehensive mental model, and lower communications overhead. But in this day and age, with no job security, and the possibility to strike out on one's own at the drop of a hat (because in the 70s you pretty much had to keep your job just to have access to a computer, let alone develop a product and make a living from it), it's not sufficiently motivating to tell people to work longer, it's also equally ineffective to say be 300% better (I would probably laugh out loud if I heard that). Somehow you need to create a vision that people really buy into that internally motivates them, which will result not only in longer hours worked, but also greater minute-to-minute productivity, and even more productive subsconscious work. This is all the more difficult when you realize that individuals have different motivations. But this is the quality that will most enable a great founder today. This is I believe what set Steve Jobs apart more than anything else.

Productivity goes negative as a programmer will eventually create more and more bugs, ultimately overwhelming the system.

I actually think that there's a sweet-spot number of programmers that isn't just 1. I really like having one or two people around to keep me honest.

Immediately made me think of this classic blunder:

http://www.nytimes.com/2001/04/05/business/stinging-office-m...

It has been a long time since I've read that letter, but it still gives me chills.

I think a large part of not saying "We need to work longer" is that if the work is interesting and rewarding enough, then employees will WANT to work longer. As soon as a manager says "We need to work longer", it generates an environment driven by employer demands instead of employee happiness. If you manage the work load at your company well enough, and the work environment is positive, then employees will be inclined to work longer out of desire to see the company excel.

>I think a large part of not saying "We need to work longer" is that if the work is interesting and rewarding enough, then employees will WANT to work longer.

Not necessarily, no. It's entirely possible your employees have lives outside work.

Right, but I would say that the general startup mentality is that you will be working more than the average work day. So telling people to work longer, rather than inspiring people to work longer, is usually not the best way to go about it. To what extent can you actually require someone to work longer anyway?

>To what extent can you actually require someone to work longer anyway?

You can reprimand and/or fire them if they don't. Seems to work for most American companies.

Doesn't work for programmers though because unlike assembly line workers, there's no way to precisely monitor their productivity, so if you force them to stay late they can just mentally check out.

Well yes, which is why you should be trying to get programmers to agree with you on their hours.

It's worth noting Henry Ford helped bring about the 40-hr work week: http://www.worklessparty.org/timework/ford.htm

I think you should watch this:

http://thewebivore.com/go-the-fuck-home-my-ignite-talk

Any manager who cannot be more specific than "work smarter" isn't smart enough to work for.

It isn't key to his point, but of course his math is wrong. 300% of 8hrs is 24hrs. 300% more than 8hrs (as he says in the article) is 32hrs.

Thanks, I will rephrase it.

Reply on news.ycombinator.com