Your most productive time. How do you do it?

I am a Director of Engineering in a software development company with a small team of really awesome programmers. I report directly to our CTO. I'm going to assume that you're trying to juggle the classic focus/interruption tradeoff that often results in heated arguments between business and engineering teams. These answers are my opinion and they seem to work for us — maybe it will work for you.

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.

Rif, founder of PageCovery.com

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.

Hey xtat ;)

(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. I get the most work done when I have a clear list in my mind of exactly what needs to get done, and am then left alone. Best hours: midnight to 3am, followed by 10am-12pm. 4-6pm is a bit of a productivity death zone.

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.