What I Learned From My First Content Conference

I went to Confab Central last week and had a blast. After years of going to tech and news conferences, it was my first ever content conference, so I thought I’d make a list of what I learned.

All the Content Ladies

I don’t know what the official numbers are, but women were definitely the majority at the conference. The lines for the women’s bathrooms were literally out the door, and my small group dinner on Wednesday was 1 guy and 7 women.

To be honest, this was kind of a nice change from code conferences.

Plentiful Food Helps

This was the first conference I’ve ever been to where there’s been enough coffee. And we were served two square meals a day, plus really generous snacks. And cake. And cinnamon rolls. No one was every going to be hangry at this conference, and I can’t help but think this helps with networking.

And I loved the small group dinner arrangements.  Confab sent out invitations via Eventbrite; they’d made reservations at some local great restaurants, and you could buy a ticket, which was just a place at the table for one of the groups.  The idea being that to get to know people in such a large group was hard and this was a nice way to get a little deeper than small talk between panels. I got to go to a stellar restaurant and meet 7 new, interesting people in a really non-awkward way.

CS Means Two Things

At this conference, “CS” meant content strategy. I was used to it meaning Computer Science. It was pretty easy to keep things straight, though sometimes it messed me up a little.

IGNITE Lightning Talks Are Tough

On Thursday, I gave a lightning talk about how technical debt was caused by the same root problems as content bloat. (I’ll write a separate post on that later.) I’m a confident speaker and I’d given lightening talks before, but the IGNITE format — 20 slides that autoadvance every 15 minutes — was unlike anything I’d ever done before. You need to rely less on the effect of that perfectly timed GIF, and more on a general sense of the flow of your points. And you had better get those points down to their bare essentials!

I did make friends with the other people waiting nervously in the lineup, though, so that was cool.

You Can Refactor Content as Well as Code

This wasn’t exactly surprising, but it made me happy to hear presenters talk about content in terms of Agile methods and refactoring, both terms that draw from engineering. And my talk was trying to talk about content strategy via code. These moments of cross-discipline translation are were exactly what I wanted to see and talk about, and I got to experience so many of them!

I Wish There Were More Communication Talks At Developer Conferences

To be clear: there are talks on communication at code conferences. But at ConFab, it was much more a sense of actionable, step-wise instructions for getting stakeholder buy-in, dealing with difficult situations, and making sure that your suggestions for change got listened to. The reason I think tech conferences could use more of this is because a CS-degree-having Linux wizard told me, regretfully, that this type of stuff was never covered in CS (or STEM) curricula. But yet, as we all know, it’s almost never the code that’s standing in the way of achieving something. And the more we move towards integrated tech and cross-functional teams, the less developers will be able to avoid being present — not merely as experts on high — but as full collaborators in a project. And I think some of the talks would give them some great tools to approach the non-coding side of things.

What’s In a (Strategic) Name?

Why A Name Matters

My team just changed our name from the Platform Team to the Engineering Team. We did this after our new editor-in-chief asked us to reflect on what we wanted to be called, and on how our tech team was different from the other tech team, and on what it was that we actually did here, anyway.

I jest. It was a welcome chance to reflect, for many reasons. In the four years I’ve been here, we were at first “the tech team”, which did little to foster collaboration. Then we were the Platform Team, a name change that came with the decision to have a separate news apps team instead of just a bucket of programmers; the titular platform was our CMS/website…and then our other site’s CMS/website…and then a few instances we had running of other things that we used to run the sites…and Salesforce…and Eventbrite.

To reflect the systemic nature of what we do, this time around we chose Engineering, and changed our individual titles accordingly. I became the Director of Engineering Strategy — the addition of “strategy” was my idea. Amusingly, there’s now a Quartz post talking about why you should never have “strategy” in their job title, viz. because “Strategy people too often have ideas that aren’t rooted in the reality of the operations. And operations people too often aren’t invested in executing the plans that the strategy people craft for them.”

If other people aren’t invested in executing a plan that solely because they haven’t come up with it, we have worse problems than titles. And if the strategy person hasn’t approached things realistically, and gotten buy-in, they’re not doing their jobs well. Which, granted, I have seen on occasion, but it’s often from people who don’t have “strategy” in their title. So again, I think the title isn’t the issue.

More frequently, I’ve seen many department directors (including past me) view their job as representing (or protecting) their departmental interests. When it came to my title, I wanted to somehow represent the big-picture nature of our team’s task, including the fact that we’ve helped change the way our organization makes web things. We’ve move to a much more agile process. We’ve started asking people to bring us user stories instead of feature requests. I included content strategy in my latest job description, because after two years of dealing with our technical debt, I’d concluded that content governance (or lack thereof) was the root cause of many technical decisions that were made.

So I added “strategy”, to try to accurately represent the fact that I (and my team) were active participants in shaping the our content and processes beyond just the technology.

Why A Name Doesn’t Matter

My advanced degree, in Classics, blithely requires you to master two separate languages, Greek and Latin, as well as to have a passing acquaintance with a few more. The idea is that the Roman Empire was built on top of the Greek one, and the two cultures were related by geographical proximity and exchange. Which is fair, and isn’t a bad introduction to the global notion that almost everything has several different words to represent it. In fact, Classics is what brought you the notion of Indo-European, a theoretical language from which most European languages sprung — this is a language, let us remember, that is totally made up, and was never spoken by anyome. It’s sort of a like a grand unifying theory of language, which is also something humanists like to look for.

Fast-forward to now, when I work at a small organization; we don’t have the resources to hire separate people for the subsets of this amorphous trade. And I’m not trying to say that specialization isn’t valuable – it is! Having experts in one area or another is necessary, particularly as you scale. But there’s also a commonality among tech things that aren’t easily boxed in as programming-language based skill categories: these tend to be called content, or product, or UX, or whatever we’re calling it these days.

But I also kind of don’t care what we call it, because our small size has allowed me a chance to observe that what’s important, really, is the mindset: the realization that code — and by extension features — won’t solve your problems. The realization that you need to focus on asking people to define problems instead of solutions, and that you need to, in Katie Zhu’s (product and engineering) words, ship outcomes not features. What unites strategy, in all of these job arenas, is a sense of standing in the middle of sometimes-competing priorities and sorting them all out. Though due to my previous training, I often think of this as an exercise in translation.

That’s my grand unifying theory, anyway. Old habits die hard.

What I’m Good At

The opportunity to change titles also brought a chance to reflect on what I liked doing best, a question that is reflected in two careers. My first career was that of an academic who studied and taught Rome. Asking why Rome became the empire it did is a lot like asking about the cause of the civil war, in that the right answer is, “It’s complicated”. (Great training for the “it depends” answer of a good engineer).

But one of the main things that allowed Rome to extend its empire was acqueducts, those arch-like things that carried water where it was needed. As far as ancient architecture goes, they’re incredibly unsexy. They’re pragmatic, long-term civic infrastructure that needed to be maintained by the ancient equivalent of home repair contractors. As one of my former professors liked to quip, “If really want to know what made Rome great, it was concrete.”

When I was still a classicist, I had the training to see a paradigm shift happening, which is part of why I changed careers. I could see that the wires of the internet (and yes, at its heart, it’s still tubes) were the new acqueducts, and that it was probably a good idea to get acquainted with the bones of our new epoch, STAT.

I applied my classics training then, and I still  apply it now: I’m in the business of building infrastructure, social acqueducts, and other long-term goals.

I’m a big believer in structure, social or otherwise Why? Well, a hundred sociologists could give you rigorous arguments, but the basic tenet is this: the individual will of one person isn’t going to enact justice. A system that is built to be fair will. That’s why organizations need to focus on, for example, systemic solutions to things like sexism and unconscious bias; all of the best intentions of individuals will not do it. And executing that system requires un-sexy maintentance type stuff: carefully designing job descriptions, actively recruiting diverse candidate pools, using rubrics to compare candidates, and making sure to ask them the same questions to have fair comparisons. Things that some might feel quash their individual expression, if they didn’t come up with the idea.

(Incidentally, that’s why we need to stop lionizing individual lone wolves. A point that’s been made by others, and/or a post for another time.)

Speaking of annoying buzzwords,  I’m glad we’ve started to notice that un-sexy maintentance, not sexy “innovation”, is what really matters. Because I like maintenance. It’s part of liking long term plans. And sure, I like building — and helping to build — if we’re talking about things that will last a long time. Short-term viral growth is boring to me, as a historian turned engineer. I like building things — teams, apps, structures — that will last a long time.

On the everchanging architecture of the web, building things to last is a helluva job. Sometimes it feels like astrology as much as making good decisions. But I still like it. Whether you call it strategic or not.





Data Philosophy: A Day in the Life of a Tech Newsroom

“What makes a Muppet, a Muppet?” wondered our designer. He’d made a prototype illustration, but wasn’t happy with it — he didn’t feel it was immediately recognizable as a Muppet.

He’d come to the tech area for input, and we were happy to oblige. We analyzed the hell out of the visual ontology of Muppetdom. We searched for web images of Muppet schematics. We agreed that the mouth should be open, and maybe there needed to be wrinkles around it it. The head seemed more Muppet-like tilted to the side. I thought there needed to be more obvious fuzziness, while my co-worker thought only the eyebrows needed to be fuzzy. We debated the need to soften harsh angles, and whether the nose should be indicated by a hard crease or a soft planar shape.

The next day, a passing editor joked that they’d heard about our philosophical discussions and wanted in. Easily accomplished, as one software engineer had just said out loud: “What makes a person, a person?” Soon, the office was filled with talk of whether a politician was defined by their office, and what said office meant – was it a building that existed around the politician? Did it exist with no politician in it? Was it a place, a personality feature, or a vocation?

The irony is, I spent ten good years avoiding similar discussions – endless philosophical debates on semantics and meaning and OMG do we have to deconstruct everything to nothingness?! One hint of such discussion and I’d find the people at the other end of the bar, probably shipping Buffy. But there’s a crucial difference in the tech room discussions: While everyone involved enjoys the speculation, it’s usually in service of building something real.

(As real as a virtual thing can be. It’s stored in hard circuitry, anyway.)

In the first case, the designer needed to produce a recognizably Muppet-like illustration. In the second, we had a more difficult task at hand, a database issue where we were trying to decide how many categories we needed, and whether we could use the same one for our site’s users and for the politicians in our directory – all real people, you see, but with different sorts of information needing to be stored. Hence the question of what makes a person a person; yes, the bane of philosophy for millennia, but also the bane of a machine trying to define a person as a series of categories ergo the bane of a programmer trying to define what the machine knows.

Anyway, I understand now why Google has been, at times, hot for people to run out and get philosophy PhDs. To them, grad school must seem like a magical wonderland of people who like to do this stuff! All day! Ad infinitum! Alas, Google’s got it wrong. By all means engage in philosophical sport if you like, but do it while getting paid to design databases, or at least make your money building software first. Also, good luck telling your grad advisor about the need for pragmatic end goals — they tend to look down on that, or at least did when I was still there.

A few weeks later, I saw again how practical some of those “useless” humanities skills could be. We were dealing with a bunch of data, inconveniently and messily produced by actual humans. Because the humans refused to use the exact same word for every description, we had to come up with a way to make the data more computer friendly, viz. by categorizing it. There were maybe 225 entries to deal with. Not even close to being Big Data.

Dealing with a small bunch of messy human data is the same as doing history, as far as I’m concerned. And it’s an obvious (and not even monumental) task for a competent grad student in many fields – history, anthropology, library science, sociology, etc. I said as much to the room;  the room laughed. The programmers were already talking about using Mechanical Turk to crowdsource the categories, because in their view anonymous data input is the only reliable way to let humans categorize stuff. Both I and the reigning editor deemed this a no-go. And even the software engineer had to admit that writing a useful parsing script (which of course they’d started to do) was probably as time-consuming as having people do it.

When I mentioned the grad student solution, I suppose it seemed like joke about how desperate PhDs are, or maybe people thought the task was too complicated to leave to the “soft sciences.” It was frustrating to try to communicate that, in actuality, there are non-science people trained in exactly this. People who could help, and who would enjoy the task. And that any parser we’d write would be just as unscientific because of the small data set and the fact that a fallible human was writing it.

The point being that basic skills such as analysis, categorization, and yes, even being skeptical about categories, are not science skills. They’re not even tech skills, particularly. They’re skills you learn from sifting through data, and thinking about categories and the people who make them.  Like a lot of soft skills , they’re not an easy sell — “Hey, I classify stuff real good!” — but if you can spin it to the specific situation, you might get somewhere. And do not, under any circumstances, tell people that what you’re really doing is humanities.

Training People Digitally, For Real

This weekend I’ll be at NICAR, the conference that last year inspired me to ponder what humanists could learn from journalism. That means I don’t have a lot of time to write. But I wanted to share an screenshot from the NICAR schedule that I think is worth a thousand words:

Screen Shot 2014-02-23 at 8.35.48 AM

This is what a genuine commitment to helping people learn tech stuff looks like. I myself will be attending several of the hands-on classes, because there are data skills I have yet to learn. That’s the thing, there’s always more to learn:


To my mind, this is what the digital liberal arts should be doing. Not worrying about the theory, but getting more people involved in the practice. Not navel-gazing about where we’re going, but making sure that humanists are equipped to enter the larger tech conversation. If haven’t bothered to learn some of the above, you’re not going to be taken seriously in a tech conversation. You can debate the fairness of that but the fact is, if you don’t get in the game, other people will be making the decisions about what digital archiving, publication, and communication looks like.

Just my two cents. And seriously, y’all, if a kid can do it, you can too.


Practical Tips for Getting Out of an Academic Job and Into the Real World

Dr. Karen Kelsky (aka The Professor Is In) asked if I had any step-by-step posts on how I got my current job. That’s its own story, which I will tell at some point, but this is a quick overview of how I got where I am, with links to all the practical posts I could find. For practical tips I’d also highly recommend Post Academic, which is archival but very, very good.

How to Get a Non-Academic Job

1) Start acquiring new skills you think you’ll need, preferably before you leave your current job. Actually, you already have a lot of soft skills and managerial/admin skills, and those are very valuable. To quote an acquaintance who left grad school, “They pay me in actual money and food, can you believe it? Turns out that the skills taken for granted in the academic world are actually highly valued in the workforce. Who knew? ”

I’d still vote for having basic digital publishing skills (like these) when trying to get any decent/interesting job these days, and more advanced stuff if you want to be in the tech industry.

2) Network, network, network. If you’re an introvert, it’s no fun, but there are non-schmoozy ways to got about it — hell, Twitter is a great place to “meet” people — so just set some goals and do it.  It’s also necessary to have a lot of contact with new people so you fully understand the differences in communication and work culture (see 3, below), i.e. what academic tics come off as a little weird.

I wouldn’t have gotten the job I have now if I hadn’t actively curated a network and gotten out there. After seeing the job ad, I showed up at an Online News Association meetup where the Tribune tech team was talking about their work. I made to sure to introduce myself to the people in the tech department. When the interview process got to the point of needing references, it was a real moment of victory to realize I had three non-academic references (two former freelance clients, one startup manager) at the ready — and that I had successfully, deliberately built a entirely non-academic network. Freedom achieved!

3) Look around at how non-academic fields operate, because you’ll need to drop your old jargon and learn some new lingo. Attend non-academic conferences in various fields to check out the lay of the land, or read up if you can’t go in person. I like the HBR blogs, for example, especially when they say helpful things like “hire from the humanities“. And whether or not you agree with Mr. Kristof’s latest, you’ll want to drop your academic writing habits and get feedback from a focus group of “normals”. You may be shocked to hear yourself using phrases like content creators and make the ask but I guarantee it’s no worse than casually using words like discourse.

4) Throw out your CV and deliberately construct a strong non-academic résumé (or portfolio, if applicable). Often, this means working for free at first, honing your new skills on passion projects, or working for trade (I’ve done both). It might mean volunteering (which allows you to test the waters of a new field and network). It might mean taking any crazy, last-minute job in your new field that gets thrown your way (or it might not — if you’re freelancing you’ll have to learn how to fire clients). It might mean having a blog, or guest blogging, or possibly doing a blogathon or or making other media of your own. Giving talks for local organizations was one way I expanded my network, and my current employers were impressed that I was doing cultural stuff out in the community. Again, you never know what could lead to jobs.

Or it may be as simple as learning how to reframe your accomplishments so they sound impressive to non-academics. Whatever you do, don’t constrain yourself to an overly traditional format — making things pretty is important in the outside world, as is making them accessible. An attractive WordPress site can get you far, and even simpler than that are services like Vizify  (now defunct) and about.me, which give you nice visual portfolios without you building anything. And I think LinkedIn is better than a resumé, these days, because you can link to it in a “cover email”, which is fast becoming the format of choice.

5) Realize it’s going to be hard. Depending on how financially stable you were before, it can be very hard. If you’re feeling bummed, read interviews like this one or this one or this one or this one to know that it’s totally possible. Possible, but hard, and there will be a lot of rejections, but really, I don’t think that’s much different from the academic job market. Or grad school. I’m a thorough pessimist, but I’d still say that to a certain extent you can make your own luck. With a few exceptions, I think it’s not worth throwing your resume into those auto-fill nightmares — that’s what the networking spares you from. And if there’s one thing you should be able to do, as a trained thinker, it’s to act strategically. And that’s really what it’s about.