operationalizing your inner rockstar: a response to Bohyun Kim

Over at Library Hat, Bohyun asks — if you can’t get involved much as a library school student, “what can you do to increase your chances of getting a job after the MLS?”

I really resonate with her question. In her case, she couldn’t get involved because she was working full-time on top of her courseload; in my case, childcare limitations kept me from getting involved with student organizations (as I’d really wanted to) or applying for part-time library jobs (all of which paid less than childcare cost; no, thanks), but it comes to the same thing. I don’t know how much my advice is worth since (having graduated in May) I’m still looking for that first professional job, but my mantra was: “a constraint, not an excuse”.

Look, I am not going to go to a prospective employer and say “well, I am SECRETLY awesome, I just couldn’t show it because there were these circumstances that prevented me, but you should hire me over these people who are DEMONSTRABLY awesome”. I mean, I would have to laugh myself out of that job interview. So it was important to me to think — given the constraints I have — what can I do to be demonstrably awesome? Because the alternative is really not an option. The way it’s been working for me:

  • Go beyond the minimum on final projects. If at all possible, produce something which has actual users or a world-visible product. DCKX, my topical index of science content in the webcomic xkcd, was my final project for my subject analysis class — but it was also an excuse to solidify my skills from my databases class; work with real users (science professor beta testers); put something online where it demonstrates my technical competences; and, frankly, do something sexy. OK, it was more work than I had to do and it kind of ate my life, but I was going to have to do some kind of final project anyway, and my other class projects were going to survive if I cut corners.
  • Leverage your strengths. Use the time you do have. In my case, regular weekly commitments were hard, but occasional major time commitments were manageable, as was anything I could do on a flexible schedule after my kid’s bedtime. So I dumped the kid on friends and family for a solid weekend and went to ALA Midwinter 2010 (conveniently next door in Boston). And I did a few presentations at the Simmons tech lab — not too daunting since they drew on my teaching background — but boom, CV entries. And I’m good at writing, so I took an idea I was kind of obsessed with and, in two solid weeks of staying up way past my bedtime and writing and researching and coding like a banshee, wrote a paper that won the LITA/Ex Libris student writing award. Whee! (Then I slept. And did two weeks of overdue homework. I stand by my choice of priorities there.)
  • When you can network, do so, damn the torpedoes, full speed ahead. Janie Hermann wants volunteers for Battledecks? Sure, I’ll throw myself on that grenade. (See above about teaching experience. Teaching middle school is pretty good prep for extemporaneous public speaking…) I signed up for Twitter just before Midwinter so I could join that conversation, and used it like mad at Midwinter and Annual to meet people and find good things to do (both sessions and after-hours); I am flabbergasted at how much it has enriched my life. I spend a few days at conferences forgetting I’m an introvert and just try to be as visible as I can. (Another mantra: “If I can’t be employed, at least I can be famous.” Four mentions in ALDirect so far. And tomorrow, the world.)

Maybe this is not your sort of thing. Maybe you’re not into teaching, and finding time for networking is hard. I get that. The point isn’t the specifics of how I do this (which, heck, for all I know won’t even land me a job) — the point is that we all have ways we are secretly (or not-so-secretly) rock stars, and “a constraint, not an excuse” means that you have to find the ways — within the time and budget and schedule you have — to operationalize that rockstardom so everyone can see it. The constraints might mean you have to be a rock star on a smaller stage than you dream of (or can handle). That’s how it goes (for now). Doesn’t mean I have any intention of sitting in the audience, meekly sipping my drink.

We are all library rock stars

So, how about you? How do you work around constraints to be a rock star?

an asymptotic approach to truth

Spent the weekend visiting the in-laws in Princeton, hence visiting my librarian crew down there; Monday lunch with Janie Hermann followed by Deep Thoughts with Peter Bromberg. Lovely! (As always: how lucky am I to have found this profession where people are so generous with their time, thoughts, and expertise?) And at one point Peter said, “Blog that!”, and so:

I spent much of library school in cultural whiplash between the library world, where I was being steadily acculturated, and the computer-geek world where my husband and so many of my friends work, and where, to an extent, my undergraduate background lies. And this is coming up again now that I’ve decided I really need to understand something about how ALA works.

Cthulhu Warning

Of course, the more I look into the committees and subcommittees and processes the more I get the sense that it is a Lovecraftian horror and if I ever understand it in full I will have lost my mind.

I have difficulty with bureaucracy. I see that ALA has a lot of it, and I don’t understand why — don’t know the historical antecedents that led to so many rules accumulated upon rules. (Please: do tell.) I sense there’s a story there, but I don’t know it, and even if I did I’d chafe against it.

I see, time and time again in the library world, the brittleness of perfection. If only we had the perfect rules — and then if we could implement them perfectly — and then everything would be great! And if something isn’t working, we need more perfect rules — we need thirteen years of committee process to write the perfect rules — and the cost of those years of inaction, the possibility that acting all along (however imperfectly) might bring more net benefit than waiting for the one true way, is politely not discussed.

And then I whiplash myself over to the computer science world and I see a merry agreement that things will be broken — that we will ship broken code, and we’ll know it’s broken, and we might not even know how, but that’s OK, because next month we’ll have banged out a new development cycle and shipped something else that — will be broken too, but will be better.

What the Real and Imaginary Parts of the Poles Do

It’s an asymptotic approach to the truth.

I was discussing this with my software-engineer husband after lunch and he said that, even in the wild-west world of software engineering, it was a tough paradigm shift, to go from implicitly to explicitly embracing this iterative mindset. But, we agreed, you have to have an iterative mindset if — following Lisa Carlucci Thomas‘s justly-retweeted Battledecks aphorism — failure is to be success in disguise.

If you aim do something once — perfectly — you either succeed or you fail, and failure isn’t an option, so we shy away from it — we shy away from even talking about it. I trace much of my networking success to having attended Andy Woodworth‘s Set Sail for Fail event at Midwinter, and I attended because that title was so striking — partly because it rhymed, but mostly because there was nothing else like it on the agenda.

Iteration liberates. Iteration frees us to walk toward the fail, to sit with it a while, to talk about it, and to take the time to understand how it’s success in disguise. Iteration means we have permission to fail because failures aren’t permanent, and because failures can be seen as mere perturbations of the system which tell us something more about how it’s shaped. Iteration means we always have the grace to fix things.

It means, as the world changes, we can change too, and our solution, so perfectly adapted for its little niche, need not die and fall apart when that niche changes.

I’m not going to be saying here that I wish everyone in the world would manage like a software engineer. (You engineers out there, I see you shuddering.) There’s a lot of deeply pathological issues in engineering management, and there’s a rough-and-tumble, high-energy aspect to the culture that is probably well-suited only to, well, software engineers. (And there are reasons we don’t generally let them near the customers.)

But I am saying that the perfect can be the enemy of a lot of things besides the good: things like learning, and adapting, and having the courage to look our mistakes in the eye. And I am saying that there’s a dovetail between the iterative mindset and something else Peter and I talked about — empowerment. You can’t empower your employees throughout the org chart unless you can be comfortable with everyone’s occasional failure, and you can’t do that unless you have a process wherein failure isn’t permanent, wherein there are second chances and we can boldly set sail for that fail because, when we get there, it won’t be a destination, but a conversation.

There’s some parallels crying out to be written here about Google Books metadata, and my experience as a teacher (and still-evolving understanding of what the culture of schools means), but this post is already long, and I’m eager to hear your thoughts on empowerment, iteration, cultures, fail.