You did not specify precisely your role/responsibility profile for this startup, but if we continue along the lines of stereotypes, you will be wearing many hats as the various circumstances of the startup variously dictate from day to day.

Based on that stereotype, and the background of past experience, perhaps the most difficult transition a person with your profile could make is to *not* consider oneself a "programmer".

This might be an important consideration, because one of the most challenging aspects of transitioning into a 'startup' mentality is the shedding of any illusion of a coherent 'job description'.

The troublesome fact is there will be *many* times when you wish you could be writing some code, but some emergency situation will pull you away to something you do not want to do. The discipline required to cope with this may be the biggest challenge.

This is a gross oversimplification that varies depending on industry, economic factors, competitive environment and available resources (exogenous) ... as well as incentives, action plan, team cohesion (endogenous) circumstances.

IMO, the key skill to learn for time management is the setting and re-evaluation of priorities. Look at what you have to do, rank the tasks by urgency (based on criteria like: making me some money, keeping me out of jail/trouble with Inland Revenue, meeting my commitments to customers), and allocate amounts of time to different tasks depending on their priority. It takes a little bit of practice, but not too much.

When the status of a task changes (bailiffs knocking on the door/final absolutely the last deadline for paperwork/critical bug taking your customers system down) re-evaluate the top half dozen tasks .

You can do this on paper to start with - after a while IME it becomes a habit that just happens, and you have a good idea of where you are at any given time.

One other thing: don't spread yourself too thin. It takes a little while to shift your attention, if you try to allocate 5 minutes to 96 different tasks for the day, you won't get anything done.

There's also a couple of tips I've always found useful on time management in this node from a few days ago.

For me, the hardest part of that transition was not thinking about a single problem as much in a single day. Like other programmers, I want to just keep hacking on the same thing all day, and that next little bit is just 15 minutes away and then the next little bit is just 15 minutes away and then I've missed lunch, dinner, and the sun is coming up.

Now, I have to spend time on a lot of things during the business day, so I schedule time for each of those things. If I don't get all the way through it, I stop at a good point and move onto the next thing. There is a little time spent changing contexts, but I can mitigate that by also taking a break between tasks to get a drink, get up to walk around a bit, make a couple of phone calls, and so on.

It sure feels like I don't get to program much anymore, and that I accomplish a lot less, but as a really good manager told me "if you finish one thing in a (business) day, you've done a lot". Most of the time I just keep other things moving.

The other trick is to solve non-programming things as fast as you can. Instead of going back and forth on a lot of discussion, try to make decisions earlier, or get the people you work with to make decisions earlier. Avoid digressions in meetings, stay on message, and get to an "action item". Keep meetings short and keep people focussed. Tell them at the start why you're talking and what you need to accomplish. I don't mean that you should cut out all small talk and banter, but as one of my co-workers has said "you're talking time is cutting into my fixing it time". People will talk as long as you let them and repeat things as many times as you let them.

Along with that, try to solve problems yourself so you don't have to hold a meeting about it. For instance, one contractor asked me "There's a bug in this module. Should I contact the author?". If he had just done that and gotten the fix (which the author sent right away), he could have kept moving on his work and wouldn't need to bother me about it. You can probably come up with a lot of other examples like that, and you need to take the initiative to get to the solution without bugging other people, if possible. Don't be a loose cannon, but don't let things involve more people than they need to. Given options, people will discuss them and you're back to the endless meetings from the previous paragraph.

Lastly (for this post), put off things you don't need to deal with right away. Some people are interrupt driven, so they deal with problems as they come up. The problem is that problems keep coming up, so their day is dealing with new things. Shove some things into the future: "Let's talk about this (tomorrow|next week)" or "Let's give it a day to see what happens". This isn't procrastination, it's two other things: triage (can this wait?) and distance (maybe this won't be such a big deal in a day). A lot of things seem like a big deal at the moment, but then turn out to be unimportant later on. Having a little patience and not panicing can often weed out those things. Not everything is software where you can just patch the source and commit the fix, so don't hold yourself to solving every problem immediately. For instance, in a recent contract negotiation, we were worried about a particular clause that might show up. Our contracts guy got in a big panic, but I told him to leave it to after the weekend. Over the weekend, the other side changed their mind and it wasn't a big deal. The extra time to think let the other side relax and think over their offer, and things weren't a problem. If we had pushed to solve it right then, they probably would have kept the problemed clause in that contract.

So, I've told you to spend time on everything you need to do, but also solve problems the first time, except when you should give things time. It's not a perscription for change, but it's something to think about. The only way to figure it all out is to get the wisdon that only the pain and sufffering of expereince brings.

Good luck, godspeed, and don't lose too much sleep. Small business sucks for everyone. :)

Specific to the question of books and approaches, I highly recommend David Allen's "Getting Things Done". Don't be put off by the shiny self-improvement wrapper -- once you get under the surface, this is way more pragmatic than any other time management system out there. Allen coaches business executives, CEOs, etc. -- people with seriously disfunctional situation-caused ADD (300+ emails a day).

In one of his seminars, he explains why he evolved this system as follows, "Because I'm the laziest SOB alive...". In reading and listening to his stuff, I realized that he put the "laziness, impatience, hubris" philosophy at the core of his system -- I think anyone who's into Perl and looking for time management help should check it out.

What I would suggest is this. If the jobs are small, do them one at a time after prioritizing based on urgency, not how fun they're going to be. If you have to break the boredom, take 15-30 minute breaks and do something else that doesn't require a whole lot of thought. If you hit a total obstacle, move to the next most important job and sleep on it. The answer willl usually be there in the morning.

If on the other hand the jobs are large, and you have to show some sort of progress in each one to the client, make yourself a schedule based on priority and how much programming time each job is going to take. Stick to it. The schedule should never have you going for more than a few days without working on a particular job, and never have you working on more than a couple jobs per day. Keep a log for each job and write down where you are in the job and what issues you're currently addressing, so you can pick up where you left off with minimum downtime. Comment your code as much as you possible without significantly affecting your programming time.

Above all, put in x number of hours per day whether you want to or not. Getting started is the hardest thing to do.

I know this was (most likely) sarcasm, but I was talking to my uncle (at thereapist) at a family gathering about two weeks ago, and based on some of the things I was describing, he sent me the list of what they look for in Adult ADHD -- and although multitasking is the useful benefits, there are enough other factors that are common, that it can outweigh any benefits. If you look at some of the common indicators, you'll see that quite a few of them are not particularly useful in the long run.

Doing lots of tasks at the same time is of no use of if none of them ever get done.

Update -- It'd probably help if I actually gave some advice -- keep a to do list. I keep mine on a small white board. I try not to take on any more tasks if the board fills up (which is about 12 to 18 things, based on the size of my writing and the board). I find it useful to make sure that I don't lose sight of all of the tasks I have assigned, and not to get so many on my plate that none of them get one.

I keep a text file open in emacs for each large project that I'm currently working on. Any time I have an idea, I switch buffers and jot it down. At the top of the file are notes about the details of what I'm currently working on. Then I have another file with notes about shorter projects and other things I need to do. These files are mostly ordered top to bottom by priority. At the top of my main file is a section that I like to clear by the end of the day. I don't just keep programming notes in here -- I also include notes about emails and phone calls that I need to respond to, etc.

I'm not suggesting you adopt my system (maybe you're a vi person :), but having a good organizational system like this will really help you alternate between many projects.

See how people program themselves to do the things. If you try to install those program one by one, in your system, you can have skills of many to do multitasking.