Maker's Schedule, Manager's Schedule (2009)

http://paulgraham.com/makersschedule.html

by ibobev • 8 years ago

383 130 8 years ago

jbob2000• 8 years ago

The problem I have now is; How can I get the manager to read, understand, and respect Maker Schedule?

Should I send them this link and then try to explain to them who Paul Graham is and why they should care about him? Should I send them the wikipedia article about Flow[1]? Should I show them the clip from The Social Network about "being in the zone"?

[1] https://en.wikipedia.org/wiki/Flow_(psychology)

codingdave• 8 years ago

Maybe you should treat both schedules as equally valuable, while acknowledging the different purposes they serve, and respectfully discuss the problem with your manager to collaborate on a solution together. It could be as simple as "Please don't schedule meeting mid-day." When I was a 50% manager / 50% dev, I blocked off 10-2 forever on my calendar for my coding. Whatever you end up with, talk, don't send links -- sending links to articles comes off about as well as sending your fellow devs to LMGTFY.

brazzledazzle3• 8 years ago

They’ll agree because it’s reasonable and makes sense but the real test will be if they ask if they can book over that big maker block, just this once. And this once. And this project is really important so just this once.

It’s like technical debt. No manager is going to disagree that it’s important. But the test is if they ever make time for it or drop the story for something else.

rumpope• 8 years ago

Yes, all these things do help and you can also speak their language - they understand having multiple "back to back" meetings, so you if you schedule meetings with yourself, that you can't miss, and open up your schedule for other times, then you can allow them to book you then.

jermaustin1• 8 years ago

This is exactly what I learned after years of developing around meetings. Block your time first. And block your time based on your tasks you have to complete.

Sure you can't completely rewrite the billing system from scratch in an hour, but you CAN stub out the new architecture. Then each hour after that you fill in a method.

I feel needing 4-9 hour blocks of time means you AREN'T focusing, not that you are "IN THE ZONE"

reggieband• 8 years ago

I find this comic is helpful: https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt...

andyidsinga• 8 years ago

I'm sending this to my wife!

codemac• 8 years ago

Taking notes in a digital lab notebook (i.e. text file) while I'm thinking has sped up the re-inflation period significantly from ~1/2 hour to ~1-5 minutes.

I can highly recommend it for folks in very noisy/distracting environments. It also points out how much you struggle to stay focused if you are not continually writing in your notebook.

wool_gather• 8 years ago

Unfortunately I'm not sure that explains it in any way that a non-maker would get. It's basically missing the last panel, where the dev writes a _new_ bug that costs millions of dollars because of the distraction.

willholloway• 8 years ago

Maker Time is an alternative time keeping system I designed after being inspired by this essay.

http://willholloway.net/makertime.html

codetrotter• 8 years ago

On mobile it’s just showing the number “751” on the middle of the page, the text “maker time” and a background picture of earth seen from space. Is this how it is supposed to look? If so, what does it do?

schrodinger• 8 years ago

On desktop there's a "What is Maker Time" link that provides the following:

Your clock has it backwards. Time is infinite, but our time on earth is not. Clocks should count down, not up. Time keeping should be based on meaningful celestial events like the year (one earth rotation around the sun) and the day (one rotation of the earth) Each unit of time should be based on a viable period of work for makers. Maker Time is reset on January 1st each year. The year is divided into 1095 blocks (1098 in leap year). Every 8 hours the count decreases by one.

thaumaturgy• 8 years ago

I've had to juggle the two schedules he describes for about a decade now. I haven't been wildly successful, but there are some tactics that seem to make it work okay.

- Write code in smaller chunks. This has been a huge change in how I do software. Almost all my code now starts out as an outline in a series of comments: "// do this", "// then do that". I write software "outside-in" now; if I need to slurp a file in one format into a database in another format, I start with the bits that read the file, then add the code that translates/interprets/processes the data in the file, then separately add code that talks to the database, then glue it together. At each step I dump output to the screen. So, I start with a stupidly simple file-dumping program and iterate it until it does the whole job.

- Write less code. Find a framework that you get along with, and stick with it. This takes away all the joy of learning new things, but you can still get work done. Develop and nurture your personal code library like you're tending to a garden; your personal code library should be highly modular, and as simple as possible, so that you can use pieces of it as often as possible in your projects, so that it's constantly being improved. Reuse as much as you can from each project.

- Do your thinking on the toilet. Or in the shower. Challenging programming often has two separate aspects, the part where you try to understand the problem you want to solve, and the part where you write code to solve it. You don't need to be in front of a computer to do the first part. Likewise, when you're in front of the computer, try not to do the second part -- just sit down and bang out code under those outline comments for as long as your schedule allows.

- Keep a notepad nearby. I carry a Remarkable everywhere now. I can sit in a meeting and write things on it and it's a lot less rude than typing on a laptop or my smartphone. People probably figure I'm just taking notes in the meeting, but I can be flowcharting or braining out the next piece of code. A paper notebook works fine for this too.

- Aggressively guard what's left of your productivity. My cell phone sits behind me or out of sight; my email tab is closed or on another virtual desktop; headphones are in. Any problems that I regularly encounter in my development environment get time set aside to permanently solve them in a way that's convenient for me. If I find that I need to be able to rapidly switch between different versions of some software, I work and work on my tooling until it's just a short commandline statement to do it. As a recent example, managing unique random passwords for everything was starting to cause a little bit of friction; a few dozen times a day, I had to switch to KeePass, scroll down to or search for the appropriate password, copy it, switch windows, paste. The other day, I wrote "pcp", for "password copy", which takes the title of a password for an argument, opens my KeePass file, locates the password, and copies it to the clipboard. I only touch the KeePass UI now to update the file.

- And finally, say no sometimes, or push back a little bit on your boundaries. If you can, find a place to work where you're most productive, whether it's a different office in the same building (so that co-workers aren't popping their heads into your workspace), or from home, or a coffee shop. Make yourself unavailable once in a while so you can get caught up. Take time away so that you're not also fighting off the inevitable fatigue from doing lots of context switching all day long. Avoid getting talked into meetings that are optional where you aren't likely to have much influence.

karthikb• 8 years ago

I've tried to keep this top of mind for my team. It hasn't been perfect, but:

(every 2nd) Mondays - Planning

Tuesdays - some meetings for followups, sparingly

Wednesdays - NO MEETINGS ALLOWED (screaming intentional)

Thursdays - some meetings for followups, sparingly

Friday - NO MEETINGS ALLOWED (screaming intentional)

Works fairly well. There's a major increase in the amount of work done on W and F. However, going to three days without meetings didn't really help, as the problems we are working on do require lots of whiteboarding and brainstorming sessions between engineers.

pkaye• 8 years ago

I've found if the teams have mostly senior engineers there is very little need for meetings. In my current situation we just have one meetings per week to discuss status and priorities. Everything else is slack chats and adhoc meetings among individuals as needed. Mostly everyone is in sync on what is the right thing to do or if not, hash it out in a quick discussion.

haskellandchill• 8 years ago

That's how I love to work. We are adults and most of our workload is fundamentally adhoc, changing with our business partnerships and market fit. Unfortunately at my current job we squaded up adding extra meeting load anyone who works across squads. With weekly planning meetings and standups for every squad it's rough. Also people treat standups like they are free, why not add more? Well they are not. I have to fight being put on more than one. It's already one more than I would like anyway :)

maxxxxx11• 8 years ago

Reading the comments here I find it interesting how management totally ignores feedback from developers. A lot of devs think open offices and endless meetings are a drain on productivity. So you would think the reasonable response would be to address these issues to get as much productivity out of these often highly paid people but instead the top guys often do exactly the opposite. It's a very curious dynamic.

gk1• 8 years ago

I agree that managers should very mindful of filling their teams' calendars with meetings. But there's not much a manager can do about open offices. They didn't design the building or the floorplan, and they can't change it now. Those decisions are made way above the typical managers' pay grade.

maxxxxx11• 8 years ago

Someone up the chain made those decisions based on some input. This stuff doesn't come down from the heavens.

rhizome• 8 years ago

At a recent interview I could have swore I heard someone stifle a laugh when I asked when the last time they had an uninterrupted 4 hour stretch.

seanhunter• 8 years ago

This is a constant trope, and every time it's wheeled out a bunch of developers say they would love more uninterrupted time and their own offices vs open spaces. Both of these ignore the obvious - you don't optimise on productivity locally you need to optimise on output of the system as a whole. Productivity of the system as a whole is significantly improved by communication. Devs in offices may burn through a ton of tickets very productively achieving failure by building the wrong thing.

Secondly, people who have never been managers often don't understand the externalities. As a manager, I've been asked "Why should the devs get so much better computers/bigger screens etc than us?" Different conditions can create an intense feeling of unfairness among people who don't get those conditions. Those types of things can wreck the culture at a company.

Finally, open space is much much more flexible, so easier to change up when you need people to sprint together on a thing, when you need to scale up your team etc. Offices are extremely inflexible and typically anchorpoints for people's perception of their own status. Therefore once someone has an office, it's practically impossible to get them to not have one any more, even if circumstances have significantly changed.

It's easy to blame management but it may well be that management have a totally different set of problems to consider than you.

dasmoth3• 8 years ago

Therefore once someone has an office, it's practically impossible to get them to not have one any more, even if circumstances have significantly changed.

What sort of change are you imagining which means someone should stop having an office?

AnimalMuppet• 8 years ago

All true. And yet, management has to keep an eye on individual productivity, for at least two reasons. First, optimizing global productivity requires at least reasonable local productivity. And second, local productivity affects morale. You can lose your best people if they consistently feel unproductive.

mindcrime• 8 years ago

Both of these ignore the obvious - you don't optimise on productivity locally you need to optimise on output of the system as a whole.

True, but in many cases, one good way to optimise the productivity of the system as a whole is exactly to optimize productivity locally.

Productivity of the system as a whole is significantly improved by communication.

Yes, but being in an office doesn't mean "no communication". Neither does being in an open environment guarantee effective, efficient communication.

Devs in offices may burn through a ton of tickets very productively achieving failure by building the wrong thing.

Same for devs in an open plan environment.

newfoundglory• 8 years ago

And most importantly, open space is cheap. None of the reasons you listed explain an open space containing 40 people working in different roles and teams, some of whom will never ever have a work related conversation.

bpyne• 8 years ago

"Productivity of the system as a whole is significantly improved by communication."

That's an overly-generalized statement. Communication is sometimes helpful, when the people involved are good communicators. Often it's a source of distraction, e.g. email chains with multiple people replying-all to a topic that is at best tangential to what you're working on. There's also an equivalent that occurs with meetings in which people invite everyone they can imagine having any interest in a topic. This strategy has a wonderful way of bringing together a large number of people, most of whom have no valuable input, or interest, in the topic at hand.

The more detailed a job is, the more uninterrupted time it requires. So, if you want quality work and don't want to push the due date, give the person doing the work some uninterrupted time.

I've been a developer for 26 years professionally and, outside IT, I ran a 501(c)(3) of several hundred people. Yes, you can leave people alone to get work done without compromising organizational goals.

lawnchair_larry• 8 years ago

The biggest problem with this argument is that the output of the system as a whole is not improved by open offices. It has all of the same problems that apply to productivity of individuals, with virtually no advantages. It’s a myth that communication is hindered by private offices, as much as managers or PMs want us to believe otherwise.

If devs are burning through tickets yet building the wrong thing, it’s not the office layout that is the problem. So having an open office environment while changing nothing else in that example simply means they are going to build the wrong thing much more slowly.

You are correct that it’s hard to come back to open space after having an office, but it isn’t for the reasons you mention. The reason is simply because open offices suck.

commandlinefan• 8 years ago

Man, if programmers ever do unionize in the face of callous management, the managers will really have nobody to blame except themselves.

abc_lisper• 8 years ago

This is a trope argument. You don't have to be connected at the hip with the rest of the company all the fucking time to make sure you are building the right thing. We are people, not cattle. You can instead do daily standups to make sure people are going in a direction you want. People (Management esp) who never get in the zone, don't fucking get it.

Status, envy, screen size - this is all bullshit. You have never been a good dev.

kazinator• 8 years ago

Therefore once someone has an office, it's practically impossible to get them to not have one any more

Oh 2002 kicked quite a few asses out of offices and back into cubes.

ljw1001• 8 years ago

Sorry, but no. You don't deliver 'the wrong thing' because you're not interrupted constantly. One status check per day is enough to insure that. All the urgent communication that can't wait a day is ego-driven not results-driven.

sh873• 8 years ago

Here’s a quick experiment. Tell your devs what you want. Get the hell out of their way. Identify the people and rituals that are ‘interrupting’ by nature and put in huge road blocks and obstacles between them and your devs. See and measure the difference in output. You will stay amazed.

chrisbennet5• 8 years ago

You aren’t wrong about it being difficult to allocate resources so I can understand where you are coming from.

If it is a money problem, don’t lie to developers and tell them that it is “to encourage collaboration” i.e. don’t pee on my leg and tell me it’s raining.

If management truly believes in the collaboration meme, I fully expect them to share a big office. After all, what could be more important than having the gears of management fully meshed?

Either hire low skilled cooks to make your product and control them rigidly (like McDanals) or hire chefs. You can imaging how unhappy (!) a chef would be if you treated them like a Mcdonalds worker.

dahart3• 8 years ago

It's worse to have focused productive time on the wrong thing than it is to have meetings that clarify requirements and goals.

I've watched a lot of very highly paid people dive into deeply technical and interesting problems that nobody needed a solution to, and fight to protect their time so they could finish. That wastes more time and money than meetings.

maxxxxx11• 8 years ago

Some of us are adult and have a professional attitude and don't need constant management. We know what needs to be done. We don't need to be treated like children.

pdimitar• 8 years ago

The original article very clearly states that it discusses managers having to manage makers. Some of the jobs you described definitely don't seem to fit that description, so please don't hijack the discussion.

Also, not all teams have poor management. That you worked in the film industry where supposedly people had no idea of the priorities daily says nothing about the software industry in general.

My last several jobs involved sync meetings once every 5-10 days. Every meeting took 5 to 15 minutes and we all knew exactly what to do. Intermittent meetings only happened when somebody was blocked.

leggomylibro• 8 years ago

It seems like ultimately, most senior managers don't care about feedback from developers.

They will ignore and steamroll any opinion that does not fit whatever arbitrary metric they need to meet, and when your dire predictions come true they will act like there was no possible way to expect them.

some_account• 8 years ago

At my place, the people who book the meetings are the ones who are coordinating work done by others, so they need meetings to be productive. We have a product owner that is constantly justifying her existence by talking very much about things that have zero relevance to what we are doing at the moment.

mattmcknight• 8 years ago

I've had success with an intermediate to a huge open office vs a private office which we called a lab, but might also be called a team room. We had about 6 people in there, all working on the same project, and it wasn't a constant distraction. We did a fair amount of pair programming as well, where a domain expert would sit with me as the computer scientist, and it was a very low bar to engaging in that sort of thing to slide around the corner. Of course we all had our own two person shared offices as well, but our main workstations were in the lab so most time was spent in there.

maxxxxx11• 8 years ago

I like small team rooms too. If you have up to 5 or 6 people the noise is still low and it's possible to have conversations.

floodfx• 8 years ago

I wrote an app called MakerSession [1] which was inspired by this essay. MakerSession automatically blocks out time on your (google or microsoft) calendar based on when your day starts/ends and how much time you need to get stuff done...

[1] https://makersession.com

padobson• 8 years ago

Working in the eastern time zone for clients on the west coast has allowed me to find some ways to solve this problem.

The time difference is about a "half day", the one PG is describing here.

So if I schedule all of my meetings in the afternoon pacific time, I can get a full day of work done before calling into teleconferences.

So I wonder if some kind of staggered scheduling, like PG described in the essay, is the answer to this problem.

bayindirh• 8 years ago

I have been parts of projects which failed just because the manager refused to accept that developers' need uninterrupted time to start and warm-up to achieve full speed in their daily routines.

Add micromanagement into this mix, and the environment quickly approaches to real-life-dilbert.

Addenda: Obligatory dilbert: http://dilbert.com/strip/2018-04-21

SteveJS• 8 years ago

I took this to heart when it was published and ensured I schedule full team meetings that are as short as possible, and either start a day, end a day, or are directly adjacent to lunch. I also ensure there are 2 days of no scheduled meetings.

Another thing that helped me as an IC was keeping notes as a habit. It needs to become ingrained enough that it isn't blocking flow to jot a note into OneNote or Evernote. This allows you to 'see' the interruptions later.

I'm more of a 'pile' based note taker, so it's a gigantic list of timestamps + notes. If you are getting too many interruptions it also provides highly detailed 'proof' to the person in charge.

More recently I realized that getting distracted today is tremendously easier than it was in the past. When I find that is an issue I set a meditation timer to ring a bell every 5 minutes. If I'm not doing what I want to be doing when that bell goes off, I just go back to doing what I planned. At a certain point the bell ringing is just a habit to ensure your attention is in the right place.

justherefortart2• 8 years ago

I took over as IT Director at a company with a small team. Everyone would take their issues to the developer all day long, interrupting his day constantly. So every new "fire" because the latest task.

Not surprisingly the hacked together new website (which went live months late and $100s of Ks over budget) was a train wreck. Unreliable and constantly causing errors/issues.

The first thing I did was said the only person that can talk to the development team is me. It took about 2 months to get all the software processes in place that were non-existent, to get the entire website working and stable, and to get our task/goal list under control.

The cocksucker owner comes to me and says "I want these 4 project you quoted that would take 6 months done in the next 3 months". So I quit (so did their lead developer that was doing 90% of the heavy lifting).

IT Management is a mess everywhere I've ever been, just to varying degrees. Maybe this is because most my career has been as a consultant or contractor, but it's really discouraging.

woqe• 8 years ago

I just finished reading the Phoenix Project, and I wanted to say the beginning of this post read almost exactly like the first 3/4's of the book.

https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine...

curun1r• 8 years ago

I hope you didn't jump straight to quitting. There may have been a legitimate need to launch something that quickly. When I get requests like that, I usually explain the immutable rule of software development... deadline, quality, scope: pick two. Since he wants to adjust the deadline, ask him which of the other two he'll compromise. One answer, quality, would probably lead me to quit, since I can't stand delivering stuff that sucks, but if he were willing to adjust scope of those projects, it's a completely reasonable request.

cpach• 8 years ago

Don’t use slurs like that here.

chx2• 8 years ago

We found start of the day to be really great and easier to schedule.

kristianov• 8 years ago

My experience is that start-of-day meeting only works for a team of morning people or they all have kids. People show up at work at different times, and their day start at different times.

chrisbennet5• 8 years ago

Morning seems pretty common for stand-ups. Personally, I try to do my heavy cognitive tasks in the morning (so not a fan). I think that some managers use morning meetings as a way to make sure people come in to work on the managers schedule.

Mornings are my “thinking” time.

The good idea/solution comes to me in the shower or while I’m sleeping and I drive to work thinking about it. I’m usually able to get a good start on implementing it before people can interrupt me.

kovek• 8 years ago

I just wanted to share that I also had success setting a regular timer woth a short period: 3 minutes. If I do not notice the timer (it's just a small sound), then I am focused on my work. If I do hear i, then I realize that I am distracted and give myself 3 to 6 minutes (1 to two timers) of meditation or distraction, depending on what I feel I need at that moment.

oftenwrong2• 8 years ago

This meets with my experience. I rarely have meetings, and I regularly get solid, 4-hour blocks of productivity. Typically two to three time per week. Those pushes account for most of my work, and my best work.

I do not schedule those 4 hour blocks because I would not be able to stick to the schedule. I often have trouble concentrating for even 30 minutes straight. When I hit 4 hours (and my time tracker sends me a notification to celebrate), I am always surprised. I get into the zone, and then I find myself still coding 4 hours later.

Every meeting is a chance to miss that enter-the-zone window.

pavel_lishin3• 8 years ago

I'm like this too, and I hate it - because it means I can't reliably get those four hour blocks.

Not having a schedule isn't a good thing, it just means that if you're ever in an environment where outside factors become significant (new job, new child), your productivity gets fucked.

slgeorge3• 8 years ago

One suggestion: change the way you think of a schedule. Book in those 4 hour blocks, calendar gym, calendar leaving the office etc.

People tend to start trying to work around the outside of those blocks.

donkeyd2• 8 years ago

I have the same issue. I'm managing a team, but at the same time I'm expected to actively participate toward the sprint goals. Because I keep getting pulled away for meetings, or to help the other developers, I can't get any focus time and my velocity is incredibly low. To the non-developers in my team, it seems like I'm a really slow developer and it's really hard to explain to them that it's really hard to write code ad-hoc.

vogt• 8 years ago

What time tracker do you use?

oftenwrong2• 8 years ago

https://qotoqot.com/qbserve/

I like it because it's all automatic.

sh873• 8 years ago

Meetings.

<rant> This has slowly and surely become the top reason for productivity loss at work for me and in my opinion, also for the team that I work in. I have walked out them once I realize there's no valuable input or output, declined them, carried my work in the meeting room, passively attended them, aggressively tried to keep the meeting on track, MoM'ed the hell out of them and just about tried every single trick I've known to get an ounce of productivity from them. And I have failed.

My next attempt is to measure time spent in meetings per sprint and report it out in the retro (meeting, ironically). I have no clue how I can get the people responsible for developer productivity see this gaping hole that are meetings that I don't have to be a part of. </rant>

blueprint• 8 years ago

Maybe consider working with people who give a shit

ccvannorman• 8 years ago

My mitigation strategy is I book calendar time for entire days to work on stuff. "Want to get coffee on X or Y date?" "Sorry, I'm totally booked those dates -- how about Z date/time?"

It makes me seem unavailable/scarce, and allows me to book things on my "manager days". The key is using the calendar to your advantage .. control your own time.

nategri• 8 years ago

Oldie but a goodie. Play it again, Paul.

eddieschod• 8 years ago

http://calnewport.com/blog/2017/04/05/why-are-maker-schedule...

dasmoth3• 8 years ago

This is an interesting follow-up to the original example. I quite like the proposals he makes (although with some reservations about the extreme one —- some level of contact with end users is always valuable in my experience)

However, relevant to contemporary software (where nearly every project, regardless of scale, seems to need a team...):

The exception, of course, is that makers working in teams have ways to communicate within their team.

My experience is that “the team” seems to be a disproportionate source of interruptions. If anything, I wonder about a system where a manager acts as a form of message-queue within the team. Pretty much the direct opposite of a lot if contemporary approaches (...scrum...) but perhaps a bigger increase in maker-schedule time than focusing on external interruptions.

lmilcin• 8 years ago

The problem with working at the large company is that every manager will see open calendar as an invitation to put in some meetings.

For this reason I am booking in my calendar actual working time. Since I am based in Europe and work with people in both US and Asia, I do this smack in the middle of the day so that I can have meetings with APAC in the morning and with US at the end of my working day.

I frequently have managers asking me why my calendar is booked so much to which I respond, "why YOUR calendar is booked so much". This of course has to follow with suitable explanation which is more or less based on this essay which I read many years ago.

voxmatt2• 8 years ago

We started Clockwise to address this problem, and this PG article was a major point of inspiration. (Looking through the comments, that seems to be a trend!)

We just launched a private beta of Clockwise for Chrome, which helps automatically put more maker time on your team's calendar. It's free and we'd love everyone's thoughts. Feel free to send me an email if you'd like to hop the line: matt@getclockwise.com

https://www.getclockwise.com/product

rupertdev• 8 years ago

This is cool!

Too bad my team is trapped in the Outlook world..

voxmatt2• 8 years ago

We'll get there! Had to start somewhere, and Google Cal is a little more common among early-adopters.

bmpafa• 8 years ago

Clockwise for Chrome, powered by AI,

Can you share where AI fits in the product?

It's not that I'm skeptical of every time a product vaguely alludes to AI in their copy, but... well... I can't think of a way to end that sentence.

ozim• 8 years ago

My feeling is it tries to fix people problem with tech. If you have reasonable manager who would respect people time instead of bomb dropping, you don't need the tool. If you have micromanager, you won't get to him with the tool.

tquinn• 8 years ago

I've run a small distributed team for years, and I've mostly resolved the manager vs maker challenge through a combination of:

-desynced collaboration tools

-avoiding interruption based tools as much as possible

-short & focused bi-weekly meetings at the front or back end of the day

It allows the majority of the day for a maker schedule, while allowing for just enough manager time. Also with desynced tools (ex: outstanding support/bug/etc issues in Trello), as long as everyone is checking in at regular internals (say 2x a day) -- things can move through fairly quickly without constant interruptions.

For the manager side I use a mix of:

-Calendar/Contacts

-Evernote

-Workflowy

-Trello

-Slack (at scheduled times, leaving it on all day is horrible idea)

For the maker side:

-Workflowy

-Trello

-Pathjet.com (A small tool that I designed for myself which mixes GTD + Kanban + Pomodoro)

-Prior to my own tool, I used a Pomodoro timer + Workflowy on my machine

-Sometimes I think it's great to get off my machine, and just use a pen+legal pad to do planning/sketching/brainstorming

mellett68• 8 years ago

I have been keeping one day a week for the manager's schedule- style calls and appointments.

The rest of the week is divided in to half-day blocks which from my own experience is the minimum useful time to switch context and complete or work on some task.

I'd never read this before but it sums up problems I've had in teams previously with scheduling and especially short-notice "quick" meetings that wreck an afternoon.

It also means there's sacred time in my calendar for unbillable stuff, which gives peace of mind rather than thinking "but I could be doing..."

kristianc• 8 years ago

I read Dan Pink's book "When" recently, and made a conscious effort to schedule all of my meetings in what Pink calls admin time between 1 and 3 in the afternoon. It's a win-win - I can go to the meetings having just been to the gym, and my morning is freed up for making.

vikasuy42• 8 years ago

Check out http://try-tempo.com/

A few friends and I built this to create more "maker time" for ourselves. It helps you group your calendar events together for the day so that you get longer stretches of time to be creative.

Would be honored if you gave it a try!

lainga• 8 years ago

Unrelated to managers, this is why I have trouble doing work when I'm home from university: "Could you fold the laundry now...?"

chrisbennet5• 8 years ago

This! That’s why I have an office that isn’t at home. (I’m a consultant/contractor.)

kyleblarson• 8 years ago

A context switch costs many IQ points and it takes at least an hour to get them back.

nkozyra• 8 years ago

This is my number one reason for working at nights outside of normal working hours.

raleigh_user• 8 years ago

I cofounded a small agency. I really enjoy it. I spend a lot of time away from our team and this is no shot at the amazing team we built.

But the time where you're in the zone and able to produce/be creative is imperative to our growth/success.

I still have meetings but days where I don't I go on really long runs in the mornings (15 miles or so) and during that time get in a great state of mind. Then 3-4 hours of awesome productivity and the business seems to keep moving forward at a rapid pace.

josephcooney• 8 years ago

Pro tip: Decline meetings, as many as possible.

brazzledazzle3• 8 years ago

I’ve encountered so many people that assume someone has to come to any meeting they’ve invited them to and it never fails to blow me away. I can understand the mindset a bit with managers but it seems to have little to do with title.

It always starts with a message or a call asking where I am. When I tell them where they let me know I’m late for a meeting. When I tell them I declined it or I was tentative you can practically hear the gears in their heads grind and seize up. The thought seemingly had, up until that point, never occurred to them to check the attendance on the invite before the meeting starts. “But... I booked it in an open spot on your calendar. Aren’t you available, can you come? Here’s why I need you here...” This is where it becomes clear to me that they’ve never considered populating the meeting with more than a subject and a conference link. They treat an open calendar like you’re some kind of reservation system.

chrisbennet5• 8 years ago

A friend of mine got so sick of the many useless meetings at a company he worked at that he would just started declining any meetings that didn’t have a written agenda.

When I schedule a meeting with clients, I send them an email with the questions I’m going to ask them and what I need to learn from the meeting. As a meeting attendee, I don’t want to be asked a question that someone knew they were going to ask before the meeting. I want to hit that meeting with answers so I’m not having to say, “I’ll look into that and tell you at the next meeting.”

droosevelt• 8 years ago

This is definitely a great model to strive for.

Whenever coworkers try to schedule unnecessary meetings w/ me I send this - https://shoulditbeameeting.com/#/

Cofike• 8 years ago

This was a major problem at my last company. There were days where meetings weren't an issue but the support channel we had to monitor was. Ugh

Fzzr• 8 years ago

I regularly send this to people where ever I work. Never stops being relevant.

blablabla123• 8 years ago

I've tried this at 2 companies, one was even my own startup. It seems like a natural separation but in my experience it alienates the makers from the business. Probably that's not an issue if you just work for the tech that is in use. YMMV but if not, it's not the best idea.

Maker's Schedule, Manager's Schedule (2009)

Related Stories