February 16, 2021

[Translation Layer] Volume 1, Issue #2

Translation Layer #2 - Liminal

WELCOME BACK to Translation Layer.

It's been a few months: low-frequency, as advertised. If you're a returning reader, accept again my sincere gratitude for being a founding subscriber. If this is your first read, please check out Issue #1. Translation Layer endeavors to provide good advice, access to opportunities, investors, and connections while providing a modicum of thought-provocation in the form of translation.

Writing a second issue is a fraction of the challenge, as it's been described to me, of a novelist writing their second novel, or a band producing their second album. I think the reason it's challenging, aside from various apocryphal slumps, is because the second time around is by definition a liminal space. Or if you're not into the whole $5 word thing, it's about transition.

Transition and translation have a lot in common, especially when viewed through an anthropological lens. Liminal spaces emerge in the middle of a rite of passage, when the participant is no longer a child, but have not yet become an adult. Whether an Amrit Sanchar, Quinceañera, or Bar Mitzvah there's a period of time when the participant dwells at a threshold between two states. This is the same place a translator dwells, but on a cyclical basis, traveling back and forth.

And as we enter a new era here in the U.S., we're certainly all of us in a liminal place: pandemic and vaccine, the last president and the new one, but mainly, and painfully: 'us' and 'them' in several dimensions made shocking and physical. Amplified by the technology we've developed and invested ourselves within, the words we use to describe and construct experience have drifted apart. And in the absence of a common language—about what were once empirically-derived observations, or the underlying mechanics of what is—it's difficult to achieve some idea of what should or could come next.

A good time for translation; an opportunity for us to define how we come out the other side of this societal rite of passage.

I'll keep this issue to translations far more mundane, but I hope we'll all be participating in some much-needed translation this year.

But first, help requests.

Help Requests

• If you have any experience with building or operating a job board site, using job board software, or are a regular user of niche job boards, particularly as a recruiter or employer, there are Translation Layer readers hoping to hear from you.

• If you are aware of a freelancer or consulting firm with experience building sites on the Hubspot platform, or has experience with content and CRM integrations, please reach out.

• If you are a science-driven organization, e.g. biotech company, university, non-profit, or science lab, I've been made aware of a fantastic resource for your design, art and marketing needs with which I'd love to make a connection.

• I am mentoring a start-up in the Diversity, Equity & Inclusion space. If you're in an organization seeking to improve your DEI—and at this point, why wouldn't you be—please let me make an introduction.

Job Seekers

• There is a VP-level product leader, whose experience in customer acquisition I can vouch for, looking for an interesting product challenge. This person has experience in international product team management, mobile products, UX/VoC, and product operations. Happy to make an introduction.

• I'm in touch with a philosophically-minded Director of Software Engineering open to conversations with a remote-first company.

• An attorney at a globally-renowned legal firm is always looking for those with specific expertise willing to consult on lawsuits or serve as expert witnesses.

• A very senior, very experienced Chief Financial Officer has reached out in search of full-time opportunities in media, technology or related fields. This person has a tremendous amount of experience in private equity-backed organizations, and with mergers and acquisitions.

Featured Translation: Everything Ops

These days, while every business is in some sense a digital marketing business, I have been out of the digital marketing business for a bit over two years now. And while I learned many things along the way, the detritus of involvement in any domain today is of course: digital. And my digital marketing digital detritus is itself, of course: digital marketing. The most pernicious form, of course, is digital meta-marketing, in which digital marketers market to themselves the benefits of digital marketing. Nietzsche said famously "...if you gaze for long into an abyss, the abyss gazes also into you."

This is not unique to digital marketing. Any epistemic community, by definition, eats its own dog food. These days, social media and e-mail newsletters (sorry) serve as a forcing function. When you're in the world itself, consuming this material is a necessary thing; a 'sometimes' evil. But you have to read it; it's an informally-enforced tax. When you're out of the world long enough, reading meta-marketing with a bit of distance provides critical perspective that's often enlightening.

The arc of my own personal digital marketing story was the emergence of what today we call uncritically MarTech—marketing technology. And the undisputed subject matter expert (and meta-marketer) is a guy called Chief Martec (real name: Scott Brinker). Nice enough fella. But even when I was in the world of digital marketing, I'd grimace when reading it. The grimaces weren't about the writing—which was informative. It came from distress that the martech platform my team was building had not achieved product-market fit, or worse, that it had—but nobody really noticed.

So it was with a mixture of distance and fascination that I read a piece of digital meta-marketing from Chief Martec that spoke at length—and with triumphal hagiographic spirit—about a concept described as "Big Ops." Bear with me; a great deal of history which might benefit from translation is tied up in that phrase.

Big Ops to Everything Ops

As described by Chief Martec, customer experience these days is "a function of an enormous number of apps, automations, bots, decision models, dynamic processes, workflows, skills, people and more — a myriad of human and software 'actors' — that must all work in concert together." And just like Big Data, the meta-marketing meme which celebrated into existence the expansion of data flowing in and out of organizations:

[Big Ops] describes a similar scaling of the volume, velocity, and variety of automated or software-mediated processes rippling across marketing operations, sales operations, service operations, and overarching revenue operations.

(For those of you unfamiliar with these mechanics, what he's describing here the machinery underpinning the automated advertising and marketing that tracks and follows you across the internet, presenting you with automated, sequenced attempts to deliver personalized offers and calls-to-action.)

Many exciting three-dimensional Venn diagrams ensue, including this one, which approaches a Grand Unified Theory of Marketing Technology:

For technical readers, some of these may be familiar terms. But People Ops? Legal Ops? Growth Ops? Where did all of this "Ops" come from, and why is it considered something so patently good, warranted and necessary? So much so, that adding on 'Ops' as a suffix to anything magically makes it relevant and important and better? Aside from employing the compound noun form to make things seem impressive for marketing purposes, I think there's something far more subtle and important at play.

The Genealogy of Ops

Adding an "Ops" to something connotes a level of discipline, planning and execution. 'Ops' is short for operations, which comes from the discipline of Operations Management, whose history dates back to the birth of agriculture. It has as its object the driving of efficiency from business operations—the extraction of value from its assets through systemic transformation of inputs (labor, ideas, raw materials) into goods and services. Perhaps its first and most influential thinker was Frederick Winslow Taylor, whose concept of 'scientific management' originated the systematic practice of performance measurement in business.

As the Industrial Revolution evolved towards mass production, Operations Management spawned a wide range of new approaches to manufacturing, starting with noted racist and anti-Semite Henry Ford. In the period following the Second World War. Taiichi Ohno's Toyota Production System (no, [not that TPS] (https://www.youtube.com/watch?v=Fy3rjQGc6lA)) and the ideas of W. Edwards Deming and Total Quality Management drive the post-war manufacturing boom. The practices of planning, observation and closely-measured execution evolve throughout the Cold War period into disciplines including Enterprise Resource Planning, "three-ring-binder" retail and food service systems, logistics platforms created by FedEx and UPS (later perfected by Amazon), and Six Sigma, created at Motorola (supported by Organizational Development folks like my father) and widely popularized by General Electric. But of all of its post-war intellectual grandchildren, it's Lean Manufacturing that connects the DNA of Operations Management's with all the Compound Ops which Chief Martec celebrates as "Big Ops" today.

From Lean to Agile to DevOps

Here's how it happens.

By the mid-1990s, things come to a head in a dynamic that has as much to do with corporate bureaucracy as with the Nerd Social Hierarchy. For many years, the systems administrators (sysadmins, back in the day) who managed large-scale computing systems, those who created accounts, allocated storage (to keep files), memory (to process information), accounts (to obtain access) sat at the top of this hierarchy (or bottom, depending on your perspective), especially in the more serious academic and corporate computing environments. In that ecosystem, which shaped much of what followed, the availability of sysadmins—when required—was a critical constraint on the development and running of applications. Application developers—today's 'software engineers'—were for a significant portion of the previous century entirely dependent upon system administrators. Simply put, if your sysadmin was not available to help out in case of an issue, the software was stopped cold.

The desktop computing revolution, the rise of workgroup computing and the democratization of software development all produce more and more applications—and more application developers—that system administrators need to manage. (Meaningfully, though all too often forgotten as emerging from the Microsoft Visual Basic ecosystem as much as the proliferation of lower-learning-curve scripting languages).

And the growth in enterprise computing produces gads of professional 'managers' who attempt to enforce older, bureaucratic, manufacturing-style processes on both sets of nerds. By the mid-1990s, I can tell you from personal experience, the sysadmins are feeling overwhelmed by duties spanning multiple flavors of Windows, Macintosh and Unix operating systems. They are managing both 'bare metal' servers (large, individual computers in a server closet or data room), and 'virtual servers' (even larger computers emulating multiple individual computers) in support all of the new application developers. And the developers are equally pretty sick of the dependency too, because their rapidly-expanding capabilities for creative expression in code are only exceeded by a tidal wave of pent-up automation demand in rapidly-computerizing industries.

Around the same time, back in the land of Operations Management, the triumph of Japanese manufacturing systems over sclerotic and aging American ones in the 1980s, particularly in the automotive industry, generates some fairly serious self-reflection. Womack, Jones and Roos' 1990 book The Machine that Changed the World translates (booyah!) and codifies Lean Manufacturing principles, which essentially boil down to: create more value for customers with fewer resources by looking at the system of production holistically. Lean organizations focus on the flow of assets (raw materials, equipment, people) in what becomes popularized as the "value stream," the set of actions which collectively embue those assets with value for the customer. The idea of Lean percolates for about a decade, but ironically mostly limited to product development circles, in the very last decade where the majority of products had not yet been eaten by software.

As the Dotcom Era ends, the Agile Manifesto is written in 2001 by a series of competent but disaffected software engineers including Kent Beck, Martin Fowler, and Ward Cunningham. Frustrated by being saddled with project failures outside their ability to control, these folks reject the inane "make-work and arcane policies" established by the professional management class confounding our nerd heroes (themselves). And yet their critique of "pushing process for process’ sake" versus doing what's best for the customer comes from precisely the same intellectual place as the Lean admonition to "create more value for customers."

The intellectual transmission vector here centers around husband-and-wife team Mary and Tom Poppendieck, who go so far as to translate (!) a section of revered Japanese industrial engineer and Toyota Production System grandmaster Shigeo Shingo’s A Study of the Toyota Production System. In their 2003 book Lean Software Development, the “Seven Wastes of Lean Manufacturing" become the "The Seven Wastes of Software Development." Armed with the Wayback machine, you can see these ideas taking root in articles on popular developer portals of the time.

Equipped with the pragmatic sensibilities of the Poppendiecks and their contemporaries, it is the nerds of the early 2000s who turn to the holistic principles of Lean Manufacturing to save themselves from what all nerds hate the most: someone else hassling them. The excitement, exhaustion, and cognitive dissonance that defines that period between 1996 and roughly 2011—when nobody really knew how exactly to handle all the massively expanding code and infrastructure while corporate or the investors were always yelling for more—it was a cornucopia of hassle.

While it's true that most of the initial benefit—and eventual meta-marketing—of Agile methods accrues to software engineers, the ideas quickly take seed with the sysadmins. Less inclined and susceptible to meta-marketing, they generate their own grassroots translation of Lean Manufacturing principles into what we call today DevOps. Emerging from dissatisfaction with heavyweight IT vendor-focused frameworks like ITIL, people like Jesse Robbins, Jez Humble, Patrick Debois and Jon Allspaw assert that the way we manage software should consider the holistic value stream from application development to its deployment on systems. The seeds of DevOps owe as much to the accelerating venture-backed pressure to build unicorns as they do to Taiichi Ohno's admonition to observe the timeline "from the moment the customer gives us an order to the point when we collect the cash."

So now, in a genealogy of ideas spanning Taylor, Toyota, and a plethora of hassled technical people, we have arrived at our first 'Compound Ops,' DevOps.

So how do we get from DevOps to Everything Ops?

Cognitive Politics

The answer lies in cognitive political dynamics. I came across a fascinating bit of research from a pair of ergonomics researchers at Ohio State University focused on exploring the "reverberations of technology change" (love that phrase) titled "How Unexpected Events Produce An Escalation Of Cognitive And Coordinative Demands." Drawing upon late 1990s human factors and safety research, they observe that while each round of new technology purports to help people engaged in a particular field of endeavors, the results are different from expectations, with the most common outcome being clumsiness: "technological possibilities are used clumsily so that systems intended to serve the user turn out to add new burdens which congregate at the busiest times or during the most critical phases of the task."

The money quote:

There is a striking contrast between the persistence of optimism of developers before the fact who expect each technological development to produce significant performance improvements and new operational complexities that are observed after the fact...Ultimately, we need to explain why this technology-induced complexity occurs so often when designers fully expect that these systems will produce major benefits for the practitioners.

If you've ever asked yourself Naked Emperor questions like "Is it me, or does this software actually help me do the thing it's supposed to be helping me with?" you are not alone. (And but also my own personal favorite: "Does the extra complexity that this software requires me to deal with actually mean that it's faster doing it by hand?")

My attempt to explain this—and in so doing explain the proliferation of Everything Ops—is that many, many new technologies are created not so much with the intent to produce performance improvements as they are to remove their creators from the pointy-end of Someone Else's Hassle. This was alluded to in Translation Layer Issue #1 as the virtuous laziness) of the programmer. Yet it has ramifications, many of which are experienced as externalities by the civilians on the receiving end of programmers' largesse.

Let's take a look at a few of these Compound Ops to tease this out a bit further.

• Sales Ops. Emerges from the development of data analysis software (including the venerable spreadsheet) as far back as the 1970s but surging in the 1980s, and its attendant forecasting, compensation and geographic analysis; or as this 2014 Harvard Business Review article describes it, to take on “all the nasty number things that you don’t want to do, but need to do to make a great sales force.” (emphasis mine)
• Marketing Ops. Emerges from the rise of marketing automation software in the 1990s and the mid-2000s push to coordinate siloed marketing activity with a discipline that "builds a foundation for excellence by reinforcing marketing strategy with metrics, infrastructure, business processes, best practices, budgeting and reporting."
• Ad Ops. Emerges from the development of automated bidding systems in the late-2000s to optimize performance in microsecond-scale online auctions for digital display advertising inventory; ends up requiring a team of 'ops' people responsible for managing the "workflow processes and software systems that are used to sell, input, serve, target and report on the performance of online ads." ()
• DesignOps. Emerges in response to automated software deployment technology in the 2010s enabling continuous delivery of new user experience features in production environments; produces teams who employ "the practice of reducing operational inefficiencies in the design workflow through process and technological advancements."
• ResearchOps. Emerges in response to the proliferation of low-cost remote user experience testing software, enabling usability research at extraordinary speed and sample size, "requiring orchestration and optimization of people, processes, and craft in order to amplify the value and impact of research at scale."
• Privacy Ops. Smack dab in the the steepest part of the hype curve right now, emerges from the widespread proliferation of behavioral tracking technologies and aggregated databases of consumer identity; produces, as described by PrivacyOps.com (maintained in a classic bit of meta-marketing by privacy management software provider securiti.ai), as "the combination of philosophies, practices, cross-functional collaboration, automation, and orchestration that increases an organization’s ability to comply with a myriad of global privacy regulations reliably and with greater speed."

Notice how often the terms process and workflow appear in those descriptions? That's scientific management, for sure. However, unlike Taylor's or Ohno's observations on the factory floor, the software produces the workflow, not vice versa.

When It Changed

From the perspective of the nerds on the scene at the birth of the commercial internet and digital businesses, DevOps is the progenitor of Everything Ops. But I think the triumph of DevOps, aside from culminating the journey of Lean principles, represents even deeper changes. DevOps is when the polarity shifted, in a meaningful way, from the business making the nerds do "the nasty number things," to when the nerds started making the business do the boring stuff under the guise of job security and self-service. All the Ops, in some sense, come from externalization of tasks that technical people built software to avoid doing themselves. Interpreted this way, economic history of the last twenty years has been one of nerds pushing the things they'd prefer not to do off on other people while simultaneously making those other people feel either empowered or important or both. We nerds refer to this practice as creating 'self-service tools,' an idea now being meta-marketed as low-code or no-code.

Yet the underlying truth of all software—so far—is that nerds cannot cover all the potential use cases to which their code is employed. Self-service inevitably creates edge cases—places where the normal rules do not apply. Unanticipated situations emerge, especially where the mental models of software people and non-software people do not overlap. And what happens when you, as an end-user of software, are stopped cold trying to accomplish something? You have to wade into Google, Reddit and Stack Exchange, places where the posts are written in two flavors, Disdainful High Nerdish (often in Aspiring Pretend Nerd sub-dialect) or Anguished Newbie. No fun.

What's happening here is the operation of a phenomenon observed by Frank Herbert: aristocracies emerge out of patterns of governance. And software, as Mr. Andreesen continues to remind us, is most definitely a form of governance, if not outright government. Alpha nerds, the pioneers who build the original tools from scratch, create them because (a) building them is an interesting and lucrative problem to solve; and (b) because it means they are not the ones who are going to have to do the boring and mundane labor that the absence of those tools requires them to continue doing. And over time, what transpires is that things which were once edge cases mature into base cases and those cases become new tools for the alpha nerds to build. The externalities produced include: extra complexity requiring Everything Ops, armies of gig-economy workers, and new set of aristocratic forms.

And there's something even more basic here which warrants addressing.

Generational Change

The first set of non-technical people to use comprehensive and fully-woven-into-the-fabric-of-the-work software lived in perpetual anxiety about the actual continuity of their information. There were, to put it mildly, some existential bugs in many, many operating systems and applications up through the first decade of this century. Regular civilians who framed consumer ideas of what software should be grew up in a time when backing up, repetitively jamming Ctrl-S or Command-S or putting it on a second floppy, Zip, external or thumb drive was imperative, lest days, months, or years of labor be lost. This was simply part of the daily mental calculus. The nerds were in the same position, but they bought the tickets and knew what they were getting into, for the most part.

So now, with the (apparent) continuity provided by cloud computing and (generally) more stable operating systems and application software, digital life has become vastly more transitory and ephemeral. The daily existential threat of the loss of information is gone. Instead of anxiety about losing information, there's too much of it, both available on hand, and requiring processing.

So what do humans generally do when presented with an unbounded flow of information, and lack the biological tools to process it? They build systems. And the marketing language of Everything Ops is just the latest expression of this urge.

There's no magic to Everything Ops. It's not a bad idea, despite the meta-marketing it's used to effect. It's the natural result of a larger iteration in how we process the technologies we've built. Eventually, those 'Ops' structures and practices will reach the same level of pedestrian, thoughtless adoption that writing words on a screen, rather than paper, have achieved. And we'll be on to the next thing.

Something to consider.

Translation ends.

Two Tools

More tools so you have the right one for the job; work and play.

Work: Seven Learning Styles

The ultimate basis for success, in my humble opinion, for any work team is its capacity to learn. Yet it's easy to forget that people don't all learn the same way. This is a critical, but all too common, miss for team leaders of all sorts. So check out the Overview of Learning Styles to understand the difference between visual, aural, verbal, physical, logical, social and solitary learners.

If you've been on a team where one person struggles with the absence of discernible patterns, where another can picture the end result and a third cannot move past a steady stream of verbiage to flesh out an idea, you're dealing with different learning styles. (In this example, logical, visual, and verbal). And people may shift from style to style depending on the subject and context.

The first time I became familiar with these concepts, I was too busy finger-painting with my small children to really grok what their teachers were describing in fullness. All credit is due to Friend of Translation Layer (FoTL) and reader KB for surfacing and embedding them permanently in my brain. Take the online inventory if, like me, you're not quite sure what your learning style is.

Play: Astronaut.io

Astronaut is eerily reminiscent of the early days of the Web, when the first webcams were set up to view coffee machines and fog and fish tanks. It's a window into the tiniest moments of life across the planet, as unedited zero- or near-zero-view videos uploaded into YouTube over the previous week. Kind of like a nano-Baraka or Samsara if you have had the viewing pleasure.

Parting Gifts

I'm a novel and short story person. Going outside my personal comfort zone a bit to offer some poetry as this issue's parting gift. It's the sophomore release of this newsletter, so I might as well experiment to avoid a slump. Experimentation seems to be the recipe for avoiding it.

Hồ Xuân Hương (1772–1822) was a Vietnamese poet who, like us, lived through an extended period of social, political and economic turmoil, and is considered to be one of Vietnam's greatest classical poets.

As we endure what may be a very long winter in North America, I'm trying to keep my eyes on the prize: Spring. And so I stumbled across one of her poems, which just kind of hit me. As always, your mileage may vary. It's entitled Spring Watching Pavillion:

Gently Spring evening comes to the pavilion, Unclouded in the least by worldly sins. Three times the temple's bell surges like a wave Unsettling the puddle where sky and water mingle. Truly the sea of Love cannot be emptied And the stream of Grace flows easily everywhere. Now, where, where is Nirvana? Nirvana's here, nine parts in ten.

Bonus Transitional Spring Content from the Depths of Winter: Check out Chicago's own vocal treasure lost too young, Minnie Ripperton, and her song Les Fleurs to keep your ears on the prize.

Final Thought

““Translation is a disturbing craft because there is precious little certainty about what we are doing, which makes it so difficult in this age of fervent belief and ideology, this age or greed and screed.”

― Gregory Rabassa,"No Two Snowflakes Are Alike"

Administrivia

If you found Translation Layer useful, please feel free to forward to others. If you did not, please let me know how it could be improved. I'd like to hear from you either way.

Until next time.

Yours in translation,

j.