Maker's Schedule, Manager's Schedule | Hacker News Reader

Maker's Schedule, Manager's Schedule

paulgraham.com

312 pointsmqt89 comments

This also speaks to why Makers tend to be somewhat noctural: the default for night-time that it be uninterrupted. Not just interruptions by other people, but by our own notions of what we "should be doing", i.e. going to the post office when it's open, doing laundry, following the news, etc.

Similarly, those people who have figured out that showing up to the office at 7am (or earlier) increses productivity are actually carving out Un-interrupted Time. I've found that early mornings are often a good strategy for being more productive if other things in your life conspire to deprive you of Un-interrupted Time.

That's my experience, too. I typically work for several hours early in the morning and late in the evening, then spend between 6-8 hours in the office. Time in the office is always full of disruptions, and I often can't get into any sort of groove. When I'm alone, at home, I'm far more productive in just a few hours.

You've got it, it absolutely is like that! It's such a subtle thing when you talk about it to people who obviously are trying to achieve things in a different mode, they'll say things like "come on, pull yourself together - you are simply not ambitious enough!" which makes you feel even more miserable and not productive. So we keep staying up all night - for a short period I managed to be able to rise at exactly 5 AM in the morning which was great but I endured it just for a month or so. You need discipline but you get much of your health back. I am working to get back in the habit again. Although nighttime has some additional quality for me which morning time doesn't seem to offer as much which is simply a higher frequency of creativity sparks (and maybe a higher error rate as well ;))

The problem I've had with coming in early is that most of the people I work around are procrastinators. So if the business day is 9 to 5, they will push off most of their work to close to 5. If I come in at 7am and expect to leave at 4 it is nearly impossible because that is the busiest time of most peoples days. It is a let down if I leave "early". I end up working 7 to 5 and then can't do my usual nighttime distraction-less work because I need to get up early the next day.

I think another reason why meetings are an extra burden on Makers vs. for Managers is that for the Managers, the meeting is their work. Their job is to meet with people, get ideas exchanged, organise people and settle conflict, which you achieve by having meetings. In many cases, when the meeting is over, the Manager's work is done: 1 hour of meeting equals 1 hour of work.

For makers though, the meeting can be additional to their main work, which is "making" something, and the meeting is really just a distraction, even if it is somehow related to what they are creating. When the meeting is over and the decision is made or the idea is communicated, the work still has to be done but the meeting time is now gone: 1 hour of meeting equals -1 hour of work, so 2 hours need to be done to catch up.

That's a weird bit of reckoning at the end. If you're short an hour of work, an hour of work is all you need to catch up.

I think he is trying to imply you cannot catch up. Doing that lost hours work consumes another hour and so on. The only way to catch up is to extend your working day by an hour.

I don't think the reckoning is weird at all. Being interrupted for an hour in the middle of your work costs more than an hour in all but the most ideal cases.

If you could somehow save your brain state in an instant, teleport directly to the meeting for an hour, teleport back, and then reload your previous brain state as you returned to your work, it would take exactly an hour to catch up.

The fact is, it takes a bit of time to change gears for the meeting and then quite a bit more time to get back in the creative zone. Aside from just remembering all the details of what you were working on, it takes quite a bit of time for your body, including your brain, to get into a state of "flow".

Tell it. In intensely focus-based knowledge work, the economics of human task switching - to borrow Joel Spolsky's term - is a formidable and intriguing science that managers who look at time as an interchangeable commodity or a cluster of cells on a spreadsheet simply don't grasp.

"I think another reason why meetings are an extra burden on Makers vs. for Managers is that for the Managers, the meeting is their work. "

I am not very sure that's true. Most good managers I know kept meetings to a minimum and kept them short. Yes they did consider meetings to be "work", but they did try to minimize the duratin and frequency of their meetings.

The best manager I know considers meetings a necessary evil (and so minimize them). He ran a whole division on a weekly 1 hour all hands meeting (plus lots of emails and so on but those are not as disruptive). Any smaller meetings had a twenty minute timer ticking down, with everyone standing up, and decisions were made fast.

He once told me that every managers job was to make himself redundant as and that his (conception of his) job was to make sure he moved things to a state where the system would flow well in his absence, by setting up expectations of how conflicts would be resolved etc, and so he would have to interfere only in the very rare cases.

He brought back the division from chaos and I would often see him sit (he sat "on the floor", not in his office) working on crosswords and so on, apparently doing nothing, but he had a finger on the pulse of what was going on and interfered minimally and effectively, obstacles being removed before they manifested. The organization ran like silk. He was the best boss I worked for and his subordinates loved him. He got promoted and was replaced by a less capable manager and soon enough we were drowning in meetings and no work got done

Your last two paragraphs hit on a point that more managers need to implement but are afraid to, because most managers think that if they make themselves redundant, then they'll be laid-off, instead of promoted.

I know of one manager in particular that is amazing at managing restaurants, but his problem is that he has to put in long hours to make sure the restaurant runs, and if he leaves on vacation, then the restaurant has often fallen apart (not to mention the years of increased stress levels it entailed worsened his cholesterol levels to the point he needed surgery). If instead he had trained everyone else to do his job, not only would he have had a ready supply of people to promote all these years, but he would also be a lot less stressed-out and maybe wouldn't have needed surgery.

And the origin of this problem is hidden in his first paragraph: most MBA-types do not have a real conception of their jobs. (Just compare that to athletes, teachers or those technicians that even have a cute name for their profession.)

Paul Graham can be hit or miss, IMO, but this one is a direct hit. I don't mind meetings per se - in a good company, they have merit - but their effect on the work day can be disastrous. If you don't work somewhere that understand that programmers need large uninterrupted chunks of time, well, you're not at a developer friendly place. There's few worse problems. And non-makers often don't have any idea that it's not just the standard 'coders are cranky' going on. (We, as a group, _are_ cranky, mind you.)

I work an odd job. It is approximately equal parts system administration, programming, and tech support. Can you guess which part I dread most?

I relish the days I can lock myself in a basement laboratory and hide out with my code. Some days I just give up on getting non-support work done because I'm getting interrupted every hour with a 5-minute fix or to reboot a fax machine. I've toyed with the idea of shifting my schedule to only overlap with the rest of the office half the day. There is no way I can really schedule much active work (as opposed to reactive tech support) in a chunk less than about three hours.

I'll move on when I can, but right now I've got one perk I don't want to trade for anything.

What's the perk? It must be pretty good if you're willing to put up with constant interruption for it...

I have a similar job + management duties. I've found the guidelines in the book Time Management for System Administrators ( http://my.safaribooksonline.com/0596007833 ) pretty good.

The strategy where you have a fellow team member act as your shield is effective. Every other day you rotate the role of shield, aka as the secretary.

Students, take this advice to heart as well. Are all your classes grouped together? They should be. I'd go so far to claim that you should take a less interesting set of classes in order to group them all together. I'm taking Distributed Systems this semester instead of Data Mining for this very reason. Am I more interested in Data Mining? Yes. But I'll wait until next semester. Distributed Systems are pretty cool too, and even the most amazing class is not worth adding several hours of dead time to your week.

(Interesting note for anyone familiar with Randy Pausch: he mentions this very phemonena in his lecture about time management.)

Counterpoint: While I agree, I have found that when I have a little spacing between classes per week (say one hour between lectures on Mondays) I face less administrative hassles in the long run.

This is because there's nothing productive that can be done in that hour except administrative work. Submitting forms, replying to emails, returning library books are all things that otherwise fall by the wayside to your productivity, but this way I don't get into trouble or waste "good" time doing them either.

Good point. Another option (as Randy mentions in his talk) is to schedule a "fake" class during the dead hour. Just go to the same spot in the library every day and work on the same class. Office hours are useful for this purpose as well.

I sort of did this during my undergrad. But instead it was essentially 9-5 minus whatever classes I had. I would just spend any time not in class during the work day to work on class work unless I had every assignment done. It helped me get ahead and then I could just relax in the evenings because I knew I'd have time to work on things later in the week.

In many classes it's much easier to do productive work in an hour than at most programming jobs. Programming jobs tend to be structured in terms of large projects/milestones, while classes tend to have smaller goals or problems on the problem sets that can be done in < 1 hour. And if all else fails, reading a text book for an hour can be quite productive, and it's nice to let the information settle in your brain before applying it anyway.

Brilliant article and spot-on.

The hardest jobs in software (IMHO) will be the engineering leads that have to be an interface between management and their engineering team. They are also asked to "make" at high quality but can't escape the management schedule overlap. So the only other option is to work themselves to death at night when no one can interrupt.

I think some managers have also begun to require (or encourage) semi-constant instant messaging which can hurt a "maker's schedule", too. I've been guilty of this even recently. Perhaps the continual overhang of the interruptive IM can make them feel that anxiety of not being able to work on any hard/long problems for fear of being interrupted?

The best "makers" have adapted to this in their own ways, of course.

My adaptation to this is just to say Bill does not do IM, and leave it at that.

I agree, the problem (and the solution) lies with the people who are the interface between makers and managers. The job description for these people varies but you know who they are - project leader type people.

Here's what we try to do: all meetings known to involve lots of people are all scheduled Thursdays. The people who only have to attend one meeting don't care, and the people who have to attend multiple ones just cross off Thursday from being a "real work" day. Yes okay, it's a cost, but at least it is only a 20% cost.

"Emergency" meetings involving senior management (you all know why the sarcasm quotes are there): the interface person should take the hit. In my experience there is rarely a technical issue raised in a senior management context that cannot be adequeately fielded (!= implemented) by a good project lead. Actually, I regard this as one of the major contributions of the leader: take all the crap on so that your guys can be left alone to do their work. I realise this opens a whole different can of worms in discussing what kind of person should be a project leader.

If you have a shop with people working mixed hours (ie when everybody is not on a 9-5 schedule) you should have "core hours" to allow for meetings anyway. This at least stops meetingitis from creeping throughout the day.

IM is a bigger problem I agree, but not necessarily in this category as it is a maker-to-maker disruption source as well as manager-to-maker one.

My solution is to simply follow my old student cycle - "lecture time" from 9am to 1pm, lunch break from 1-2 (if you want a hot lunch as I do, it always triggers an interrupt regardless). Since lectures are almost never contiguous, you can slot meetings and speculative meetings between them. I often meet people for lunch (the equivalent of "for coffee") and put important meetings at 2pm - 3pm (so that they stand out in my schedule, but still don't break my contiguous day.)

Everything important happens at 2/3pm onwards. I often go for a run at 6/7pm (hint: exercise is important) but I usually do a lot of thinking while on the treadmill, so it counts more as "retreat and reassess time" than an interrupt. Peak time is 8/9pm onwards, since the run provides time for reflection and restrategizing. I view the next few hours as a "runway" in that it provides a time for loading things onto my mental stack. If by midnight things aren't flowing, I wind down and get to bed by 1am to prep for the next day - but if things are in flow, I unleash and never stop until I'm exhausted (anywhere between 3am - 8am) and crash. (This is why important meetings are kept for 2pm, so that recovery is still possible without constraining the runway)

To echo pg on this- another trick that i was taught early on was to book out a day or half day per week for meetings. Slot them in, try and get people to come to you (helps if you have membership to a club or some such :)) and then keep people to their time slots. If they need to follow up - email or reschedule based on an action point.

One other point: agile standups seem to work well even for makers because they're bound tightly to the start of working sessions and last for a short time. They enable everyone to feel connected to each other on a team, but allow them to disappear back into their office or cube to work for the rest of the day.

> agile standups seem to work well even for makers because they're bound tightly to the start of working sessions and last for a short time.

I think there's another thing going on too. Most meetings that developers go to have some specific purpose of importance. They are tactical, so as a developer you need to prepare (mentally and/or more concretely) for them. Standups - being recurring events - don't have this aspect to them. This makes them much less stressful.

The problem with the meetings PG is talking about is they tend to be in the middle of productive blocks and they are long.

The idea of an Agile standup is usually it is right at the start of the day, when people are still drinking their coffee and waking up, and they are short (the standing is deliberately to keep it short and to the point). Sure, you might have a 10 minute standup at the start of the day, but that's only 10 minutes off the beginning of your 3-hour productive chunk. They can also help you get into the flow by getting you thinking about work.

That only works if everyone starts their workday at the same time.

Yeah, XP is kind of predicated on people working in the same place at the same time.

Agile does not necessarily imply XP.

Isn't that's where the standups come from, though?

I get that. But I think there is an additional element of explanation as to why standups are less disruptive.

Although the comparison of schedule types is interesting, the application to YC's schedule makes no sense.

An investor may use the manager's schedule for his work-day where he meets with prospective investments, meets with current investments, "grabs coffee"s, etc. When he goes home, he does not spend an hour with his wife, an hour with his kids, an hour reading "the brothers karamazov", and an hour of sleep. He goes home and has the maker's schedule.

Similarly, PG mentions that YC operates on the maker's schedule. But what he means is: if he grabs coffee it will cost him half a day's making work, not a half a day's YC managing work. PG, I'm assuming, writes essays, writes code, etc, not for YC investment management but for other projects. YC does operate on a manager's schedule: he mentions that Office hours are scheduled, interviews are in timely segments, etc.

So really, YC spends less time on investment management than other investors. There's nothing wrong with this. That's great. But let's not suggest that management is better done on a maker's schedule.

Strangely enough, management may actually be better done on a maker's schedule. It's certainly no worse done. Office hours seem to work fine for all the startups who want to talk to me. And in addition, compressing them all into the shortest time means that a group that shows up for an appointment during office hours is likely to meet several other groups of their peers while they're there. They invariably talk, and often end up helping one another.

Plus you're assuming that doing making work doesn't affect the quality of one's managing work. But that isn't true. Actively working on webapps myself makes me a much better advisor to startups doing it.

"Management on a maker's schedule" is a powerful idea. Imagine the world under that paradigm. So much quieter.

Unrelatedly, for some reason I'm leery of terms like 'office hours'. They seem ... infantilising. I guess 'office hours' is a precise description, though.

Yeah, I don't love the term "office hours" either. It's not even correct, since people have actual appointments; they're just clumped together. But I got into the habit of calling this thing office hours, and it is probably too late to change now.

I've found a way to partially counteract a manager's meeting schedule: splinter my work into extremely small pieces, and write them down in a TODO list. These tasks must have a clear DONE/NOT DONE boundary, and shouldn't need to be revisited. You should also break it up so that every time you finish something, you should be able to check something off of your TODO list. If it's not already there, add it, and then check it off.

For instance, if I had to write code to read data from a GPS unit, I might break it up like this:

* Find data spec on new GPS unit. * Look up current GPS interface.. if none, write an example and design an API around the example. * Write out header file (We use C++... that's another story :D) * Write function 1. ... * Write function n. * Procure GPS unit. * Debug.

I always feel some personal inertia against doing a task like "Write class to load data from the new GPS unit", but it's pretty hard to look at each subtask and say "err, I guess I should organize my inbox." Which I would probably do otherwise.

I have trouble finding tasks that are indivisible, but they exist! Designing and implementing custom data structures is one that I've run into recently... it has an ambiguous up-front design cost that makes it hard to divvy-up work.

Yes! Microtasking is the enemy of procrastination. When I feel like procrastinating (99.99% of the time?) and nodding off, I just tell myself, - I'll go play this game but first I'll let myself know what exactly I'll do after I get bored with procrastination. And so I write something like:

1. Pull init code from old repository.

2. Find function that accepts the data.

3. Insert init code into the class.

4. Debug and see if it works.

5. Write callback for accepting data from TCP.

6. Link callback to init.

7. Refactor.

Then, as I have successfully broken down the huge (2-4 hr for me) task into 20-30 minutes tasks I go and run, or swim, or play 3d shooters (love Tribes 1). Interestingly, while I do that, my brain subconsciously works on the stuff from todolist and when I get back and look at the tasks it's extremely easy to get started, plus, I got a chance to think of a better way (if exists) to do stuff.

This is exactly why we have a Don't Bug Tom (my co-founder) Rule.

I've actually found that I can't get into top "people mode" form without a warm-up. This means that, not only does a random meeting deprive me of a half day's worth of intense "maker" concentration, but I'm not even at my best for the 30 or 60 minutes of the meeting, because I've not warmed up into "people mode".

In my ideal world, I'd be in maker mode all but one day every workweek. I'd spend that remaining day doing nothing but meeting with people. I'd be in better form for both "maker mode" and "people mode", and I'd get more of both done.

The other problem is that a 2 hour team meeting takes 2 hours for the manager 2*n hours for the team, even before considering the disruption.

This probably just means the meeting is too large. I'd recommend cutting n in half and trying again.

From a smaller n, I'd expect not only a shorter meeting, but also a greater per person output.

This is why our team meetings are only 15 minutes long, and usually shorter. Any discussion or questions get done offline by only those people that are directly affected.

One way to prevent 2 hour meetings is not to let people sit down. We had an unofficial rule to that effect at Viaweb.

I remember once passing by a room and noticing a bunch of people sitting around a table. I must have raised an eyebrow or something, because one of them jumped up and said "We're not having a meeting! We were just talking."

One of the better practices from the world of "agile" software methodology is dropping the team's weekly status meeting and instead having morning "stand-up meetings" every day. Same thing - you don't let people sit down. It completely changes the tone of the conversations, because no one wants to stand in a meeting room for longer than 10 or 15 minutes.

Not to mention that when the status meetings - or, even more significantly, other kinds of meetings (design meetings, planning meetings, etc.) - are spaced that far apart temporally, every meeting just becomes mostly a rehash of everything forgotten since the last meeting. The "agile" folks have the additional insight that reporting early and often is good.

Thank you.

I just forwarded this to my latest ex-girlfriend to help her understand one of the major causes of drama while we were dating. :)

Get yourself a musician next time. Mine is in hackmode more often than I am :-)

Really, really interesting. Totally agree. As activity around Woobius has picked up recently, I've been struggling with exactly this problem. My cofounder happily schedules meetings with various potential clients or contacts or other useful people to meet, and they tend to break up my day in disastrous ways. I do indeed find that often, a meeting in the early afternoon (say 1-2pm) can blow up my entire day (at least in terms of turning a day that could have been chock full with super-productive work into one that only contributes a few bits of real work here or there).

I like the tip about working from dinner to 3am, too, but doesn't that blow away any chance whatsoever of social life? If you have a significant other, I imagine that's a clear no-go. Also, if you plan to attend the odd networking event, you won't (or at least, a networking event will basically cost you a whole working day, which seems pretty disastrous). How do you deal with those sociable activities when you're on the dinner-3am schedule?

A 1pm meeting (directly after a 12pm lunch) works ok for me. It's the 10am and 3pm ones that kill me. They mean virtually nothing done in the morning or afternoon, respectively.

It does blow away a social life and is antithetical to a significant other. PG clearly states elsewhere that he had neither for all but a very short part of the time that he was working on Viaweb, and implies or states in numerous places that this kind of dedication is necessary to achieve startup success.

The theory goes that the financial reward of a startup is a highly dense, compressed version of what you would otherwise be collecting through decades of salaried work of some sort, but is risky and always close to the margin of failure. So, the account goes, it requires a level of commitment that pretty much necessarily precludes a "healthy work-life balance."

Hey, I'm not suggesting "it gets in the way of a healthy work-life balance". Going out for drinks or to networking events is often a part of work. A lot of business success depends on who you meet, and how you get on with them, rather than how well you build your product. If you're totally anti-social, you'll probably miss out on a lot of potential business contacts that could make or break your business, no matter how good your product is.

Another problem this poses for companies is that conference rooms are a scarce resource. Not everyone can schedule all their meetings so they're not in the middle of an uninterrupted work period.

Penny wise and pound foolish, on the part of such companies...

There is a parallel to the "work expands to fill the schedule" thing. Our big company team recently moved to a brand new big building. No expense was spared. Lots and lots of conference rooms are available; a significant amount more per employee capita. However, the scarcity is only marginally less. People just start booking rooms for time slots or of sizes they don't really need.

It's a nightmare for me to lug two laptops and for a meeting just to spend the whole time fighting with others over power outlets and waiting for the last person to get online.

Lately, I do all my "meetings" on GoToMeeting or Skype, and reserve face to face meetings for the beer relay and bonding.

Or sacrifice Tuesdays, for example, to the suits; one meeting might fuck up a day, sure, but eight meetings would fill it, possibly usefully.

Not so good if you have a great idea on Monday night and want to stay up to work on it.

A "regular schedule", for me, is the worst possible thing for productivity.

pg, was this done on etherpad? mind sharing? I am sure, many over here share my thoughts of watching you write.

No, unfortunately, I forgot. I hadn't written any essays for a while because I'd been working on Arc.

A very interesting article. As a manager, I always tried to schedule meetings with my people first thing in the morning for precisely this reason (though I could not have articulated it in these terms before.)

One other option for his dilemma about "grabbing coffee" is simply to reschedule. It may not always work, but you can often minimize that interruption by pushing it to the end of the day or having it coincide with lunch where there is at least some small interruption anyway. It is hardly a perfect option, but it may often be the best.

This really hit home! Having transitioned from maker to manager over the past couple of years, I was just commenting to a co-worker yesterday that I find it almost impossible to finish the maker-like tasks on my to-do list (mostly writing and reviewing long documents). I've been feeling a lot of guilt about this, but I couldn't see a clear way out. After reading pg's post, I'm thinking about blocking off some afternoons for maker activities. Thanks!

GREAT essay-- I wish everyone would read it.

Curious question to PG: At this point, you can have any darn schedule you want-- I imagine your schedule is a combination of personal preference and habit... But do you think that YC (and YC companies) would be more successful if some/all of you adopted manager's schedule?

I can't quite have any schedule I want. In 2003 I could. Now I have a wife and a kid and YC.

I don't think YC would be more successful if one of us switched to the manager's schedule. VCs like to meet with one another all the time to learn about tech trends and hot deals. But we don't need to rely on other investors for either of those. The only people we really need to meet with are the startups we fund, and office hours seem to be ideal for that.

I'd gain nothing by switching to the manager's schedule, but I'd lose essays and hacking, both of which I think help me do YC better. So it looks like it would be a net loss.

I wouldn't even have heard of YC if not for the essays. I'm sure the same is true for others, some of whom have probably applied and been good investments for YC.

I set the policy early on in my company (we follow very complete Agile and XP) for all engineering related meetings: immediately after lunch or not at all. Standups, Iteration planning and review, Manager 1-on-1s, you name it.

Lunch interrupts everyone and people are rarely doing their most incisive thinking while food digests...if we're going to be unproductive anyway, might as well have a meeting.

I put in this policy for the same reasons PG talks about, and feel like it pretty completely handles the problem. Do people agree or disagree? Is there any reason I shouldn't be treating 1-2:30 as talking time, and the rest as coding time?

Our take (similar, just more concise): http://gettingreal.37signals.com/ch07_Meetings_Are_Toxic.php

I find it interesting that you (pg) schedule the office hours for the evening, not the morning. I find that if I have something scheduled at a fixed time immediately after "making" mode, I'm less productive just by knowing I can't tail off naturally. I therefore try to schedule "stuff" as the first thing in the morning.

Or is it tricky to get the founders you're advising to agree (with you, and among each other) on a common definition of "morning"?

I'm really surprised nobody has mentioned Peopleware (http://www.amazon.com/Peopleware-Productive-Projects-Teams-S...). It's full of stuff about creating an environment that minimizes interruptions so you can get into the flow (or zone or whatever you want to call it).

One thing I'll say about this essay, which was great btw, is that its comforting to hear that other programmers feel the same way in terms of actually not starting work if they have a meeting coming up, and how having their day sliced up kills productivity. I've always felt this way but also kind of suffered in silence - so thanks pg for putting this out there

I'll see this point and raise it: particularly ambitious projects often need weeks, even months of uninterrupted time to really get going. This means that a short mid-week trip, a conference or two, and a little contract work can clobber several months if you're not careful. Try blocking out two months with no interruptions and see what you can do!

This is nice validation to have. For a while now, I've been wondering if I'm just a bit precious for asserting that I absolutely need full focus and no interruptions otherwise my productivity dies.

Still, makes me wonder how on earth I'm ever going to successfully grow the business, while I've still got development work to focus on.

"Grab coffee" meetings can be particularly bad (in terms of time lost) because of the extra cost in getting to and from the cafe. When I had a normal job, getting to a meeting meant putting my shoes back on and walking down the hall. Now I have to consider which bus I'm going to take...

It's odd for me that PG is the source of this essay. I have a lot less trouble working in shorter bursts now that I'm using a Lisp dialect all the time. When I worked in C, long stretches were essential. I would think working in Arc would make short stints productive as well.

Can relate entirely... and I've been talking with my boss about "sequestering" myself, perhaps even regularly. Something like half-day Monday, half-day Friday, then a full "I don't even open the email application" day on the weekend. Might work, haven't tried it yet.

Great article. I'd this analysis is about 70% of whether I'll be productive or not in a particular day.

Anyone solve this by setting aside a few half-days each week for manager stuff, and reserving the other time for maker stuff?

How true.

And it has been said many times, too. Perhaps this iteration will be more successful: people may want to listen to pg more than some random guy.

pg, thank you so much for writing this!

"All we ask from those on the manager's schedule is that they understand the cost."

YES! I was just saying this the other day: how a meeting for a programmer has a different cost than a meeting for a manager. I will be sending this link out to many people.

Office hours for non-founders? Maybe in a coffee-shop nearby to YC -- maybe once every 2 weeks?

Why don't you just schedule "Grabbing Coffee" during an open office hours slot?

This is not some new insight pg just came up with. In fact it is pretty common knowledge, as Joel and many other has written countless times before, that interruptions are costly for software developers. Slapping new words on a well known and well understood problem, is not insightful.

I just forwarded this to my team at work and I hope they read it.

pg, you nailed this one. nough said.

I love this man.

What about an online meeting? On an IRC channel? Can a hacker working on a project multitask and attend the IRC meeting while simultaneously coding (perhaps he has 2 monitors, he codes on the larger one and IRCs on the other one) ?

I'd like to hear some thoughts on this.

that's why more people should be on ROWE (http://www.culturerx.com/) then their manager's schedules would be MORE efficient :)

"Meetings suck." Preaching to the choir a bit? I'm not impressed. Nobody ever got fired for buying IBM|Microsoft|flavor du jour. No hacker every got shot down for saying meetings suck.

> "Meetings suck."

Is that really all you got from this? Did you actually read it?

The thing I find about PG's essays isn't that his points are revelational, unexpected or intrinsically new, but that he so often manages to explain why these things are true, in such a way that I find myself nodding along with (nearly) every point. And he doesn't say "Meetings suck." He says:

    > Those of us on the maker's schedule ... know we
    > have to have some number of meetings. All we ask
    > from those on the manager's schedule is that they
    > understand the cost.

And that's the difference between PG and so many others. He explicitly recognises that it's not a binary "Sucks" versus "Doesn't Suck". Meetings are essential, but costly. KNowing why they're costly is of enormous value.

I'll be pointing my co-directors at this.

I think that there is a simple way to look at it too.

If you're a manager, you're supposed to think & act with people as a priority. U're supposed to operate from 'Social Intelligence'.

But if u're a programmer, u're supposed to operate from 'Technical Intelligence'.

Since these two are very different and will result in different thinking & acting so the schedule will obviously be different.

Reply on news.ycombinator.com