Skip to content

How to Get a Job in IT without Knowing How to Write a Line of Code

December 13, 2011

A few weeks ago, I was invited to join a panel discussion on alternative careers for librarians hosted by SLA’s Boston chapter.  I was very excited to be able to participate in this — my boss and I both come from LIS backgrounds, and have had some animated conversations over the course of the past couple of years about how frustratingly under-informed many LIS students and professionals are when it comes to career opportunities outside of traditional library settings.  I was even more excited to see several dozen interested folks show up for this session — clearly, there’s a lot of demand for this sort of information, and I’m very happy that SLA Boston made this program available.

Like most people, I didn’t grow up aspiring to be a taxonomist.  Even when I began library school, I couldn’t have told you that the career path I would end up following even existed.  Neither could the faculty who were teaching me.  And indeed, enterprise taxonomy is a novelty — it has historically deep roots, but the relative ubiquity of available positions is a product of only the past decade or so.  I became a taxonomist because I was a grad student in desperate need of a job and was a little startled to discover that I had a skill set that would allow me to do something so … well, technical.  Ironically, since receiving my M.L.S., I haven’t worked in a library setting again.  And I don’t regret that one bit — my job rocks.

I prepared a handout for the audience listing some resources for learning about career opportunities in IT settings, and also shared some tips in my remarks for thriving in the field once you’re here:

Don’t count yourself out for job opportunities that appear above or beyond you.  However unlikely it may seem on the surface, you may be able to see a fit between a job and your skill set and experience which a recruiter or hiring manager may not have considered.  If you do see one, take a few minutes and apply for the job.

Don’t be afraid to step outside your comfort zone.  Lots of people don’t necessarily enter IT with deep technical or business expertise.  The expectation is that there’s a willingness to pick up new knowledge and skills on the fly as needed to support business priorities.  Be willing to learn a little bit of a lot of things, because odds are you will end up doing some of them (writing requirements or documentation, designing screens, performing tests, conducting research, managing projects), even if they’re not in the job description.

Be honest about your limitations.  Sometimes, talking to web developers or database administrators can feel like relying on Berlitz while traveling in a foreign country.  If you’re up front about the fact that you’re bluffing your way through, people will most often be happy to help you learn more.

Appreciate what you have to offer.  Most customer-consumable enterprise data is managed by people who have not been trained to do it and for whom it is only one (small) priority among many.  Having a dedicated, specially trained resource to do it allows for improved internal communication as well as improved customer experience.  Those are big impacts to a company’s bottom line.

Toot your own horn.  Self-promotion is an option for career librarians, but in industry it’s a way of life.  The hardest work I did in IT consulting was not meeting client needs, but convincing project managers within my own organization to option me for more work.  Many people will be happy to avail themselves of your services (rather than doing a half-assed job themselves) once they understand what it is you do.  To make them understand, don’t spend time explaining what taxonomy is or how to do it — tell them what kinds of business problems your expertise helps you solve.

Quantify, quantify, quantify. In a related vein, you will get a lot of requests for business justification or “ROI” ( = return on investment) from the work you do.  This is not simply to harass you (though sometimes it may seem that way) — management needs straightforward, quantitative evidence in front of them to determine business value.   Has your taxonomy facilitated information discovery or streamlined publishing workflows?  How many minutes or hours of others’ time are your efforts saving? There are a number of resources out there which will help you calculate this.

Does Product-Based Navigation Degrade Customer Experience?

December 6, 2011

It’s a truism of designing for web experiences: your site navigation should not replicate your company’s org structure.  But what about having your navigation reflect your product line?

I’ve been pondering this since Christian Buckley touched on it during a presentation at Taxonomy Boot Camp last month.  He offered the example of Apple’s online store.  If you knew nothing about Apple’s product line, how would you navigate this experience?  If all you knew was that you wanted an MP3 player, where would you even start to look?

Of course, Apple trades heavily on the ubiquity and the global cultural impact of their devices; their product names have become metonyms for whole classes of devices, as well as an intrinsic part of popular discourse.  Apple also benefits from having a relatively small product line.  Not all of us can count on those factors, however.  I work for a large IT company which has several dozen distinct product lines; the taxonomy management work I do principally supports a product-centric web support experience.

Arguably, a support experience organized by product is a plus for customers.  But in the consumer space, many times support engineers are confronted with the fact that customers do not know the name of the product they are requesting support for.  (An Adobe support manager memorably related to me her customers’ most common complaint: “I need some help with my Adobe.”)

As noted here, product- (or topic-) based navigation assumes a greater level of user expertise.  Most of my employer’s products are sold to IT professionals working in industry, not consumers, so it’s tempting to believe that our customers are more savvy about our products.  But in fact, they often aren’t.  And why should they be, when between numerous acquisitions and strategic rebrandings, we can hardly keep up with the product list ourselves?

A task-based navigation provides a lower barrier to entry for less expert users, which may include internal users as well as customers.  It’s frequently used in combination with a topic-based navigation, in order to provide different affordances to meet different user needs.  This is a strategy which Microsoft deploys across both developer and consumer experiences.

In my experience, it’s far less common to be tasked with managing task-oriented metadata versus product metadata.  I imagine that’s largely a factor of navigation nodes being embedded in page code rather than associated to content elsewhere.  But as more sites move toward a service model for delivering web (and notably mobile) content, managing tasks will fall within the taxonomist’s purview as well.

The challenge, then, becomes defining tasks — or rather, understanding how users define them.  How to go about that is a topic for another post.

So what do taxonomists do all day?

November 21, 2011

 

Here’s one answer to that question: a slide deck I put together for an employee brown bag this past summer, replete with lunchtime-appropriate references.  People respond well to food metaphors.  Also, if you can explain how what you’re doing benefits them (rather than just explaining what it is), they’re often more inclined to lend you a a hand or solicit your advice.

Taxonomy: what’s pragmatism got to do with it?

November 21, 2011

When I was quite small, my mother would wash and save empty margarine tubs for me to play with.  (Why we ate so much margarine, I have no idea.  It was a different time.)  She noticed that I made a point of sorting them by size and color, without prompting.

A few years later, I started collecting tiny soaps from motels on our drives from Colorado to New York for family visits.  I carefully labeled every bar of soap with a number, which was keyed to a handwritten spreadsheet that I kept in my motel soap lockbox, detailing the provenance of each.

We all know by now that metadata geeks skirt a fine line between systematic thinking and mental illness.  Whatever our weirdness, the world is often better for our attempts to order it.  Sometimes, though, our love for order leads us to impose it purely for order’s sake, the benefit of which is less clear.

Few of us who work as professional taxonomists are granted the luxury to simply arrange the world to our liking.  We have a lot of other people to answer to: business stakeholders, content publishers, web designers and developers, and of course our end users.  If what we design doesn’t work for our audience, it doesn’t really matter what platform it’s built on, what standard we use, or how pretty it looks.

Every day at work I am confronted with the dilemma of “doing the right thing” versus “doing what works”.  Much of my job is about striking a balance between those two.  Sometimes I’m pleased with the outcome; sometimes less so.  Such is the life of a pragmatic taxonomist.

This blog is a place where I can share tools and strategies that have helped me make pragmatic decisions (driven by professional best practices, the exigencies of application platforms, and user need) that I can feel good about, and that my consumers can feel good about, too.  Happy reading!