Now that I am going to be a "lead" again, I'm reviewing what I've done wrong in the past. My last stint as a manager was the worst professional experience of my life, and I don't want to repeat it.
One good thing about my new project is that I'm getting in at the beginning. I'll understand the history better and I'll have some influence on the overall plan. Also, we don't yet have requirements, a budget, or deadline. I'm sure budgets and deadlines will be imposed soon enough, but this time I'll know I should quit instead of accepting an impossible task.
I've started by writing a set of use cases and learning all I can about the prototypes and the envisioned solution technologies. The use cases have been helpful in determining what I don't understand. This is one of those products where everything is easy when stuff works, but there are lots of ways it won't work, so the use cases give me a place to explore all the various kinds of error processing we will have to provide.
Our organization has a terrible "process" for software development, and so of course everyone is insisting that this is the project where we can start to do some things right. That sounds nice, but I have to be realistic: a good process doesn't get created overnight just because somebody wants it. There is no agreement among the principals about what a good process would be, so I am not hopeful that a single set of rules will be adopted by everyone. My reaction to this will be to focus on agile processes, and then try to make them look like whatever processes the higher-ups starting asking for.
I'm going to delegate a lot more responsibility to others this time around. Last time I was a manager, I tried to do all the hard work myself, and to help everyone else with the rest of the work. That really burned me out. So this time, I'll assign myself a reasonable amount of work, and assign everyone else a reasonable amount of work, and I won't try to do anyone else's job.
I plan to focus my own work on design and implementation of "infrastructure" types of stuff. I hope this keeps me in the center of things. Of course the danger is that I'll make myself a critical resource, which is bad for a manager to be, so I'll be sure to involve others in what I'm working on. I'd like to do pair programming, but I'm not sure whether this company's culture will accept it.
Finally, the most important thing I learned from last time is that this project is not my life. It's just another computer system that will make money for some people I don't know. It's not going to change the world. Nothing important is lost if I don't get it done. It's not worth sacrificing myself to complete it.