Live data from Hacker News

Ask HN: How to experience 'flow' state as a manager?

news.ycombinator.com

1–8 of 8 posts

Re: Ask HN: How to experience 'flow' state as a manager?

#3
I agree with coderintherye. You might want to read about manager vs maker schedule. The conclusion I come to is the manager schedule is nearly incompatible with deep work. But if your job as manager involves strategy planning, that might require deep thinking in which case I’d block off a day, and go on a long walk to think.

Re: Ask HN: How to experience 'flow' state as a manager?

#5
I don't get into flow, my team does - If my team can get there, then I'm successfully meeting their needs to have what they need to do so, including giving them the resources, information, and direction to know their path, removing roadblocks, and handling the meetings that they don't want to be in.

Re: Ask HN: How to experience 'flow' state as a manager?

#7

I disagree with the other responses. A manager can experience a flow state when they are highly engaged in a series of meetings and conversations, and when they are writing.

Agree. I had flow today. Meetings all day, figured stuff out. Was awesome!

Re: Ask HN: How to experience 'flow' state as a manager?

#8
I actually got into flow more as a manager.

The problems are the same. You are communicating. This is what you do with software too. Organization charts are like architecture; take note of what supports the system and where it is weak.

The difference is that software crashes and throws errors. Humans try to fix their own problems when there's a bug. Sometimes this fix is not ideal to the rest of the system. You end up with things like one team pressuring another to extend a deadline, or buying excess junk to maximize their budget next year. You sometimes have to design the system to throw errors. Scrum is sort of like the managing equivalent of Java; it's bloated, slow, but it's safe and it works with dumb users.

There are lots of communication issues in every organization. You can do this manually or with tools, but you must be careful not to overengineer.

If you look, there's a lot more to refactor, and much of it is low hanging fruit. I'd suggest starting by tracking how the organization works and then trying to figure out how it can be optimized.