I had the privilege last night of joining a panel as part of DUL Digital Scholarship Service‘s Doing DH series. This is a great series and the panel format is a lot of fun: 5-minute lightning rounds followed by free-roaming discussion. The subjects are interesting: this one, project management. And the panel itself was great: Mary Caton Lingold, Erin Parish, and Ashley Reed are doing fantastic things! I wish I had been so with-it as a grad student!

So far so good. But what do I know about project management?!?

For about a decade now I’ve had the privilege of working with a number of brilliant colleagues from several fields, distributed across 5 time zones, with an annual budget ranging from a million dollars to zero. What little I know about project management I learned on the job, often the hard way, sometimes through failure. So, I figured I’d just offer the panel a list of maxims, lessons that I think I’ve learned along the way.

Some members of the audience asked for the list…so here it is. This is not meant to be exhaustive, prescriptive, scientific, or well informed! These are just a few of the notions I try to keep in mind while collaborating struggling to keep up with a bunch of brilliant scholars.

• It is crucial to begin with a clear idea of a need; in fact, the multiple needs of multiple users and user scenarios. Try to keep your user and the interface as close to the initial design and build process as possible.
• Try to decide what you need in the first case without reference to what packages you can buy. Start with needs not solutions.
• Relationships are important; people work better when they want to help each other; when they don’t want to let each other down. Eat together. Laugh together. Sleep on couches. Meet families. Take the time.
• Inefficiency is not always bad; duplication is not always bad; sometimes you have to have the painful go-nowhere conversations to pave the way for more productive talk.
• Try to avoid over-engineering whenever possible. Don’t throw technical solutions at problems that are really social.
• Constantly revisit even basics. Never assume that everyone understands each other. Don’t learn two years into a project that “document” means two different things to two different developers. 
• Learn fast the distinctive strengths of each team member; always think about solving problems through creative combination of complementary strengths.
• Assume that for any given problem the brilliant solution could come from anyone in the room. 
• Aim high. It is better to have way more deliverables than you can make; way more ideas than you can develop. Focus on the good that you build and not on the things that you couldn’t. 
• If you are like me you don’t want to tell people what to do. Sometimes you have to. That doesn’t make you a bad person.
• Stock your team with the smartest people you can find. Try to articulate a clear set of goals. Get the hell out of their way. 
• Sometimes team members think they cannot do things. Sometimes they’re right. Try to develop a Spidey sense for sensing when they’re not.
• As my colleague Hugh says, you cannot erase complexity; you can only move it around. That applies, I think, not only to development, but to management as well.
• Conflict is not bad. Disrespectful conflict is bad. Difficult things are difficult, and talking about them is too. 
• Develop a network of extra-mural collaborators, trusted colleagues who can offer a disinterested opinion of things. Even the most brilliant team can benefit from an outside perspective.
• Take good notes. Write down every decision. You think you will remember. You will not. If you don’t understand something ask. It is always good for smart people to explain difficult things, even repeatedly.
• Soft money sucks. I would rather nurture a small pool of talent over the long term than host an army of transients. 
• Share the love. When someone does something awesome, say so. Loudly, directly, and to anyone who will listen.
• Lead through service. Try to do the crap work for your team, so that they don’t have to. 
• All too often in the DH space the Humanities professor, who tends to be the manager, is thought to be brains of the operation and the programmers mere implementers. That is wrong, short-sighted, stupid, and unsustainable. Don’t think like that.
• Remember that we spend most of our time failing. Hiding that fact impedes growth. Don’t be afraid to jettison things that don’t work, even things that you built, at consider expense of time and money. Don’t fall prey to the sunken cost fallacy.
• Finally, try always to relate even the smallest detail to the big picture. Situational awareness of the whole, at all times and at every scale, is your job. Juggling the small and the large at the same time in in my view the manager’s most important, and also most difficult, role.

The conversation was great, stimulating, productive, a lot of fun. It may have helped that panelists and audience members alike had been fueled by the heavenly (or evil, depending on how you look at it) confections of Scratch.

Liz, Will, and anyone else who happens to see this: I’ll speak at any venue that has those little donut/muffins.