No, not - ugh, never mind. (Image from... Pak's Wholesale? What?)
I'll also be dropping my usual high regard for relevant and carefully sourced images.
Sociotechnical Systems: A Quick Look Around
STS goes, like, waaaayyyy back in the literature, to I believe the 40s in English coal mines. When coal workers were given more autonomy and decision-making power, productivity increased along with innovation and morale, while injuries went down. However, management ultimately stripped the workers of their additional responsibilities to keep them compartmentalized, fearing collectivization - cutting off their noses to spite their faces, more or less. Things didn't go so smoothly - productivity etc. went back down and injuries went back up, but management was happy to have reestablished control. Considering business' reaction and subsequent drive against all forms of legislation, I find it likely that this is an insecurity-motivated move to... y'know what, let's skip their motivations, for now.
The term "sociotechnical" was coined to deal with the theoretical framing of unexpected phenomena emerging from the live interplay of social systems and technical systems - in other words, sociotechnical theory is an analytical theory, a way of looking at things, rather than a predictive theory, a way of foreseeing outcomes. In a nutshell, you've got a social system and a technical system, and when they interact, these interactions result in outcomes and experiences, which in turn feed back into each of the aforementioned systems.
An easy concrete is when a software developer makes UI changes based on user feedback: user experiences feed back into the technical system via the developer's changes, the product improves, and as more people buy it, the company continues to grow and change. Note that the method by which users provide experiences is itself another technical system, which can also respond to changes: differences in methodology can affect changes downstream, even the kind of change that happens.
Suppose the developer has a feedback form on their website with several free-response sections, and the software engineers actually read the feedback and organize themselves how to classify and respond to the feedback (small developer with a high degree of autonomy). Now suppose management of a large developer hears about Big Data through their own social system, decides to bring it to their UX, and to that end brings in consultants to design surveys for automated processing and analysis, then hands those decisions down to development. How might these two methodologies differ?
Proponents of Big Data might argue that their approach is more inclusive, more efficient, and more refined - but at the same time, this model is only equipped to deal with the kind of problem that Big Data is capable of identifying and solving. Many potential improvements might be shut down by executive meddling, or even go unseen as a direct consequence of the data collection methodology.
The smaller development house, with its free-response sections and human processing, can't analyze as many responses per hour - but because the engineers decide themselves how to interpret the feedback and what to implement, they are free to use their own expertise in determining which changes are more feasible and more necessary. Both can go off the rails and do dumb things, but by hiving off the decision-making and the feedback selection & processing from implementation, we introduce more failure points because the people who do the things aren't involved in deciding what to do.
The takeaway here isn't that Big Data is "bad" or that handcrafted feedback is "better" - the takeaway is that we should be mindful of the decisions we are making in a sociotechnically-oriented way. Big Data doesn't have to lose the human element, and certainly brings a lot of value to the table for the kinds of things it's good at. But it's not an all-purpose solution, or even always necessary or desirable. It's one tool in what should be a whole toolbox, and while some tools are more expensive or useful or specialized than others, they can all be used for good or for evil - the uses and purposes have moral content, the tools themselves do not.
Community Informatics: Down the Rabbit-Hole
Harris' article raises these issues when he asks questions like, "What's not on the menu?" There's value in that sort of techno-criticism: not just playing Good App, Bad App, but thinking in a critical and systematic way about what functionalities are life-enhancing or life-draining. I think we should take this approach to a broader level, and here's how.
I gave a talk at a prominent tech conference a few years back along with my PI (boss) and site liaison (the aforementioned Faceborg friend) based on some grant work I had done in setting up a community technology center to advance understanding in how to address the digital divide (not linking any of this - crowbar separation between professional life and this blog). By the terms of the grant, we had to teach certain basics of computer use: this is a keyboard, this is a mouse, this is how you download a file from the internet, you get the idea. Computer 101 stuff. Satisfying the terms of the grant was easy sauce, but it wasn't our end goal.
This brings us to the field of "community informatics." CI goes back decades, and the gist of it is "helping people use the resources available to them in order to facilitate lasting improvement in their lives." So many times, grant workers of our stripe will come in, do a workshop or three with some pre & post surveys, and maybe a follow-up down the line to see if anything changed. I had done work like this as a volunteer for such efforts - volunteers who I would now be in a position to recruit, myself - and the sad fact is that lots of folks who feel like they're "not computer people" will come to these sessions eager to learn, and may even report high satisfaction and "feeling empowered" as a result, but nothing changes. Meanwhile, tech moves on, and they're more or less right where they were before. Your workshop may as well never have happened.
During my undergrad years in the ivory trenches of the philosophy department, I wrote a research paper on philosophy of technology in which I cited a study of fisheries... somewhere. Japan, maybe? They had been striped into a few "levels" of technology, and many factors were tracked before and after significant tech overhauls. Those that made the highest jumps up the tech tree reported being most excited about the technology and optimistic about its implementation - and after it was implemented, they saw a corresponding drop in morale, increase in sick days & complaints, and even less job satisfaction than before the technology was even talked about. In other words, they expected the tech to make their lives better, and when it didn't, they were really disappointed.
This has been a recurring theme in the last seventy years or so: back in the 50s and 60s, most computer jobs were engineering jobs, held by experts with college degrees. As these folks prospered in ways inaccessible to those without such jobs (a gulf which we came to call "the digital divide"), people in the nascent field of CI thought computers were the thing that did it - if everyone just had computers, they could also prosper! Technical problem, technical solution.
Then during the 70s and 80s, a bunch of Big Names put a whole pile o' money into making lots of computers, and most computer jobs became white collar jobs, held by professionals with specialized training. Manufacturers had gotten richer, but nothing else changed, because those best positioned to get into the expanding field were those already privileged enough to get that specialized training. CI folks then thought, duh, it wasn't just physical access to the machines, but also the skills to use them that enabled the prosperity - if everyone just had the skills, they could also prosper! Educational problem, educational solution.
So during the 90s and 00s, a bunch of Big Names put a whole pile o' money into making computer education part of school curriculum, and most computer jobs became entry level positions, held by unskilled laborers working for hourly wages with high school skills. Companies that relied on computers had gotten richer, but nothing else changed, because the exploded supply of computer-skilled people drove down the wages they could command. CI folks then thought, duh, it wasn't just the skills to use the machines, but also the ability to innovate that enabled the prosperity - if everyone just knew how to innovate, they could also prosper!
Now it's the 10s, and a bunch of big names have been putting a whole pile o' money into making innovation culture part of school curriculum. Industry-disrupting apps are popping up like weeds, from Über to Patreon, greatly enriching a few folks who then live the American Dream of making an IPO and selling out to one of a shrinking pool of parent companies owning most of the country. Companies that were able to capitalize on this bounty of innovation got richer, but nothing else changed, because taking the cutting edge and spreading it around makes it no longer the cutting edge and so what the Hell do we do about all this? Every time, we cheer on the fancy new shit; every time, the rising tide doesn't lift all ships; and every damn time, the digital divide gets bigger.
What outcomes of this story have been life-enhancing? What outcomes have been life-draining?
Media Literacy and STS - Back Up the Rabbit-Hole
This is where I come back in. My PI, my colleagues, and I all agreed that CI had, up until very recently, been mis-aimed the whole time: what we had been teaching people was not How To Improve Your Life, but rather How To Get Rich Under Capitalism. Our methods were sound, but our our aim was off because we weren't even thinking clearly about what we should be aiming at, or why. A few people who were the very best at what we were teaching would go through the sorting algorithm of our economy and prosper, but most just learned how to be marginally savvier consumers. We weren't doing anything wrong, per se - we just had been thinking about the wrong problem from the word Go.
We had been teaching folks how to assimilate; we needed to teach them how to deviate.
We ran five different community technology centers that year, each at a different site, and each to be run in a different way. My site was a K-5 school with over three quarters of the student population (considerably more than that, but I'm not getting specific) on free or reduced lunch. After collaborating with the faculty, we decided that I'd run a before- and after-school tech program. It was a bit of a pressure-cooker situation: I was also on two other research projects, each of which helped with both the others. Armed with this critical perspective, charged to do something awesome, and empowered by carte blanche from my PI, I shot for the moon.
To make a long story short, I used a situated evaluation framework to integrate observations and feedback on a short development cycle for rapid-turnaround iteration - the buzzword-free translation is that I made it up as I went along with a little help from my friends and some excellent note-taking skills. This included discussing industry sexism to break down gender stereotypes in discussion and practice, differentiating diverse lessons across the whole K-5 cohort, lots and lots of distributing and cleaning up snacks, and centering equity concerns in the overall structure of the program.
By the end, we had kids at all grade levels doing things like: disassembling and reassembling computers and small electronics; basic bicycle and automotive maintenance; crocheting and making friendship bracelets; writing code and building robots; collaborating on Minecraft projects; and doing smaller one-off and short-term workshops with volunteers from the local chapter of the National Society of Black Engineers and Prominent Technology Company That Shall Remain Nameless. That's not even half the stuff, just a representative sample (I wound up creating 50 standalone and sequenced lesson plans as a result of this project). And at the end, my site liaison and the school's volunteer coordinator worked with me to develop a sustainable model that they're still running years later.
Basically, I was running a third-wave feminist hacker academy. And now I had to Present Results at a prominent conference, knowing that the situated nature of this program meant that it's success couldn't be replicated by doing the same thing elsewhere, because the methods were specific to the environment. WTF was I gonna talk about?
Space and time, of course.
Here we were with a crowd full of tech-savvy educators, wanting to know about all the cool shit we'd been doing, but the coolest thing wasn't this or that workshop, it was how we had used the space and time available to figure out what was needed, and then responded to that need as effectively as possible. My PI came up with the overarching conceit of a "self-demonstrating" session, where we'd all do the thing we were trying to teach them how to do, by way of a modified Think-Pair-Share: the attendees would listen to a five-minute intro spiel, spread out to think alone or in pairs about questions and obstacles they'd encountered in their own efforts to create engaging and participatory tech programs, then assemble into a few small-ish groups to share their thoughts and experiences, and finally we'd take back the helm and the last half would be a discussion of the most salient topics from the groupwork.
In other words, attendees collaboratively came up with questions and obstacles they needed help addressing, and we responded with practical advice peppered with anecdotes from Your Favorite Blogger that spoke to their issue. God, that sounds so generic - let me be more specific: someone asked how to address socioeconomic inequality among students, and I replied with an anecdote about how we used paper permission slips instead of Google Forms to run the sign-up. Some parents complained that it was such a low-tech method, and their kids would forget the forms or whatever, and couldn't we just bring the sign-up into the 21st century. I fought hard to keep it all on paper, because if parents could do it themselves at home, that would be a social justice double-whammy: the kids without at-home internet access would have a harder time signing up, and the kids would also be less involved in the process.
I then used this anecdote to talk about robustly considering the barriers to access that we create when we decide to go with one method over another. Sure, some (white) parents were butthurt that they couldn't take matters into their own hands to make sure Little Jimmy got into one of the (admittedly limited) spots, and he forgot his slip all the time 'cuz he was on his phone all night; but for the kids who didn't have home internet or smartphones, this was often the highlight of their week (besides recess), and they almost always got their slips in the first day. So, sure, I was creating a barrier to access that disproportionately affected the more affluent - but why did it go that way? Because for them, this was one tech experience among many; for the less affluent kids, this was their only chance.
That's why I went toe-to-toe with the (mostly white) PTA when they told me they felt my "old-fashioned" sign-up method was exclusionary: I explained (not in these exact words) how their desired solution would reinscribe the same power dynamics that got us here, and while this was an inconvenience for them, the kids who are turning in their slips on time have a greater need and are responding to that by taking responsibility. They grumbled - but they came on board.
This is the upshot of what I'm trying to get at: it's fine and good to look at specific mechanisms of attention control, or supermarket psychology, or asshole design, and come up with specific ways to counteract it. But it's much more important to understand the big-picture dynamics at play, the reasoning behind why we're even in this situation in the first place, and how the historical context and generational forces that brought us here continue to influence and shape us. This is also why I continue to describe myself specifically as "not a tech person, but a people person who happens to have a lot of technical skills": it's a broad-minded perspective that doesn't look at how "modern" or "old-fashioned" something is, but at which outcomes are life-enhancing, and which are life-draining.
No comments:
Post a Comment