
Maker's Schedule, Manager's Schedule - mqt
http://paulgraham.com/makersschedule.html
======
timdellinger
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.

~~~
logicalmind
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.

------
ahpeeyem
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.

~~~
willchang
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.

~~~
xiaoma
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".

~~~
abalashov
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.

------
Kirby
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.)

~~~
Periodic
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.

~~~
jac_no_k
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.

------
tsally
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.)

~~~
arjunnarayan
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.

~~~
tsally
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.

~~~
Periodic
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.

------
thorax
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.

~~~
frossie
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.

------
arjunnarayan
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)

------
imajes
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.

~~~
troels
> 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.

~~~
Periodic
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.

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

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

~~~
donaldc
Agile does not necessarily imply XP.

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

------
jpwagner
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.

~~~
pg
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.

~~~
thunk
"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.

~~~
pg
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.

------
rabidgnat
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.

~~~
mannicken
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.

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

------
donaldc
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.

------
tybris
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.

~~~
pg
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."

~~~
projectileboy
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.

~~~
abalashov
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.

------
_pius
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. :)

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

------
swombat
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?

~~~
abalashov
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."

~~~
swombat
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.

------
philwelch
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.

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

~~~
mahmud
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.

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

~~~
jrockway
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.

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

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

------
timwiseman
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.

------
URSpider94
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!

------
webwright
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?

~~~
pg
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.

~~~
xiaoma
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.

------
dshupp
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?

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

------
pmjordan
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"?

------
liquidcool
I'm really surprised nobody has mentioned Peopleware
([http://www.amazon.com/Peopleware-Productive-Projects-
Teams-S...](http://www.amazon.com/Peopleware-Productive-Projects-Teams-
Second/dp/0932633439/)). 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).

------
goodgoblin
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

------
mhartl
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!

------
gstar
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.

------
vegashacker
"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...

------
brlewis
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.

------
timf
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.

------
jon_dahl
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?

------
cema
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.

------
lr
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.

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

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

------
niels
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.

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

------
mchristoff
pg, you nailed this one. nough said.

------
hitthewashboard
I love this man.

------
wizardofoz
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.

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

------
korch
"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.

~~~
RiderOfGiraffes
> _"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.

~~~
mtanva
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.

