Comment by sfllaw

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.