> It's disheartening that there is a whole group of people - developers and managers alike - who do not understand or see the value in exploration as part of the process.
To steelman, because, as Frank is sending ethernet packets, we're stuck picking up the slack, doing things that are part of the job description, that are needed by the org as a whole. Why doesn't he just innovate in the actual problem we're working on, since there's a near infinity backlog?
I think, ideally, everyone is given exploration time, but that requires a manager that can strictly defend it, even when upper management is made aware of it and inevitably says "we need <project> done sooner". It's also a problem when other managers become aware of it with "You're allowing that team to hire more to compensate for the "lost time"? We need those people!". It really needs to be an org level thing, which even Google gave up on [1].
"Unethical" solution: Pad your development time to include some of it.
You may be on a team that has decided "developer burnout" is just an inevitable and acceptable cost of business.
> since there's a near infinity backlog?
Which is a problem in and of itself. In any case I'm only going to be able to give you like 4, real, solid hours of work a day on that log. The other 4 will be team coordination, managing that log, and stress management maybe while I hate eat my lunch.
> everyone is given exploration time
Call it "skill investment time." We're in a fast moving industry and keeping heads down for too long is destructive personally and organizationally. It's also the pathway to getting more than the basic level of engagement above.
> You may be on a team that has decided "developer burnout"
No. Burnout is a work life balance thing more than a "doing work at work that is related to the business" thing. Fun can be had outside of work hours, just as everyone else who is employed handles it. You can give people meaningful work they're interested in and still keep it related to the actual business.
> Which is a problem in and of itself.
Absolutely not. If you don't have a near infinity list, then that means you don't have a roadmap. Why aren't you thinking about the future?
> Call it "skill investment time."
Yes, and this can always be done in the context of the work. If it's not related to the work, or the business, then it's not an investment for the people paying you.
It's more than that. Perhaps you haven't been in a position to accept a lot of resignations in your career. Burnout is most definitely implicated by the work place itself, specific work assignments, and general office culture.
> don't have a near infinity list, then that means you don't have a roadmap
Are you talking only about startups? That would make sense. In the more general case I doubt your assertion here. Does this fragment truly sound rational to you on a second reading?
> and this can always be done in the context of the work.
The very article this thread is attached to clearly shows how false this is.
To steelman, because, as Frank is sending ethernet packets, we're stuck picking up the slack, doing things that are part of the job description, that are needed by the org as a whole. Why doesn't he just innovate in the actual problem we're working on, since there's a near infinity backlog?
I think, ideally, everyone is given exploration time, but that requires a manager that can strictly defend it, even when upper management is made aware of it and inevitably says "we need <project> done sooner". It's also a problem when other managers become aware of it with "You're allowing that team to hire more to compensate for the "lost time"? We need those people!". It really needs to be an org level thing, which even Google gave up on [1].
"Unethical" solution: Pad your development time to include some of it.
[1] https://hrzone.com/why-did-google-abandon-20-time-for-innova...