It depends on the work you are doing and how good your team is at managing what needs to get done. We know who our clients are, what features they want, and how to think about adding those features in. That's pretty much all you need to focus on when it comes to software. We make sure to bring in and keep those who understand those core facets of the business and understand what should be a priority and what shouldn't.
In startups that become stressful, the main problem I have seen is an ungrounded management team that doesn't quite know what they want the business to look like in 5 years, so every other week - surprise! We've got a new client and they want X, Y and Z by tomorrow, so get working! - that never results in low-stress work.
I think that if you only do a few hours of actual time working each week, you are deceiving not only your employer but yourself about what is productive and whether you're a good employee.
There are no good metrics for programmer productivity, but spending < 20 hours a week actually switched-on as a full-time employee is obviously a problem, to me.
I honestly doubt any one who says that they are productive for 40 full hours a week, or even 6 hours per day. There's a lot of downtime that employees usually do not notice from a first person perspective. Even still, the goal of IT is first and foremost to empower business goals through technology, one of the main aspects of that is increasing workflow efficiency and throughput of the rest of the business processes - in other words, make good software so the rest of the business doesn't have to work so hard.
I have definitely met workers who I've given a task and they produce sub-average work and, when confronted, give me the spiel about they worked "so many hours on this" and how could I "invalidate the time they spent".
At the end of the day, as long as you are doing the job at the pace I need you to be doing the job, then I don't care if you did it in 1 hour or 8 hours. If you want more work, ask, and if you're spending too much time on a task, then there is a communication problem as a team member should have caught that you were on the wrong track.
In my experience, focusing on hours worked has never produced quality work.
The goal of work is to intentionally decrease the amount of work you have to do to achieve the same tasks. Why pay you when I can find a person who will do the same work you do in less time?
I think what you're arguing is that employees should always have some work to do, which simply won't be the case in every industry
What I'm saying is that if I manage to build enough tooling to streamline my work so it takes me twenty hours of "at work" time instead of the forty it used to, then under the standard full-time employee arrangements, I have an obligation to use the remaining time for other tasks, like finding a new corner of the company's workflows I can help optimize and streamline.
I've never seen a system that was even close to perfectly designed or optimized. You can always find more to improve.
Yes, there are diminishing returns for any specific corner, and there comes a point when the increase in risk from doing further deployments is not worth the shrinking business gains for optimizing a given corner, but I strongly believe there are always more improvements that can be made, both at a small, focused level and stu the big picture level of what systems should even exist in a given company.
You don't though. If you become 40% more productive, you should be paid more. Quietly taking that time as part time hours, instead of staying full time and getting a promotion+raise, is fine.
In startups that become stressful, the main problem I have seen is an ungrounded management team that doesn't quite know what they want the business to look like in 5 years, so every other week - surprise! We've got a new client and they want X, Y and Z by tomorrow, so get working! - that never results in low-stress work.