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.