4 ms·

Maybe "flow state" is not the most important thing?

mewpmewp2 2y ago
To whom? For my sanity and productivity that's the most important at least. I only enjoy working when I am in that flow state captured by the problem without having to worry about interruptions. This is when I provide most actual value and also get most enjoyment out of work myself. Everything that takes me out of it feels like annoying and frustrating interruptions. And usually I have to then try to not show my frustration and act like I am happy to do small talk or whatever, so I wouldn't seem rude.
- DannyBee 2y ago
  "To whom? For my sanity and productivity that's the most important at least." Optimizing for you vs the team is often not the goal. "This is when I provide most actual value and also get most enjoyment out of work myself." In most companies, it's much more valuable to have a team productive than a single individual, even if it comes at a cost to the individuals. IE Assume a team of 10, and that working like you suggest provides 1.5x productivity for you, but you working like this cost 0.15x to each other person on the team because you are slower at responding, etc. If it had no effect on anyone else that would be super weird (it would mean nobody depended on anyone, etc. Basically that being a team didn't matter). Let's assume when you don't work like this, it cost nobody else anything, but is really crappy for you (0.6x) With you working like this, team productivity is 1.5x+(9*0.85x)= 9.15x. Without you working like this, team productivity is 0.6x + 9x = 9.6x. Obviously it's different at different numbers and tradeoffs, but optimizing for individual productivity, when it costs things for teams, can often end up a net loss. Not always of course. You can argue it costs nobody else anything but i think that would honestly be a silly argument. We should admit there are positives and negatives to the tradeoffs here, and sometimes the aggregate works out and sometimes it doesn't.
  - deleted 2y ago
    [deleted]
ath3nd 2y ago
For a developer, arguably "flow state" is arguably the most important thing. Provided, that is, that requirements are clear and people are in sync what should be worked on. What do you think is the most important, if not flow state?
- DannyBee 2y ago
  Team and organizational productivity. Teams are not a simple sum of independent productivity of individuals. (If they are, it implies they don't need to be a team, since nobody is dependent on anyone else)
  - danaris 2y ago
    You say that like it's not possible to have a balance—have enough meetings and communication to properly coordinate the team, while still leaving each individual enough uninterrupted time to get plenty of flow-state work done. The posters above advocating for flow state aren't saying anywhere that they don't want to have any communication with the team. They're saying they need the flow state to get their own work done. That's fully compatible with agreeing, as a team, that there are certain times when you don't interrupt your teammates short of an emergency—and other times when everyone's fair game, and still other times for regular scheduled meetings. So many of the "quick calls" could just as easily wait until tomorrow, or a scheduled block of "interruptible time" at the end of the day. Saying "But I need to interrupt you now!" during a time designated for deep work means that you're optimizing for your individual productivity rather than the team's; instead, you could write your question down for later, and switch to a different task for the time being, or work around it, or research it yourself, or a dozen other possibilities.
    - deleted 2y ago
      [deleted]
  - ath3nd 2y ago
    While that is true, good team members don't interrupt each other and make sure they maximize both their individual and team interactions. "Hey, you got 5 min" all the time is a symptom of bad communication and bad team flow. It means lots of things are not clear, often, things that can be put in a knowledge base, or batched into a longer conversation. The price we pay as an organization when team members switch context is high, and if your culture is a culture of constant context switch, then it's not a good culture. Let's not normalize interruptions as "the price to pay" for being in a team. We can be in a team with better dynamics than that.

To whom? For my sanity and productivity that's the most important at least. I only enjoy working when I am in that flow state captured by the problem without having to worry about interruptions. This is when I provide most actual value and also get most enjoyment out of work myself. Everything that takes me out of it feels like annoying and frustrating interruptions. And usually I have to then try to not show my frustration and act like I am happy to do small talk or whatever, so I wouldn't seem rude.

DannyBee 2y ago
"To whom? For my sanity and productivity that's the most important at least." Optimizing for you vs the team is often not the goal. "This is when I provide most actual value and also get most enjoyment out of work myself." In most companies, it's much more valuable to have a team productive than a single individual, even if it comes at a cost to the individuals. IE Assume a team of 10, and that working like you suggest provides 1.5x productivity for you, but you working like this cost 0.15x to each other person on the team because you are slower at responding, etc. If it had no effect on anyone else that would be super weird (it would mean nobody depended on anyone, etc. Basically that being a team didn't matter). Let's assume when you don't work like this, it cost nobody else anything, but is really crappy for you (0.6x) With you working like this, team productivity is 1.5x+(9*0.85x)= 9.15x. Without you working like this, team productivity is 0.6x + 9x = 9.6x. Obviously it's different at different numbers and tradeoffs, but optimizing for individual productivity, when it costs things for teams, can often end up a net loss. Not always of course. You can argue it costs nobody else anything but i think that would honestly be a silly argument. We should admit there are positives and negatives to the tradeoffs here, and sometimes the aggregate works out and sometimes it doesn't.
- deleted 2y ago
  [deleted]

ath3nd 2y ago

For a developer, arguably "flow state" is arguably the most important thing. Provided, that is, that requirements are clear and people are in sync what should be worked on. What do you think is the most important, if not flow state?

DannyBee 2y ago
Team and organizational productivity. Teams are not a simple sum of independent productivity of individuals. (If they are, it implies they don't need to be a team, since nobody is dependent on anyone else)
- danaris 2y ago
  You say that like it's not possible to have a balance—have enough meetings and communication to properly coordinate the team, while still leaving each individual enough uninterrupted time to get plenty of flow-state work done. The posters above advocating for flow state aren't saying anywhere that they don't want to have any communication with the team. They're saying they need the flow state to get their own work done. That's fully compatible with agreeing, as a team, that there are certain times when you don't interrupt your teammates short of an emergency—and other times when everyone's fair game, and still other times for regular scheduled meetings. So many of the "quick calls" could just as easily wait until tomorrow, or a scheduled block of "interruptible time" at the end of the day. Saying "But I need to interrupt you now!" during a time designated for deep work means that you're optimizing for your individual productivity rather than the team's; instead, you could write your question down for later, and switch to a different task for the time being, or work around it, or research it yourself, or a dozen other possibilities.
  - deleted 2y ago
    [deleted]
- ath3nd 2y ago
  While that is true, good team members don't interrupt each other and make sure they maximize both their individual and team interactions. "Hey, you got 5 min" all the time is a symptom of bad communication and bad team flow. It means lots of things are not clear, often, things that can be put in a knowledge base, or batched into a longer conversation. The price we pay as an organization when team members switch context is high, and if your culture is a culture of constant context switch, then it's not a good culture. Let's not normalize interruptions as "the price to pay" for being in a team. We can be in a team with better dynamics than that.