I don't take my work home with me, I don't check my work email when I'm at home. It's just not worth the stress to me.

I love my job, I love my work, I feel like I'm contributing to making the world a better place -- it's just not 100% of who I am. I have a dog, a girlfriend, a handful of close friends, a few engaging hobbies, and a ton of books to read and miles to run. I'm more than my job, and once I can pay the bills, the rest of the money is just a nice to have -- but not nice enough to give up my health and sanity.

Then again, I'm extremely lucky to be in this situation, and a lot of people aren't. Some of my coworkers work long hours still, but they seem happy about it. As long as that's true,... well, whatever floats your boat, right?

I feel like places that have a "show up at 10 and work till its late" are immature and fooling themselves thinking they have gains in productivity.

Properly managing your time is a skill and one that management should help you develop. I shouldn't feel pressured to stay late because everyone else was fooling around all day. It also sets clear expectations of how hard and long you should work. There's no "Oh if I don't stay till 9 tonight will my manager think I'm not working hard?" Everyone is on the same page.

Before I started working there I was one of the people that would stay up all night sometimes to finish something. come in groggy the next day and get nothing done for that day. When in reality if I spent 8.5 hours the first day working on it and 8.5 hours the second day, I would have had full mental clarity when working on the project and the added bonus of mental and physical well-being.

To some extent I think tech startup culture evolved this way not just because it takes a superhuman effort to build a successful company, but also because learning to be a good programmer is something that is extremely difficult if you're not at least a little obsessed with it. My tendency to work 80 hours a week at my startup is the natural evolution of my 14-year-old self wanting to spend all my time working on the computer.

But now that I have a couple decades experience under my belt, I can sit down and focus for 8 hours that will lead to far more productivity than slogging through 16 hours. Furthermore, my subconscious is able to continue working on problems during my downtime, so stepping away, getting some exercise, cooking some healthy food, sleeping 9 hours all feed back to greater overall productivity.

Geniune question here. How the fuck do you people do this? I hear stuff like this a lot, especially in the software community. Do you guys actually log 80 hours a week of doing stuff? How on earth do you "start loosing productivity" at 50 hours a week? I start loosing productivity around 40 if not before.

BTW, totally not asking this to be a dick, and I really respect your work ethic and your choices for how to live. I just don't understand how people can live in that reality. Most of Europe says 40 hours of work a week is too much, and frankly I'm completely on board.

There are lots of factors (age, discipline, interest in what you're doing, etc) but I think a lot of people overlook that one big component of this is brain chemistry. Some athletes are endurance athletes, some athletes are sprinters. It seems obvious that you wouldn't expect Usain Bolt to run the fastest marathon just because he's a runner.

Our brains are just as genetically varied as other physical characteristics. For me, I know that my peak productivity is from 11 pm - 4 am and it goes down exponentially if I have to do non-fun tasks or if I'm in a stressful crunch as opposed to a positive crunch. I also know that after 3-4 months of 10-12 hours, I need to go back down to 5-6 hours until I get excited again. And for some strange reason, if I don't feel something is required, I can leisurely work on something for 12-16 hours a day indefinitely (researching, reading conference papers, learning). If I have to debug code nasty bugs like multithreaded data races, I can't be productive at those lengths of time so I try to mix fun work with this type of dreaded work.

Know what works for you and build your work schedule around that. That's how we work at our startup.

* Caffeine in public, or for starters, and then adderall or something more potent,

* Alcohol after work to wind down,

* Maybe oxycodone or heroin.

If it seems like your problems can be solved by working more hours, then you end up medicating yourself into oblivion, blowing up, or burning out.

I am also baffled by the idea of working 80 hours in a week.

As for your 10+ beers followed by welcome hangover comment, I believe Adorno addresses this in Minima Moralia and some of his other texts. His basic belief is that people are so alienated from themselves that they treat the weekend (their only time to really be themselves completely) as a respite that will ready them for the onslaught of the next week's work. Basically, the work week and attitudes that have arisen to rationalize it are a system of total self-alienation, with all traces of your "in an ideal world" personality smothered out of you.

http://en.wikipedia.org/wiki/Minima_Moralia

Anyway, sorry if this came off sounding very dramatic. I really am not like deeply worried about you, hah, I'm just saying from a theoretical standpoint what you're describing does not prove your point at all. It's more like you're just using black humor to perpetuate bread&circus mentality.

http://www.mayoclinic.org/healthy-living/nutrition-and-healt...

Personally I don't drink coffee unless I'm interviewing someone at a coffee shop (even then I sometimes order hot chocolate), and only drink socially. Does that mean I work less than some adderall-infused college kid? Maybe. But quality of life and stability should also be valid concerns.

I work 60+ hours a week at my startup and 20+ hours on various side projects.

I also am completely anti-stimulants (include caffeine). If you truly believe in what you're doing (in my case, engineering the future of culture to retain intellectual thought while simultaneously building my financial independence), it's trivial to work long hours through adrenaline alone.

The bad side is that if your work fails for some reason (as work often does), your entire life failed.

Needless to say i don't work there anymore.

I can hit 50 hr in a week and be pretty productive. After that i'm running at 50% efficiency and rapidly dropping after that. Once over 80 hr it's a struggle to get the most menial tasks done.

I can easily log 30 hours of paid coding a week, tack on 10-ish hours of email, add some 5+ hours of marketing, and add 10 hours of working out with 10 hours of learning new stuff. I call all of this productive hours and will gladly say an average week contains 70 to 80 productive hours.

But you'll notice that I never spend more than 30 hours a week on any one type of productivity. And that only some 30 odd hours a week are directly billable.

50 hours/week is probably a sweet spot for me.

This is why after making "deploy" a one-click operation, "roll back to the last deployed version" should also be a one-click operation.

Fixing things "ASAP" in a panic doesn't work at all well. First get to a known good state and then do a calm assessment of the right fix, taking as much or as little time as you need (and no need to work late).

I know that this doesn't work for all failures - If a server's drive fails, you still need a plan for how to repair - but it does for many common things.

There are rarely cases when a new feature needs released Fri at 4pm or days before a holiday break.

We're working on computers, doing work which does not benefit from typing for N hours straight; there is no meaningful correlation between quality/quantity and hours worked.

I wish more people realized this.

The company managers don't care about you and your work/life balance, only the work they can get out of you. And in terms of efficiency, that means paying you the smallest salary and benefits that you'll accept. And it means telling you whatever is necessary to get you to be as productive as possible. If they can get you to inprove processes or something, even better.

Also, with pretty much everything in life, including software development, there IS a correlation between hours worked and quality/quantity. All other things being equal, the one who spends 40 hours working, not just typing, but thinking about the problem, fixing bugs, finding new ones, improving performance, refactoring to improve structure, et cetera, will produce work output that is higher quality or in grater quantity than the one who puts in 30 hours. And I know you're the special snowflake who can do a better job in 30 hours than that other guy can in 40, but that's irrelevant. They are paying you a complete salary, so they can demand that you put in complete effort. The good news is that once you can prove that you're producing more in your 40 hours than the other guy is, you can demand a higher salary or take your talents elsewhere.

Edit: Fixed grammatical error.

They can "demand" whatever they want. They can demand a pony for all I care. I provide what I want, and that's not always 40 hours a week. If it's still worth it to them to employ me, then they may continue to do so. That's all there is to it.

Let's not grant the corporation too much moral high ground. They routinely ask people for more than forty of those hours. Let's not pretend someone is a reprobate for granting fewer.

It's pointless to act like they have a moral right to a specific number of hours simply because that's the convention or because that's what they wrote in an employment agreement that grants you nothing in consideration for your concessions. I work, you pay me. If you don't like my work, fire me. I'll do my work in as many or as few hours as I please. Those are the terms I'll abide by.

Don't get me wrong, I understand the incredible luck I have to be able to operate this way. Only the strength of the seller's market that is software labor, and my own financial prudence, allows me this freedom. But it is a freedom I feel no reluctance, moral or otherwise, to exercise.

Honestly, I genuinely don't understand how the classical employment model (salary alone) ever worked for any professional employers/employees. Incentives are diametrically opposed, and in 90% of situations someone is getting at least partially shortchanged.

Yes; there's one shaped a bit like a bell curve. Too many hours, and you start losing creativity, your focus becomes too short-term, and you start missing things, making expensive mistakes.

Coding when tired is usually net negative, unless it's something throwaway for a demo due at short notice, or it's something you've done a dozen times before and don't need to think about. All too often, you overpay later fixing bugs and refactoring design mishaps.

I think there's a bit of a fallacy behind your assertions. Whether you're present at work for 30 hours or 40 hours doesn't make a massive difference to a job as intellectual as software development. Your brain doesn't completely shut off work when you go home. Much of the thinking time that you'd spend at work in 40 hours a week will happen at home when working 30 hours. Manual labour, and famously, showers, are conducive to this thinking.

I find I'm both more motivated and create better software if I stop working in the middle of something, before I've gotten too tired, and come back to it the next morning. I don't know my optimum number of hours that need to be spent at a desk in front of a PC to maximize my productivity. It's almost certainly less than 40.

We have one employee who thinks he is a rock star (he is not), he finishes his assigned tasks in 4 days instead of 5 and then takes Friday off because he thinks he "deserved" it for being so damn creative and intellectual and he thinks about work at home anyway... Guess what happens on Fridays, people are still at work and need to contact this guy, questions about old code, plans for future, a new task came in, and surprise surprise, the code he merged in on Thursday night wasn't as good as he thought, it has tons of bugs and actually breaks the build which stalls everyone else, who should take care of that?

Its a tough balance, i am also very against pushing through when unispired and the sit on your chair and wait for the clock kind of job and I also need distraction free creative time. But this guy has thought me that many times the team needs you more than you need your oh so precious creativity and that is what you are being paid for, helping the team, the company, to move forward.

A team leader that uses people like this - cogs that munch through assigned tasks - is not operating at high efficiency. It's top-down directed, and is missing effective feedback from people who know most about the code, its architecture, what it can and can't do. People are treated as manual laborers rather than self-directed professionals. You're only using 40% - if that - of their capabilities.

There are times when a team needs to operate like that - e.g. impending business-related deadlines - but they should be exceptional. The top-down model creates work politics, where the team members need to lobby and scheme to influence the team leader to make particular choices, and it leads to atrophy of initiative, and destroys most of the creativity that ought to be latent in a team.

I'm extrapolating a lot from a single statement of yours, so it may not actually apply to your organization, but it definitely does apply to a lot of dysfunctional workplaces.

the code he merged in on Thursday night wasn't as good as he thought, it has tons of bugs and actually breaks the build which stalls everyone else, who should take care of that

The person merging code should be the person reviewing the code, not the author of the code. If code breaks the build, the person reviewing it is at fault for merging it. And code isn't finished until it's reviewed and merged. Reviewing, at a minimum, means making sure it builds, the tests pass, and the tests have enough coverage, using code coverage tools if necessary.

If the code is no good and accidentally got merged, the merge commit should be reverted. If the code is absolutely necessary (e.g. for Monday), that's a crunch, the guy shouldn't have left on Friday, and he's let the team down. You can't do that too often without needing to leave. But not for productivity reasons, for team reasons.

> They expect that you treat your position not just as a job where you work so many hours or do just the tasks that you are asked to do, but that you take more personal responsibility for doing the very best job you can, improving your own productivity, and making the company function better and more efficiently.

That's actually how I prefer to treat my job, and why I like startups. But...

> The company managers don't care about you and your work/life balance, only the work they can get out of you. And in terms of efficiency, that means paying you the smallest salary and benefits that you'll accept.

If the company treats me like that then I'm going to start punching the clock, that's only fair.

There are a lot of employees that take advantage of their employer, and there are a lot of employers that take advantage of their employees (with more leverage FWIW), but such an adversarial relationship is a drag on overall resources and productivity. In knowledge work trust is paramount, there are no metrics which you can use to guarantee that an employee is "100%" productive, and management attempting to do so is a huge red flag for me.

The only difference in opinion that I see here is that those 40 (or 50, or 30, or whatever) don't all have to be done while sitting at a computer and looking busy.

Who is to say that the folks in the OP's article aren't thinking about work problems on a Friday? I'd be shocked if they don't get more of the thinking portion of their job done on a Friday (or after hours or over lunch or...) than they do in the remaining 32 hours "working hours" of the week.

People are up in arms about the lack of traditional appearance of work (that is, in a chair in front of the computer, or in a meeting, etc.), not the time actually spent thinking about how to solve a problem.

So when you think I'm working 40 hour weeks, I'm actually working 20 hour weeks and browsing reddit/HN. The guy you're comparing to that's working 30 hour weeks could actually be working 30 hours straight.

If you compare me working 30 hours and me working for 40 hours, I'll do the same amount of work (20 hours worth + emailing/meetings/other work-related non-coding things)

By the I knew Arrington (mentioned in the article) prior to Tech Crunch. He worked very hard to try and convince me to join Pool.com writing multiple times and not taking no for an answer. Back and forth, negotiating all of that. And I'm glad he did because after agreeing to get involved we made a ton of money from that service for years. I owe that all to the effort that Mike put in and was able to do so because of the hours that he worked (as well as the hours that I worked which was "all the time".)

[1] The problem is people don't realize that some people can work all the time, actually enjoy it and not be stressed. Just like some people can exercise or can climb mountains or swim fast or practice piano or anything else. Just because it burns one person out to work 7 days don't assume that it burns everyone else out to do the same. If you are exceeding your limitations and can't take it don't assume that everyone feels the same way (although they might..)

Working 7 days on extrinsic motivations is soul destroying.

Doing the same on intrinsic motivations is life affirming.

There's also different types of work. Manual labour can be done for long hours - if you're young. Mentally intensive work can be done briefly for long hours, but it rapidly stops working well. If you work is more about connecting people and motivating them, I think it's a bit more scalable, especially if you can feed from the emotional energy of interaction.

"Working 7 days on extrinsic motivations is soul destroying."

If being in the moment isn't its own reward, that moment only pays off when you get the reward at the end. If you need to put in too many of those moments, no reward justifies it.

If your work isn't playful, all work and no play makes Jack a dull boy.

Good luck selling that line when it becomes more profitable to outsource or eliminate your position.

Does this exist in software development? There is always more work to do than there are people to do it (wherever I have worked). If I clearly goof off/don't work friday while others struggle to push us to our goals, I will not have a very good relationship with my team. Our team philosophy is that if you finish early, then you help others out who are struggling. I'm all for working less hours, but there would have to be a perfect storm of events to make it a regular thing, including a push from management to make it the culture.

I don't think it's fair to blame this on bean-counting or crazy managers. Many of us are salaried and don't have people scrutinizing our hours worked.

That's a failure at the management level, not the developer's level. Expecting developers to make up for the management failure will work for a week, maybe even a month. Then attrition will rise, overall productivity will fall, and the team is screwed anyway.

It is quite literally management's job to identify what needs to get done when, and to ensure that they have the proper resources to get it done. If they can't hire, then they need to triage between pushing their workers harder now at the consequence of loosing their productivity (or the workers themselves) later, or pushing out the timelines.

The problem is that most managers don't understand the tradeoffs involved, because we as programmers don't provide the proper feedback (or they're just bad managers and don't listen to feedback that's provided).

> [...] I will not have a very good relationship with my team. Our team philosophy is that if you finish early, then you help others out who are struggling.

It sounds like management has been able to use group dynamics to create an unhealthy working situation. These kinds of attitudes typically come from above, not below. The problem which will arise from this situation is going to manifest itself as the "early finishers" dropping their productivity (why bother working hard when all I get is to pick up after my co-workers), burning out, or they just plain leave. Have you seen any of that yourself?

Try providing feedback up the chain that you need more workers for the given workload. You'll learn a lot from their response.

Sure, there are plenty of cases where management has unreasonable expectations. I'm not talking about that.

And it is often not a 'management' at all. I have side projects I'm working on. I can watch TV at night, or work on the project. I have a limited budget (time) and if I don't spend it on the project, the work won't get done. It's my equity, it's my labor, it's my project. If I'm rested and able to work, but choose not to, well, I end up with less as a result.

Management don't necessarily accurately know how much effort the work will take. They can ask developers to estimate this, but even then it will not always be accurate.

The crux of movements like the agile movement (and management processes like scrum within it) are to make things more process orientated - management ensures employees work for x hours a week following a process, and adapts based on what output they produce (increasing resources if they want more output).

Product orientated processes (where managers tell employees they have to produce y output, and after that they can slack off or go home if they want to) might work if someone's job is to sit on a production line doing a well understood process, but it does not work well for software. I think both businesses and developers are better off for the trend to abandon such processes when it comes to software.

Given a process orientated environment, it is the prerogative of management to make sure everyone works as close as possible to their contracted number of hours - someone who is working less should rightly get called out on it. They may have finished their current task, but they should help someone with their task, or work on improving processes / infrastructure / addressing tech debt to make likely future work easier.

Not everyone needs to work the same number of hours in a process-orientated environment, but if they work less, that should be in their contract (and most likely they will get paid less than they would have if they worked longer) and not just the employee unilaterally deciding that.

Or they listen and empathise, but their budget comes from above and there is nothing they can do.

The deadlines come from above, too.

Note, this is a subtly different response from "We will have to do more with less", which is manager-eese for "I've been shut down by my managers". That said, in either case you should probably be ready to jump ship (though in the second case, your manager will probably be willing to give you a good reference).

More manpower, more money/pay or more time off isn't the definitive answer to problems.

At the end of the day, an employee who is as rigid as you present yourself to be is the kind you hope jumps ship ASAP. It seems like you are the austist type who would complain that they wont be getting a greater variety of snacks in the break room because managers said "We will have to do with less" after being shut down by their managers.

Personal attacks aside, how would you solve the problem, in a way which won't result in churn or reduced performance?

Now, I do have to admit that for certain companies (such as EA or the Financial sector), this technique works fine. They will hire a developer who is "passionate" for the work (writing video games) or for the money ($250,000+ a year), work them for 80 hours a week for a year, and when they leave just replace them with another "passionate" developer who is waiting in the wings.

Any manager who consistently pushes their team to work 50+ hours a week is probably not doing their job correctly.

On the other hand, in a startup particularly there are always certain cases where everyone has to work 80+ hours a week for a while (ex. this is the closing date of the acquisition; for every day you delay integration, we are losing thousands of dollars in revenue.)

Good startup management is threading the needle between the two.

For instance I tend to be put on larger umbrella tasks which take a few weeks. It isn't uncommon for me to wrap up a little ahead of time - sure there are things I could do but usually because of the way things have been planned there are other pieces of that puzzle which aren't fully in place either. So I'll poke around a bit but take it easy for that day or so. Sure, I could jump in to help someone else out for that day but is it really worth distracting that person to get me up to speed with what they need and what they're doing for what would amount to a few hours worth of work? Not really.

The flip side of this is that when one finds themselves in a position where the deadline is going to be difficult to meet there's an expectation that extra time is put in to make it happen.

As long as the two are happening roughly the same it balances out anyways.

Give engineers the discretion to take on what they deem reasonable and trust them to finish it.

So if we assume that all the programmers are honest (which I do), then I can't just say "get this done by Friday." But I can say, "So you think this might take a week? Okay, I know how hard it is to do estimates, so please make your best effort to reach that goal, but if problems crop up, let me know and we'll adjust the schedule. Or if it turns out to be easier than you thought, let me know that too, and we can find another fitting task for you to tackle." Regardless, it only seems possible to ask a certain amount of time and effort from a programmer since that is the basis on which the schedule is created. Now I fully acknowledge the ideal amount of time is likely less than 40 hours a week. But still, it's the most a person can comfortably get done in a certain amount of time that we're paying for.

How else could it work? I fully acknowledge there may be better alternatives, and I'm glad to read about them. My only caveat is that such suggestions would be best if realistically applicable to full-time employees, which is short-term-unchangeable situation I'm in.

More specifically, give them a list of things to work on. Have them give estimates, silently apply the "Scotty" factor, and base their performance against that.

The list means that they are never short of work to do, so our ideally motivated candidate will always be working towards the company's goals. This list should comprise of at least one easy thing "I can do that in an hour", one "less than a week" project, and one "greater than a week" project. This provides your developers with a bit of variety, so they don't get burned out on trying to grind through the tough problems. It also makes them feel like they're making progress by letting them knock out at least one project every week - this can be very motivating.

The Scotty factor (development estimate * 3) will give you a more realistic idea of how long something will take. I use it on my own estimates, and it's accurate more often than it's not. You can use this to gauge both their skill at estimating, and as a measuring stick for identifying when they are underperforming (getting a second opinion on an estimate can help identify the underperforming part).

This does mean that you won't be able to look at the output of a given day/week and gauge a worker's performance just on that. However, you will be able to look back on a month, six months, or more, and get real data with which to identify the exceptional performers and those who need help (and perhaps even those who need to be let go).

So far, my strategy goes like this: rather than pressuring a developer to give me a more optimistic timeline, I instead do the opposite, I encourage them to really consider things that may go wrong. I'll sit down and try to talk about the potential overlooked risk. I try to understand the assumptions they're making, to help them become aware of the assumptions they're making. Are they assuming the data feeds they're counting on are available and easy to integrate? Are they assuming a certain amount of support from other departments will be available when they need it? Are they assuming they'll be able to understand and work with an existing code base before they fully immersed themselves in it?

This doesn't just improve your odds of getting a more accurate estimate of time-to-project-completion, I find it reassures the developers that you really do understand the difficulty of understanding and estimating a complex task.

I meant butt-in-chair time, not project completion time.

THIS.

But I understand companies. When they won a cash cow, they want to milk it.

A good dev can either slow down, till he's as fast as the others and keep chilling the rest of the time, or, get more money for getting more things done than other devs.

Suppose week 1 you tell me to get X done by Friday and I finish on Thursday. Perhaps I get Friday off, slack off or whatever.

Then on week 2 you tell me to get Y done by Friday and on Weds I realize that's not happening so I end up working an extra 8 hours over thurs and fri to make it happen.

What's the difference?

(Yes, I realize that this is an overly simplistic example, but hopefully it conveys the point)

I'm in a similar situation as you, one of an upper echelon of devs and while nothing is ever official sometimes increasingly there are people "under" me on any given project. So because of that, the tasks that I'm holding in my mind and have deadlines for tend to be longer running - not the typical 4 hour sprint ticket.

If I was fresh out of college and simply pulling stickies off the queue I'd likely have a different take on things. In those situations it's literally just a matter of doing something and moving on to the next something. My personal experience these days is different, it takes a little bit to shift gears and move on to the next thing, it's not as simple as simply grabbing a sticky.

I think it does have an unfortunate cooling effect though, in that, if they're paying you for your time there's no particular reason to put in extra effort to do things faster or better (other than personal pride and the nebulous possibility of a raise somewhere down the line).

There's been times I've gotten my entire sprint done in a couple days, only to get rewarded with... more stuff to do. That's not a criticism, I mean, that's the employment agreement I signed up for, I'm expected to do stuff 5 days a week, but I imagine that if I could get a sprint done in 3 days and then take 2 days off, I would be more motivated to get that stuff done quickly, and then QA would have more time to test it, and so on.

It's like the good old "Don't push on a Friday", except now "Friday" can be Wednesday or Thursday.

I imagine that there'd be more than a few of the less scrupulous devs who would push stuff earlier than they should (which creates more work for everyone downstream), to get the promised day off. In any case, if you do find yourself with extra days left-over in your sprint, why not tackle some tech debt or documentation, things that are usually lacking?

Remote from anywhere in the world has a lot of issues. The benefits are well known. Time flexibility and it forces management to focus only on results. However, doing face to face meetings is extremely difficult due to distance. Even tools like skype and hangouts are not effective when big time zone differences exist. Face to face communication has a lot of advantages and it's missing in this kind of workplace.

Forcing everyone to be in the office everyday also has a lot of issues. Going to the office and staying 8 hours or more regardless of productivity is a waste of time. There is also the wasted time commuting and it allows management to be lazy by focusing on hours in the office instead of actual results.

Allowing remote anytime anywhere, but hiring only within 50 miles of the office has the advantages of both. Face to face meetings are easy to schedule since everyone is only 50 miles away or less from the office. There are no time zone issues so skype and hangouts are very effective. It also allows all the flexibility of working remote.

If John is working only 4 hours coding everyday and gets stuff done. He can do double in 8 hours. So I should ask John to not goof around and focus on getting more things done.

So the challenge seems to be finding the ideal and somehow getting management to understand/believe it.

That's why every technical manager should have a technical background.

Has it genuinely been studied in a meaningful way, and this was in fact the conclusion?

http://skeptics.stackexchange.com/questions/14028/does-worki...

For myself, it's absolutely the truth. I do not get more meaningful work done in 8 hours than I do in 6, or some days, 1. I spend more time thinking about design and implementation than I do coding, and thinking does not require me to be at my computer, or even in the office. The only benefit of being in the office is the ability to BS with my colleagues (and occasionally it's even about work!).

If you're the owner, you're the one setting the goals and timelines. If your team seems to easily meet your expectations, then yeah, you're justified in pushing them a bit. But if they can't keep up, you have to make the choice between hiring more people or easing the expectations back to where your existing team can complete the tasks. There is a third option: push harder and expect more from your workers, but the tradeoffs from the short term productivity increase is just that - short term - and detrimental to your business in the long run.

More specifically, if person A can get `N/2` tasks done in a week (where N is the average velocity), and person B can get `N * 2`, reward person B, set up a performance plan for person A, assign out tasks appropriately, and move on with life. If you really need `N * 5` output every week and have four employees, hire another employee. Don't keep giving person A N tasks and expect persons B, C, and D to do their work plus person A's.

EDIT: Formatting fix

This is a simple question with a very simple answer: Because if you can get your work done in 15 hours, that means you can handle more work. I can't think of a single project I've ever worked at where there wasn't bugs or backlog or refactors that I could work on during spare moments. What kind of place do you imagine working for that doesn't have these waiting to fill in time?

I would understand if I could work at top performance 10-12 hours a day, 5 days a week but that's just not possible for me. In the end driving developers to exhaustion is worse for everyone, with subpar code that'll probably require refactoring Monday morning.

This should not be a problem in a sane software development shop because there should be a way to track a) code reviews done b) tickets implemented/code merged /etc.

LOC/hour is a crappy metric for software development but averaging these over, say, six months should give some indication if someone is slacking off. Or just working in a different project than anyone else but task based variances ahould be accounted for. It does not give a "perfect metric" that could be used for perf evaluation but should be a sufficient safe guard against total slackers.

I would say that everyone is addicted to the thought that attendance == effort. It's just such an easy measuring stick to use when comparing the relative worth of two people.

<s> I mean, come on. That other lady might be "smart", but she leaves at 5, but I'm here until 6, so I deserve the raise, not her. </s>

This is very true. Personally I find that after a certain number of hours my ability to write good code and solve problems is significantly diminished. Although I would love Friday off personally I would find it more useful to finish at 3pm or 4pm instead of 6pm as that's when my productivity declines quickly. First of all that's a waste of my time in those final few hours as I'm getting much less done. But for the company I think if I had an extra few hours every evening I would be better rested and prepared for the next day and probably more productive in those first 6/7 productive hours.

I would be very happy to do 75% of my current work for 75% of the pay. Unfortunately things don't scale like that for a number of reasons. E.g. a team of 8 people working at 75% will not be as effective as a team of 6 people working at 100%. Coordination is costly, and the fewer people can get a job done, the better.

The overwhelming majority of people are in a situation where such a practice isn't possible. Jealousy is a very, very strong emotion, and leads to the crab mentality.

http://en.wikipedia.org/wiki/Crab_mentality

You see it in any sort of "someone has a better situation than me" post.

These people probably work their ass off during their 40, 60, or maybe 80 hrs on the job. So they dont understand when they ear that startups' work schedule is more relax because they cannot relate to it. However, when they leave their desk, it's over, they're up to something else and they probably even force themselves not to think about work anymore.

Startups take a relaxing approach to work hours because the (right) person who works there lives and breathes startup 24/7.

It's easy to say when you're a founder (disclaimer: I am one). But it is something I have witnessed in (good) startup employees as well. They think about it all the time.

@falcolas is right, who the hell cares how many hours in the week you spent executing your tasks? Shouldn't the time "thinking" about work be valued as much as "executing" the work? Don't we all "think" better outside of execution time?

And I don't mean that in a workaholic sense. I mean that if that anything arises or emerges, I respond to it immediately out of genuine interest rather than out of obligation. It's just the way things are, I think, when you're that much closer to the "value source". (How I choose to think about it.)

Things like rigorously structured work days are constructs that can only exist in large companies. I'd use a naval metaphor: If you're working on an Aircraft Carrier or a huge Cargo Ship, you can take sick days, you can operate tight schedules. If you're working as part of a small team on a little rowboat, though, the concept of a schedule itself is rather ludicrous– just mutual fiction.

The real schedule is closer to "do whatever it takes to get it done, and take whatever breaks you need to stay fighting fit".

Early stage startups are a sprint, startups like Treehouse have a proven business model and are now basically dealing with scale and optimization, they can go into a well-deserved "regular job" mode with weekends and family time. If you want a 9 to 5, do not do a startup, unless you have something absolutely incredible in your deck that will allow you to bypass the "work crazy" stage.

Also early startups aren't all about coding. There's a lot of other extremely beneficial work that can be done once you've reached your coding quota for the day.

Nobody wants to hear this, everybody wants to work 4 hours a week and be billionaires, so this inaccurate mythology gets propagated.

The clock isn't ticking that fast. I have some experience here . I was the second technical hire at a company that went on to sell for nine figures. I founded an unsuccessful company. My second startup (as a founder) went on to be a successful and ongoing thing (revenue in the 7 figure range). For the last two years I've been with a nicely growing early stage startup.

I'm throwing out my resume to establish that I'm coming at this with nearly 15 year of startup experience.

I've rarely put in more than a 40 hour week at any point in my entire career. While I understand the idea that you are racing to product market fit.. I've never bought into the idea that effort is the thing that drives it. You need to be focused. You need to work hard, but you also need to keep your mind and body fresh. It's more important to produce great work at a reasonable speed, rather than bad work really quickly.

Those pre-PMF days aren't a sprint. They are most definitely a marathon, just one with a clear finish line. When I think of great early stage teams I don't think "high output", but instead I think "methodical" and "relentless". They are constantly analyzing the problem they want to solve. They are clever about soliciting feedback. They build prototypes leveraging every useful shortcut they can. However, few of them (again this is my experience) approach these early days with 60 or 70 hour work weeks. The benefit just isn't there.

That is what meditation is supposed to help one do - in a sense :) - thinking when you need to, none when you don't.

Once everything fits together you just do it.

> "But he soon found himself working that same intense pace until his wife asked him why he was working more and making less. She suggested taking Fridays off."

So the central concept of this workplace format, around which this entire article is based, was the idea/inspiration of Ryan Carson's wife, whose full name is not even mentioned. (Her first name is Gill, but is her last name Carson? Unclear from the article.) Not that it's a purely original idea---other companies have done four-day workweeks before---but it was obviously one that hadn't occurred to this particular founder. Three cheers for Gill possibly-Carson!

> "With Treehouse, Carson said he hopes to, again, buck conventional start-up culture, and not cash out by selling the company, the brass ring for most start-ups, but continue to run it as a sustainable business."

Let's hope that also starts a trend. I'm so heartily sick of companies building a great product and actively recruiting user bases to use and love that product, only to shutter it and throw all the users under the bus when the founders achieve their real goal, which is getting the attention of Google or Facebook or whoever and getting acquihired or otherwise bought out. I know that individual founders and other startup workers will often (indeed almost always) say that they really do care about their users, but as a collective structural pattern in the way that SV startup culture seems to work, it sure doesn't look that way from afar. So three cheers for (the currently-stated intentions of) Ryan Carson!

Yep, Gill Carson. It does suck that they didn't give her more credit. Gill's had a lot of positive effect on Treehouse.

I think the general assumption when two people are married is that they have the same surname. I know this isn't always this case anymore but it seems to me that it's so common that if her surname was different they should point it out but that it's unnecessary to do so if it's the same.

Fast forward five years from now. There are going to be a ton of tough competitors in this space and eking out revenue growth month over month is going to be much harder. However, in five years they probably have the added pressure to start thinking about something called profitability.

The going is going to be a day of reckoning here when the harsh realities of cut throat competition set in. That just hasn't happened yet.

We don't talk publicly about finances, but let's just say that's something that's been thought about already and that bit of what you're saying doesn't scare me.

> There are going to be a ton of tough competitors in this space and eking out revenue growth month over month is going to be much harder.

Codecademy (free), Code School, Pluralsight, Lynda, Udacity, Coursera, Udemy, free online content. Things are already tough, and they get tougher every day. We have an amazing team that works like crazy, 32 hours a week, because we believe we're uniquely situated to work on this problem. So the competition thing won't magically appear. It's already here.

It's a competitive advantage to offer less hours and more intensity.

When the 40hr work week came in, it was in part pushed by industrialists because it produced higher productivity than longer hours. That was for relatively low creativity work.

Every investigation that I know of that has looked at this matter finds that working more than 40hrs a week gives you a relatively short boost (2 weeks or so) and within a few more weeks, you're producing less over your 60hrs than you would if you'd just worked 40 the whole time.

It's quite plausible to me that this is true for 32 hours too for particularly creative jobs.

It might actually be an advantage that helps them defeat the cut-throat competition to work a 4 day week.

Soon enough everything is a commodity and the Amazons and WalMarts of the world hire managers who's only possible goal is to eke out that last 2%.

I wish it wasn't like this, but I can't see it being otherwise.

Because so many of our team members are either remote or working from home any given day, we're often meeting via Hangouts, and that helps a ton with time in meetings since you really just don't want to be on there too long.

I spend what feels like a lot of time in meetings, but it's probably like half of each day for me, and maybe only half of that is scheduled. For most of our developers and designers, though, I think it's probably a couple of 15-30 minute meetings each week tops.

Also, can you hire me? :)

You tell me.

Do you have any opinions about optimal work spaces?

I think a lot of folks, once breaks and all are accounted for, probably work 6-7 hours in an 8 hour chunk, and that seems to work pretty well.

> What percent of "working time" do you think consists of actual "work"?

See above :)

> Do you have any opinions about optimal work spaces?

I like a clean desk. I like to stand more than I sit. I like to be in a spot where I can walk freely, and I go outside a good bit during the day, even in our lovely Portland rain, to think. I think the best work space is probably always the one you want, and over time what you want changes. It's iterative.

We have folks on our team that like working from home. I like working in the office. Some of our team sits on the couch at the office with their computer in their lap, and that seems crazy to me. So yeah, whatever you want.

I think a lot of managers on Earth spend a lot of time trying to get folks to 8/8 because that's their job, but that's not a job I'm all that interested in. There are way too many hypotheticals around it. Let's say you don't look at HN for a few and instead keep cranking. Is that extra crank time as productive?

If you were on my team I'd want you to be the most productive person you could be, but I'd bet (maybe I'm wrong) that how you communicate with others would be a lot bigger issue than your HN reading time, and we'd probably talk more about that. How you tested might be a bigger issue (I'm assuming you're a dev or designer here). Or how you shipped even though CI failed.

In my 15 years of software experience I've seen a lot of folks do a lot of weird stuff at work, but reading a website for 15 minutes has seldom been the main reason they weren't a top performer on the team.

As the founding engineer at my current startup, I have tremendous flexibility in setting my own hours but I willingly and intentionally work 60+ hours a week. Not because any manager pushes me to. Not because I even have to. Simply because I genuinely enjoy it.

Indeed, work is probably the most enjoyable thing in my life. On a given Friday, I'd rather be building products at work than watching a movie or engaging in some other leisure activity. Some of us don't have wives, children, or friends—we just want to spend our time executing.

Would Treehouse be accepting of that? If not, they're just choosing to enforce a different paradigm of work rather than giving their employees true freedom.

And then, I go backpacking or bike-riding or something that tends to be demanding physically and relaxing mentally—I find it helps me keep a healthy balance. I know there are plenty of people that don't crave that reprieve though, and that's totally okay as well.

There's weekends where I'm working on a particularly interesting problem where I'll work through the weekend because I want to. The big difference is the extrinsic pressure is missing. Nobody has to.

So if this perk gets Treehouse talent that is +30% more productive, even if they lose -20% of productivity from Fridays off, they still win.

One caveat, so much of programming is loading things into your head, I think three days off every week would be difficult for anything sophisticated being developed.

This assumes that your wife is not working. I've tried taking some days off like this and, in the middle of the week everyone works, so you don't get to hang out much

But I'm no martyr. If you think Friday with your family is awesome, you should try having Fridays with almost no responsibility sometime. It's pretty great.

Before I had kids, this wouldn't have mattered since you already have 2 days a week you can do whatever you want. Having 3 free days a week vs 2 is not really that different. But after kids, and working 5 days a week, I had 0 free days a week for myself. Going from 0 to 1 free days a week is a HUGE difference.

Efficiency is key, not some arbitrary limit of working hours.

Chances are yes, as a founder you aren't going to work just 32 hours a week. But it also depends on the state of the company.

And quite frankly, sometimes you can't solve problems by sitting at your computer or even talking to others in the office. Sometimes it involves taking a break and chilling out or exercising.

Too bad they don't have a need for a front-end engineer right now. I would be all over that.

Keep up the good work, guys!

In my fifteen years of tech work, the only occasions I had to work overtime were those when somebody screwed up. It was often because somebody didn't say no to requests for: CYA meetings; last-minute scope changes; mandatory "butts in chairs" policies.

Thirty-two hours a week doesn't give lousy management enough time to take root. Like kvcrawford, I can't overestimate how appealing that is when it comes time to recruit.

I ask because I would love to implement something like this, but we get requests for service or user questions every day - and a three day turn around time on a user issue is terrible customer support - especially if they have other work riding on it. I realize treehouse is different in this respect.

It seems like the more employee focused you are the less responsive to customers you can be.

We did this in the military and would rotate who had Watch/CQ/duty[1]...

[1]http://terminallance.com/2013/08/15/terminal-lance-286-duty-...

Silicon Valley is a successful environment for startups because it has many unique advantages that have nothing to do with working harder - see pg's numerous essays on the subject. "Hard work" (defined as long hours and obsessive focus) is not the key ingredient, because people work hard everywhere. I watch people do startup-like hours in the sluggish old enterprises that baffle startup folks. Concentration of money and experience? That matters.

Think about the utility function of hours worked. What's the relative productivity of the 50th hour of work this week, compared to the 10th? At what point does exhaustion and overfocus actually hurt rather than help productivity? It may be earlier than you think. If I'm only 20% as productive on the least pleasant working hours, why am I even doing that to myself and the people who love me?

Work is a marathon, not a sprint. If you sprint in the middle of a marathon, you'll get a slower time overall, because you're draining too much energy. Likewise, an all-nighter or two of coding will hurt you for days afterward.

Work smarter, not harder. People who brag about how smart they are should understand this.

So what is it...32 or 60?

The only answer can be "it shouldn't matter!", if you work in an industry where you can just as easily work from home as work from your desk.

I am speculating, but I would think that most of the IT developers at Treehouse work well over 40 hours a week.

[edit] see bdcravens comment for the idea I was trying to express.

Huh? How many hours I work has very little to do with whether I can work from home. If I'm expected to work 60 hours/week and have the option of working from home for all of them, that's definitely still a problem.

Some managers (or even people hiring contractors) think they can get around this, but, ultimately, you can always do in 4h what they expect you to do in 8h and get paid for 8h. Not saying it's moral, but it is the reality. The conclusion is inescapable: working from home implies that the only important metric is the quality of your work (and the deadline), not how much time you spend on it. Because you can "simulate" one with the other.

Some people don't realize this, yet. Doesn't make it not true.

EDIT: PS: I'm talking about project where the "deadlines" are reasonably far apart and predictable. Say, no more than a few times a day. If your work includes being on-call and responding to incoming requests, that's a different story.

I can do that, but I won't. I value my integrity. So to me, it definitely does matter if I'm expected to work 8h as opposed to 4h, even if I can work from home.

My speculation had to do with believing that most IT employees, given this situation, would "work", at job related tasks, for over 40 hours anyway.

Personally, if a job that paid me for 40 hours a week expected me to work 60 for more then perhaps once or twice a year, I would quit instantly, so I've never understood the "mandatory 60-hour" meme.

Perhaps this is where our wires were crossing.

If this is a "nudge nudge wink wink we don't really work 40 hours when we're working from home" kind of thing, then why make the pretense of working 40 hours?

I value my integrity. When I say I'm working 40 hours, I work 40 hours. If "working from home" is implicit permission to lie about how many hours you work, then that creates a system where dishonesty is rewarded and honesty is exploited.

And if it's a "it's a little nicer to work from home" thing, then I'd say, not really. I would actually rather not work from home--my home is my space, where I can de-stress and do what I want. I currently work at a job where I "work from home" and I actually have an office I rent for myself so that when I go home, I'm actually not working.

The battles on extending days we're dealing with are things like getting pinged through HipChat because we're across 5 time zones and avoiding email at night, not forced extra work because you work from home. I'd ask some devs and designers from the team to talk about it but it's Saturday, so they're not working.

Folks are expected to work 32 hours per week, although if you get technical and throw in PTO and holidays they're actually expected to work 28.9 hours per week.

My objection isn't to systems where there is a clear, honest expectation set. My objection is to systems where people say, "We don't give much time off, but you get to work from home a lot. Oh and we won't be able to verify if you don't work the 40 hours we expect, nudge nudge wink wink."

It sounds weird, but the latter is all-too-common, especially at startups.

28.9 hours * 52 weeks ~= 1500 hours

---

37.5 hours * 48 weeks ~= 1800 hours

37.5 hours * 47 weeks ~= 1760 hours

37.5 hours * 46 weeks ~= 1725 hours

37.5 hours * 40 weeks ~= 1500 hours

So even if you have 4 weeks off and 10 holidays, Treehouse still expects ~225 hours less work per year, or the equivalent of having 10 weeks off and 10 holidays at a normal 9-5 job with a half hour lunch. Treehouse likely gives 2 weeks off, 10 holidays, and 52 Fridays off :)

18 days (or 4.5 weeks) paid time off

1 week off for the holidays (in addition to paid time off)

https://teamtreehouse.com/jobs/at-treehouse-3b0b0839-71a0-4f...

Treehouse has managed to make a 4 hour week work since everyone is working remotely, so that social aspect is not as prominent and consumes less time. For people who have kids spending time for the kids becomes more important than the social experience at work as it should. The 4 day work week all of a sudden makes sense since they have bundled those 3 hours / day of a work social time into one day of a kids time.

Employee culture is important but to be honest I only care about how well the founders are executing their original vision then all the yoga classes, free food, Friday's off, beer pong, maid service and other things companies are offering.

32 hours a week is nice for some but that doesn't always equate to marketplace monopolization.

Then again since Treehouse is competing with others this may not be their goal anyways.

Of course since I'm a cofounder I work pretty much 24/7 but such is life...

Now, that's fine for factory work, but as far as I know, relatively little effort has been put into testing that theory in knowledge jobs.

I would have been willing to accept the pay given the hours and other aspects of the job, but we didn't work out for other reasons.

It's only 8 hours less than the average work week so I'd expect the salary cut to be minimal.

Also, look at the number of companies that do/have done 20% time. If giving employees 20% of the week to do whatever makes them happy result in better productivity it would be fair to keep the salary the same.

It's not just startups. In my experience, most people spend a good portion of their time playing around, chatting, doing stuff that doesn't matter to appear busy, etc etc at work. Then they come home tired. It doesn't really make sense.

I think the fear is, if hours were reduced, people would still would tend to do the same types of things. So, it appears the standard setup is underpay, overstaff, keep everyone there more hours than they need to be, and assume at least some of the people are working some of the time.

I don't think they said anything of the sort. There's no claim they don't have enough work for 40 hours; I'm sure like most of us there is no end to the work, and it can and will consume all the time we're willing to give it.

They're just not willing to give it as much. It's possible that will put them at a disadvantage to their competitors. It's also possible that they may be sufficiently more creative to overcome that disadvantage.

Look at the moron below who calls "up on toes" as corporate slang. NO. It's not a corporate slang, rather a pursuit of a start_up to beat the rest.

Hopeless! This site used to be quality. Now it's full of sheep with one-track mind. My last note here. Go ahead vote it down, enjoy your dumb echo-chamber and live through your satisfaction.

Bye.