Wednesday April 28, 2021.
\nFrankly, I had a terrible morning. Don't ask.
\nI wrote to Hamish McKenzie, the co-founder of Substack today (replying to an email chain he started in 2017 wondering if I'd be interested in trying out a new newsletter platform) to finally get this newsletter off Substack and properly onto Buttondown. And I got a reply! Progress? We'll see, I guess.
\nOn with the show.
\nOn the back of the previous episode's post about the UK Post Office's Horizon IT project, another long government/technology piece today (which, to be honest, applies to pretty much most technology projects), as well as a few short things that caught my attention.
\nShort things first, then:
\nThe Computer’s Voice - From Star Trek to Siri is a book by Liz W. Faber.
\nCaught my attention because: deconstructing the voices of computers that talk through the lens of gender is totally my jam and honestly seems like good reading for anyone involved in anything that even remotely touches voice user interfaces.
\nThe Hidden Mythology of Ōkami: Part by Katherine Byrne from 200 is a brilliant first post about the frankly stunningly art-directed 2006 game Okami. Caught my attention because: the debate about art and videogames was over years if not decades ago and here's as good a reminder as any. Also, people who do interactive, non-games work should pay more attention to games because there's so much to learn from and be inspired by.
\nThis 2007 article from Nielsen Norman Group (so, honestly, two blasts from the past) about the Palm Foleo ("Palm Foleo: A Failed mobile Device"). Caught my attention because: of all my writing about what the iPad might be good at, might not be good at, and what it might deliberately not be good at, through the lens of a mobile computing device launched 3 years earlier.
\nMaslow Got It Wrong by Teju Ravilochan is (was) at first a piece on where some of the ideas behind Maslow's Hierarchy of Needs came from. The piece has a good author's note that acknowledges the need for revisions and follow-ups. Caught my attention because: Maslow's hierarchy is trotted out often enough that anything wrong about it is worth knowing, anything about its origins or related material is worth knowing, and honestly I'm as guilty of this as well -- making sure you understand what it actually means, instead of just the general gist.
\nAndrew Ferguson found the novelization of Hackers, the 1995 film and it is glorious. Caught my attention because: mainstream depiction of technology and what technology might become, and the anticipation of the wider public's perception of that technology is kind of a thing I'm interested in anyway.
\nVia Ross Floate, a man in Adelaide, Australia was arrested and bailed for "[allegedly placing] fake QR codes over business COVID check-ins". Caught my attention because: Okay for one, can you get more cyberpunk-ish, and second: the whole risk of using QR codes and what feels like security through obscurity which relies on people not... printing out and putting other QR codes on top... as well as the quite frankly amazing bail condition of "not carrying fake QR codes"(!)
\nI had a conversation last week with someone at a pretty big government department about this problem I’d call Where Do You Start.
\nThe problem looks a bit like this:
\nYou have a government department and it’s busy humming along.
\nYou’d like to do something new. It’s not big — not like replacing your entire system. It’s not completely small, either, because you would like what you’re doing to become big.
\nWhat you want to do also doesn’t have anything to do with a crisis, or meeting a past-due requirement. You are in the most enviable position of a green field. Obviously you need to show results and be quick about it, but nothing is exploding (too much).
\nWhat you’re describing, or what you’re suggesting you want is actually a combination of policy/program/delivery/organizational change. Let’s just bite the bullet and call it Digital Transformation.
\nYou know you want to do things differently. You might want to do things differently because you:
\nknow that you’re organized around silos that don’t make sense anymore, or you recognize that you are organized around silos that would make the outcome you would like to see difficult to achieve;
\nonly have experience with a certain model of technology procurement, design and delivery (i.e. traditional government technology procurement: up-front requirements analysis, control agency approval, solicitation, waterfall design and development, emphasis on project management);
\nare intrigued or have heard about new approaches like digital services, user-centered design or human-centered design. You might have heard about “agile” (and you might also be nervous about it, because you might have heard/seen/experienced some agile failures); and
\nsuspect that a conventional solicitation/procurement might go to the incumbents (“the usual suspects”), or would only be accessible to incumbents and, basically, want such a different approach that you are not confident incumbent vendors are able to provide it.
\nYou have a team around you who are good at what they do. But what they do isn’t what you want. This doesn’t mean that the team can’t be good at what you want, just that they’ve never done it before. Nobody is good at things they have ever done before. You would like more assurance than “trying our best at something new”. This is, after all, public money that you’re spending.
\nGiven the above, you’re stuck. Do you need to procure something? You might feel like you need help writing the solicitation. You might feel like you’re not even sure what should be in the solicitation, or what shouldn’t be. Or how to communicate it. Or if there are different types of solicitation available. Or even later on, once there are responses, how they can be evaluated. Does this mean you need to procure help with the solicitation? Is that even allowed? How would you know if that help was any good?
\nYou have a big question: given all of the above, where do you start? What do you do next? You’re at the very earliest stages — you have an idea of an outcome or a change you’d like to make, but it feels like the current environment is going to push you down a certain route, or that it’s the lowest-energy route, the one of least resistance. Which is fine — that’s the way things are — but how do you go about the actual next steps? What are they?
\nSo: let’s pretend we’re having a conversation and I’m answering these questions for you.
\nLet’s make sure you’re clear on the problem you want to solve or the outcome you want to achieve. For our example, let’s assume this is an internally-driven problem. It’s not an external requirement, like Federal or State rules now say we must implement x, or report y.
\nYou might be thinking: “We do process X and there has to be a better way of doing this. I want to find a better way to do process X”.
\nWanting to find a better way to do process X is a problem, but to borrow a phrase, it’s not the right problem.
\nBut, I never find abstract examples like this helpful.
\nSo let’s make it real.
\nImagine you’re in charge of restaurant hygiene inspections, and the way you’re set up is that in addition to investigating urgent reports and regular inspections required by legislation, every 2 years you also generate a list of restaurants to proactively inspect. 2 years seems a long time to you. So the way you’re currently thinking about your problem is:
\n\n\n“As part of our food safety job, we come up with a list of restaurants to inspect for hygiene every 2 years and there has to be a better way of doing this”
\n
I like asking “so that…?” when people have statements like this. It helps anchor your problem to an outcome.
\nAnchoring a problem to an outcome opens up how we might achieve that outcome. Approaching something like a process problem means you’re already thinking about a certain process-type solution, as if you’re pre-ordaining (“There must be better software, or better technology, for doing this thing”).
\nSo ideally, the problem now becomes reframed as:
\n\n\n“There has to be a better way of inspecting restaurants for food hygiene than using a list we come up with every 2 years so that fewer people are struck ill when eating in restaurants”
\n
This immediately brings up some new questions that it would be good to have answers to:
\nSome of these questions are going to be annoying. Some of them may be, in practicality, out of scope of what you’re doing or want to do right now because they open a can of worms that you don’t want to deal with yet because they’re existential to your organization (e.g. “are our restaurant inspections actually effective at preventing food-borne illness?”)
\nSo, for practicality’s sake (but tabling it as a pretty fundamental issue), let’s assume that inspections are effective.
\nFiguring out this actual problem (reducing the number of people who are struck ill when eating in restaurants) while feeling like it makes your initial question impossibly big, is actually helpful to defining the scope of what to do and where to do it.
\nBut you might want to be prepared for different answers than what you assumed.
\nBecause it may be that there are different ways to reduce the number of people who are struck ill when eating in restaurants, than improving the way you use a 2-yearly generated list of restaurants for inspection.
\nBut let’s assume that for practical and political reasons (which are real reasons), the actual opportunity right now is to do something about this inspection process that is kicked off by the generation of this list every 2 years.
\nYou need to make a map that takes you from the start of something to your outcome. This map will help you understand or decide what you want to try changing in order to achieve our outcome of reducing the number of people who are struck ill when eating in restaurants.
\nThis map is one that is practically centered around an inspection process and the generation of a list of restaurants for inspection.
\nBut most importantly, it is a map that ends with reducing the number of people who are struck ill when eating in restaurants.
\nKeep this in mind, because when you get to the solicitation or procurement stage, what you want to center is the outcome of reducing the number of people who are struck ill when eating in restaurants.
\nNailing the process to the outcome means doing the work so you know:
\nIn other words, you need some sort of journey map, or some sort of conceptualization of one.
\nUnderstanding this map is important because in traditional language, it will help you define scope. A clearly defined scope helps reduce risk. This map is like (but not the same as) a business process diagram. It is different from a business process diagram because it involves people and their experiences more, which sounds trite, but isn’t in practice.
\nDoing this doesn’t need to take long. You just need enough of the map to know more than you did before.
\nDoing this will mean you have a better idea of what you should put in a solicitation.
\nTo make this simple and minimal, you need at least:
\nYou may be thinking “Well, we’ve never really done that before. We’re going to have to buy figuring that out. So what do we need to buy?”
\nIt depends. That isn’t a helpful answer, but it’s the true one. The reason why “it depends” is based on:
\nyour immediate expertise environment — what sort of expertise is available to you? If your assumption is that there is zero or negligible expertise available to you, your assumption is likely wrong. (It is more likely that any expertise that is available doesn’t have an outlet, or is not required / actively pushed away by existing technology management and procurement processes);
\nyour wider expertise environment — there may be teams outside your organization that have the relevant expertise; and
\nhonestly, a lot more factors.
\nOK, there’s two answers here:
\nFind existing, experienced teams in your government structure who can directly help and train people in your organization in defining, drafting and running through to award a problem-based, iteratively delivered, time-limited solicitation for achieving an outcome; or
\nProcure services or workshops (which might include organizations like 18F, from the Federal government) that will do the work involved in helping your team define, draft, publish and communicate a problem-based, iteratively delivered, time-limited solicitation for achieving an outcome.
\nYou might be thinking: Thanks Dan, that’s not actually an answer. I want to know what, exactly needs to go into that solicitation, or if it’s, say, an IAA, what needs to go into it. (Clue: for the IAA, I expect that the organization you’d be signing the IAA with would have pretty good language).
\nWell, I’m just over 1,900 words in, and that’s going to wait for the next post. But as a preview, some of the key words are going to be:
\nIn the meantime, I highly recommend reading the comprehensive and state-of-the-art reference work, the De-Risking Guide from 18F.
\nOK, that's it for today!
\nHow are you doing?
\nBest,
\nDan
\n","body_text":"0.0 Context Setting\n\nWednesday April 28, 2021.\n\nFrankly, I had a terrible morning. Don't ask.\n\nI wrote to Hamish McKenzie, the co-founder of Substack today (replying to an email chain he started in 2017 wondering if I'd be interested in trying out a new newsletter platform) to finally get this newsletter off Substack and properly onto Buttondown. And I got a reply! Progress? We'll see, I guess.\n\nOn with the show.\n\n1.0 Some things that caught my attention\n\nOn the back of the\nprevious episode's post\nabout the UK Post Office's Horizon IT project, another long government/technology piece today (which, to be honest, applies to pretty much most technology projects), as well as a few short things that caught my attention.\n\nShort things first, then:\n\nComputers that talk and gender\n\nThe Computer’s Voice - From Star Trek to Siri\nis a book by Liz W. Faber.\n\nCaught my attention because\n: deconstructing the voices of computers that talk through the lens of gender is totally my jam and honestly seems like good reading for anyone involved in anything that even remotely touches voice user interfaces.\n\nThe hidden mythology of Okami\n\nThe Hidden Mythology of Ōkami: Part\nby Katherine Byrne from 200 is a brilliant first post about the frankly stunningly art-directed 2006 game\nOkami\n.\nCaught my attention because:\nthe debate about art and videogames was over years if not decades ago and here's as good a reminder as any. Also, people who do interactive, non-games work should pay more attention to games because there's so much to learn from and be inspired by.\n\nThe Palm Foleo\n\nThis 2007 article from Nielsen Norman Group (so, honestly, two blasts from the past) about the Palm Foleo (\"\nPalm Foleo: A Failed mobile Device\n\").\nCaught my attention because:\nof all my writing about what the iPad might be good at, might not be good at, and what it might\ndeliberately not be good at\n, through the lens of a mobile computing device launched 3 years earlier.\n\nMaslow Got It Wrong\n\nMaslow Got It Wrong\nby Teju Ravilochan is (was) at first a piece on where some of the ideas behind Maslow's Hierarchy of Needs came from. The piece has a good author's note that acknowledges the need for revisions and follow-ups.\nCaught my attention because:\nMaslow's hierarchy is trotted out often enough that anything\nwrong\nabout it is worth knowing, anything about its origins or related material is worth knowing, and honestly I'm as guilty of this as well -- making sure you understand what it actually\nmeans\n, instead of just the general gist.\n\nData streamed across mirrored shades\n\nAndrew Ferguson found the\nnovelization of Hackers\n, the 1995 film and it is glorious.\nCaught my attention because:\nmainstream depiction of technology and what technology might become, and the anticipation of the wider public's perception of that technology is kind of a thing I'm interested in anyway.\n\nBail on the condition he... ...doesn't carry any fake QR codes.\n\nVia\nRoss Floate\n, a man in Adelaide, Australia was arrested and bailed for \"\n[allegedly placing] fake QR codes over business COVID check-ins\n\".\nCaught my attention because:\nOkay for one, can you get more cyberpunk-ish, and second: the whole risk of using QR codes and what feels like security through obscurity which relies on people not... printing out and putting other QR codes on top... as well as the quite frankly amazing bail condition of \"not carrying fake QR codes\"(!)\n\n2.0 Where Do You Start?\n\nI had a conversation last week with someone at a pretty big government department about this problem I’d call\nWhere Do You Start\n.\n\nThe problem looks a bit like this:\n\nYou have a government department and it’s busy humming along.\n\nYou’d like to do something new. It’s not big — not like replacing your entire system. It’s not completely small, either, because you would like what you’re doing to become big.\n\nWhat you want to do also doesn’t have anything to do with a crisis, or meeting a past-due requirement. You are in the most enviable position of a\ngreen field\n. Obviously you need to show results and be quick about it, but nothing is exploding (too much).\n\nWhat you’re describing, or what you’re suggesting you want is actually a combination of policy/program/delivery/organizational change. Let’s just bite the bullet and call it Digital Transformation.\n\nYou know you want to do things\ndifferently\n. You might want to do things differently because you:\n\nknow that you’re organized around silos that don’t make sense anymore, or you recognize that you are organized around silos that would make the outcome you would like to see difficult to achieve;\n\nonly have experience with a certain model of technology procurement, design and delivery (i.e. traditional government technology procurement: up-front requirements analysis, control agency approval, solicitation, waterfall design and development, emphasis on project management);\n\nare intrigued or have heard about new approaches like\ndigital services\n,\nuser-centered design\nor\nhuman-centered design\n. You might have heard about “agile” (and you might also be nervous about it, because you might have heard/seen/experienced some agile failures); and\n\nsuspect that a conventional solicitation/procurement might go to the incumbents (“the usual suspects”), or would only be accessible to incumbents and, basically, want such a different approach that you are not confident incumbent vendors are able to provide it.\n\nYou have a team around you who are good at what they do. But what they do isn’t what you want. This doesn’t mean that the team\ncan’t\nbe good at what you want, just that they’ve never done it before. Nobody is good at things they have ever done before. You would like more assurance than “trying our best at something new”. This is, after all, public money that you’re spending.\n\nGiven the above, you’re stuck. Do you need to procure something? You might feel like you need help\nwriting the solicitation\n. You might feel like you’re not even sure what should be in the solicitation, or what shouldn’t be. Or how to communicate it. Or if there are different types of solicitation available. Or even later on, once there are responses, how they can be evaluated. Does this mean you need to procure help with the solicitation? Is that even allowed? How would you know if that help was any good?\n\nYou have a big question: given all of the above, where do you start? What do you do next? You’re at the very earliest stages — you have an idea of an outcome or a change you’d like to make, but it\nfeels like\nthe current environment is going to push you down a certain route, or that it’s the lowest-energy route, the one of least resistance. Which is fine — that’s the way things are — but how do you go about the actual next steps? What are they?\n\nSo: let’s pretend we’re having a conversation and I’m answering these questions for you.\n\n1. What’s the Actual Problem\n\nLet’s make sure you’re clear on the problem\nyou\nwant to solve or the outcome you want to achieve. For our example, let’s assume this is an internally-driven problem. It’s not an external requirement, like Federal or State rules now say we must implement x, or report y.\n\nYou might be thinking: “We do process X and there\nhas to be a better way of doing this\n. I want to find a better way to do process X”.\n\nWanting to find a better way to do process X is\na\nproblem, but to borrow a phrase, it’s not the\nright\nproblem.\n\nBut, I never find abstract examples like this helpful.\n\nSo let’s make it real.\n\nImagine you’re in charge of restaurant hygiene inspections, and the way you’re set up is that in addition to investigating urgent reports and regular inspections required by legislation, every 2 years you also generate a list of restaurants to proactively inspect. 2 years seems a long time to you. So the way you’re currently thinking about your problem is:\n\n“As part of our food safety job, we come up with a list of restaurants to inspect for hygiene every 2 years and\nthere has to be a better way of doing this\n”\n\nI like asking “so that…?” when people have statements like this. It helps anchor your problem to an outcome.\n\nAnchoring a problem to an outcome opens up how we might achieve that outcome. Approaching something like a process problem means you’re already thinking about a certain process-type solution, as if you’re pre-ordaining (“There must be better software, or better technology, for doing this thing”).\n\nSo ideally, the problem now becomes reframed as:\n\n“There has to be a better way of inspecting restaurants for food hygiene than using a list we come up with every 2 years\nso that fewer people are struck ill when eating in restaurants\n”\n\nThis immediately brings up some new questions that it would be good to have answers to:\n\nHow many people are currently struck ill when eating in restaurants?\n\nHow would we know if fewer people were struck ill when eating in restaurants?\n\nWhen people\nare\nstruck ill from eating in a restaurant, do we know when the restaurant was last inspected?\n\nWhen we inspect restaurants, do the incidences of food illness decrease?\n\nSome of these questions are going to be annoying. Some of them may be, in practicality, out of scope of what you’re doing or want to do right now because they open a can of worms that you don’t want to deal with yet because they’re existential to your organization (e.g. “are our restaurant inspections actually effective at preventing food-borne illness?”)\n\nSo, for practicality’s sake (but tabling it as a pretty fundamental issue), let’s assume that inspections are effective.\n\nFiguring out this\nactual problem\n(reducing the number of people who are struck ill when eating in restaurants) while feeling like it makes your initial question impossibly big, is actually helpful to defining the scope of what to do and where to do it.\n\nBut you might want to be prepared for different answers than what you assumed.\n\nBecause it may be that there are\ndifferent\nways to reduce the number of people who are struck ill when eating in restaurants, than improving the way you use a 2-yearly generated list of restaurants for inspection.\n\nBut let’s assume that for practical and political reasons (which are\nreal reasons\n), the actual opportunity right now is to do something about this inspection process that is kicked off by the generation of this list every 2 years.\n\n2. Nail the process to the outcome\n\nYou need to make a map that takes you from the start of something to your outcome. This map will help you understand or decide what you want to try changing in order to achieve our outcome of\nreducing the number of people who are struck ill when eating in restaurants\n.\n\nThis map is one that is practically centered around an inspection process and the generation of a list of restaurants for inspection.\n\nBut most importantly, it is a map that ends with\nreducing the number of people who are struck ill when eating in restaurants\n.\n\nKeep this in mind, because when you get to the solicitation or procurement stage, what you want to center is the outcome of\nreducing the number of people who are struck ill when eating in restaurants\n.\n\nNailing the process to the outcome means doing the work so you know:\n\nwho the different people and teams are involved in getting from one end of the map to the outcome\n\nthe information that goes into this process\n\nthe decisions involved, and who makes those decisions\n\nthe actions involved, and who performs those actions\n\nIn other words, you need some sort of journey map, or some sort of conceptualization of one.\n\nUnderstanding this map is important because in traditional language, it will help you\ndefine scope\n. A clearly defined scope helps reduce risk. This map is like (but not the same as) a business process diagram. It is different from a business process diagram because it involves people and their experiences more, which sounds trite, but isn’t in practice.\n\nDoing this doesn’t need to take long. You just need enough of the map to know more than you did before.\n\nDoing this will mean you have a better idea of what you should put in a solicitation.\n\n3. Yes, but what do I do next?\n\nTo make this simple and minimal, you need at least:\n\nSomeone internal to own this initiative\nbecause you aren’t outsourcing this: you’ve said you want a new internal capability because this is core to your business.\n\nSomeone to manage a product or service\n— someone to own what it is that you might be making or changing to achieve your outcome. (This is\nnot\nproject management). Owning means making decisions.\n\nSomeone to do just enough research\nto help you nail your process to your desired outcome, which helps to figure out scope. This means a whole bunch of research interviews not just to technology and program, but also in this case\nrestaurant owners\nas well as figuring out what existing technology vendors are involved.\n\nSomeone to run procurement\nto help you express what you want to buy, design how you’re going to communicate those needs, run the process through to selecting and buying what it is you need.\n\nYou may be thinking “Well, we’ve never really done that before. We’re going to have to buy figuring that out. So what do we need to buy?”\n\nIt depends. That isn’t a helpful answer, but it’s the true one. The reason why “it depends” is based on:\n\nyour immediate expertise environment — what sort of expertise is available to you? If your assumption is that there is\nzero or negligible expertise available to you\n, your assumption is likely wrong. (It is more likely that any expertise that is available doesn’t have an outlet, or is not required / actively pushed away by existing technology management and procurement processes);\n\nyour wider expertise environment — there may be teams outside your organization that have the relevant expertise; and\n\nhonestly, a lot more factors.\n\n4.0 Give me short version already\n\nOK, there’s two answers here:\n\nFind existing, experienced teams in your government structure who can directly help and train people in your organization in\ndefining, drafting and running through to award\na problem-based, iteratively delivered, time-limited solicitation for achieving an outcome; or\n\nProcure services or workshops (which might include organizations like 18F, from the Federal government) that will do the work involved in helping your team\ndefine, draft, publish and communicate\na problem-based, iteratively delivered, time-limited solicitation for achieving an outcome.\n\nYou might be thinking: Thanks Dan, that’s not actually an answer. I want to know what,\nexactly\nneeds to go into that solicitation, or if it’s, say, an IAA, what needs to go into it. (Clue: for the IAA, I expect that the organization you’d be signing the IAA with would have pretty good language).\n\nWell, I’m just over 1,900 words in, and that’s going to wait for the next post. But as a preview, some of the key words are going to be:\n\noutcome definition (“statement of objectives”)\n\ntechnical discovery\n\nuser research\n\njourney mapping\n\nuser stories\n\nevaluation criteria\n\nIn the meantime, I highly recommend reading the comprehensive and state-of-the-art reference work, the\nDe-Risking Guide\nfrom 18F.\n\nOK, that's it for today!\n\nHow are you doing?\n\nBest,\n\nDan","raw_format":"markdown","source":"app","summary":"This issue explores where and how to begin modernizing government operations, using a mix of cultural commentary and concrete case studies. The connective tissue across diverse pieces—from the gender-coded voices of digital assistants to failed mobile devices to a man arrested for placing fake QR codes—examines how technology intersects with human perception, institutional inertia, and the gap between what we think we understand about systems versus their actual mechanics. The longer essay grapples with the specific paralysis that emerges when government departments want to pursue digital transformation but lack clear frameworks for starting, caught between unfamiliar methodologies, entrenched procurement practices, and uncertainty about whether existing teams can actually execute something genuinely new.","reading_minutes":13,"links":[{"url":"https://newsletter.danhon.com/archive/s09e21-seeing-past-the-horizon/","normalized_url":"https://newsletter.danhon.com/archive/s09e21-seeing-past-the-horizon","domain":"danhon.com","anchor_text":"previous episode's post","is_archive":0,"archive_url":null,"archive_service":null,"category":"self"},{"url":"https://www.upress.umn.edu/book-division/books/the-computeras-voice","normalized_url":"https://upress.umn.edu/book-division/books/the-computeras-voice","domain":"umn.edu","anchor_text":"The Computer’s Voice - From Star Trek to Siri","is_archive":0,"archive_url":null,"archive_service":null,"category":"external"},{"url":"https://www.nintendojo.com/features/editorials/ce-the-hidden-mythology-of-okami","normalized_url":"https://nintendojo.com/features/editorials/ce-the-hidden-mythology-of-okami","domain":"nintendojo.com","anchor_text":"The Hidden Mythology of Ōkami: Part","is_archive":0,"archive_url":null,"archive_service":null,"category":"external"},{"url":"https://en.wikipedia.org/wiki/%C5%8Ckami","normalized_url":"https://en.wikipedia.org/wiki/%C5%8Ckami","domain":"wikipedia.org","anchor_text":"Okami","is_archive":0,"archive_url":null,"archive_service":null,"category":"external"},{"url":"https://www.nngroup.com/articles/palm-foleo-failed-mobile-device/","normalized_url":"https://nngroup.com/articles/palm-foleo-failed-mobile-device","domain":"nngroup.com","anchor_text":"Palm Foleo: A Failed mobile Device","is_archive":0,"archive_url":null,"archive_service":null,"category":"external"},{"url":"https://gatherfor.medium.com/maslow-got-it-wrong-ae45d6217a8c","normalized_url":"https://gatherfor.medium.com/maslow-got-it-wrong-ae45d6217a8c","domain":"medium.com","anchor_text":"Maslow Got It Wrong","is_archive":0,"archive_url":null,"archive_service":null,"category":"external"},{"url":"https://twitter.com/epiktistes/status/1387432033337675777","normalized_url":"https://twitter.com/epiktistes/status/1387432033337675777","domain":"twitter.com","anchor_text":"novelization of Hackers","is_archive":0,"archive_url":null,"archive_service":null,"category":"external"},{"url":"https://twitter.com/RossFloate","normalized_url":"https://twitter.com/RossFloate","domain":"twitter.com","anchor_text":"Ross Floate","is_archive":0,"archive_url":null,"archive_service":null,"category":"external"},{"url":"https://www.9news.com.au/national/man-arrested-fake-qr-codes-adelaide-south-australia/98da9e7f-1014-4ec4-a96d-5a5a8d9ed65a","normalized_url":"https://9news.com.au/national/man-arrested-fake-qr-codes-adelaide-south-australia/98da9e7f-1014-4ec4-a96d-5a5a8d9ed65a","domain":"9news.com.au","anchor_text":"[allegedly placing] fake QR codes over business COVID check-ins","is_archive":0,"archive_url":null,"archive_service":null,"category":"external"},{"url":"https://derisking-guide.18f.gov","normalized_url":"https://derisking-guide.18f.gov/","domain":"18f.gov","anchor_text":"De-Risking Guide","is_archive":0,"archive_url":null,"archive_service":null,"category":"external"}],"sections":[{"id":1876,"ord":0,"number":"0.0","heading":"Context Setting","level":1,"word_count":70},{"id":1877,"ord":1,"number":"1.0","heading":"Some things that caught my attention","level":1,"word_count":53},{"id":1878,"ord":2,"number":null,"heading":"Computers that talk and gender","level":3,"word_count":60},{"id":1879,"ord":3,"number":null,"heading":"The hidden mythology of Okami","level":3,"word_count":79},{"id":1880,"ord":4,"number":null,"heading":"The Palm Foleo","level":3,"word_count":72},{"id":1881,"ord":5,"number":null,"heading":"Maslow Got It Wrong","level":3,"word_count":99},{"id":1882,"ord":6,"number":null,"heading":"Data streamed across mirrored shades","level":3,"word_count":53},{"id":1883,"ord":7,"number":null,"heading":"Bail on the condition he... ...doesn't carry any fake QR codes.","level":3,"word_count":93},{"id":1884,"ord":8,"number":"2.0","heading":"Where Do You Start?","level":1,"word_count":582},{"id":1885,"ord":9,"number":"1","heading":"What’s the Actual Problem","level":2,"word_count":606},{"id":1886,"ord":10,"number":"2","heading":"Nail the process to the outcome","level":2,"word_count":310},{"id":1887,"ord":11,"number":"3","heading":"Yes, but what do I do next?","level":2,"word_count":297},{"id":1888,"ord":12,"number":"4.0","heading":"Give me short version already","level":2,"word_count":214}]}