Developers are easy to manage. You just shovel intriguing problems towards them, and they’re fine. They just don’t want to even hear about anything else (professionally speaking, at least). I’m just like that.
We developers tend to have two different functioning modes. The first is called, more or less by everyone, The Zone. Whilst we are in this mode, we write 10 kloc per day and we seldom take breaks.
The second mode is much different. I’ll call it Brainstorming, but the word doesn’t really describe it in full. Brainstorming happens when a developer has an idea and starts building some structured plan around it, preferably taking peers on the discussion (possibly disrupting their Zone). This usually involves drawing on whiteboards (and windows when whiteboard space is completely used), talking loudly and simply assuming that users will love it, how-can-they-live-now-without-this. It’s almost crazy, but it’s when the magic happens and sensational things come to life. (BTW, if your developers are not like that, then you’re in trouble.)
The problems start when your company is mostly run by developers (like mine) and non-developers never take part to Brainstorming sessions because, well, they’re technical discussions. They’ll not understand why a particular feature ended up in production, or another one was removed. Or what the entire product you’re building is about.
The main point here is that Brainstorming can start at any time, without any advance notice. It could be at 8 in the morning, or 6 in the afternoon, or at lunch. And you can’t stop it, or plan it, or repeat it, because it just doesn’t work like that. It’s a passionate, down-in-the-guts, collective thing. You just have to be there, otherwise you’ll only see the final results. Which are seldom perfect, and that’s the entire point in being there too if you’re not a developer and want to have a word in what’s happening.