I think it's a fair trade-off. I get my work done on my schedule, then help people get there's done when they need me - even if that's not "core hours". The benefit is no one cares if I spend sometime during the day running errands, getting lunch, or exercising - as long as I can respond to them in a reasonable amount of time.
Maybe this is true in some feature factory somewhere, but every tech company I've worked with has required synchronous collaboration to get things done.
> The benefit is no one cares if I spend sometime during the day running errands, getting lunch, or exercising - as long as I can respond to them in a reasonable amount of time.
Exactly. I don't care if someone steps out to run an errand or pick the kids up from school or to hit the gym, but they need to be available with some regularity during core working hours for any collaborative work to proceed.
When one person starts taking excessive liberties with schedule flexibility, everyone else is forced to adapt their schedules to that one person. It's not good for everyone else on the team.
But the starting premise was that some people would work 5 hour days, there's plenty of overlap there. It's not much different than separate time zones, as another commenter pointed out.
Separate timezones are fine as long as there is some overlapping core hours.
If that's not possible, the work needs to be more cleanly divided across timezones.
I've had to collaborate across different timezones (as an IC). It's rough. We tried to take turns staying up late so everyone suffered equally, but it's still brutal.
The nature of engineering does not align to this. Let's imagine the future with said "rockstar":
If you give them busy work to fill the rest of the sprint they get frustrated and leave because they're doing more work than everyone else, and they probably get paid the same (most companies do not have high compensation plans that align to single team performance).
If you assign them no work and just let them coast, now they're bored and required to be somewhere, so they leave.
If you give them more work that's large projects to fill their time but don't have opportunities for promotion or leadership, they leave. The opposite can be true too, where they repeatedly get accolades and promotions, then the rest of the team gets annoyed.
You're just displacing the issue rather than fixing it.
What I'd do with rockstars is stick them on complex things that are cogs in the larger machine. Have them fully document their work, detailing things like interfaces where others will plug into their work. Then they can do whatever with their extra time and I get the longevity I need out of them.
What I'm saying is, the processes and communication on your team need to align to having someone of greater talent in the same ways that having someone of lesser talent requires the team to change to support them.
do you understand that the time spent working on something is only very weakly correlated with the quality of the deliverable?
do you understand that some people can save you months or years of work and operational pain?
do you understand that some people no matter how much they work end up creating negative value and someone has to clean up after them?
you also have a very distorted view on what a superstar is. you’re effectively substituted toxic person with high output with superstar.
“superstars” get where their input is needed and provide the input in a timely manner (most of the times even before it’s requested). superstars think about the product and the output of the team as a whole. superstars grow junior developers and instill the values that will turn them in then next gen of superstars. superstars don’t sacrifice the future because of the present. superstars despise managers with but-in-seat mentality such as yourself. you probably have never worked with a superstar or if you did you were oblivious to the value they actually created.
I think you misread. I was speaking about my experience as an employee in this situation.
When a single team mate refuses to work with everyone, you have to put in extra work to work around them. It's as simple as that.
> When I transitioned to management I made a point to try to balance workload and availability across teams. It often makes more sense to let go of superstar engineers who are only available 4 out of 5 days per week and only working a few hours per day, even if their work is good in isolation.
Rarely does something needs an answer right now. Asynchronous work? Also, of course you don’t want to encourage people that are straight up hostile, but also your expectation that I’m gonna drop everything at any point in time to answer some thing that does not matter right now is pure bs. randomization is where productivity goes to die.
Replace the superstar with someone working "normal" hours but in a time zone offset by >= 5 hours to your own. You seem to be saying that cooperation with such people cannot work. But that is simply not true, many companies do make it work.
Is it always easy? No. But it can work very well.
The key is to require some defined overlap of working hours. If that's not possible, you divide the tasks as cleanly as possible across timezones so that people in the same timezone can work together.
Trying to force teammates to work together on something in opposite timezones doesn't work unless you have very relaxed deadlines. When someone has to wait until the next day to get a response to any blocking questions, work slows to a crawl.
Sure, that's not what I'm disputing.
> When someone has to wait until the next day to get a response to any blocking questions, work slows to a crawl.
Blocking questions should be an absolute exception in any case, even if the person who can answer them is just down the hall. It's on engineering management to organize work and documentation practices so that people can find answers on their own.
-Phil Jackson
https://a16z.com/2011/01/04/when-smart-people-are-bad-employ...
This makes it so there's no incentive to finish your work quickly, because you'll just be assigned more work.
Doesn't it make more sense to give people the rest of the day off if they finish their work ahead of schedule?
You'll have more satisfied employees and less burnout.
One more note: the best developers on my team look for more work when they have finished their tasks. They are focused on the success of the overall team.
Seemed to work great. The early birds would come in early, people with kids could take off early, the night owls could come in a little later, and everyone had some blocked off time to get some focused, individual work done without meetings.
Great for them, terrible for everyone who had to work with them. When one person has significantly less availability than everyone else, the rest of the team is forced to structure their activity around catering to that person's schedule.
Superstar engineer only works a couple hours per day? Prepare to block that time off in your calendar so you can try to catch them to coordinate that work you need to do together. Rockstar coder unavailable every Friday? Better hope they're not blocking your work, otherwise you're waiting until Monday to make progress. Or more realistically, you're going to waste all Friday trying to solve something on your own that could be finished 10x faster if you could get 15 minutes of that person's time.
> Don’t lie, don’t make up excuses, but be prepared to say I did xyz as planned.
The fallacy is that for most tech jobs, that "xyz" is rarely the end of the story. Planning isn't perfect and we almost never know the complete scope of a task or project at the planning phase.
The end result is a lot of work shifted to other team members who are forced to pick up the slack simply because they're available and reliable, unlike the person who disappears every Friday or spends every afternoon at the gym.
This may work in a hypothetical workplace with perfect planning and perfectly isolated work units, but in practice it just moves the excess work burden to other teammates. You're not sticking it to the company, you're sticking it to your team.
When I transitioned to management I made a point to try to balance workload and availability across teams. It often makes more sense to let go of superstar engineers who are only available 4 out of 5 days per week and only working a few hours per day, even if their work is good in isolation.
A healthy team requires everyone to play by similar rules.