I think part of the problem is that an employee has a set of fixed costs (healthcare, hr, etc) that don't decrease as an employee works less hours.
Now if you can just get rid of the cold, maybe I'd move there..;)
As CEO you have shareholders, competitors, customers, blah blah blah all expecting growth or seeking to take your growth.
So to do this, either a) everyone works more efficiently, but how many will hold themselves accountable to this? b) you hire more people, but creates more organizational complexity c) you ask people to work more hours
Seems most companies would take C.
I have done this for a development team by agreeing milestones and targets for my team with both the developers involved and the internal customers. The devs are then responsible for hitting their targets, and notifying everyone else if they slip or are unable to meet them. The customers are responsible for notifying everyone if the requirements or context changes. I was responsible for notifying everyone if the priorities changed.
It then became the dev's responsibility to determine how many and which hours they needed to work to achieve the goals set, with some simple rules (like a maximum of 8 hours coding per day and 6 days working in a row). We had some weekly meetings that the entire team needed to show up at, otherwise it was their call. They could work from home or from the office, although we generally preferred office because of the network effects. If they completed a task early, they got to go home if they wanted (some didn't).
We got some flak from other departments because it appeared to them that we were never around, but they got used to it. The fact that we were consistently hitting deadlines was a HUGE plus to the whole thing; they could see this worked. As a bonus, we had decent support cover for some of the evening and night shifts as there were devs who preferred working those hours.
TL;DR: Don't measure people on how long they sit behind their desks. Measure them on what they actually do. Then set targets based on what you expect someone to do in a week. Then send them home once they've hit target. To grow the company, set harder targets.
But then do you find games emerge? For example, do devs sandbag their time estimates so they only get 2 tasks instead of 3 tasks?
And what happened when you needed 50 tasks done, but the time estimates from your team, combined with the cap of 48 hours per week, fell short of 50 tasks?
There are mechanisms like planning poker that help to prevent this. They still aren't perfect.
> And what happened when you needed 50 tasks done, but the time estimates from your team, combined with the cap of 48 hours per week, fell short of 50 tasks?
Most methodologies should see this coming except in minor cases. You generally have better foresight over longer projects. This can allow for some correction. Sometimes you just asked too much. Consequences are context dependent.
Who is the judge as to whether the target has been hit? Do you lay the rules in advance? That must be a lot of work just to define what needs to be done... When developing a new product the specifications are bound to change during development, how do you tackle that?
I am genuinely curious how you approached these difficulties and would love to hear more about it.
Generally speaking we kept each milestone small, ideally each dev would be hitting 1 or 2 milestones each week, not necessarily on the same project. I measured schedule time in quarter-day blocks and had a weekly 'schedule' that showed who was working on what each week. This meant our smallest schedule block was 2 hours... if it was a 5-min job we either did it for free or charged the customer 2 hours, which really helped reduce the mass of tiny jobs into manageable requests.
For new products we iterated a lot and involved the customer in specifying the next steps. There was one project that needed a lot of architecture up front, and that got a bit tricky as we had to spend a lot of time building with nothing to show for it, but usually we were able to do it in small sprints (this was before "Agile" hit our corner of the world!). This is pretty much a solved problem now.