Unpopular opinion: Weekdays/weekend split isn't for everyone
twitter.com
twitter.com
Not mainstream, but I think the idea has been popular for a while [1].
>6.4
>A manager went to his programmers and told them: "As regards to your work hours: you are going to have to come in at nine in the morning and leave at five in the afternoon." At this, all of them became angry and several resigned on the spot.
>So the manager said: "All right, in that case you may set your own working hours, as long as you finish your projects on schedule." The programmers, now satisfied, began to come in at noon and work to the wee hours of the morning.
>Much more difficult for collaboration especially for small questions
>Bad workers exploring nice policies
Pros-
>I can sleep/think about code without being paid. Making my solutions lower cost and higher quality
>Happier employees
>Potentially less micro management needed
As for people exploiting it, you should measure relative performance and not but time
One of my first startups I worked had a noon-4pm core hours. You had to be in by noon, and should stay until 4pm, the rest was flexible. I thought it worked really well for both early risers and late owls.
This is also easier said than done. How do you measure programmer performance? LOC is obviously not a reasonable metric. Closed tickets isn't either. It takes an experienced manager who understands code to understand what work is actually being done, and managers like that are rare and valuable.
- the company restaurant closes at the normal time (or all good stuff is taken)
- you still get that condescending look from early-birds
In contrast, early-birds act superior while you are there.
I definitely never got any bonus points for being at work before my boss.
As a result, there were people that worked 6am to 3pm(ish), 10-3, followed by 7-10 in the evening, 11-8, etc. I had a young child and handled school dropoff, so my hours were roughly 9am - 6pm. My boss, the CEO, was a workaholic who arrived around 10am and worked to whenever. I spent an amazing amount of time dealing with "where is everyone?" sorts of questions, despite the team running fairly efficiently and still completing work on aggressive schedules.
The solution was literally “come in any time you want as long as your projects get done” - what’s your objection? That everybody who wants to come in at lunchtime, and work until the small hours force themselves around your schedule because you have a family?
Even jobs that are quite flexible are going to want some overlap time and, even if an atypical schedule allows for a few hours of overlap, the reality is that people will get tired of always having to schedule around your preferences.
Only a very small group of people are going to have a strong opinion about how other people should organize their work life. They mostly won't care. I suppose lots of managers will be in that group, but work is organized around weekends for lots of non-arbitrary reasons.
Needless to say, this didn't work as intended, and the workforce was split between those who didn't care about it (higher ups) and those who maxed up their meter by overestimating their tasks' story points.
The purpose of this system is to provide the team with a powerful tool that it needs in order to set a realistic timeline on team deliverables, such as a launch milestone or a new feature. The ability of the story point methodology to have predictive power is destroyed when people are incentivized to gamify it.
1/ the team’s composition at a point in time (and all the variability that comes with this)
2/ the team’s dependencies (a kind of exponential effect is at work here: the team’s dependencies also have all these issues in variability and so do their dependencies)
3/ the type of work being estimated in the context of the product (even “basic” things like “CRUD” can be quite intricate in some cases)
Basically unless the estimation is literally for a known change (e.g. modify source code files X, Y and Z with code changes A, B, and C) its predictive power diminishes substantially.
It’s not a powerful tool, it’s a micromanagement technique disguised as a tool to empower ICs.
Having a concrete plan ("micromanagement?") for getting to the finish line is important, and the story point methodology is an intuitive tool for figuring out what lengths the tasks need to start out with on the timeline.
It's entirely possible to provide meaningful estimates of both complexity and time-to-implement without resorting to story point formulations or any particular PM framework. "This will take about 6 weeks and has a few dependencies and unknowns that make it moderately risky to take longer." Rephrasing that as "This will take 3 sprints and has a story point value of 8 points per print" doesn't add any value, except from management's perspective as a way to put some "objective" quantification to the problem of estimates and deliverables.
When not focused on just one objective and not under deadline pressure, the team's average story point velocity per week was 30. This was when we tracked anything and everything we did. When we've track against a launch, where we only focused on the minimum set of tasks we needed to meet a clearly-defined objective with inter-team dependencies and a deadline, the team's average velocity has been 12.
We don't use story points alone in forecasting timelines. What we do is presume a per-dev weekly velocity of (12 / team size). With all of the tasks on a chart, we work with the team to assign tasks to individuals, and we create a strawman schedule for how all the work gets done to meet the timeline. The "length" of each bug is a function of (12 / time size). We track and reassess how all the tasks are coming along on a weekly basis, with the understanding that the "strawman" schedule will end up looking different than we initially project.
For example, take a team size of 6. Then the story points per week per dev is (12 / 6 = 2). Story points per weekday is (2 / 5). So for a task of size 3, we expect one dev to take ((5 / 2) * 3 = 7.5) days to complete, and so the length of the task on the timeline is (rounded up) 8 days.
Then we bring the "fudge factors" into play. For the devs who are more productive we tend to schedule them back-to-back with the tasks that are more urgent and/or are blockers. For the devs that tend to need more time, we keep a lot of whitespace between the end of their assigned tasks and the deadline.
The only time this methodology has gotten us into trouble is when we've caved to pressure by upper management to say we can actually do 15 story points per week or whatever. The most important thing is to measure actual velocity under as similar conditions as you can, and then refuse to accept any projection with a velocity other than you've actually observed. Story points are opaque outside of your team, and upper management is usually satisfied when you translate the story points into the schedule using the method I described.
That gives you both time (min, max, which is the information you need) as well as the risk (distance between min and max).
Then countermeasures could be taken to reduce the risk, until min and max are reasonably close.
Sometimes max is +infinity when there is 0 knowledge, but even that information is useful: missing a role or need research.
My main problem with points is the impossibility to represent: - A long task of 5 days that's very well known, it's 5 days of work - A short task that's very uncertain. It could be a one line change or many days of work
With time range, you can represent that and it's very visible. With points, you can represent that as the same points, but that does not reflect reality, one of the two estimates is potentially wrong. This also helps providing input on what research tasks should be performed and what's their value.
I've found that upper management doesn't care whether any given task actually takes 3 days when we estimate it at 3 days. They just want to see a schedule where each task is estimated to take X days. It communicates that you've really thought through the plan. Then, in terms of results, what they really care about is that we track to the date we committed to for the overall effort.
If a senior director is drilling down into a schedule and asking, "Why is this 5-day task taking Bob 7 days to finish?" that's a strong signal that it's time to change your management.
This can also give you a minimum and a maximum for when the project is done. This is actually very useful in large projects, because it lets you identify upfront what are the greatest factor of risks of a project.
It didn't want to be a discussion of how management is done, just to highlight that having a time range seems to provide more information to management, which is usually what's desired.
It would be hard to sell me on taking Wednesday off, but I can see where people with more obligations would get a lot out of an arrangement like that.
Any short term study will observe effects of people wanting to "reward" shorter working week and aren't really representative. This type of change needs a long "stealth" study period.
Only if you have Tuesdays and Thursdays off you won't be able to get a contiguous five day holiday with only two days extra off that can include any weekday (e.g., with a fixed Thursday off, you can't include Tuesday in your five day block without taking a third extra day off).
My wife and I both work four days a week and have Fridays off. It makes it much easier to get into the weekend mindset.
I’ve tried both, for extended periods and I ended up much preferring the Wednesday off.
I suppose there's pros and cons to either approach (which I haven't really researched at all yet) but to me right now breaking up a continuous stream of work days makes total sense (while still fitting for the 9-5 custom, which I, like many people, don't prefer but I haven't had any better opportunities yet).
Anyway, this tweet is really someone trying to turn the thought "I don't really like my work schedule"/"Some people don't like their work schedule" into something profound.
Your point about 911 call centers is true, but the principle is just that the work schedule needs to mesh with the job role itself. E.g. restaurants have to be open for meal times, customer service needs to be around when customers are around.
I can see how this issue would come up for creatives though. Some jobs have their hours or shifts dictated by the complexities of the profession: for doctors and nurses, handing off patients to new caregivers can be complex and it’d be easy to lose information in the process: the marginal utility of keeping the same person in charge vs the marginal risk that they’re too tired and would make a mistake is something that’s being studied. For creatives, the 9-5 seems to be much more akin to a vestigial organ than a system driven by first principles.
I ran a team of software developers, system administrators, and a help desk. The software devs had near complete freedom of scheduling, the sysadmins had a little less, and the help desk had almost none since they needed to be there when the people they were helping were. Everyone had as much flexibility as their job allowed and it worked great. It sucked that the help desk didn't have the flexibility, but they understood why, and I tried to find ways to provide other perks. Plus on the flip side they'd never find themselves trying to resolve an outage at 1 in the morning on a Sunday.
I believe that's because as time rolls we assign minor duties to ourselves for the weekend, and that weekend becomes just another time of work filled with worry and a sense of obligation. An unplanned day off, by contrast, has no duties.
Now if only I could replicate the same sense of freedom on the regular weekend I would be the happiest man alive.
Instead, especially in our more privileged profession, you should be pacing yourself so that you are not utterly broken by Saturday. Then you can take a full two-days off and do whatever you want, there are so many more things you can do with a two-day off in a row that you cannot do with single days, from simple organizing dinners with friends to weekend getaways.
Also, huge numbers of people have to work at the weekends. From highly-paid doctors to fast-food employees. Presumably their kids understand.
You're right that kids understand but it's far from ideal when their schedules are so firmly fixed M-F with weekends free.
There are some days in the week when I'm not checked in mentally and very unproductive. During those days, I'm better served to either sleep more or do something light to recharge for the next day/later in the week.
And then there are some days including the weekend where I can code for the entire day non-stop and feel energetic.
I still think having standardized days for working and rest is best for the sake of having multiple hours of operation overlap (e.g. schools, most businesses and government operations).
If we standardize on seven day work-weeks then some of those benefits may be gone.
There have been a number of times in the current situation where it's been a nice day and the weekend has a lousy forecast and I didn't have any meetings or only had them in the morning. I've just told my manager I'm taking the afternoon off and would make it up on Saturday. TBH, I didn't even really need to ask. I'm not sure why this would be controversial.
The shift to Saturday has been mostly great. I get a full day of deep work when nobody else is willing to work (Saturday), and neither Monday nor Friday had meetings I cared much about. Being able to walk around on a Monday is way nicer during the pandemic. Again, I get that others can’t replicate it if they have other commitments — importantly, both partners would need to have this flexibility, and most children’s’ schools probably wouldn’t be up for it :).
The main thing as many are highlighting below is about overlap (and predictability for recurring meetings). I mostly work with people in US/Pacific, but also US/Eastern and somewhat less often Europe (London and Warsaw) and Sydney. So that’s already unschedulable anyway. People have been reasonably receptive to “oh, I see, yes you don’t work that day” though a good chunk ask “Do you really work on Saturday?” (to which I not only really work on Saturday, I probably get the most useful things done on that day).
But how would you synchronize the poor weather days of Seattle with the nice days the Bay Area?
Then again, it’s definitely something I miss from doing research at school. Nice day, go for a hike. Bad day, time to finally rerun those experiments. Sadly, I have way more meetings than those days...
it would be kind of cool to have calendar software which has a "bad weather" feature: correlate the 10-day forecasts of the required attendees, and pick the least sunny timeslot. mind you i'd also want the software to keep track of how frequently i've hiked, because even a sunny day of meetings is OK after a couple days of hiking. gotta mix it up. i'm sure this bin-packing problem has a reasonable enough solution :)