2. Pre-defined hours are useful to maintain work discipline.

3. I manage and prioritize distractions by utility and time sinks. I pre-manage situations by making sure that stuff is reliable or stupid-easy-to-fix so that people don't freak out. That makes it easy to engage opportunities when they arise.

4. A good tech thinks like a business guru and a good business guru thinks like a tech. It's all the same discipline.

5. Chat is disabled for all of my work. I typically disable e-mail unless I'm filing a status report or handing off an asynchronous task.

6. My productivity is scheduled according to whether I'm with people, or by myself. I handle extended tasks when I'm alone. When I'm with people, I handle the tasks that benefit more from real-time iteration. I prefer to work independently since real-time iteration almost always leads to a dumbing down of a final product.

2. I don't. Double Cluepon is a startup, not everyone is paid. Sometimes you do work with some people when you can, but you balance it out so something is always getting done. Flexibility is always key, but again..you have to keep yourself focused.

3. We've had some drama in the past. We nip that shit in the bud. Drama, power basing, political bs...we show it the door. We don't need it, actively remove it. Better to remove one, than lose all.

4. As the Production Director and the CEO in a company that makes games, I balance it as best I can. I actually love all aspects, from art to the infrastructure and code. Really, when you're a chief, you have to be a generalist, not a specialist.

5. ALL. THE. TIME. We also hire people who are local. Telecommute is a buzzword in some respects; there is no substitute for face time.

6. It entirely depends on the job. We're in games, sometimes I design away from people, away from my computer. Other times, such as Game Design meetings, I work with others. It ultimately comes down to an amalgamation of what I said above: you do some stuff when you can, do fill in the other time with stuff that still needs doing.

2. While I have the option of starting my workday early or not, I generally still arrive at the same time every morning and put in my required hours. However I dont believe its efficient. I'm not a morning person. My work in the morning hours is more frantic than planned. But I also dont want my work day to bleed into my personal hours - its a struggle.

3. Despite having various filters before I'm even involved [help desk, jr. devs], everyone considers everything an emergency and will bypass the 'system.' Verbally communicating with people freaking out is key. Everything is a queue with some preemption. And generally any user related emergencies are preempting my actual projects. Its annoying but necessary balancing act.

4. I'm definitely more of the hacker type. I'm not satisfied at just fixing something. I want to know what it does, why its breaking, how can it actually be resolved for good. Usually this surpasses the business desire of just getting things working and patch it later. Sometimes going beyond that is seen as good and other times its a 'wasted' effort.

5. I love IM. But information gets quickly lost. And at some point we decided to start using two IM clients at work (one for dev, one for support) WTF? I find its very efficient for get that quick yes/no answer from devs, but not for users. And email is a much better medium for multiple long questions or answers.

6. Away from people - but still accessible

2. It chafes somewhat, but when I don't have them, I'll eventually go crazy. Plus there needs to be some kind of reasonable hope of being around at the same time as your co-workers for those chats where email just won't do.

3. I'm not good at multitasking (at least not if one of those tasks is programming), so I'll give all my focus to whatever the interruption is, in the hopes of getting it out of the way as soon as possible. Sometimes, if it's an interruption that doesn't seem immediately important, I'll end up ignoring it. Neither of these strategies is the greatest thing ever.

4. Hacker.

5. I try to avoid it unless necessary. I find if I'm in any conversation, it takes over all my attention, at least to the exclusion of programming. If there is a conversation needed on a subject, I find in-person conversations have much higher bandwidth, so it takes less time overall to go and find that person (if they're physically proximate) than a slow back-and-forth over instant messages.

6. Away from them, mostly. I need to have enough discussions to have a plan for where I'm going.

2. I don't have a problem with it. In fact, I prefer it.

3. I wish people would explain exactly what they want. What is the goal here? I also don't work well when others assume I know everything they know. Breaking down the preferred end result and then explaining why they haven't arrived there is most helpful. Follow that up with specifically what I can do to help them reach their goal and things usually end up successful.

4. I don't believe in MB. I prefer business-y things, but have pigeon-holed myself in the tech world. Ooops.

5. I am constantly on phone/IM with my team. I actually quite enjoy phone calls and feel this is likely an anomaly. Most people don't like it, but I see it as a way to communicate more effectively and avoid email.

6. Split! I actually love working from our offices because I am an 80% remote employee. Facetime, IRL with my co-workers is invaluable. I feel they're more forthcoming and much more willing to share ideas when it's just stopping by my desk. Phone calls, IMs and emails are purpose-driven, which removes a lot of off-the-cuff creativity and brainstorming. I like being available in person for people to just grab me and talk about what's on their mind.

2) Annoying. My sleep schedule does not lend itself well to rules, man.

3) E-mail me for anything that isn't urgent. IM me for anything that is urgent but not important. Call me for anything that is urgent and important. Deviation from these rules will make it more difficult to reach me when it really is important and/or urgent.

4) I can bridge the gap between programming and businessing. I get more joy out of programming than businessing.

5) I do not chat using voice/video if I can avoid it. E-mail is better, there is a record to refer to when I forget the answer (in that respect, 6-month E-mail purging policies are counter-productive). I tend to ask more questions than I answer.

For teaching things, face-to-face seems to be better than e-mail. Most people seem to get more out of presentations (I, again, prefer text, but whatevz).

6) I don't think it matters. What matters is managing distractions: Alone, I can do anything (only one option being work). Too many people and it's hard to concentrate.

But some people actually work well using pair programming, I am not one of them.

My ideal work environment is a cubical with at least 20 sq ft of floor area, desk covering two adjacent sides, walls high enough to prevent stray movement from other cubicals. At least 2 conference rooms with doors and presentation equipment big enough to support the entire team. Temporary shared offices with doors, 40 sq ft, for use by anyone (for interviews or otherwise). One extra room with A/V equipment for video games (but I work at a video game company, so that's "research"). Galley kitchen would be a nice-to-have.

2) Awful. I like to sleep when I need to sleep, which is not the same time every night, so why would I get up for work at the same time every day?

3) Written, non-realtime communication when possible. This gives me the opportunity to figure out the answer to more complex problems, and the time to actually fix simpler ones.

4) Hacker as a mindset. There are equally complex business and code challenges.

5) IRC when I remember to sign in. Google Talk whenever my browser is open. It's all latent communication through a real-time source. (ie: if I ask/answer a question, I don't expect an immediate response, but when it gets responded to we can have a short discussion about it) I usually ignore chat when I'm "in the zone" because that's very tunnel-vision-y for me. Sometimes feedback through chat is essential to moving something forward.

6) Away, but only when there's a space I can go if I need to talk to someone. I make a choice to be in "world-mode" or "zone-mode"

2. I like each team member having a schedule that they set (as long as the team has a couple of hours of overlap daily or a day or two overlap weekly).

3. I wish that while some members of a team are involved in high-focus activities, another team member (changing day-to-day) would be the emergency point-of-contact.

4. Technical side. INTP.

5. Almost never: I sometimes use Jabber, but that's usually just to get or receive a quick note. I find that face-to-face communication is the best, unless you need to send a command or code fragment or URL to someone.

6. Most of my work is done on my own, but it's also necessary for me to have the other team members within speaking or walking distance for quick conversations. IM could cover that, I suppose, but see #5.

2. I like having a small amount of pre-defined hours (up to 4), but I hate being stuck in an office when I'm not getting anything done.

3. As long as interruptions first come to me in email or IM, vs. a phone call or someone in person, I'm fine. Having 5-15 minutes to wind things up before switching is important.

4. I sadly do more business stuff now, but was even more like this before. INTX, although not as strongly I vs. E as I once was, and less J vs. more X than I used to be, too.

5. I leave an IM client running sometimes, but not when I'm focusing. What I'd prefer is some kind of agent (like a receptionist) which could mediate IM and email for me.

6. Away, generally, although it helps to have people nearby or at least available if something depends on them.

1. Tranquil would be the word. Work best during wee hours when the night is quiet and peaceful.

2. While it is good to stay disciplined, I try to miss a few work day timing to stay productive at night.

3. Evernote is what our team used to keep track of ideas, feedback, improvements. Bound to have hiccups along the journey, but if there is a SOP in place - everything should be just fine

4. I love developing, but i am starting to learn the ropes of business management from my partners

5. Almost daily. Remote management with clients require us to stay online via chat, email, etc

6. I get more done away from people. I am easily distracted.

1. After hours, when no interruptions are happening.

2. Not crazy about the idea

3. I encourage asynchronicity as much as possible for all but major emergencies. I try to plan my work outside of potential emergencies.

4. Hacker

5. Lately very often, but I feel more effective in isolation.

6. Typically away from them, but also with them --something like a meeting a week seems really productive.

2. nearly impossible to achieve

3. Realtime chat. Whiteboard that shows what I'm currently working on, what's on deck.

4. hacker

5. Checking in to a chat room every hour or so is great

6. Around people that are busy focusing on their own thing, but not bothering me

(1) I definitely experience "flow state" (c.f. http://en.wikipedia.org/wiki/Flow_(psychology) for explanation). It is, unfortunately, random and unpredictable as to when it occurs and what conditions trigger it.

Sometimes, it comes first thing in the morning as my feet are hitting the floor, I'm razor-focused on the task I want to accomplish right away and I sit at my desk and productivity pours out of me. Sometimes, it happens mid-day - often two or three hours after waking up. Unfortunately, sometimes it happens just as I'm getting ready for bed - I lie down, my head hits the pillow, then I feel it come on - and, most times, I'll grumble as I get back out of bed and sit back down at my keyboard.

The one thing that's for sure is that my biorhythmic lows are 2-4 PM, and if I'm staying up all night long, from 4-6 AM. During those hours, I actually struggle to just stay awake, let alone be productive. I keep thinking about experimenting with dividing my 8-10 hours of sleep into two chunks per day: one from 1-5 PM and the other from 2-6 AM.

(2) I generally have self-established predefined hours every workday: 8 AM to 10 PM. However, I'm 80% telecommute, and the 20% that I commute is generally flexible within reasonable boundaries - e.g., I'm not penalized for not arriving by a pre-set time, nor do I punch the clock and leave at a pre-set time.

I have never had a job where I had pre-set hours, so I honestly can't say how I would actually feel about it. Perhaps that says a lot about how I would feel about it, actually. Strongly enough that in 15+ years of continuous employment, I've never once held a job that required it, and have no intentions of in the future.

(3) Evidence-based scheduling enables you to estimate a certain level of "planned interruption." This is the "overhead" of collaboration and communication. I don't think this is what you're asking about, though.

Truly unplanned interruptions - i.e., emergencies - are interesting. Given proper engineering discipline, these should be so rare that to drop everything and respond to them with full attention is infrequent enough that I don't worry about their impact.

In the case of responding to an emergency, I prefer people to remain as calm as possible, remember to maintain a professional behavior, and to stay focused on the positive desired outcomes. I have no trouble asking, or telling, people who cannot do these things to GET THE FUCK OUT of the situation room in an emergency, because to manage around them just makes things more risky. There is plenty of time for cluelessness, rage and blamethrowing AFTER the emergency is resolved. Those things are not acceptable to me during an emergency, nor should they be.

(4) I am first a pure hacker (doing for the sake of doing regardless of perceived boundaries) as well as very business-focused (if a tree falls in a forest and there's no one around to sell it, it's worthless).

Personally, I liken Meyers-Briggs to horoscopes: write something generalized enough and it'll apply to 90% of the population. However, I DO find codified descriptions of archetypical personalities useful as a form of communicative shorthand. To that end, I most closely resemble a mixture of INTJ and ENTP.

(5) I am constantly using forms of text-based store-and-forward (email, IM, IRC, SMS, etc.) communication. It is currently the highest concurrency form of communication we have available, and therefore is the most efficient for me. I actively avoid audio/video communication as it's single-threaded and therefore highly disruptive, as well as very low-throughput in terms of information exchange.

Regarding answering and asking questions, I'd like to clarify the question by rephrasing it: do I more frequently initiate communication by asking others questions, or do others more frequently initiate communication with me by asking me questions?

To that question, I'll answer that others definitely initiate communication more with me than I do with others. To summarize it simply: I suspect many people treat me like their personal Google (search).

When I answer, I'll sometimes answer with a question that hopefully enables the asker to produce the answer themselves, or better align their thinking so that the answer will make sense, or lead them to learn what they need to learn in order to understand the answer or deduce the answer themselves.

(6) I feel I am more productive when collaborating with people, but not necessarily working geographically adjacent to them.

Unless the work task is solely to communicate with someone else in real-time, making real-time interruptive communication so frictionless through geographic adjacency results in it occurring too frequently, which interferes with getting the actual task at hand done.

Sure, I'll be the first to say that working elbow to elbow with collaborators is fun - and don't get me wrong, fun is a critical component of work - there is a time and a place for it - happy hour after work, or weekend get-togethers, etc. But, time spent in single-threaded real-time communication is time spent not completing work, so it should be kept to the minimum and no more or less.

1. It depends on what you define as work. My experience, and that of the team I work with, seems to validate Paul Graham's Maker's Schedule, Manager's Schedule dichotomy: http://www.paulgraham.com/makersschedule.html. If the goal is to communicate, clarify, or design something with others; then the standard business day (Manager's Schedule) is the most effective. If the goal is to write a proposal, analyze customer behaviour, or program a bugfix; then I find I'm most effective when there are no distractions during (Maker's Schedule). For me, this is after I make dinner and into the wee hours of the morning.

Since this is equivalent to putting in double time, this is also not very sustainable. Because I work with both types of schedule, I stick all of my Manager's Schedule tasks early in the day, with meetings booked back to back. Then, after lunch, I'm able to focus on my Maker's Schedule. Unless there is a fire to put out with a customer, I'm concentrating on tasks that require deep focus. Anything outside of that can be postponed until the next morning.

2. I believe that each team must have "office hours" where they are available to communicate with the outside world, and the rest of the day should be allocated according to each person's preference. You basically trust each person to contribute to their own ability, otherwise why have that person on board? But you also need the whole team to be available so that you can form social bonds between each other and also the other teams you work with. People who don't overlap with those office hours aren't going to mesh with your team very well, so either pick a new timeslot or only work with that person as a consultant.

To look at it another way, I need to contact people without caring that I'm interrupting a focus-oriented task. During office hours, I don't have to worry, and other people don't have to worry about interrupting me.

Finally, none of this forbids people from independently agreeing to times that they work with each other. For example, I love pair-programming with coworkers, and we work out the best times to do this activity amongst ourselves. Office hours merely guarantee that our productivity won't get ruined, and we're available for discussions every day.

3. As answered above, office hours are for what a programmer/maker would call an "interruption" and other people call "real work".

For more urgent incidents (failing servers, flooded offices, angry customers, etc) we all agree that these are emergencies that are dealt with by a standard IT Escalation Procedure. The procedure is a one-page decision tree that you walk through: what time is it? how urgent is it? It tells you how to contact people (email or phone) and which people you ought to call. We haven't had to use it much, but nobody ever complained when it got used.

One important caveat: your staff won't be amused at being told something is urgent if they discover that someone else in the company had predicted this incident would occur. There will probably be some angry words, a severe drop in morale, and an instant loss of trust if an urgent incident happens because someone cut corners, ignored some warning signs, or outright lied to a customer.

4. I identify more closely as a developer who has a strong engineering background. My training leads me to think about: problem analysis, root causes, cost reduction, and maximizing profit. I am neither a hacker nor a business guru, which are both extremes that us engineers like to avoid. My Myers-Briggs type is ??T?.

5. I use realtime chat throughout the day: I will respond instantly during office hours (manager's schedule) and whenever I see the message when I'm on a maker's schedule. Realtime chat is great for questions where you need an interactive response, but can wait until the other person has finished whatever they're doing.

I'm available for voice chat during office hours and we often have meetings over Google+ Hangouts. Meetings with voice and video really reduce misunderstanding that arise from tone and diction. We also are able to go over documents, numbers, and drawings during these meetings which really reduces the number and length of our meetings; because we're able to come to a common consensus earlier.

I use email for announcements and work requests. We also communicate with our bug tracking and project tracking systems. These are for requests that are highly asynchronous and package up large tasks. Features, bugs, and customer feedback almost always result in either realtime chat or a full on video-conference to hash out the details. Often, this communication will be brief (15 minutes) but they've sometimes taken much longer for difficult problems. When that happens, we try to break the work apart into Manageable/Minimal Viable Features.

As a general rule, I always prefer to have the highest bandwidth meeting possible to get people to consensus the fastest. It might seem better to always prefer something lightweight like an email thread up front, but the chance of confusion is high enough that you'll probably end up in a long meeting anyway to decide what work you're going to undo because you got it wrong in the first place.

I ask more questions than I answer, because our calls almost always involve unknowns. We're very good at keeping each other up to date with answers on our mailing lists, our shared calendars, and our shared documents. The reason we have meetings is to find out whether we are asking the right questions and making sure that the right people are working to discover the right answers.

6. For manager's schedule work, I definitely get more done around 3-5 people, which I find is the optimal size for meetings. With too many people, we are just wasting time and money. Manager's schedule work is rarely done in isolation, you need to have other people questioning your assumptions.

For maker's schedule work, I get the more done by myself. However, I find that I get higher quality work done when working with someone else. Doing high-focus work with a partner results in fewer mistakes and less time spent doing useless work. There's a tradeoff though: if I need to finish something fast, I work alone; if I need to finish something correctly, I work with someone else. Pair work is documented as effective for programming, but I've also found it effective for UI/UX design, business plans, and even writing press releases.