“Hackathons” are cool. But who knows what they really are and how they work? This makes them ideal things for clueless managers to do poorly. But if we take a little time to understand their “why” and “how” they do represent a potentially useful organizational form that could have a positive impact on sclerotic, inertia bound institutions. For higher educational organizations they have special potential for moving beyond “we tried that 5 years ago” and “not invented here” and for making actual interdisciplinary teams actually effective and the experience of working on institutional problems inspiring instead of demoralizing.
This post from InnovationManagement.se is a good starting point because of how it manages to convey the essence of hackathoning outside the context of coding.
That essence is group process bound in space and time that focuses effort on well defined challenges in a short, structured design sprint. The elements are important:
- defined chalenge
- structured process.
Notes from this semester. Each semester I jot down observations about organizational practices, usually inspired by events at my place of employment. Every now and then I try to distill them into advice for myself. Most are obvious, once articulated, but they come to notice, usually, because things happen just the other way round.
- Always treat the people you work with as if they are smart; explain why you take a stand or make a decision in a manner that demonstrates that you know they are smart, critical, and open to persuasion by evidence and argument. Set high standards for yourself. Your institutional work should be at least as smart as your scholarly work.
- “it is better to be wrong than vague.” – Stinchcombe
- If smart people are opposed to your idea, ask them to explain why. And listen. Remember, your goal is to get it right, not to get it your way.
- Do not put people in charge of cost cutting and budget reductions. Put them in charge of producing excellence within a budget constraint.
- Make sure everyone is able to say how many Xs one student leaving represents. How much will it cost to do the thing that reduces the chance a student will get fed up with things?
- If most of what a consultant tells you is what you want to hear (or already believe), fire her.
- Don’t build/design system and policies around worst cases, least cooperative colleagues, people who just don’t get it, or individuals with extraordinarily hard luck situations. Do not let people who deal with “problem students” suggest or make rules/policy.
- Be wise about what you must/should put up for a vote and what you should not. And if you don’t know how a vote will turn out, they are are not prepared to put it up for a vote. Do your homework, person by person.
- If a top reason for implementing a new academic program is because there’s lots of interest among current students, pause. Those students are already at your school. What you want are new programs that are attractive to people who previously would not have given you a second look.
- If you are really surprised by the reaction folks have to an announcement or decision then just start your analysis with the realization that YOU screwed up.
- Related: and don’t assume it was just about the messaging; you might actually be wrong and you should want to know whether that’s the case.
- If you or someone else’s first impulse when asked to get something done is to form a committee, put someone else in charge of getting that thing done.
- Persuade/teach folks that teams and committees in organizations are not representative democracies. The team does not want your opinions, feelings, experiences, or beliefs; it wants you enrich the team’s knowledge base by reporting on a part of the world you know something about. And that usually means going and finding out in a manner that is sensitive to your availability bias. In the research phase, team members are the sense organs of the team. Be a good sense organ not a jerking knee or pontificator or evangelist or nay sayer.